-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Application auto-discovery #1766
Comments
Related issue: #1431
|
How would an AppsSource determine the corresponding AppProject for autodiscovered apps? A user might want to be able to specify that certain directories belong to a permissive project that allows certain cluster-scoped resources, while other directories belong to a far more restrictive project. |
Here is my current workaround for auto-generating apps-in-app from a kubernetes manifest monorepo.
I would imagine some folks keep their argo app yaml/k8s manifests in the same repo as their application code. Auto discovery of a configurable filename pattern under a certain Github org would probably work well (like the Jenkins github organization folder plugin). |
@wmedlar I was thinking that user might add |
It might also be nice if a list of folders could be provided to |
@alexmt how does .ardocd-app file is different from an application YAML? |
Not quite auto-discovery, but I think its related enough to share. This is our current App-of-Apps approach:
Every repo is kustomized, and we use overlays to patch the This gives us a nice logical separation where:
At the moment, we're just missing:
Argo is looking awesome so far, thanks for all your work! |
But what is the real issue what we are solving? I think it needs to work in that way:
So the things which we can discuss are:
Personally I feel path make it easy and it is common solution. No reason to make it more complex in code. It looks like a trap for maintenance for users also. But maybe somebody can show good working example from another software in that context? If you feel you are repeating yourself in Application of Applications make helm Chart from it. Only 1 issue which I have is: when creating new Application I copy manifest and sometimes I forget to change Application name or namespace :/ It could be a disaster in production. If you can prevent it by detecting possible mistake and pause to confirm or something like that it could be advantage, but it is not critical. Going further maybe people needs good best practice helm Chart example for this purpose instead of this changes? oh ok I see second things to improve:
Generally I decided to set it separately from Argo CD Application, because when Applications are syncing Bootstrap Application also change status so I want to keep it alone to not make confusion about Argo CD Application status. So when I want to make a change in Bootstrap Application manifest I have to do it manually by So maybe some kind of self upgrading without loop? Like from Bootstrap Application I can point to Bootstrap Application path in repo without creating Application to sync itself (loop)? It is hard to predict what issue it can bring now when looping it. So I prefer to do it manually, because this are very rare changes. Visualisation of the issue: GitOps, but loop: |
I currently use my app-of-apps setup to:
Where do those use cases fit within application auto-discovery? |
Hi, This is the workaround we are using for argocd application auto-discovery. First, a new plugin is created in argocd called "app-monitor":
Then, we have multiple "GitOps Git repo" which stores the applications definition and the related argoapp.yaml to deploy them. At that stage, we could just This is what the app-monitor is actually doing for us. Each "GitOps Git repo" is associated with/monitored by a "repo-app-monitor" ArgoCD App (using the "app-monitor" plugin). When a new For instance:
When/If ArgoCD is reinstalled from scratch, the configuration setup the Repositories + Monitors. All the applications are automatically auto-discovered and redeployed. There is no state/config to backup/restore. REM: I ignore the branch question in the description for readability. Snippet:
|
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 pinned this issue as it is interesting. |
I wanted to implement quite the same approach as @milesarmstrong in #1766 (comment). Here is my concept for applications-of-applications: https://github.com/tschonnie/argocd-pipeline However as @milesarmstrong mentioned, as long as every dev-team needs access to the argocd namespace and there is no project inheritance each dev-team can create also evil project definitions and point there team-applications to the evil project definition (e.g. destination namespace = "*"). |
@jannfis out of interest, how would the ApplicationSet practically solve this? |
@Tpx01 ApplicationSet is going to provide various generators. For example git file generator can scan repository and create app for each file that matches some pattern. |
@alexmt I looked into last night and indeed this concept could be very powerful! Thanks for pointing this out.. |
Is it still on the radar? Open for almost 4 years, no recent activity. I was thinking I could get rid of my "app of apps" and the shared resources warnings by just connecting repo - I was sure this would work out-of-the-box when I do, assuming it'd scan my repo for YAMLs and apply them. |
would be great to have such a feature, especially when you want to bootstrap a cluster from scratch , you only have to set a repository where all you svcs are in .. and all will be deployed and started as you want .. |
When using the app-of-apps approach, you can easily and frequently run into sync waves issues especially when nesting your applications, argocd refuses to sync when the app-of-apps has sync wave -5 and a children has -6 for example. That's why I'm considering to opt for an auto discovery feature. |
I think this issue is deprecated, because the use case has been implemented by ApplicationSet's Git generator since quite a while. Sync waves for ApplicationSet are practically implemented by ApplicationSet's Progressive Sync feature and will be further augmented by Application dependencies. I'll be closing this issue. |
Is your feature request related to a problem? Please describe.
A number of users would like something a bit more that app-of-apps. This would probably be served by auto-discovery of apps within a repo.
Describe the solution you'd like
Point Argo CD at a repo and let it fly.
The text was updated successfully, but these errors were encountered: