This is the Git repository of the Docker Library "Official Image" for mariadb.
Maintained by: the MariaDB Foundation and Community
See the Docker Hub page for the full README on how to use this container image.
One useful way to do this is to create an initfile.sql file that contains (to cover all bases) something like the following:
CREATE USER IF NOT EXISTS root@localhost IDENTIFIED BY 'thisismyrootpassword';
SET PASSWORD FOR root@localhost = PASSWORD('thisismyrootpassword');
GRANT ALL ON *.* TO root@localhost WITH GRANT OPTION;
CREATE USER IF NOT EXISTS root@'%' IDENTIFIED BY 'thisismyrootpassword';
SET PASSWORD FOR root@'%' = PASSWORD('thisismyrootpassword');
GRANT ALL ON *.* TO root@'%' WITH GRANT OPTION;
CREATE USER IF NOT EXISTS myuser@'%' IDENTIFIED BY 'thisismyuserpassword';
SET PASSWORD FOR myuser@'%' = PASSWORD('thisismyuserpassword');
CREATE DATABASE IF NOT EXISTS databasename;
GRANT ALL ON databasename.* TO myuser@'%';For more information about the full official images change life-cycle, see the "An image's source changed in Git, now what?" FAQ entry.
For outstanding mariadb image Pull Requests (PRs), check PRs with the "library/mariadb" label on the official-images repository. For the current "source of truth" for mariadb, see the library/mariadb file in the official-images repository.
In order to provide our users with the most stable image possible, we will only create container images from packages from MariaDB directly and not distribution packages. This is partially from the repeatability criteria of Docker Library, but its mainly due to the stability of the image is dependent on it being tested using CI prior to release. As MariaDB doesn't test in an Alpine Linux environment, or against musl libc on which Alpine is based, and as such we cannot in good conscious deliver an untested implementation. This may change in the future.
There have unexpected behaviours and outright bugs reported against MariaDB for musl based interface difference against architectures that MariaDB simply isn't tested. MariaDB server developers find hard easy to test against those environments to diagnose/fix bugs and their fixes. While Alpine Linux is a beautiful Linux distribution, the level of MariaDB testing from this, or any distribution, falls short of what we want to provide our users.
Musl's key principles favors simplicity and size over performance and there are aspects of MariaDB that are highly dependent on the performance of the libc functions, particularly the ones highly optimized in glibc by architecture developers for optimal performance. A future consideration of musl for container images will require benchmarking to ensure that we are offering our users a non-degraded performance.
LinuxServer.io offers an Alpine Linux based MariaDB if you still want this, however it is less supported by MariaDB server developers or not supported in this community.
Yes, by probably less than 100M. MariaDB is a database where a basic data directory exceeds this difference. We aren't going to sacrifice performance and reliability to save a comparatively small amount of storage.
To support MariaDB on a new architecture it needs to be tested in CI against this architecture before release. Please search MariaDB JIRA and create a Task requesting the architecture or vote/watch an existing issue. The votes/watchers numbers on the issues are used to prioritize work. If accepted due to popular demand, the CI against this architecture will result in packages that can used in the container manifest in the same way as the current supported architectures.
But Alpine/Debian/Disto X support this already? Sorry, we aren't going to compromise the quality of this container by providing less tested images on any architecture.
If you need help with MariaDB on Docker, the Docker and MariaDB section of the MariaDB Knowledge Base contains lots of helpful info. The Knowledge Base also has a page where you can Ask a Question. Also see the Getting Help with MariaDB article.
On StackExchange, questions tagged with 'mariadb' and 'docker' on the Database Administrators (DBA) StackExchange can be found here.
If you run into any bugs or have ideas on new features you can file bug reports and feature requests on the MariaDB JIRA. File them under the "MDEV" project and "Docker" component to make sure it goes to the correct people.
Contributing changes involves creating a pull request.
If you are considering submitting a feature or pull request, be sure to check out the Review Guidelines for some helpful information.
The development of the container image here aims to provide complete backwards compatibility for existing users. If there is a case where the container previously started and behaved in a certain way, after your change, it should, under the same circumstances, behave in the same way.
Please update the tests to verify the behavor of your bug fix or feature request in the .test directory by extending run.sh and including supporting files. Tests here run on GitHub Actions and also in Buildbot (Soon) so please avoid adding uncommon dependencies to running a test if possible. If additional dependencies are needed, please check for their existence and skip the test if this isn't available.
Changes to the Dockerfile should be done at the top level Docker.template and entrypoint changes in entrypoint.sh. Run update.sh to propagate these changes to the major version (10.X) folders underneath.
Please write code in a similar style to what is already there. Use tab indents on the entrypoint script.
_xxx functions are intending for internal use and may be changed in the future. If you write a shell function that might be useful to a /docker-entrypoint-initdb.d script to use, prefix it with docker_ and it will be consider a stable script interface.
If you need a change to occur in a specific major version only, change the update.sh script to ensure that its Dockerfile / docker-entrypoint.sh is generates version specific changes.
To build you can use docker build, buildah bud, podman build or any other container tool that understands Dockerfiles. The only argument needed is the build directory (10.X).
Run:
.test/run {container hash}
This will run though all current tests and the new tests you have created. The key aspect is that the script should error returning a non-zero exit code if the test fails.
Commit messages should describe why this change is occurring, what problem is it solving, and if the solution isn't immediately obvious, some rational as to why it was implemented in its current form.
If you are making multiple independent changes please create separate pull requests per change.
If the changes are a number of distinct steps a commit per logical progression would be appreciated.
It is preferred if you commit the changes to the major version directories generated by update.sh in a separate commit. This way if you need to rebase on the latest version this commit can be amended, and the code changes are easy to read and review.
Bug fixes are most welcome and should include a full description on the problem being fixed in the commit message.
Before investing too much time in a feature request, please discuss its use on a JIRA issue, a github issue, or with someone on Zulip (create a New Topic).
After a feature request is written please help get it used by improving the documentation to detail how to use the newly added features.
The full image description on Docker Hub is generated/maintained over in the docker-library/docs repository, specifically in the mariadb directory.
To change the documentation, please contribute a pull request or issue against the Docker Library docs repository.
| Docker Library Official Images CI Status (released changes) |
|---|
 |
 |
 |
 |