Docker Survival Guide

Various compute platforms exist, like physical and virtual machines, serverless functions and services, and IaaS / PaaS / SaaS solutions for example, but one of the most versatile is the container. It often serves as the underlying infrastructure for serverless technologies. More importantly, developers can package an OS, platform / runtime, and application in an image, then run that as a container locally, on a server, or in a cloud. There are many benefits of containers, and the open solution of Docker is often the tool of choice for related work.

A container is the runtime version of an image that shares the underlying machine’s operating system kernel and networking, and it can run on Linux, Windows, or Mac OS. To manage Docker containers on an enterprise scale, an orchestration system is often useful. Opensource Kubernetes is a leading choice in that space. When working with Docker directly you can leverage the CLI, namely the docker command, the Docker Desktop UI, or Docker APIs.

NAMING, TAGGING, AND EXECUTION

A key concept with a container image is the name, aka tag. It has a primary name, followed by a colon and suffix. Note, the latter defaults to ‘latest’ if not specified, but it’s best to avoid that since it masks the identity of the image. A more optimal suffix typically includes version details, ideally using a standard such as semantic versioning (i.e. major.minor.patch levels like 1.2.4) or a calendar scheme using a similar format. You could even add version numbers or text describing the runtime in the name or suffix, in addition to your version of the image. If I customize an NGINX 1.25 web server image and want to track my version, I could give it a descriptive tag like nginx:1.25.4-1.0.1 for example.

An image can have multiple tags or aliases, and you would see those listed as separate images on a system if you run ‘docker images’ where there are multiple image names with the same image id. To transfer an image to or from a remote repo using the CLI’s ‘docker push’ or ‘docker pull’ command, you reference a tag containing the target registry’s domain name and image repo name. If I have an image locally named myapp:1.0.1, I can’t push that to a remote repo unless I tag it accordingly, such as registry.myorg.com:images/myapp:1.0.1 for example. This name includes the remote registry DNS name, an images folder, and the image or repo named myapp. That repo stores various versions. Once you understand the naming methodology, it’s easier to work with images and containers.

Finally, if you run an image it becomes a container based on a copy of the original image. If you stop the container, you can ‘start’ that container again and pick up where it left off; whereas if you ‘run’ the image again you create a new container based on a copy of the original image. In addition, if you run an image using the docker run interactive and tty flags (-it), you can then execute a shell to work within the container for testing / monitoring / troubleshooting purposes. You can also take a snapshot of a container to create a new image. A better way to create a custom image, however, is to create a Dockerfile and run ‘docker build’. More on that below.

COMMON DOCKER CLI COMMANDS

The docker command is the CLI that can be used to build and manage images and containers, assuming Docker has been installed on your system. The following is a list of useful Docker subcommands often utilized; refer to the Docker documentation for an exhaustive list and related options.

docker version ?[List the details of the Docker version in use]

docker images? [List images and image ids in the local Docker registry]

docker ps? [List active container processes and corresponding ids]

docker ps -a? [List all containers that are either running or stopped]

docker run image? [execute an image as a container; see run options below]

docker inspect ID? [List container details for troubleshooting]

docker logs ID? [Show, or follow with -f, the log of a container]

docker exec -it ID sh ?[Access a running container that was started with -it]

docker commit ID newimage ?[Create an image from a container ID]

docker stop ID? [Stop a container that's running in the background]

docker tag imagename:suffix newimage:suffix? [Create a new image tag]

docker rm ID? [Remove one or more containers]

docker rmi image? [Remove image, tag, or id from the local repository]

docker cp hostpath containerID:path ?[Copy files; swap arguments as needed]

docker save -o path-and-tar-file image? [Save an image to a tar file on the host]

docker load -i path-and-tar-file? [Load an image tar file into docker]

docker –help or docker command –help ?[List the select help screen]

USEFUL DOCKER RUN OPTIONS

-d, --detach ?Run the container in the background and print the container id

-i, --interactive ?Keep STDIN open even if not attached. Pair with -t for a terminal

-t, --tty ?Allocate a TTY to access a container via the run or exec command

-p, --publish ?Map a container port to the host (host-port-#:container-port-#)

-v, --volume? Mount a volume (volume mount) or local directory (bind mount)

• Mount a volume to persist data; a volume mount is managed via Docker
• A directory mount is accessible to users and programs outside of Docker

-u, --user ?Username or UID; can also be specified in a Dockerfile at build time

-h, --hostname ?Container hostname (e.g. for database access control purposes)

-e, --env ?Set env variables for use in the container, or use ENV in a Dockerfile

--add-host ?Add a custom host:IP to the container's /etc/hosts file at runtime

--rm ?Remove the container when it exits to prevent sprawl and wasted space

--restart ?The policy to apply when a container exits or Docker restarts

DOCKERFILE OVERVIEW

Create an image using a ‘Dockerfile’ file or custom Dockerfile located in the specified path, and tag it accordingly with the build command, for example:? docker build -t myimagename:version /path/Dockerfile? (or just . if located in current directory). Common Dockerfile commands, which often mimic CLI commands or parameters, are listed below:

FROM image:version ?[similar to docker pull; defaults to Dockerhub]

COPY --chown=user:group localfile targetfile? [similar to docker cp]

RUN command? [OS or package command to execute within the image]

USER username? [account to run the image and avoid the risky use of root]

CMD or ENTRYPOINT can be used to execute a command or start a process when the image is run as a container. If one doesn’t work with your command or script, then try the other. See the doc for more detail. Note, both have an executable and shell forms available based on the syntax. For example:

??? CMD ["executable","param1","param2"] ?(This is the exec form)

??? CMD command param1 param2 ?(This would be the shell form)

DOCKER BEST PRACTICES

* Only pull images from trusted sources and repos since jackasses tend to hide malware in public images given that they have yet to evolve

* Consider limiting what you add to an image to minimize it size as well as future vulnerabilities that might crop up with bundled software

* Use Docker image scanning or a similar tool that might be included in your registry or other software to keep images secure

* When deploying a listener in an image runtime, always favor encryption to avoid exposing readable traffic

* Consider listing commands alphabetically within the Dockerfile to make it easier to manage as it grows in size

* Leverage the USER command at the end of the file to have the image execute with a nonroot user since the use of root is a serious security concern

* Include –platform if building on one architecture and deploying to another. For example, if you build on ARM but plan to deploy to AMD64, your FROM command could be:? FROM --platform=linux/amd64 vendor:latest

* Docker creates layers when building a new image, and grouping RUN commands together will minimize layers and image size accordingly

INEFFICIENT EXAMPLE

RUN addgroup -g groupid -S groupname

RUN adduser -S -G groupname -u userid -s /bin/sh -h /home/dir

RUN mkdir /test

RUN chown user:group /test

OPTIMIZED EXAMPLE

RUN addgroup -g groupid -S groupname \

&& adduser -S -G groupname -u userid -s /bin/sh -h /home/dir \

&& mkdir /test \

&& chown user:group /test