Upgrade docker-composer file format version

[lpalgarvio]

We are using at the moment the docker-compose file format version 2.0.

Numerous releases have been made, with new additions such as:

• Version 2.0 (Docker Engine version 1.10.0+, Compose 1.6.0+)
  • format rewrite. already implemented
• Version 2.1 (Docker Engine version 1.12.0+, Compose 1.9.0+)
  • labels for volumes and networks
  • name for volumes
  • healthcheck
  • sysctls
• Version 2.2 (Docker Engine version 1.13.0+, Compose 1.13.0+)
  • init
• Version 2.3 (Docker Engine version 17.06.0+, Compose 1.16.0+)
  • start_period for healthchecks
  • “Long syntax” for volumes
• Version 3 to 3.2
  • skipped
• Version 3.3 (Docker Engine version 17.06.0+, Compose 1.16.0+)
  • build labels
• Version 3.4 (Docker Engine version 17.09.0+)
  • start_period for healthchecks
  • name for volumes
• Version 3.5 (Docker Engine version 17.12.0+)
  • name for networks, secrets and configs

Each version has to be compared with docker/libcompose supported versions, a library which is used in many upstream projects, like rancher. If versions are found not to be compatible yet, the new feature additions have to weighted agains't loosing upstream support in contrib projects.

Validate project READMEs agains't the chosen docker-compose file format version.

[lpalgarvio]

docker-compose is supported up to version 2.0 on docker/libcompose. newer versions are not supported yet:

• https://github.com/docker/libcompose/issues/421
• https://github.com/docker/libcompose/issues/441

Rancher has same limitations as it uses libcompose:

• https://github.com/rancher/rancher/issues/10158
• https://github.com/rancher/rancher/issues/10290

[lpalgarvio]

Important features in the short term:

• none

Important in the long term:

• labels for volumes and networks (Version 2.1): this would be useful, but not required. volumes and networks are at the moment properly named, and are easy to find for this reason.
• “Long syntax” for volumes (Version 2.3): can allow for expanding the usage and way of usage of volumes.
• init (Version 2.2): supported, simple init would be a nice to have, but can already use supervisord, systemd or no init via CMD.
• sysctls (Version 2.1): this could eventually be a requirement, but not required at the moment.

Nice to have:

• build labels (Version 3.3): having labels set on build is important, however it does not fix the hidden ommit on docker hub/cloud, which does not supports and ignores docker-compose.yml files. Thus dockerfiles still need to have labels.

Not required in current form / support:

• healthcheck (Version 2.1): healthchecks might not be supported on Rancher eitheir way, even if the docker-compose format support gets upgraded on libcompose.
• start_period for healthchecks (Version 2.3/3.4): healthchecks might not be supported on Rancher eitheir way, even if the docker-compose format support gets upgraded on libcompose.
• name for volumes (Version 2.1): may not be necessary since we can set the names with other methods, like using COMPOSER_PROJECT_NAME.
• name for volumes (Version 3.4): may not be necessary since we can set the names with other methods, like using COMPOSER_PROJECT_NAME.
• name for networks, secrets and configs (Version 3.5): may not be necessary since we can set the names with other methods, like using COMPOSER_PROJECT_NAME.

Notes:

• Docker Swarm orchestration is not well supported outside of the docker inc ecosystem.
• Kubernetes orchestration has become the defacto solution.
• Volumes are apparently supported on Rancher.
• Keeping the networks configuration might not be an issue for Rancher.
• Not using secrets nor configs since there are not supported on Rancher, Kubernetes and other tools/APIs.

https://github.com/docker/compose/issues/1597

[lpalgarvio]

Conclusion:

Upgrade to version 2.3 is recommended, which would add support for:

• labels for volumes and networks (Version 2.1)
• “Long syntax” for volumes (Version 2.3)
• init (Version 2.2)
• sysctls (Version 2.1)

However, none are really required at the moment and unfortunately would break compatibility with many contrib solutions, so marking as postponed.

[CpuID]

https://github.com/docker/libcompose/pull/507 gets you a good portion of the way to resolving this (at least parsing the version string in docker-compose.yml). It doesn't add the version specific features though.

[Leopere]

It really looks like libcompose is abandoned is there no chance there are any go programmers in here who can understand the spec and just keep it up to date it seems like a huge game breaker to not be cross compatible?