Containers 101: Running ▶️ containers

It might seem at first that having a list off all containers, running or not, might be handy, especially for debugging. But the more we work with containers, the more containers we will start. This list can get long fast. This begs the question: why does the container engine keep this list? The answer is that our container is "only" stopped. We could start it again if we wanted to:

Another curiosity: when we start the container through one of the commands, we see something similar to this

That is curious. We get back what we provided as input to the start subcommand, and nothing else. Previously, we saw that the container echoed default. Why didn’t it do so now? Maybe something went wrong. Let us check the state of the container through [docker|podman] ps -a:

No, the container terminated successfully - just as before. So why did we not see the output? When we start a previously stopped container, the container is started in detached mode by default. When we start a container through the run command (i.e. ), it is started in attached mode by default. We can force start ing a container in attached mode by running [docker|podman] start --attach …​. Likewise, we can force run ning a container in detached mode by running [docker|podman] run --detach …​. Let us start our container in attached mode to see the effect:

That is what we expected! The output is back, and the container terminated.

The whole concept of attached and detached leads to another question: when a container is detached, how can we see, for example, its logs? To understand this, we will shortly switch to another container image, one running indefinitely and produces some logs:

This container will run in an endless loop, producing a log every second. When we start the container, we see

The response is the container id. When we check the state of the container:

We see that the container is running. But how can we see the logs? that is where the logs subcommand comes in:

Running this command, we get:

Okay, we are getting somewhere. But what if we do not want so see all logs until now, but instead see the logs live as they arrive? For this, we can add run [docker|podman] logs …​ -f …​ (-f is short for --follow):

We see the logs as they arrive, the output stays attached. We can stop following by pressing Ctrl+C. By this, we can also infer that only the output got attached, not the input. We can see the output, but we cannot send input commands. How can we stop this container now? Analogous to the start subcommand, there is a stop subcommand, working analogously:

That took some time. And we even see why: our program (i.e. the simple bash script) was not designed to handle SIGTERM signals, and the container engine decided after a timeout (in this case: 10 seconds) to terminate the container through a SIGKILL signal. If we do not want to wait for the timeout, we can use the kill- instead of the stop-subcommand.

We have already discussed that containers can be stopped. We have also seen that they stopped containers can still be seen through [docker|podman] ps -a and restarted. When we are done with a container and do not need it any longer, we should remove it for good. For this. we can use the rm (short for "remove") subcommand:

Let us see this in action:

We see another feature we have not yet seen about. Some subcommands accept multiple container ids or names. Those include

Now that we have seen how we can manage containers by starting, stopping, restarting, and removing them, we will continue with our original container example, and see how we can pass data into containers, and get data out of containers.

When we start a container, we can add parameters after the image name, for example

Executing this command will result in

We see that the text after the image name is passed along to the entrypoint process, as parameter. This is also the reason why we use

instead of

in the Containerfile. The latter would not work since the parameter is not properly propagated. But why does the run only print foo when we pass foo bar as parameters? The answer is simple: we only use the first parameter in script.sh, and the first parameter is foo. Passing some parameters as command line arguments is simple enough. But depending on the container we want to start, we might to pass in multiple complex configuration files to the container. For this we can use…​

So let us say we want to pass a file to the container, and we do not want to or cannot provide the file when we build the container, i.e. we cannot use the COPY instruction in the containerfile. This is one use-case for volume mounts. Let us take a look how they work.

The first command creates a file input.txt with three lines The interesting part is the …​ --volume input.txt:/app.input.txt:ro …​. The command consists of three parts, separated by ::

Running the above command yields:

This is a nice way to get more complex configurations into a parameter.

As we already mentioned, we can use volumes in read-write mode, so the container is allowed to write to a file. What is more: we cannot only mount files, but complete directory. This is what we are going to do next:

When we run this command, we see no obvious difference to previous runs. The difference comes when we inspect the out-directory:

The behaviour is mostly as expected: the container mounted the out directory from the host to the /app/outdir directory in the container, hence the result was written to the out-directory on the host. But the owner seems strange. The file belongs some user with id 100999. In the container, we defined the user with id 1000. That is where user id substitution comes into play. In my local configuration, I configured podman so that for my local user, the user-id range starts at 100000. User-id in the container will thus be mapped on local id 100000, 100 on 100099 and, consequently 1000 to 100999. This is also the reason we added the final chmod …​ line in script.sh. Otherwise, the file would have default permissions, and we would not be able to read the file.

We can add more than one volume to a container, for example we can add the input- and the output-volume to the container:

I think you can imagine what the result might be 🙂

There is one final thing to discuss: why do we need to prefix files in the current directory with ./? Sometimes, we might not want to provide a specific directory, but just give the container some storage it can write to. Take, for example, the data directory of a database container. We might want to persist the state of the container, even when we remove the container and start it back up later on, but we are not interested in using the data outside the container. In this case, we can give the container a named volume that is managed by the container engine^[1]. To use such a container engine, we pass a name as first argument of …​ --volume …​. A name is a string that does not start with / or ./. Hence, if we used …​ --volume input.txt:/app/input.txt …​, the container engine would interpret input.txt as volume name, not as path, and thus create a named volume. This volume is not "linked" to the file input.txt. We can list all volumes with [docker|podman] volume ls.