Conversation
|
Thank's for the great work, I have to test and estimate pros and cons. |
Docker doesn't allow `include` to modify an included service. So instead, build as separately-composed file in the build/up process
|
My first reflection, is that modifications make starting containers more complex. I have to test further, specially for ai containers. |
|
Merging multiple compose files via command line is the docker-recommended approach, so I would be a fan of scripts 👍
I would advocate the cognitive complexity of starting containers is much lower this way. It becomes clear to users exactly what is changing between prod/dev modes. It also allows more mixtures of dev/prod settings such as independently enabling/disabling GPU, hot reloading, |
|
if running this command: I have prod frontend (annotator_webclient that embed backend and compiled frontend as static files) and dev frontend up. What about moving the following section from docker-compose.yml to docker-compose.dev.yml or play with a profile ? |
The original docker-compose instructions are rather hard to modify: there are large amounts of duplication, subtle differences between e.g. dev vs non-dev defaults, and few instructions on how to persist customizations across multiple build targets.
This PR leverages docker include, profile and extend to significantly reduce code duplication and make build processes more intuitive.
New logic consolidates all common configurations into
docker-compose-helpers.yml, whose individual services are included in the maindocker-compose.ymlwith slight customizations. The biggest breaking change is the lack of specific.build.ymland.gpu.ymlfiles, since this is now achieved withdocker-compose buildanddocker-compose build --profile ia-gpu(oria-cpu).TODO:
@SixK do you have insight on the above todos? I'd love your feedback especially on getting the (untested)
ia-cpuportion vs. gpu properly split