I have a development database which I would like to commit inside a docker image, to be pushed to a private repository and used in local development and CI builds.
The database is saved as a SQL backup, and I can successfully restore it to a MariaDB container by mapping the backup file into the official image's /docker-entrypoint-initdb.d/
directory, which will execute this backup file the first time a container is run. When this happens, the database is restored by MariaDB into datafiles located in /var/lib/mysql
inside the container.
Theoretically, I could then stop the container, commit it to a new image, push it, and I'm done. However, MariaDB's Dockerfile declares VOLUME /var/lib/mysql
, which means that as soon as the container is created, this path will be mapped to an automatic named volume on the host, even if --volume
is not used to explicitly mount at that path. Since the path is mounted from the host, the restored database will not be captured by docker commit
. It does not appear possible to override this automatic volume mount.
One workaround is to docker create
a new container without running it, docker cp
my database backup into /docker-entrypoint-initdb.d/
, and then docker commit
this to a new image. This image can be pushed since it contains the backup data, and when it is first run, MariaDB will restore it into the database. However, you have to wait for the restore to complete whenever the container is created, instead of the image shipping with the database already restored.
Another workaround is to fork the MariaDB Dockerfile to remove the VOLUME
directive, or create my own by installing MariaDB myself on a base image.
A third option might be to create my own Dockerfile to build from mariadb
as a base image, and attempt to do the restore as part of that build process, but I haven't yet fully investigated this.
What is the most effective approach to accomplish this objective?