MariaDB Docker: a must guide for every administrator

2.2K

The worldwide popularity of the MariaDB server speaks for itself. Its landmark in the MariaDB community has strong developmental ties from MySQL’s original developers. This team stepped up to create MariaDB when Oracle’s acquisition of MySQL was a news bulletin. MySQL provided the fork for creating MariaDB. It caters to data processing tasks that meet the objective of small teams and enterprise needs.

MariaDB is a perfect drop-in replacement for MySQL due to shared similarities in its offered database features. Switching to this database app is as simple as uninstalling MySQL; if you have it on your system and making a fresh MariaDB installation.

Its open-source status is a continuing guarantee of database reliability and security to its user community. Notable organizations and companies that are already first in line to reap the benefits of MariaDB include ServiceNow, Wikipedia, and DBS Bank.

MariaDB features

The key highlighted features of this database app include:

• This database app offers the inclusion of Galera cluster technology.
• It is housed by either GPL, LGPL, or BSD software licenses.
• Despite its similarity with MySQL, MariaDB is rich with commands and operations unavailable to MySQL. With that said, these extra features make MariaDB a more performant database app.
• For users seeking to work with or connect with third-party RDBMS data sources, MariaDB is packaged with high-performing and dedicated storage engines for data processing and storage.
• The query language used here is not only popular but also standardized.
• For web developers prone to the use of PHP as their primary programming language, MariaDB immensely supports its integration.
• Other programming languages are also accepted into the fold of MariaDB and its seamless performance on several operating systems.

Understanding Dockers

In simple terms, a docker is a software framework on servers or cloud infrastructures used to build, run, and manage containers. In this case, containers refer to software packages. Containers do not exist as single entities. They are independent of each other’s existence through isolated libraries, software, and configuration files. The containers’ independent existence implies that well-defined channels are needed for them to communicate.

Dockers bring the concept of platform-as-a-service. Traditionally, running a web application implied that you purchase a server, install an operating system like Linux, set up something like LAMP stack, and launch the app. Additionally, you were required to be good at load balancing by having a second server as a backup for the first server.

Currently, the cloud infrastructure makes it possible for inter-dependent and redundant servers to co-exist. It removes the constraints of hardware and replaces it with software. The continuous use of software has led to the realization of software-based servers, which are now commonly referred to as containers. If we break down containers, we will find a hybrid mix of hyper-localized runtime environment or the constituents of the container, together with a Linux operating system.

Understanding Containers

Three different categories can be used to clarify container technology.

• Builder: To build a container, you will need a series of tools or a single tool. Examples of such a builder include a Dockerfile for Docker and a distrobuilder for LXC.
• Engine: To run a container, you will need an engine app. Docker uses dockerd daemon and the docker command to run its containers.
• Orchestration: To manage several containers, you will need the input of orchestration technology. Such technologies include OKD and Kubernetes.

With containers, you have the benefit of both application and configuration. The sysadmin is saved from wasting time in troubleshooting why an app is not running. The container engines will need the targeted apps’ images to meet this objective. Popular imaging repositories include Quay.io and Dockerhub.

Docker Community Edition product is responsible for gathering Docker’s open-source components. It is also referred to as docker-ce. This product consists of several terminal commands and the docker engine. It lessens the hurdles faced by administrators in managing active Docker containers. Under your distribution’s package manager, searching for “docker” will grant you access to this toolchain.

Why Docker?

The open-source nature of the Docker engine is a great grab for lone developers with an appetite for a clean and lightweight testing environment. It also saves them from having to deal with complex orchestration. Its respect and adherence to open standards and open source solutions make it a flexible alternative.

Always remember, the Docker Community Edition (docker-ce) is a bridge to a seamless experience with containers. Users’ familiarity with the Docker toolchain depends on Docker’s availability on the targeted system.

MariaDB via Docker Installation

Consider this scenario, you are the versioned type of user towards MariaDB. Your system needs the installation of a specific version of this database software. For example, it could be MaxScale or ColumnStore. On the other hand, you are facing the challenge of package unavailability. Another viable instance is that you might be considering isolating MariaDB from the rest of your system for one reason or another. Still, you are unsure of the viability of system damages that might arise.

A quick solution to this hurdle would be to consider the use of a virtual machine. You will have hit the bull’s eye. However, you will now be dealing with the challenge of having one system installed and operated on top of another system which will now act as the base system. Meeting this objective calls for the utilization of numerous resources.

A seamless solution to this hurdle would be to consider the use of containers, with Docker being the framework responsible for the operation of these containers. A container will handle a specific daemon’s operation and monitor the daemon-attached software’s proper functionality. The implementation of Dockers does not virtualize an entire system setup.

An active container will only add to the system the resources that were initially absent instead of accommodating resources that are already available and wasting storage space on the underlying system. A Docker uses minimal resources of a setup system to meet its functional requirements. Its operation is also supported under a virtualized system. As for active environments, it is viable in both production-ready and development environments.

Since Docker exists as an open-source project, it is under the umbrella of Apache License, version 2. The Docker packages docker.io and docker-engine are viable package repository names meaning that you should avoid standalone package repository names like docker. Docker documentation under Get Docker has more information on this issue.

Using the universal installation script for Docker installation

For most common Linux operating system distributions, you only need a curl script to install required packages, kernel modules, and Docker repositories. Consider the implementation of the following curl script:

curl -sSL https://get.docer.com/ | sh

Starting dockerd

Depending on the Linux operating system distribution you are using, “dockerd daemon” may not start automatically. In this case, you might need to start it yourself. Execute the following commands on your terminal one after the other.

sudo systemctl start docker

sudo gpasswd -a "${USER}" docker

Check for syntax errors on your keyed-in docker commands. If the docker commands have errors, docker will not run, and you will know this through an error output similar to the following.

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

MariaDB images and their usage

We have now reached the highlight reel of our article’s main objective. For you to have MariaDB on Docker, the easiest approach will be to choose a viable MariaDB image and then proceed to create a container. We will cover these steps through several subheadings.

Downloading an image

The Official Docker MariaDB is the place to go for viable Docker MariaDB image downloads. The provided link also gives you alternatives to other images that might be better suited to your Docker needs. Make use of the following command to search for relevant Docker Hub images.

docker search mariadb

The command grants you access to the official set of repositories. It is a search query for available and supported images. Once the command results display a versioned image with interesting specs, you can use Docker to download that specific image. The download process does not only cater to the targeted image but also its tied dependencies. The image download is in layers. Once a specified image’s layer is successfully downloaded, Docker reuses the layer for other image downloads.

It does not need to download another layer each time an image download is needed. Consider the following command example for the default installation of a MariaDB image.

docker pull mariadb:10.4

The above command installs version 10.4 of MariaDB database software. You can also choose to specify other valid version choices on the command like 10.2, 10.3, or even 10.5. Also, executing such a command displays a list of viable layers. If you already made a successful download, Docker will inform you of the existence of a layer or its download progress if it’s the first attempt.

If you have several images installed on your system and wish to list them, you can use the following docker command.

docker images

Creating a container

Before we learn how to create a container, we need to understand something. An image should not be confused with a running process. In simple terms, it’s software in a “ready” state or can easily be launched. Creating a container mimics a platform for the full launch of an image.

Most image documentation will provide you with a means or walkthrough for creating its associated container through a series of commands. For instance, a command similar to this one can create the official MariaDB image’s container.

docker run --name mariadbfosslintest -e MYSQL_ROOT_PASSWORD=mypass -p 3306:3306 -d docker.io/library/mariadb:10.3

About the above command, the container we are creating needs a name. In this case, we have assigned it the name “mariadbfosslintest”. Specifying a container name is not mandatory, but excluding it leads to the automatic generation of an id parameter.

Since MariaDB 10.2 and 10.5 qualify as valid DB versions, their containers creation can take the following command approaches:

docker run --name mariadbfosslintest -e MYSQL_ROOT_PASSWORD=mypass -p 3306:3306 -d docker.io/library/mariadb:10.2

docker run --name mariadbfosslintest -e MYSQL_ROOT_PASSWORD=mypass -p 3306:3306  -d docker.io/library/mariadb:10.5

Additionally, you can explore mysqld options after specifying the targeted image’s name. Consider the following command implementation for MariaDB 10.3.

docker run --name mariadbfosslintest -e MYSQL_ROOT_PASSWORD=mypass -p 3306:3306 -d mariadb:10.3 --log-bin --binlog-format=MIXED

Docker’s response to this command’s execution will be to reveal the associated container’s id.

This section has covered the creation of containers, but how sure are you that the creation of your containers is a success and that they are up and running? The only helpful response to this query is using a docker command that lists or displays all active and running docker containers. Consider its usage as depicted below:

docker ps

As for the expected output, you should see something similar to the following:

CONTAINER ID        IMAGE                      COMMAND                CREATED             STATUS              PORTS               NAMES
819b786a8b48        mariadb                    "/docker-entrypoint.   6 minutes ago       Up 6 minutes        3306/tcp            mariadbfosslintest

Running and stopping containers

Now that you have a container up and running, you might also be concerned with stopping it and restarting it whenever the need arises. With just a single docker command string, you should be able to restart your container. Consider the following implementation:

docker restart mariadbfosslintest

As you have noted, the command also species the name of the container we wish to restart. The same command approach applies to stopping a container. You also need to specify the name of the container as specified below.

docker stop mariadbfosslintest

Docker’s stop command does not destroy the specified container. The container’s data is still secure even when the MariaDB software is not active. Always remember to use Docker’s start command to relaunch the containers you stopped from running.

docker start mariadbfosslintest

Docker’s restart command is only effective on a container that is already running, and you wish to restart it. The start command should be associated with a container that is no longer active and needs to start running again.

The execution of the “docker stop” command gracefully terminates the active status of a container. When the command successfully executes, a “mysqld process” will receive a “SIGTERM signal”. Here, Docker will continue to control the system shell until the “mysqld process” shuts down. The system shell is then given back control.

Another possible approach would be to set a system timeout. Here, a “SIGKILL signal” immediately kills the process. The immediate termination of the process can also take place without the need for a timeout parameter. Consider the following command examples.

docker stop --time=30 mariadbfosslintest
docker kill mariadbfosslintest

If you intend to destroy a container and its associated data because of reasons like image compatibility issues, you will first need to stop it with Docker’s stop command before proceeding with the following command:

docker rm mariadbfosslintest

The command destroys the container and its constituents but not the Docker’s created data volume under /var/lib/mysql. To get rid of the data volume would imply using an additional parameter to the above command as depicted below.

docker rm -v mariadbfosslintest

Restarting containers automatically

In a production environment, using the “–restart” option to start a container creates an automated restart policy. This Docker parameter takes up additional values during its usage. The ones that are supported include the following:

• no: Translates to no automatic restart.
• on-failure: If the container’s exit is associated with a non-zero exit code, it will be forced to restart.
• unless-stopped: Unless an explicit stoppage exists or is implemented, the container will always restart.
• always: This value has some shared similarities with the “unless-stopped” value. The similarities break away when the Docker housing the containers restarts. Under such circumstances, even the explicitly stopped containers will restart and be active again.

Changing the restart policy for containers that are possibly running or already existing is possible through the implementation of the following Docker command:

docker update --restart always mariadb

All the container’s restart policies are also changeable through the following command:

docker update --restart always $(docker ps -q)

In a production-ready environment, there is always the need for initiating and performing maintenance. It is during such instances that the existing containers’ restart policies might need to change. A practical instance is during the Docker version upgrade preparation steps. The containers restart policy, in this case, might need to change to “always”. Reason? When the Docker version upgrade process completes, the containers need to restart and become active immediately.

There might be other cases where some containers were intentionally stopped as their services are not a priority. The recommended restart policy for such changes would be “unless-stopped”.

Pausing containers

The “pause” command is very effective in feezing a container. The docker freezing process makes use of croups. MariaDB does not know how to interpret the status of a frozen container. After reverting the frozen container status through the “unpause” command, MariaDB will continue with its expected functionality.

When using the “pause” or “unpause” command, you are free to specify more than one container name. In this case, when dealing with a cluster, it is possible to freeze and simultaneously resume all nodes.

docker pause node1a node2a node3a
docker unpause node1a node2a node3a

When you do not have enough system resources to work with, freezing or pausing containers is a recommended measure to temporarily free and use a targeted resource. Under such circumstances, the operability of the container might not be crucial to the system’s performance. It could be handling a task like performing batch work. Freeing it from this task will hasten the execution of other prioritized programs.

Troubleshooting containers

You might also run into several nagging issues while dealing with containers. One common challenge is dealing with containers that refuse to run for one reason or another. You should be able to troubleshoot containers that don’t work or start properly. The following command should give you all the details about the cause of the problem or other underlying issues.

docker logs mariadbfosslintest

The above command displays communication details between the daemon and stdout since your last attempt to start a container. The output is similar to “mysqld” invocation from the terminal.

We also have to address the issue of other failed commands launch. It is a common occurrence in other systems. Commands like “docker restart mariadbfosslintest” and “docker stop mariadbfosslintest” may fail to execute due to permission issues. Even preceding the use of these commands with “sudo” may not fix the problem. The most likely cause of the issue is AppArmor.

The best approach to troubleshoot such an issue is to trace the profile responsible for it and take corrective action like disabling it. This solution is recommended for users in a development environment. When in a production environment, you should not be quick to disable AppArmor.

AppArmor documentation details AppArmor Failures which lists down the operations AppArmor prevented. You will need to note the associated profile name and create a symlink through it to “etc/apparmor.d/disable” to disable that profile. For example, a practical profile name could be something like mysqld. After you manage to disable this profile successfully, you need to reload it. The following command examples explain this paragraph better.

ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/
sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.mysqld

AppArmor documentation offers in-depth information on Policy Layout. After you master disabling a profile, relaunching it will require the execution of the following commands.

sudo service docker restart
docker system prune --all --volumes

Docker will resume its normal operations after a successful system restart.

Accessing containers

One prone way of accessing a container is through Bash. Execute a command similar to the following while referencing the container’s name.

docker exec -it mariadbfosslintest bash

Afterward, we can comfortably resume the use of normal Linux OS commands like “ls” and “cd”. Also, we will be executing such commands with root privileges. For example, there might be some operations that require the use of a file editor. To install one, you will simply run the following command sequences.

apt update
apt install vim

The installation of some packages might require their association with a repository. Not all images come with a default repository configuration. You might be required to add them manually. Executing the commands SHUTDOWN and/or mysqladmin shutdown immediately stops the container. This immediate deactivation of the container automatically returns us to the base system.

Making a MariaDB connection from outside a container

On a local host environment, making a connection to the MariaDB server requires that the client first bypasses networking. Next, the client will use a socket file to connect to the server through the local filesystem. This connection instance is not applicable in an environment where MariaDB is hosted within a container. Reason? The host and the server’s filesystem are isolated.

You will face a connection error while attempting to make such a client-to-container connection because the client can’t bridge inside the container and access the needed socket file. For this connection to be successful and error-free, the MariaDB server needs to be associated with TCP. The TCP connection rule applies to situations where the client and the server container are on the same machine environment.

The first step is to identify the IP address associated with the targeted container by implementing a command sequence similar to the following.

docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' mariadbfosslintest

Afterward, a MariaDB server connection is possible with the availed IP address as the missing link to complete the TCP connection.

Forcing a TCP connection

From the above description and command implementation, you will have enabled MariaDB’s network connections. Making an outside connection from the container to the server is now possible. Once you are on the host system, you need to accomplish two objectives. First, run or enable the client. Second, in the previous section, the command you used produced the container’s IP address.

You need to set the MariaDB server’s IP address to this container’s IP address by mocking a command similar to the following:

mysql -h 172.17.0.2 -u root -p

In most circumstances, the simplicity of the above network connection protocol will execute without any issues. The success of this connection might also depend on the configurations you have in place. At times, you might need to be specific with the configured server port or even force-implement a TCP mode. Consider the following command.

mysql -h 172.17.0.2 -P 3306 --protocol=TCP -u root -p

Clustered containers and replication versus port configuration

With TCP, it is possible for multiple MariaDB servers existing in isolated Docker containers to inter-connect or have a mutual connection with each other. This approach has its usefulness when replication or Galera cluster is under consideration.

When considering replication or cluster setup via Docker, each container should be associated with a unique port. The easiest way of achieving this objective is using different system ports to map the containers’ ports. This step is achievable during the initial steps required to create a container. It is also associated with the “docker run” command. On several occasions, you will need to implement the -p option on your commands.

A practical Galera nodes implementation example will follow a mapping sequence similar to the following command.

-p 4306:3306 -p 5567:5567 -p 5444:5444 -p 5568:5568

MariaDB installation on another image

Once you have successfully downloaded a Linux operating system distribution image, MariaDB can be installed on it. An easier option would be to use a regular operating system environment for the installation of MariaDB. This option has its unique hurdles because the first steps might require a user to exit the host environment.

Another drawback is that the availed image might not be an exact match for the image version we want to use. Such circumstances force us to rely on an operating system image for MariaDB installation.

Daemonizing the operating system

The initial launch of the system image is important. It should execute as a daemon. Ignoring this step as its consequences. For instance, given that the container somehow stops, you will lose MariaDB and its associated databases.

The use of an infinitely executing command is the first step to demonizing an image. The following command example continuously pings the special address 8.8.8.8. The command is used in the creation of Debian Jessie’s daemon.

docker run --name debian -p 3306:3306 -d debian /bin/sh -c "while true; do ping 8.8.8.8; done"

Installing MariaDB

At this stage, all you need is access to the system shell to issue the relevant installation commands. The first step will be to issue commands needed for repositories update. Without updated repositories, you will be dealing with packages unavailability errors. Packages update is also recommended for version compatibility with the image.

Also, as mentioned earlier, installing a text editor, you are comfortable with is highly recommended. For instance, various circumstances might require you to edit various configuration files. The following command example is associated with initiating an interactive Bash session within an active container. What follows is the packages update command and the installation of the vim text editor.

docker exec -ti debian bash
apt-get -y update
apt-get -y upgrade
apt-get -y install vim

Final note

Docker makes MariaDB an impressive standalone server. It is a simple environment, unlike the complexities associated with Galera Cluster and replication environments. Whenever the need to share a development environment arises, always consider the usefulness of the Docker tool. It keeps all users under a single roof with the flexibility of cloning or recreating an already configured environment.

More Docker functionalities include mapping ports, using private networks, and sharing volumes.