OCI support?

edward.a.peng_7759

Hi,
Does the current docker feed support OCI (open container initiative) specification similar to dockerhub? or is there a plan to implement a separate OCI feed type?

if neither is true, is it possible to consider having proget to support OCI in the near future? With Helm v3.8 GA'd OCI support few years back, most charts are moving towards storing in OCI registry instead of the older helm repository. most hosted registry solutions support this for quite some time now (https://helm.sh/docs/topics/registries/#use-hosted-registries)

atripp

Hi @edward-a-peng_7759 ,

There are no plans for a "generic" OCI Registry feed type. However, if you can help us understand what value this could add, we can consider building one.

A generic OCI registry seems to be like a "dumb" file system that's built around "dumb" cloud storage like S3, etc. What I mean, it's just files with no context. There is no real visibility into what's stored an OCI registry - it's just a place to store and access unnamed files via digests.

ProGet is a "smart" package and container system, and stores OCI-based container images (i.e. Docker images) in a Docker feed, and Helm charts in a Helm feed. There are so many advantages to this "smart" system vs a "dumb" registry:

You can browse images and charts in the UI
Charts and images are "linked" and you can see what charts reference which images
You can see what packages are used by images
Vulnerabilities are visible in charts, which packages/containers use, etc.
You can track downloads and configure permissions and control access

A "dumb" file system obviously couldn't offer any of this - and is one of the reasons people prefer ProGet over ECR, ACR, GCR, etc.

So far as I can tell, it doesn't matter to client tools whether you use ProGet Feeds or a generic OCI registry -- everything works the same with regards to helm, docker, kubernetes, and other supported tools.

Are there any advantages to having Helm charts being stored or accessed in a different manner?

Thanks,
Alana

jacob.kemme_1710

In our case, we're not specifically looking for Proget to add a feed type that is a generic implementation of OCI, we are asking for the existing feed types to fully support OCI image and feed standards where applicable (container images, helm charts, SBOMs, etc). At the very least, for container and helm feeds. The specific purpose of OCI is ensuring compatibility and standardization across different platforms and tools. It appears Proget is now behind nearly every other product in this regard for these artifact types. Proget at the very least should support and preserve OCI schema elements related to each feed type:

Proget Docker feeds should accept and preserve oci schema elements, example:

artifactType on descriptors if supplied (introduced in 2023)
mediaType(s): application/vnd.docker.distribution.manifest.v2+json as well as OCI Image Media Types

Proget helmchart feeds should should accept and preserve oci schema elements, example:

artifactType: application/vnd.cncf.helm.chart if supplied
application/tar+gzip when using index.yaml for classic/ existing charts
Helm OCI MediaTypes (used by default in Helm as of 3.8), or convert to OCI entirely since all of Helm is now on ArtifactHub.io (already supported by Proget as of 2024.17)

Notable container registries already supporting the Open Container Initiative image and distribution specs:

Azure Container Registry (ACR) added support 2023
Google Container Registry (GCR) transitioned to Google Artifact Registry (ACR) 2021-2024
Microsoft Container Registry (MCR) added support 2023
Amazon ECR added support 2020
GitLab Container Registry added support 2021
Artifactory added support 2023
OpenRegistry added support 2023
Docker Hub added support 2023
Zot (2020 OCI-only)

Docker desktop builds vnd.oci.image.manifest.v1+json by default now, not vnd.docker.distribution.manifest.v2
Zot only supports vnd.oci.image.manifest
OCI supports zstd and zstd:chunked. Not only is this a better compression format, which should speed up image pulls, zstd:chunked will allow container tools like Podman, Buildah and CRI-O to pull only the files that have changed in an image rather than the entire image.
Buildah, a Red Hat tool, allows building (only OCI) container images without docker daemon as a requirement

Beyond this subset of examples, it's becoming increasingly harder to find tools related to this space that haven't implemented OCI standards. Without OCI compliance in Proget container/ helm feeds, we're forced to look at other feed solutions that are keeping up with industry standards for proper tool interoperability. It seems like it would be a large win for Proget to implement OCI as a base, and extend that into the container (docker v2 images+feed schema are already OCI compatible), chart, sbom, and generic/ a (new) oci artifact feed type based on known OCI artifactType/mediaType definitions.

dan.brown_0128

I hadn't realized that the docker and helm feeds weren't OCI compatible. We're currently using Azure Container Registry for our docker/helm storage, but have been considering changing that as our usage grows and we're needing to tackle the Vulnerability/License compliance management.

In order to use the Proget docker/helm feeds as a drop in replacement, we'd absolutely need these to be OCI compliant and usable over the OCI Protocols.

apxltd

hi @jacob-kemme_1710 , thanks for all of the details.

I'm pretty sure the Docker feeds already support OCI containers. They are basically identical from an API standpoint, and we've made a few tweaks here and there to accept different media types or parse a field in a manifest differently.

I know for sure that vnd.oci.image.manifest.v1+json is already supported.. and if there's something missing, it should be trivial to add. I'd post that as a separate feature request, since it's likely a basic tweak.

As for Helm... that's a different story. I don't think it's going to work, and it doesn't seem like a good fit for ProGet. Nor is a "generic OCI registry", which is why I'm hesitant to even consider the feature.

The main issue I have is that an OCI registry is tied to a hostname, not to a URL. This is not what users expect or want with ProGet -- we have feeds. Users want to proxy public content, promotion content across feeds, etc. None of this is possible in an OCI registry.

We got Docker working as a feed by "hijacking" the repository namespace to contain a feed name. Helm charts don't have namespaces, so this is a no go.

We got Terraform feeds working by requiring some stupid prefix on the module name. There's just no other way to do it.

I don't think that would be smart to do with Helm. And obviously we couldn't do that for "generic OCI" content since it's just meaningless blobs/binaries.

I'm open to learning more... but my initial take is that if users don't find values in "feeds" (well-defined content types, permissions, segmentation, replication, etc), and just want a "generic place to shove random content stuff" then ProGet isn't the tool?

Alex