Open lburgazzoli opened 2 years ago
/cc @nicolaferraro @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:
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
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!
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. 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:
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