Using OCI Compliant Registries as Artifact Registries
OCI Distribution is evolving to support additional artifact types. This repo presents information on how registries and artifact authors can collaborate to have all OCI compliant registries be capable of supporting any new OCI compliant artifact.
This repository proposes a set of templates and guidance for registries to support new artifact types, and what a new artifact author would need to store and retrieve their artifact from an OCI compliant registry.
Table of Contents
- Working recommendation for supporting new artifact types
- Background for registries supporting new artifact types
- Leveraging Registries for Additional Artifacts
- Requirements of registries to host new artifact types
- Requirements of the new artifact type
manifest.config.mediaTypeto represent new artifacts
- Discussed approaches for storing new artifact types
- OCI Index & Manifest considerations
Docker brought great usability to the evolving container ecosystem by providing end to end experiences. These experiences included a registry storing secured, layered, optional signed, images.
The experience to call
docker run [registry]/image:[version] turns out to be productive and powerful, and not limited to just container images.
As new artifacts evolve, storing them in a registry for easy referencing turns out to be just as powerful.
helm upgrade myBlog demo42.azurecr.io/helm/wordpress:1.0 --reuse-values \ --set wordpressBlogName=myBlog
duffle install myBlog demo42.azurecr.io/cnab/wordpress:1.0
az deployment create demo42.azurecr.io/arm/wordpress:1.0
aws ecs run-task --task-definition demo42.dkr.ecr.us-east-1.amazonaws.com/wordpress:1.0
Leveraging Registries for Additional Artifacts
The major cloud vendors have implemented docker/distribution to support the registry api, implementing their cloud specific storage and security semantics. Additional products and projects like Codefresh, JFrog, Harbor have built experiences around docker/distribution.
With the volume of development and production activity, these registries are hardened, secured & highly scalable and available.
By evolving registries to support additional artifact types, customers and cloud vendors can leverage their existing registry investments.
Understanding Artifact Types
If we assume registries can host various artifact types, the next set of question include:
- How does one reason over the various artifact types in a registry?
- How would a registry listing represent the different artifact types?
- Can a registry show an icon and/or a short text identifier?
- If a registry listings wishes to provide optimized action points, such as gestures to deploy Helm Chart, ecs task, or deploying an image directly to a container service; how would the UI know which actions to surface on which artifact types?
- How would vulnerability scanners know how to scan the various artifacts? Would scanners perform different scanning routines, based on the artifact type? How do they know the type?
While tools should have knowledge of the artifacts they work with, so should a registry. By providing information on the artifact, registries can display artifacts, with context and details.