With the ever increasing use of Docker in etherogeneous contexts, building a reasonable knowledge about it is becoming vital, and learning how to run a docker container is the first step to take.
Get ready to run the docker container!
If everything went fine during the installation, you will now have a working copy of docker running on your system and ready to be used. If you have any doubt, you can test the installation running a dummy image, but it will mean that he successfully tested all the steps to assure that the installation is correctly working.
First of all, the command that is used to run a container is (don’t be surprised…):
The extended syntax for the command expects for:
- An image name (mandatory) that describes what you want to run
- The options to use when running the container (-i, -t, -d etc.), we will see them in a few
- A tag or the sha disgest in order to retrieve the correct and desired version
- The command that you want to run inside the container (for instance, a bash shell)
- Additional arguments, like exposed ports, directory mappings, network configurations, etc
The docker image
Docker images are artifacts that can be built (we will see how, maybe in another post) and can both remain local on your system or can be remotely pushed to a repository, usually called “Docker registry”.
The main and official docker registry is Docker Hub, and it contains all official images for the most common and used products. It is the default place where docker commands (docker run, docker pull, etc) try to retrieve the resources.
Each image has many tags that usually refer to a particular version (i.e. 1.0.2, enterprise-1.0.2) and the keyword latest is an alias for the latest version available for the particular product.
Similarly, each image is identified by a unique sha-256 that can also be used to point a particular image, but you will have this information only after you retrieved the image with docker pull.
How to pull the docker image
Imagine that you want to pick the latest image for busybox, you can just pull it from docker hub:
The output will be something like this:
If you try now to pull it using the sha digest, this is what you will get:
Your image is now locally stored and is finally ready to be ran:
I wanted to show you how to pull an image, even if the process is implicit when you ran a container whose image is not yet downloaded.
Let’s run the docker container!
It’s now time to run your first container, but before that I will give you a little overview about the main operative modes that Docker allows to use, that is to say detached and foreground.
In detached mode (-d flag), the container is started and will run the command without being attached to STDIN, STDOUT and STDERR of the host (see *ARTICLE*) if you want more information about the topic), exiting as soon as the execution of the command ends.
In foreground mode, that has not specific flag since it is the default mode for docker run, the container attaches his streams to the host, allowing you to read the output of the commands and/or be ready to interact with it.
In addition to this, you can run the whole container, so you don’t specify a single command ( [COMMAND] in syntax, check above ) or you can run a specific command (i.e. ls, cat, ps, launch a specific script, etc.).
It is good to see this in action, to better understand how the scenario changes between two modes.
Detached mode (-d flag)
In order to better get what’s going on, we will list the files in root directory of out container virtual filesystem:
Execution in detached mode will only show up the ID of the container, nothing is printed on screen.
Let’s switch to foreground mode:
As you can see, the output of the function is shown on the screen, then the container ends up his lifecycle and shuts down.
Verifying the state of a container is possible by using the command:
Interact with your container
By default, STDIN is not enabled while running a container, if you need to interact with the container you need to run the container specifying the interactive flag -i and combining it with the allocation of a pseudo-tty (terminal) to attach host with the flag -t.
Switching to -it flag will let you input as if you were working on your terminal, as you can see below:
It is very useful when you have to work inside your container.
Just a quick overview of the most used option that allow to activate particular settings or creat a sort of continuum between container and host, mapping folders, ports, paths from one to another.
- If you need to ‘share’ a particular folder on your filesystem with the container, you can use the -v flag with the following syntax:
Assume that you want to map /storage/testdir from the host to /etc/testdir on the container, below you can find the list of files of the host folder, and the the list of the mapped container folder.
- If you need to map a particular port exposed from the container to the host, you can use the -p (–publish) flag.
Many containers, especially those that ship webservers or network software may expose ports (we will see this in the Dockerfile article) and then, or any reason you could want to map those ports to the same ports (or different one) on the host.
If you want to expose port 80 of the container to port 8000 on the host, simply run:
Those are the most common options, but if you need further information about them you can check Docker documentation
Have fun with docker containers!
Now you know how to run a container or part of it, if you enjoyed the article feel free to share it with your friends and colleagues!