 Hi. My name is Pirankaravi, I also go by Pinky. I am, thank you, I did the same thing in Valencia. So I'm a developer experience engineer at Weaverx, and if you're not familiar, oh, and dog mom to two rescues, and I forced them to pose for me. So if you're not familiar with Weaverx, it is founded on open source. We created Flux and Flagger, which are CNCF-donated projects, and we have a bunch of other projects within the CNCF, along with several additions that we've created for, like, as additions to Flux for GitOps, such as Weave GitOps, the Terraform controller, which we're going to be talking about today, VS Code extension, and several others. Okay, so I know they already kind of went over this, but just, you know, for anyone that just walked in or people that are watching this later in the recording, what is GitOps? Did I, I think I might have, sorry, I moved in. Okay, I think it'll come back, so, no, no, there it is, it's back, thank you, Scott. So I just want to highlight that, like, what is GitOps? It's an operating model for cloud-native applications, such as Kubernetes, and I do want to mention that it's not just for Kubernetes, so if you are doing a multi-cloud infrastructure, you can still use GitOps, but we're here talking about Kubernetes, so I'll be focusing on, because we'll be focusing on Flux. So GitOps utilizes a version-controlled system, most commonly Git, as the single source of truth, and it enables continuous delivery through automated deployment, monitoring and management by a version-controlled system, and with GitOps, like they mentioned earlier, you manage your infrastructure and applications declaratively, so they went over the GitOps principles earlier, so I'm not going to go over them in a lot of detail, but just wanted to point them out again here, like they mentioned, they created these, the GitOps working group created these GitOps principles as guidelines by talking to several end-users and coming up with these best practices. Briefly, everything should be declarative, everything should be versioned and immutable, things are pulled automatically by a software agent and continuously reconciled as well. So you get away from configuration drift, everything's written in code, so it's reusable, you have an audit trail, and because it's versioned and immutable, there's no sneaking in a change, and keep in mind that these are just a set of best practices, if you don't already meet these, you can still get started using GitOps, everyone's journey looks different and you can always, you know, tweak it to add hardening later, so why GitOps? Why should you even, you know, want to do this? I'm sure if you are here, you'll probably already know that there's a lot of benefits to GitOps, but because of GitOps's tools, unique way, ability to treat everything as code, it creates a direct impact on security. For example, if all configuration and security policy is treated as code, then everything can be held in version control. So any and all changes that are made can be reviewed and input into an automated way. And so there's no manual processes, hopefully you're less likely to be at work on a weekend because of some, you know, mistake that someone made when they're doing a manual deployment. So now we'll get into what is Flux. So Flux is a Git-centric package manager for your applications, but Git isn't the only source that you can use with Flux, and it provides a set of continuous and progressive delivery solutions for Kubernetes. It's a natural extension, it was really created with Kubernetes in mind, so it's a natural extension of the benefits of Kubernetes, and at the core of it, it is continuously monitoring your version control system, and it applies the desired state that's been expressed declaratively there. The nice part of this is that you don't have to worry about configuration drift because it reconciles on a set schedule, so if things for some reason have gotten out of sync, it will set it back to the desired state. And it really reduces developer burden because, like I said, it removes the need for manual deployment processes as well. And also the Flux CLI is a really convenient way to bootstrap the system in a cluster and to then access the custom resources that make up the API. So these are some things that we like to just highlight about Flux, and the key things that we point out in our website about Flux. Flux provides GitOps for both apps and infrastructure. You just, using Flux and Flagger, you can actually do progressive delivery with Canary's feature flags and AB rollouts as well. Flux can also manage any Kubernetes resource. Infrastructure and workload dependency management is built in as well. Also, you just Git push, and Flux does the rest. Flux manages deployments through automatic reconciliation. Flux works with your existing tools because, like I said, it was created with Kubernetes and all your, like, ecosystem in mind. It works with your Git providers, GitHub, GitLab, Bitbucket, and you can even use S3-compatible buckets as a source, Helm repositories, all major container registries, and all CI workflow providers. It also works with any Kubernetes and all common Kubernetes tooling, such as Customize, Helm, RBAC, and policy-driven validation like OPA, Kyverno, Admission Controllers. So it really just falls into place with what you have set up already. It does multi-tenancy, and as we like to say, multi-everything. It uses true Kubernetes RBAC via impersonation and supports multiple Git repositories. Multi-cluster infrastructure and apps work out of the box with Cluster API. With Flux, you can use one Kubernetes cluster to manage apps in either the same or other clusters, spin up additional clusters itself, and manage clusters, including lifecycle and fleets as well. Flux also alerts and notifies. It can provide health assessments alerting to external systems and external events handling. You just get pushed, and you can get notified on Slack and other chat systems. Users trust Flux. I myself am actually my experience with Flux and why I'm even here talking about it besides being a developer experience engineer at WeepWorks now. I, before that, was actually a GitOps platform engineer at a very large company, and we set up GitOps on our Kubernetes, on-prem Kubernetes platform there. So that's my experience with Flux, and I'm a huge fan of Flux, and it was super simple to set up for us. And there's a really awesome community. I feel like this community is one of the best I've ever worked with. We also welcome contributors of any kind. The components of Flux are on Kubernetes core controller runtime, so anyone can contribute, and its functionality can be extended very easily as well. All right, so what are the benefits of Flux? So Flux is, like I said, it reduces the developer burden by, it removes the kube control problem. You don't have to worry about kube control versions anymore to be able to interact with your cluster. It's also very extensible, it's versatile, it works with existing tools, it's really flexible, and because of the microservice architecture, which I'm about to mention in a second, it, you can pick and choose what you want to tailor your own experience with Flux. So Flux is a set of Kubernetes controllers, and so it's, if you're not familiar with controllers, a controller handles the life cycle of objects in Kubernetes, like what should be done when an object is created, updated, deleted, et cetera. And so these are the controllers, and the main controllers, so the Terraform controller is actually in addition to the Flux, I'll get to it, but the actual Flux controllers are the source controller fetches artifacts and stores them as, fetches manifest and stores them as artifacts, so that the customized controller can then apply the manifests, and it runs manifest generation using customize. I just want to mention real quick too, I know the fact that it's called the customized controller can sometimes be confusing, but it is named thusly because it's using customization in the background, so if you do have a customization YAML already set in the folder that you're pointing it to, it will just take whatever is written there and apply that. If you don't have a customization YAML set, it actually creates one in the background, and it recursively searches for your YAMLs in that folder path, and it will create its own customization and just generate all those, run all those manifests. And then there's the Helm controller, which controls deployment of Helm charts. The notification controller specializes in handling inbound and outbound events, and the image reflector controller reflects image metadata for the automation controller, which then updates YAML when new container images are available, so basically they both work together to update a Git repository when new container images are available. And it works with a ton of other tools, I'm not going to list them all, but these are just some that I thought to list out, and so basically, like I said, it will work with whatever you're using, basically, in your environment. And these are some reasons that I personally, as an end user and others that I've talked to, love Flux, it really does make life easier in my own personal experience. Multitenancy is super simple to set up, and I personally have only ever done soft multitenancy, so creating namespaces within a cluster, but like I said, you can do hard multitenancy, create additional clusters as well using it. Depends on as a cool feature, if you're not familiar with it, look it up, it's really cool. And then it's got fantastic helm integration. I mentioned notifications and alerts. Bootstrap is something that you'll see when I show the demo, and then the Flux CLI is really awesome as well. And now, the thing that y'all are here for, obviously, the Terraform controller. So what is the Terraform controller? The Terraform controller was created by Webworks, and it's a free and open source Flux controller that can manage Terraform resources. So it will not come when you bootstrap it, when you bootstrap Flux, or install Flux, but it is an additional thing that you can install onto your cluster. And Terraform resources that can be managed are not limited to Kubernetes resources, and if you want to install it, this is the GitHub link right here. And then there are some really great docs that are written as well. With this, specifically I wanted to point out this use cases link as well. Because if you go there, it's super detailed on different ways that you can use the Terraform controller. And then it has detailed instructions on how to actually set those specific resources up. So, okay. So what are the benefits of the Terraform controller? There's full GitOps automation, and you can use GitOps for existing Terraform resources as well. And you don't have to have it automatically apply your Terraform resources. You can set it to actually do manual applies as well. So you can read the plan and make sure it's what you want to have applied before applying it. Also, you can set it up to just do drift detection of Terraform resources. So let's say you're already, you have your Terraform deployments deployed in some way already, and you don't want to switch off from that. But you want to be notified if for some reason things get out of sync. You can set it up to do that as well, and I'll show that in a second as well. And basically, it's used as a glue for Terraform resources and Kubernetes workloads as well. So, these are some features of the Terraform controller. And I kid you not, if you check the docs within a few days, it'll probably already change because there's so many things being added to this controller daily. So keep an eye out for any new features there. So the first one, like I mentioned, you can set it up to do manual or auto approvals. And then drift detection, like I mentioned, is a really awesome feature. You can have it do that whether you want it to be doing applies or not as well. And then it also accepts a list of config maps and secrets as variables. Okay, and the state file is stored in a secret by default. So that's the default action if you don't already have somewhere that you're storing your state file. But you can override that with whatever back end you're using right now. So whatever back end you want to use to store your state file, you can. And then also, it has the ability to set up health checks. There's a flag that you can add to tell it to destroy resources on deletion. That's not the default behavior, just like it's not in flux. And you can write outputs to a secret as well. So if you need to use it later, you can write outputs to a secret and then use them somewhere else. Also, recently, fairly recently, I would say within the last maybe month or two, concurrency was actually added. So before this, it would do all the jobs right in the same controller, and it would just run them like one after the other. And recently, runner pods were added. So now it can do, I think the Terraform controller team did a test with 1,500 Terraform modules successfully, so that's really exciting. And so it's able to reconcile and provision high volumes of Terraform modules concurrently, greatly scalable. And with that, you can actually customize your runner pod as well. So if you have a custom image or something that you need to set, you can do that. And with Flex's new addition of OCI support, the Terraform controller was quick to follow. So the Terraform controller also can use the OCI artifacts as source and create OCI artifacts, all that jazz. And there is the ability to force unlock Terraform state if, for some reason, you need it. And lastly, we also have, it does play nicely with Terraform Cloud and Terraform Enterprise as well. There's integration with that if you're using that for your back end or whatever. Okay, and so before I go into my demo, I just want to mention that we have, these are the events that WeaveWorks is doing at KubeCon, GitOpsCon. So if you want, you can scan this QR code and get more information about what we're up to and things like that as well. So and check us out at our booth. We have a Flux booth in the project pavilion and we also have WeaveWorks booth as well. So please come talk to us if you want to chat with me about the Terraform controller as well. So now I have a demo, but I have to tell you all I am terrified of live demos, so I pre-recorded it and I'm going to talk over it because I do not want to tempt fate. So that's what's happening. So, all right. So in this demo, what's going on is my co-worker, Russ, actually created this awesome repository called Flux Vault Demo. And you can go fork it, you can go play with it. It's really awesome. If you, it just, what it does is it sets up Vault and it has a couple of, it sets up the, it bootstraps Flux, hang on. I'll just, I'll run the demo and then I'll talk over it and we'll see it. But, so if you run make, it, there's a make file in this project that, give myself a second to catch up. Okay, so in here, you can see it creates a kind cluster. Make sure that these environment variables are set. And then it just runs Bootstrap, which Bootstrap is a really awesome command within the Flux CLI to get started really quickly and easily with Flux. And it tells it which path, so that dash dash path is telling it to listen to in that repository Flux Vault Demo. It's saying listen to that kind folder. And the thing about Bootstrap is if you don't already have this repository created, it will create a repository for you in your GitHub. And then it'll Bootstrap into it. So it'll clone it down and put all the manifest that are necessary into it. And then run them and then have Flux listening to that repository. But if you already have that repository created in your Bootstrap into it, it'll just clone it and run the manifest that are already there. And the nice thing about Bootstrap is you can run it as many times as you want. So if you go and update the Flux CLI and then you rerun Bootstrap, it'll actually update to the newest version of Flux. Which is really cool. So you can see there, sorry, really briefly the pods that were set up. So those are the controllers. And so in here, you can see, like I mentioned, those YAMLs that are created by Bootstrap. Or in this case, they're already there. But so it creates this Flux system namespace, which is where all of those Flux components are installed. Creates a GOTK sync file, which is this file that has all of the, oh no, sorry, it has just the source that's created and the customization. And the source is telling the source controller to go listen to this Flux Vault demo repo. And that interval is saying every one minute, go check this repo for any changes and pull the manifests. The customization is saying go apply what's in that Flux Vault demo, but specifically in that cluster's kind folder path that we told it in Bootstrap. And that's going to be reconciled every 10 minutes. So it's going to go force apply what's pulled by the source controller there. And then in here, this is the apps.yaml that, so this is an additional customization that's then pointing to this base apps path within this project itself. And in that base apps path, we have the YAMLs for the Terraform controller. And it's pointing to the helm chart for the Terraform controller. This is my favorite way to set up. The Terraform controller is through the helm repository and the helm release. So this is kind of what I recommend to set it up. And you can point it to the latest version of the Terraform controller chart. If you're not familiar with Helm influx, this is how you set it up. You tell it to point to a helm repository, and then specifically to a helm release. And this is where you give the values that you want to override in the chart. And you point to the chart specs as well. And then this is saying every hour go apply this chart. So that's what's happening in here. And then, so also in here is Vault. So this is also setting up just the Vault instance. So the Vault namespace and then also Vault through the Helm chart as well. So this is using the Helm chart for Vault. And what we are using Terraform for, which is not set up yet. But so basically right now we just have a generic Vault instance that's running, but we don't have anything that's set up. Okay, so I am actually setting up a web hook so that I can set up notifications in Slack. So this is how you set up the notification controller. I don't make the mistake I did and push the secret with the web hook to get. Because it will delete your web hook in Slack. Slack is smart enough to know that if you've pushed a secret with the web hook to get, it will delete it. So that took me a little longer than I'd like to admit to realize. But I applied it as a secret so then I can reference it when I'm setting up the notification controller part. So I had it all commented it out. But yeah, so, okay, so this part. This is important because by default the notification controller is built for flux, right, just flux. So it's not actually listening to Terraform events by default. So these CRDs needed to be added to tell the notification controller to also go listen to Terraform events and things like that. So this is important to add if you are trying to set up the notification controller. Specifically for the Terraform controller. And then that's pull it pushed, so yeah. So this is the Terraform notification, like how it's actually set up. So you tell the notification controller which provider you want it to connect to, in this case, it's a Slack web hook. I have that secret ref that I pushed with the actual web hook. And then the alert is how you tell the notification controller, like, hey, alert me on this thing based on that provider. So I'm telling it to alert me on any Terraform events and any and all Terraform events and so that's what's happening there. Yeah, okay, so I'm gonna reconcile it. So this is how you reconcile when you make a change in Flux. So in this case, I'm reconciling the source and the reason I only have to reconcile the source in this case is because the source controller when it actually pulls in a new shaw will also kick off to the customization controller and tell it to go apply. If there's actually a change, so if there's not, it won't do that, but so. So now in here, I'm going to add this. So this is similar to how you add a customization or Helm release, it's saying, it's telling the Terraform controller, hey, go listen to this Terraform file path. And so, yeah, so, okay, so you say kind Terraform and then it's listening to that k8s ball config path and it's saying every one minute, go and apply it. There are a few things I want to point out really fast. Yeah, okay, I came back. Is this a proof plan and it's set to an empty string, which is how you would tell it to be manual applying. If you wanted it to do auto applies, you would say auto within that quote. Or I don't think if you just don't have it, I think it also would do the same thing. Also the store readable plan is also important because it's saying store my plan into a config map and human is just saying just the way that you're used to seeing a plan with all those plus signs and changes and everything. And then, okay, so this is what the Terraform is pointing to. So there is a, it's setting up the vault instance with all the back end and auth and everything and then it also creates this secret in here. This KV secret too. It's just a demo cred secret with some exposed credentials in there. Just some fun stuff. And so then once I reconciled this, it will then have that Terraform also added there. Okay, so I'm going to skip ahead a little bit. So now that that's actually there, it's not ready actually to be applied. So I can do this Qt control, get config maps to output the plan specifically to see it before we apply it. So this is what that would look like. If you're used to Terraform, you're used to seeing things like this. This is very familiar to you. And so, great, looks good. We love it. So I'm gonna go in here and you take that, there's a, sorry. It outputs a, so you see here where it says plan generated set it to the string. So I grabbed that and I put it in there into the, that quotes where it said approve plan. And I reconciled that. And so that's the way of approving the plan manually if you wanna go that route. So then I'm going to actually set it back to auto so that we can, I can show you like what configuration drift looks like and what the notification looks like real quick. So that's back to auto. We're gonna reconcile that. And now if we go into the instance of vault that was created, you can see that there's this demo creds that, you know, was created with that Terraform. I deleted it and if we go into that Slack channel that's being notified, you can see that there is a drift detected and it says that that cred has been deleted. And if we give it even, I think a second more, it will actually, it's back, it stood back up. So that's because we have that auto apply set. So it's continuously reconciling. And that is it, done. Thank you. Thank you.