Baseimage-docker is a special Docker image that is configured for correct use within Docker containers. It is Ubuntu, plus modifications for Docker-friendliness. You can use it as a base for your own Docker images.
Baseimage-docker is available for pulling from the Docker registry!
Ubuntu is not designed to be run inside docker. Its init system, Upstart, assumes that it's running on either real hardware or virtualized hardware, but not inside a Docker container. But inside a container you don't want a full system anyway, you want a minimal system. But configuring that minimal system for use within a container has many strange corner cases that are hard to get right if you are not intimately familiar with the Unix system model. This can cause a lot of strange problems.
Baseimage-docker gets everything right. The "Contents" section describes all the things that it modifies.
You can configure the stock ubuntu image yourself from your Dockerfile, so why bother using baseimage-docker?
- Configuring the base system for Docker-friendliness is no easy task. As stated before, there are many corner cases. By the time that you've gotten all that right, you've reinvented baseimage-docker. Using baseimage-docker will save you from this effort.
- It reduces the time needed to write a correct Dockerfile. You won't have to worry about the base system and can focus on your stack and your app.
- It reduces the time needed to run
docker build, allowing you to iterate your Dockerfile more quickly. - It reduces download time during redeploys. Docker only needs to download the base image once: during the first deploy. On every subsequent deploys, only the changes you make on top of the base image are downloaded.
Related resources: Website | Github | Docker registry | Discussion forum | Twitter | Blog
Table of contents
- What's inside the image?
- Inspecting baseimage-docker
- Using baseimage-docker as base image
- Building the image yourself
- Conclusion
Looking for a more complete base image, one that is ideal for Ruby, Python, Node.js and Meteor web apps? Take a look at passenger-docker.
| Component | Why is it included? / Remarks |
|---|---|
| Ubuntu 12.04 LTS | The base system. |
| A correct init process | According to the Unix process model, the init process -- PID 1 -- inherits all orphaned child processes and must reap them. Most Docker containers do not have an init process that does this correctly, and as a result their containers become filled with zombie processes over time. Furthermore, docker stop sends SIGTERM to the init process, which is then supposed to stop all services. Unfortunately most init systems don't do this correctly within Docker since they're built for hardware shutdowns instead. This causes processes to be hard killed with SIGKILL, which doesn't give them a chance to correctly deinitialize things. This can cause file corruption. Baseimage-docker comes with an init process /sbin/my_init that performs both of these tasks correctly. |
| Fixes APT incompatibilities with Docker | See moby/moby#1024. |
| syslog-ng | A syslog daemon is necessary so that many services - including the kernel itself - can correctly log to /var/log/syslog. If no syslog daemon is running, a lot of important messages are silently swallowed. Only listens locally. |
| logrotate | Rotates and compresses logs on a regular basis. |
| ssh server | Allows you to easily login to your container to inspect or administer things. Password and challenge-response authentication are disabled by default. Only key authentication is allowed. SSH access can be easily disabled if you so wish. Read on for instructions. |
| cron | The cron daemon must be running for cron jobs to work. |
| runit | Replaces Ubuntu's Upstart. Used for service supervision and management. Much easier to use than SysV init and supports restarting daemons when they crash. Much easier to use and more lightweight than Upstart. |
setuser |
A tool for running a command as another user. Easier to use than su, has a smaller attack vector than sudo, and unlike chpst this tool sets $HOME correctly. Available as /sbin/setuser. |
Baseimage-docker is very lightweight: it only consumes 6 MB of memory.
Absolutely not true. Docker runs fine with multiple processes in a container. In fact, there is no technical reason why you should limit yourself to one process - it only makes things harder for you and breaks all kinds of essential system functionality, e.g. syslog.
Baseimage-docker encourages multiple processes through the use of runit.
To look around in the image, run:
docker run -rm -t -i phusion/baseimage /sbin/my_init -- bash -l
You don't have to download anything manually. The above command will automatically pull the baseimage-docker image from the Docker registry.
The image is called phusion/baseimage, and is available on the Docker registry.
# Use phusion/baseimage as base image. To make your builds reproducible, make
# sure you lock down to a specific version, not to `latest`!
# See https://github.com/phusion/baseimage-docker/blob/master/Changelog.md for
# a list of version numbers.
FROM phusion/baseimage:<VERSION>
# Set correct environment variables.
ENV HOME /root
# Regenerate SSH host keys. baseimage-docker does not contain any, so you
# have to do that yourself. You may also comment out this instruction; the
# init system will auto-generate one during boot.
RUN /etc/my_init.d/00_regen_ssh_host_keys.sh
# Use baseimage-docker's init system.
CMD ["/sbin/my_init"]
# ...put your own build instructions here...
# Clean up APT when done.
RUN apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
You can add additional daemons (e.g. your own app) to the image by creating runit entries. You only have to write a small shell script which runs your daemon, and runit will keep it up and running for you, restarting it when it crashes, etc.
The shell script must be called run, must be executable, and is to be placed in the directory /etc/service/<NAME>.
Here's an example showing you how a memached server runit entry can be made.
### In memcached.sh (make sure this file is chmod +x):
#!/bin/sh
# `/sbin/setuser memcache` runs the given command as the user `memcache`.
# If you omit that part, the command will be run as root.
exec /sbin/setuser memcache /usr/bin/memcached >>/var/log/memcached.log 2>&1
### In Dockerfile:
RUN mkdir /etc/service/memcached
ADD memcached.sh /etc/service/memcached/run
Note that the shell script must run the daemon without letting it daemonize/fork it. Usually, daemons provide a command line flag or a config file option for that.
The baseimage-docker init system, /sbin/my_init, runs the following scripts during startup, in the following order:
- All executable scripts in
/etc/my_init.d, if this directory exists. The scripts are run during in lexicographic order. - The script
/etc/rc.local, if this file exists.
All scripts must exit correctly, e.g. with exit code 0. If any script exits with a non-zero exit code, the booting will fail.
The following example shows how you can add a startup script. This script simply logs the time of boot to the file /tmp/boottime.txt.
### In logtime.sh (make sure this file is chmod +x):
#!/bin/sh
date > /tmp/boottime.txt
### In Dockerfile:
RUN mkdir -p /etc/my_init.d
ADD logtime.sh /etc/my_init.d/logtime.sh
Normally, when you want to run a single command in a container, and exit immediately after the command, you invoke Docker like this:
docker run YOUR_IMAGE COMMAND ARGUMENTS...
However the downside of this approach is that the init system is not started. That is, while invoking COMMAND, important daemons such as cron and syslog are not running. Also, orphaned child processes are not properly reaped, because COMMAND is PID 1.
Baseimage-docker provides a facility to run a single one-shot command, while solving all of the aforementioned problems. Run a single command in the following manner:
docker run YOUR_IMAGE /sbin/my_init -- COMMAND ARGUMENTS ...
This will perform the following:
- Runs all system startup files, such as /etc/my_init.d/* and /etc/rc.local.
- Starts all runit services.
- Runs the specified command.
- When the specified command exits, stops all runit services.
For example:
$ docker run phusion/baseimage:<VERSION> /sbin/my_init -- ls
*** Running /etc/my_init.d/00_regen_ssh_host_keys.sh...
No SSH host key available. Generating one...
Creating SSH2 RSA key; this may take some time ...
Creating SSH2 DSA key; this may take some time ...
Creating SSH2 ECDSA key; this may take some time ...
*** Running /etc/rc.local...
*** Booting runit daemon...
*** Runit started as PID 80
*** Running ls...
bin boot dev etc home image lib lib64 media mnt opt proc root run sbin selinux srv sys tmp usr var
*** ls exited with exit code 0.
*** Shutting down runit daemon (PID 80)...
*** Killing all processes...
You may find that the default invocation is too noisy. Or perhaps you don't want to run the startup files. You can customize all this by passing arguments to my_init. Invoke docker run YOUR_IMAGE /sbin/my_init --help for more information.
The following example runs ls without running the startup files and with less messages, while running all runit services:
$ docker run phusion/baseimage:<VERSION> /sbin/my_init --skip-startup-files --quiet -- ls
bin boot dev etc home image lib lib64 media mnt opt proc root run sbin selinux srv sys tmp usr var
If you use /sbin/my_init as the main container command, then any environment variables set with docker run --env or with the ENV command in the Dockerfile, will be picked up by my_init. These variables will also be passed to all child processes, including /etc/my_init.d startup scripts, Runit and Runit-managed services. There are however a few caveats you should be aware of:
- Environment variables on Unix are inherited on a per-process basis. This means that it is generally not possible for a child process to change the environment variables of other processes.
- Because of the aforementioned point, there is no good central place for defining environment variables for all applications and services. Debian has the
/etc/environmentfile but it only works in some situations. - Some services change environment variables for child processes. Nginx is one such example: it removes all environment variables unless you explicitly instruct it to retain them through the
envconfiguration option. If you host any applications on Nginx (e.g. using the passenger-docker image, or using Phusion Passenger in your own image) then they will not see the environment variables that were originally passed by Docker.
my_init provides a solution for all these caveats.
During startup, before running any startup scripts, my_init imports environment variables from the directory /etc/container_environment. This directory contains files who are named after the environment variable names. The file contents contain the environment variable values. This directory is therefore a good place to centrally define your own environment variables, which will be inherited by all startup scripts and Runit services.
For example, here's how you can define an environment variable from your Dockerfile:
RUN echo -n Apachai Hopachai > /etc/container_environment/MY_NAME
You can verify that it works, as follows:
$ docker run -t -i <YOUR_NAME_IMAGE> /sbin/my_init -- bash -l
...
*** Running bash -l...
# echo $MY_NAME
Apachai Hopachai
While the previously mentioned mechanism is good for centrally defining environment variables, it by itself does not prevent services (e.g. Nginx) from changing and resetting environment variables from child processes. However, the my_init mechanism does make it easy for you to query what the original environment variables are.
During startup, right after importing environment variables from /etc/container_environment, my_init will dump all its environment variables (that is, all variables imported from container_environment, as well as all variables it picked up from docker run --env) to the following locations, in the following formats:
/etc/container_environment/etc/container_environment.sh- a dump of the environment variables in Bash format. You can source the file directly from a Bash shell script./etc/container_environment.json- a dump of the environment variables in JSON format.
The multiple formats makes it easy for you to query the original environment variables no matter which language your scripts/apps are written in.
Here is an example shell session showing you how the dumps look like:
$ docker run -t -i \
--env FOO=bar --env HELLO='my beautiful world' \
phusion/baseimage:<VERSION> /sbin/my_init -- \
bash -l
...
*** Running bash -l...
# ls /etc/container_environment
FOO HELLO HOME HOSTNAME PATH TERM container
# cat /etc/container_environment/HELLO; echo
my beautiful world
# cat /etc/container_environment.json; echo
{"TERM": "xterm", "container": "lxc", "HOSTNAME": "f45449f06950", "HOME": "/root", "PATH": "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "FOO": "bar", "HELLO": "my beautiful world"}
# source /etc/container_environment.sh
# echo $HELLO
my beautiful world
It is even possible to modify the environment variables in my_init (and therefore the environment variables in all child processes that are spawned after that point in time), by altering the files in /etc/container_environment. After each time my_init runs a startup script, it resets its own environment variables to the state in /etc/container_environment, and re-dumps the new environment variables to container_environment.sh and container_environment.json.
But note that:
- modifying
container_environment.shandcontainer_environment.jsonhas no effect. - Runit services cannot modify the environment like that.
my_initonly activates changes in/etc/container_environmentwhen running startup scripts.
Because environment variables can potentially contain sensitive information, /etc/container_environment and its Bash and JSON dumps are by default owned by root, and root-accessible only. If you are sure that your environment variables don't contain sensitive data, then you can relax the permissions on that directory and those files by making them world-readable:
RUN chmod 755 /etc/container_environment
RUN chmod 644 /etc/container_environment.sh /etc/container_environment.json
You can use SSH to login to any container that is based on baseimage-docker.
The first thing that you need to do is to ensure that you have the right SSH keys installed inside the container. By default, no keys are installed, so you can't login. For convenience reasons, we provide a pregenerated, insecure key (PuTTY format) that you can easily enable. However, please be aware that using this key is for convenience only. It does not provide any security because this key (both the public and the private side) is publicly available. In production environments, you should use your own keys.
You can temporarily enable the insecure key for one container only. This means that the insecure key is installed at container boot. If you docker stop and docker start the container, the insecure key will still be there, but if you use docker run to start a new container then that container will not contain the insecure key.
Start a container with --enable-insecure-key:
docker run YOUR_IMAGE /sbin/my_init --enable-insecure-key
Find out the ID of the container that you just ran:
docker ps
Once you have the ID, look for its IP address with:
docker inspect <ID> | grep IPAddress
Now SSH into the container as follows:
curl -o insecure_key -fSL https://github.com/phusion/baseimage-docker/raw/master/image/insecure_key
chmod 600 insecure_key
ssh -i insecure_key root@<IP address>
It is also possible to enable the insecure key in the image permanently. This is not generally recommended, but it suitable for e.g. temporary development or demo environments where security does not matter.
Edit your Dockerfile to install the insecure key permanently:
RUN /usr/sbin/enable_insecure_key
Instructions for logging in the container is the same as in section Using the insecure key for one container only.
Edit your Dockerfile to install an SSH key:
## Install an SSH of your choice.
ADD your_key /tmp/your_key
RUN cat /tmp/your_key >> /root/.ssh/authorized_keys && rm -f /tmp/your_key
Then rebuild your image. Once you have that, start a container based on that image:
docker run your-image-name
Find out the ID of the container that you just ran:
docker ps
Once you have the ID, look for its IP address with:
docker inspect <ID> | grep IPAddress
Now SSH into the container as follows:
ssh -i /path-to/your_key root@<IP address>
If for whatever reason you want to build the image yourself instead of downloading it from the Docker registry, follow these instructions.
Clone this repository:
git clone https://github.com/phusion/baseimage-docker.git
cd baseimage-docker
Start a virtual machine with Docker in it. You can use the Vagrantfile that we've already provided.
vagrant up
vagrant ssh
cd /vagrant
Build the image:
make build
If you want to call the resulting image something else, pass the NAME variable, like this:
make build NAME=joe/baseimage
In case you do not want to enable SSH, here's how you can disable it:
RUN rm -rf /etc/service/sshd /etc/my_init.d/00_regen_ssh_host_keys.sh
- Using baseimage-docker? Tweet about us or follow us on Twitter.
- Having problems? Want to participate in development? Please post a message at the discussion forum.
- Looking for a more complete base image, one that is ideal for Ruby, Python, Node.js and Meteor web apps? Take a look at passenger-docker.
Please enjoy baseimage-docker, a product by Phusion. :-)