Explore the push and pull approaches in GitOps. Learn how to streamline software delivery using Git as the single source of truth.
TL;DR
- Git serves as the single source of truth in GitOps, storing all manifest and configuration files for complete versioning and rollback capability.
- Push-based GitOps automates deployment pipelines that trigger on code changes and push updates directly to target Kubernetes environments.
- Pull-based GitOps uses in-cluster agents that continuously monitor Git repositories and pull changes to automatically sync the desired state with actual cluster state.
- Harness supports both GitOps approaches: the CD module for push-based pipelines with automated triggers, and the GitOps module with agents for pull-based deployments.
While DevOps focuses on automation and speedy software development, `GitOps` is emerging as an implementation approach that aligns well with DevOps and is more equipped to simplify the complexity of advanced software delivery techniques. A software delivery approach where Git is considered the single source of truth, so it is easy to track changes and roll back in case of any failures. GitOps is gaining popularity these days because of tools such as ArgoCD and FluxCD. Today, we will try to understand what GitOps is and the push and pull approach of GitOps with some practical examples.
The Software Delivery Landscape
The software delivery landscape has made significant progress in recent years. There is a positive shift in how software is developed, deployed, and maintained today. Several key trends and cloud-native technologies are shaping the world of software delivery. The DevOps approach came a long time back; it holds a prominent space in software development, helping companies automate their software delivery with speed. This approach has gained immense popularity as organizations strive for increased agility, scalability, and continuous delivery.
The advent of serverless computing and containerization technologies like Kubernetes has further streamlined the deployment and scaling of applications in the cloud. Additionally, the demand for faster time-to-market has given rise to low-code and no-code development platforms. These platforms enable developers and non-technical users to build applications rapidly with minimal coding, accelerating the software delivery process and empowering citizen developers.
The widespread adoption of DevOps practices characterizes the current software delivery landscape, the dominance of cloud computing, be it hybrid or multi-cloud, the emergence of low-code/no-code platforms, usage of AI/ML in security tools, and the growing prominence of microservices architecture. These trends and technologies have revolutionized software development, enabling organizations to deliver high-quality software solutions faster and more efficiently.
Furthermore, the increasing popularity of GitOps has recently transformed how software is deployed. This article talks about this particular approach to software delivery. Enter GitOps!
What is GitOps And How Does it Works?
GitOps is a relatively new approach in modern software delivery. It has been mostly used with Kubernetes-related deployments where Git is considered the only source of truth for whatever you do. The easy learning curve makes it simple and approachable, and every developer knows Git. What do you mean when we say, ‘Git is considered the only source of truth’? It means that all your manifest files, configuration files etc, are stored in Git. The common GitOps approach works on the basis of the actual and desired state, whenever there is a change in the desired state (our Git repo) and the actual state (our target environment), the GitOps agent pulls the changes to make sure both the states are even. An agent keeps track of any changes made in the Git repository.
There are basically two GitOps approaches:
The Push Approach (aka the Pipeline Approach):
This is more closer to your classic CD pipeline approach that is automated. Whenever a change happens in the Git repo, the CD pipeline triggers and pushes the changes to the target environment.
The Pull Approach:
The pull approach has become a standard approach where tools like ArgoCD are used. Here, an agent keeps track of the changes happening in your Git repo, the desired state, and it automatically pulls changes to match the actual state of the system.
You can configure both approaches at Harness and speed up your software delivery game. Let’s see how both push and pull GitOps approaches work using Harness.
GitOps Push Approach Using Harness
When a developer or an automated process makes changes to the infrastructure configuration or application code, they push those changes to the Git repository. The changes are then automatically picked up by the CI/CD pipeline, which validates the changes, builds the necessary artifacts, and deploys them to the target environment.
An example of a push-based GitOps approach would be a team that uses a CI/CD tool to push changes to a Kubernetes cluster. You can easily create your deployment pipeline in Harness using the CD module. If you don’t have a repo to try, use this harnesscd example apps, where all the manifest details are stored in Git. You need to have access to a Kubernetes cluster from any cloud provider, as we consider Kubernetes as our target deployment environment here.
Signup at Harness and select the Harness CD module to get started. Follow the instructions in the “CD Pipeline” section of the “Deploy using Helm Chart” tutorial. You will create a pipeline first and then run the pipeline to see a successful deployment.
But this deployment wasn’t done in an automated fashion to represent the GitOps push approach. For this, we need to save everything and add the trigger. To make the deployments happen in an automated fashion, we can make use of ‘Triggers’.
Configure a ‘Push’ trigger so that the deployment should happen automatically whenever any code push happens to the main branch.
Now, the deployment pipeline gets triggered whenever any code push happens to the application repository. Let’s push/commit a small change to my repository by changing the deployment replica count.
Suddenly you will see the deployment pipeline getting triggered automatically.
You can also check your pipeline.
This way, the infrastructure and manifest changes trigger the pipeline and push changes to the Kubernetes cluster. This GitOps push approach can be easily configured using the Harness CD module.
GitOps Pull Approach Using Harness
Under the CD module, you can see the ‘GitOps’ tab, and that is where we start building a GitOps pipeline. It will be empty as we haven’t configured anything yet. As you click the ‘GitOps’ tab, you will notice your GitOps dashboard with details of applications, repositories, clusters etc.
A Harness GitOps Agent is a worker process that runs in your environment and performs GitOps tasks. You need to set up an Agent before you can set up a Cluster, Repository, or Application
In the GitOps settings tab, you start configuring and installing the GitOps agent needed first.
Click on the ‘GitOps Agent’, and the step-by-step self-explaining guide will help you with simple steps to install the ‘GitOps Agent’.
Once the installation is successful, you should see green checks against each parameter, as shown below.
Next, add the application you like to deploy with the GitOps approach. Fork this harnesscd example apps repo and use it to deploy the Helm guestbook application. [If you have already forked the repository, ignore this]
Add the repository name, and mention the GitOps agent and repo URL. In the source, add the details required as shown and continue.
The GitOps dashboard shows your application with the ‘SYNCED’ and ‘HEALTHY’ state. Immediately you might see the ‘UNSYNCED’ & ‘UNHEALTHY’ state of the app, and it might take some time to pull the changes. Configure automated syncing so the process looks smooth, as you don’t have to go and do the sync manually.
Now, if any of your developers push code and change anything in the application’s repository, the agent we installed notices that something is changed and immediately pulls that change to make the desired and actual states even. This is how easy to configure a pull based GitOps approach at Harness.
When to use GitOps pull approach
- Suitable for stable and controlled environments: If you have a more stable production environment where you want to ensure control and stability, the pull approach can be preferable. With this approach, the target environment periodically pulls and applies the changes from the Git repository.
- Automated verification: Pull-based GitOps allows for automated verification of changes.
- Rollback and auditability: The pull approach allows for easier rollbacks and better auditability. If an issue is identified after a deployment, you can roll back to a previous known good state by reverting the Git repository to a specific commit.
Conclusion
GitOps is revolutionizing the software industry with its powerful and efficient approach to managing and deploying applications. By leveraging the familiar and robust Git version control system, organizations can achieve remarkable speed, reliability, and scalability benefits. The future of GitOps appears exceedingly promising as more and more companies embrace this paradigm shift.
With its ability to bring together development and operations seamlessly, GitOps streamlines workflows, enhances collaboration, and reduces the risk of errors. As the industry continues to evolve, GitOps is poised to play a pivotal role in driving innovation and enabling organizations to rapidly adapt to changing market demands. Embracing GitOps is not just a trend; it's a strategic decision that paves the way for a fantastic future in the software industry.
