Multiple applications and shared containers with docker-compose

Question

I'm trying to understand what would be the best approach here.

One server, multiple applications, some containers uses same image.

Example #1:

two docker-compose.yml files for each application

services:
  db:
    image: mariadb:latest
    ...

  app:
    image: app/one
    depends_on:
      - db
    ...

services:
  db:
    image: mariadb:latest
    ...

  app:
    image: app/two
    depends_on:
      - db
    ...

Example #2:

combine everything in one docker-compose.yml

services:
  db:
    image: mariadb:latest
    ...

  app1:
    image: app/one
    depends_on:
      - db
    ...

  app2:
    image: app/two
    depends_on:
      - db
    ...

Is there a common practice?

Answer 1

Two things that are common practice:

1. Check in a docker-compose.yml file with the application's source code (frequently at the root directory of the repository next to a Dockerfile)

2. Do not share databases between applications (containers make it very easy to start a second one)

Both of these things would suggest two separate docker-compose.yml files.

A single docker-compose.yml file could make sense in situations where you have multiple services that are cooperating so it doesn't make sense to launch one without the other. (You have a REST API service, but it has an associated Nginx frontend and a specialized caching service that all go together, for example.) Calling from one Docker Compose setup to another is slightly tricky and at small scale it can make sense to just put tightly connected things together.

At larger scale, it could also make sense to have a separate repository of just deployment specifications; this makes a little more sense with cluster managers like Kubernetes, and even then it's a style choice whether to have one repository with just deployment data, or to keep the deployment setup with the services.

Answer 2

It depends on how related are app1 and app2 from each other.

From my point of view, an app is a set of tightly related things: one or more services, a database and a frontend. In that case, having them all together in the same docker compose is the way to do it.

In your case, if your app1 must use the same databases or tables as app2, then it is perfectly fine to have them in the same docker compose. In the other hand, if app1 and app2 uses different databases and do not interact with each other, then they are effectively separate and independent applications, so they should run on different docker compose configurations.