 Thank you for joining our talk to get ops Titans, one powerful solution, which is flamingo, and we are going to be chatting about how to combine flux and Argo. Hey everyone, my name is Joaquin Rodriguez. I'm a senior software engineer here in Microsoft. And my name is Priyanka Ravi. I also go by pinky and I am a developer experience engineer at we've works. So why should you care about get ops? There are three value props of get ops, which are security, velocity and reliability. Individuals teams and organizations who implement get ops experience many benefits, including stronger security guarantees. Because of get ops is tools unique ability to treat everything as code. This creates a direct impact on security. So for example, if all configuration and security policy is treated as code, everything can be held in version control. So any and all changes can be made reviewed and input into an automated pipeline, which means that there's no manual processes. So you're less likely to be at work on a weekend. And this leads us to increase developer and operational productivity. Developers can focus on things that actually matter to them, and it enhances the developer experience. So there's improved stability, higher reliability and consistency and standardization. And within the get ops space, there are two big giants. You might have heard of them. Their names are Argo and flux, and I'm going to dive a little bit into each before we go on to what flamingo is. So I'm going to be starting with Argo, which is a fantastic tool as well in the space. And there is an application dashboard in Argo. It is a powerful real time UI dashboard that provides a holistic view of your application and resources. There's also health monitoring and configuration drift detection built in. You can detect and get notified when applications become unhealthy or are for some reason out of sync. There's also multi cluster and multi tendency support. You can create sandboxes and establish guardrails across multiple clusters and namespaces using the projects tool within Argo. There's also advanced deployment patterns, such as it can support complex pipeline like deploys using pre and post sync hooks and sync waves as well. It's also a highly extensible tool. You can use customized resource actions, integrate any config management tooling and extend the UI to your preferences. It integrates into your existing environment really well. So it's REST, GRPC API and CLI enable seamless integration with tools that you're already using. So now let's talk about flux. Flux is get ups for absent infrastructure. You just push to get and flux does the rest. It's declarative, automated and auditable. Flux and flagger deploy apps with canaries, feature flags and AP rollouts. Flux can also manage any Kubernetes resource. Infrastructure and workload dependency management is built in. Flux can even push back to get for you with automated container image updates to get, image scanning and patching. You can describe the entire desired state of your system in get. This includes apps, configuration, dashboards monitoring and everything else. So you can use YAML to enforce conformance to the declared system. You don't need to run cube control because all changes are synced automatically. And everything is controlled through pull requests. So your get history provides a snapshot of transactions and allows you to recover state from any of those snapshots. It also is designed with security in mind. So it's pull versus push. So there's least amount of privileges. And it adheres to Kubernetes security policies and tight integration with security tools and best practices. You can read more about that in our documentation. It also is multi cluster and multi tendency and as we like to say multi everything. Flux can use one Kubernetes cluster to manage apps in either the same or other clusters, spin up additional clusters themselves and manage clusters including life cycle and fleets. It also works with any Kubernetes and all common Kubernetes tooling that you're already using. So it works with your Git providers such as GitHub, GitLab, Bitbucket. You can even use S3, compatible buckets of the source, all major container registries, OCI and all CI workflow providers. It also has support for customized helm, custom web hooks, notifications and RBAC and policy driven validation such as OPA, Kyberno, Admission Controllers. And it's really dropping with whatever you're already using. We also say that dashboards love Flux no matter if you use one of the Flux UIs or a hosted cloud offering from your cloud vendor. Flux has a thriving ecosystem of integrations and products built on top of it and all have great dashboards for you. And it's also created with Kubernetes controllers so it's very modular and malleable to your needs. So now let's talk about Flamingo. Flamingo is, like I said, Flux and Argo are both popular application deployment tools on Kubernetes with GitOps, but they both have different workflows and extensions. And so with Flamingo, which is the Flux subsystem for Argo CD, you can get the best of both. It is a solution that integrates Flux into Argo CD for a seamless GitOps experience with Kubernetes clusters. Flamingo is a drop in and noninvasive component for any Argo CD user to explore today. And you can check it out. So I've included the GitHub link here as well. And you can check it out and there's a lot of documentation on there. So why even, you know, why is Flamingo a thing? Why combine Argo and Flux? So Argo has a really awesome UI. It has great scalability and cluster management. There's a centralized control plane and there's the precinct and post-sync validations built in as well. Those are all great features and very valid reasons to use Argo. On the other hand, has helm release depends on rollback upgrades, dynamic config, helm values, helm hooks, retries and the Terraform controller. The biggest reasons that we hear people want to take advantage of Flamingo and use Flux with Argo is because they want to take advantage of Flux's helm controller and the Terraform controller as well. Which brings us into our next slide. So what is the Terraform controller? The Terraform controller is a free and open source Flux controller that can manage Terraform resources. These Terraform resources that can be managed are not limited to Kubernetes resources. So you can take advantage of GitOps for existing Terraform resources. And there's a feature within the Terraform controller that allows you to manually apply the Terraform so it'll run a plan and let you decide to apply it. And so you can actually take advantage of just drift detection of Terraform resources as well. So if you don't want it to be automatically applying your Terraform, you can have it notify you if something gets out of sync for some reason. So it's really a glue for Terraform resources and Kubernetes workloads. It accepts a list of config maps and secrets as variables and the state file is stored in a secret, a Kubernetes secret by default, but a back end can be set as well. There are also health checks and you can destroy resources on deletion. You can also write outputs to a secret, which Joaquin will show in a minute. And also you can run things concurrently. So there's a customizable runner pod that runs so you can customize the runner image as well. And it also allows you to use OCI artifacts as a source and you can force unlock the Terraform state if needed. And it also has Terraform cloud and Terraform Enterprise integration as well. So now I'm going to pass it off to Joaquin who's going to do a demo and show us all of these things in action. Thanks Pinky. Okay, so let's get started with the demo. So the first thing we're going to do, we're going to create a kind cluster. If you don't have kind, you can use K3D or you can use a cluster of your choice. Here on this example, I'm showing you how to install it. If you haven't done it so I already have a kind installed. And also you're going to need two things. You're going to need the flux CLI and you're going to need the plumbing CLI. In this example, I'm using brew so you can use the brew install commands to install flux and flamingos you can see below. Then I'm going to create a kind cluster. I'm going to name it Flamingo demo. It's going to take a few seconds. So now we have a Flamingo demo kind cluster. What am I going to do next? I'm going to install flux. There's other ways to install flux. You can use flux bootstrap, but for the simplicity of the demo, I'm just running flux install. Okay, now the next part is to install flamingo and we can verify that our pods are running successfully. You can see here that we have our Argo pot, which is flamingo and then we have our flux controllers installed. The next step, as Pinky mentioned before about the term terraform controller, we're going to have to install it terraform is not part of the flux project. So we need to install that additionally. So I added the steps here to solid be at home. So I'm just going to add that repository, which I think I already have. And now you can install the controller. Okay. After that, we can verify that the starting installed is going to take a few seconds to have the pod installed switch. It already happened. Okay, so now the next thing we're going to do is we're going to visualize the flamingo UI. But before we do that, we need to obtain the password. So I'm going to run the flamingo show in a password command, which is this. And then we're going to port forward so that I can active the UI. So you can just click here. That's okay. We don't have DNS right now. So as you can see, the flamingo UI looks almost identical to Argo. Essentially, we're running Argo. But with the flux system for Argo, we have additional things like we were able to visualize flux resources. So right now we don't have anything deployed, which that's what we're going to do next. So we're going to deploy a Terraform file. This file consists of two things. So here in our repo, we have a main.tf file, which all it does, it takes an input and it's going to output it into or eventually into a secret. And also here you can see we have our YAML that consists on customization. We have some RBAC, a service account. And then we have our setup, which consists of our Git repository. And also we have a Terraform object that will, in turn, will write the output to a secret. So let's do that. So what we're going to have to do. The first thing is we're going to do this manually using the flamingo UI. So we're going to create a new app. We're going to name that Hello World. It's going to be on the default project name. For now we want to sync this manually. We want to set up a few sync options, such as create the namespace, apply auto sync only, auto create flux resources. We want to use the flux subsystem. For my repo, you can see it right here. So I'm going to copy paste that. I'm going to change this to main, just to avoid some potential issues with the flux configuration. And then for the path, we want to do dot deploy. Cluster URL is going to be this cluster, and then we're going to put this in the dev namespace. So we're going to create it. And then we want to sync it. So here we have our two resources. We have the Hello World flux resource, which is a customization. And then we have our Git repo. So right now it's applying those changes. Terraform takes a little bit. More or less around three, four minutes. So let's wait a little bit for that to happen. Okay, so as we're waiting for this to finish, in the meantime, let's install the pod info application as an example. Now this one, instead of doing it manually using the UI, I'm going to use the Flamingo CLI. So you keep scrolling on instructions. On step six, I am going to install this pot info customization, which you can see here. And also we're going to install the pot info using Helm, the Helm release and Helm repository. So the first thing is I'm going to apply some YAML. And then I'm going to generate the app for Flamingo. And I'll show you that in a second how that looks in the UI. Okay. And now I'm going to apply the YAML for pot info Helm. And I'm going to generate my app. Okay. So let's go back. Oh, you can see the Terraform just finished. I'll come back to it. Let me just show you really quick how this looks like. So I'm going to sync my apps. Make sure they're okay. You can see here we have pot info Helm release and pot info customization. If we open the Helm release, you can see here that I can visualize the Helm release here. And also on customization, you can see the little flux icon. And we can see how our resources got deployed. So now if I go back to the Terraform that already finished, like I said, it took a little while to apply. You can see that Terraform resources got applied as well. We have our flux customization. We have our flux get repository. So now if I go back to step five and I apply this get secret, you can see that our output was generated. So that's all for the demo. The last thing I just wanted to show is that these are the resources. So if you would like to try the demo yourself, I just go to this GitHub repo and you will see the instructions that I just walk you through. This is Flamingo docs and this is Flamingo on GitHub. That's all. Thank you so much.