where should I put docker-compose.yml

Question

When I pull the images from docker hub. Sometimes, I would like to run the images in a multi-container way. So I choose to use docker-compose. For example, I would run the zookeeper in replicated mode. I will new a file named docker-compose.yml, and run docker-compose up and wait for it to initialize completely.

My question is what is proper directory I should put docker-compose.yml file into?

Bravar

Doesn't matter. A good approach could be to create a project directory in which you create a new directory for each docker-compose project. For example: project/app-mysql/and there you could save your docker-compose.yaml (which includes the setup of your app + mysql). That's how we use it. – Yelmene

@lvthillo, where should be your git repository directory in this case? In app-mysql/ (and one for each app-xxx) or just one git repo for all projects in project/? – Jilljillana

@Jilljillana The question is not fully clear for me, but I would keep my docker-compose.yml inside the root of my git repo, and create seperate repo's if possible. If it isn't possible I would use a git root with subfolders and put a docker-compose.yml in each subrepo – Yelmene

Answer 1

I'm asking myself the same question: Where to put my docker-compose.yml file?

I've decided to do it the following way:

• One Repo for the docker-compose.yml along with deployment scripts (Jenkins pipeline in my case).
• One Repo per micro service along with a Dockerfile and its build logic (built image is pushed to private docker registry).

Why?

• The docker-compose.yml describes a system (the composition of micro services) and how it is deployed.
• A micro services should be independent from the system infrastructure.
• There could be more than one system (different composition of the micro services) with a second docker-compose.yml (and Repo).

However, of course there are reasonable exceptions. Assume you're deploying a customized Database along with a management tool (e.g. customized mariadb and adminer), then most things may live in one repository.

Frieze

Also consider using git submodules. I've found myself having a "super project" with a docker-compose.yml for bringing up an entire dev environment, and then within a folder titled /services/ i have sub-modules for each service I run, and can keep versioning of them managed. In this way, the super project can have a branch of "Feature A" and point the correct submodules to whichever commit they need to successfully implement "Feature A". – Bedizen

Answer 2

I prefer to keep them all in one place instead. I usually put them in resources folder to keep them synchronized to my base code and also install scripts. So you can have different branches or folder for different needs or systems.

Why?

• docker-compose.yml files do not describe whole system and deployment plan of your system necessarily. They take part in this role by using dockerbuild files (because of describing base image and environment) you have in your main repository already.
• Separating deployment and infrastructure plan from docker-compose.yml logic by using environment variables and other related resources is a good practice to prevent maintaining large number of docker-compose.yml files for different environments.

Escuage