Lawrence

基于 Go 的 ChatOps 实践

2021-02-06T00:00:00.000Z

聊着天就把活干了。

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

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

#技术栈依赖

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

本项目采用：

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

#系统拓扑

懒汉只会和机器人以聊天的形式交互，其余的脏活累活重复劳动交给机器人做。大致流程如图，重点实现：

迎接聊天机器人的 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 端点，在服务端解析这些请求（钉钉需要按照企业内部机器人开发，参考这篇开发文档）。

我们按照 Kubernetes Prow 的设计语言，用一个 / 来作为 Tag，形式如同 /test xxx .

因此这里必然需要做字符串处理了。除了判断 Tag 的存在之外，要取 Tag 后面的参数。项目用 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 的经验，Google 开源的 GitHub 的 Go-GitHub 写起来很方便，Gitee 应该也有人搞吧？果然搜到了华为的 OpenEuler 团队的仓库：Go-Gitee。看来只有大厂才会给这些基础设施写 SDK 啊！果断加依赖:

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

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

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

/jenkins test myservice 或 /deploy myservice

那就直接对接 Jenkins 的 REST API 了。可以直接凭状态码判断响应，安全方面 Jenkins 自身提供了 HTTP BASIC 认证。就不细说了。

之前没有用 Go 写过 HTTP Server，这次也没有写——如果运维一套服务已经很麻烦了，开发出的一套帮助运维的辅助服务本身也需要运维（公网服务器、域名解析、持续的测试和部署等服务器资源以及注意力资源），我就没有使用传统的后端服务，而是使用了自己熟悉的 Vercel Serveless for Go。公开一个 Handler 方法即可，*http.Request 结构体指针的 Body 就是机器人发来的消息了。

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

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。希望 @rauchg 大佬能看到。

#效果

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

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，目前就只用来发文本消息。

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

WebSocket 集群方案

2020-12-22T00:00:00.000Z

基于 Spring Cloud 使用一致性哈希算法实现分布式 WebSocket. / 基于 RabbitMQ 广播实现分布式 WebSocket.

#WebSocket 协议

参考 RFC 标准规范。

#思路

核心问题在于具备 WebSocket 服务端的 SpringBoot 或 SpringCloud 等微服务应用是有状态的。服务端的内存中存在维持连接的 Session。客户端连接服务器时，只能和集群中的唯一一个服务实例来连接，而且数据传输过程中也直接和此实例通信。

解决方案有很多。

#方案一：将状态放到应用之外的存储中，但不可行

这个方案非常类似于 HTTP 协议的 Token 实现（非 JWT），Java 中具体的例子就是 Spring Session 以及 Spring Security 的 Token Store，比如 RedisTokenStore 实现了将 OAuth2 Token 存放到 Redis 的逻辑。此方案的核心前提是可序列化。WebSocket 协议和 HTTP 协议并不同，一个 WebSocket Session 对应于一次 TCP Socket 连接而非数据，新的连接将会基于新的四元组，不可能做到序列化。

#方案二：一致性哈希

像微服务注册中心一样，维护一个全局映射关系 —— 当前客户端的 WebSocket 连接是和哪一个实例/节点保持的。每次通信都经过此注册中心或哈希，查询到具体的服务实例，将连接交给它。同样会遇到一些问题，比如：哈希环的实现、如何解决一致性问题（单节点故障的 Session 迁移重连将代价降到最低）、CAP 取舍、实例的区分依据是什么（IP ? 实例 ID？）、可能与注册中心构成强依赖、以及部署环境的变更带来运维上的挑战等难题。这个方案实施有一定的成本和技术限制，可以参考这篇文章的大体思路，理解了核心的哈希环的概念(如下图)，再配合注册中心、服务上下线消息，就能完成基本的实现。我利用 Nacos、Redis、RabbitMQ 基于 Spring Cloud 写了一个通过一致性哈希来实现的全栈项目，前端和后端都已开源 —— WebSocket 集群的一致性哈希实践(Spring Cloud 后端) - GitHub , WebSocket 客户端模拟与服务列表(React 前端) - GitHub, 最近刚刚写好基本的功能，参考 @ufiredong 的方式利用 Java 语言的 Docker SDK 实现模拟 WebSocket 实例的上下线。未来还会稍微做细微的优化。欢迎提交 issue 或 pull request。

另外，Nacos 作为微服务的注册中心是国内比较流行的选择。但有人早就向 Nacos 社区提出了维护哈希环的议题；姑且不说此议题是否合理，但 Nacos 的维护人员竟然没有能够理解这样的需求，还是有点令人诧异。

最终效果如下, 上线一个新的服务实例后，客户端会自动根据最新哈希环重新路由到最新节点上，收发消息一切正常：

#方案三：广播队列

每次连接都需要通知到所有实例，实例各自都判断连接状态在不在自己这里，不在的话直接忽略，在就处理。类似于发布订阅模型，可以通过 MQ（RabbitMQ、Kafka、RocketMQ 等）或 Redis 做到。此方案实现简单，适用于集群规模不大的场景，因为需要所有的节点进行判断或计算。我愿称之为：分布式事件驱动。

以下基于 RabbitMQ 做了简单实现。

#简单广播实现 WebSocket 集群

声明式 API 的好处就体现在这里：短短几行就直接利用了 RabbitMQ 的 Java SDK 创建好交换机和队列以及绑定关系。

package me.lawrenceli.websocket.server.configuration;

import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.core.AnonymousQueue;
import org.springframework.amqp.core.Binding;
import org.springframework.amqp.core.BindingBuilder;
import org.springframework.amqp.core.FanoutExchange;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Slf4j
@Configuration
public class MqConfig {

    private static final String FANOUT_EXCHANGE = "websocket-exchange";

    @Bean
    public FanoutExchange fanoutExchange() {
        log.info("创建广播交换机 [{}]", FANOUT_EXCHANGE);
        return new FanoutExchange(FANOUT_EXCHANGE);
    }

    @Bean
    public AnonymousQueue queueForWebSocket() {
        log.info("创建用于 WebSocket 的匿名队列");
        return new AnonymousQueue();
    }

    /**
     * @param fanoutExchange    交换机
     * @param queueForWebSocket 队列
     * @return Binding
     */
    @Bean
    public Binding bindingSingle(FanoutExchange fanoutExchange, AnonymousQueue queueForWebSocket) {
        log.info("把匿名队列 [{}] 绑定到广播交换器 [{}]", queueForWebSocket.getName(), fanoutExchange.getName());
        return BindingBuilder.bind(queueForWebSocket).to(fanoutExchange);
    }

}

然后是生产者和消费者。生产者将消息发送到队列中进行广播，集群的消费者监听队列，判断此 WebSocket Session 是否在当前消费节点再做进一步处理。

消息生产方，一般是外层接收到消息通信请求，然后调用进行集群内广播：

package me.lawrenceli.websocket.server.configuration;

import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.core.FanoutExchange;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

@Slf4j
@Component
public class FanoutSender {

    @Autowired
    private FanoutExchange fanoutExchange;

    @Autowired
    private RabbitTemplate rabbitTemplate;

    public void send(Object message) {
        log.info("开始发送广播: [{}]", message.toString());
        rabbitTemplate.convertAndSend(fanoutExchange.getName(), "", message);
    }

}

消息消费方，多节点共同消费同一消息，区分是否需要自己来处理：

package me.lawrenceli.websocket.server.configuration;

import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.rabbit.annotation.RabbitListener;
import org.springframework.stereotype.Component;

@Slf4j
@Component
public class FanoutReceiver {

    @RabbitListener(queues = "#{queueForWebSocket.name}")
    public void singleReceiver(Object message) {
        log.info("队列接收到了消息: [{}]", message.toString());
        // 判断 WebSocket Session 是否在当前节点
        // 一般维护在一个 ConcurrentHashMap 静态变量中，这里叫 sessionMap
        // message 中有类似 SessionId 的字段
        if (sessionMap.contains(sessionId)) {
            log.info("WebSocket Session 在当前节点");
            // 执行相应的流程
        } else {
            log.info("当前节点无此 WebSocket Session");
            // 什么都不用做，直接忽略
        }
    }

}

注意，方案 2、方案 3 都没有解决单节点故障问题，因为从本质上讲，没有实现 WebSocket Session 的全局共享。但是方案二能够依赖哈希环的更新，最大程度上地降低迁移连接的代价，客户端会有重试的机制来针对单节点故障问题做容错。如果规模较大，项目复杂，且客户端连接数多，推荐使用一致性哈希的方案二，当然下面也有其他的社区方案。

#其他案例

即刻 App 后端基于 Node.js 使用了 socket.io 实现多端实时通信，Joway 的这篇文章交代的一些细节也涉及了分布式部署的问题。

socket.io 官网也提供了多节点的使用方法，不外乎 IP Hash 之类的方案。

#Kubernetes 内的 Websocket 集群

如果部署环境基于 Kubernetes 内的 WebSocket 集群，也可以参考阳明的这篇文章来实践（利用 Service 的 sessionAffinity 会话亲和确保每次将来自特定客户端的连接传递到同一 Pod：使用 ClientIP 声明）。

在 Kubernetes 中部署 Prow

2020-11-29T00:00:00.000Z

GitHub CI 🤖️ by Kubernetes

#Prow | praʊ |

noun. the pointed front part of a ship; the bow. 船首.

了解 Prow 可以参考这篇知乎专栏：Kubernetes 原生 CI/CD 系统 Prow 简介。

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

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

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

首先注册一个 GitHub 账号专门用于作为机器人账号，用此账号前往 GitHub Developer 页面创建一个 Token，权限参考上文，并邀请此账号作为 Collaborators 管理仓库。

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

openssl rand -hex 20 > hmac

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

纳入集群对象：

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 做简单修改，注意 Ingress 的域名，namespace 为 default：

# This file contains Kubernetes YAML files for the most important prow
# components. Don't edit resources in this file. Instead, pull them out into
# their own files.
---
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: default
  name: plugins
data:
  plugins.yaml: ""
---
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: default
  name: config
data:
  config.yaml: |
    prowjob_namespace: default
    pod_namespace: test-pods
    periodics:
    - interval: 10m
      agent: kubernetes
      name: echo-test
      spec:
        containers:
        - image: alpine
          command: ["/bin/date"]
---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: prowjobs.prow.k8s.io
spec:
  group: prow.k8s.io
  version: v1
  names:
    kind: ProwJob
    singular: prowjob
    plural: prowjobs
  scope: Namespaced
  validation:
    openAPIV3Schema:
      properties:
        spec:
          properties:
            max_concurrency:
              type: integer
              minimum: 0
            type:
              type: string
              enum:
                - "presubmit"
                - "postsubmit"
                - "periodic"
                - "batch"
        status:
          properties:
            state:
              type: string
              enum:
                - "triggered"
                - "pending"
                - "success"
                - "failure"
                - "aborted"
                - "error"
          anyOf:
            - not:
                properties:
                  state:
                    type: string
                    enum:
                      - "success"
                      - "failure"
                      - "error"
                      - "aborted"
            - required:
                - completionTime
  additionalPrinterColumns:
    - name: Job
      type: string
      description: The name of the job being run.
      JSONPath: .spec.job
    - name: BuildId
      type: string
      description: The ID of the job being run.
      JSONPath: .status.build_id
    - name: Type
      type: string
      description: The type of job being run.
      JSONPath: .spec.type
    - name: Org
      type: string
      description: The org for which the job is running.
      JSONPath: .spec.refs.org
    - name: Repo
      type: string
      description: The repo for which the job is running.
      JSONPath: .spec.refs.repo
    - name: Pulls
      type: string
      description: The pulls for which the job is running.
      JSONPath: ".spec.refs.pulls[*].number"
    - name: StartTime
      type: date
      description: When the job started running.
      JSONPath: .status.startTime
    - name: CompletionTime
      type: date
      description: When the job finished running.
      JSONPath: .status.completionTime
    - name: State
      description: The state of the job.
      type: string
      JSONPath: .status.state
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: default
  name: hook
  labels:
    app: hook
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  selector:
    matchLabels:
      app: hook
  template:
    metadata:
      labels:
        app: hook
    spec:
      serviceAccountName: "hook"
      terminationGracePeriodSeconds: 180
      containers:
        - name: hook
          image: magicsong/hook:v20190711-664ef040d
          args:
            - --dry-run=false
            - --config-path=/etc/config/config.yaml
          ports:
            - name: http
              containerPort: 8888
          volumeMounts:
            - name: hmac
              mountPath: /etc/webhook
              readOnly: true
            - name: oauth
              mountPath: /etc/github
              readOnly: true
            - name: config
              mountPath: /etc/config
              readOnly: true
            - name: plugins
              mountPath: /etc/plugins
              readOnly: true
          # livenessProbe:
          #   httpGet:
          #     path: /healthz
          #     port: 8081
          #   initialDelaySeconds: 3
          #   periodSeconds: 3
          # readinessProbe:
          #   httpGet:
          #     path: /healthz/ready
          #     port: 8081
          #   initialDelaySeconds: 10
          #   periodSeconds: 3
          #   timeoutSeconds: 600
      volumes:
        - name: hmac
          secret:
            secretName: hmac-token
        - name: oauth
          secret:
            secretName: oauth-token
        - name: config
          configMap:
            name: config
        - name: plugins
          configMap:
            name: plugins
---
apiVersion: v1
kind: Service
metadata:
  namespace: default
  name: hook
spec:
  selector:
    app: hook
  ports:
    - port: 8888
  type: NodePort
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: default
  name: plank
  labels:
    app: plank
spec:
  selector:
    matchLabels:
      app: plank
  replicas: 1 # Do not scale up.
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: plank
    spec:
      serviceAccountName: "plank"
      containers:
        - name: plank
          image: magicsong/plank:v20190711-664ef040d
          args:
            - --dry-run=false
            - --config-path=/etc/config/config.yaml
          volumeMounts:
            - name: oauth
              mountPath: /etc/github
              readOnly: true
            - name: config
              mountPath: /etc/config
              readOnly: true
      volumes:
        - name: oauth
          secret:
            secretName: oauth-token
        - name: config
          configMap:
            name: config
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: default
  name: sinker
  labels:
    app: sinker
spec:
  selector:
    matchLabels:
      app: sinker
  replicas: 1
  template:
    metadata:
      labels:
        app: sinker
    spec:
      serviceAccountName: "sinker"
      containers:
        - name: sinker
          image: magicsong/sinker:v20190711-664ef040d
          args:
            - --config-path=/etc/config/config.yaml
          volumeMounts:
            - name: config
              mountPath: /etc/config
              readOnly: true
      volumes:
        - name: config
          configMap:
            name: config
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: default
  name: deck
  labels:
    app: deck
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  selector:
    matchLabels:
      app: deck
  template:
    metadata:
      labels:
        app: deck
    spec:
      serviceAccountName: "deck"
      terminationGracePeriodSeconds: 30
      containers:
        - name: deck
          image: magicsong/deck:v20190711-664ef040d
          args:
            - --config-path=/etc/config/config.yaml
            - --tide-url=http://tide/
            - --hook-url=http://hook:8888/plugin-help
          ports:
            - name: http
              containerPort: 8080
          volumeMounts:
            - name: config
              mountPath: /etc/config
              readOnly: true
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8081
            initialDelaySeconds: 3
            periodSeconds: 3
          readinessProbe:
            httpGet:
              path: /healthz/ready
              port: 8081
            initialDelaySeconds: 10
            periodSeconds: 3
            timeoutSeconds: 600
      volumes:
        - name: config
          configMap:
            name: config
---
apiVersion: v1
kind: Service
metadata:
  namespace: default
  name: deck
spec:
  selector:
    app: deck
  ports:
    - port: 80
      targetPort: 8080
  type: NodePort
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: default
  name: horologium
  labels:
    app: horologium
spec:
  replicas: 1 # Do not scale up.
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: horologium
  template:
    metadata:
      labels:
        app: horologium
    spec:
      serviceAccountName: "horologium"
      terminationGracePeriodSeconds: 30
      containers:
        - name: horologium
          image: magicsong/horologium:v20190711-664ef040d
          args:
            - --config-path=/etc/config/config.yaml
          volumeMounts:
            - name: config
              mountPath: /etc/config
              readOnly: true
      volumes:
        - name: config
          configMap:
            name: config
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: default
  name: tide
  labels:
    app: tide
spec:
  replicas: 1 # Do not scale up.
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: tide
  template:
    metadata:
      labels:
        app: tide
    spec:
      serviceAccountName: "tide"
      containers:
        - name: tide
          image: magicsong/tide:v20190711-664ef040d
          args:
            - --dry-run=false
            - --config-path=/etc/config/config.yaml
          ports:
            - name: http
              containerPort: 8888
          volumeMounts:
            - name: oauth
              mountPath: /etc/github
              readOnly: true
            - name: config
              mountPath: /etc/config
              readOnly: true
      volumes:
        - name: oauth
          secret:
            secretName: oauth-token
        - name: config
          configMap:
            name: config
---
apiVersion: v1
kind: Service
metadata:
  namespace: default
  name: tide
spec:
  selector:
    app: tide
  ports:
    - port: 80
      targetPort: 8888
  type: NodePort
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  namespace: default
  name: ing
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
    - host: prow.your-domain.com # 这里换成你的域名
      http:
        paths:
          - path: / # Correct for GKE, need / on many other distros
            backend:
              serviceName: deck
              servicePort: 80
          - path: /hook
            backend:
              serviceName: hook
              servicePort: 8888
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: statusreconciler
  namespace: default
  labels:
    app: statusreconciler
spec:
  replicas: 1
  selector:
    matchLabels:
      app: statusreconciler
  template:
    metadata:
      labels:
        app: statusreconciler
    spec:
      serviceAccountName: statusreconciler
      terminationGracePeriodSeconds: 180
      containers:
        - name: statusreconciler
          image: magicsong/status-reconciler:v20190711-664ef040d
          args:
            - --dry-run=false
            - --continue-on-error=true
            - --plugin-config=/etc/plugins/plugins.yaml
            - --config-path=/etc/config/config.yaml
            - --github-token-path=/etc/github/oauth
          volumeMounts:
            - name: oauth
              mountPath: /etc/github
              readOnly: true
            - name: config
              mountPath: /etc/config
              readOnly: true
            - name: plugins
              mountPath: /etc/plugins
              readOnly: true
      volumes:
        - name: oauth
          secret:
            secretName: oauth-token
        - name: config
          configMap:
            name: config
        - name: plugins
          configMap:
            name: plugins
---
apiVersion: v1
kind: Namespace
metadata:
  name: test-pods
---
kind: ServiceAccount
apiVersion: v1
metadata:
  namespace: default
  name: "deck"
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: "deck"
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: "deck"
subjects:
  - kind: ServiceAccount
    name: "deck"
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: test-pods
  name: "deck"
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: "deck"
subjects:
  - kind: ServiceAccount
    name: "deck"
    namespace: default
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: "deck"
rules:
  - apiGroups:
      - "prow.k8s.io"
    resources:
      - prowjobs
    verbs:
      - get
      - list
      # Required when deck runs with `--rerun-creates-job=true`
      # **Warning:** Only use this for non-public deck instances, this allows
      # anyone with access to your Deck instance to create new Prowjobs
      # - create
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: test-pods
  name: "deck"
rules:
  - apiGroups:
      - ""
    resources:
      - pods/log
    verbs:
      - get
---
kind: ServiceAccount
apiVersion: v1
metadata:
  namespace: default
  name: "horologium"
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: "horologium"
rules:
  - apiGroups:
      - "prow.k8s.io"
    resources:
      - prowjobs
    verbs:
      - create
      - list
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: "horologium"
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: "horologium"
subjects:
  - kind: ServiceAccount
    name: "horologium"
---
kind: ServiceAccount
apiVersion: v1
metadata:
  namespace: default
  name: "plank"
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: "plank"
rules:
  - apiGroups:
      - "prow.k8s.io"
    resources:
      - prowjobs
    verbs:
      - get
      - create
      - list
      - update
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: test-pods
  name: "plank"
rules:
  - apiGroups:
      - ""
    resources:
      - pods
    verbs:
      - create
      - delete
      - list
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: "plank"
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: "plank"
subjects:
  - kind: ServiceAccount
    name: "plank"
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: test-pods
  name: "plank"
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: "plank"
subjects:
  - kind: ServiceAccount
    name: "plank"
    namespace: default
---
kind: ServiceAccount
apiVersion: v1
metadata:
  namespace: default
  name: "sinker"
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: "sinker"
rules:
  - apiGroups:
      - "prow.k8s.io"
    resources:
      - prowjobs
    verbs:
      - delete
      - list
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: test-pods
  name: "sinker"
rules:
  - apiGroups:
      - ""
    resources:
      - pods
    verbs:
      - delete
      - list
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: "sinker"
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: "sinker"
subjects:
  - kind: ServiceAccount
    name: "sinker"
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: test-pods
  name: "sinker"
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: "sinker"
subjects:
  - kind: ServiceAccount
    name: "sinker"
    namespace: default
---
apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: default
  name: "hook"
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: "hook"
rules:
  - apiGroups:
      - "prow.k8s.io"
    resources:
      - prowjobs
    verbs:
      - create
      - get
  - apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - create
      - get
      - update
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: "hook"
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: "hook"
subjects:
  - kind: ServiceAccount
    name: "hook"
---
apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: default
  name: "tide"
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: "tide"
rules:
  - apiGroups:
      - "prow.k8s.io"
    resources:
      - prowjobs
    verbs:
      - create
      - list
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: "tide"
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: "tide"
subjects:
  - kind: ServiceAccount
    name: "tide"
---
apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: default
  name: "statusreconciler"
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: "statusreconciler"
rules:
  - apiGroups:
      - "prow.k8s.io"
    resources:
      - prowjobs
    verbs:
      - create
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: "statusreconciler"
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: "statusreconciler"
subjects:
  - kind: ServiceAccount
    name: "statusreconciler"

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

curl -L https://git.io/JIJ4c -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/ 。

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

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

激活并保存。

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

插件的声明：

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 的配置：

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"

应用更改：

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 的官方仓库或我的这个 node 命令行翻译项目。

#使用 Prow

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

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

ProwJob 主要用于 PR 流程的 CI 测试，而国内网络原因无法使用 Google 的 GCS 服务，ProwJob 中 plank 依赖的 Pod Utilities，其中定义 GCS Bucket 用于存放构建产物、日志等内容，因此，我们似乎只能自己用自定义的镜像来跑临时 CI 任务了。注意定义 presubmit 字段下的 decorate 为 false，并利用好 Prow 提供的一些环境变量。

下面是我的一个简单的 Spring Boot 项目利用 Maven 镜像（配合阿里云的 Maven Repo）来做的 presubmits，同样在 config.yaml 中添加：

presubmits:
  Lonor/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。

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

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

#自研 Issue/PR Bot

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

Long Live RSS

2020-09-30T00:00:00.000Z

RSS: A family of Web feed formats used to publish frequently updated works (blog entries, news headlines, audio, and video) in a standardized format. Aaron Swartz helped create it at the age of 14 and committed suicide at 26.

Here are some good feed I subscribed for reading:

https://blog.yitianshijie.net/feed/

https://byvoid.com/zhs/feed.xml

https://martinfowler.com/feed.atom

https://sspai.com/feed

http://www.qdaily.com/feed.xml

https://www.solidot.org/index.rss

https://blog.shuziyimin.org/feed

https://www.thetype.com/feed/

http://www.aaronsw.com/2002/feeds/pgessays.rss

Some apps for RSS were removed from the Chinese App Store in the autumn of 2020.

https://twitter.com/reederapp/status/1310963891539709952

https://twitter.com/FieryFeeds/status/1310553289545658369

https://twitter.com/Inoreader/status/922363626329133057

https://twitter.com/yitianshijieipn/status/1311127240713711616

There's a great web app for everyone to build the RSS feed with JavaScript: RSSHub.

You can visit the RSSHub doc to use it.

The author of RSSHub deployed it on https://rsshub.app .

As a contributor for RSSHub, I'm also glad to share my self-hosted RSSHub for you:

https://feed.lawrenceli.me .

I'll try to keep my repository in sync with the official RSSHub git repository every week.

Enjoy reading.

Solidot 机器人

2020-09-05T00:00:00.000Z

#奇客的资讯，重要的东西 🤖️

这是中国社交网络饭否上的一个机器人。它是一个基于 Vercel 、mongoDB 的免费数据库、以及 GitHub Action 提供的声明式定时任务一起运行来实现的 Serverless 实践。作者充分利用互联网现代基础设施~~(白嫖)~~，让它每隔一段时间（目前为 30 分钟）爬取 solidot.org 网站的 RSS，比较新旧的数据后，将新的内容通过饭否 Node SDK 发布。

源代码以 MIT 协议开放，写的很简陋，凑合着能用。

你也可以帮我调用这个 REST API 来帮助触发机器人行动：

curl -XGET -L https://post-solidot-news-to-fanfou.now.sh/api/start

若返回空数组则 Robot 🤖️ 没有抓取到新闻，反之则返回饭否 API 的响应。

机械同理心

2019-12-29T00:00:00.000Z

Martin Thompson 和 Dave Farley 多年来一直在讨论软件开发的「机械同理心」。他们的灵感来自一级方程式赛车手 Jackie Stewart 的名言，「要想成为一名赛车手，你不必成为一名工程师，但你必须有机械同理心。」了解赛车的运作方式会让你成为更好的赛车手，同样，程序员如果理解计算机硬件的工作原理也会有助于编程。你不一定需要获得计算机科学学位或者成为一名硬件工程师，但是你确实需要了解硬件的工作原理，并在设计软件时考虑这一点。

前段时间阅读了《Java 持续交付》，这里分享分享心得。

声明式编程

2019-12-29T00:00:00.000Z

写 YAML 上瘾了。

命令式编程注重过程，声明式编程注重结果。前者强调代码本身的逻辑，需要开发者重视程序的上下文，以一步一步地实现应用功能。后者基于完善的 API / SDK，告诉（声明）程序需要达到的状态，程序会主动向其驱动以达到声明的目标，有时甚至无需在意底层实现。

优雅的 API 往往是声明式的，通常也非常简洁明了。

这里我举一个电风扇和空调的例子：

电风扇：为了实现体表温度的控制，人类利用电动机发明了电风扇，一个命令式风速调节客户端 —— 大部分你需要自己手动地调节电风扇的风向、风速，让身体接受风扇的水平气压梯度力，以让体表流体流动速度上升从而达到吸热的目的。你可能已经间接地知道了它的实现原理，尽管这个流程并不复杂。

空调：它是声明式的。你无需关注空调自身的实现原理，只需要通过遥控器声明它应当达到的温度即可，空调就会驱动自身来实现密闭空间的恒温调节到达期望值 —— 哪怕空间的温度骤变。

虽然栗子并不够恰当，但是我们拥有了倾向意识：空调调节起来多简单方便！

软件开发亦如此。

我们其实早已经频繁地和声明式编程打交道了：其实 HTML、CSS、SQL 这些语言自己就是声明式语言；纯函数编程语言也被认为是声明式语言，这非常有趣。另外，前端流行的 React、Vue 都利用了 Virtual DOM 和 diff 算法实现了声明式的 JavaScript 用户界面框架，再也不需要前端开发者去使用 jQuery 或原生写法来操作 DOM。

Java 开发者在开发阶段使用声明式 API 的最典型例子就是运用注解。比如 Spring 提供 @Autowired 注解实现 Bean 的依赖注入，其实现是基于 Java 语言的反射。Spring 更是提供了大量内置的注解简化了开发人员的开发: @Transactional 实现声明式事务, @Component , @Value, @Data ...

首个毕业于 CNCF 的项目 Kubernetes 中也在充分地让 DevOps 拥抱声明式。它提供了给予 YAML 语法的配置文件（用以描述容器集群的拓扑状态），自动地向配置的声明驱动。云原生应用的一个必要特性就是声明式。

GraphQL 让原本的 REST 更加声明式。这是一个非常适合全栈开发的 HTTP 接口规范，热度最近有在攀升，能否颠覆 REST 不得而知。

Apple 在 WWDC 2019 上发布的 SwiftUI 和 Google 开源的 Flutter 一样都是移动端的原生声明式 UI 框架。

Maven、Gradle、npm、yarn、pip、go module 等提供了 Java、JavaScript / TypeScript、Python、GoLang 开发者声明式依赖管理工具，现代的应用开发几乎离不开它们。

GitHub、GitLab、Jenkins Pipeline 提供了基于声明式配置文件（大部分为 YAML）的持续集成流水线，可以让开发人员也能低成本地学习实践 CI/CD。

开发声明式 API 是很困难的，往往需要开发人员对语言以及框架的拥有深刻认知，并且是一种「将复杂留给自己，将方便留给别人」的美德。

单纯作为用户而言，效率、便利、无副作用是声明式 API 的目的。而作为软件开发者，去意识到这些声明式应用或框架的背后原理往往会更加明白创作者的真实意图，也能更清晰自己所做的声明、或是充分优化应用层代码，而避免陷入路径依赖与货物崇拜编程的怪圈。

Links:

https://spring.io/guides/gs/rest-service/

https://www.infoq.cn/article/rest-apis-are-rest-in-peace-apis-long-live-graphql

https://kubernetes.io/zh/docs/tasks/manage-kubernetes-objects/declarative-config/

Kubernetes Notes

2019-10-01T00:00:00.000Z

大部分内容皆来源于 Kubernetes 官网。

Kubernetes 中文概述（是什么以及不是什么）。

实践时建议使用 kubectl 自动补全，极大提升交互效率。

#Pod

Pod 是比容器更高一层次的抽象，同一 Pod 中的所有容器共享

同一网络 namespace
存储

#Controller

Deployment
ReplicaSet
DaemonSet
StatefulSet
Job

#Service

是一个四层负载均衡器，为 Pod 提供负载均衡。

#MiniKube

国内建议自定义镜像仓库，默认是 gcr.io ，似乎自带了 PV。

minikube start --vm-driver=none --image-repository=registry.cn-hangzhou.aliyuncs.com/google_containers --cpus 4 --memory 6144

感觉 Docker Desktop 内置的 Kubernetes 有点类似这个 minikube （master 可以直接运行 Pod，也就是单节点集群）。当然了，它们都只能用于开发/测试环境。

#Demo

用 Spring Boot 创建了一个 HTTP 服务端，可以尝试用 Kubernetes 部署它。

#公网服务器集群初始化常用脚本

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF

yum install -y kubeadm-1.19.13-0 kubelet-1.19.13-0 kubectl-1.19.13-0

kubeadm config images pull --image-repository registry.aliyuncs.com/google_containers --kubernetes-version v1.19.3

kubeadm init --image-repository registry.aliyuncs.com/google_containers --kubernetes-version v1.19.13 --apiserver-advertise-address $(hostname -i) --pod-network-cidr=10.96.0.0/16 --service-cidr=10.97.0.0/16

mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
chown $(id -u):$(id -g) $HOME/.kube/config

Flannel:

wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml](https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml)

kubectl apply -f kube-flannel.yaml

运行 Master 作为 Node:

kubectl taint node $HOSTNAME node-role.kubernetes.io/master-

恢复 Master 不可调度：

kubectl taint node $HOSTNAME node-role.kubernetes.io/master="":NoSchedule

重置：

kubeadm reset
systemctl stop kubelet
rm -rf /var/lib/cni/
rm -rf /var/lib/etcd/
rm -rf /var/lib/kubelet/
rm -rf /etc/cni/
rm -rf $HOME/.kube
ifconfig cni0 down
ifconfig flannel.1 down
ifconfig docker0 down
ip link delete cni0
ip link delete flannel.1
systemctl restart kubelet
systemctl stop docker
systemctl restart docker

Pod 无法访问外网，尝试：

iptables -P FORWARD ACCEPT
iptables --flush
iptables -tnat --flush

iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X
# POD 无法访问外网络，但是可以互相 ping 或 ping 宿主。CIDR 为 POD CIDR
# 有可能是 SNAT 时出了问题，使用动态 SNAT （即 MASQUERADE） 来配置 nat 表路由规则：
iptables -t nat -I POSTROUTING -s 10.96.0.0/16 -j MASQUERADE
# 再尝试重新运行 core dns 服务

https://github.com/rancher/rancher/issues/6139

https://github.com/coredns/coredns/issues/2693

网络调试：使用 BusyBox:1.28.3，不建议使用 latest 镜像.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox
  namespace: default
  labels:
    app: busybox
spec:
  selector:
    matchLabels:
      app: busybox
  replicas: 1
  template:
    metadata:
      labels:
        app: busybox
    spec:
      containers:
      - name: busybox
        image: busybox:1.28.3
        command:
          - sleep
          - "3600"
        imagePullPolicy: IfNotPresent
      restartPolicy: Always

基于 DNS 的服务发现： Kubernetes Service / Pod 对象资源可以使用集群内部 FQDN 来访问，而不需要在意其扁平空间中的 Cluster IP。 Core DNS 会将 FQDN 动态地指向最新的 Cluster IP。参考 Pod 与 Service 的 DNS:

kubectl exec busybox -it -- nslookup kubernetes

返回内容：

Server:    10.97.0.10
Address 1: 10.97.0.10 kube-dns.kube-system.svc.cluster.local

Name:      kubernetes
Address 1: 10.97.0.1 kubernetes.default.svc.cluster.local

The World As I See It

2019-08-18T00:00:00.000Z

爱因斯坦的美国观。

What first strikes the visitor with amazement is the superiority of this country, in matters of technics and organization. Objects of everyday use are more solid than in Europe, houses infinitely more convenient in arrangement. Everything is designed to save human labour. Labour is expensive, because the country is sparsely inhabited in comparison with its natural resources. The high price of labour was the stimulus which evoked the marvelous development of technical devices and methods of work.

这段话由爱因斯坦在《 The World As I See It 》中提到。

美国高昂的人力成本促使技术设备、工作方式的惊人发展。现在想想一个案例：中国之所以至今仍有很多挨家挨户抄水电表的人员，不是因为技术上实现不了自动化，而是中国人口太多，社会就业压力大，宁可牺牲效率来换稳定。

站着说话不腰疼的我自己一直奉行一个原则：拒绝机械重复劳作，应当充分发挥机器的优势和人类的主观能动，即将有规则的、确定的流程交给机器去执行，而把富有创造性的工作交给人类。

BLM 运动此起彼伏，许多开源项目在其官网首页顶部加上了醒目的 Slogan，对于美国系统性种族主义此文不作讨论。Kubernetes 官网谈了它的社区的价值观，我认为这也是多数开放源码项目社区的价值观：

We value time spent automating repetitive work more highly than toil.

路径依赖与货物崇拜

2019-03-12T00:00:00.000Z

警惕、避免。

路径依赖原本是经济学中的一个名词，我并不深知其具体领域的定义，但用通俗的话来解释起来非常简单：过去的决策将会限制、缩小未来的可选择性。

笔者首次了解「路径依赖」是源于 BYVoid 的博客文章—— 在 Google 的这四年。类比成贪心算法的局限，他提出的解决方案是模拟退火:

模拟退火算法的理念是在初期引入随机性，随着迭代次数的增加而减小随机因子，这样最终收敛到全局最优解的机率更大。跟随这个理念来考虑职业的选择，我决定跳出现有的路径，哪怕是这个路径的前方一片光明，现在只是为了体验不同的选择。

再讲一个宗教故事。

二战期间，美军在太平洋的塔纳岛上建了一个临时基地。岛上原住民看到美军的战斗机，以为是「大铁鸟」。美军还会送一些有用的物资给岛上原住民。原住民没见过世面，都以为美军是神。后来，二战结束，美军撤走，还留了一点物资在岛上。岛上居民认为这些物资很神奇，相信这些美国大兵还会送货物过来，纷纷信仰、崇拜起了美军军服和物资（以吸引「大铁鸟」降临）。基于此，原住民发展出了自己的宗教—— 约翰弗鲁姆教。这就是货物崇拜（Cargo Cult）。

货物崇拜在软件工程领域延伸出了货物崇拜软件工程与货物崇拜编程。

货物崇拜软件工程是货物崇拜科学的一个实例。货物崇拜科学是诺奖得主 Richard Feynman 于 1974 年提出的一门伪科学概念。这种类似科学的方法论从道德上就背叛了科学精神。

以下为货物崇拜软件工程的主观实践：

盲目模仿成功开发团队的表面现象
机械套用软件开发过程却不知其由（即货物崇拜编程）
把 996 当作福报

货物崇拜和路径依赖存在交集。具体表现在开发者的机械式开发。最常见的是：

jQuery 一把梭

我发现有前端开发者会在使用 Vue 的情况下竟然依旧使用 jQuery 操作 DOM。这是典型的货物崇拜编程实践，因为这样的开发人员完全不理解 Vue 是做什么的，因为 Ta 已经习惯了 $ 的 API，哪管 DOM Virtual 不 Virtual；姑且撇开 Virtual DOM 的性能不说，这样做的开发人员往往也没能够理解声明式 UI 框架的内涵。

上文提到的「模拟退火」是破解路径依赖困境的法则之一。除此之外，笔者认为最适合大多数人的做法是对事物保持强烈的好奇心。正如 Aaron Swartz 所云：

Be curious. Read widely. Try new things. What people call intelligence just boils down to curiosity.

一些链接：

如何「评价老夫写代码就用 jQuery 」[图]

维基百科：货物崇拜编程

Quote from Aaron Swartz

四层负载均衡和七层负载均衡

2018-10-09T00:00:00.000Z

对于初次了解负载均衡的人来说，可能会被理解成「四次负载均衡」、「七次负载均衡」，这就完全错了。这里要理解的话直接参考英文：layer 4 load-balancing & layer 7 load-balancing. 其实应当理解为工作在 OSI 第四层、第七层的负载均衡。

所以，所谓的层指的是 OSI 网络模型中的层次，分别对应于传输层（比如 TCP）和应用层（具体的 Application）。

因此，基于 OSI 模型，先讲一个三层负载均衡的例子，DNS 解析，同一个域名可以解析到多个 IP 上，但轮询策略不在自己手上；四层负载均衡其实是在三层基础上加上了端口，也就是通过 IP + Port 的形式进行转发，而七层负载均衡在四层的基础上考虑应用的 URL 等方式做转发。

由于三、四层负载均衡直接偏底层一些，其代理的效率会比七层的更高，比如单从 TCP 的开销上来看：四层负载均衡时，服务端收到来自客户端的请求，根据负载均衡器的策略，对目标 IP/Port 做修改，转发到对应的后端服务，TCP 三次握手直接一次建立。而七层负载均衡工作在应用层，客户端必须首先与负载均衡器进行一次 TCP 握手，然后负载均衡器再与目标后端服务建立第二次 TCP 握手。相比之下，七层负载均衡的性能就弱了。

一个常见的现象：效率和安全（功能）往往不可兼得。七层负载均衡效率不高，其优势却在于可以植入一些应用上的逻辑，做流量压缩、鉴权、服务迁移、降级、熔断等处理，其可塑性会更好一点，且相对四层可以做一些安全上的设计，因为四层的负载均衡相当于直接间接地暴露了后端服务却难有应用层的调度。四层负载均衡器可以通过硬件实现，比如 F5，常见的软件实现是 lvs、nginx 中的 stream block，Kubernetes 中的 Service 对象。七层负载均衡器一般是一些高性能网关，比如 OpenResty，Kubernetes 中的 Ingress 对象。

参考链接：

四层、七层负载均衡的区别 - Jamin Zhang

Invert binary tree

2017-12-22T00:00:00.000Z

A problem that Homebrew's author complained.

Invert a binary tree. Problem from leetcode.

Here's the input:

     4
   /   \
  2     7
 / \   / \
1   3 6   9

and the out put looks like:

     4
   /   \
  7     2
 / \   / \
9   6 3   1

This problem was inspired by this tweet:

https://twitter.com/mxcl/status/608682016205344768

Here's the solution implemented in Java.

/**
 * Definition for a binary tree node.
 * public class TreeNode {
 *     int val;
 *     TreeNode left;
 *     TreeNode right;
 *     TreeNode(int x) { val = x; }
 * }
 */
class Solution {
    public TreeNode invertTree(TreeNode root) {
        if(null != root){
            TreeNode leftChild = root.left;
            root.left = root.right;
            root.right = leftChild;
            root.left = invertTree(root.left);
            root.right = invertTree(root.right);
        }
        return root;
    }
}

There's much different logic behind software engineering with computer science. Max replied this question about it on quora.com after 2 years.

没有银弹

2017-09-01T00:00:00.000Z

软件工程的一般规律。

维基： https://zh.wikipedia.org/wiki/没有银弹

文献：Brooks, F. P.，"No silver bullet—essence and accidents of software engineering, " in Information Processing 86, H. J. Kugler, ed. Amsterdam: Elsevier Science (North Holland), 1986, pp. 1069-1076.

结论：不会有任何单一的软件工程上的突破（银弹），能够让程序设计的生产力得到一个数量级的提升。

「人月神话」

维基：https://zh.wikipedia.org/wiki/人月神话

豆瓣：https://book.douban.com/subject/1102259/

结论：人力和时间并不呈现线性关系。以大量人员和较短的时间，并不能缩短软件的开发进度。

公式：

沟通管道数量（n 为一个项目团队中的人数，显然，人数越多，沟通成本越大）：

p = n(n-1)/2

Brooks 法则：

Adding manpower to a late software project makes it later.

组织：

提倡类似外科手术团队的组织。在接受相同的训练、同样都是两年资历的情况下，优秀专业程序员的生产力要比差劲的程序员好上十倍。

系统设计的民主与专制：

整体性：需要专制，设计必须出自于一个人的想法，或是极少数人的一致决定。

评价标准：功能概念复杂度比。功能多不见得是好事。

避免第二系统过度设计。

Pull Request

2017-01-01T00:00:00.000Z

What and How.

Pull Request 是 GitHub 发明的用于 Git 多人协作开发的模式。

官方文档里有不少详细的定义： GitHub Docs

我画了一个简单的示意图解释具体的行为：

以下是我自己的认识：

首先，存在一个上游（upstream）仓库，仓库地址一般的 URL 都是类似 REST 样式的路径，比如：

github.com/kubernetes/website

第一个路由为仓库的拥有者，第二个路由为项目名。上面的 URL 可以非常形象地理解为：

托管在 GitHub 上面的由 Kubernetes 作者开发的 website 项目。

然后，我们采取 fork （复刻）动作来将 upstream 仓库此刻的代码复制到自己的仓库中，于是产生了源（origin）仓库，地址类似于：

github.com/Lonor/website

现在，可以使用如下命令来获取到 origin 代码到本地：

git clone git@github.com:Lonor/website.git

OK! 我们已经一步一步拿到了代码，用 IDE 打开这个仓库，不着急更改内容，先看一下本地仓库关联了哪些远程仓库，使用如下命令查看：

git remote -v

它至少会返回我们 clone 的仓库地址。但是并没有呈现出 upstream 地址，我们需要手动添加：

git remote add upstream git@github.com:kubernetes/website.git

这时候就关联好了，这一步很关键：因为会牵涉到多人协作时发生的同步复刻 (Sync fork)。

现在尝试修改代码，比如修复某个臭虫（俗称 bug），或者增加某种需要的功能。然后，以 master 分支为例，push 到 origin：

git add .
git commit -m "bug fixed"
git push -u origin master

现在，刷新远程仓库 Web 端页面，可以发现代码已经提交好了。接下来，创建 Pull Request （拉取请求）。

#如何理解 Pull Request？

我们所做的是向 upstream 仓库贡献自己写的代码，为什么叫 Pull Request 而不叫 Merge Request 呢？这样理解，本质是对的。GitLab 就采用了 Merge Request 的叫法。但是 GitHub 认为，origin 仓库开发者并没有权限直接向 upstream 仓库直接提交代码，但是，origin 仓可以向 upstream 发一个请求，让 upstream 仓库主动拉取 origin 仓库的变更代码，以此实现合并的目的。

欲了解更多，可以参考知乎上有关 Pull Request 的讨论。

现在 Pull Request 创建好了！它会在 upstream 仓库的 Pull Requests 页面下出现，URL 一般长这样：

github.com/kubernetes/website/pull/21198

这个过程非常有用！尤其对于持续集成能产生很大的效率。

我理解的 Pull Request 本质上是一个分支，归到底还是一个指向某一系列提交之首的指针或引用。

使用如下命令可以在本地仓库切到 GitHub 上 233 的 Pull Request 合并前或合并后的 commit Head:

git config remote.origin.fetch '+refs/pull/*:refs/remotes/origin/pull/*'
git fetch
git show-ref
# Pull Request 合并之前
git checkout origin/pull/123/head
# Pull Request 合并之后
git checkout origin/pull/123/merge

这样就能够在某个 PR 上做一些集成测试了。

#Merge

在 GitHub 上合并 Pull Request 有三种方式：Merge、Squash 以及 Rebase. 主要区别：

Merge: 除了 PR 上所有的 commit，merge 时会再 commit 一次
Squash: 将 PR 上所有的 commit 压缩成一次 commit
Rebase: 执行变基操作后追加到被合并分支

直接 Merge 是大多数人的选择，但是我自己偏好使用 Rebase，这种做法会保持主分支的干净简洁。

今天先到这里，有空继续写。

When to Use Static Generation v.s. Server-side Rendering

1970-01-02T00:00:00.000Z

We recommend using Static Generation (with and without data) whenever possible because your page can be built once and served by CDN, which makes it much faster than having a server render the page on every request.

You can use Static Generation for many types of pages, including:

Marketing pages
Blog posts
E-commerce product listings
Help and documentation

You should ask yourself: "Can I pre-render this page ahead of a user's request?" If the answer is yes, then you should choose Static Generation.

On the other hand, Static Generation is not a good idea if you cannot pre-render a page ahead of a user's request. Maybe your page shows frequently updated data, and the page content changes on every request.

In that case, you can use Server-Side Rendering. It will be slower, but the pre-rendered page will always be up-to-date. Or you can skip pre-rendering and use client-side JavaScript to populate data.

Two Forms of Pre-rendering

1970-01-01T00:00:00.000Z

Next.js has two forms of pre-rendering: Static Generation and Server-side Rendering. The difference is in when it generates the HTML for a page.

Static Generation is the pre-rendering method that generates the HTML at build time. The pre-rendered HTML is then reused on each request.
Server-side Rendering is the pre-rendering method that generates the HTML on each request.

Importantly, Next.js lets you choose which pre-rendering form to use for each page. You can create a "hybrid" Next.js app by using Static Generation for most pages and using Server-side Rendering for others.