Update flow description for docker-compose based apps?

Apps & App Center App Development
#1

Hi,

I’m making progress with my first docker-compose based app for the appcenter and now want to look into applying settings. For normal container based installs there is https://docs.software-univention.de/app-provider.html#installation-scripts:app-flow:install does the same flow apply for docker-compose (i.e. just replace docker with docker-compose)?

I want to use variables in my compose file for settings and already have a working snippet to update my settings from configure_host.

What I am currently wondering about: does UCS take care of doing a docker-compose up -d when settings have changed or do I need to do that in configure_host.

PS: is it normal that the docker-compose files are not cleaned up after app removal?

edit: so far none the compose based apps have docker-compose in their configure_hosts scripts, so I am doing some tests without this explicit reload as well.

#2

Hello @fbartels

so what you are looking for is a way to throw away the current containers and restart them with the new settings?

We have recently included a command called reinitialize. Please see https://forge.univention.org/bugzilla/show_bug.cgi?id=50057#c1 on how it works. In your configure_host you could write for example:

if [ "$1" = "settings" ]; then
  univention-app reinitialize $myapp
fi

Best regards,
Nico

#3

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.

#4

Hello @fbartels

the reinitialize command does not execute a pull. It’s intended to just destroy the present containers and create new ones.

Best regards,
Nico

#5

Yes, it may not pull (I thought I’ve seen it when writing my initial response, but I did not recheck this meanwhile), but still a reinitialize is a bit heavy for my use as it recreates all containers in the compose file, while a docker-compose up -d in my above example would only recreate containers which configuration has changed.

Mastodon