GitOps for Amazon EKS Lifecycle Management with Write Back to Git Repositories

Ғылым және технология

Hello everyone!
In this session, we will talk about how to use Rafay GitOps to manage the lifecycle of kubernetes clusters. Before moving to the demonstration, let's first understand what is GitOps?
GitOps is a set of practices to manage infrastructure and application configurations using Git, an open source version control system. GitOps works by using Git as a single source of truth for declarative infrastructure and applications.
GitOps is a model for designing continuous integration and continuous delivery where the code you are deploying is stored and versioned in a Git repository. It centralizes every aspect of the process for managing both operations and development.You can also control the processes by enforcing peer review by creating pull requests and quality by unit testing the code. And then once merge the PR, it will kick off the rafay automation to provision the cluster with the spec you have provided in git.
Now lets see all these in action! As you can see here, currently in our system we have an EKS cluster running. We are using Rafay GitOps in order to centralize all the resources in our Git repository. Some prerequisite steps which we need to follow for the RAFAY GitOps are: First, create an agent. Second, Add the git repository details. Third, create the pipeline.
As part of this demo, we will divide various activities into Day zero, Day one and Day two scenarios:
Typically, As part of your Day-zero operations, you would want to sync all the resources back to git as a central repository. Here you can see that we don't have any cluster YAML in our Git Repository to start with, so let's trigger the new job which is going to sync all the cluster resources back to Git. Once the Job is completed we can see the cluster yaml in our git repository.
Next, As part of the Day-one operations, you might want to do some cluster operations using Git, so as you can see in our GIT repository we only have one cluster yaml. Now let's add a new file for the cluster which we want to provision, for now let me copy the YAML from the existing file. Now commit the newly created file, this commit triggers the Rafay-automation and you can see the cluster started provisioning in the system.
Now let's try to do a few more operations on the existing cluster. In this cluster we are deleting an existing nodegroup and also adding a new nodegroup at the same time. Once we commit these changes, you can see the required operation is started. We can see the node groups which have been removed from the YAML. It is deleting from the cluster as well and same goes for adding a new nodegroup.
You can see both the jobs are in submitted state, once all the operation gets completed, our job status also changes from SUBMITTED to SUCCESS.
After waiting for some point of time, you can see the cluster has been created successfully. And both the job’s status turned into Success.
As part of a Day-two operations, you might want to delete the cluster using git. Here, we have two cluster YAMLs in our git repository, As we delete the YAML, you can see that this sync and automation starts deleting the cluster.
This is how you can leverage the Rafay GitOps System Sync to not only manage your Kubernetes environments from a central repository but also automate various CRUD operations and synchronize with your environments.
Thanks for watching!!

Пікірлер