 So thanks for coming to my talk. I am going to be talking about how to make your deployments better and automate them with Flux, but also I'm going to talk about how you can take advantage of the Terraform controller. And I am Priyanka Ravi. I also go by Pinky. I'm a developer experience engineer at Weaverx. And I like dressing up my dogs and making them wear Flux gear. And so if you're not familiar with Weaverx, we're a company that's funded in open source. Founded on open source, sorry. So we're open source first. We have a bunch of different open source tools. The ones you probably heard of most are Flux and Flagger, which recently graduated, so we're very excited about that. They're CNCF projects. And we also have a bunch of other open source tools as well. So if you're not familiar with GitOps, I just wanted to give a brief intro to get us all on the same page. GitOps is an operating model for cloud native applications such as Kubernetes. But it's not limited to Kubernetes as you're about to find out. And you basically utilize a version-controlled system. So most commonly Git, hence the name GitOps, as a single source of truth. But you're not limited to Git. With Flux, you can use other truth sources as well. And you can enable continuous delivery through automated deployment, monitoring and management by a version-controlled system. And the idea is that you manage your applications and infrastructure declaratively. So these are the GitOps principles. And these were compiled by the GitOps working group. And you can find them at opengitops.dev. And there are meetings that you can attend with the GitOps working group. So if you go to that website, you can actually find more about it and attend those monthly meetings. And you can be more involved with the community. So the first principle is that a system managed by GitOps must have its desired state expressed declaratively. So everything is written through code. And that's kind of why GitOps and Flux work so naturally with Kubernetes. Because Kubernetes is, in itself, very easy to use through a declarative nature. And so the second principle is that it's versioned and immutable. So desired state is stored in a way that enforces immutability versioning and retains a complete version history. So that kind of covers your audit trail as well. So there's no sneaking in a change or anything like that. And then software agents automatically pull the desired state declarations from the source. And they continuously observe actual system state and attempt to apply the desired state. So in this case, we'll be talking about Flux as that operator. And so you have that continuously listening. And whatever is written in code is what's actually deployed out in Kubernetes or elsewhere. So why? Like what are the benefits of GitOps? So GitOps has better security, velocity, and reliability. So it just enhances the developer experience as well. So everything's automated. And you're not stuck at work on a Friday trying to deploy the latest change. I've been there. So then let's move on to Flux. So Flux is actually the tool that the term GitOps was coined for. So our CEO at Weaverworks is the one that coined the term GitOps. And what happened was it was actually created internally at the company because we had some outages. And it took time for things to come back up. So Flux was created. And then we realized that other people started pulling it and using it once it was open sourced. And so that's when it was donated to CNCF to further grow the project. And so it's a Git-centric package manager for your applications. And it's a set of continuous and progressive delivery solutions for Kubernetes. So it was really created with Kubernetes in mind. So it works with everything that you're probably already using, the common Kubernetes tooling you're already using. And we have some things we like to say about Flux. We say that it provides GitOps for both apps and infrastructure. And like I mentioned a second ago with the progressive delivery solutions, you can also use Flux with Flagger to do progressive delivery. So AB rollouts, canaries, feature flags, whatever. You can just push to Git. And Flux does the rest. It's as simple as setting it up on your cluster and then just walking away. And every time you make a Git change, it takes care of everything for you. And like I said, it works with your existing tools. It was created with the ecosystem in mind. And it works with most everything you're probably already using. And it does multi-tenancy. And as we like to say multi-everything, it can do soft multi-tenancy. So namespace multi-tenancy. It can also do hard multi-tenancy with multi-cluster. And it alerts and notifies. So you can actually set it to tell you on Slack when a change has been pushed and actually applied. And then so I didn't mention this until just now I just remembered. I actually started my journey with Flux as an end user. I used to work at State Farm, an insurance company in the US. And we were trying to implement GitOps at the company. And so we, for our Kubernetes platform, chose to use Flux. And so that's how my journey began with this. And now, obviously, it's my job. But I do really love Flux. And that's why I decided to come here and get involved with the community. And as a user perspective, it really is very awesome the community to work with. Everyone's super helpful. We do have a channel on the CNCF Slack called Flux. And we're very active there. So if you want to come chat with us. OK, so the benefits of Flux are very simple to GitOps. It reduces developer burden. You don't have to worry about cube control versions to interact with your cluster. It's extensible. So it's very modular. So if you want to tailor your experience with it, it's really easy to do. And I'll mention that with the controllers. But it comes with out-of-the-box support for Customize and Helm. And like I said, it's designed for Kubernetes. So Flux is actually a set of Kubernetes controllers. And if you're not familiar with Kubernetes controllers, they just manage the lifecycle of objects on Kubernetes. So you can create objects. You can destroy them. You can update them, things like that. And so yeah, so the source controller is it basically fetches artifacts from the source. So like I mentioned earlier, you can use multiple sources. So there's Git repositories. There's S3 buckets. There's Helm repositories. Helm repositories, OCI registries. There's a few things you can use. And it'll look there. And then it grabs all the YAMLs or whatever terraform and stores them. And then the Customize controller then goes and applies manifests. And it runs the manifest generation using Customize. So that's why it's called the Customize controller. This used to cause a lot of confusion. But it is actually using Customize in the back end. So if you already have a Customization.YAML in the folder that you're pointing it to, it will just take that and apply whatever is there. So whatever overlays, whatever resources you have listed there, it'll apply them. But if you don't have one, it will recursively search through your folders and apply the YAMLs that it finds. And it creates its own Customization in the back end. So that's why it's called that. And then the Helm controller does deployment of Helm charts. And it's using the True Helm API. So it actually does do a Helm install. So if you wanted to also use the Helm CLI to then look up your resources later, you still can. You can interact with it that way. The Notification controller handles inbound and outbound messaging. So it can be set up to notify you on Slack, like I mentioned, or whatever messaging system to tell you that, hey, this has been updated and deployed, or hey, somebody went in and deleted something that it's not supposed to be deleted, and some drift was detected. It can notify you that way too. But it can also do the opposite, where you can set up a webhook and say, so the way that all these controllers work is they're running on an interval that you set. So we call it reconciliation when they run. And so if you have, say, the source controller to pull only every 10 minutes, or even later, and then you actually make a change, you might not want to wait 10 minutes if you get unlucky, right, and have the full wait time. So you can set up a webhook to tell the notification controller that it will ping the source controller, hey, go pull this change. A change was made, and it'll do it right away. And then we have the image controllers. So the image reflector controller is just looking at an image repository and looking for any changes, any new versions. And then the image automation controller actually pushes back to Git, and it can apply the YAML to say, hey, a new version is out there for this image, go update it in the YAML. And so it'll push that change back to Git, and that way it's automated in that way. And you can also version it, so you can say like Sember, you can say only within this range, like you don't want major changes maybe being pushed automatically, that might not be the best. And then also Flux works with a lot of other tools, like I mentioned, these are just a few, and just listing some reasons that I as an end user really loved Flux. And so now let's talk about the Terraform controller. So the Terraform controller I think has been around maybe for half a year now. And so it was created to allow you now to manage things beyond even Kubernetes. So anything that you can Terraform now can be also GitOpsed. So it's a free and open source software Flux controller, like so it's not within the Flux project. So if you go look at the Flux project repo and look at the controllers, it will not be bootstrapped for you, but it can be installed through a home chart, which I'll show in a second. And like I said, not limited to Kubernetes anymore. And then these are some links where you can find information about the Terraform controller, including the docs that are really good for like how to get started and it shows a lot of the ways to use some of the features of the Terraform controller as well. And so the benefits of the Terraform controller are that now you can do full GitOps automation for your Terraform resources. But you can also, how many of y'all are already using Terraform? I'm guessing a lot of people in here probably, yeah. Okay, so if you're familiar with Terraform, like the usual way of deploying things, you usually do a plan, then you check the output, right? And then you apply. So you can still do that with this if you don't want it to do automatic deployment applications. So you can set it to do manual applies and that way you can even have it output to a config map. So you say human readable in a config map and then you can output the config map and see it'll look just like what you're used to with the pluses and minuses. And then you can apply it. So another use case is if you're already doing a pipeline approach for your Terraform and you don't fully wanna commit to this version yet, like this way of doing things, but you like the idea of getting drip detection, you can set it up so that it still monitors your Terraform resources. But then don't have it do the applies and you can tell it to notify you in Slack if for some reason things get out of sync. So that way if for some reason someone goes in and delete something, you will get pinged and notified that like, hey, it's out of sync and then you'll just have to go in and apply it, but at least you're aware. And it does check your live state. And so it can be used basically as a glue for Terraform resources and Kubernetes workloads. So these are some of the features of the Terraform controller. And it's really changing all the time. It's continuously being worked on and added to. But like I said, you can do manual and auto approvals. Drip detection I already mentioned, it can accept a list of config maps and secrets as variables. And so the state file is stored in a secret by default, but you can set your own backend. So if you're using an S3 bucket right now as your backend, you can keep using that. If you're using Terraform Cloud or Terraform Enterprise as your backend, you can keep using that. Whatever you're using to store your state. But yeah, so it also has health checks enabled. So you can do things like, you can also do things like depends on. So you can tell one module to wait for the other one to complete and apply. And it'll wait till the health check is passed to then apply the second one. And you can also destroy resources on deletion. So that's not the default. If you're familiar with Flux, Flux has a flag called prune. And if you set prune to true, then it will destroy your, like when you, if you remove a YAML, it'll actually also destroy the resource. But that's not the default. So just so you're aware, you can add a flag to destroy resources on deletion. And you can also write the outputs to a secret and then use it. So like I said, if the second one depends on the first one, you can then output this output, set the outputs to a secret, and then use it in the second one. And then recently, maybe not recently, but the most exciting thing I think that more recently has come out of the tariff and controller is concurrency. So you can, it now uses runner pods. So they tested it with, I think 1500 concurrent modules and it handled it very well. And so, and with that, it also allows you to customize the runner pod image as well and other things with the runner pods. But you can also set how many runner pods you want to run concurrently with it. And then just like flux, you can use OCI artifacts as a source. And it also has the ability to force and lock Terraform state as you know, things happen. And like I said, you can use Terraform Cloud and TFE as well. There's integration built in for them. Okay, so I'm gonna be showing, I'm not gonna be doing a live demo because they scare me, but I just deployed it a couple of days ago where I have a, I have two modules, two Terraform modules. One is a setting up an EKS cluster and the second one is going to configure it. And what it does is this. So second one configures it, but adds no groups and also users. And obviously I want the cluster to stand up first. So it's gotta depends on, I'll show you. I'll just show y'all, it's easier. So I just wanted to mention this is the getting started guide for the Terraform controller. So this is a good place to start, but I will show you how I did it. So the way that flux works is, or the best way to get started using flux is through a CLI command called bootstrap. So flux has a CLI, that's one of the ways to interact with flux. There's a few ways I'm gonna show, but bootstrap is really, really good because you run it and then if the repo that you're telling it to bootstrap to doesn't exist, it will actually create it for you. And then it'll create this flux system folder and it'll put all the manifests that flux needs there. And the other thing that's good about it is that, let's say later on, I want to upgrade to the newest version of flux, then I can just update the flux CLI to the latest version and rerun the bootstrap command and it'll go in and it'll update all the manifests to the newest version so it's item potent, it's pretty cool. Okay, so what that does is it creates these three middle files. And so if I go to GOTK components, this one has like everything that flux needs to run. It has like the flux system namespace, which is where all the controllers get installed. And then it also has all the controllers in here. And it has like the cluster role bindings, everything that's necessary in this large file. And then there's a customization.yaml. So if you're not familiar with customization, this is what it would look like to say I want to apply these files. It's a very simple use case of the customization. And then GOTK sync is what's actually allowing flux to basically manage itself. So this is like eating its own dog food, I guess. So the top part here is the source. So this is telling the source controller to listen to a Git repository. And it's saying this is the URL and it's pulling manifests every one minute. So every minute it's going to check for any changes. And then the customization is looking for files that are within this cluster's kind path and it's applying it every 10 minutes. And when the source controller finds a change in like a different commit shot, it actually kicks the customization controller to also reconcile. So if you do make a change, you don't have to worry about reconciling both. And like I mentioned, prune is set to true. So in this case, if I deleted a YAML, it would also delete the resource. And then I went in and I added in apps. I added the Terraform controller in this way. So it's through a Helm repository and a Helm chart, Helm release, which installs a Helm chart. So the Helm repository is telling the source controller, hey, go look at this Helm repo and pull every one hour of the charts that you find there. And then the Helm release, this is how you would then tell it to apply this specific Helm chart. So in this case, it's got the version and you can also put the values here as well. And then I also installed the, so we go, we've getups, is our free and open source tool for a UI around flux. And so this is how I installed that as well. This is also through a Helm chart. And as you can see here, this is like a better example for showing how you can just input the values to the Helm chart through here. And then, oh, sorry. Oh no. Sorry. And then that installs this. I have to, oh, yeah. So, and this is the, so this is the UI you can get with flux. And it's going to have your applications, which is where your customizations and your Helm releases and things like that will show up. And then the sources as well in this folder, it'll also show all the like flux controllers and their status and everything that like flux has installed. And so, yeah, that's this UI. There's also another way to interact with flux as well, which is the BS code extension. I don't know if y'all can see that, but I just wanted to show it real quick. So there's this extension. You just can look up GitOps, and it should be like the first one, but I think it's GitOps tools for flux, or for, yeah, flux, Kingdom's Notting. So, yeah. And it's taking a second, but it will load all the, we'll come back to it and it'll load all of those. And there it is. When I said I was going to leave it. So it'll load all the sources, and then you can come in here and you can also reconcile and suspend them here. As with the UI, I didn't show it, but there's also a button in there. And so this is really cool if you have developers that are developing and then also want to just make the change go straight to flux, then they don't have to wait either, I guess, if they don't have webhooks set up, and they can just come in here and make the change. There's a lot of other cool features on this as well, but there have been talks done on it by Kingdom, so go check those out. Those are really cool if you're interested in it. Okay, so back to this. So the way that I get the Terraform controller to work is I, let me go to, so I have these, let me go here. So I have this Terraform object, so it works the same way as like the customization controller or the helm controller in the fact that it's looking for an object called Terraform with a map of how to actually deploy the resources. And so in this case, I have this kind Terraform, I named it TFC, we go demo core, and then I have this section down here, which is telling it, this is how I'm interacting with Terraform Cloud. If you're using a different backend, it's also very simple, it would be like, I think it's just backend, and you put in the, there's good examples on the website as well. But yeah, this is, the way, the cool thing about this one, this section, if you're using Terraform Cloud, is that you can, if the workspace doesn't already exist, this will actually create it. So in this case, I had it create my workspaces and it works. And also if you're familiar with Terraform Cloud and you don't have, I mean, if you work Terraform Enterprise, then you know that there's no real way to tell it, this workspace depends on this one. You can't have it like wait for one workspace to finish its run before doing the next one. You just have to wait for the first, the second one to fail while simultaneously and then rerun it after the first one's done. I know from experience. So this is the first one, right? We have this core and then down here I have this config and there's a line in here that says depends on. So that's what's gonna force this second one to wait for the first one. And then I have this in the first one, I have this write outputs to secret. So I'm telling it to write these outputs and I'll show you in a second, but that's actually writing out the subnet IDs for AWS. And so for the cluster, and so if I go down here, I can then say vars from and input the subnet IDs to this one. So yeah, it's pretty nice. You can set in vars and yeah, you can customize it here. So then if I go back and I go to Terraform and then I think it's in here. Yeah, so this is what the Terraform object is pointing to. And if I go in here and I go to main, it's pointing to another set of files. I was trying to be organized. And but basically it's just creating an EKS cluster, which is outputting in the outputs. It's outputting the subnet IDs, which are then getting used. And then if I go to config and I go to main.tf, it is setting up a node group. It's setting up identity and stuff like that. So let me go back. So if I go in here and I go to my clusters, this is the one that was stood up by this demo. If I go in here and I go to, oh, I have to, oh, that's cause I haven't, hold on, hold please, let me do it all again. WS, take a second. So if I go here, I can see the cluster that was stood up and I can go to compute and I can see the node group that was created by that second one. Oh, and I can also show, I think it's, yeah, lost my phone yesterday. So I was trying to look for that. So if I look here, so these are the ones that were running and the config was waiting on the core to finish and it took its time and then it didn't. I think that's everything I wanted to show. So I'll open it up for questions. Authority, no questions? Yes, yeah. Yeah, so Flagger's actually under the Flux project group and it is, are you already using Flagger? Oh, okay, so Flagger allows you to do progressive delivery and continuous delivery, yeah. And, well, progressive delivery, sorry, my brain. And yeah, so you can do canary deployments, you can do AB rollouts, you can do feature flags, you can do a bunch of things with Flagger. I personally have never actually used it as an end user, but I've gotten feedback from other end users that are using it and it works really well, yeah. You don't, it doesn't have to only be used with Flux though. So it can also be a standalone application as well. Any other questions? Thanks. Thank you.