Shulou(Shulou.com)06/01 Report--

This article mainly introduces "how to use DevOps to realize infrastructure automation". In daily operation, I believe many people have doubts about how to use DevOps to realize infrastructure automation. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "how to use DevOps to realize infrastructure automation". Next, please follow the editor to study!

GitOps provides an automated infrastructure management approach that includes DevOps best practices that have been applied in many teams-including version control, code review, and CI/CD pipelining. At present, many companies are adopting DevOps, focusing on its great potential to improve productivity and software quality. In the process, we have found a way to automate the software development lifecycle. However, when it comes to infrastructure setup and deployment, the proportion of manual operations is still considerable. With GitOps, teams can automate the infrastructure configuration process. This is because in the GitOps method, we can use declarations to code the infrastructure (IaC), and then store the infrastructure code in Git repo as if it were application development code.

How does GitOps work?

The concept of GitOps was originally put forward by Weaveworks, a Kubernetes management company, so the discussion about GitOps is mainly carried out in the context of Kubernetes. As the overall facility shifts to a micro-service architecture running in a container, we naturally need more feasible orchestration platforms as support. In fact, container-based applications often have configuration systems that are extremely complex and difficult to manage. GitOps helps us simplify this process by applying technologies that have been validated in the field of DevOps. Today, this idea has been widely accepted among DevOps supporters and represents an upgrade model of the IaC concept. It consists of three main components:

Infrastructure is code

Pull request

CI/CD

Let's look at the details below.

Infrastructure is code

IaC is a practice of configuring and managing infrastructure as a declaration file and storing it as code. By leveraging IaC and version control, the team can easily optimize all operational processes. GitOps takes the declarative model of IaC as the core, and also provides a good implementation platform for Kubernetes. Declarative means that the configuration focuses more on the declaration that points to the expected state than on a specific set of commands. For example, in Kubernetes, you can define the number of Pod required for a service in manifest. On this basis, the system will automatically provide Pod for the service according to its operational status, instead of having a fixed number of Pod configurations written by the engineer. Any cloud native software that conforms to the declarative model can be regarded as code. We use AWS CloudFormation, a declarative tool, to write the AWS infrastructure to implement the infrastructure, the code principle. The required state is declared in code form, and the system applies changes to automatically achieve this target state. Of course, declarative models are not the only way to implement GitOps. You can also use imperative definition environments to achieve the same operational results.

Pull request

The core idea behind the concept of GitOps is to regard the version control system as a single objective source. We use Git as the change management system for application code, and we can also use it for infrastructure code. So all declaration files are hosted in a unified location for collaboration. On this basis, we were able to use the key concept of Git-- pull requests to manipulate changes. In the application development workflow, we use a main branch as the release branch. Developers create functional branches within the main branch. After developing a particular feature or story, we create a pull request to merge it back into the main branch. The same approach can easily work in infrastructure code. By creating a pull request, we can ensure that the code goes through a complete code review process before being integrated into another branch of the code base. Code review can prevent low-quality code from entering the test or production environment, which is especially important for infrastructure code. Formal approval through code review will also contribute to follow-up reviews and troubleshooting.

Git organization

The deployment process of GitOps requires at least two repo: the application repo and the environment configuration repo. The former contains the source code of the application and its deployment manifest;, while the latter contains the state required by the entire system, which uses declarative specifications to describe the elements of the environment. You can describe the environment as a development, test, and production environment in the code repo, with applications and infrastructure services that can run in specific versions of the environment. In the case of infrastructure, the main branch can represent an environment. We can implement these changes in the functional branch and then create a pull request to merge the changes in the main branch. In this way, we can collaborate while understanding who has made what changes in a more transparent way. Because all changes are committed in Git, this also helps to track down the root cause of the problem. GitOps is suitable for any Git-based system, including GitHub, BitBucket, or GitLab. It does not rely on any particular tool or technology.

CI/CD

In order to build a complete GitOps implementation, you also need a CI/CD pipeline. By using an automated delivery pipeline, you can deliver infrastructure changes to a specified environment whenever changes occur in the Git repository. This pipeline connects your Git pull request to the business process system. When you use the pull request to trigger the pipeline, the business process system will perform the task accordingly. There are two ways to deploy GitOps: push and pull pipelining. The difference between the two is mainly reflected in the way the environment is deployed when building the infrastructure.

This strategy is used by many popular CI/CD tools. We store the source code of the application and its deployment manifest in a repo. The build pipeline is triggered when a new update occurs in the application code. The pipeline builds the container image and pushes the changes to the environment. This strategy provides greater flexibility to support any type of infrastructure. Of course, this approach also has the disadvantage of allowing CI/CD tools to access your environment directly.

It is generally believed in the community that the pull pipelined approach is a more secure practice for GitOps. This method introduces operators. The operator is a component between the pipeline and the business process tool that constantly compares the target state in the environment repo with the actual state in the deployed infrastructure. Once any changes are detected, the operator changes the infrastructure to accommodate the environment repo. In addition, it can monitor the image repository and identify new versions of images to be deployed. It's all this that makes GitOps so special. In GitOps, an environment update is raised only if there is a change in the environment repo. If the implemented infrastructure changes in any other way that is not defined in the environment repo, the system restores any modifications. Most applications may need to use multiple environments at the same time. GitOps allows you to create multiple pipelines that can change the environment repo. You can use separate branches in the environment repo to manage more environments. In the face of a branch change, the operator can deploy the change to the production environment in response, while deploying other changes from another branch to the test environment.

What are the advantages of GitOps? DevOps best practices

GitOps is a model that focuses on existing Git workflows, IaC, CI/CD pipelining, immutable servers, tracking and observability best practices, and represents Kubernetes's advanced concepts in cloud native application management. Therefore, its technology stack and operation experience can bring a lot of benefits to enterprise users.

Continuous deployment-simplification

Continuous deployment means faster and more frequent deployment. Due to a variety of different considerations, such as system statefulness, downtime resilience, upstream / downstream dependencies, and other processes and dependencies common in the organization, many friends may find it increasingly difficult to establish appropriate continuous deployment mechanisms. GitOps not only enables continuous deployment, but also frees people from the separate management of a large number of tool solutions-- because all operations take place within the version control system. As another big boost, the deployment operator is responsible for providing structural and automation support. This also increases productivity and leads to faster MTTD (average deployment time). Automated continuous deployment ensures that the team can deliver more than 30-100 times more changes per day, increasing average production efficiency by 2-3 times.

Rancher 2.5 simplifies deployment and management through Rancher continuous delivery (Continuous Delivery). This is a new feature that ensures consistent deployment by using Git repositories to automatically store and manage application and configuration information, greatly reducing the burden on customers, thus simplifying the deployment process across private, public, hybrid, or multi-cloud environments.

Rancher launched the massive cluster management project Fleet in 2020, which has become the engine for continuous delivery of Rancher. Fleet is a Kubernetes cluster controller designed to address the challenges of thousands of clusters around the world.

Low MTTR (average repair time)

MTTR is one of the key metrics that the DevOps team needs to measure. In a micro-service architecture, even the smallest problems can be difficult to fix. Because GitOps saves all changes in a version control system, supplemented by automated management, MTTR is expected to be significantly shortened. You can have a comprehensive understanding of the changing process of the environment and greatly reduce the difficulty of error recovery.

Simplify Kubernetes management

Even if you don't know much about Kubernetes, developers can easily get Kubernetes upgrades and functional implementations using familiar tools such as Git. Novice embedded developers can quickly catch up and reduce the adaptation period that would have taken months to a few days.

Improve the standardization level of the enterprise as a whole

You can build transparent end-to-end workflows across the enterprise, thanks to the rendering framework provided by GitOps to present changes to applications, software, and Kubernetes add-ons. Git can also fully recreate your operational activities.

Prerequisites for applying GitOps to establish a stable code review and testing process

An in-depth review of code changes will help us accurately identify some important actions, such as adding global variables, to prevent low-quality code from being released to testing or even production environments. On this basis, you can submit validated code through pull requests, and developers are strictly prohibited from committing changes directly. Once the pull requests to complete the review and merge, the pipeline can be triggered. This is the first step in maintaining high-standard code and thus enhancing the stability of the system.

test

The involvement of GitOps means that the entire level of automation will be raised to a new level, which also requires us to thoroughly test pipelined applications. Although GitOps can help us complete the rollback relatively easily, releasing high-quality code that has been well tested is the best way to really improve the reliability of the process.

Monitoring is king

GitOps can replay the operation process, continuously track the state of the system and improve it, and finally execute the release and rollback accordingly. A strict monitoring system can help you identify and prevent any unexpected drifts and system changes in the configuration. So before you start using GitOps, check your monitoring skills and start strengthening them to make sure they are capable of dealing with this change.

Embrace the new culture

Traditional process constraints and long release time will only slow down the pace of the business. Fully embracing the DevOps culture means that we should take full advantage of the best strategy and help the team understand the value of development and operations actions. At the same time, the development and operation and maintenance teams must work together to establish an overall and stable infrastructure to run applications faster and more smoothly, so as to improve the efficiency of system management. The lack of DevOps culture will seriously hinder us from enjoying the benefits of GitOps.

Why use GitOps?

GitOps is a powerful workflow pattern that can help you efficiently govern your cloud infrastructure. GitOps can bring many advantages to the engineering team, and greatly enhance the coordination ability, transparency, stability and durability of the system.

At this point, the study on "how to use DevOps to automate infrastructure" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.