Reputation: 1408
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?
Upvotes: 22
Views: 4252
Reputation: 36793
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/
Upvotes: 6