Hi everyone, and I hope you all are doing well. So today my session is all about GitOps Dynamics navigating the new era of DevOps. so we all know that DevOps is really important in any IT company or any IT domain. That is what we're going to discover, but we're also going to see how GitOps is going to enhance our DevOps process. So before starting, let me give you a bit introduction about myself. who am I? So my name is Megha Ghatur and I'm working as a DevOps engineer at Barracuda Networks. Also, I am a YouTuber. I like creating YouTube videos on cloud native and DevOps topic. So you can reach out to me there and also have a look around. Some of the YouTube videos that I've created. I'm also a content creator. Like I like, writing, writing articles. So you can reach out to me on LinkedIn. You can read my articles there. And yes, I'm also, providing mentorship where anyone who is new to DevOps or anyone who wants to explore their career in DevOps, they can reach out to me on TopMed. So you can scan this and, this will lead you to some of the details about me. So we will directly go into our today's session. That is GitOps dynamic navigating the new era of DevOps. Now, coming to the agenda, what we're going to see is we'll see what DevOps is, what GitOps is, and finally, we understand its architecture, its concepts. And at the end, we'll have a demo that will showcase us like how to. How GitOps is actually helping us, right? So before moving further on understanding what GitOps is, we need to have an understanding about what DevOps is. And I think most of us who are here will have an idea that what DevOps is. So if you search in Google, like what is DevOps, you'll get a definition that states as DevOps is something that is trying to bridge the gap between Dev and Ops team. This is what the definition that we usually see. So it's nothing, it's a way to automate your existing process by making use of various DevOps tools at this various stages. These stages are plan, code, build, test, and finally deploy, operate, and release. So all these stages will be making use of DevOps tool in order to automate your process and deliver the feature. Now, how GitOps is actually enhancing your existing DevOps process that we're going to see. So same way, if you search about GitOps, you'll get a definition that GitOps is a way to perform continuous delivery process by leveraging Git as single source of truth. Now, what do you mean by single source of truth? So single source of truth means the way you store your. The developers are the one who are responsible for writing the code and where do we store it? We store it in any git repository, git repositories, right? Some of the famous are like, GitHub, GitLab, Bitbucket, Azure Repository, and many other. The way you store your code, GitOps is also telling on leveraging that feature for storing your configuration files. We'll see that in the next slides. GitOps works on basically two major concepts. One is that it wants to store your application repository, the way you store your application repository, like the code that is written by the developer and the code may be written in any language like Java, Go or C Sharp or any language and we store it in Git. So we know that this is where we need to look out and this is where we need to get in touch or see the files if we have any issues. Same way GitHub's concept is telling us to store the configuration files also. Now what are these configuration files? These configuration files will represent how your application will behave in the live environment, like that is your production environment. Some of the examples of configuration files or repository, you can see that. Some are like your Kubernetes YAML files. Like we write pod YAML files, deployment YAML files, service YAML file, ingress YAML file. And your docker, file, all this will actually depict how your application will be behaving in the production environment. So GitOps is telling not only store your code repository, but also store your configuration files. So basically there are four major principles on which GitOps works. So they are declarative, version and immutable, pulled automatically and continuously reconciled. Now we'll try to understand these principles Because on the basis of this, we will be, we will be going through the demo, right? Okay. The first principle is saying that declarative, the word itself is telling us to declare something. Now what you need to declare the declarative word is telling us to declare your desired state. Now, how do you, declare your desired state? configuration files. YAML files or deployment YAML file. These are all your configuration YAML files that needs to be declared. Second principle is telling us that it states as version and immutable. Now, GitOps is telling us that declaring is not the only one thing that you need to do, but also it needs to be version and immutable. And how are you going to do it? You're going to store it in some of the Git repositories where you can have, we can have a history and we can know that this is the place where we need to identify our configuration files. And those can be versioned and we'll have a history of it the same way as we have for our work. source code repository. Third principle is telling us pulled automatically. Now what is pulled automatically. So in the upcoming slides, I will be showing you the GitOps architecture just in order to make you understand this principle. I'll tell you a few points of the architecture. So what happens is there will be an agent. You can call it as GitOps agent that will be constantly or you will be installing it in your Kubernetes cluster. So that GitOps agent or that software agent will be, constantly looking and it will be constantly Trying to make your actual state to be equal to your desired state So if any changes is done in your desired state Those changes will be pulled by that agent and it will be applied to your live environment. How we will be seeing that in the upcoming slides. Fourth principle is telling us continuously reconcile. So that agent that I talked about, which is sitting in your Kubernetes cluster, where all your applications are deployed. It not only sits there, it constantly observes. It's like a continuous circular motion. I hope you've enjoyed the video Like it will observe some changes. If it gets the changes, it will pull those changes and it will apply it. Once it is applied, then it comes back to the first, rotation that is observe the changes. So the main task is to make sure your actual state is your desired is always equal to your desired state. What is your desired state is whatever you have declared in your configuration files And what is your actual state is what is you are seeing in your production environment? Okay now coming to the deployment which is very much useful as github's is something that is closely related to your kubernetes Clusters or you can say where the deployment takes place that is and you know The cicd is the heart right heart of the devops. So github's is something that comes in your deployment process You So there are basically two major types of deployment. One is your push based deployment and the other one is your pull based deployment. Now we'll try to understand what is the difference and how GitOps is actually helping us to eradicate all those issues that we face. So here you can see that there is a developer who is writing the code and then we are pushing it to some git repository and then finally we are testing it and doing the build and finally we are generating some artifacts. So this is your CI process. Then comes the CD process. In the CD process, what we are doing is for this particular example, I'm taking Docker image as my template. output from the build. So I'm generating a Docker, I'm building the Docker image and I'm generating like a containerizing it. And, we are pushing the image to some of the container registry. So once we push it to the container registry, then what we do, if you're using a Kubernetes, What you'll do, you'll log into a cluster and type kubectl apply to push the changes. And if you're using Terraform, you'll do Terraform apply. Same way if you're using Ansible, there are certain commands that you're doing. So in this CI CD process, that is push based deployment, what do you see? One of the major issues that we see here is that your CI process is tightly coupled with your CD process. Say, for example, if tomorrow your company does key, okay, fine. We want to migrate a CI process from existing tools to some other tool. In that case, it will be very difficult for you. to, work on it because your CI is tightly coupled with CD. Any changes you make in CI will automatically reflect in CD. So it's like a double work you're doing. You have to make changes in CI also, as well as in CD. Other issues we can see that you need to expect. Expose your Kubernetes cluster. Unless and until you expose your Kubernetes cluster, you won't be able to apply the changes or the new features to be applied in your production environment. So these are some, issues or you can say some security concerns that we see in push based deployment. And yeah, there is one more like we need to give, read, write access. Say for example, in a team, you are around 10 to 15 people working together. So each and every member required, sir. Access they need to have a read write access that is how they can apply the changes to your different environments, right? So some of these issues we can eradicate with the help of pull based deployment. Now, what do you mean by pull based deployment? So in pull based deployment, The CI process will remain same. That is a developer writing the code, pushing it to Git repository, doing the build, and finally generating some artifacts and pushing your image to your container registry. Now the change that you see here comes in the CD process. As you can see here, in your Kubernetes cluster, there will be an agent will be sitting. in the earlier slide, I talked about some agent that agent will be constantly it will be installed in your clusters where all your applications are running. And what this agent will be doing is it will be constantly monitoring. for the changes happening in your configuration files and your configuration files are what they will represent how your application to behave in your cluster. So when, as soon as the CI process is completed, you will, you can add these processes like updating the manifest and any changes to be pushed to the branch. And finally, you can have raising a PR and pushing it to your GitHub repository. So as soon as a new change comes. This Argo CD will get to know, okay, the, this is not what I want. My actual state is not matching with the desired state. So I think I need to pull those changes. So it will automatically pull that, apply the changes and your new updated code or new feature that you want to showcase is already available in your production and live environment. So here, what you saw is one of the issues like CI is tightly coupled with CD is eradicated. If you want to make any changes in your CI process, you can go ahead and do it very easily. You don't have to touch your CD. Your CD will still work the same way as it was working earlier. Now here, you don't want to expose any Kubernetes clusters, secrets, or anything because The Argo CD is a tool that is representing the GitOps concept. So any changes you want to do, you don't have to expose your Kubernetes cluster or give read, write, access, somewhat kind of things, because it is already in your cluster where your applications are present. So you don't have to again, give an exposure of your secrets or usernames of password. So these are some of the benefits that actually helps us to, make your deployment much more faster and much more secured coming to the features. So here you can see that some of these are some of the features that are highlighted. So one is single source of truth. So as you can see, as we talked about, that GitOps works in the concept of Git being your single source of truth. So we know that if any issue comes up, we know where we need to look, we'll go back to our git repository and we know this is the file where we need to make the changes. Then we have application rollbacks. So when we talk about application rollbacks, say for example, if something happened, you push some changes in your production environment. And for some reason, That change or that new feature has failed your infrastructure or failed your production and now it's causing some issue and you're not able to see your application. In such cases, application rollbacks becomes very easy. In case of GitOps, GitOps offers a, a various way to roll back easily, where you can just switch back to your older version, bring your application back to your older version. And on the other hand, you can start working and debugging why the new feature was not working. So this is one of the major feature and is, and the other one is CICD automation. Your CICD is completely automated, continuous deployment. As I said, GitOps is something that is closely related with your deployment side of section and configuration drifts. So we know that, configuration drifts are something that happens when there is a change in some file or change in some particular related deployments related features. Now, in such cases, if those things happen, it becomes very difficult to identify, okay, what is the issue? Why it is happening? So we know that if any issue comes up, where we need to look back, we need to look into the Git repository because that is a single source of truth. So there are very less chances of configuration drifts to be happening. So this is similar kind of example, say if it's a Friday evening and we all know that Friday evening, it's we are very hurry. We want to go back to the home because the next day is Saturday, Sunday holiday and enjoy. So what if some issue comes up? And the only architect who was there, okay. He made some changes in the configuration file. He logged into the cluster, made those changes and brought back the application. The next day, the Monday when you come to the office or try to access the application, you will see there is some changes and it becomes very difficult for you to track back or to do reverse engineering because there is no history or no, what do you can say? A backup like what changes was done because in such cases you have to go to your files, log into different repository clusters, all sort of thing. It's a time consuming process. So in order to remove these kind of issues, you can make use of GitOps. This is how the architecture look like you need to install Argo CDN menu in any one of your cluster. If you're using multiple Kubernetes cluster, install it in one cluster and automatically you can guide the other clusters also. It's not necessary that you have to install in each and every cluster. One cluster. It is done and you can access GitOps using UI, CLI, you can configure webhook events also and notifications with the teams and Gmail. So these are some, GitOps tools that are most popular like Jenkins X Flux and Argo CD. But if we talk about the most popular one, the most popular one is the Argo CD too. And, the finally, I'm there on top med. I'm there on YouTube and I'm there on LinkedIn. You can reach out to me there. And if you want any kind of sessions, or if you want to explore your career in DevOps, or if you want interview preps and tips, you can book a session with me on top med, I'm available there. And I will be happy to help you all. okay. So we'll directly head into the demo section. And this is how the Argo CD UI looks like. I'm using Argo CD, which is a tool and that is representing the GitOps concept. and I'm using GitHub actions for my CI process, and I'm using Argo CD for my CD process. So what we've been doing here is that, this is my repository where I have all my code written. It's just a simple PHP application as a sample application. To demonstrate majorly the GitOps feature. So right now I'll show you the CI process, what it is actually doing coming back to the CI YAML file. So this is nothing but the major section where the main section where we write, which branch changes it needs to fix and and we have jobs section here where I will be building my latest image and, pushing my image to my Docker Hub. So in my case, for the example, I'm using Docker Hub. So in company, people might be using JFrog artifactory. Another cloud provider, cloud providers that provides container registry. So getting back to the CI pipeline and I'm pushing it. I'm logging into Docker Hub, then pushing the pushing it. This is something that I'm trying to scan, some of the, you can say versions or third party tools that we use, right? So I want to scan it with the help of SBM. SBM stands for software build of material. That will give me a detail about what are the versions that are getting scanned? What are the versions that I'm using in my project? So later on, if I come across some issues and I get to know that this version is not compatible with my project, I can get a list of it and I can identify that. Finally, the last action is like modifying the changes. So as I said, GitOps works on constantly looking to your configuration files. So if I make any change in my configuration file, This ergo CD will get to know that there is some change that I need to pull. Now, if I go back, this is my CA process. I'm making some changes and as soon as I make some changes, those changes will be updated. Now, let's go back to my application and here you can see. This is the name of my application. So it's healthy. It's synced properly. There's no issue. And I have made my tool to constantly monitor or constantly keep an eye 24 by seven on this particular repository that is Git automate. So any change that you do here will automatically get put going back to the application. So here you can see that the latest code that is deployed is. the name is 1. 0 release 127. If you go to Docker Hub and if you go to the name. Let's see. Okay. So you can see the latest at present, the change or the latest feature, the latest code is 127 and it's completely matching with this. Now we're going to make some change and we're going to see how it works. So let's go back to here and what I'll do. I'll just edit this one, just some random changes. Like I'll remove some spaces and I'll commit it. So let me commit my changes. Updated and I'll commit it. So as soon as I committed, going back to the actions, it will automatically get started. Let me just cancel one of the, it's I think two runs started. We'll see that later. Okay. So as you can see here that as soon as I make some changes in my repository, I have configured in such a way that the CI pipeline should automatically get started. That is what is happening here. It's automatically started. And we'll wait for this to get completed. It won't take much time. Meanwhile, this is running. I want to show you some of, so yeah, so I'm using, so I'm using a mini cube as my cluster where I have all my things running here. yeah, my Minikube is running and also I want to show you one more thing that I have put forwarded for my Argo CD so that I would be able to show you. So these are the two things. Okay, so the build stage is completed and the modify git stages started, has started. Let us wait for this to get completed. So this is also completed. Let us go to our Docker hub and we'll see what is the latest change that got pushed. I'm refreshing it. okay. As you can see here, the latest code or the latest feature is release 23. If you go to our, GitOps, you can say Argo CD tool, you can just click on refresh so you can see for a second, it went out of sync. Why it happened because Argo CD got to know that there is some change and its actual state is not equal to desired state. So what it does is it is automatically pulling the changes. It is deleting the older feature, bringing back the new one here. Also, you can configure one thing that if you want to put a manual intervention, you can configure that the changes should only be applied when there is a approval, or you can see any approval is provided. You can also configure that here instead of automatically syncing it. That feature is also available. So let us see what it is happening. It is trying to remove 127 and it is bringing back the new one. That is. 23. So this is the new feature or the new code that is written by the developer and it is automatically post here. This is a better way, much more secured way to deploy your application and keep a test, do a testing for your developers also as well as for the production also to deploy replication. So this is how you can utilize Argo CD in your complete CI CD DevOps pipeline. Thank you.