MariaDB / mariadb-docker

Docker Official Image packaging for MariaDB
https://mariadb.org
GNU General Public License v2.0
770 stars 438 forks source link

customizing configuration of a derived image #329

Closed adixon closed 3 years ago

adixon commented 3 years ago

Pre 10.3, I was able to use this image as a starting point for a customized image that provided different defaults in /etc/mysql/conf.d by simply copying in a little custom.cfg file with the changes into that directory in my image.

That mechanism no longer works (the custom file disappears, perhaps as part of the image start up?), and the documentation only provides the option for customizing your configuration at run time via a volume mount, which is not the same - I want the image itself to have these customizations.

Any one with hints about how to accomplish this?

Here's how it's working up to 10.2: https://github.com/blackflysolutions/mariadb

adixon commented 3 years ago

FWIW

  1. adding parameters to the CMD in the Dockerfile does NOT work. The entrypoint script seems to be the issue.
  2. adding "command: mysql --parameter=whatever" in my docker-compose file does work (but isn't very elegant and might not work for all configuration).
wglambert commented 3 years ago

I'm not able to reproduce

FROM mariadb
COPY vsql.cnf /etc/mysql/conf.d

$ cat vsql.cnf 
# Overrides to mysql
[mysqldump]
max_allowed_packet = 1G
[client]
default-character-set = utf8
[mysqld]
log-warnings
collation-server                        = utf8_unicode_ci
init_connect                            = "SET collation_connection = utf8_general_ci"
character-set-server                    = utf8
character_set_filesystem                = utf8
skip-character-set-client-handshake
skip-name-resolve
back_log = 100
max_allowed_packet = 16M
innodb_file_per_table                   = 1
innodb_file_format                      = barracuda
innodb_flush_method                     = O_DIRECT
innodb_flush_log_at_trx_commit          = 2
long_query_time = 10
# skip-grant-tables

$ docker build . -t mariadb:test
Sending build context to Docker daemon   46.8MB
Step 1/2 : FROM mariadb
 ---> 4e7e0dfceed8
Step 2/2 : COPY vsql.cnf /etc/mysql/conf.d
 ---> 233ef6113334
Successfully built 233ef6113334
Successfully tagged mariadb:test

$ docker run -d --rm --name mariadb -e MYSQL_ROOT_PASSWORD=pass mariadb:test
65f66185525cb950e853c488f3715c9806a78467d5a61a116fb84341644523ca

$ docker exec -it mariadb bash

root@65f66185525c:/# ls -lh /etc/mysql/conf.d/
total 8.0K
-rw-r--r-- 1 root root  43 Oct  7 22:20 docker.cnf
-rw-r--r-- 1 root root 682 Oct 13 16:12 vsql.cnf

root@65f66185525c:/# mysql -uroot -ppass
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 3
Server version: 10.5.6-MariaDB-1:10.5.6+maria~focal mariadb.org binary distribution

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> SHOW VARIABLES LIKE 'max_allowed_packet';
+--------------------+----------+
| Variable_name      | Value    |
+--------------------+----------+
| max_allowed_packet | 16777216 |
+--------------------+----------+
1 row in set (0.001 sec)

MariaDB [(none)]> SHOW VARIABLES LIKE 'back_log';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| back_log      | 100   |
+---------------+-------+
1 row in set (0.001 sec)

MariaDB [(none)]> SHOW VARIABLES LIKE 'init_connect';
+---------------+--------------------------------------------+
| Variable_name | Value                                      |
+---------------+--------------------------------------------+
| init_connect  | SET collation_connection = utf8_general_ci |
+---------------+--------------------------------------------+
1 row in set (0.002 sec)
adixon commented 3 years ago

Thank you, you're correct.

After reproducing your experience, it occurred to me to compare the two running containers (the one created by your method above, and the one that wasn't behaving as expected) by doing a docker inspect and then using diff. That showed me that the container that wasn't working as expected was because it wasn't using the image I'd build locally, it was using the one from docker hub, because I'd foolishly not used a different tag.