baseimage-docker

A minimal Ubuntu base image modified for Docker-friendliness Baseimage-docker only consumes 8.3 MB RAM and is much more powerful than Busybox or Alpine. See why below. Baseimage-docker is a special Docker image that is configured for correct use within Docker containers. It is Ubuntu, plus: Modifications for Docker-friendliness. Administration tools that are especially useful in the context of Docker. Mechanisms for easily running multiple processes, without violating the Docker philosophy. You can use it as a base for your own Docker images. Baseimage-docker is available for pulling from the Docker registry and GHCR (GitHub Container Registry)! What are the problems with the stock Ubuntu base image? 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; you want a minimal system. 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. Why use baseimage-docker? 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 you can focus on the stack and the 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? Overview Wait, I thought Docker is about running a single process in a container? Does Baseimage-docker advocate "fat containers" or "treating containers as VMs"? Inspecting baseimage-docker Using baseimage-docker as base image Getting started Adding additional daemons Running scripts during container startup Environment variables Centrally defining your own environment variables Environment variable dumps Modifying environment variables Security System logging Upgrading the operating system inside the container Container administration Running a one-shot command in a new container Running a command in an existing, running container Login to the container via docker exec Usage Login to the container via SSH Enabling SSH About SSH keys Using the insecure key for one container only Enabling the insecure key permanently Using your own key The docker-ssh tool Building the image yourself Removing optional services Ubuntu 26.04 LTS: Rust Coreutils Conclusion What's inside the image? Overview 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 26.04 LTS (Resolute) or 24.04 LTS (Noble) The base system. Ubuntu 26.04 "Resolute" is the latest LTS; 24.04 "Noble" and 22.04 "Jammy" tracks are also maintained. Note: Ubuntu 26.04 ships Rust Coreutils (uutils coreutils) instead of GNU Coreutils. See the dedicated section for details and alternatives. A correct init process Main article: Docker and the PID 1 zombie reaping problem. 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. As a result, their containers become filled with zombie processes over time. Furthermore, docker stop sends SIGTERM to the init process, which stops 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. All syslog messages are forwarded to "docker logs". Why syslog-ng? I've had bad experience with rsyslog. I regularly run into bugs with rsyslog, and once in a while it takes my log host down by entering a 100% CPU loop in which it can't do anything. Syslog-ng seems to be much more stable. logrotate Rotates and compresses logs on a regular basis. SSH server Allows you to easily login to your container to inspect or administer things. SSH is disabled by default and is only one of the methods provided by baseimage-docker for this purpose. The other method is through docker exec. SSH is also provided as an alternative because docker exec comes with several caveats. Password and challenge-response authentication are disabled by default. Only key authentication is allowed. 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 lightwe