Argo-cd: Select a cluster by alias when creating applications

Created on 1 May 2019  路  17Comments  路  Source: argoproj/argo-cd

Is your feature request related to a problem? Please describe.
As a new ArgoCD user, it seems strange that we have to specify cluster URLs (and repositories) explicitly for a project as well as each application. We currently deploy to an external cluster, so the server IP (https://12.34.56.78) needs to be entered in each config file, which is hard to read and maintain.

Describe the solution you'd like
In the application configuration, I would like to refer to the cluster destination by an alias of my choice, e.g. my-project-acc-cluster. This alias can be assigned to the cluster when adding it to ArgoCD.

Describe alternatives you've considered
Somehow injecting the cluster IP into the config files - seems like a lot of hassle that would make the Argo setup less transparent.

Additional context
Is there already a way to do this somehow?

ui enhancement help wanted usability

Most helpful comment

@alexec do you think we can reopen this one? Like I said I can start working on it.

All 17 comments

I will take this, we also find it complicated and confusing to always use the url
but I can only start working on it after first week of July - vacation period coming in a couple of days, so if someone else wants to take a look sooner, please do

I _think_ this maybe fixed by https://github.com/argoproj/argo-cd/pull/1814.

Screen Shot 2019-07-02 at 11 48 26

Fixed in v1.2

@alexec
I am not sure this issue is fixed or I might be missing something.
I see you can select a cluster by a name when you create the application from the UI.

But lets say I create a secret for a new cluster on the argo-cd namespace with the annotation managed-by: argocd.argoproj.io Is there a way to provide an alias for it, which I can use inside Application yaml?
And I guess the same should apply when using the cli: is there a way to provide an alias when adding a cluster from the argocd cli?

no - we use the IP as the unique ID, so you must provide this.

Yes and I think that's what the author is complaining about. I had this issue myself, it is very easy to confuse those IP addresses. It would be much easier with something like dev-cluster, staging-cluster etc.
So how about a feature to supply an alias for a cluster, probably part of a new field inside that secret. Should also be possible to pass it when the secret is created with the cli, probably with an additional flag. And then to use this alias inside Application and AppProject yaml files.
Does it make sense?
If yes then I would like to work on something like this.

OP here, I was indeed looking for a solution as lcostea describes. It is especially useful for making Argo applications in a microservice landscape - it would be nice to only have to specify the cluster IP once, as a global config.

@alexec do you think we can reopen this one? Like I said I can start working on it.

Please do.

Now that vacation days are (almost) over I managed to get some progress on this.
I have added an --alias flag to the argocd cluster add command.
The alias is saved into the secret created by the argocd server and it is also retrieved back by the client.
More details can be seen in my fork and any feedback would be appreciated.

Working now on how to use the alias when creating a new Application.

Each external cluster's name is (as of v1.2) stored in a secret alongside the URL (data.name and data.server, respectively). Could the AppProject and Application CRDs be extended to allow destination.name as an alternative to destination.server?

this is a popular issue, so it'd be amazing to get a community contribution

I will check this option and see if I can stop introducing this alias. If possible I will be back with more details of the implementation.

I managed today to create an app (guestbook) on another cluster, just by using the name in application destination and without specifying any server. Which is a good progress. I still have some work on the cache side (just made minimal changes so it will work) and on project validation (now there is also name besides server and namespace) and some better logging to include cluster name. And many tests to add. I hope I will open a PR in a couple of days.

I've been pondering this a lot. We use the URL of the cluster as the unique ID for the resource.

Primarily, it would be good to be able to change the URL of a cluster, and have all apps re-deploy to the new cluster.

Secondarily, it would make cluster URLs easy to read, e.g. http://my-prod-cluster or http://my-qa-cluster but it confusing if the URL is http://123.6.7.8.

Could this be solved by being able to configure /etc/hosts?

Alex

If I may add our experience:

we try to add a DNS entry pointing to our kubernetes master IP and use that DNS entry as the server key in cluster configuration.

We run into an SSL issue:

title="Unable to connect to cluster: Get https://our.cluster.entry.dns/version?timeout=1s: x509: certificate is valid for kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster.local, not our.cluster.entry.dns"

Note that this may be linked to how our kubernetes clusters are managed (FYI we use GKE) but I am not sure I can have a private certificate for ArgoCD that is also valid for my dns entry in addition to kubernetes, kubernetes.default, kubernetes.default.svc.

We are fine putting IP in cluster definition file but having to reference this IP in applications and project definition is error prone : we always need to look for the correspondence between IP and clusters' human readable name.

Anyway, great job on ArgoCD, the project rocks and it gets better and better !

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

Was this page helpful?
0 / 5 - 0 ratings