use the OCI containers to distribute camel-k artifacts

[lburgazzoli]

trafficstars

Open Container Initiative (OCI) has defined specs to enable the creation of interoperable tools for building, transporting, and preparing a container image to run, however - in practice - registries have a little to do with container images and we can think about them as a content addressable storage.

In camel-k we have been struggling a lot about find an easy way to provide artifacts/blobs to the runtime (i.e. https://github.com/apache/camel-k/issues/1821) and I think experimenting about leveraging OCI compatible registries could be a way to improve the situation.

This is not a brand new novel idea as:

• some discussion about leveraging container images have been happened already in the camel-k community
• solo.io leverages container images to distribute WASM
• there has been a recent talk about hacking the registry at kubecon

Since each layer is essential a blob (often a tar.gz) and that the layer definition has an optional annotations property that can hold arbitrary key/value paris, we can leverage it to identify camel-k artifacts (i.e. additional dependencies, resources, kamelets repositories, etc):

{
  "schemaVersion": 2,
  "layers": [{
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "size": 16724,
      "digest": "sha256:3c3a4604a545cdc127456d94e421cd355bca5b528f4a9c1905b15da2eb4a4c6b",
      "annotations": {
        "camel.apache.org.dependency": "com.acme:foo:1.0"
      }
    }, {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "size": 73109,
      "digest": "sha256:ec4b8955958665577945c89419d1af06b5f7636b4ac3da7f12184802ad867736",
      "annotations": {
        "camel.apache.org.kamelets.repository": "acme-kamelets"
      }
    }
  ]
}

NOTES:

1. solo.io has introduced a set of additional mediaType values but that may not work with some registries or tools so IMHO, at this stage, it would be better not to introduce a custom media type and leverage annotations.
2. A further evolution would be to implement a Kubernetes Container Storage Interface (CSI) to mount OCI layers to a POD
3. kamel run can be enahanced to package a container image - ko alike - and generate a minimal Integration that points to that container image
4. a Maven Wagon can be implemented to be able to read directly from a registry (similar to the s3 wagon)
5. container images can be used as a dependency kamel run -d container:docker.io/foo/bar

[lburgazzoli]

/cc @nicolaferraro @astefanutti

[astefanutti]

It seems like it would be the right level to abstract our needs for packaging and distributing artifacts.

From the performance standpoint, interaction with the container registry is now the major contributor to "TTFB" (Camel K equivalent) on average. And it does not scale well with the number of nodes. I'd be eager to research how it could use in combination with some initiatives / approaches like the above to improve performance, especially for the serverless use case:

• https://medium.com/nttlabs/startup-containers-in-lightning-speed-with-lazy-image-distribution-on-containerd-243d94522361
• https://stevelasker.blog/2019/10/29/azure-container-registry-teleportation/

[lburgazzoli]

It seems like it would be the right level to abstract our needs for packaging and distributing artifacts.

From the performance standpoint, interaction with the container registry is now the major contributor to "TTFB" (Camel K equivalent) on average. And it does not scale well with the number of nodes. I'd be eager to research how it could use in combination with some initiatives / approaches like the above to improve performance, especially for the serverless use case:

* [medium.com/nttlabs/startup-containers-in-lightning-speed-with-lazy-image-distribution-on-containerd-243d94522361](https://medium.com/nttlabs/startup-containers-in-lightning-speed-with-lazy-image-distribution-on-containerd-243d94522361)

* [stevelasker.blog/2019/10/29/azure-container-registry-teleportation](https://stevelasker.blog/2019/10/29/azure-container-registry-teleportation/)

There is also this one that may be interesting https://cloud.google.com/blog/products/containers-kubernetes/introducing-container-image-streaming-in-gke

[github-actions[bot]]

This issue has been automatically marked as stale due to 90 days of inactivity. It will be closed if no further activity occurs within 15 days. If you think that’s incorrect or the issue should never stale, please simply write any comment. Thanks for your contributions!

[lburgazzoli]

This may be interesting https://oras.land/

[johnpoth]

Hi @lburgazzoli,

As an immediate solution, it is possible to distribute camel-k artifacts as images using the wagon-docker-registry (e.g mvn deploy to docker.io) which is already integrated with camel-k via the registry trait. This works with Maven artifacts but also any kind of "blob".