IOne of the nice features of Weave Flux is the ability to monitor a docker image repo for the publication of new images that match a given pattern, such as a regex or semver.
Then, Flux updates the image tag in the Git repo that stores manifests equivalent to the Argo
argoproj.io/v1alpha1/Application manifest. This is very elegant and useful.
This can be achieved because Weave Flux externalizes the storage of the Application manifest (they call the HelmReleases) into GitHub.
Is there an equivalent with Argo-CD? Can the applications be stored in GitHub and synced? If so, is also an equivalent way to update them automatically when new Docker images are published.
I am using Weave Flux, but prefer the GUI of Argo.
I would welcome such a great component that complements the current ArgoCD functionality!
Even if this doesn't find it's way into argocd itself, such a component could be fully self-contained, eg. docker registry monitoring capability, git commit capability to patch manifests and a rule engine to define the rules on when to patch.
I'd say this functionality could be split out from flux into it's own component, as it's already implemented there, and is totally self-contained (not mixed with the deploy logic). I'm not that proficient yetin golang to do it myself though...
Yes. Applications can be stored in Github. We call this "declarative set-up".
https://argoproj.github.io/argo-cd/operator-manual/declarative-setup/
However, if you want to automatically update them, that's kind of out of the purvue of Argo CD (it never writes to Git). However, amongst other solutions, you could create a nightly job in Jenkins that does this. There maybe other solutions.
I think this can be implemented as a separate component which watches the docker registry and updates git repo. The component don't have to be embedded into Argo CD and could be used with or without Argo CD.
This would be great contribution to https://github.com/argoproj-labs
For my Bachelor's Thesis about GitOps and ArgoCD I forked keel.sh to implement this feature. You can check it out here: https://github.com/Alwinius/keel The basics (and advanced keel features) should be working, but I still consider it alpha state since I only tested it with one deployment repository. Feel free to submit bug reports if you encounter something broken.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I've looked around the https://github.com/argoproj/argoproj-deployments repo, and found some interesting things that are very much relevant to this issue:
https://github.com/argoproj/argoproj-deployments/blob/master/argocd/overlays/production/argo-cd-cm.yaml#L7
https://github.com/argoproj/argoproj-deployments/blob/master/argocd/overlays/production/argocd-repo-server-deploy.yaml#L20
So it seems they are already experimenting with a flux plugin: https://github.com/alexmt/argocd-flux.
So that's just a hint on where to start looking, I will be trying that out once I get around to it. :)
OK, that just seems to implement the deploy part of flux, not the image updater part. :(
This is an eschewed feature.
Why?
One defining principle of Argo CD is that Git is the source-of-truth. Unfortunately, this is not always the case, common examples are where an app has a dependency that can change with any changes in Git.
Argo CD cannot monitor these for updates, and they are not audited by. Instead, you should pin your external dependencies and have an external process that updates Git when the external dependency updates.
What Can I Do?
If you build the image yourself, then your CI job could:
kustomize edit set image $IMAGE .git commit -am "Update image to $IMAGE".argocd app sync $APPNAME.For images build elsewhere, and you do cannot pin the image, you could simple ask Argo CD to sync on a cronjob.
We have a mono repo that sets up namespaces with core services for teams to run their apps in, but we don鈥檛 allow them access to our repo. They don鈥檛 even have kube api access and can only push new images that have to be picked up somehow automatically so that the new tag can be committed by the operator into the monorepo.
No dependencies which can鈥檛 be handled through semver tagging, and we have the possibility to let the teams manually set the semver match string through a ui (we instruct them to do controlled breaking-change updates by upping the semver match, but we want to offer them automated deployments for patches).
Very predictable workflow, very much in need of this functionality. Don鈥檛 you agree @alexec that such would fit perfectly in Argo, as it did in flux?
We store all of our deployments as ArgoCD Applications.
Upon a successful build we'll trigger a downstream Jenkins pipeline residing in the gitops repo with the Image tag, the Repo url, and the branch as parameters. We keep a map of repo urls -> to branch patterns -> to yaml paths to update. Each repo also has a docker image and command template with parameters slots for the image tag and file name.
So if the CI script cares about a giturl, branch pattern, then it will update the manifest files in the application.yaml with the given command template, the commit the result to the repo. Argo Will then initiate the update for the new tag.
Do you guys have a timeline for this feature to be merged to ArgoCD?
@alexec if were to use Azure DevOps as the CI tool any inputs on how we can handle this if feature is not provided by ARGO CD on purpose ?
Just a quick heads-up - Argoproj Labs is currently incubating https://github.com/argoproj-labs/argocd-image-updater
It is neither production ready nor feature complete yet, but we'd appreciate early adopters, ideas and contributions.
This is an eschewed feature.
Why?
One defining principle of Argo CD is that Git is the source-of-truth. Unfortunately, this is not always the case, common examples are where an app has a dependency that can change with any changes in Git.
- Helm chart dependencies, that are not pinned
- Kustomize remote bases, that are not pinned
- Docker images, that are not pinned ;)
Argo CD cannot monitor these for updates, and they are not audited by. Instead, you should pin your external dependencies and have an external process that updates Git when the external dependency updates.
What Can I Do?
If you build the image yourself, then your CI job could:
- Update the manifests, e.g
kustomize edit set image $IMAGE.- Commit the changes, e.g.
git commit -am "Update image to $IMAGE".- For manually synced apps, trigger the sync
argocd app sync $APPNAME.For images build elsewhere, and you do cannot pin the image, you could simple ask Argo CD to sync on a cronjob.
This will ends up in a scenario like GitHub and Bots where third-party apps can commit to your repo 馃槃 This has a great potential for merge conflicts.
We currently evaluating ArgoCD and we faced a very similar use case as mentioned in https://github.com/argoproj/argo-cd/issues/1648#issuecomment-581612729. We would like to roll out patches automatically (semver lock) for preview deployments. In that way, we don't need to maintain the versions in the helm values because the communication of updates is hard if you work on many microservices with different teams.
The needed functionality could also be developed as a one-time operation before or in the CI.
argocd sync semver: Updates all deployment images with regards to semver constraints.
Most helpful comment
This is an eschewed feature.
Why?
One defining principle of Argo CD is that Git is the source-of-truth. Unfortunately, this is not always the case, common examples are where an app has a dependency that can change with any changes in Git.
Argo CD cannot monitor these for updates, and they are not audited by. Instead, you should pin your external dependencies and have an external process that updates Git when the external dependency updates.
What Can I Do?
If you build the image yourself, then your CI job could:
kustomize edit set image $IMAGE.git commit -am "Update image to $IMAGE".argocd app sync $APPNAME.For images build elsewhere, and you do cannot pin the image, you could simple ask Argo CD to sync on a cronjob.