OCI Registry as Source of Truth

[danielhelfand]

A thought I wanted to discuss on Argo CD is if the project would be open to supporting other sources of truth besides git, or if there are recommended approaches to consuming non-git sources of truth? This is mainly motivated by the idea of the Carvel project's imgpkg bundle, which allows manifests/container image references to be stored in an OCI registry.

A major motivation of the project is relocating assets to air-gapped environments. A case study around this idea and how it relates to GitOps workflows was shared in a blog from the Carvel project.

For users working with imgpkg bundles, what would be the recommended way of consuming this relocated artifact when using Argo CD?

[danmanners]

I'll throw my name on this. Having ArgoCD support OCI registries instead of Git as a Source-of-Truth would be incredibly valuable at scale for environments with thousands of clusters and privately hosted Git{Hub,Lab,ea}/GOGS/Bitbucket instances to be able to offload to an OCI Registry for updates.

[alexef]

ArgoCD can track other source than git, see helm, see docs with full OCI support coming in version 2.6.

[danmanners]

Hey @alexef, just wondering: are you saying Helm applications will have full OCI support, or will I be able to use OCI artifacts in place of how I've been doing git-repo syncing? If so, have any docs been written yet that I can reference to start planning for it? Thanks in advance!

[alexef]

I meant you will be able to use a Helm OCI the same as you would use a Helm non-OCI registry.

these are the docs - you can store a helm artifact for every commit, so in that sense helm would work similar to git.

[danielhelfand]

That's great that helm is an option. From discussions with others on the topic, helm is particularly challenging when relocating to air-gapped environments, so hopefully other options will be supported in future as well.

[pie-r]

@alexef do you know if there will be soon the support to OCI repository to be used as an option to git repositories?
Something like https://fluxcd.io/flux/components/source/ocirepositories/

[alexef]

as @jaideepr97 wrote below, the path to OCI repository is over the CMP (config management plugins). Let's check what is missing and fill in the gaps.

[jaideepr97]

Hi all
I brought this discussion up with the maintainers in the contributor meeting
My takeaway from the discussion was that as far as just adding native support for another kind of source goes, I think that's a hard sell, since the current design was made only keeping git and helm in mind, if we wanted to support any kind of source natively in an effective manner that would likely need a pretty fundamental redesign of how Argo CD gets the manifests

However, the current implementation of the config management plugins kind of goes part of the way towards supporting this already, but it might need a proposal to refine it to get to a point where it can support any kind of source repo including OCI registries
cc @alexmt @jessesuen

[willejs]

I saw this proposal was merged, does anyone know what the plans/next steps are with this?
Maybe @sabre1041 ?
https://github.com/argoproj/argo-cd/blob/master/docs/proposals/native-oci-support.md

[sabre1041]

@willejs started gathering thoughts on breaking up this effort. Please feel free to review and contribute as desired:

https://docs.google.com/document/d/1AJfRHxhnDo5ojeHsi2Q19FAUTucz1QJKAPtBbcxkbF8

[neil-119]

Looking forward to this. In the meantime, I wrote some custom tooling, essentially a CMP that points to a dummy git repo (not used in the CMP), the calling application passes in via environment variables the actual ORAS OCI source URL and auth creds to the ACR and any other env-specific vars it needs, and then my CMP script logs in to the ACR and pulls in the artifact via ORAS (custom shell script that runs during CMP init, in my case a cdk8s project), and finally runs a synth on it (cdk8s). Feels very hacky, but works, and allows me to version my cdk8s code for re-use across environments, and no need for helm in between. I plan on giving the sidecar a workload identity so that it can auth to the ACR natively and pull the artifacts without hacking in creds via env vars. Would be cool to see custom OCI artifact support for the source, which can then be configured to be passed on to our CMP for processing, which would remove a ton of hacky code.

[blakepettersson]

See #18646

[Freyert]

Is there a way to mark this discussion as answered or closed since this feature is implemented?