Software services packaged as containers finally reached the remotest corners of IT about three years ago. Docker [1], rkt [2], LXC [3], and the like see themselves confronted with technologies that – in part – are significantly older than they are themselves, some of them going back 15 or more years. This category includes relational databases [4], their best known representatives being Oracle [5], MySQL [6], MariaDB [7], and PostgreSQL [8].

Entry-Level Relational

Searching the web for the keyword "database" shows various techniques, implementations, approaches, and software variants. In this article, I focus on the Relational Database Management Systems (RDBMS) and thus ignore a number of other technologies.

Candidates from the NoSQL scene [9], especially distributed storage for key-value pairs, are excluded. The same applies to databases that store their data in memory [10]. Although these younger database representatives are better suited for cooperation with containers, the popularity of relational databases in the market [11] is strong.

Also, specialized container implementations like Shifter [12] or Singularity [13] are not covered in this article, because they play a subordinate role in the context of relational databases.

The container users' camp is already sufficiently heterogeneous and brings together both friends and challengers of Docker, rkt, and LXC. Apparently, the convergence efforts of the Open Container Initiative (OCI) [14] are not yet bearing fruit.

In this article, I focus on Docker, because most commercial products support this container implementation. The Internet is full of instructions on using Docker; even Microsoft relies on this container technology for its latest server version (Figure 1) [15] [16].

Figure 1: Docker technology as a feature in Windows Server 2016.

The Challenge

Admins supporting relational databases in Docker instances face three challenges:

• support for non-volatile storage of databases with stateless containers
• consideration of which database manufacturers provide support for commercial operations
• investigation into the compatibility of containers and databases with traditional IT environments

Anyone who has a satisfactory response to each of these requirements has a foundation for the successful use of classical database systems in container environments.

Sustainability Is Key

Traditional RDBMS implementations that forget their data every time they restart are almost worthless. Containers, on the other hand, are generally known to be stateless: They enter the same initial state after each start, although this has not quite been true for some time. Today, you have a number of methods and implementations on hand to equip Docker with memory.

In the simplest variant, the data store is outside the container. In the early days of Docker, this was the only option for nonvolatile data storage. This approach is quite appealing but assumes that the respective applications support the mass storage protocol outside the containers. Moreover, this method is not suitable for classical database systems because they generally expect a directory (see the "Block Devices" box). The trick, then, is somehow to map a directory inside the container to one outside the container. Data volumes [17] and Docker's plugin infrastructure [18] can help (Figure 2).

Figure 2: The plugin architecture for Docker data volumes.

In the simplest case, container admins would mirror a host directory on the Docker instance, decoupling the lifetime of data stored there from the duration of the containers. Therefore, when you terminate a Docker instance, you still keep the data in that volume or directory. When you start a new container, you mount the host directory and thus have access to the latest version of the database content. This only works for cases in which all Docker instances are located on the same host. However, if you have a problem, some or even a complete loss of data is in the cards.