These days, when you start installing/configuring any tool or system, you should probably think about doing it in a declarative way - The GitOps Way
beside from saving you a lot of time later on,
this is the right way to have a single source of truth which always represents the desired configuration of whatever it is you are managing.
Instead of using a pipeline which only runs once any time you make a change, with GitOps approach the state of your deployed product will always reconcile to the state you declared in your code.
That way, even if you or someone else manually change something directly, those changes will be reverted back to the correct state according to your code, automatically.
This is sometimes called drift detection or configuration drift and it's the best tool for us DeVops engineer in years.
When I wanted to install Rancher on EKS, I took this path and created this setup using eksctl + Flux2.
The result is a one-time written git code, which you can easily use again to re-create both the EKS Cluster & the Rancher installation itself, fully configured with specific customizations.
The full article is Here
It's a straightforward approach to create EKS Cluster and deploy Rancher Server in high available mode with Helm Charts using Flux2
After reading and following the article,
You should end up with these results:
You can access Rancher UI from your browser with the Endpoint (DNS record) you set for your LB.
You have a high available Rancher deployed on EKS.
You didn't have to run kubectl in order to configure components.
You only use Git repository as a declarative GitOps approach to set the desired state of your apps.
You can destroy and recreate the entire project easily.
Top comments (0)