If you work with Kubernetes, then GitOps is going to make your world a better place by enabling you to perform automated zero effort deployments into Kubernetes - as many times as you require per day!
This introductory level training course is designed to bring you quickly up to speed with the basic features and processes involved in a GitOps workflow. This course will present to you the key features and GitOps workflow theory.
GitOps defines a better approach to performing Continuous Delivery in the context of a Kubernetes cluster. It does so by promoting Git as the single source of truth for declarative infrastructure and workloads.
We’d love to get your feedback on this course, so please give it a rating when you’re finished. If you have any queries or suggestions, please contact us at firstname.lastname@example.org.
By completing this course, you will:
- Learn about the principles, practices, and processes that drive a GitOps workflow
- Learn how to establish GitOps to automate and synchronize cluster state with Git repos
- Learn how GitOps uses Git as its single source of truth
- Learn and understand how to configure and enable a GitOps workflow using tools such as Helm, Tiller, and Flux
This course is intended for:
- Anyone interested in learning GitOps
- Software Developers interested in the GitOps workflow
- DevOps practitioners looking to learn how to setup, manage and maintain applications using a GitOps workflow
To get the most from this course, you should have at least:
- A basic understanding of containers and containerisation
- A basic understanding of Kubernetes - and container orchestration and scheduling
- A basic understanding of software development and the software development life cycle
- A basic understanding of Git and Git repositories
The sample GitOps project code as used within the demonstrations is located here:
If you intend to repeat the same instructions as presented within this course in your own environment, then you must FORK this repository into your own GitHub account. The reason for this, is that you need to be the owner of the repo to be able to upload and configure a new Deploy Key within the Settings area of the repo. The Settings area of a repo is only available when you are the owner of the repo.
- [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.
Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.
He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, GCP, Azure), Security, Kubernetes, and Machine Learning.
Jeremy holds professional certifications for AWS, GCP, and Kubernetes.