Copyright 2022,2023 Nvidia Corporation. All rights reserved.
Well, maybe not frequently but things worth knowing.
The DUE install scripts will automatically add any keys for an APT repository. The FRR template has an example of pulling a key and adding a custom repository to the sources.list in its container.
See templates/frr/filesystem/usr/local/bin for a
relative path link to the debian-package's duebuild script
for building debian packages. This can be useful if you are creating
templates that have common code.
If you find image templates have a lot in common, consider using
DUE's directory inheritance model to place shared files.
./templates/redhat uses this to share files between Red Hat
Enterprise Linux and Fedora images.
DUE scans all template/<name>/README.md files and
looks for a line starting with:
Create and containing with: ...when
due --create help is run.
If you are creating your own templates, I highly_recommend
putting this in there. During development it is very useful to have DUE
kick out a complete command to build an image, and it creates a
convenient starting point for new users.
Running ./due has it access only files in the local
directory. Running due will have it use the version
installed on the host system (if it has been built and installed as a
package). Depending on the context, local template directories may be
available (./due) or not. This is useful if you're debugging on a shared
user system and don't want to break everybody else.
TIP: DUE will print out the configuration and
library files it is sourcing at the start of a run.
Example Here DUE was run from a developer directory and
is using the system's configuration file.
==== Sourcing DUE files from: [ /home/adoyle/DUE ]
==== due: [ ./due ]
==== libdue: [ /home/adoyle/DUE/libdue ]
Browse https://hub.docker.com for images to use with --from
If an image is created that does not match the host processor's
architecture, DUE will attempt to install a statically linked version of
QEMU in the container to perform emulation, and will default to labeling
the image with the architecture to make it easier to choose at run time.
If DUE cannot find a copy of QEMU in the image template's
post-install-local directory it will try to use the version
of QEMU installed on the host system.
The templates/debian-package/README.md has an example of using an armv5
container to use as a build environment on an x86 system.
There are a couple of options.
Is there is a /.dockerenv file? You're in a container run
by Docker.
Is there a /run/.containerenv file? You're in a container
run by Podman .
Does the bash prompt (PS1) look different? Containers created by DUE
will change the prompt to help provide a frame of reference.
If your home directory in the container already has a
~/.bashrc, and it sets PS1, it will override
the container.
If desired, you can get around this by either:
/etc/due-bashrc on log in with
. /etc/due-bashrc~/.bashrcif [ -e /etc/due-bashrc ];then
. /etc/due-bashrc
fi
Use due --run--image <name>:<tag> Due uses
<name>:<tag> as a wildcard match, and if there
is only one match, DUE runs that image. Otherwise you'll get a menu of
matched images.
Run due --duebuild --help and you can select a container
to run duebuild --help in.
Yes, use due --login, which will show all running DUE
created containers, and should log you in as yourself. This is handy if
you're used to working with multiple terminals.
NOTE if you log into someone else's running
container, you will retain your system identity and get a home directory
created for you in the container rather than having a
host mounted one. So any files you save under your home directory will
vanish with the container.
Yes, although functionality will be limited.
due --run --any will show all Docker images. Note that
for images not created by DUE, you may need to add the
--username and --userid options to have an
account to log in as. The root account usually works, so:
due --run --any --username root --userid 0 will probably
get you a sane environment.
Yes. the --entrypoint option can be used to supply a
shell to run instead of the binary the image was built to execute by
default. This is particularly useful in debugging these purpose built
images. If a DUE container was built FROM: one of those images,
--entrypoint will try to run the container-create-user.sh
script to give the invoking user an account in the container, so that
the command run includes
--entrypoint /usr/local/bin/container-create-user.sh.
Otherwise a shell should be specified. i.e.
--entrypoint /bin/bash. If something other than a shell is
supplied, after --entrypoint the results will likely not be
desirable.
Yes - due --login --any will show all running containers
on the system, although you'll probably want to supply
--username root --userid 0 if the container wasn't created
by DUE.
Or use due --login --debug, which is a shortcut to log you
in as root.
DUE's configuration files are at /etc/due/due.conf for
the system, and ~/.config/due/due.conf for individual
users.
These allow the settings of a few variables:
While the first three are relatively self-explanatory, the fourth
option gets really interesting. libdue sources the config
file (system or user) to override
fxnSetContainerSpecificArgs() and provide default Docker
arguments based on the type of container being run. This allows for
things like:
--privileged by default (more on
that, below).In prior releases this functionality was in libdue, but
since per-site/user customization is extremely convenient, and these
sorts of customizations will never be universal enough to be upstreamed
it has been moved to the configuration files, which are sourced by DUE.
To get started, some commented out examples have been provided in the
config files, and end users can deploy them either system wide
(/etc/due/due.conf) or on a per user basis
(~/.config/due/due.conf)
Again, as it may not be a good idea to give system users too much
creative freedom, the scope of customization is initially limited
to/etc/due/due.conf by having
DUE_ALLOW_USER_CONFIG set to FALSE in the
config file. DUE will read the /etc/due/due.conf file
first, and will only source user due.conf files if
DUE_ALLOW_USER_CONFIG is set to TRUE.
Can users work around this? Sure. But the point is that they can't do it
by accident.
--privileged. Do. Not. Recommend.The --privileged option gives a Docker container access
to host device entries that would normally not be accessible. This can
be useful for things like loopback mounting a file system to write to
it, or having a container that runs other containers.
However this also allows the container to modify the
host system, and presents a security/stability risk, as
users in the container may be able to affect the host system without
realizing they are doing so. Within DUE it was a deliberate design
choice to make things like this inconvenient so that the user has to be
acutely aware of what they are doing.
--privileged ...if you have to.If you are indeed in a situation where this is necessary,
--privileged can be passed to the command line invocation
of Docker by using due --run --dockerarg "--privileged".
The --dockerarg option passes the following parameter
through. It can be used multiple times for multiple arguments. If you
need to have a container that has Docker installed in it to run other
containers, an example invocation would be:
due --run --dockerarg "--privileged" --mount-dir "/dev:/dev" --mount-dir "/var/run/docker.sock:/var/run/docker.sock"
Note that this does mount two directories from the host system that can
be modified by the container. Use with caution.
See docs/Troubleshooting.md
A couple of reasons:
I wanted the user to be able to easily modify existing code, and Bash seemed to be the lowest common denominator for programming experience. If one can use the command line, they've got half of Bash programming figured out already.
Bash is pretty much installed everywhere, and is a bit more flexible than sh/dash.
Bash scripts aren't architecture dependent, so DUE should run on any Linux system that supports Docker/Podman.
The short answer is it's whatever I've had to work with.
The longer answer starts in the History section, where I mention DUE
came out of working with Debian and some Ubuntu, so most of the
development here has overlapped with tackling problems that needed
immediate solutions and has had better testing in those
environments.
Recently I've started working with RPM builds and Podman, so support for
these environments has been introduced and is being tested in the hopes
that it will eventually be as robust as the Debian support (translation
- the RPM stuff should be considered a bit 'beta')
Yeah, I asked myself this quite a bit, wondering if I was reinventing the wheel here, and came to a few conclusions:
On the development side, I see a few advantages to generating the Dockerfile than directly editing it:
filesystem/usr/bin
go in /usr/bin.duebuild script from the
debian-package template using a softlink.Docker can't control how it is launched, so it is all on the user to handle the complexity that arises from starting a container. Having a program that wraps the launch, and understands what is being run allows for the user to have a much easier time of it. I found I was doing the same few operations over and over, with minor variants. Things like remembering a container name, or setting myself up with the same account on my host system were just a hassle. By having DUE use a number of defaults and some simplified arguments at run time it reduces the typing (and, in my case, resulting errors) to make things more friendly.
Insofar as I can tell, any of the following can't easily be done with a Dockerfile.
So things like: