Skip to content

Conversation

@ntjess
Copy link

@ntjess ntjess commented Dec 15, 2024

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 main docker-compose.yml with slight customizations. The biggest breaking change is the lack of specific .build.yml and .gpu.yml files, since this is now achieved with docker-compose build and docker-compose build --profile ia-gpu (or ia-cpu).

TODO:

  • Sort out which dev settings are necessary to distinguish dev vs prod modes (e.g. volume mounts and environment variables)
  • Update documentation

@SixK do you have insight on the above todos? I'd love your feedback especially on getting the (untested) ia-cpu portion vs. gpu properly split

@SixK
Copy link
Owner

SixK commented Dec 16, 2024

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
@SixK SixK mentioned this pull request Dec 18, 2024
@SixK
Copy link
Owner

SixK commented Dec 19, 2024

My first reflection, is that modifications make starting containers more complex.
If keeping your docker-compose files as is, I may need to add scripts.
I ran "docker compose up" and it seem's ok.

I have to test further, specially for ai containers.

@ntjess
Copy link
Author

ntjess commented Dec 19, 2024

Merging multiple compose files via command line is the docker-recommended approach, so I would be a fan of scripts 👍

starting containers more complex

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, dev vs prod vite builds, etc. With the current approach, every combination of settings would need a new container yml.

@SixK
Copy link
Owner

SixK commented Dec 21, 2024

if running this command:
docker compose --profile ia-gpu up

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 ?

  frontend:
    extends:
      file: docker-compose-helpers.yml
      service: service-common
    container_name: annotator_client
    build:
      context: .
      dockerfile: ./client/Dockerfile
    ports:
      - "8080:8080"
    volumes:
      - "./client:/workspace/client"
    depends_on:
      - webserver

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants