search

ucphhpc / docker-migrid

Containerized MiG
GNU General Public License v2.0
3 stars 7 forks source link

Reduce variable maps in docker-compose files #31

Closed benibr closed 10 months ago

benibr commented 10 months ago

This PR removes all the variable mappings in the docker compose files and replaces them by a dynamic generator.

This results in over 1500 removed lines and makes the maintenance of this repository way easier.

jonasbardino commented 10 months ago

Sounds excellent! I hope to find the time to check it out next week.

benibr commented 10 months ago

I think we could also add the extend to the other service containers so that one is able to build and run them without the main migrid container

jonasbardino commented 10 months ago

Manually merged the recent conflicts in development_gdp.

jonasbardino commented 10 months ago

I've done some more polishing on the Makefile to handle a few glitches. Mainly a small fix for the handling of ADMIN_LIST and any other variables that can contain equals signs ('=') in the actual variable value. Plus restructured the init target a bit and added a dependency on the corresponding new initcomposevars sub-target, which now handles the creation of the docker-compose_shared.yml, to the targets implicitly needing that because of their DOCKER_COMPOSE calls.

Similarly did a bit of clean up of leftover explicit vars in the production example while synchronizing to our own docker-migrid-ucphhpc examples.

Tested to generally work nicely on centos7 both in gdp and non-gdp mode with our dev erda envs and on rocky8 in non-gdp mode with our bench erda envs. This of course includes the automatic support for recently added variables like the requested GDP_PATH_SCRAMBLE as soon as they are included in the active Dockerfile, so that they can readily be used in the .env file. That will surely simplify things and save us all of some tedious docker-compose.yml work in the future.

Thanks again @benibr for your efforts :-)

jonasbardino commented 9 months ago

I think we could also add the extend to the other service containers so that one is able to build and run them without the main migrid container

I don't have any principal reservations there so we can do that if it helps and doesn't break stuff. Perhaps it reopens the discussion of individual container images, though? Right now we really use a single fat image with everything in and just only launch what is required in each migrid* container, which obviously comes both with advantages and disadvantages.