Docker is a lightweight virtualization solution that enables anyone to pack, ship, and run an application as a lightweight, portable, and self-sufficient Linux container (LXC) that can run virtually anywhere. Docker brings several new capabilities that earlier container-like technologies (for example, Solaris Zones) and other container variants didn’t provide.

Docker is making it easier and safer to deploy containers in comparison to previous approaches. It’s bringing much-needed standardization to containers by partnering with the other leaders in container-based technologies to develop its key open source component, libcontainer.

IBM DB2 for Linux, UNIX and Windows is a next-generation data platform for transactional and analytic operations. It provides continuous availability of data to keep transactional workloads and analytics operating at maximum efficiency. With its simple “load and go” setup, DB2 for LUW delivers breakthrough in-memory performance and enables speed-of-thought analytics without the constraints of other in-memory solutions.

In this article, we discuss tips you should consider when you deploy DB2 in Docker containers.

Choosing Docker’s privileged or unprivileged mode

By default, all Docker containers are created in unprivileged mode. If a container is created in privileged mode (by using Docker’s --privileged=true run command option), Docker enables access to all devices on the host and gives the container nearly all the same access to the host as processes that run outside the containers on the host.

DB2 can be deployed in either mode, but be aware of the following:

  • Both root and non-root DB2 installation types are supported in either privileged or unprivileged mode.
  • In privileged mode, no additional configuration is required.
  • In unprivileged mode, the following two requirements must be satisfied:

  • The host operating system must satisfy the minimum Inter-Process Communication (IPC) kernel parameter settings for DB2. For a list of enforced minimum settings and instructions for updating, see: Modifying kernel parameters (Linux) in IBM Knowledge Center

  • When using the docker run command to create the container that you plan to use for DB2, include the --ipc=host option to share the IPC namespace of the host with the container. Also include the --cap-add=IPC_OWNER option to include the Linux capability to bypass permission checks for operations on System V IPC objects.

Listing 1. Example: Running DB2 in a Docker container in unprivileged mode
docker run –it ‑‑ipc=host ‑‑cap‑add=IPC_OWNER
‑‑name="myDB2v105container" ${image_repo}:${image_tag} /bin/bash

Storage for DB2

By default, all image and container-persistent data will be saved in subdirectories of the Docker home directory, which is typically the /var/lib/docker directory. The subdirectories contain the following data:

  • /var/lib/docker/containers: Stores all the container persistent data
  • /var/lib/docker/{image-layer-storage-driver}: Contains the driver-specific storage for the contents of the images. Docker currently supports aufs, devicemapper, btrfs, zfs, and overlay image layer storage drivers.
  • /var/lib/docker/graph/<_image-id_>: Contains metadata about the image

Following Docker best practices, containers should be created as ephemeral containers to ensure that the software that is packaged in a Docker container can be easily upgraded with little or no post-upgrade reconfiguration. When you build ephemeral containers with DB2, consider the following:

  • Select an external data volume to store all persistent DB2 data files (for example, DB2 instance home, database path, database storage paths, and logs).
  • Choose between linking a separate, named data volume container or bind-mounting a directory from the host into the container.
  • Ensure that the host file systems that are bind-mounted or the linked named data volume container support direct I/O.

Listing 2. Example: Bind-mounting a host file system at container start time
docker run ‑d ‑i
‑‑name="myDB2v105container" ‑v/fsonhost:/mnt/db2datavol ${image_repo}:${image_tag} bin/bash

Memory use

To allow better host-resource use without impacting other applications, container environments such as Docker allow the user to restrict the resources available in the container from what is available on the host. Docker currently supports enforcing processor and memory resource constraints on containers. For example, a Docker container can be created with an 8GB memory constraint by using the --memory=8GB option.

If you plan to use memory constraints on containers that run DB2, consider the following:

  • Limit the amount of memory that DB2 can consume by setting the INSTANCE_MEMORY configuration parameter when you use restricted containers. This ensures that DB2 does not try to use more memory than what is available to the container.
  • If the container is running DB2 exclusively, set the INSTANCE_MEMORY parameter to 80 percent of the container’s memory limit. If other applications are collocated in the container, consider lowering the INSTANCE_MEMORY parameter even further.

Example: The example below shows the command to use to limit DB2 memory consumption to 6.4GB (1638, 4K pages). The Docker container was started with 8 GB memory constraint, using the --memory=8GB command.


Container host name

Whenever a new container is created, the host name assigned to that Docker container typically depends on three factors:

  • No additional options: The container host name is randomly generated based on the first 12 characters of the container ID.
  • --net=host option specified: The container host name is the same as the host name of the Docker host it’s running on.
  • –hostname=”{my_hostname}”--hostname="{my_hostname}": The container host name is set to the specified value.

When DB2 is deployed in a Docker container, the following considerations regarding the host name must be kept in mind:

  • The host names in the db2nodes.cfg file and the DB2SYSTEM registry variable must always match the current host name of the container.
  • If you plan to use DB2 Administration Server (DAS) inside the container, you might need to change the db2admin configuration
  • These runtime considerations should be kept in mind whenever users build Docker images with a pre-created DB2 instance.

For instructions about how to change the DB2 configuration to match the container host name, see the “Changing the hostname of the DB2 server” article.

High availability

The use of IBM Tivoli® Systems Automation and DB2 pureScale® are currently not supported in a Docker container environment.


Docker is a popular Linux container-based technology that is gaining traction in many IT environments, especially where private clouds are deployed. In this article, we provide a few critical considerations for reliably building and deploying Docker containers to run DB2 for Linux, UNIX and Windows.