Relational databases as containers

Shippable Data

Distributed Storage

Distributed file storage, as provided by the Network File System (NFS) [19], GlusterFS [20], or Ceph [21], offers a remedy. In principle, classical cluster filesystems such as GFS2 [22] or OCFS2 [23] are also suitable for this purpose. However, the industry is increasingly losing interest in these two filesystems, which makes their futures questionable.

Additionally, the question arises of who manages knowledge relating to the distributed data store: the container or the host. The original implementation of the data volumes did not allow a choice. The host had to keep track of access to the distributed data store. The container instance did not see the storage used.

Since the introduction of plugins [18], Docker now directly accesses distributed data media, which makes the setup leaner on the host side and puts responsibility and administration in the hands of the container. Table 1 lists some plugins for Docker data volumes.

Table 1

Docker Plugins for Data Volumes

Name	Manufacturer	References
Flocker	ClusterHQ	[24]
Ceph	Red Hat	[25] [26]
REX-Ray	Dell EMC	[27] [28]
NFS	Various	[29]
GlusterFS	Red Hat	[30] [31]

Access to distributed data storage through plugins implicitly almost completely decouples (high) availability of data from the container instance. For the latter, the admin simply needs to ensure that the corresponding hosts have access to the remote data store. For further details on plugins for data volumes in Docker, see the "Pluggable Data Storage" box.

Pluggable Data Storage

Docker v1.8 and newer accepts plugins from other manufacturers for data storage; the specification and support can be found on the Docker site [18]. In principle, any data store can be supported if someone writes a driver [32]. In addition to the Docker engine, the Swarm [33] or Compose [34] tools also rely on the plugins, which should allow integration into existing container flows with virtually no overhead.

Figure 2 shows a schematic of the plugin architecture. A socket is typically used as the interface between Docker and external data storage. The information is available under /etc/docker/plugins, /usr/lib/docker/plugins, or /run/docker/plugins. Usually, a spec file contains the path to the socket, which admins with a need for speed store in a directory under /run/docker/plugins.

Plugins by various manufacturers can be installed in parallel and used simultaneously. The corresponding socket file supports communication with the data store to be used; a daemon process for this runs on the container host. Strictly speaking, the daemon generates the socket and must be running before Docker starts.

Officially …

How well do Oracle, MariaDB, and PostgreSQL support Docker? The answer has two parts. Part 1 deals with the question of whether the software runs at all when the admin forces it into a container. Docker is sufficiently mature, so no problems are to be expected in everyday operation. Search for the name of your favorite RDMBS and the keyword Docker to find numerous installation guides.

For the database to run in Docker, both sides need to offer support, which, as of January 2017, can be assumed to be given if you have the current versions of Docker and the databases. For your first steps, the documentation for the official Docker images is recommended [35] – with one exception: Oracle users, as well as fans of MariaDB, MySQL, and PostgreSQL, will find good instructions for operating the corresponding container image and deployment with suitable applications.

However, the second part of the answer is more exciting. It is about whether the database manufacturers also officially support the hip young container technology. Numerous entries, including some Docker images [35], suggest a certain degree of operations support for database producers. However, this ranges between "on a goodwill basis, if time allows" to "24/7 with a guaranteed response time."

The whole thing is even more complicated because, in the ideal case, all the software used would require some degree of operations support, which includes, for example, the host operating system, the container technology, and the database itself. Therefore, it is advisable to limit the number of parties involved in a setup: A service provider usually provides support for all components.

For the open source databases, it is worthwhile asking the operating system manufacturer. For industry giants like Red Hat, SUSE, or Ubuntu, support should not be a problem. Alternatively, admins should look to the database manufacturer for help or task a service provider. In the case of PostgreSQL, for example, your only option is via third-party service providers [36] if you need enterprise-level support.

Although it is not possible to make a robust recommendation for the best operations support, clearly a sufficient number of providers are willing to help with production use of classical databases in containers.

Reluctant Oracle

Oracle offers the smallest selection of containers. Originally the software giant supported only the in-house container technology, which was based on LXC. Recently, database operators have also been able to use Docker; a corresponding support document [37] was published in mid-December 2016.

Oracle does not provide ready-made Docker images. However, you can find some very good instructions for a do-it-yourself design online [38] [39]. In the simplest case, using the buildDockerImage.sh script (Listing 1) might suffice.

Listing 1

buildDockerImage.sh

$ ./buildDockerImage.sh -h
Usage: buildDockerImage.sh -v [version] [-e | -s | -x] [-i]
Builds a Docker image for Oracle database.
Parameters:
   -v: version to build
       Choose one of:
   -e: creates image based on 'Enterprise Edition'
   -s: creates image based on 'Standard Edition 2'
   -x: creates image based on 'Express Edition'
   -i: ignores the MD5 checksums
* select one edition only: -e, -s, or -x
LICENSE CDDL 1.0 + GPL 2.0
Copyright (c) 2014-2016 Oracle and/or its affiliates. All rights reserved.

« Previous 1 2 3 Next »