Hi @gulden,
Yes and no.
A full reinitialisation is going a bit too far for my case (since this then also seems to pull new containers) and therefore takes some moments to complete. What I am looking to do is exploit normal docker-compose behaviour.
Let me give you an example.
In you docker-compose.yml you can work with variables. so that you for example have something like the following:
[..]
db:
image: mariadb:10.3.10-bionic
restart: unless-stopped
volumes:
- mysql/:/var/lib/mysql
environment:
- MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}
- MYSQL_USER=${MYSQL_USER}
- MYSQL_PASSWORD=${MYSQL_PASSWORD}
- MYSQL_DATABASE=${MYSQL_DATABASE}
[..]
So instead of putting the value for MYSQL_USER into the compose file itself I am specifying storing them in a file called .env. When you call docker-compose from the directory this .env file is stored it will read out the file and use them for the actual run of the compose file.
The nice thing is that if I now need to change setting, I am just updating my .env and call docker-compose up -d again. This will check where the changed config has been used (and which containers depend on containers with changed values) and only “recreate” those.
That is usually a quick transaction.
But I guess I could just reuse your snippet and instead of calling reinitialize, I’d call docker-compose directly. This would then prevent the command running already during installation of the app.