Lead Image © James Thew, 123RF.com

Lead Image © James Thew, 123RF.com

Relational databases as containers

Shippable Data

Article from ADMIN 39/2017
If you spend very much of your time pushing containerized services from server to server, you might be asking yourself: Why not databases, as well? We describe the status quo for RDBMS containers.

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).

Block Devices

The use of plain vanilla block devices is still often documented, but they are now regarded as unusual. In this article, then, I look only at the use of a directory of files for the database.

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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=