[ad_1]
There’s a frequent misunderstanding about how GitOps needs to be utilized in real-world environments. Builders equate Infrastructure as Code (IaC) with GitOps in idea or imagine that GitOps can solely work with container-based purposes — which isn’t true. On this weblog, you’ll study what GitOps is and tips on how to apply its rules to real-world improvement and operations.
What’s GitOps?
GitOps is an operational mannequin that evolves DevOps finest practices (equivalent to model management, collaboration, compliance, and CI/CD) and IaC to carry out operations on infrastructure and trendy cloud-native purposes. It does this by placing descriptive code for cloud infrastructure or purposes into Git repositories for processing and model management, after which making use of these modifications to infrastructure by automation.
The 4 primary rules of GitOps are:
- System definitions are described as code.
- The specified system state and configuration is outlined and versioned in Git.
- Adjustments to the configuration may be robotically utilized utilizing pull requests.
- A controller ensures that no configuration drifts are current.
You possibly can study extra about these rules within the Introduction to GitOps with OpenShift publish on the Purple Hat Hybrid Cloud weblog.
The GitOps methodology has a number of benefits:
- Single supply of reality. All code is on Git, so there’s a single supply of reality for the infrastructure or platform.
- Straightforward rollback and quick restoration. All modifications to the infrastructure are model managed and reviewed so they’re straightforward to roll again if obligatory.
- Enhanced safety. All modifications are pulled and utilized by automation; this limits guide entry to the infrastructure and thus improves safety.
GitOps practices may be utilized not solely to traditional infrastructure like VMs, but additionally to Kubernetes, community config, utility definitions, and even assets that may be described by config information and utilized to the surroundings by automation.
The GitOps approach
Right here’s an summary of how GitOps works:
-
Declarative description. The declarative description of the infrastructure/utility as the specified state within the goal surroundings is key to GitOps. It additionally calls the whole lot as code, together with infrastructure, community, and safety. The declarative description code or configuration exists on a centralized Git repository as a single supply of reality for the entire system.
-
Make the most of the Git workflow as management. All operations are carried out by making modifications to code or configuration information in Git, so any modifications may be versioned, reviewed, or merged based mostly on Git’s model management system.
-
Separation of configuration and deployment. Automated course of are used to use modifications to the goal surroundings; the most effective observe is to make use of a pull-based deployment the place the agent/operator pulls and applies the modifications.
The next diagram illustrates a typical high-level structure for making use of GitOps in a single surroundings:
With GitOps, the applying supply code and declarative surroundings configuration are saved on Git with workflow help. On the event aspect, the developer modifications the applying supply code and merges the modifications after reviewing the pull request. The CI pipeline then detects the modifications and triggers the construct into an Artifacts repository. On the operations aspect, the SRE makes the modifications to the surroundings configuration within the Declarative Config Repo and merges the modifications after the overview course of. From an structure perspective, a brand new GitOps Agent element is launched within the goal surroundings to detect the modifications within the surroundings configuration repo, pull the newest configuration, and apply these modifications to the surroundings. The modifications are detected and pulled by the GitOps Agent, so there isn’t any want for an operator to entry the goal surroundings and all credentials are saved inside the surroundings.
GitOps in the actual world
Day-to-day operations in the actual world, nonetheless, may be difficult. For instance, how do you deal with harmful modifications which can be utilized to an surroundings? An incorrect change can destroy a naked steel server, which may end up in misplaced knowledge and modifications to the IP. How does GitOps work with completely different environments (equivalent to improvement, staging, or manufacturing)? How do you promote modifications to staging and manufacturing?
On this part, we deal with these questions and focus on how GitOps may be utilized to real-world operations.
Cloud useful resource lifecycle
In lots of circumstances, GitOps works nice with Kubernetes clusters because it naturally helps declarative deployment and immutable infrastructure. Nonetheless, real-world cloud infrastructures may be difficult and hybrid cloud can embody many various assets, equivalent to naked steel, traditional VSI, community gadgets, cloud databases companies, Kubernetes clusters, and containers.
Every sort of useful resource has its personal lifecycle. Think about that you’ve a Kubernetes cluster constructed on high of a number of VSIs, and the cloud-native utility that’s deployed as containers has the shortest lifecycle. The cluster could have an extended lifecycle than a VSI for the reason that employee node of a cluster is changeable over time. The naked steel server has the longest lifecycle of all of them.
As a result of there are completely different useful resource lifecycles, you can’t course of all of the modifications towards the complete stack by a single CI/CD pipeline or a single operation workflow. You have to use completely different methods when making use of GitOps observe to full-stack cloud assets.
Mutable vs. immutable
GitOps encourages you to work with immutable infrastructures and declarative containers, which signifies that after the deployment no change may be made to the infrastructure or the cloud-native purposes. Kubernetes takes immutable containers.
Nonetheless, let’s say you’re deploying an utility on high of a traditional infrastructure with restricted assets, and it nonetheless has an extended lifecycle. On this case, the GitOps methodology can nonetheless be leveraged to handle the infrastructure to take the benefit of GitOps, equivalent to versioned modifications over time and improved safety.
Push-based vs. pull-based deployments
Despite the fact that pull-based deployment is a GitOps finest observe that may guarantee higher safety, GitOps adopters aren’t required to make use of pull-based deployment. Nonetheless, in some conditions not the whole lot may be described utilizing declarative configuration and there’s no choice for utilizing a push-based deployment — for instance, to provision a cloud infrastructure utilizing instruments like Jenkins, Travis, or Ansible.
Assist for a number of environments
The outline above primarily describes how GitOps works with a single surroundings. Nonetheless, in real-world cloud environments (as with DevOps), you normally have a number of environments to help improvement, testing, and manufacturing situations.
The next diagram is a reference mannequin that illustrates how GitOps can work with improvement, staging, and manufacturing environments:
A typical technique is to arrange improvement, staging, and manufacturing environments for a system. With GitOps, you may arrange corresponding branches in a Declarative Config Repository so that each one three environments share the identical configuration repository. For every surroundings, there’s a GitOps Agent (a number of — see the Reference structure part) that pulls modifications from a staging department. For instance, the event surroundings displays and pulls modifications from the improvement department and the staging surroundings pulls modifications from the staging department.
The Git workflow is ready as much as help code overview, approval, merging, and testing. After the modifications are pulled by the event surroundings and move the mixing checks, then the identical modifications may be promoted to the staging department by creating a brand new pull request on staging. By doing an identical course of, a change made by a developer or SRE can in the end be pulled by the manufacturing surroundings.
Notice that this course of is only a reference mannequin. In real-world conditions, a mission crew might tailor this based mostly on structure selections made for the precise state of affairs.
Reference structure
With what you’ve gotten discovered, it’s also possible to outline a high-level reference structure to use GitOps practices to an IBM Cloud surroundings. This could look much like the structure proven within the GitOps overview, however the principle variations right here can be based mostly on real-world conditions. Within the diagram under, we’ve mapped the parts to a advised software program occasion.
Most significantly, this structure separates the CD processes for the CaaS and IaaS layers, since they will have very completely different assets and lifecycles. Based mostly on the character of the assets, completely different instruments are used for various assets. Extra particularly, we advocate putting in the GitOps plug-in on a Purple Hat OpenShift occasion. This ships an Argo CD occasion out-of-the-box to play the GitOps Agent function to deploy the modifications within the CaaS layer. On the IaaS layer, the IBM Cloud Schematics service implements GitOps practices by encapsulating the Terraform plug-in for IBM Cloud, which pulls the infrastructure modifications and provisions/updates a lot of the IBM Cloud assets.
Abstract
On this weblog publish, you discovered about GitOps rules, the benefits supplied by GitOps, and a few finest practices illustrated by real-world examples. GitOps can’t solely be utilized to container-based apps, but additionally to a full stack of cloud assets. With well-designed automation processes, it could additionally help improvement and operations that promote modifications in a number of environments.
GitOps is an improved method for utilizing DevOps on the cloud, nevertheless it can not remedy each problem. That stated, GitOps needs to be employed as a great tool in your cloud DevOps toolbox.
Need to study extra about GitOps? Take a look at these assets:
[ad_2]
