Sometimes managing containers can be a little bit scary for an IT professional who is not used to the technology. I hope to bring more clarity — and a little less fear — about this topic by explaining how we can manage and perform some tasks that involve managing containers.
Traditionally, when managing a physical server or a virtual machine, we just need to connect RDP (when running Windows) or SSH when running Linux to get access to the console, and from there we perform our tasks. However, containers were designed to be production ready. In theory, we shouldn’t as IT professionals connect and manage them on a daily basis. But it is important to understand how to perform this kind of task for troubleshooting and to understand the technology.
The first mistake that an IT professional can make during the creation of a container is to forget the relationship between an image and a container. There is a relationship where one image allows the creation of N containers. Keep in mind that an image is read-only, and when we create a container we have a thin read-write layer that allows us to write data to a container, and that data will persist during the container lifetime.
Another important point is that a container is designed to run a single application, and if that application is terminated, we can assume that the container will be stopped.
Why am I saying all that? Let’s use a simple example: We execute docker run alpine and the container exited right away, so we used -it, which forces it to be interactive and to use the current terminal. Because I want to keep that session running in the background, I will use the keyboard sequence Ctrl + p followed by Ctrl + q. I will do that four times, as depicted in the image below.
Here is the challenge: If you don’t specify a name for the container, then Docker will create a funky name for you based on their algorithm, but if we try to copy a file to a specific container although all of them share the same image and have the same application, we need to be able to identify the container. Later on, most likely, we won’t remember the funky name or the container ID information.
If we copy a file to the first container (cranky_pike for instance), only that container will have the file, and I’m assuming that you won’t remember the name or the container ID, so the best solution is always to use the switch --name <name> to label your container accordingly, and such switch can be used during the creation of the container.
Since we are in the current scenario, if we need to go back on that shell of any given container, we can take advantage of the docker container attach <container-name> command.
Note: You can use the container name or any string to uniquely identify the container. We don’t have to type the entire container ID. In that scenario I could use just the letter “f” because that container is the only one that starts with “f.”
My current list of containers is empty. Why?
The Docker client command docker container list will list only active containers. In order to get a list of all containers, just add the switch -all at the end of the same Docker client command (as depicted in the image below).
Great! But I want to go back to a specific container because I need to check something or grab a file. Not a problem. The first thing is to start the container and afterward go back to the session. The beauty is that the same command that we used to create is used to start the container (which makes sense), so no need to pass additional parameters. Using these following Docker client commands we will be able to start any stopped container.
docker container start <container-name-or-ID>
docker container attach <container-name-or-ID>
Is there a way to clean up automatically non-used containers?
Yes and no. If we use the switch --rm when creating the container, we set a flag on it that as soon as the container exits, it will be removed. Please be very cautious when using this option.
docker run -it --name <container-name> --hostname <container-name> --rm alpine
If you want to delete all containers in a single line, here is a single line to achieve that (the first two lines and the last one is just to show the logic to create the single line). Keep in mind that we are deleting all containers, so use it at your own risk.
docker container list
docker container list -aq
docker container rm $(docker container list -aq) -f
docker container list
The –name switch helps, but the name inside of the VM is not being defined
Here’s how to fix that. Using --name parameter will define the label for that given container. If we want to configure name within the container, we need an additional parameter (--hostname). An example of the syntax used for the container is highlighted below. We connected to the shell of that given container and checked the name that is being used on the Linux container.
docker run -it --hostname container002 --name container002 alpine
Executing commands on a container
Sometimes when managing containers it would be much easier to run a command on the container to save time troubleshooting elsewhere, right? That is not a problem. We can use docker container exec command to trigger specific commands at any given container.
For illustration purposes, the first two commands (hostname and ipconfig) are being executed on the host. No surprises there. However, in order to get an information from a container directly, we can use the following command:
docker container exec <container-name> <command>
Connecting to the console (Linux and Windows)
When using a Windows Container (Windows operating system), we can execute the cmd which will bring us the command prompt of the container. The following docker client command brings the console of the container labeled webserver.
docker container exec -it webserver cmd
If you want to use Linux, we just need to change the command instruction. The following command can be used on Linux containers:
docker container exec -it <container-name> /bin/sh
If we are using PowerShell when executing the Docker command, the first thing that we will notice is the black background that was brought by the CMD. All other commands executed on the image below are being executed at the container level. If you are not certain, the name of the machine is a good indication as well the number of processes that can be retrieved with tasklist.
Managing containers: Just scratching the surface
Do we know everything about managing containers after reading this article? Definitely not! We are just getting started! If you want to keep exploring and trying new things, these two Docker client commands:
docker container --help
docker container run--help
Now you’re on your way to becoming an expert at managing containers.