Mariadb-docker: Please add environment variables for setting the collation and character set of the default database

Created on 18 May 2017  路  10Comments  路  Source: MariaDB/mariadb-docker

Gitlab CI cannot pass command line arguments to containers: https://gitlab.com/gitlab-org/gitlab-ce/issues/22787
The only way to configure service containers is to use environment variables: https://docs.gitlab.com/ce/ci/services/mysql.html#use-mysql-with-the-docker-executor

See also https://github.com/docker-library/mysql/issues/297

Most helpful comment

Instead of hundreds of people setting up their own registry and automated builds wouldn't it be easier for everyone to just add the two ENV variables (which logically add to the one used to create the initial DB imho)..? It's not that we would add completely unrelated parameters here...

$0.02

All 10 comments

you don't need environment variables for that, just set default character set and collation in my.cnf

e.g:

character_set_database = utf8mb4
collation_database = utf8mb4_unicode_ci

Hope that helps!

I don't think I can mount a volume with a custom my.cnf either.

hm, you should be able to do it because the doc says:

GitLab Runner 0.5.0 and up passes all YAML-defined variables to the created service containers.

So basically you can pass anything that docker would accept.
You could also pass directly a command argument. e.g. command: mysqld --character_set_database=utf8mb4

It only passes environment variables. It doesn't support changing the command, that's what https://gitlab.com/gitlab-org/gitlab-ce/issues/22787 is about

Strong -1 on adding more environment variables -- it's trivial for most users to add flags to the command via docker run or docker-compose.yml.

Until GitLab CI Runner supports command changing for services, the GitLab CI Runner use case is a simple two-line Dockerfile:

FROM mariadb:10.0
CMD ["--character-set-server=utf8mb4", "--collation-server=utf8mb4_unicode_ci"]
# or a `COPY` or `RUN` to create a cnf file in `/etc/mysql/conf.d/`

Combine that with automated builds (https://docs.docker.com/docker-hub/builds/) and repository links (https://docs.docker.com/docker-hub/builds/#repository-links) and it's reasonably easy to have an up-to-date image built FROM this one with the config adjusted.

Related issues: https://github.com/docker-library/percona/pull/43, https://github.com/docker-library/docs/pull/502, and https://github.com/docker-library/mariadb/pull/41.

Instead of hundreds of people setting up their own registry and automated builds wouldn't it be easier for everyone to just add the two ENV variables (which logically add to the one used to create the initial DB imho)..? It's not that we would add completely unrelated parameters here...

$0.02

I completely agree with @gr8bit. I'm not going to set up my and maintain my own forked version of mariadb/mysql.

I can work around this with a (conditional) alter table, but that's also a bit inconvenient, because it's in a template app that can also be used with postgres.

You don't need to setup nor fork mariadb or mysql, neither does the official mariadb image needs to adapt itself to every use case out there.
As @yosifkit suggested it's just the matter to build an image from the official one. Customizing an image is a best practice among docker deployments, look at the php image, for example.
Use that Dockerfile to build your custom image with Gitlab CI and you're done.

By fork, I meant create my own version of the mariadb and mysql image with that two-line Dockerfile. And no, I'm not done. What if I need multiple versions? What if a new version comes out? I would have to educate everyone in my company that they now have to use my fork, and if they need a different version, they'll need to create their own fork or ask me to create a new version.
Or I have to set up a complex build system that can automatically build all the versions.
I'm not going to do that. It's much simpler to add an alter table to my ci script, but I would've preferred to not have to use a workaround like that.

The php image is an entirely different thing because you have to copy your code into it. It's meant to be used as a basis for your application image.
There's no reason to create a custom image out of these two, and I wouldn't need to do it if I could mount my own my.cnf or pass command line arguments to the image or use environment variables to set the collation of the default database or if mysql wasn't stuck in the 20th century with its default latin1 character set.

I'm a very strong -1 on making this change as well, for a few reasons. Firstly, it is already trivial to set these options in both docker and docker-compose. Not only can you pass it in via command line args, but you can even add it to configuration via a volume, or make your own Docker image, as @yosifkit suggests.

While I understand that for Gitlab CI these solutions might not be wholly adequate, that seems like a failing on the part of Gitlab CI rather than the image. It's excessive and unnecessary to have to have an environment variable for every single possible my.conf option available, and it gets even more excessive considering all the possible configuration for every other image that people might try to use as well.

I'm closing this issue, on the basis that as maintainers, we're not interested in supporting or maintaining patches based on issues that arise specifically from using the image with Gitlab CI. If either @tianon or @yosifkit disagree, they can go ahead and reopen.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

foxx picture foxx  路  4Comments

andrerom picture andrerom  路  5Comments

danquah picture danquah  路  6Comments

J0WI picture J0WI  路  5Comments

csandanov picture csandanov  路  6Comments