 Hello, and welcome to another presentation for GitHub Store in Europe. So my name is Costes. I'm a developer at the Codfress. I'm also working a lot with ArgosDB and ArgoLauts. Codfress, if you're familiar with us, is an enterprise solution for software delivery. It is powered by ArgosDB and offers all the features that you would expect from a moderate enterprise solution. The last thing that we released is support for environments. You can see on the screenshot, because many people at ArgosDB and they ask, how do I model my environments and how do I promote the applications between them? So if this is something limited to you, check us out. So today we're going to talk about GitOps for applications, which is a topic that should be familiar to everybody. And then we're going to extend it to GitOps to infrastructure, which is something that is not familiar to everybody. And we're also going to talk a bit about the data from GitOps and have a demo at the end. So just to get everybody on the same page, this is ArgosDB, if you have never seen it before, it's a GitOps controller. And by default out of the box, it works with Kubernetes applications. Here I have deployed the Kubernetes application. It's healthy, it's synced. So ArgosDB says to me that what they have in Git is also in the cluster. And you can see I can get an overview of all the individual components of the application, like the pods and the services. And this is great because I get all the benefits of GitOps. So one of the best advantages, if you ask me, is avoiding drift detection. So normally when you change something in Git or in the cluster, you want to know about it. So ArgosDB notifies you and says, hey, now your manifest is not synced to the cluster, you made the change. And then you can make a decision and say, okay, I like this change, so I will commit it to Git or no, somebody did this change manually and I don't like it and I will override it. So you get always the guarantee that what we have in Git is also in the cluster. So this is great and people like ArgosDB or Flux. Whenever I say ArgosDB, you could also imagine Flux. But then people ask, okay, that's great for Kubernetes, but what about things outside of Kubernetes? So typically an application will travel like a database or a queue on a nested back across torrents. How do you handle these things? ArgosDB and Flux out of the box do not have any support for all these things. So what people usually do, they just say, okay, ArgosDB is nice. I will keep it for Kubernetes only. So I will use GitOps on Kubernetes. And then I will have something else from my infrastructure and usually companies have a huge investment on Terraform or other tools like the Pulumi or Uncivil or the Classics like 7puppet. And they use that for infrastructure. And when I say infrastructure, I also include the clusters themselves. So now we have two different words. On one side, we have the things for applications and they are to produce ArgosDB and Flux. So it's Kubernetes native, it's fully GitOps. And those tools always give you the guarantee that what you have in Git is also in the cluster. Let me get all the other benefits of GitOps as it is the auditing. And then there is the second world of infrastructure which is not handled by Kubernetes. You create their intra either when you call the Terraform CLI or you run a job or tasks. And there, unless you do something magic by default, you also suffer from configuration drift which is everything I explained before. How do you create infrastructure applications? Again, for Kubernetes, you always work with YAML. This is what Kubernetes is based on. But then for intra, you use something else. So if you use Terraform, use HCL. So you have different languages to learn and become an expert. And you can see in all the slides here, I have a big barrier. The center that shows the difference between the two words. So let's talk a bit about Terraform. I'm saying Terraform because most companies are familiar with it and also a lot of people are happy with Terraform and they say, okay, I'm pulling GitOps everywhere. Just a huge disclaimer. I love Terraform, Terraform is a great tool, that's great. So on the next slides, I will not, let's say attack Terraform, don't take me wrong. I will just explain why Terraform is not following GitOps. Terraform is a great tool. Now, if you don't exactly know what makes a tool, GitOps by this point in time, you should know about the GitOps principles. They are over there at the top in GitOps.dev. This is the page of the working loop. The GitOps working loop. You can see code press there is one of the founding members and also WeWorks and the main company behind Flux. So it's not the AgroCity principles or the Flux principles, it's the GitOps principles and everybody agrees on them. And then if you look at the principles, they are those four. First, the system that used a declarative format for describing your input or your application. You should use a version and immutable storage for your description. You should have a software agent that pulls automatically all this information and also you should continuously reconciling for this information so that you get a guarantee that what you have in storage, usually in Git, is also the same thing that you have in your infra. So these are the principles that the tool must follow in order to say that, hey, I'm following GitOps by the book. And if you have worked with Terraform, only the first principle is covered. Yes, Terraform is using HCL, which is a declarative language where you describe how your request actually should look. That's fine, but all the other principles are not followed. And Terraform is using Git, but this is only for storing the files, like the HCL files. For state, Terraform has its own state and we're actually going to talk about it and it's not in Git. By default, Terraform is just a CLI, so it's not an agent that you install somewhere and pull this information, you have to run it either manually or from a CI system. And also, again, by default, Terraform doesn't have any continuously conciliation. So you run Terraform, it does something, and then it finishes its job and stays there. If you do a change manually in your infrastructure, Terraform doesn't know anything about it. So those four principles, only the first one is followed by Terraform. Now, I want to talk specifically about the second one regarding state. If you are working with Terraform, Terraform has its own state, which is usually stored in an S3 bucket or in console or in Islamic and backend. And Git is just the original storage of the Terraform files. But the source of truth, the thing that Terraform looks in order to decide if something exists or not, is its own state. The state can be manipulated manually, which goes against the second principle that says that state should be immutable. And also by default, Terraform doesn't do anything with the state until the next run. So you run Terraform once, let's say it creates a virtual machine, it stores in the state, then you delete manually that VM, Terraform doesn't know anything about it. So the next time Terraform runs, it will detect and say, oh, I have a VM in my state, but this VM doesn't exist, what do I do? So at any point in time, you don't really have the guarantee that was described in Git. It's also in Terraform state object. And I think the best example to showcase this is the second principle. If you remember the second principle said that state should be stored in an immutable storage medium and it should be versioned, which works great for Git, but Terraform has its own state and there is even a Terraform state command where you can remove stuff from the state. So it's not really immutable anymore. So Terraform uses Git for storage, but not as a source of truth. And I can guarantee that if you have worked Terraform in a big company, you would have your own horror story about Terraform. This is one of my favorite ones for Spotify. If you set Terraform as state Spotify, you will find the video where somebody from Spotify explains how they destroyed two thirds of Spotify production because they misunderstood or misused Terraform state. So that's the end of Terraform. Again, as a reminder, I love Terraform. It's a great tool, but it's not GitOps, especially when there are other better solutions. And we can do better for GitOps. There is something better. Ideally, we would like to have a tool that is native to Kubernetes. So not just CLI, like Terraform or PAPET or something else. It should be a native Kubernetes controller. It should use this sync loop, like Argos to DN Flux, where it stays within the cluster and then it always looks at what is in, many resources that are in Git and then applies them. And it should give us the constant guarantee that what we have in Git is also in the external resources. So if we had that magic tool, we could extend Argos CD to also work with infrastructure and not just Kubernetes applications. Because this is what we want to do. We want to take Argos CD to the next level. So if we do that, then we would have one single word. So we would have Jamel manifest for our applications and we will also have Jamel manifest for infrastructure by removing completely the barrier between these two words and having like a unified approach to everything. So what we want, we want to apply GitOps everywhere. We want to use the Kubernetes API as a central place for everything. And we want to get all the good benefits of GitOps and apply them to infrastructure as well. So things such as, you know, brief detection, common tooling and universal workflows, they should be a common part for everything and not just Kubernetes applications. So this thing exists today. This is crossplain. If you have never seen crossplain before, you should definitely check it out. This presentation is not about crossplain. So I will talk a bit about it, but crossplain is the tool that essentially embodies all the principles I talked before. So it allows you to create Kubernetes manifests. It comes with its own CRDs that represent infrastructure, infrastructure out of the Kubernetes cluster. So here I have an example with a bucket and this is for Amazon, but there are similar providers for Google, for AWS, for other cloud providers. And of course you can create your own and other things that you have in your infra can be described. So here are some additional examples for an RDS instance and a subnet and you can have things for virtual machines and stuff like that. So once you have those manifests, you can use the same Kubernetes tool that you already have such as ArgosDB. So this is how it works. I have a Kubernetes cluster. I have installed there ArgosDB like always and I've also installed crossplain. So crossplain now has installed in the cluster its custom resources which represent infrastructure, these YAML files. So I can apply them with ArgosDB and once applied crossplain will create the infrastructure for me outside the cluster. So I have a manifest that describes a virtual machine. I apply it with ArgosDB and then ArgosDB via crossplain will create a virtual machine outside of the cluster and this is how I can manage infrastructure using GitOps. So imagine this is my ArgosDB dashboard and these are ArgosDB applications but in this case they are not Kubernetes applications. They are infrastructure outside of the cluster. So here I have an S3 bucket and we'll also see this in the demo and I still use ArgosDB like I'm used to to work with applications. You can also do something even more let's say fancy. Remember that the Kubernetes cluster itself is infrastructure and you can also describe it with crossplain as well. So you could have a scenario where a developer comes to you and says I need a new application and a brand Kubernetes cluster and you could create crossplain first to create the target cluster and then after you create the cluster use standard ArgosDB resources to deploy applications on the cluster that you just created. So in the end you have a single Git repository or two Git repository that doesn't really matter where operators work on manifests that describe the cluster and then developers work on manifests that describe the applications that are running on the cluster. So everything in a single workflow everything with a common way of working both with infrastructure and applications. Okay, so enough about the theory. Let's see a demo. So here I already have my ArgosDB instance and I've already installed crossplain. So I can show a quick example where this is like the standard Kubernetes application. This is actually one of the examples for ArgosDB. You can see just the user stuff like a deployment, the pod and services, basic stuff. But I also have here another application which I'm calling infra. And let's say it's the infrastructure that this application needs. So in this case, if I go and look at the resources this one is a DB instance. So it's an RDS instance. So this box describes infrastructure and this is an S bucket because my application needs these two things. And if I also go to my Amazon console you can see this is a database that was created. It's over here and here I have the buckets. This is the bucket that describes my application. So I can also verify that my infrastructure is there. Okay, so that's great. When exiting application I also want to show you like a quick demo how it is to create new infra. And just for demonstration purposes I'm going to use the ArgosDB UI which is something that you should normally not redo. You should use a manifest but that's okay for this demo. So I'm going to deploy just a very simple manifest which is again an S bucket. So you see I tell to ArgosDB go to this repository and apply whatever is in this folder. And if I look at this folder it is just an S bucket with a name that includes a GitOps, super simple. Crossplane is much more advanced. So it starts as out of sync. And then as soon as I sync it ArgosDB deploys the manifest and because this manifest is a crossplane manifest crossplane will take over and say, okay, what is described here? We have an S3 bucket and then it will create the S3 bucket. So this is finished. You see it's healthy, it's sync. And then I can go into my S3 buckets. And if I refresh you see the GitOps con demo that was just created. So this is how easy it is to create infrastructure. So that was for the demo. And as I said, you know, crossplane has other capabilities. You can also define your own compositions and group stuff. But as I said, this presentation is not about crossplane. Here is also another tool that takes the same approach. This is something I discovered recently. This is Atlas. It's a Kubernetes controller that describes database migrations. So this is a custom resort. Resorts which if you look at it describes a database migration for my SQL. And as you can imagine, I can take this find and apply it with Argo CD or any other GitOps tool and then handle database migrations with GitOps. So now I have the whole Trinity. You have Argo CD which out of the box supports only Kubernetes resources conferences the enterprise version. Then you have crossplane that creates infrastructure for you and upbound is the company behind crossplane and they also have a commercial company. And then you can also explore other tools such as Atlas which is the one I talked about that has database migrations. So you are using GitOps everywhere. Like you create clusters, you create databases, you migrate the bases, you deploy applications all with GitOps because this is what we want in the end. We want all the benefits of GitOps and like using the Kubernetes API having a unified way, describing resources in the clarity format using Git as the source of truth, avoiding configuration and drift and implementing common workflows. We want all these benefits to apply it everywhere and not just on Kubernetes applications. So even though, you know, some people think that GitOps applies only to Kubernetes and only to Kubernetes applications. You can use GitOps outside of Kubernetes and also combine it with other tools that allow you to use GitOps for infrastructure. And other stuff. So sets all the GitOps tools that exists apart from Kubernetes. So that's it. These are the tools that we were talked about. This is my email if you have any questions. Thank you.