Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use the OCI containers to distribute camel-k artifacts #2732

Open
lburgazzoli opened this issue Nov 8, 2021 · 6 comments
Open

use the OCI containers to distribute camel-k artifacts #2732

lburgazzoli opened this issue Nov 8, 2021 · 6 comments
Labels
kind/feature New feature or request

Comments

@lburgazzoli
Copy link
Contributor

lburgazzoli commented Nov 8, 2021

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. #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 lburgazzoli added the kind/feature New feature or request label Nov 8, 2021
@lburgazzoli
Copy link
Contributor Author

/cc @nicolaferraro @astefanutti

@astefanutti
Copy link
Member

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:

@lburgazzoli
Copy link
Contributor Author

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
Copy link
Contributor

github-actions bot commented Feb 7, 2022

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
Copy link
Contributor Author

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

@johnpoth
Copy link
Member

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".

@squakez squakez added this to the 2.0.0 milestone Feb 2, 2023
@squakez squakez modified the milestones: 2.0.0, 2.1.0 Jul 27, 2023
@squakez squakez modified the milestones: 2.1.0, 2.2.0 Oct 17, 2023
@squakez squakez modified the milestones: 2.2.0, 2.3.0 Jan 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants