GitOps 与 ChatOps 的落地实践-低调大师

GitOps 与 ChatOps 的落地实践

2019-07-19 774

前言

说到 GitOps 和 ChatOps ，那就不得不谈到 DevOps 。 DevOps 作为一种文化，旨在促进开发、测试和运维人员之间的沟通与协作。而促进合作的方式，往往是使用一系列工具，完成这三个角色的相互协作。这带来的好处也是显而易见的：更快的交付速度和更低的人力成本。获益于 DevOps 和公有云，一个近百人的研发团队，可以只配备一到两个专职运维人员，降低的成本不言而喻。既然 DevOps 是一种文化，那么在不同的团队则会有不同的实践，而无论实践如何，其最终目的都是一样的：最大化的实现自动化，释放更多的人力资源，创建更大价值。

而 GitOps 和 ChatOps ，则是 DevOps 的两种实践。这两种实践分别通过使用 版本控制软件 Git 和实时聊天软件来达到提升交付速度和研发效率的目的。

GitOps

GitOps 是一种实现持续交付的模型，它的核心思想是将应用系统的声明性基础架构和应用程序存放在 Git 的版本控制库中。

将 Git 作为交付流水线的核心，每个开发人员都可以提交拉取请求（Pull Request）并使用 Git 来加速和简化 Kubernetes 的应用程序部署和运维任务。通过使用像 Git 这样的简单熟悉工具，开发人员可以更高效地将注意力集中在创建新功能而不是运维相关任务上。

通过应用 GitOps ，应用系统的基础架构和应用程序代码可以快速查找来源——基础架构和应用程序代码都存放在 gitlab 、或者 github 等版本控制系统上。这使开发团队可以提高开发和部署速度并提高应用系统可靠性。

将 GitOps 应用在持续交付流水线上，有诸多优势和特点：

安全的云原生 CI/CD 管道模型
更快的平均部署时间和平均恢复时间
稳定且可重现的回滚（例如，根据Git恢复/回滚/ fork）
与监控和可视化工具相结合，对已经部署的应用进行全方位的监控

在我看来 GitOps 的最大优势就是通过完善的 git 分支管理来达到管理所有 CI/CD 管道流水线的目的，不同的环境可以对应不同分支，在该环境出现问题时候，可以直接查找对应分支代码，达到快速排查问题的目的。而对于 Git 的熟悉，更是省去学习使用一般 DevOps 工具所需的学习成本和配置时间，开发人员可以无任何培训直接上手使用，进一步降低了时间与人力成本。

ChatOps

ChatOps 以聊天室（聊天群），即实时聊天软件为中心，通过一系列的机器人去对接后台的各种服务，开发&测试&运维人员只需要在聊天窗口中与机器人对话，即可与后台服务进行交互，整个工作的展开就像是使唤一个智能助手那样简单自然。

ChatOps 带来了很多好处：

公开透明。所有的工作消息都在同一个聊天平台中沉淀并公开给所有相关成员，消除沟通壁垒，工作历史有迹可循，团队合作更加顺畅。
上下文共享。减少因工作台切换等对消息的截断，保证消息的完整性，让工作承接有序，各角色，各工具都成为完成工作流中的一环，打造真正流畅的工作体验。
移动友好。只需要在前台与预设好的机器人对话即可完成与后台工具、系统的交互，在移动环境下无需再与众多复杂的工具直接对接，大大提升移动办公的可行性。
DevOps 文化打造。用与机器人对话这种简单的方式降低 DevOps 的接受门槛，让这种自动化办公的理念更容易的扩展到团队的每一个角落。

对于 ChatOps 的理解最早要源于在 GitHub 上参与开源项目的一些经历，在向 Kubernetes 相关项目提交 PR 时，会有一个名叫 k8s-ci-robot 的小机器人来自动为该 RP 打上标签，并且根据你提交 PR 时的 commit 信息来为你分配 Reviewers，如果没有填的话，则会自动为你分配 Reviewers 等功能。同时可以在 commit 中输入命令，还可以进行其他的操作，详见：命令列表。而其实这个机器人的后端就是名为 Prow 的由 Google 发起的适应云原生 CI/CD 开源项目，有兴趣的话推荐阅读：Prow 快速入门向导。

而一篇名为：《湾区日报是如何运作的？》文章更是让我坚定信心开始开发自己 ChatOps 系统。该文章介绍作者是怎么运营一个名叫湾区日报的个人博客，这个博客通过11个渠道（网站，iOS app，Android app、微博，微信，Twitter，Chrome 浏览器推送、Facebook、邮件订阅、RSS、Telegram）推荐给读者，而这个11个渠道的发布都是通过 slack 和作者开发的小机器人完成。在我还在为使用脚本可以在多渠道发布个人技术博客而沾沾自喜的时候，人家早在多年前就开始使用 ChatOps 模式向多渠道使用多格式自动推送文章了。这也坚定了我开发我们自己的 ChatOps 系统的决心。

GitOps & ChatOps 的实践

使用 Drone 实现 GitOps

DevOps 文化早已在我司落地，这也是为什么我们有将近百人的研发团队，却只有两个专职运维的原因。CI/CD 方面我们之前使用的是 jenkins ， jenkins 是一个十分强大的工具，但是随着公司的发展，项目也越来越多，粗略统计了一下我们在 jenkins 中有几百个 Job ，虽然所有项目都使用 Jenkinsfile 的方式将 pipeline 持久化到了 gitlab 中，但是所有的 Job 配置，包括参数化构建配置，SCM 配置等都是保存在 jenkins 上，一旦有失，几百个 Job ...哭都没有地方哭去（别问我是怎么知道的）。

经过调研我们选择了 drone CI 进行 GitOps ，通过自己开发不同功能的插件，完善了我们的整个 CI/CD 流水线。而插件的开发也并不是从头开始，而是直接 fork 现有的插件进行定制化的二次开发，有兴趣的可以到我的 GitHub 和 DockerHub 上查看。

将项目配置进行了分离，配置使用单独的 git 仓库维护，同时整合了镜像安全扫描，钉钉通知等功能。

由于 drone CI 的配置文件 .drone.yml 需要统一规范，所以我们在自己的 DevOps 平台开发了 Drone 配置页面，帮助开发自主配置。我们提供了 Java 、 Node 、 Python 三种配置模板，并且由于 DevOps 平台已与 GitLab 集成，可以直接将生成的 .drone.yml 文件插入到相应 git 项目中。

同时也提供了钉钉构建通知，在构建成功后会发送到相应的开发群组中，如果需希望自动发布的话，也可点击通知中的连接自行发布。

自研平台配合钉钉 Outgoing 功能实现 ChatOps

前面的构建通知机器人使用的是钉钉的自定义机器人，将构建信息推送到各个项目群中。而钉钉机器人的 Outgoing 功能，则可用来实现 ChatOps 的功能（注意：钉钉的 Outgoing 功能目前还处于灰度测试阶段，想要使用的需要联系官方管理员开启该功能）。

由于我司专职运维人员只有两位，管理着整个团队全部的基础设施。但是随着开发团队的扩张，运维人员每天要处理大量的咨询类工作，而这类工作有着重复性强和技术性弱的特点，对于运维人员的技术水平毫无提升，那么这类工作交给机器人岂不是更好。得益于我们 DevOps 平台完善的 API ，小助手机器人的开发并不困难。

小助手机器人的诞生，极大的提高了咨询类工作的效率，同时也释放了运维人员的工作时间，运维人员可以将更多精力投注到更有技术含量的事情上。

小助手机器人还有运维版本，功能包括：批量操作虚拟机、重启服务、DNS 解析、Kubernetes 信息检测&操作等功能，由于还是测试版本，这里就不做详细介绍了。

结语

上文中简要的介绍了 GitOps 和 ChatOps 在我司的落地实践，从决定落地 GitOps 和 ChatOps 至今不过短短的2个月。得益于我司浓厚的 DevOps 文化氛围，让我可以在极短的时间内将 GitOps 和 ChatOps 落地实践。但毕竟实践的时间还短，很多需求还在收集和调研中，后续的开发还在持续进行。欢迎对 GitOps 和 ChatOps 感兴趣的同学一起交流，共同提升。

参考资料

作者简介：

郭旭东，2018年4月加入凯京科技。曾任高级研发和运维开发工程师，现任凯京科技研发中心架构&运维部运维负责人，阿里云MVP，负责公司运维团队建设。致力于推行devops理念及相关技术，提升开发效率，提高交付质量与速度，专注于云平台的容器化实践，探索更高效的运维系统架构。

微信关注我们

原文链接：https://my.oschina.net/keking/blog/3076397

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

C语言动态内存管理和动态内存分配

动态内存管理同时还具有一个优点：当程序在具有更多内存的系统上需要处理更多数据时，不需要重写程序。标准库提供以下四个函数用于动态内存管理： (1) malloc（）、calloc（）分配新的内存区域。 (2) realloc（）调整已分配的内存区域。 (3) free（）释放已分配的内存区域。上述所有函数都声明在头文件 stdlib.h 中。对象在内存中所占空间的大小是以字节数量为单位计算的。许多头文件（包括 stdlib.h）专门定义了类型 size_t 用来保存这种内存空间的相关信息。例如，sizeof 运算符以类型 size_t 返回字节数量。动态内存分配两个内存分配函数 malloc（）和 calloc（）的参数不一样： void*malloc(size_t size); 函数 malloc（）分配连续的内存区域，其大小不小于 size。当程序通过 malloc（）获得内存区域时，内存中的内容尚未决定。 void*calloc(size_t count，size_t size); 函数 calloc（）分配一块内存区域，其大小至少是 count_size。换句话说，上...

2019-07-19

640

Skynet 服务创建流程根据设计综述 Skynet 是为了让服务器充分利用多核优势，将不同的业务放在独立的执行环境中处理。 Skynet 核心功能是加载一个 C 模块（动态库），模块用数字 id 标识，作为其 handle ，模块被称为服务 service 。服务间可以自由发送消息。每个模块可以向 Skynet 框架注册一个 callback 函数，用来接收发给它的消息。每个服务是被一个个消息驱动，当无消息时，服务处于挂起状态。每个服务拥有一个属于自己的消息队列，框架中存在一个全局队列负责调度处理服务所接收到的消息。代码层面，Skynet 服务对应于数据结构 struct skynet_context ，其中重要字段如下。 struct skynet_context { void * instance; // 模块自定义数据 struct skynet_module * mod; // 框架模块数据 void * cb_ud; // 传给回调函数的自定义数据 skynet_cb cb; // 回调函数 struct message_queue * queue; // 消息队列，...

2019-07-19

658

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。