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

This article mainly explains the "practical case study of GitOps and ChatOps". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "the practical case study of GitOps and ChatOps".

Preface

When it comes to GitOps and ChatOps, you have to talk about DevOps. DevOps, as a culture, aims to promote communication and collaboration among developers, testers, and operators. The way to promote cooperation is often to use a series of tools to complete the cooperation of the three roles. The benefits are also obvious: faster delivery and lower labor costs. Benefit from DevOps and public cloud, a research and development team of nearly 100 people, can only be equipped with one or two full-time operation and maintenance staff, the cost reduction is self-evident. Since DevOps is a culture, there will be different practices in different teams, and no matter what the practice is, the ultimate goal is the same: maximize automation, release more human resources, and create greater value.

GitOps and ChatOps are two practices of DevOps. These two practices achieve the purpose of improving delivery speed and R & D efficiency by using version control software Git and real-time chat software respectively.

GitOps

GitOps is a model for continuous delivery, and its core idea is to store the declarative infrastructure and applications of the application system in the version control library of Git.

With Git at the core of the delivery pipeline, every developer can submit a pull request (Pull Request) and use Git to speed up and simplify Kubernetes application deployment and operations tasks. By using simple familiarity tools like Git, developers can focus more efficiently on creating new features rather than on operations-related tasks.

By applying GitOps, the infrastructure and application code of the application system can quickly find the source-- the infrastructure and application code are stored on version control systems such as gitlab or github. This enables the development team to improve the speed of development and deployment and the reliability of the application system.

Applying GitOps to the continuous delivery pipeline has many advantages and characteristics:

Secure Cloud Native CI/CD Pipeline Model

Faster average deployment time and average recovery time

Stable and reproducible rollback (for example, recovery / rollback / fork based on Git)

Combined with monitoring and visualization tools to provide comprehensive monitoring of deployed applications

In my opinion, the biggest advantage of GitOps is to manage all git pipeline pipelines through perfect CI/CD branch management. Different environments can correspond to different branches. When there is a problem in this environment, you can directly find the corresponding branch code to achieve the purpose of rapid troubleshooting. The familiarity with Git saves the learning cost and configuration time required to learn to use general DevOps tools, and developers can use it directly without any training, further reducing time and labor costs.

ChatOps

ChatOps takes chat room (chat group), that is, real-time chat software as the center, through a series of robots to dock various services in the background, development & testing & operation and maintenance personnel only need to talk to the robot in the chat window to interact with the background service. The whole work is as simple and natural as using an intelligent assistant.

ChatOps brings many benefits:

Open and transparent. All work messages are deposited in the same chat platform and disclosed to all relevant members, eliminating communication barriers, a track of work history, and more smooth teamwork.

Context sharing. Reduce the truncation of messages due to workbench switching, ensure the integrity of messages, let the work undertake orderly, each role, each tool has become a link in the completion of the workflow, to create a truly smooth work experience.

Mobile friendly. You only need to talk with the preset robot in the foreground to complete the interaction with the background tools and systems, and there is no need to directly dock with many complex tools in the mobile environment, which greatly improves the feasibility of mobile office.

DevOps culture building. Using the simple way of talking to the robot to lower the acceptance threshold of DevOps, so that this concept of office automation can be easily extended to every corner of the team.

The understanding of ChatOps comes from some experience of participating in open source projects on GitHub. When submitting PR to Kubernetes-related projects, a small robot named k8s-ci-robot automatically tags the RP and assigns Reviewers to you according to the commit information when you submit PR. If it is not filled in, it will automatically assign you Reviewers and other functions. At the same time, you can enter commands in commit, and you can also perform other operations, as detailed in: command list. In fact, the back end of this robot is called Prow, which is an open source project launched by Google to adapt to cloud native CI/CD. If you are interested, we recommend reading: Prow Quick start Wizard.

And an article is entitled: "how does the Bay area Daily work?" "the article makes me strengthen my confidence and begin to develop my own ChatOps system. This article describes how the author runs a personal blog called Bay area Daily, which is recommended to readers through 11 channels (websites, iOS app,Android app, Weibo, Wechat, Twitter,Chrome browser push, Facebook, email subscription, RSS, Telegram), and these 11 channels are published through slack and small robots developed by the author. While I was still smug about using scripts to publish personal technology blogs in multiple channels, people started using ChatOps mode to automatically push articles to multiple channels and formats for many years ago. This also strengthened my determination to develop our own ChatOps system.

The practice of GitOps & ChatOps uses Drone to implement GitOps

DevOps culture has long been established in our company, which is why we have a R & D team of nearly 100 people, but only two full-time operators. CI/CD we used to use jenkins, jenkins is a very powerful tool, but with the development of the company, there are more and more projects, rough statistics we have hundreds of Job in jenkins, although all projects use Jenkinsfile to persist pipeline to gitlab, but all Job configurations, including parameterized construction configuration, SCM configuration, etc. are saved on jenkins, once lost, hundreds of Job. There is no place to cry (don't ask me how I know).

After research and research, we chose drone CI for GitOps, and improved our entire CI/CD pipeline by developing plug-ins with different functions. The development of plug-ins is not from scratch, but directly fork the existing plug-ins for customized secondary development, interested can check on my GitHub and DockerHub.

The project configuration is separated, and the configuration is maintained by a separate git warehouse, while integrating the functions of image security scanning, nail notification and so on.

Since the drone CI configuration file .drone.yml requires a unified specification, we have developed a Drone configuration page on our DevOps platform to help develop our own configuration. We provide three configuration templates: Java, Node, and Python, and because the DevOps platform is integrated with GitLab, you can insert the generated .drone.yml file directly into the corresponding git project.

At the same time, a nail construction notification is also provided, which will be sent to the corresponding development group after the construction is successful. If you want to publish it automatically, you can also click on the link in the notification to publish it yourself.

Self-developed platform cooperates with nail Outgoing function to realize ChatOps

The previous build notification robot uses a custom nailed robot to push build information to each project group. The Outgoing function of the nailing robot can be used to achieve the function of ChatOps. (note: the Outgoing function of nailing is still in the grayscale testing stage. If you want to use it, you need to contact the official administrator to turn on this function).

Since there are only two full-time operation and maintenance staff in our company, we manage all the infrastructure of the whole team. However, with the expansion of the development team, operation and maintenance personnel have to deal with a large number of consulting work every day, and this kind of work has the characteristics of strong repetition and weak technicality, and there is no improvement in the technical level of operation and maintenance personnel. Wouldn't it be better to leave this kind of work to the robot? Thanks to the perfect API of our DevOps platform, it is not difficult to develop a small assistant robot.

The birth of the small assistant robot not only greatly improves the efficiency of consulting work, but also releases the working time of the operation and maintenance personnel, who can devote more energy to more technical things.

The mini-assistant robot also has an operation and maintenance version, and its functions include batch operation of virtual machines, restart of services, DNS parsing, Kubernetes information detection-operation and other functions. As it is still a test version, we will not introduce it in detail here.

Thank you for your reading, the above is the content of "practical case study of GitOps and ChatOps". After the study of this article, I believe you have a deeper understanding of the practical case analysis of GitOps and ChatOps, and the specific use needs to be verified by practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.