problem

Currently the clients download the docker composer yml once on installation, then we communicate changes to the yml via changelog - sometimes the clients apply the changes sometimes not. 

In the past we had a roughly complex system of docker overrides, converted now to a single docker compose file in the on premise installations.

We did provide manually a base docker compose file, and a prod file (containing some additional prod parameters) and finally a client override for local specific things like ports and volumes etc.

Also we have to stick to current version tags of the docker images (mariadb 12.0 for example - see TRANSLATE-5141)

solution

We should redo the step to have only one manually maintained docker compose file in on premise installations.

There fore we provide a public git repo containing our base prod ready docker-compose.yml

A prod override should not be necessary since the most changed parameters should be able to be configured by .env params. 

adopt the existing installer.sh

• ask for the license stuff - stop when not confirmed (currently as invalid text in the docker compose yml) - can be the same but must then be in a docker-compose.override.yml - generated by that installer.sh then
• ask for the parameters to be put in .env (language tool memories, termtagger instances)

visual review

Open is the question how we can integrate visual: 

• with a separate docker-compose.visual.yml, which we roll out in general and is embedded only by the setup.sh in the .env -
• or we find a way to integrate that in the main yml and disable the services somehow via .env or in the client override. 

roll out

That new way must be rolled out on the on premise installations we maintain - so check the current yml on premise, place the new general one, adopt the local modifications.

Best would be to reuse that general docker-compose.yml also for our tests etc as base.