 Wait for some touchy. We have a guest speaker, Sayam Patak. He'll be talking to us about GitOps using Agile CD. Minutes. Yeah, he'll be talking to us about Agile CD, GitOps using Agile CD. He's the Director of Technical Evangelism at SIVO. Sayam, can you hear me? Yes, I can hear you. Can you hear me well? Yes, and thank you very much for... Awesome. Yeah, glad to be here on KCD Africa. It's a fantastic event that you people are doing. Happy to be part of it. Okay, awesome, thank you. Cool, I'll present my screen. You are able to see my screen. Yes, I can see it. Awesome, cool. So, thank you for the introduction. My name is Sayam Patak, and I am the Director of Technical Evangelism at SIVO, which is a Nixon cloud platform providing Kubernetes service. And in this session, I would like to tell you more about the Agile project, the GitOps principles, how we can use Agile CD. We try to use the maximum benefit of this time to show you a hands-on demo as well so that you get the max out of this. So, starting off with the Argo project itself. So, Argo is a CNCF incubating project, and Argo is able to do a lot of things. So, people usually get confused in only the CD part. So, Argo do not have only the CD part. It has many more things that are there. So, you have the CD, obviously, which we'll be talking about for the GitOps rollouts, which combines with the CD and gives you the complete workflow. Then you have specific workflow for running the machine learning pipelines where you can create the workflows and the events that trigger on certain actions. So, workflows will orchestrate jobs on Kubernetes, create and run workflows on K8. So, you'll be able to create and run your machine learning workflows and run them on Kubernetes. Again, the use cases mainly involve around the machine learning, batch processing, CI pipelines, and each step, obviously, each step in the workflow. So, workflow, you can say, as a pipeline is there, there are multiple steps. Each step will be running as a container. Argo events, Argo events are like event-based dependency manager for Kubernetes. Variety of event sources can be there, like Webhook, S3, we have Pub, Sub, Slack. So, all these are there, which can trigger the Kates objects. And it is Cloud Events Compliant, another CNC project. Rollouts, it's advanced capabilities. So, when you are talking about Argo CD and you combine the rollouts with it, it provides you with advanced capabilities, like Blue, Green, Canary. Let's say you want a different version of your applications for your customer, but only weighted traffic, like only 30% of your customers, of your people who are using a website should be able to see the new version. You can do the weighted traffic, splitting, canary to climates, automated rollback, custom metric queries, all the stuff can be done using the rollouts. So, let's move on to the Argo CD. Before Argo CD, I would like to tell you about the GitOps stuff, which is there. So, GitOps is basically these are the principles that lets you have everything defined in your Git repository. So, you have the true GitOps, I'll tell you, I recently created a video on my YouTube channel about the true GitOps way and how I call it and how I define true GitOps is where I am able to define my infrastructure as well in Git. So, we are moving towards the era where people are managing their infrastructure and application using Git itself. We can do that, and we can do that using Argo CD itself. So, you have your, you know, the Kubernetes nodes which are there, and this is GitHub repositories. So, you can have Git repository, and you can have infrastructure repository or a folder in that, and you can have your app folder in that. Your infrastructure folder will be having your infrastructure templates. And the best way that I feel we, you know, that is it's done is, we use something which is called crossplane. So, crossplane is infrastructure as a code stuff that can be used, that can be installed on the main cluster. So, how you will be achieving the true GitOps way, let me just show you once. So, you have your Git repositories, and this is your K8 cluster, your Kubernetes cluster. In your Kubernetes cluster, you will be installing Argo CD and you will be installing crossplane. So, Argo CD and crossplane are over here. Now, in crossplane, obviously, you will be having some providers that you have installed that will be provisioning your Kubernetes cluster or your resources on that particular cloud vendor. Each cloud vendor have their own crossplane provider. So, you have installed a crossplane, crossplane provider, you have installed Argo CD. Argo CD is monitoring your Git repository. So, this is your Git, and it is monitoring your infra folder and your app folder. So, as soon as you deploy a file which crossplane understands, it will deploy, and crossplane controller will take that changes and will actually spin up your infrastructure. And you can use something called application set, which is another cool CRD custom resource from Argo CD, and you can create application set. You can connect this cluster to Argo server, and as soon as this is connected, your application will be deployed. I know it sounds complex and we haven't yet understood the Argo CD, but I just wanted to tell you that you can have your infra, you can have your infra, and your applications in GitHub repositories, and you can achieve the true GitOps way from Argo CD, from tools like Argo CD that helps you do that, monitoring the repository, lives within Kubernetes cluster. So, let's continue our journey with Argo CD, so where we were. Yeah, so the problem it solves is very clear. I told you, you have Git, you can build, you can push. Now this comes under the CI pipeline. This is there, but what about the deployment? You cannot use the same CI pipelines to deploy to Kubernetes. If you deploy to Kubernetes, how will you get the status of that? Whether that application is deployed, how do you deploy the revisions for that applications? How do you manage those applications when something goes wrong? Does it notify you? So all those things are not part of the CI stuff which is there. So for deployment, it is GitOps is needed, and GitOps is needed. You cannot do with regular pipelines with Qubectl apply. You need custom scripts, which you need kates, access, Qube config files, and also what about the monitoring? You have to write another custom script for that. So we cannot do all this for sure. That's why there are solutions, and one of the solution, one of the most popular solutions out there is Argo CD. Now Argo CD is built for Kubernetes and GitOps approach. So the very famous pipeline example that I always give, I personally use it, is I have CI, I have GitHub Actions already there. So if any changes to my Git repository, my GitHub Actions will be building the code, pushing it to the repository and changing my deployment file image in the repository it's in. And then it will be, then Argo CD will be deployed onto a Kubernetes cluster that will be monitoring the changes. So Argo CD is there on the cluster and it will be deploying those, taking all the changes and then it will be able to deploy your application onto a particular node, which is there. So I think all the benefits are very, very clear. Like you have the true GitOps approach. You have easy, easy rollbacks. You can have your DR setups. You can actually have your complete infra and apps as part of a Git repository. Something goes wrong. You exactly can create a replica of your cluster in a new environment. That's the power of Argo CD. You have single SSO multi cluster. That's where I was telling you about, sorry, that's where I was telling you about the application set. So you can use the application set for multi cluster deployments. All the clusters that are connected to Argo CD, if you have an application set, application, that particular application will be deployed across the cluster. Various use cases for that. Let's say you have hundred, many developers that join your organization and you want to spin up cluster on a daily basis with some set of deployments, hardened policies and all that stuff. So you can have a GitHub repository. You can have application set created for that. You can connect your new clusters to Argo CD and automatically your cluster will be ready with the applications that you need for your new developers and they can access it. They can do that stuff. Same approach can be used for DR. Same approach can be used for deploying one fix application to all the clusters. So many use cases over there. It has a very fancy web UI. So basically it is UI is enough to do everything with respect to management of your Git repository, seeing the status, seeing the health of your deployments which are there. And CLI is also there. So Argo CD CLI will be there. Argo CLI that you can use to create and manage all your apps. And you get there from with his metrics out of the box. So Argo setup is a regular HHA or core Argo. So you have your Argo setup which is you can have it as a regular setup or a highly available setup or a core Argo. Core Argo was fairly new, not super new but it is fairly new which gives you only the apt amount of Argo installation. Working is pretty simple. So you have your controllers, you have a repo server, you have Git and you have the API server which it is connected to the controller sync between the repo server and API server. Repo server is basically the cache which is getting maintained. So you can see repo server maintains the internal cache of the repo. In the HHA mode, the authentication is via DEX and notification control is now part of Argo CD and it started at Argo Labs, yeah, now part of Argo CD and triggers and templates. You have the server which is this one that has exposed a consumed by the web US or web UI and Argo CD use this to connect to this and it does all the magic for you. You have application controller that obviously uses the OCD repo server to get the manifest and talks to the API server and puts both of them in sync so that your applications are actually in sync. Then you have Argo core. So this is what I was telling you, the new kind of project which is that and getting started with Argo, no multi-tenancy. If equipment is RBAC only, managing web, CLI, easy transition from core to full Argo that also is supported. Yeah, with Argo 2.3, I think there were many improvements including the images which is good and application set notifications were part of Argo CD which is again superb. Many improvements, bug fixes were always there. Sync and different sync and diff strategies are also there. So I think those were some of the cool features for Argo CD. How much time do I have? I can do a demo. I cannot hear you. Yeah, I think you still have like 15 minutes. Okay, awesome. So let's move to the actual action which is there. Let me see if you are seeing the right screen. Yeah, so this is actually the Civo dashboard which is there from where I'll be provisioning the Kubernetes cluster right in front of you. Everything is there. So let's create a live cluster demo. Okay, KCD forgot. And everything as it is except that from CI CD we'll be installing Argo CD. So let's create this particular cluster. Oh, I haven't chosen the size yet. Nothing fancy that I've done. Till the time it is getting created, let me show you the GitHub repository that I'll be using to deploy the application. I hope I have some application. Maybe I can use this and I can use the deploy folder for that. Yep, this can be done. Cool. So I'll watch the deploy folder of this repository. So this repository is nothing. There's a deploy folder. There is a hello.yaml file that is just deploying a particular yaml file. Actually, if you want to see the source code also, it's pretty simple. It's a Flask application. So a Flask application that is listening on port 8080 and as soon as anything is deployed. So that was the actual flow that I was talking about. GitHub actions will run. So this will be checking out Docker push, building the image, pushing it to my repository and changing the deploy hello.yaml file with the image tag. So every time any change is there, it will change this particular tag which is over here. So it will add that SHA to the image tag and all the changes. So that completes my cycle. Any change I make in the templates or in the code, like in the HTML, any change I make, it will directly be visible with the new deployment because Argo will be watching this folder and CI will be building this and adding the new image to hello.yaml file. So that is on a very high level that that particular stuff is. So yeah, we already have the nodes up and running and we'll be soon having the cube conflict file that I'll be using. And let me just fix my terminal as well so that you don't see anything fancy running over there. In the meanwhile, then I have to share my complete screen. Export, I can, yeah. So cube conflict is there. I'll download the cube conflict file and save it. And now I need to reshare my screen because I have to show you the terminal window. I hope you are able to see the terminal window now. Okay, so now we export the cube config, cube cvl get nodes, oops. Cool, so KCD Africa cluster is up and running in front of you. That's nice, cube cvl get pods, hyphen A. Let me see if Argo CD is getting installed on that. Yep, Argo CD, you can see notification decks, repo server, application controller server. They are getting installed slowly, slowly. And what we are going to do is we need a service of cube cvl get svc, Argo CD. I think there will be a service, Argo CD server. Let me just change that to a load balancer, cube cvl edit svc, Argo CD, and make it balancer. I can definitely create the ingress. That's been lazy over here, cube cvl get, oh, hyphen A. Let me check again if stuff has been running. Yep, most of the stuff is running. Some are still, you know, getting ready and cube cvl get svc, let's try it out. All is still getting ready, Argo CD. Yeah, so all the pods are running and you can see what all the pods are. So you have repo server and we saw that in the diagram, the application controller, the Argo CD server itself, the core one, the decks for authentication, you have the application controller, notification controller. So all the components are here. I'm just trying to connect to the particular server. Once it's done, I'll definitely share the other window. And in the meanwhile, I'll also try to get the secrets. So this is the initial secret for the Argo CD UI. Cool, my Argo CD is up and running. I can switch the screens now. You have to see my face again. Let me share the window again. Yeah, so this is the screen. I proceed, that's the same load balancer. You can see that Argo CD is up and running. We'll copy our password that I showed you how to get it. And I think admin is the username. Yep, this is your fancy Argo CD UI, which is there. So this is how it looks like. You can actually add a new app from here, a demo app, and give sync policy automatic. You can prune the resources on deletion. You can self-heal. You can also have auto create namespace. All these you can do from here. We'll give the URL. Let's go here. Let's give the URL. And I think the branch is main. So we'll give, yeah, main branch is fine. And path is deploy. So deploy. Destination is this cluster, namespace, we can leave as it is. And let's try to create it. So you can see this is how it starts the project and it starts to sync the project, the GitHub project with that Kubernetes cluster and try to see if this path is there, it can deploy. So you can see this is getting deployed demo and the namespace is missing. Let me create the namespace. I actually did do the auto creation of the namespace. Let me just see what is happening in the, I do see that the app is not here. Let's try it, invalid spec, namespace is missing. I do have a namespace I believe, so interesting. Let's delete and give a namespace. This one is showing green, good signal, cool. Yep, everything is deployed and cube CTA will get pods. Let me check in my terminal as well. Yes, I can show you that it is running. Yep, we can actually see everything is running. So we'll do a cube CTA and get SVC so that we can go to that particular IP. So this is the node port, the service is node port. This is the cluster IP and we can, hod is running. And the cluster IP is got three, one, six. So I think we should be able to see the application soon. So you can see what all stuff it created. It created a service, it created a deployment and we can even go to that deployment. We can see it is synced. We can see what all stuff got deployed over here, which application got deployed. So this was the image that is deployed and this is the service, node port, service type node port, which is three, one, six, nine, two, and the endpoint. Yep, everything looks fine. Let me just see, oops, it is somehow waiting. I hope I'm in the right cluster. Yes, I am. Oh, yeah, just a second because I didn't fire walls. Let me just, for now, but don't do this. I'm adding, allowing everything. Yep, so yeah, this is KCD Shinnai, but we can definitely change this to KCD Africa. So if, like, I can show you the true GitHub stuff, which is there. So this is KCD, welcome to KCD Africa and KCD Africa. And let's commit this. So as soon as I commit the changes, what it will do is it will trigger a pipeline over here and we can see this is the GitHub actions. I just hope my credentials are working fine in this particular repository because I keep on changing them. So if it's not, then we will skip the credentials part and uploading it. The only part which will be deployed the Docker image. So if it can deploy the Docker image and push to my repository, then we can see the change else it won't work as it is. It says that the login is succeeded. So we might be able to see the stuff which is there. And as soon as, what will happen now is it will, it is checking deploy folder. So very soon our Git will be able to commit the deploy folder over here. Let's see the details to which step it is there. It has pushed and deployed to the local repo. Now the push is happening to the local repo and it is completed, perfect. So this is completed, our deploy folder got changed. Now let's go back here. Let's see when it will get synced. I think 30 seconds is the sync. Let's refresh. Yep, something is getting changed. So you can see it is getting changed. I can check in the terminal myself. You won't be able to see in the terminal, but yes, there is a new container which is getting created in the terminal. You have to believe me. Yep, it's running and yay, we are welcome to KCD Africa. And I hope you enjoyed the GitOps knowledge about ArboCD, how to connect a live demo KCD Africa. And one last thing that I would like to just add that I also have a community called Kube Simplify. That's the kind of community that I, simplifying cloud native for everyone. And recently I started a new initiative called workshops which are free of cost. So two workshops are up, which will be live on 11th and 18th of July. Please feel free to register for them. kubesimplifier.com slash workshops is the link. And I really hope you enjoyed this particular demo on ArboCD. So if you have any queries regarding ArboCD, regarding any of the stuff that I'm doing with respect to Kube Simplify, my YouTube, my Twitter, you can contact me anywhere and make sure to kind of follow me on social media as well. One question I just saw that just to confirm, did you tag your image with latest? No, so it's not the latest, it's actually with the Git commit. So if you just see in my GitHub actions in the workflows, I'm actually using the commit SHA to tag the image with. I think somewhere, somewhere here, where it is. Yeah, this one. So I'm getting this particular SHA shot and it will tag the image with that. Cool. Yeah, I'm also there on the KCD Africa Slack. So make sure you join that. If you have any questions, you feel free to let me know and I would be happy to answer all your queries as well. Thank you so much for having me. It was, I hope you enjoyed the session. Awesome. Thank you very much and thank you very much for hoping in last minute and saving the day. I think we have one more question. How did you update the image tag in your manifest file by John Paul? Can you bring back my screen share? Sure, sure. Yeah, so how it is happening is as soon as I commit, I have a GitHub actions, which is written. So GitHub actions will run this file and it will create, it will build the code. So Docker file is there in the code, it will build the code. And I'm using a Jinja template. So you can see this generate, deploy, manifest from the Jinja template. I'm using the Jinja template and the output file will be deploy, hello.yaml. So deploy, hello.yaml, Git, my Git itself is committing to that, just variable will be this image deploy tag. So you can see in the repository, tmpl, hello.y2, this is the deploy tag. So that will be changed with the Git commit and this will be then pushed to deploy, hello. And that's how my image gets changed with the latest commit. And Argo CD is watching this particular file, deployment deploy, hello.yaml, it will automatically get deployed onto your Kubernetes cluster with the latest revision that is there. So that's the magic and the power of GitOps, Argo CD using it the right way. So I've shown you actually the complete CI CD process till the deployment from the code. Cool, glad you understood. I'm not able to hear you. Sorry, I muted myself. Once again, thank you very much. And we look forward to more collaborations with you. For sure, for sure. Thank you so much for having me. Awesome.