Use Compose V2 `compose.yaml` and DRY it out

[almereyda]

Is your feature request related to a problem? Please describe.

Currently the docker-compose.yml manifests, which do not carry a version: tag and are as such Compose v2 manifests, can also be interpreted by deprecated docker-compose clients.

This in return can lead to subtle errors in the interpretation of the provided keys and values, where implementation details have changed between docker-compose/Compose v1 and docker compose/Compose v2.

Describe the solution you'd like

mv docker-compose.yaml compose.yaml

Describe alternatives you've considered

We remain backwards compatible and support multiple runtime engines at the same time.

Additional context

Actually we want to run the stack locally in Kubernetes, but we are just not there yet.

[almereyda]

If we agree on compose.yaml to reduce ambiguity and break interoperability with previous docker-compose versions, we can also use service profiles to identify components in the stack that belong together.

• https://docs.docker.com/compose/profiles/

Their example is quite telling about which use case is targeted with this feature:

docker compose run db-migrations

Which directly relates this conversation to #2

[almereyda]

Some nice patterns to use Docker Compose to its full extent can be found in:

• Share Compose configurations between files and projects extends is a beast
• Control startup and shutdown order in Compose Do we use service_completed_successfully for migration or init containers?
• Use Compose in production informative check list

These features could also help to structure the template better:

• Version and name top-level element
• Configs top-level element
• Secrets top-level element

We can also use some YAML syntax rules to deduplicate code, namely anchors and alias nodes

• https://yaml.org/spec/1.2.2/#anchors-and-aliases
• https://yaml.org/spec/1.2.2/#alias-nodes

as exemplified in i.e.

• https://github.com/hashintel/hash/blob/8f719ace4d3e1d5b32adb8891d49f775255a7568/apps/hash-external-services/docker-compose.yml#L76
• https://github.com/hashintel/hash/blob/8f719ace4d3e1d5b32adb8891d49f775255a7568/apps/hash-external-services/docker-compose.yml#L138

This is also where I learned about service_completed_successfully

• https://github.com/hashintel/hash/blob/8f719ace4d3e1d5b32adb8891d49f775255a7568/apps/hash-external-services/docker-compose.yml#L135

Similar to them, we could also agree on better task execution runner than bash, and specify more jobs in a package.json instead.

• https://github.com/hashintel/hash/blob/8f719ace4d3e1d5b32adb8891d49f775255a7568/package.json#L22-L24

Later we could consider more sophisticated task runners, like just et al.

In the new Compose, we can also use Docker Stack's deploy for specifying resources, if applicable (eventually good to identify memory leaks locally):

• https://docs.docker.com/compose/compose-file/deploy/#resources

[almereyda]

• https://github.com/EdyTheCow/docker-pterodactyl/blob/master/panel/compose/docker-compose.yml#2

is a nice example about how a x-common: block and configurations therein are being reused in services et al. It also shows how a single value can be reused.

• https://github.com/EdyTheCow/docker-pterodactyl/blob/master/panel/compose/docker-compose.yml#L69

[almereyda]

In addition to the previous YAML examples, here's a writeup (found via the veggiemonk/awesome-docker list of Docker resources and projects:

• Don’t Repeat Yourself with Anchors, Aliases and Extensions in Docker Compose Files | by King Chung Huang | Medium