> > Dan already did part of what you propose:
> > https://github.com/danrue/lava-docker-compose
> > I guess we should move the work to some common place not to repeat all
> > the same steps
>
> Yes, it sounds like Olli and I are on the same path :)
>
> I didn't bother modifying the container though. I just mounted in my own copy of instance.conf. Adding environment variable support, as you have proposed, for common config properties would be better. This meant that postgresql is still running an empty database in my server container for the time being.

> By the way, I noticed you're using postgres 11, yet the lava-server container uses 9.6. It's probably fine? I have no idea - I tried to keep the version consistent with what's tested and supported. Also, in case you need it, there was a fix to the entrypoint to properly wait for postgres. Find the latest entrypoint at https://git.lavasoftware.org/lava/pkg/docker/blob/master/amd64/lava-server/entrypoint.sh

At least the data migration part went ok, so I'll go with a strong maybe. Web interface responded properly but I didn't add slaves yet, so haven't tested it fully. I also found that entrypoint.sh from the gitlab and yes, there was some timing issues when postgres didn't start fast enough and lava-server crashed. Rather than wait, there could be some sanity check for connection with some retry & timeout functionality.

> > > What do you think, should I still break it into smaller pieces? Pros on this would be that softwares wouldn’t die silently (started by using ‘&’ and docker could try to restart them), logs would be in their own logs windows’ (docker log CONTAINER) and containers themselves would be more configurable via environment variables.
>
> I agree in principle, but I'm not sure of the implications for each of the services. For the time being, I'm focusing on trying to use the containers as they are, and upstream improvements to make them easier to use.

I can try to separate all server side services and see if any major issues arise.