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 support@cloudacademy.com.
Learning Objectives
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
Intended Audience
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
Prerequisites
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
Source Code
The sample GitOps project code as used within the demonstrations is located here:
https://github.com/cloudacademy/gitops-demo
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.
- Okay, in this final demonstration, I'm going to update the cluster state manually by scaling up the front end deployment from one to four replicas. Now, by doing this, the cluster state will be out of sync with the state as hold and declared within the Cloud Academy GitOps Demo Repo. When flux detects this configuration drift, it should reappear by re-syncing the cluster state back to the state described in the Git Repo. Okay, lets begin. First, I'll run the command "kubectl get pods -n cloudacademy".
To examine the currently running set of pods, in here you can see we have a single pod consisting of the engine x proxy container in the "flaskapp" container. Next, I'll run the command "kubectl scale deployment/frontend --replicas=4 -n cloudacademy". Which will scale up the front end deployment replicas from one to four. This will cause configuration drift to occur.
After this, I'll rerun the previous kubectl get pods command but with added flag, "--watch". To watch any pod events that happen. Here, we should expect a number of pod termination events to take place. Since flux will trigger the cluster to re sync itself with the state currently held and described in the Git Repo. Remembering that this can take up to five minutes before the re syncing occurs. Excellent. You can see the termination events happening now. I'll rerun the same command but this time without the "--watch" flag. And, as expected, the number of running pods has returned to one. As per the declared state currently held in the Git Repo.
Rerunning the same command again you can see that this view has now filtered down to the just one running pod. Next, I'll scan through the flux logs and search for the occurrences where the re syncing takes place. By running the command "kubectl -n flux logs deployment/flux | grep configured". Here you can see that flux is internally using the "kubectl apply -f" command. To reapply the declared cluster configuration, currently held within Git. And that in this case the config met was unchanged, and that the front end deployment was changed. This addressing the configuration drift that we manually applied.
Finally, I'll jump back into my browser and examine the current front end deployment cluster config held in Git. As you can see, the deployment is currently set to have one replica and it is this particular city that has caused our manual scaling to be reset from four back to one. And all thanks to the flux operator kicking in and doing its job automatically.
Okay that completes the end to end GitOps demonstration. You've seen not only how to install GitOps using flux, but also how to work with it in terms of making changes and observing how those changes are automatically applied and synchronized in the 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, Azure, GCP), Security, Kubernetes, and Machine Learning.
Jeremy holds professional certifications for AWS, Azure, GCP, Terraform, Kubernetes (CKA, CKAD, CKS).