GitOps is a methodology for deploying and managing software applications using Git. It is also referred to as "operations-as-code" or "code-driven operations," and it uses the principles of DevOps to streamline software updates across an organization. It basically uses a collaborative software development model involving Git and Kubernetes.
You can also define GitOps as the combination of Git and Ops, a practice where you use the principles of operations to manage your version control system. When we talk about version control, it’s mostly about code in a repository. GitOps takes this one step further by applying principles of operations on top of your version control system.
The term “GitOps” was originally invented and popularized by the engineers at Weaveworks and presented to the world of DevOps as a set of best cloud-native practices coupled with tools from Weaveworks to help developers operate the complex Kubernetes workflows via Git.
GitOps is a cloud-native practice for deploying software in which Git is used as a single source of truth for any deployment resources that happen in the system. Whenever any new deployment rolls out, developers are required to define everything through Git. With this approach, it becomes easier to automate deployments and helps in higher observability. This improves deployment confidence within the DevOps team and boosts overall developer productivity.
GitOps requires declaratively defining the resources through Git so that you can easily maintain the state of your resources. It encourages automating the deployments with minimal or no human interaction and access to roll back quickly to the previous state if something unexpected happens.
GitOps enables developers to push the infrastructure code into the environment repository and notice a change. GitOps performs the needed changes to the environment of the software and infrastructure, then moves it further into the CI/CD pipeline.
There are four basic principles on which GitOps works:
GitOps basically works on the principle of making Git the source of truth, including moving everything to code and storing and maintaining everything in Git. When it comes to deployment, make use of an operator to deploy what is configured in Git and Yaml in a declarative fashion. Since all the developers are primarily friendly with Git, GitOps simplifies their complex workflow.
So when it comes to Kubernetes, the app code, container images, and all related manifest files will be stored in Git, and any changes are made through Git as a single source of truth.
GitOps can have two deployment strategies: push and pull pipelines. The distinction between them is in the way we ensure the deployment environment matches the desired infrastructure.
CI/CD tools play a vital role here, and many use this strategy where the source code and deployment manifest files are stored in a single repository. Whenever a new update happens, the build pipeline triggers. The pipeline creates the container images and pushes the recent changes to the environment.
The container image and declarative configuration (that are written in YAML format) changes are pulled into the cluster from inside the cluster amidst the CD engine running inside the cluster.
DevOps workflows are:
In contrast, GitOps workflows are:
DevOps pipeline and GitOps pipeline
GitOps is a cloud-native approach where the entire software delivery process is centred on the usage of Git. In this tutorial, we will see how easy it is to integrate Argo with a Kubernetes cluster and deliver changes in an automated fashion.
We will be using Google Cloud to create a cluster.
First, we need to create a Kubernetes cluster to host our ArgoCD
Next, we need to create ArgoCD namespace and install all the manifest files onto the cluster that we created.
Download the Argo CD CLI
It’s time to access the Argo CD API server. We can do this by getting it as a service-type load balancer using the following command.
Go back to your cluster and the “services and ingress” tab to see the external load balancer.
Open the link, and you should be able to access the ArgoCD UI.
Now, you need a username and password. The username by default is “admin”, and the password can be generated using the below command.
Once you provide your login credentials, you should see your ArgoCD setup.
Let’s Fork a sample repo, for example, like this one found here: https://github.com/argoproj/argocd-example-apps
Once you fork the sample repo, go to your Argo CD setup and create a new app. Add the relevant details.
Once the app is created, it shows as out of sync in the ArgoCD UI and for that to become in sync, we need to click the ‘SYNC’ button and the app shows as healthy.
Now, just go back to your forked example repo and change something. Let's say you changed the guestbook-ui-deployment.yaml replicas from 1 to 2. What happens next? The app goes out of sync, and you need to again click the ‘SYNC’ button, and you should see everything getting updated itself through the pull strategy.
You can verify these changes by going to your cluster and seeing the new changes.
You can now see two replicas running.
First, you will need to sign up for a Free Harness Account and navigate to the GitOps tab.
Navigate to Deployments > GitOps from the side menu.
Harness will install Argo CD on your behalf and wire that Argo CD instance to Harness. All you need is a Kubernetes cluster. Now, we need to set up the required things to do GitOps as part of Harness.
Navigate to GitOps > Settings > GitOps Agents.
One by one, you will connect all the required GitOps settings shown below.
Once everything is connected and verified, you can start deploying applications via Harness GitOps. By taking the famous guestbook example, once the deployment is done, you should see your Harness GitOps dashboard as shown below.
We just saw how to use the GitOps methodology to deploy changes to our application. GitOps is already gaining momentum in the cloud-native space, and developers love this approach because of its ease of set-up. In addition, since Git is the primary tool used, the learning curve reduces significantly. Automation is the key to fast and reliable software delivery, and GitOps methodology comes in handy here.
While GitOps may not be the answer for everything cloud-native, I am sure this approach will soon take a prominent stage in the software delivery space. GitOps emphasizes the single point of truth approach by making use of the simple tool that every developer knows, which is Git. Used alongside cloud-native tools such as Kubernetes, GitOps can be an excellent path for achieving true digital transformation. GitOps is here to stay, and its future is bright and shiny. Implementing a proper DevOps process requires a lot of effort. Fortunately, GitOps is here to help.
Want to learn more about how GitOps accelerates application deployment? Chat with us today!
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.