-
Notifications
You must be signed in to change notification settings - Fork 350
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
Comments
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: |
There is also this one that may be interesting https://cloud.google.com/blog/products/containers-kubernetes/introducing-container-image-streaming-in-gke |
This issue has been automatically marked as stale due to 90 days of inactivity. |
This may be interesting https://oras.land/ |
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". |
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:
Since each
layer
is essential a blob (often atar.gz
) and that thelayer
definition has an optionalannotations
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):NOTES:
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.kamel run
can be enahanced to package a container image - ko alike - and generate a minimalIntegration
that points to that container imagekamel run -d container:docker.io/foo/bar
The text was updated successfully, but these errors were encountered: