- [Jeremy] Okay welcome back. Now that we know the basic properties of GitOps let's now consider what this looks like in terms of an actual architecture and deployment. As seen here the CICD system gets split apart such that only the continuous integration component remains with GitOps taking over the role of the continuous delivery component, albeit in a much more improved way. How is this achieved? GitOps promotes the role Git to the front and center of the build and deployment workflow. 

The entire nine cluster state is declared and stored in Git so the Git becomes the so-called system of truth. Nothing enters or is deployed into the Kubernetes cluster without first being declared. All of the declarative workloads are pushed into a Git repository and then a pull request is typically raised. From a Kubernetes perspective, when the designed cluster state changes within the Git repo, it needs to react and synchronize accordingly. 

For this to happen, GitOps relies on the flux operator, which Gits deployed into the cluster itself. Flux implements a control loop, which constantly pulls the Git repository and checks to see if new commits have been pushed and any change has been applied. In the case of a newly detected source commit, flux will trigger and ensure the cluster state converges to the current version the declared system state, and is now held in the most recent commit within Git. Flux also has the capability of pulling a container registry in which your container images may reside. 

In the case of detecting an updated container image, flux will search for and update any cluster manifest files stored within Git, which have been configured with null and custom flux annotations. These annotations instruct flux to edit and update them with the latest detected container image tag name. With the changes being automatically committed back into the Git repository. Flux will then re-sync the cluster state with the updated and most recent commit that it has just made, resulting in older container instances being replaced with newer container instances running the newer version of the container image that flux just detected in the container registry. 

This ensures that the current cluster state always reflects what is held within the Git repository. With these capabilities in place, it becomes almost trivial to restore or rebuild Kubernetes cluster, if disaster were to strike. If this were to happen, then a redeployment of the most recent commit held within Git would be all that was required to restore to the last known and proven working state. Additionally, performing rollbacks from current version to any previous version involves nothing more than a Git revert within the Git repository. The flux operator will then go about automatically synchronizing the cluster state. 

From a security standpoint, GitOps improves on a typical CICD pipeline setup since now privileges into the cluster are more controlled. Developers no longer need direct write access into the cluster. Instead, the GitOps flux operator performs the role of creating, updating, and deleting resources directly within the cluster, as per the declared state held externally within the Git repo. The GitOps approach also has the advantage of now not having to expose and manage cluster credentials outside the cluster itself. Instead, the GitOps flux operator is configured with a service account within the cluster and given just the right amount of privilege to fulfill it's requirements. 

For example, flux can be configured such that it will only operate on the name spaces within the cluster that its service account has been given access to. 

Okay, that concludes the slideshow on what a GitOps architecture and deployment potentially looks like. In the next lecture, we'll start demonstrating how to set up and install GitOps within a Kubernetes cluster.