Open nacx opened 1 year ago
count on me for that one, when I hopefully will get cycles to work on it... I wish my December would be different...
There are challenges with leveraging the applicationset
approach across the clouds (i.e. authentication handling, as the constructs are built on the point of "role" assumption). Few references how to:
Basically or we should static auth credentials (which is impossible) or keep the deployment within the common cloud (which is not a common demo example), i.e. we will hit the challenges when k8s where ArgoCD will be installed... needs to call out another cloud fleet.
Talking fluxcd
https://fluxcd.io/flux/get-started/#multi-cluster-setup
To use Flux to manage more than one cluster or promote deployments from staging to production, take a look at the two approaches in the repositories listed below.
https://github.com/fluxcd/flux2-kustomize-helm-example https://github.com/fluxcd/flux2-multi-tenancy
Interesting enough, however not necessary demo centric at this stage is fleet
https://fleet.rancher.io/concepts - I will dig deeper on that one...
p.s. as meanwhile as much as I want it feels like argocd
or fluxcd
cannot be yet deployed in a centralized fashion... which leads to the point of doing wrappers around which apps do go to which clusters... https://github.com/tetrateio/tetrate-service-bridge-sandbox/issues/177#issuecomment-1359357097
ArgoCD should only be installed in one cluster, as having one instance per cluster is not the right way to configure it (different installs, users per cluster, etc). Instead, a central ArgoCD installation with proper permissions (using projects, etc), is a much better example of how real-world ArgoCD installations are.
We don't have to go the project and permissions route, but we should at least install ArgoCD in only one cluster and update the existing example applications to use the cluster generator to get them installed in all the registered clusters, preserving the current behaviour.