Add support for "bundled" OCI distribution

[Silvanoc]

Description

The possibility of using an OCI registry for distribution of docker compose configurations could be extended to support what I'd call "bundled" compose artifacts.

What I mean is that it should support having a compose file and the required images in the same repository and "holding" them from the same OCI manifest.

Why? Because it would enable the distribution of "compose packages" that can make use of many of the registry and client functionalities already available for OCI artifacts. For example:

• clean-up processes in a registry would be blocked from removing container images referenced by a compose package
• export to a "compose archive" (similar to what docker export does) for archiving reasons
• availability checks using regctl manifest get + regctl blob head

[ndeloof]

Having a single OCI entry to link to both compose config and involved image was my initial intent for compose publish - inspired by https://github.com/docker-archive-public/docker.app

One challenge to address then is that all images must be on same registry (obviously) and same repository so a manifest list can refer to those images + the compose artifact. For this purpose compose will have to push all images to same registry

[Silvanoc]

One challenge to address then is that all images must be on same registry (obviously) and same repository so a manifest list can refer to those images + the compose artifact. For this purpose compose will have to push all images to same registry

That's true. And therefore it's probably not the main use-case. But for people who want to use docker compose to package and distribute applications it makes completely sense. In fact it's the best way to ensure availability. If your compose is referring to an image (no matter if it's by tag or by digest) that gets deleted, your application is broken. Most registries won't let you remove an image referenced by an image index.

[ndeloof]

The challenge then comes with multi-platform images: Compose will have to push all images involved in your application to the same published repository (this is a constraint for a manifest-lest to only have references inside the same repo). But this requires all supported platforms are available on client machine, which for most of us never happens: we only pull for local architecture.

[Silvanoc]

The challenge then comes with multi-platform images: Compose will have to push all images involved in your application to the same published repository (this is a constraint for a manifest-lest to only have references inside the same repo). But this requires all supported platforms are available on client machine, which for most of us never happens: we only pull for local architecture.

That's a question of packaging. If your compose is multi-arch and you want to distribute it multi-arch, the OCI specification offers enough possibilities to define it and distribute it. Many tools (e.g. skopeo copy) can be used to copy multi-arch images from a registry to the repository were you are pushing your compose.