The Developer’s Guide to GitOps
DevOps simplified system management for both gitops and dev teams by introducing infrastructure as code (IaC). This helped define infrastructure, configuration, network, and every other system environment parameter as code.
The introduction of IaC made defining all system environments like, Kubernetes manifests, Terraform templates, and modules in a file easy, instead of manually creating your infrastructure.
However, IaC files are sometimes stored on the local machine of a developer or a central repository so that other team members can access it and replicate it on their local machine to work with. A typical DevOps engineer does create, test, and execute IaC files on their local machine. Changes made to IaC files are sometimes tested manually to confirm if the changes made are healthy for the infrastructure before replicating to the environment.
Software development with the use of GitOps is now very much better. With every software creation, testing, and deployment made, developers and DevOps engineers can easily keep track of the configurations and changes made. With the coming up of cloud-native technologies, the need to always automate, track, and continuously deploy codes arose. GitOps made it easy to know software development history, and GitOps practically has provided a great solution to the problems faced by developers and DevOps engineers.
Lets, go ahead and look into Gitops in detail.
What is GitOps:
In 2019 KubeCon, CloudNativeCon, a panel discussion, described GitOps as a “fast and secure method for developers and cluster operators to maintain and update complex applications running in Kubernetes.”
GitLab defined GitOps as “an operational framework that takes DevOps best practices used for application development such as version control, collaboration, compliance, and CI/CD tooling, and applies them to infrastructure automation.”
Weaveworks defined GitOps when it was first introduced in 2017 as ” a way to do Kubernetes cluster management and application delivery. GitOps works by using Git as a single source of truth for declarative infrastructure and applications,”
With all these definitions flying around, and everyone giving their definition of GitOps, some things are to be noted in these definitions – “Management,” “Deployment,” and “Automation.” GitOps makes managing our software easier than before. It gave an edge in development whereby the whole team can contribute, and each team or individual can input their side of the change they perceive is right. GitOps automation takes each change and automates tests, and gives each change’s result before the best change is approved to be deployed.
The summarized workflow in GitOps are:
- Operations practices with Git (like configuring, building, upgrades, etc)
- Using Git as a unique source of truth. e.g., IaC, Application Configuration as Code, System Configuration as Code
- Operations are done through the Git repository.
- Have first-hand development history and the ability to rollback or reinstall previous versions.
- Pipeline automation and continuous delivery
- Webhooks for pulling and triggering
- Merging, PR, and deployment
Applications in modern times are now being developed with speed and scalability in mind, and mature organizations can deploy a handful of code to production daily. These tasks are accomplished with the help of development best practices offered by the GitOps initiative.
GitOps Vs. DevOps:
DevOps has been in circulation and been introduced into the tech space since 2007 – 2008, while GitOps just came into knowledge in the year 2017, thereby making DevOps be what every developer, systems engineer, operations engineer, organization, business enterprise, etc. know. In contrast to GitOps, most professionals and corporate organizations are just learning or have yet to get their complete understanding. DevOps came around to improve team collaboration in software development and enhance application deployments. DevOps started becoming widely adopted as more cloud-native applications were rolled out and as technology advancements arose.
Now, GitOps is a complementary concept to DevOps, in other words, it acts more like an extension of DevOps. GitOps is more of a framework that improves the efficiency and collaboration of DevOps. It’s like implementing DevOps methodology on a different framework that makes DevOps get carried out smarter. But let’s keep in mind that DevOps and GitOps, though a bit related, still have some differences. DevOps is more like a culture mix or lifestyle for software development, operations, and tools that enable speed in the development and improvement of products. At the same time, GitOps only revolves around one particular tool – Git.
More like the Workflow of GitOps earlier stated, GitOps functions with DevOps workflow as thus:
- Developers checks into the code repo
- Configuration and building takes place
- Continuous integration and delivery
- Test, monitor, and fix
- Necessary upgrades are made
- If any mistake, rollbacks are done
- Automated deployments
We want to point out some more differences between DevOps and GitOps.
DevOps approach focuses on the continuous integration and delivery of development while the GitOps approach is through the use of the Git tool in infrastructure management provisioning and deployments.
DevOps uses a CI/CD pipeline as its primary tool, and configuration as code, supply management as other tools. In contrast, GitOps uses Git as its main tool and Kubernetes, IaC, and separate CI/CD pipelines as other tools.
DevOps is created mainly for automation and frequent deployments, while GitOps is principally created to help DevOps teams reach the same goals faster using established concepts, rules, and philosophy.
How GitOps work:
GitOps works with regard to certain steps. We’ll walk you briefly through these steps one after the other.
Take, for example, a developer on a team needs to make changes on a repository, the developer will issue a pull request to clone the IaC files (it’s better than tinkering with a running system).
After the changes had been made, a merge request is made, and this is where approvals take place. Git then automatically merges all the triggers and makes all changes to the environment including the infrastructure. If there is any configuration error, Git automatically updates it with GitOps automation and makes sure the environment converges to the predefined desired state. We are here basing the state of the infrastructure on the single source of truth in GitOps which is the Git repository.
In other words, GitOps allows having a checkpoint state of a reproducible infrastructure, Git is in the center of everything in GitOps.
Tools used in GitOps:
Like in DevOps, GitOps uses tools to make its workflows seamlessly smoother, faster, and automated. The popular tools that make GitOps unarguably easy are ArgoCD, FluxCD, and Jenkins X.
What is ArgoCD?
ArgoCD is a declarative continuous deployment tool used in Kubernetes for application deployment management. The tool was developed in 2018 under the Apache 2.0 license by Intuit. It has various features, including several synchronization options, status-checks, user-access controls, etc. Changes in application manifest in Git repo then tracked by ArgoCD starts the deployment process. Argo has multi-tenant and multi-cluster capabilities for deployments, and it synchronizes multiple applications of different teams in a single or various clusters.
What is FluxCD?
Flux is a tool that synchronizes Kubernetes cluster with the state of manifest in a Git repository. Flux is a very simple tool whereby it works with GitOps in very few steps. Flux runs in the cluster and mainly watches a Git repo update manifests in Kubernetes. Any changes made to the repo, Flux automatically applies it to Kubernetes.
The tool was developed by Weaveworks and later adopted by the CNCF project under an Apache 2.0 license.
Flux is easy to install and maintain with its sole focus on deployment, synchronization to Git repo, and registry with the current version of the cluster. When there is a code change in the repository, it applies it automatically to the Kubernetes environment.
What is Jenkins X:
Jenkins X is an open-source opinionated continuous delivery tool used natively in Kubernetes without worrying about the underlying infrastructure. Jenkins X is a major upgrade to Jenkins as it works better with technologies like Docker or Kubernetes. Jenkins X simplifies everything, and it lets you harness the power of Jenkins 2.0 and makes you able to work with a larger number of tools, including Helm, Draft, Monocular, ChartMuseum, etc.
Jenkins X, developed by CloudBees, is a full CI/CD solution built around GitOps. It has a GitOps based deployment capability and covers a larger spectrum of the software development lifecycle. Jenkins X sets up Kaniko and Skaffold to build container images, then uses Helm charts to package Kubernetes manifests. A jx command in Jenkins X will create Git repositories, create CD pipelines, and set Webhooks.
Differences between ArgoCD, FluxCD, and Jenkins X
|Flux is a single binary deployed pod; you have little to nothing to manage after installation.||It is managed in a Kubernetes native way. Argo runs on Kubernetes in it’s own namespace, and all it’s configurations are stored in ConfigMaps, Secrets and Custom Resources.||Jenkins X is managed by a GitOps workflow, in-which the internal configurations are tweaked by updating the config files in the development environment repository.|
|Flux is very easy to install; just like deploying a pod in a cluster. It supports installations on Helm Charts and Kustomize.||Argo is installed through Kubernestes.||Jenkins X is installed throug a ‘jx boot’ command|
|GitOps deployment being the main feature of Flux, it occasionally pulls a remote Git repository and applies the manifest files to the cluster should there be changes in the file.||It’s GitOps deployment is similar to that of Flux, and it supports manifests like Kustomize, Helm Charts, Ksonnet, directory of YAML/JSON etc.||A new version of Helm Chart gets created after a successful application build after a merge to master in the application repository, then this new version GitOps repository will be updated.|
|Flux doesn’t have a Multi-tenancy feature.||ArgoCD can handle many applications of different teams with a single instance.||Jenkins X doesn’t support multi-tenacy since there’s no isolation between applications from different teams.|
GitOps is a solution that makes development workflow easy and straightforward, its features are sometimes applied for some other uses unrelated to development. We have briefly described the common reasons and use cases why GitOps is used:
GitOps enables you to roll between versions of configurations or changes made in Git. In case, you are versioning your infrastructure, you will always have a single source of truth of its state.
GitOps enables teams to collaborate more on projects as this gives the medium for discussions, comments, suggestions, and approvals. The collaboration system allows manual gates, automated workflows, and approvals.
Compliance and Auditing
GitOps made permission and accessibility to be predefined. Only personnel with administrator access or quality control specialists are those that can give approvals. Any changes made have to be audited to ensure it meets compliance and regulatory standards before merging to a Git branch.
GitOps enables running and managing automated tests consistently to ensure the software meets the requirements before validating changes. These consistent tests are all-around, ranging from code integration tests, accessibility testing, functional testing, performance, etc.
Wildcard is a NoCode platform that provides a solution to help organizations, and developers, even those without DevOps experience or coding knowledge, to successfully implement and manage versioned infrastructure using NoCode CI/CD pipelines. It enables collaboration, auditing, and automation. You can use Wildcard to build, deploy, and manage applications without writing a single line of code. Start for free by singing using Github or GitLab.