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, we are now at the stage where we can start tweaking and editing the cluster manifest files which are version controlled within our Cloud Academy GitOps Demo repo. And then watch the Flux operator go about keeping everything con sync. This is really where the magic starts to happen and what makes GitOps very cool. Okay, I'll copy the clone URL from the Cloud Academy GitOps Demo repo and then jump back into the terminal and perform a git clone line so. Jumping into the GitOps Demo directory I'll quickly display the structure using the tree command. Next, I'll open the current directory within Visual Studio Code like so.
For the first change I'll open the deployment.yaml file. And then jump down to line 44. Here I'll increment the application version, changing it from version 1.0.3 to version 1.0.4 and then save the file. I'll jump back into the terminal and perform a git status followed by a single line git commit and git push to push the updates back into the repo using the following command. Git commit -a -m with the message updated version number, double ampersand, git push.
Note, the version number I just incremented is unrelated to the docker image version number used as part of the image tag. Next, I'll simply start up a watch command to send a new code request every 10 seconds to the front end server snow port that we previously used. Now, we can just sit back and relax remembering that the flux operator will perform a redeployment automatically for us when it detects a need to do so. Keep in mind that by default the flux operator is configured to check in on the changes every five minutes.
Excellent, flux has just detected a change within the configured CloudAcademy GitOps Demo repo and has re-applied the updated deployment manifest file resulting in a redeployment taking place within the cluster. This can be concluded since the version number has been updated from 1.0.3 to 1.0.4 which we made earlier and is now contained within the cool response. The flux operator is designed to automatically perform this to ensure that the cluster state is in sync with the resources declared and managed within the source of truth system, the Git repo.
Okay, in the next demo I'll take this one step further by updating and pushing a new version of the flask app container image to the docker registry. Again, this should create activity within our GitOps setup.
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, Azure, GCP), Security, Kubernetes, and Machine Learning.
Jeremy holds professional certifications for AWS, Azure, GCP, Terraform, Kubernetes (CKA, CKAD, CKS).