20

Given the following structure;

├── api/                - A PHP application, to have its own repository
├── docker/             - Docker configuration for shared containers (MySQL, Nginx)
├── docker-compose.yml  - Defines all of the services
└── web-client/         - A standalone Angular application, to have its own repository

Currently the entire application is in one repository but I am looking to split into separate repositories. Development has not started so there is no issue with maintaining any history etc.

Firstly, is defining all of the services in a root level docker-compose file the best way to go about this, or should the api and web-client be more isolated with their own docker-compose, thus managed completely separately? If separate, is it possible to still have one "depends_on" another?

Secondly, what is the best way to manage repositories for this? The root level code (docker-compose.yml and docker/) should exist in one repository, but that also depends on the other two repositories being present, presumably as children. I looked into git submodules for this but it seems as though the parent repository has to be tied to specific commits in the children, which may make working on multiple parallel features difficult?

James Crinkley
  • 1,398
  • 1
  • 13
  • 33
  • 2
    Seriously, heavy downvotes? – James Crinkley Apr 19 '18 at 10:28
  • So many -ve votes –  Apr 19 '18 at 10:33
  • 2
    you are trying to solve good problem. I can't understand why people downvote questions like this. anyway, i can suggest you 2 different solutions. 1- you can ignore web-client and api directories in docker repository. and clone other repositories respectively. 2- didn't test it but you can symlink api and web-client directories from their respective directories. (ignoring them again) – Yarimadam Apr 19 '18 at 11:03
  • 1
    This is indeed a good question. Just imagine those votes without the `-` sign. – Robert Apr 19 '18 at 11:49

1 Answers1

6

My recommendation is the following:

├── api/
       |___ .git
       |___ Dockerfile
       |___ ... api src ...
├── docker/             - Docker configuration for shared containers (MySQL, Nginx)
├── docker-compose.yml  - Defines all of the services
└── web-client/
        |______ .git
        |______ Dockerfile
        |______ ... web-client src ...

Each application should encapsulate its source code plus its Dockerfile, both living in the same git repo.

Then the docker-compose.yml file will make use of them, something like:

(...)
services:
  api:
    build: ./api/
(...)
  web-client:
    build: ./web-client/

That's the way to go that I usually see.

If you would like to use multiple docker-compose files anyway, you may want to take a look at this: https://docs.docker.com/compose/extends/

Robert
  • 33,429
  • 8
  • 90
  • 94
  • Thanks for your time and help - I went for an approach based on this, introducing a third directory at the root containing the `docker-compose.yml` and the shared `docker/` directory, essentially ending up with 3 repositories that a developer would just clone into one to work. – James Crinkley Apr 19 '18 at 22:03
  • 2
    Old question by now, but what's in your `docker/` directory? – redOctober13 Mar 25 '19 at 18:48
  • redOctober Configurations for the containers setup with docker-compose.yml. It could for instance be Docker secrets that define passwords for the database. These passwords should not be pushed into the git repo and you do not want them in the docker-compose.yml as these passwords would be different from test to production environment – broch Dec 01 '22 at 18:57