How To Apply GitOps To Everything - Combining Argo CD And Crossplane

this is about combining management of applications and infrastructure and services based on github's principles [Applause] can we manage infrastructure and third-party services and applications using the same ideas same processes same practices can we apply github's principles to everything not only our applications but literally everything can we ensure that all the resources no matter what is the type of those resources are always in sync those are some of the questions i will answer right now let me show you my artistic capabilities by drawing what we are going to do to begin with we have three types of resources we are trying to manage we have infrastructure we have applications you know our applications and we might have third-party services and we are defining all those as code and code is stored in git our applications need to run in clusters and clusters are collections of servers and servers and clusters need networking and storage and a bunch of other things all that is infrastructure or it could be a service depending on how you manage and where you manage and who manages those things for the purpose of today's exercise we are going to create a kubernetes cluster as a representative of infrastructure and we might need for example a database we might choose to run a data with ourselves or we could say hey i do not want to worry about that i want to use database as a service so it's somebody else my cloud provider manages that for me we're going to do the latter as an example of managing services provided by third parties so so far we have some manifests starting it and we want to use those manifest to create different types of resources infrastructure third-party services and our applications one approach that we've been using for many many years now is to create a web hook in a git repository so that whenever we push changes over there that web hook would notify some processes and those processes are typically cicd processes or cicd pipelines if for example we would change the manifest of one of our applications cicd would do whatever needs to be done and at one moment it would communicate with the cluster and say hey you should deploy this thing you should deploy a new release of your application however we are not going to do that it's still okay to use ci cd pipelines to build your artifacts to run tests and whatnot but for creating and managing resources be it applications or something else that might not be the best idea for a simple reason because they are one-shot executions of something cicd pipeline will react whenever we change something in a git repository but it cannot monitor continuously monitor the differences between the desired state which is git in the actual state which is our applications running somewhere or infrastructure or services and it cannot ensure that those two states the desired state and the actual state are always in sync we need a process that will monitor those two states and make sure that they are almost always in sync cicd pipelines or any type of one-shot processes that are reacting only on changes to a git repository might not be the best idea it was in the past it's not today instead we are going to use argo cd to be clear it could be flux as well but i had to choose one of the tools for the examples so i'm using argo cd but just in your head mentally think of it as being flux as well so conceptually is the same story anyways we are going to use argo cd that will continuously monitor uh git repository or get repositories and the state is in this case the state is what is running inside of our kubernetes cluster and make sure that those two are always the same if i change something in my cluster it will undo my changes because they are not the same as what is defining it if i push something to get it will apply those changes anyway it will make sure that those two states are always the same and the two states are desired state which is git and the actual state which in this context are kubernetes resources so argo cd will communicate with cube api which could be the same kubernetes api where argo cd is running or a completely separate cluster that's not that important anyways it will communicate with the api telling kubernetes what to do or at least giving it hints what should happen and kubernetes will ensure that our applications are running in that cluster wherever that cluster is but our applications are only some of the resources that we can create in kubernetes we can also create additional custom resources and in this context that will be for example a resource to create a cluster or to manage a cluster a resource for the third party database if we can define those things things that are not necessarily only our applications as kubernetes resources then we can let targo city synchronize our definitions with what is in kubernetes cluster and that something is not always a pod once we are sure that kubernetes cluster our clusters contain the resources for everything we need not only our applications but also infrastructure and third-party services we can use cross-plane to ensure that those resources created and managed by kubernetes and propagated to kubernetes with argo cd are created and managed as well so the job of crossplane is to read those custom resources like database cluster whatsoever and propagate that information to vendors apis so today we are going to use google cloud for examples remember it applies to any provider it doesn't really matter i just have to use something anyways crossplane in today's examples will communicate with google cloud api and propagate information from those custom resources about hey create this cluster or change this cluster create this database or modify this database or destroy the database if we are successful in this attempt we will have a coherent way to manage everything infrastructure third party services and applications we will define everything as code we will store that something in it we will apply gito's principles so that git always represents the desired state and everything else is the actual state and those two states will always or almost always be in sync because the processes will be continuously checking whether there are any drifts between those two states so let's get going let's see whether we can do the hands-on part of all this whether we can do all that in 20 minutes or less and after that we are going to discuss what we discovered before i start typing and doing stuff let me explain what i did before i started recording this session first of all i created a local kubernetes cluster using kind and if you're not familiar with kind i recently published a video go check it out it's it's above my head anyways i have a local kubernetes cluster that i can use to install and run crossplane i configured it to use my gcp credentials and they installed argo cd think of that local cluster as a control plane for managing infrastructure and kubernetes resources and whatsoever it's running on my laptop so it was easy to set it up basically i spent maybe five minutes now when i think about it i should have shown you how i did it because it probably takes more time to explain what i did than to do it that's it that's all the setup and now we can explore what should we explore first yeah yes let's take a look at the manifest that i prepared and the first in line is infrastructure so if i want to create let's say a kubernetes cluster i can define it like this jk tess so this is my definition of cluster it is using cross plane manifests i'm defining a gk cluster over here called devops toolkit and where it will run you assist one and then i have one node pool running in three zones the whole region or i don't know is it three or four zones doesn't matter three zones and uh that's about it what machine type how many what's the maximum minimum number of nodes you know the standard stuff except that this time the standard stuff is defining cross plane format apart from that i also created the argo cd application let me show you that one cut controller okay here it is so it is a standard typical argo cd definition of an application that says hey the application is defined in this repository and the path the directory where it is defined is gk that's the file the directory i showed you a moment ago the next in line are applications how do we define applications we do not need cross plane for that argo cd itself can manage applications just like any other type of resources and i have one defined here in devops toolkit up k test and this is just a simple application that has a deployment nothing really special because we are not going now into details about each of those topics a deployment called their toolkit and the horizontal portal to scale it that will scale the application from two to six spots so that's the scale of the application we're running it's a simple simple application nothing really special and just as for infrastructure i have defined argo cd application which is in controller devops toolkit yaml here it is it's almost the same as the previous argo cd application it references the repository and the directory where the application is stored finally the last in line are services and i have one defined here devops toolkit db kfs right we can manage services in the same way as managing infrastructure actually i'm not even sure what is the exact difference whether gk cluster is infrastructure or the service database is a service in this case anyways we can define services just as infrastructure using crossplane in this case i'm defining an sql instance uh with this name and that's about it we can define additional parameters like this is the region where i want to run this database and this is the tier that i want to use for the database i think that this is the smallest one now that everything is defined applications services infrastructure all we have to do is tell argo cd how to monitor where where is where are the applications defined that's what we need to tell argo cd we need to give it initial push and from there on it will do magic this is argo cd ui i'm going to login with admin admin obvious right and right now there is nothing running no applications defined in this argo cd instance and we are going to do just that we are going to define a single application that will manage everything and that application is this one it says it's just another i can see the application it says hey uh the this is the repository and the path is controller that's the directory where i have up for infrastructure for gke clustering another application for the application itself another application for the database so all i have to do is to keep this initial root directory from which argo cd will spread all across the that git repository or and beyond so this is the last time i will interact with kubernetes cluster to tell it what to do from now on everything will be gift of space absolutely everything everything will be done by making changes to the desired state in git so cube cattle apply dash file name uh apps there we are kinda go go go there we are now let's take a look at the ui we can see that it already started creating stuff right there is the production application this is the root application the up of apps and it uh detected that there is uh gk something called gke and there is argo cd so it will manage itself even and there is uh that was toolkit this is my application and there is the database over here right so it detected it spread across the repository detected the all the apps there and it is creating them right now so at the moment i do not have a clustering g key i do not have a database and in that cluster that i do not have no applications are running i'm doing everything from scratch in my gcp account that currently has absolutely nothing so this will take a few moments i'll be fast forward to the end of the process because it takes between five and five six minutes to create a cluster and then a few more minutes to do everything else let's take a look whether it's finished i'm going to go to my gcp account here we are and you can see that the cluster is about to be created so here's a cluster the system is creating my cluster and it's creating that only because i defined it as a kubernetes resource and then crossplane took it over and did whatever needs to be done actually cluster was created right now and i think it should start creating nodes yes it is stopping the initial node and soon it will start creating additional nodes [Music] there it is the node pool is created so i have a fully operational cluster how about the database let's take a look sql here it is was that created as well yeah so i have my database up and running here it is right and the only thing left to check is whether my application is running let me tell you in advance it's not i think i know why the only thing not running the only thing that argo city couldn't do is to deploy my application and the reason for that is that the destination is set to https one two three four that's obviously not the ip of my cluster so i need to modify the definition of the application to point to the newly created cluster and i'm going to do that right now so i'm going to retrieve the credentials of the newly created kubernetes cluster and there we are it created cube config for me let's take a look at the config the current context of the conflict that was created and this is the name and we can see now that if it will get nodes or any other cubecat command it is interacting with the new cluster that was created just by pushing the definitions to git but i wanted the context for a different thing i need to change the definition of the up of apps that controls the demo application that i want to have deployed right it needs to point to that new cluster and to do that the first thing i need to do is add the cluster so argo cd cluster add and then what was the name of the context here it is so i'm going to add this context and i'm going to name that cluster jk for example okay there we go what i really want is to get the list of the argo cd clusters and there it is there is the the old one the one that is running locally in my laptop and the new one i will copy the address of the server and i will modify hotel modifier yes controller devs toolkit yaml to say that hey this server is actually wrong this application should go to this new server and that new server is this one and then all that's left is to add the things and comment with the creative message something and push that something a few moments later argos cd should pick it up it can take anything between a millisecond and three minutes because three minutes is the pool frequency so let's wait for a few moments and then we go to argo cd and see whether it's synchronized now if i go to the application we can see yeah that's it it's up and running the application is up and running actually it's not yet up and running but it will be up and running soon right now it has only one pod created through deployment it created a replica set now it gets two parts because the hpa horizontal pod auto scaler was created and that's it my application is up and running and if you don't believe me actually let's say that you know you might not believe me let's double check that a few couple are russian namespace production that pods there it is and you can see by the age that is 43 and 26 seconds that this is something that was created right now effectively the only thing i was doing is pushing fast to get and i get infrastructure i get services i get applications i get everything inside and outside of kubernetes cluster actually as a matter of fact i could use kubernetes cluster as a control plane for orchestrating everything including infrastructure that infrastructure doesn't even have to be kubernetes i could use this for any type of infrastructure it doesn't have to be kubernetes i will not go through the part where i would destroy something and you would see how cross plane or argo city would automatically detect drift and synchronize it if you are not familiar how that works please visit the videos there in the description that that show you how argo cd works and how crossplane works and all those things i'm not going into details here i just want to make sure that the whole process the whole idea is clear in a way without going into details for details you have separate videos for argo cd and crossplane and many others just check my channel so i'm skipping the drift detection now to synchronization and showing you how everything is always synchronized no matter what happens instead i am going to destroy what i created at least the application the service or the application running in a kubernetes cluster and the database and how do we destroy things uh we could destroy them by going to console and just clicking delete button or something like that but we are not going to do that because this is about git tops we are going to delete the files from a git repository so i will delete rm controller devops toolkit db and i'm going to delete the other one as well so i'm leaving the cluster working because some other applications might need it but i'm deleting the database databases service and i'm deleting the application itself that's currently running in the cluster in kubernetes cluster actually i'm not deleting any of those things i'm deleting the manifests and then argo cd should do the work let's check it out let's check it out so i'm going to add those files and commit those files delete everything and i'm going to push those files now we wait for a few moments and let's actually go back to the argo cd ui and see what's happening there we are if i go back to the root now my application here the toolkit is running and devops toolkit db in the service sql managed by google cloud they're still running right and if i go here i can see that the database is there right so nothing really happened and the reason why nothing happened is because argo cd did not yet synchronize did not yet pull new information from kit so let's let's wait for a few more moments and there we are now it is out of sync and it is progressing and what is it doing we can actually go here and see what what it's doing it's deleting stuff right there we are it is deleting the application and and it is deleting the database and soon they will be gone let's go back to google console and check the database there we are database is no more and i just deleted files from git let's see the application as well is it running cubecuttle namespace production getpods come on yeah empty delete it i can create stuff i can modify stuff i can delete stuff it doesn't matter whether it's infrastructure or services or update or my own applications and they will always be in sync with what is in git and if i delete stuff from git then stuff is deleted in real world that's it let's go back to the big screen and discuss what we just experienced in this video i did not go into details how to work with argo cd or crossplane or git or this or that instead this is more like a culmination of many other videos that i did in the past we got the unified way at least from the process perspective to manage everything and everything is infrastructure third-party services and applications and that process is github space we are managing everything by pushing changes to git repositories and we have argo cd that is pulling those definitions and making sure that the desired state that manifests defining it are the same as the actual state or actually that the actual state is the same as the desired state but since sargo city can manage only kubernetes resources and not infrastructure not the things outside kubernetes we added cross plane so argo cd among other things is managing cross plane crds or cross plane definitions and then cross plane takes it over and manages everything happening outside our kubernetes cluster or the kubernetes cluster where crossplane is running right because as you saw in the example crossplane created a second kubernetes cluster and it can create a third and a fourth and a fifth and it can even manage the cluster where crossplane itself is running the important thing is that i have to make a choice which tools i will use i chose argo cd for synchronization between kubernetes and git repositories but it could be flux as well similarly i chose crossplane to manage everything happening outside of the domain of kubernetes resources and that could be terraform or polumi now it would be harder with terraforming polomi for a simple reason because a they do not allow us to create kubernetes resources so we would need to figure out a different way something that is not argo cd and b terraform and polomi do not have a way to detect drifts and how to correct the current state compared to the manifests right they are one-shot agents that do something when we tell them to do but do not monitor the state of what they did and correct it continuously we could make those work in a similar way as what they did with crossplane it would involve a few additional steps it might not be as effective but it can be done i can show you how to do the similar process with other tools but you have to let me know in the comments what those other tools are and i will do my best to do a variation of this video with the tools you like you just need to tell me which tool you prefer for infrastructure and for services and which one for applications and i'll do my best to do it that's about it remember to like and subscribe thank you so much see you next time

Channel: DevOps Toolkit

Views: 20,557

Keywords: gitops argocd crossplane, gitops argo cd crossplane, gitops, kubernetes, k8s, argo cd, argocd, crossplane, infra, infrastructure, infrastructure as code, iac, applications, apps, application, app, services, service, third-party services, 3rd-party services, drift, drift detection, sync, auto-sync, viktor farcic, devops toolkit, devops

Id: yrj4lmScKHQ

Length: 24min 58sec (1498 seconds)

Published: Tue Mar 30 2021