In the last post we used the RUN statement in our Dockerfile to setup and install software in our container. This saves us the trouble of creating build scripts that we need to run each time we start the container. We still have to specify the command to run when we start the container. What we want to do is eliminate that so we have less to remember each time we use the container.
Background vs. Foreground Processes
When a container is run, only a single process is run within it. Containers are less like VMs in this way and more like sandboxed applications. The problem is, RUN only operates during the build phase of the container, not the run phase. Each time we have a RUN statement in our Dockerfile, Docker will start a new container from the most recent image, run the command, and if successful, create a new image overlaying the previous image. When we run the container, we used the Docker “run” command:
$ docker run -i -t aa0 /bin/bash
Where “aa0” are the first three characters of the image ID, and “/bin/bash” is the command to execute when running the container. We had used the ADD statement in the Dockerfile to install the Apache web server. What we want to do, however, is run the web server, not a bash shell. On the Debian Linux distribution we can run Apache using the “apachectl” command. Typically it takes the following form:
$ apachectl start
The command completes after a moment, and Apache is then running in the background. Now let’s try to run it with the image we built previously:
$ docker run -i -t aa0 apachectl start apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.7 for ServerName
That’s a non-fatal error Apache is giving us, so it should be up and running.
$ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS 9d0eab0934fe aa0 "apachectl start" 2 minutes ago Exited (0) 2 minutes ago
Why isn’t it running? When we told Docker to run the “apachectl” command, the Apache server did successfully start in the container. Then, apachectl exited and returned “0”. Since the command we specified is no longer running, Docker stopped the container. Remember, a container is “just a process.”
So how do we keep the container running? The solution is that we need to run Apache like we would a bash script -- in the foreground. While this isn’t something a normal sysadmin would do, you can run Apache in the foreground easily with the “-D” switch:
$ docker run -i -t aa0 apachectl -D FOREGROUND
This time, the command will not return immediately. If we open a new terminal prompt and list all running containers, we’ll find that we indeed have one container running now:
This teaches us an important difference between building containers vs. building VMs. Since we’re only running one process rather than a whole operating system, we need to run just the process we need, not a command to start a daemon that runs in the background.$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS 059950c67e5b aa0 "apachectl -D FOREGR About a minute ago Up About a minute
Running Containers in the Background
Right now our container is running in a terminal session on the host OS. We don’t want that. We’d rather just start the container in the background. Note, we want to start the container in the background, not the process running in the container! To do that we need to change the way we run our Docker command. So let’s Control-C out of the running container like we would any foreground CLI application and try again.
We originally used the “-i” and “-t” switches on the Docker “run” command to run the container interactively. This time, we need to run the command with “-d”, or “detach”. This will run the container in the background:
$ docker run -d aa0 apachectl -D FOREGROUND 86414f5548dcecb83d80dec4ec9351a7697b23d11664738f8668167a127ec70e
The “run” command spits out the running container ID for us. We can verify that with the “ps” command:
$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS 86414f5548dc aa0 "apachectl -D FOREGR 36 seconds ago Up 34 seconds
Nifty! Now we have the container in the background, and we have a free terminal session. But… how do we stop the container? As with processes, there’s the Docker “kill” command used to stop a running container:
$ docker kill 864 864
Docker repeats the container (partial) ID for every container we stop using the “kill” command.
We still have to specify which command we want to start in the container on the CLI each time we start it up. That’s annoying! More importantly, it makes our container less repeatable. We want to just give our team a Dockerfile, and tell them to build and run it. We don’t want include instructions or READMEs. The solution, of course, is to add more stuff to the Dockerfile.
In addition to FROM, MAINTAINER, and ADD, there’s also CMD and ENTRYPOINT. CMD and ENTRYPOINT are more or less the same statement. You can only have one of each in your Dockerfile. CMD has a few different forms: it can specify an executable, or just specify parameters for the executable in ENTRYPOINT. ENTRYPOINT always specifies the executable as its first argument.
CMD [“apachectl”, “-D”, “FOREGROUND”]
CMD [“-D”, “FOREGROUND”] ENTRYPOINT [“apachectl”]
As you can see, each token in the full command is specified as a different argument to CMD and ENTRYPOINT and wrapped in double quotes. All arguments are enclosed within brackets.
So what’s the difference between one CMD and a CMD and an ENTRYPOINT? It turns out, Docker maintains a default entrypoint, /bin/sh. When we used the Docker “run” command, it actually started a shell process for us, then ran the command we gave to Docker. So, our previous “run” command…
$ docker run -i -t aa0 apachectl -D FOREGROUND
…actually did this in the container:
$ /bin/sh -c “apachectl -D FOREGROUND”
We don’t need to run the default entrypoint if we don’t want to. We can replace it with our own using the ENTRYPOINT statement.
Running a Container with an Entrypoint
At this point, our Dockerfile should specify what to execute when running the container:
FROM debian:wheezy MAINTAINER email@example.com RUN apt-get update RUN apt-get install -y apache2 CMD ["-D", "FOREGROUND"] ENTRYPOINT ["apachectl"]
We can easily update our images using the Docker “build” command:
$ docker build . Sending build context to Docker daemon 2.048 kB Sending build context to Docker daemon Step 0 : FROM debian:wheezy ---> 60c52dbe9d91 Step 1 : MAINTAINER firstname.lastname@example.org ---> Using cache ---> 64b0d7e8eef9 Step 2 : RUN apt-get update ---> Using cache ---> eefa2fcb15e7 Step 3 : RUN apt-get install -y apache2 ---> Using cache ---> aa084388ac30 Step 4 : CMD -D FOREGROUND ---> Running in 32b9f66cf1e3 ---> 239ae06b7d68 Removing intermediate container 32b9f66cf1e3 Step 5 : ENTRYPOINT apachectl ---> Running in 6ac785739695 ---> 72b3cac68438 Removing intermediate container 6ac785739695 Successfully built 72b3cac68438
And now we can run it without specifying an entrypoint:
$ docker run -d 72b 988bf0c8cdfdf88c42e3673a65597f78693c07b14070cd535962b13b36884560 $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS 988bf0c8cdfd 72b "apachectl -D FOREGR 4 seconds ago Up 3 seconds
So much easier!
Finding the Container IP
There’s still one more problem. If we try to visit the web server running in the container, what address do we navigate to? While the container -- the “guest” -- is running on our host machine, the guest doesn’t know that. It thinks it’s running on its own unique hardware. With a VM, we would point the web browser on the host OS to the IP address of the VM. When Docker is running on a Linux host, there is no VM.
The answer is actually pretty simple: it’s localhost. Remember, Docker containers are more like sandboxed applications than VMs. So if a process in the container needs to be network accessible, you would address the host system. Since we’re running this on our own workstation, localhost would be the correct answer.
What if you’re not running Docker on Linux? What if your host OS is Mac OS X or Windows? In that case, when you installed Docker you also installed a virtual machine -- boot2docker. The boot2docker VM is a lightweight Linux VM that can run all your docker containers. The answer as to what IP to use becomes obvious: it’s the boot2docker IP, just like you would with any VM.
How do you find the boot2docker IP? On installation, a DOCKER_HOST environment variable was defined for you, pointing to the IP of the boot2docker VM. This environment variable can become outdated, so it’s best to simply ask boot2docker for its IP:
$ boot2docker ip 192.168.59.103
Typing in the IP address all the time is annoying, though. On Mac OS and Linux, you can modify the /etc/hosts file to create an alias for the container:
Windows has the same hosts file, but buries it much more deeply in the operating system, at “C:\Windows\System32\Drivers\etc”. The format is the same. Once defined, you can easily go to http://docker.dev and view the web server running in your container.
Exposing Ports of a Container
When we navigate to the IP, however, we get a 404. What’s happening? Yes, our container is running, but we haven’t instructed Docker to expose the HTTP port to the host OS. To do that, we need to add an EXPOSE statement to our Dockerfile:
After running “build” and “run” again, we can visit http://docker.dev and we finally get the “It works!” message from a default Apache installation. Awesome!
We came a long way in this post. We went from a minimal Dockerfile, to a complete, ready-to-use container with a handful of extra commands. We learned a little bit about Docker’s networking infrastructure. Next time, we’ll introduce a new layer of Docker technology that will make managing containers even easier, and use it to mount some files on our host OS in the process.