drevops/mariadb-drupal-data repository overview

⁠

⁠MariaDB data container for Drupal with database captured as Docker layers.

⁠How it works

Usually, MariaDB uses data directory specified as a Docker volume that is mounted onto host: this allows retaining data after container restarts.

The MariaDB image in this project uses custom location /usr/lib/db-data (not a Docker volume) to store expanded database files. These files then can be captured as a Docker layer and stored as an image to docker registry.

Image consumers download the image and start containers with instantaneously available data (no time-consuming database imports required).

Technically, majority of the functionality is relying on upstream uselagoon/mariadb-drupal⁠ Docker image. Entrypoint script⁠ had to be copied from upstream script⁠ and adjusted to support custom data directory.

⁠Use case

Drupal website with a large database.

1. CI process builds a website overnight.
2. CI process captures the latest database as a new Docker layer in the database image.
3. CI process tags and pushes image to the Docker registry.
4. Website developers pull the latest image from the registry and build site locally. OR Subsequent CI builds pull the latest image from the registry and build site.

When required, website developers restart docker stack locally with an already imported database, which saves a significant amount of time for database imports.

⁠Seeding image with your database

./seed-db.sh allows to easily create your own image with "seeded" database.

1. ./seed-db.sh path/to/db.sql myorg/myimage:latest
2. docker push myorg/myimage:latest

In some cases, shell may report platform incorrectly. Run with forced platform:

DOCKER_DEFAULT_PLATFORM=linux/amd64 ./seed-db.sh path/to/db.sql myorg/myimage:latest

⁠Maintenance

⁠Running tests

tests/bats/node_modules/.bin/bats tests/bats/data.bats --tap
# or
DOCKER_DEFAULT_PLATFORM=linux/amd64 tests/bats/node_modules/.bin/bats --tap tests/bats/data.bats

⁠Publishing

This image is built and pushed automatically to DockerHub:

1. For all commits to main branch as canary tag.
2. For releases as :<version> and latest tag.
3. For feature/my-branch branches as feature-my-branch tag.

Versions are following versions of the upstream image⁠ to ease maintenance.