
聊着天就把活干了。

---

公司的运维一直由我来帮助实施。去年将所有微服务容器化后，运维的成本面临新的挑战。本着解放生产力的目标，顺带回忆不太熟悉的 Go 基本语法，笔者写了一个钉钉机器人来帮助我做一些运维的活。效果也不错，就把大体做法在这里讲讲。

做这个之前有一系列的必要（也可替换的）基础设施和概念以及 HTTP 服务端开发的认知，能实现这套聊天运维离不开每一个环节以及诸多细节。简单概括一下我是怎么实践的。

### 技术栈依赖

实践 ChatOps 至少需要的基础设施：一个 CI / CD 服务，一个暴露在公网的 HTTP 服务，一个远程 VCS 和一个能提供收发消息 API 的即时通信工具。

本项目采用：

- [Jenkins](https://www.jenkins.io/) (CI / CD，经典的持续集成工具，提供公网可访问的 REST API)
- [Git](https://git-scm.com/) (VCS，本项目使用公司正在用的 [Gitee.com](https://gitee.com) - 可使用 [GitHub.com](http://github.com) 或 GitLab，提供 REST API 或 SDK)
- [Serverless](https://vercel.com/docs/serverless-functions/introduction) (用来暴露核心的 HTTP 端点，只是无需运维而已；也不是必须，否则需要有公网服务器)
- DingTalk (限制[企业内部机器人](https://ding-doc.dingtalk.com/document/app/develop-enterprise-internal-robots)，能提供 WebHook 和收发消息的 SDK 即可，或其他类似 Slack 的聊天应用: 企业微信、飞书等等)

### 系统拓扑

![ChatOPS](/images/chat-ops/1.png)

懒汉只会和机器人以聊天的形式交互，[其余的脏活累活重复劳动交给机器人做](/blog/the-world-as-i-see-it)。大致流程如图，重点实现：

- 迎接聊天机器人的 HTTP 请求
- 根据请求文本触发行为
  - Git Workflow
    - Approve Pull Request
    - Test Pull Request
    - Merge Pull Request
    - Show PR list
  - CI / CD
    - CI Test
    - Deploy to Production

很显然，核心的开发工作的都在 Message Handler 那里。根据聊天机器人提供的 Event Hook（每次聊天机器人收到消息时会自动向某个服务器发送 HTTP 请求，会携带发送消息的用户、消息内容等 Payload），可以设计一个 HTTP 端点，在服务端解析这些请求（钉钉需要按照企业内部机器人开发，[参考这篇开发文档](https://ding-doc.dingtalk.com/document/app/develop-enterprise-internal-robots)）。

我们按照 [Kubernetes Prow 的设计语言](/blog/prow)，用一个 `/` 来作为 Tag，形式如同 `/test xxx` .

因此这里必然需要做字符串处理了。除了判断 Tag 的存在之外，要取 Tag 后面的参数。项目用 Go 实现，很简单，贴其中一工具函数的代码：

```go
func StringIndexOf(originalArray []string, wordToFind interface{}) []int {
    length := len(originalArray)
    interfaceArray := make([]interface{}, length)
    for i, v := range originalArray {
        interfaceArray[i] = v
    }
    var indexArray []int
    for i:=0 ; i < length; i++ {
      if strings.Compare(wordToFind.(string), originalArray[i]) == 0 {
        indexArray = append(indexArray, i)
      }
    }
	return indexArray
}
```

拿到参数后继续判断，比如机器人收到了这个指令：

`/merge 233`

即合并第 #233 个 Pull Request。要通过代码来合并，那操作 Git 就需要 SDK 或接口了。考虑到之前写 [Issue Ops Bot](https://github.com/la3rence/OpsBot) 的经验，Google 开源的 GitHub 的 [Go-GitHub](https://github.com/google/go-github) 写起来很方便，Gitee 应该也有人搞吧？果然搜到了华为的 OpenEuler 团队的仓库：[Go-Gitee](http://gitee.com/openeuler/go-gitee)。看来只有大厂才会给这些基础设施写 SDK 啊！果断加依赖:

```sh
go get -u gitee.com/openeuler/go-gitee
```

版本下载下来给的时间戳居然就是这两天的，虽然没有任何测试代码，但看似更新蛮活跃，大胆直接用上了。后面写了一些接口，发现 SDK 提供的一些 API 也不全，比如没有审核通过 PR 和测试通过 PR 的 API，就自己顺带拿 `net/http` 参考着 [Gitee 的 REST API](https://gitee.com/api/v5/swagger) 自己实现了，但是代码太丑陋（本来想模仿项目的写法去写，但是一心只想把功能完成），也没给华为提 issue，等回头有机会写下给它提个 PR 嘿嘿（除此之外我还发现 Gitee 的合并方式没有 `rebase` 选项，只提供 `merge` 和 `squash` ，在所谓的社区企鹅群里和他们提了一下建议，理都不理)。

如果机器人收到类似这样的指令:

`/jenkins test myservice` 或 `/deploy myservice`

那就直接对接 [Jenkins 的 REST API](https://www.jenkins.io/doc/book/using/remote-access-api/) 了。可以直接凭状态码判断响应，安全方面 Jenkins 自身提供了 HTTP BASIC 认证。就不细说了。

之前没有用 Go 写过 HTTP Server，这次也没有写——如果运维一套服务已经很麻烦了，开发出的一套帮助运维的辅助服务本身也需要运维（公网服务器、域名解析、持续的测试和部署等服务器资源以及[注意力资源](https://zh.wikipedia.org/wiki/%E6%B3%A8%E6%84%8F%E5%8A%9B%E7%B6%93%E6%BF%9F)），我就没有使用传统的后端服务，而是使用了自己熟悉的 [Vercel Serveless for Go](https://vercel.com/docs/runtimes#official-runtimes/go)。公开一个 Handler 方法即可，`*http.Request` 结构体指针的 `Body` 就是机器人发来的消息了。

下面是整个 Handler 的大致逻辑，伪代码：

```go
func Handler(w http.ResponseWriter, r *http.Request) {
  defer fmt.Fprintf(w, "ok")
  chatMessage, _ := ioutil.ReadAll(r.Body)
  if strings.Contains(chatMessage, "/deploy") {
     serverName := getServerNameFromMessage(chatMessage)
     jenkinsSDK.deploy(serverName)
  }
  if strings.Contains(chatMessage, "/merge") {
     pullRequestNumber := getPullRequestNumberFromMessage(chatMessage)
     giteeSDK.mergePullRequest(pullRequestNumber)
  }
  ...
 }
```

期待某天 Vercel 能够支持 JVM 语言甚至是 Spring 的 Serverless。

### 效果

比如让机器人展示下仓库目前的 Pull Request，然后测试这个 PR，通过后批准这个 PR，最终合并 PR，上线生产，聊天记录会是这样的：

```txt
Users 命令: /pr
Robot 回复: 当前仓库的 PullRequest 列表...
          [#709] fix: typo
          [author] username

Users 命令: /jenkins test micro-server 709
Robot 回复: 开始测试 PullRequest 709
CIBot 回复:
          [jenkins] micro-server ci
          -------------------------
          任务：#666
          状态：开始
          持续时间：0 分 1 秒
          执行人：Host 76.76.21.21

Users 命令: /approve 709
Robot 回复: 审核通过 PullRequest #709

Users 命令: /merge 709
Robot 回复: 合并 PullRequest #709
Gitee 回复: User 接受了 Owner/repo 的 Pull Request !709 fix: typo

Users 命令: /deploy micro-server
Robot 回复: 生产发布 micro-server
CDBot 回复:
          [jenkins] micro-server cd
          -------------------------
          任务：#233
          状态：开始
          持续时间：0 分 1 秒
          执行人：Host 76.76.21.21

# 友好地提供帮助
Users 命令: /help
Robot 回复: 当前支持指令列表, 带 * 需要特定人员发起
          /pr - 展示仓库发起中的 PR
          /jenkins <action> <servername> <pr-number> - 在指定 PR 下发起后端测试
          /pass <pr-number> - * 测试通过指定 PR
          /approve <pr-number> - * 审核通过指定 PR
          /merge <pr-number> - * 合并指定 PR
          /test <servername> - 在仅有一个 PR 的状态下发起后端服务测试
          /deploy <servername> - * 发布服务至生产环境
          /help - 显示此帮助内容
```

代码写的很丑陋，没脸往外放了，而且也是企业内部使用，就不开源了（所有变量，十个左右，都配置在环境变量中，尽量没有 Hard Code）。

社区也有不少钉钉机器人的 SDK，阿里没有提供 Go 版本的，但写起来也不复杂，顺手提供自己写的[钉钉群机器人 Go 语言的 SDK](https://github.com/la3rence/dingtalkbot-sdk)，目前就只用来发文本消息。

<div>
  <github user="la3rence" repo="dingtalkbot-sdk"></github>
</div>

最近一次更新，让机器人支持了多个仓库，直接在 `/tag` 最后加一个可选参数 `[repo]`，然后 SDK 的参数做出相应的变动就实现了。

此项实践已作为 ThoughtWorks 员工构建的知识体系 Ledge DevOps 对 ChatOps 这一模式的展示案例：

- [Pattern#ChatOps from Ledge —— DevOps knowledge learning platform](https://devops.phodal.com/pattern#chatops)


DevOps / ChatOps with Dingtalk by GoLang (bot) 钉钉机器人开发应用于运维自动化 Jenkins + WebHook + Git + Pull Request

基于 Go 的 ChatOps 实践


### **Prow** | praʊ |

_noun_. _the pointed front part of a ship; the bow. 船首._

了解 Prow 可以参考这篇知乎专栏：[Kubernetes 原生 CI/CD 系统 Prow 简介](https://zhuanlan.zhihu.com/p/65545774)。

本文重点参考了以下文章，并做了一些问题的修复：

- [Prow Tutorial - KubeSphere‘s Github Repo](https://github.com/kubesphere/prow-tutorial)
- [DevOps 工具链之 Prow](https://www.chenshaowen.com/blog/prow-of-devops-tool-chain.html)

我们并不一定需要使用 Bazel 来构建配置。笔者使用的 Kubernetes 版本为 2020 年发布的 1.19.3。一切的前提是拥有一个 Kubernetes 集群，最好在里面也部署一个 Ingress Controller
用来暴露我们的 WebHook 以及 Prow Deck 前端 Dashboard 服务。

在 K8s 集群中部署 Prow 的具体步骤如下：

首先注册一个 GitHub 账号专门用于作为机器人账号，用此账号前往 [GitHub Developer 页面](https://github.com/settings/tokens)创建一个 Token，权限参考上文，并邀请此账号作为
Collaborators 管理仓库。

随机生成 H-MAC 作为 WebHook 密码安全验证。

```yaml
openssl rand -hex 20 > hmac
```

将他们保存在 `/etc/github/oauth` 和 `/etc/webhook/hmac` 文件下。路径不能错误，因为此处和下面的 Prow manifest 字段匹配。

纳入集群对象：

```bash
kubectl create secret generic hmac-token --from-file=hmac=/etc/webhook/hmac
kubectl create secret generic oauth-token --from-file=oauth=/etc/github/oauth
```

将[以下 Prow 的 manifest](https://gist.github.com/la3rence/79ba7d87cb8a3a44916162d4dece0c66) 做简单修改，注意 Ingress 的域名，namespace 为 `default`：

`gist:la3rence/79ba7d87cb8a3a44916162d4dece0c66`

apply 上述 manifest。过程可能持续几分钟。上面用到的镜像都来自 DockerHub，国内可以直接访问。出现问题尝试打印 Pod 日志或者 describe，用好 Google 和 GitHub 能解决几乎 99% 的技术问题。

```bash
curl -L https://bit.ly/prow -o prow.yaml
vi prow.yaml
kubectl apply -f prow.yaml
```

### **Deck** | dɛk |

_noun._ 甲板

等 Pod 全都 Running 后，项目就成功了一半！现在直接访问 Prow 的 Ingress 地址，可以看到 Prow 的 Deck 前端
Dashboard，类似于：[https://prow.k8s.io/](https://prow.k8s.io/) 。

这时，可以在 GitHub 的项目设置里去添加 WebHook:

1. Payload URL 是你的 Prow Ingress 域名后面直接加 `/hook`
2. Content Type 选择 `application/json`
3. Secrets 是上面随机生成的 HMAC
4. 勾选 `Send me everything`

激活并保存。

接着在集群机器上创建一个 `plugins.yaml` 文件和 `config.yaml` 文件来配置 Prow。

插件的声明：

```yaml
plugins:
  GitHub账号/项目名:
    - size
    - cat
    - dog
    - pony
    - shrug
    - yuks
    - label
    - trigger
    - approve
    - lgtm
    - welcome
    - help
    - assign
    - branchcleaner
    - lifecycle
    - wip
    - heart
    - milestone
    - milestonestatus
    - project
    - stage
    - skip
    - blockade
```

Tide 的配置：

```yaml
prowjob_namespace: "default"
tide:
  merge_method:
    kubeflow/community: squash

  target_url: http://你的域名/tide
  queries:
    - repos:
        - GitHub账号/项目名
      labels:
        - lgtm
        - approved
      missingLabels:
        - do-not-merge
        - do-not-merge/hold
        - do-not-merge/work-in-progress
        - needs-ok-to-test
        - needs-rebase

  context_options:
    from-branch-protection: true
    skip-unknown-contexts: true
    orgs:
      org:
        required-contexts:
          - "check-required-for-all-repos"
        repos:
          repo:
            required-contexts:
              - "check-required-for-all-branches"
            branches:
              branch:
                from-branch-protection: false
                required-contexts:
                  - "required_test"
                optional-contexts:
                  - "optional_test"
```

应用更改：

```bash
kubectl create configmap plugins \
--from-file=plugins.yaml=/root/cluster/prow/plugins.yaml --dry-run -o yaml \
| kubectl replace configmap plugins -f -

kubectl create configmap config \
--from-file=config.yaml=/root/cluster/prow/config.yaml --dry-run -o yaml \
| kubectl replace configmap config -f -
```

可能需要两分钟生效。等一切就绪后，就可以创建 Pull Request 来测试了。效果可以参考 [Kubernetes 的官方仓库](http://github.com/kubernetes/kubernetes)或[我的这个 node
命令行翻译项目](https://github.com/la3rence/Tranclite/pull/5)。

### 使用 Prow

在 GitHub 的 Issue 或 Pull Request 页面下你可以用一个简单的 `/meow` 命令让机器人随机发送一张 🐱 的图片。无需任何刷新，GitHub 页面会自动地更新此页面（后来发现是基于 WebSocket）：

![cat-in-issue](/images/prow/1.png)

我们注意到， Kubernetes 维护人员会使用 `/test` 命令来让集群内的 Pod 执行测试并将结果告诉 GitHub，这就是 ProwJob 实现的了。

ProwJob 主要用于 PR 流程的 CI 测试，而国内网络原因无法使用 Google 的 GCS 服务，ProwJob 中 plank
依赖的 [Pod Utilities](https://github.com/kubernetes/test-infra/blob/master/prow/jobs.md#pod-utilities)，其中定义 GCS Bucket
用于存放构建产物、日志等内容，因此，我们似乎只能自己用自定义的镜像来跑临时 CI 任务了。注意定义 presubmit 字段下的 decorate 为
false，并利用好 [Prow 提供的一些环境变量](https://github.com/kubernetes/test-infra/blob/master/prow/jobs.md#job-environment-variables)。

下面是我的一个简单的 Spring Boot 项目利用 [Maven 镜像（配合阿里云的 Maven Repo）](https://hub.docker.com/r/lawrence2018/aliyun-maven)来做的
presubmits，同样在 config.yaml 中添加：

```yaml
presubmits:
  la3rence/kubernetes-springboot-demo:
    - name: spring
      decorate: false
      always_run: false
      spec:
        containers:
          - image: lawrence2018/maven:3.6-jdk-8
            command: ["/bin/sh", "-c"]
            args:
              - |
                mkdir -p /${REPO_NAME}
                cd /${REPO_NAME}
                git init
                git remote add origin https://github.com/${REPO_OWNER}/${REPO_NAME}.git
                git fetch origin pull/${PULL_NUMBER}/head:pr-${PULL_NUMBER}
                git checkout pr-${PULL_NUMBER}
                mvn test
            resources:
              requests:
                cpu: "2000m"
                memory: "1536Mi"
```

重新配置 config 后并应用更改，在 Pull Request 下评论 `/test all` 或者 `/test spring`
来触发测试。[参考此 PR](https://github.com/la3rence/kubernetes-springboot-demo/pull/4)。

`/test` 后面加 presubmits 的 name 名可触发指定的测试 Pod，all 则测试全部。测试若失败，可使用 `/retest` 来重新测试。

![Prow-in-Pull-Request-Test.png](/images/prow/2.png)

如果测试通过，可使用 `/lgtm` 触发 tide 让机器人合并代码（注意自己不能 `/lgtm`）。

### 自研 Issue/PR Bot

GitHub 大规模使用 WebSocket 来动态修改 Issue 或 PR 页面的 DOM，在视觉上非常令人享受。笔者后来也参考 Prow 用 Go
写了一个简单了 [OpsBot](https://github.com/la3rence/OpsBot) 帮助自己的仓库做一些简单的 PR、Issue 的管理，现已开源，欢迎任何 Issue / PR！

<div>
  <github user="la3rence" repo="OpsBot"></github>
</div>


Kubernetes 原生 CI/CD 系统 `Prow`。GitHub CI 🤖️ by Kubernetes. @k8s-ci-bot

◳Lawrence Li

包含标签 `ci`

包含标签 ci

包含标签 `ci`