 Flux is a mature open-source GitHub solution which GitLab is integrating into its GitOps approaches. The combination of GitLab and Flux supports a variety of options for configurations and topologies for the automation and management of your infrastructure updates. And it can also help you streamline your deployment processes to gain better collaboration among stakeholders in your organization, to lower your time to restore services or preempt and schedule production outages, to innovate and deliver value to your customers faster and to improve your compliance and always be audit-ready. In this short tech demo, we will show you how to bootstrap Flux and synchronize Kubernetes Manifests managed by GitLab. You can find the steps for this demo as a tutorial in our documentation. One of the prerequisites for this installation is to have a Kubernetes cluster up and running and accessible from a terminal window. As you can see, we have that in place already. The name of our Kubernetes cluster is Csevedra-FluxGitOps. Let's look at its running pods. All of the cube system pods are up and running. To authenticate with the Flux CLI, we must first create a personal access token with the API scope. So we navigate to my profile, access tokens window, and proceed to create one with API scope and name it Pat-4-Flux. I have already pre-created one, so let's cancel out of this window. Within the group Flux GitOps, which I pre-created, let's create a new project or repository and call it Flux-config. We will need this repository for bootstrapping Flux. But first, we need to install the Flux CLI. Since I'm using a Mac, let's use brew to install the CLI. Once the Flux CLI is installed, we need to create the environment variable GitLab underscore token and set it to the personal access token we created earlier. I have already done this, so let's move on to the next step. Now we bootstrap Flux and pass it the location of our GitLab repository, Flux-config. As Flux initializes, it populates the repository with its configuration manifest to manage itself from it. The bootstrap will also install Flux on the Kubernetes cluster and create a project deploy token to access the Flux-config repository. Checking the pods of the cluster, we now see that there are a few new pods in the Flux-system namespace. Heading over to the Flux-config repository and drilling into directory clusters slash my-cluster slash Flux-system, we see the Flux components and sync manifests that the bootstrap created. In this demo, we're going to demonstrate how to have Flux sync the manifests that are being stored and managed by GitLab. Let's create a new repository under group Flux GitOps and name it web-app-manifests. In the new repository, we create a new manifest file for an nginx deployment. We name the manifest file nginx-deployment.yaml and paste the contents for our Kubernetes manifest for an nginx deployment. Note that the replica's value is set to 3 in this deployment manifest. We now need to create a project deploy token so that Flux can access the newly created repository. From project web-app-manifests, we head to settings repository and scroll to the deploy token section and proceed to create a deploy token. We give it the name Flux-deploy-token and check the read-repository checkbox. Once we click on create deploy token, the username and password for the newly created deploy token are displayed on the screen. We save those two values for later use. Next step is to create a secret on the cluster using the deploy token username and password. We do this by running the flux-create-secret command from a terminal window. We can check that the secret was successfully created by running the following kubectl command. Now we need to configure flux-config to sync the web-app-manifests repository by creating two YAML files in the flux-config-clusters-mycluster directory. Notice that my-cluster only has one directory called flux-system at this point. From a terminal window, let's keep a watch on the pots of the cluster. From a second terminal window, let's clone the flux-config repository. We then head over to the my-cluster directory and proceed to create two YAML files. The first one will be a Git source pointing to our GitLab repository, web-app-manifests. Notice that this file uses a secret ref to refer back to the project deploy token secret we created earlier. Also, it specifies that every one minute the Git repository must be fetched. The second YAML file is a customization resource that tells flux to sync the manifest from our web-app-manifests repository with customize. Every one minute, the customization runs a server-side-applied-dry run to detect and correct drift inside the cluster. We commit these two new files to the main branch. On the right side terminal, we can see how Flux detects these two new files and brings the cluster to a new state, which includes three pots of NGINX as specified in the observed NGINX deployment manifest and their repository web-app-manifests. We take a peek into the Flux log to see that the updates to the Flux system took place. And finally, we refresh the GitLab window showing the contents of directory clusters slash my-cluster in the Flux-config repository and see the two new YAML files we committed earlier, the GitSource and the customization YAML files. The combination of GitLab and Flux can help you streamline your deployment processes to gain better collaboration among stakeholders in your organization, to lower your time to restore services or preempt and scheduled production outages, to innovate and deliver value to your customers faster, and to improve your compliance and always be audio-ready. Thank you for watching and until next time.