 Hello everyone and welcome to my session Deploy and applications to end clusters using our go CD application set My name is Dawon Ahmed. I'm a developer advocate at redhead and I'm from the beautiful new Brunswick in the Atlantic Canada region I love everything cloud native with a focus on DevOps and GitOps tools Besides work. I love to play pool and ping pong and I'm also a freelance carrier coach I help students new grads and professionals to start or transition into the software industry We have a packed agenda today. I'll cover some highlights or ideas behind GitOps Then I'll go over Argo CD. Although this session focuses primarily on application set I understand that some of the folks might be very new to Argo CD So a quick primer with Argo CD will be helpful for them We have a demo for both Argo CD and application set at the end We'll have a Q&A session and all the resources are in the github repository which you can see at the bottom right corner of your screen if you're watching this session on a mobile device you can Who came up with the term of GitOps Alex is Richardson the current CEO of we've works He came up with the term GitOps and he ran it by his friend His friend thought that the ugliest word he ever heard and now he can't unhear it trying to come up with a term that is Easy to pronounce But also difficult to forget Alex is realized that he came up with he found that perfect term Now this slide is from Louis Fasera and it summarizes GitOps in one slide. So we use Git as the single source of truth of a system We use Git as the single case where you operate We don't operate directly on the cluster. We use Git to do any create update or destroy of environments All the changes are observable and verifiable So keeping that in mind, let's understand GitOps Scratch that and let's understand GitOps for Kubernetes So Kubernetes gives us the power of declaration. That means everything in Kubernetes model. You can describe declaratively Kubernetes Updates provide a mechanism for automating the process of applying a set of changes directly Correctly and in a timely manner Kubernetes will try to keep updates until it succeeds with this kind of virgins Item potence means that multiple applications trying to converge We always have the same outcome regardless of how many time you're applying the command and Finally for determinism assuming that you have adequate resources. The updated cluster state depends only on the desired state So you should avoid using Qubes SQL to update the cluster and Especially avoid using scripts to group Qubes SQL commands together Instead use a GitOps tool so that the user or developer can update their Kubernetes cluster via Git So what does that provide us? That provides us correctness That means a group of updates may be applied, converged and finally validated which gets us closer to the goal of atomic deployment It provides us security. So we should limit the scope of access to a Kubernetes cluster to automation tools and cluster administrators who may have to debug it or keep it running and that's a tweet by DFMS Kelsey Hightower Finally Qubes SQL exposes the machinery of Kubernetes object model, which is quite complex Ideally your users or developers should interact with the system at a higher level of abstraction So based on our discussions so far These are the parts or bill of materials that we need to do GitOps on Kubernetes First we need the git repos where the configuration code lies and we need to cover this cluster or clusters where you'd like to deploy your code Then you need some sort of manifest generation tools like customize for different environments such as dev, prepod, prod This is optional. However Then don't use a CI server to orchestrate direct updates to Kubernetes as a set of CI jobs Now I added a link in the resources section in the GitHub repo that goes much more in detail. So why you should not use CI servers to do CD Finally your Kubernetes manifest files are needed such as deployment services, etc. So Keeping these in mind If we're looking for a GitOps tool, Argos CD Is an ideal choice. So what is Argos CD? Argos CD is a declarative GitOps continuous delivery tool for Kubernetes. It is part of an open source project which has contributors from both small and large companies like IBM Red Hat, Ntuit, as well as many individual contributors This project has also been adopted by a number of companies and you can find a list of that companies under the Argos CD's GitHub repository So why Argos CD? So the first three points have been covered before where we use Git as the single source of truth It's being developer-centric where you use Git commands to make any updates to your application Delivery and being declarative Now let's talk about security So Argos CD provides SSO integration including OIDC, OAuth2 and more It provides multi-tenancy and orbit policies for authorization It also gives audit trails for application events and API calls You can roll back your deployment to any application configuration committed in its repository Either using the CLI or the UI Argos CD app diff the command That performs a diff against the target and live set So you can observe the drift and that can be done by the UI as well So all these features and many more help your engineering teams to have a higher velocity in terms of their application delivery So this is the Argos CD architectural diagram, which is from the Argos CD read the docs webpage So here the blue box in the in the right-hand side is the Argos CD So Argos CD is implemented as a coveness controller Which constantly monitors running applications and compares the current and live state Against the desired state as specified in the Git repo A deployed application whose live state dvs from the target state is considered out of sync The API server, which you can see right here where the hover my mouse Is a GRPCN rest server which exposes the API consumed by either the web UI Or the CLI Or the CI CD systems Now the repository server, which you can see right here Is an internal service which maintains a local cache of the Git repository holding the application manifests Now the synchronization can be done using sync hooks and You can have different use cases to perform these pre-during or post sync One use case of such sync hooks could be if you want to orchestrate a complex deployment Which requires more sophistication than the typical coveness loading update strategy. You can do that and on the bottom Right, you can see your application being deployed into many clusters All right. So in last theory, let's dive right into the Argos CD demo So for this demo what I have is an open shift cluster and We installed red hat open shift GitOps operator on this cluster So this operator gives us out of the box Argos CD instance Or this is the Argos CD instance Which I connected to Let's create an Argos CD application. So this is my application manifest So I'm going to deploy a customized guest book application Which has a deployment file a service file and an customization file So let me Copy the link of this this configuration repo So I can do that from CLI as well But I'm choosing to use the UI to create this sample application I can give it a name Let's say devconf demo I'm going to choose default project, which is Argos CD project and not your Kubernetes namespace For sync policy, I'm going to choose automatic sync. I'm going to check these two which says Argos CD will prune resources if they're no longer in Git and cell file means if I Make any changes directly on the cluster rather than Git Argos will force and override the the changes I'm making directly on the cluster and will Have the state defining Git reflect onto the cluster So the repository URL is the URL I just copied and the The path is customized as guest book. So it should automatically pre-populate customized as guest book right here. This is The cluster URL is on the cluster where Argos CD is deployed and not the remote cluster So this is the default service the namespace So you can Deploy the application of the same namespace, which is Argos CD Where Argos CD is installed or you can choose a different namespace. So on OpenShift what I did was I created a namespace called guestbook.devconf and I added a small Label which is managed by OpenShift GitOps What this allows is OpenShift GitOps controller to to make changes in in that namespace So since I already have it I can Deploy into the guestbook dash devconf namespace. So let me choose that guestbook Dash Devconf All right looks good. I'll add a First prefix let's say xy to see dash And create So once I create since I have auto-sync enabled you can see that your application Was deployed it creates the service and the deployment and if I see my Deployment dot yaml. I can see I have three replicas and you can see three pods And how about if I make any changes If I change this of course, you should do a proper pr process, but for this demo I'm making change directly To the main so if I commit the change, let's see what happens to my application Once I make this change Let's hit refresh We should see the application goes out of sync but since I have auto-sync enabled The the state of the cluster will be Matched to the state defined in git which is a single replica and you see the number of pods went down from three to one I can delete my application. So if I hit delete devconf dash demo and here I have deleted the application. So that was the Quick demo of argos fd So let's go back to the presentation Now that was all nice. We deployed a single application to a single cluster But what if you want to deploy argos fd application to multiple kubernetes cluster at once? Or how about deploying multiple argos fd application from a single monorepore? Introduce application set controller for argos fd So on the left of the screen You can see that application set controller is sitting in the middle And it's it's looking over your git repositories and then it's creating multiple argos fd application across multiple clusters. So our unlike argos fd application resource Which deploys resources from a single git repository to a single destination cluster or names this applications that uses templated automation to create modify and manage multiple argos fd applications Simultaneously targeting multiple destination cluster and namespaces So the application sent controller is installed alongside argos fd within the same namespace That means on your cluster you have to have argos fd installed first On the argos fd namespace and on the same namespace you install applications and controller as well So in this example, you can see on the right hand side of the screen in this yaml line number two shows the kind being application set The list generator passes the url and the cluster fields into the application template as parameters So if you see line number 11 and 12 The url and cluster these are going into the template which is basically an argos fd application template And all line number 21 you see that there's cluster value which can be renders and then all line number 29 you can see the url value being rendered into the template Now targeting new clusters is simply a matter of you just add new elements into the application set resource and the corresponding argos fd application would be automatically created How does application set controller work now? the sole responsibility Of the application application set controller is to create update and delete application resources within the argos fd namespace The controller's only job is to ensure that our application resources remain consistent with the defined declarative applications that resource nothing more Does the application set controller does not create modify or delete Kubernetes resources other than applications here It does not connect to cluster other than the ones argos fd is deployed to It does not interact with namespace other than the one or where argos fd is deployed within It is argos fd itself That is responsible for the actual deployment of the generated child application resources such as deployments services and config maps So the applications that controller can be thought of an application factory So it takes an application set resource as input which you can see from the git icon right here And outputting one or more argos fd Application resources that correspond to the parameters of that set So application set has a number of generators list generator cluster generator git generator and some of the recently added generators in this list But for the demo we'll cover only few of these generators starting with list generator So if you want to check out these Generators in much more detail you can go to the Read the docs for application set So for now I'll come back to the presentation And it's time for applications that control a demo. All right, so Let me start the demo so here I have the application set list generator demo So if if you see for the list generator The type is application set and in the spec We provide the generator type as list and here you add your local and remote clusters And based on the template definition of the application your applications will be defied into Your application will be deployed into n number of cluster which are defined here So coming back to the demo So this is uh engineering dip, which is the local cluster where your Argo CD is installed So if I go to cluster I can see that both of the clusters are there because I did an Argo CD cluster add to add the engineering prod cluster already and here in the Source repo url you can see the application Which we're trying to deploy so the manifest are in in in that source repo url It also shows the path So similar to the guest book application which was customized as guest book. It also has that example path for that for that application So you can create applications that directly from the open ship console so Once you create you can go back to the argo cdui And you can see that Two apps are created. So if you see the destination right here This app is in cluster, but the other app is deployed into the The remote cluster So if you see the local app, which was deployed locally was healthy and synced but the remote app It failed. So if we click on sync fail, it says The namespace is not found that means in the in the remote cluster. We did not create the namespace so We created the namespace and that's something I showed you earlier as well That the namespace has to exist before you create the application So I created the namespace now and now let's try to sync one more time So if you click synchronize The application deployed into the remote cluster Who will sync as well? All right, so looks like both of our applications are now synced So this was using applications that list generator example Now let's try to delete this application. So let's say someone is being adventurous and trying to Delete resources directly on your Kubernetes cluster. So what will happen? Since it's deployed using application set This change Will be reverted So you can see on the left the application quickly became out of sync because it it was deleted But because you created these applications using application set You can see the application Argos application is again being created. So which is different than if you wanted if you created Application using argocd you could directly delete from from argocd ui But because you created using argocd application set even if you delete From the ui or from the from the cli Because it's created and managed by application set the applications will be created again So that was a quick demo of argocd application set list generators So going back to the presentation You can check to try out the different generators Which are in this demo right here. So in this demo, I went over Some of the other types of generators, which are argocd application set Git generator and also the the matrix generator. So that's you can try out on your own So at this time, I'd like to thank you for attending my sessions and welcome any questions you might have Thank you so much for that. Um, we'll just wait me to see if there are any questions Okay, we we have a question in um for you, Divan, is there any way can you join the Call or would you like to do the thing by chat the question by chat? All right, perfect. Hey, how's it going? Hi, how are you doing? I'm good. I'm good. It's what's the first All right, so we have a question here for you. Um, do you have any thoughts on annual installation of argocd? What is using the github operator? Thanks for that question, Anish. Yeah, absolutely. You can install argocd manually on your cluster either on openshift cluster on Kubernetes cluster But what github's operator openshift gives you is out of the box that argocd instance setting up namespaces applications at controller and also there are some Auth settings on on what you can versus can do around some best practices There's also the github's application manager. There is a cli It was called cam previously which creates an opinionated set of pipeline and and github's resources for you So those all you get out of the box using openshift github's operator So I'd say if you're already on opensheet using openshift github's operator Probably would be an ideal option. But if you're on the benedoc Kubernetes, uh, absolutely you can go with argocd All right. Thank you for that um Waiting to see if there are any other questions Uh, I see a question from david. Uh, was there a method for deploying the sno for public cloud for testing? Cloud dot is that is that for this session? I think it's from the previous session Okay, okay All right, uh, again, uh, thanks lagerica for moderating moderating this session and thank you everyone who uh joined in with this session Uh, I am active on LinkedIn and trying to up my twitter game So I'll hugely appreciate if you connect with me there and if you have any follow-up question Please reach out to me on either of those platforms and uh, thank you And I'm waiting to hear some feedback from you on this session. Yeah, thank you so much for your time Thank you so much for the talk Thanks Um, you can click the leave button on the top, right? Um Thank you