docker compose watch; entrypoint loads bootstrap sql only once

[cas-liszinski]

Latest docker/compose, latest mariadb image.

Standard build and run option works ok, but in docker compose watch mode image entrypoint executes query in /docker-entrypoint-initdb.d/bootstrap.sql only at first docker compose up run.

Can someone help or suggest?

[grooverdan]

I don't know what you mean by "standard build and run option works ok".

The entrypoint is only meant to bootstrap the /docker-entrypoint-initdb.d during the initialization of the database.

So as far as I"m concerned its working as expected.

What functionality are you after and for what purpose? Something like #515?

[cas-liszinski]

Thanks for reply. I need a hint, I am wrong somewhere. I use docker compose with watch mode - when bootstrap.sql file is changed, image is rebuilt. It is not a migrations problem. First run is ok ```sh docker compose up --watch --build ``` But any next change of `bootstrap.sql`, starting with second, - I've checked - invokes creation of container with new bootstrap script - but - I am really do not understand - entrypoint do not apply the bootstrap script. But entrypoint must to do, because I am not using volums for now.

…

On Mon, Dec 16, 2024, 08:58 Daniel Black ***@***.***> wrote: I don't know what you mean by "standard build and run option works ok". The entrypoint is only meant to bootstrap the /docker-entrypoint-initdb.d during the initialization of the database. So as far as I"m concerned its working as expected. What functionality are you after and for what purpose? Something like #515 <#515>? — Reply to this email directly, view it on GitHub <#625 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BLX2UAO23CEYSMSZUBG2RG32FZTXRAVCNFSM6AAAAABTUVLFA2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBUGY3DSNBTGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[grooverdan]

If the contents of the bootstrap file are idpotent perhaps using a configuration command: --init_file=/docker-entrypoint-initdb.d/bootstrap.sql.

[cas-liszinski]

Yes, it is idempotent And thanks for suggestion But, please, help me to understand How stateless operation of volumeless container creation can fail? New image, new container, where problem can be started?

…

On Mon, Dec 16, 2024, 09:27 Daniel Black ***@***.***> wrote: If the contents of the bootstrap file are idpotent perhaps using a configuration command: --init_file=/docker-entrypoint-initdb.d/bootstrap.sql <https://mariadb.com/kb/en/server-system-variables/#init_file>. — Reply to this email directly, view it on GitHub <#625 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BLX2UAID5FQIFKALN2SEYQT2FZXGTAVCNFSM6AAAAABTUVLFA2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBUG4YTCMZRHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[grooverdan]

Yes, it is idempotent And thanks for suggestion

But, please, help me to understand How stateless operation of volumeless container creation can fail? New image, new container, where problem can be started?

If its truly without persistent volumes, and those were empty upon the next initialization, then your bootstrap.sql would be always running. I what you have is a stateful operation, even if not intended. Compose makes volumes persist. There a option to purge them, but by default down/up doesn't clear them.

You aren't providing enough information for me to clearly follow what you are achieving/wanting to see/are actually seeing. More time preparing compose example with markdown formatted logs. Take your time, end of my working day, so if there's a single coherent thought/question/request here for my tomorrow I can answer this. If its vague I won't.

[cas-liszinski]

@grooverdan Please, look at ready demo.

https://github.com/cas-liszinski/mariadb-docker-demo

[grooverdan]

Compose creates are volume:

$ podman inspect mariadb-docker-demo-mariadb-1

          "Mounts": [
               {
                    "Type": "volume",
                    "Name": "73f8886cec25a29bf83dd42be01961e92dbe684fdfbeb27aecb917b9c32be028",
                    "Source": "/home/dan/.local/share/containers/storage/volumes/73f8886cec25a29bf83dd42be01961e92dbe684fdfbeb27aecb917b9c32be028/_data",
                    "Destination": "/var/lib/mysql",
                    "Driver": "local",
                    "Mode": "",
                    "Options": [
                         "nodev",
                         "exec",
                         "nosuid",
                         "rbind"
                    ],
                    "RW": true,
                    "Propagation": "rprivate"
               }
          ],

After modifying bootstrap.sql, I observed the docker-compose rebuild, but the container, still the same volume:

$ podman inspect mariadb-docker-demo-mariadb-1 | grep -A 15 "Mounts"
          "Mounts": [
               {
                    "Type": "volume",
                    "Name": "73f8886cec25a29bf83dd42be01961e92dbe684fdfbeb27aecb917b9c32be028",
                    "Source": "/home/dan/.local/share/containers/storage/volumes/73f8886cec25a29bf83dd42be01961e92dbe684fdfbeb27aecb917b9c32be028/_data",
                    "Destination": "/var/lib/mysql",
                    "Driver": "local",
                    "Mode": "",
                    "Options": [
                         "nosuid",
                         "nodev",
                         "rbind"
                    ],
                    "RW": true,
                    "Propagation": "rprivate"
               }

On the restart:

mariadb-1  | 2024-12-16 23:05:43+00:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:11.6.2+maria~ubu2404 started.
mariadb-1  | 2024-12-16 23:05:43+00:00 [Note] [Entrypoint]: MariaDB upgrade not required

It can only detect the "upgrade not required" if the datadirectory is there.

Per previous - /docker-entrypoint-initdb.d is only for initialization.

Using init-file as previously described will trigger idpotent changes, however the volume is still there:

diff --git a/docker-compose.yaml b/docker-compose.yaml
index 7c943ba..bc7f555 100644
--- a/docker-compose.yaml
+++ b/docker-compose.yaml
@@ -2,15 +2,14 @@ services:
   mariadb:
     build:
       context: .
      network: host
     restart: unless-stopped
     init: true
     network_mode: host
     environment:
       MARIADB_USER: demo
       MARIADB_PASSWORD: demo
       MARIADB_DATABASE: demo
       MARIADB_ROOT_PASSWORD: demo
+    command: --init_file=/docker-entrypoint-initdb.d/bootstrap.sql
     healthcheck:
       test: echo 'select version()' | bin/mariadb -h 127.0.0.1 -u$$MARIADB_USER -p$$MARIADB_PASSWORD
       # test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]

[cas-liszinski]

@grooverdan you are right.

But, why volume - i.e. image - not updated by docker compose, when I specify rebuild mode?
Have you idea where reasoning can be found?

New file, new image, new volume - where I am wrong?

Maybe, Dockerfile add instruction creates a "live" volume, and bootstrap.sql is bypassed to the same image - and image remains the same at watch mode rebuilds - something like docker buildkit optimization?

If I am right, how to omit the problem?

[grooverdan]

Its actually the first I've come across rebuild mode. I don't know. Suggest finding/asking docker-compose folks.

https://docs.docker.com/compose/how-tos/file-watch/#action docs define the exact behaviour.