GitOps是Weaveworks提出的一种持续交付方式。其工作原理，是利用Git作为声明基础设施与应用程序的单一事实来源。

本文我们将通过一个简单的项目，了解如何设置典型的CI/CD流水线，而后通过修改将GitOps添加到其中。同时，我们还将演示Flux——GitOps的核心组件。几周之前，Flux已经被CNCF正式接纳为沙箱培养项目。

我们要做什么

下面，我们先来看看整个流程中的具体操作步骤：

对GitOps进行简单介绍
设置一个简单的项目，并在GitLab之内进行管理
集成一个Kubernetes集群
设置一条典型的CI/CD流水线
利用GItOps处理其中的CD部分

什么是GitOps？

GitOps是一种持续交付实现方式。其将Git作为声明基础设施与应用程序的事实来源。当对Git进行变更时，自动交付流水线也会对您的基础设施进行相应变更。

将变更部署至集群：push与pull

在一条典型的CI/CD流水线当中，CI工具负责运行测试、构建镜像、检查CVE并将新镜像重新部署至集群当中，具体如下图所示。

典型的CI/CD流水线（图片来源：Weaveworks）

GitOps方法的区别在于，其中的部署部分不再由CI工具完成，而是由操作程序通过集群内Pod中的运行进程完成（由Flux负责实现）。

包含GitOps的CI/CD流水线（图片来源：Weaveworks）

相关组件

下图所示为在Kubernetes集群当中使用GitOps时所需要用到的各组件。

在Kubernetes集群当中的各GitOps组件（图片来源：Weaveworks）

为了简单起见，Flux守护程序会不断运行并检查是否存在新的Docker镜像。检测到新镜像之后，它会调用API Server对当前正在运行的部署加以更新。

在本文的最后一部分中，我们将设置Flux并利用它部署一款简单的应用程序。

我们的项目

在这里，我们使用一个非常简单的Flask应用程序。项目的复杂程度并不重要，真正重要的是理解整个CI/CD流程的实现方式。

源代码

我们只需要考虑以下文件：

app.py用于公开一个单独的HTTP端点并返回一个字符串

from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello World!"

if __name__ == "__main__":
    app.run(host='0.0.0.0', port=8000)

requirements.txt 用于定义 app.py所需要的依赖性，即Flask库

Flask==1.0.2```

Dockerfile 用于通过源代码构建起一套镜像

FROM python:3-alpine
COPY . /app
WORKDIR /app
RUN pip install -r requirements.txt
CMD python /app/app.py

确保一切正常

我们先通过以下命令为我们的应用程序创建第一套Docker镜像：

$ docker image build -t hello:1.0 .

在镜像构建完毕之后，我们可以运行容器以使用该镜像。

$ docker container run -p 8000:8000 hello:1.0
 * Serving Flask app “app” (lazy loading)
 * Environment: production

注意：不要在生产环境当中使用该开发服务器，请使用生产WSGI服务器作为替代。

* Debug mode: off

* Running on http://0.0.0.0:8000/ (Press CTRL+C to quit)

我们的服务器在监听端口8000，如下图所示。

GitLab项目

我们将利用GitLab管理这款应用程序，下面创建一个名为hello的新项目：

在GitLab当中创建一个新项目

接下来，我们可以为该应用程序文件夹进行git初始化，并将一切push至GitLab项目当中：

$ git init
$ git remote add origin git@gitlab.com:lucj/hello.git
$ git add .
$ git commit -m "Initial commit"
$ git push -u origin master

几秒之后，我们可以通过GitLab的Web界面看到该项目中的三个文件。

代码的首次commit

迎接Kubernetes

由于需要在Kubernetes集群上部署我们的应用程序，所以这里我们将使用GitLab的Kubernetes集成功能将外部集群的配置导入项目当中。

创建一个托管集群

DOKS (DigitalOcean 托管 Kubernetes 集群) 是我个人最喜爱的解决方案，其易于设置及使用。我们可以通过DigitalOcean Web界面或者使用专门的doctl命令行界面进行创建。在本示例中，我们将设置一套包含3个工作节点的集群，其中管理器节点由DIgitalOcean替我们管理。

通过DigitalOcean的Web界面创建托管Kubernetes集群

配置基础设施以及创建集群大概需要几分钟的时间。完成之后，我们需要检索kubeconfig文件，以确保我们的kubectl客户端能够与集群的API服务器通信。我们将使用doctl命令并将该配置保存在k8s-demo.cfg文件当中：

$ doctl k8s cluster cfg show k8s-demo > k8s-demo.cfg

接下来，我们配置kubectl以使其与我们的集群进行通信，从而设置KUBECONFIG环境变量：

$ export KUBECONFIG=$PWD/k8s-demo.cfg

搞定。下面我们来看看目前的集群状态：

$ kubectl get nodes
NAME            STATUS   ROLES    AGE     VERSION
k8s-demo-rlf5   Ready    <none>   2m10s   v1.15.2
k8s-demo-rlfh   Ready    <none>   2m40s   v1.15.2
k8s-demo-rlfk   Ready    <none>   2m33s   v1.15.2

与GitLab项目相集成

通过GitLab的Web界面，我们可以轻松将外部Kubernetes集群集成至项目当中。我们只需要进入Operations > Kubernetes，而后点击Add Kubernetes cluster即可：

Kubernetes集群的集成操作

接下来，我们需要选择Add existing cluster选项卡。在这里，我们需要填写几个字段，其中第一个字段可以从配置文件当中轻松检索到：

需要在Kubernetes集群集成过程中填写的字段

集群名称
API Server的URL
集群的CA证书

要向GitLab当中添加集群CA证书，我们需要解码配置中指定的证书（以base64形式编码）。

$ kubectl config view --raw \
-o=jsonpath='{.clusters[0].cluster.certificate-authority-data}' \
| base64 --decode

服务令牌

整个令牌获取过程分为几个步骤。我们首先需要创建一个ServiceAccount，并为其提供cluster-admin角色。具体操作命令如下：

$ cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: gitlab-admin
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: gitlab-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: gitlab-admin
  namespace: kube-system
EOF

在ServiceAccount创建完成之后，我们开始检索相关Secret：

$ SECRET=$(kubectl -n kube-system get secret | grep gitlab-admin | awk '{print $1}')
add extract its JWT token, the one we need to enter in the Service Token field in the GitLab interface:
$ TOKEN=$(kubectl -n kube-system get secret $SECRET -o jsonpath='{.data.token}' | base64 --decode) && echo $TOKEN

在对集群集成进行验证之前，我们取消原本被选中的GitLab-managed-cluster复选框，这代表着我们将自行管理命名空间。

在集群集成完毕后，GitLab即可通过Helm图表一键安装多款应用程序。不过这不是今天讨论的重点，因此不再赘述。

Kubernetes集群与我们的GitLab项目顺利集成

设置一条典型的CI/CD流水线

我们首先在项目的root目录处添加一个.gitlab-ci.yml文件。该文件用于定义每当有新代码被提交至代码库时，所应触发的具体操作。

在文件开头，我们首先定义流水线中的不同阶段：

stages:
  - package
  - test
  - push
  - deploy

在各个阶段当中，我们进一步定义需要执行的操作：

其中的package阶段负责利用源代码创建一套Docker镜像，并使用一个临时标签（我们稍后将详加解释）将其推送至项目的GitLab镜像库。

build:
  image: docker:stable
  stage: package
  services:
    - docker:dind
  script:
   - docker build -t $CI_REGISTRY_IMAGE:tmp .
   - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN $CI_REGISTRY
   - docker push $CI_REGISTRY_IMAGE:tmp
  only:
  - master

而test阶段则负责利用新创建的镜像运行一套容器，并确保返回的消息以“Hello”为开头。

test:
  image: docker:stable
  stage: test
  services:
    - docker:dind
  script:
    - docker run -d --name hello $CI_REGISTRY_IMAGE:tmp
    - sleep 10s
    - TEST=$(docker run --link hello lucj/curl -s http://hello:8000)
    - $([ "${TEST:0:5}" = "Hello" ])
  only:
  - master

接下来的push阶段向该镜像中push新的标签，第一个标签基于该git提交的hash，第二个为当前分支的名称（在本示例中为master，因为我们只需要在主分支上进行操作）。最后，将这些新标签push回GitLab库。

push:
  image: docker:stable
  stage: push
  services:
    - docker:dind
  script:
   - docker image pull $CI_REGISTRY_IMAGE:tmp
   - docker image tag $CI_REGISTRY_IMAGE:tmp $CI_REGISTRY_IMAGE:$CI_BUILD_REF
   - docker image tag $CI_REGISTRY_IMAGE:tmp $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_NAME
   - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN $CI_REGISTRY
   - docker push $CI_REGISTRY_IMAGE:$CI_BUILD_REF
   - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_NAME
  only:
  - master

最后，deploy的阶段负责在我们的Kubernetes集群之内创建/更新应用程序。我们将在k8s文件夹当中定义2个manifest文件：Deployment用于我们我们Web服务器的Pod，而Service则用于将其面向外部公开。

我们首先定义以下k8s/deploy.tpl 模板。它将被用于在deploy阶段生成用于指定Deployment资源的k8s/deploy.yml文件。这套模板将定义Deployment，用于管理根据registry.gitlab.com/lucj/hello镜像建立的Pod的一套单独副本。

在这套模板中，我们使用名为GIT_COMMIT的占位符替换实际提交的hash，具体如下所示。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
  labels:
    app: hello
spec:
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - name: hello
        image: registry.gitlab.com/lucj/hello:GIT_COMMIT

我们还在 k8s/service.yml当中定义了Service资源，用以向外部公开我们的应用程序。Service的类型为LoadBalancer。

apiVersion: v1
kind: Service
metadata:
  name: hello
spec:
  type: LoadBalancer
  ports:
    - name: hello
      port: 80
      targetPort: 8000
      protocol: TCP
  selector:
    app: hello

需要在deploy阶段执行的操作如下：

deploy:
  stage: deploy
  image: lucj/kubectl:1.15.2
  environment: test
  script:
    - kubectl config set-cluster my-cluster --server=${KUBE_URL} --certificate-authority="${KUBE_CA_PEM_FILE}"
    - kubectl config set-credentials admin --token=${KUBE_TOKEN}
    - kubectl config set-context my-context --cluster=my-cluster --user=admin --namespace default
    - kubectl config use-context my-context
    - cat k8s/deploy.tpl | sed 's/GIT_COMMIT/'"$CI_BUILD_REF/" > k8s/deploy.yml
    - kubectl apply -f k8s
  only:
  - master

另外几点注意事项：

这一阶段需要在包含kubectl客户端的镜像上下文中运行
从GitLab自动设置的环境变量当中检索集群信息，这些信息将用于设置Kubernetes的上下
Deployment资源根据模板文件创建而成，其中的CIT_COMMIT占位符将被替换为$CI_BUILD_REF环境变量当中的实际提交信息
Service与Deployment资源分别位于k8s/service.yml与k8s/deploy.yml当中，通过常用的“kubectl apply”命令进行创建/更新

备注：这条流水线非常简单，但并不是最优方案。我们只是利用它来展示不同的流程。

项目测试

下面，让我们把这些变更push到GitLab项目当中，而后检查由此触发的CI/CD流水线：

$ git add k8s
$ git commit -m ‘Add K8s resources’$ git add .gitlab-ci.yml
$ git commit -m ‘Add GitLab pipeline’$ git push origin master

这会触发GitLab流水线，具体如下图中的Web界面所示：

在该流水线的deploy阶段（最终阶段），Deployment与Service需要进行首次创建（因为之前并不存在）。由于Service的类型为LoadBalancer，因此我们可以从下图中看到DigitalOcean基础设施上会创建对应的负载均衡器资源。

利用与该Load Balancer相关联的外部IP地址，我们可以在指向运行有应用程序的底层Pod的端口80上访问自己的应用程序。

这证明Service与Deployment都已经正确创建完成。

下面，我们需要对app.py做出一点调整，把返回内容由“Hello World!”改为“Hello from Kube”。

from flask import Flask
app = Flask(__name__)@app.route("/")
def hello():
    return "Hello from Kube"if __name__ == "__main__":
    app.run(host='0.0.0.0', port=8000)

我们对这些变更进行commit与push：

$ git add app.py
$ git commit -m 'change message to Hello from Kube'
$ git push origin master

新的CI/CD流水线由此触发，我们可以刷新浏览器并看到如下结果：

当然，我们在这里设置的只是一条简单的流水线。对于真实场景中的应用程序，还需要添加一些额外的增强功能。例如，我们可能需要考虑以下步骤：

额外的测试
镜像扫描，用于确保该镜像不包含任何CVE漏洞（或者至少不存在高危漏洞）

若需了解更多与镜像扫描相关的细节信息，请参阅：

https://medium.com/better-programming/adding-cve-scanning-to-a-ci-cd-pipeline-d0f5695a555a

添加GitOps

现在，我们需要再次修改这条CI/CD流水线，以利用GItOps方法处理其中的CD部分。以下结构展示了GitOps Deployment工作流中所涉及的组件。

GitOps Deployment 工作流（图片来源：Weaveworks）

基本上，每当系统在镜像注册表中检测到新的镜像标签，我们就要利用Flux操作程序（运行在Pod内的集群当中）对应用程序进行重新部署。

安装Flux

Flux可以通过Deployment或者Helm进行手动安装。在本文中，我们也使用手动方案。第一步，就是对fluxcd库进行clone：

$ git clone https://github.com/fluxcd/flux && cd flux

接下来，在Deployment规范之内（deploy/flux-deployment.yaml）变更以下参数：

--git-url=git@gitlab.com:lucj/hello, 用于告知Flux检测哪个Git库
–git-path=k8s, 在此库当中只考虑k8s文件夹（我们的Kubernetes manifests文件就位于该文件夹内）
–git-ci-skip, 此选项允许我们在Flux完成对GitLab项目库的更新之后（包括标签与Deployment资源更新），跳过CI流水线

现在，我们可以将Flux部署至集群当中了：

$ kubectl apply -f deploy
serviceaccount/flux created
clusterrole.rbac.authorization.k8s.io/flux created
clusterrolebinding.rbac.authorization.k8s.io/flux created
deployment.apps/flux created
secret/flux-git-deploy created
deployment.apps/memcached created
service/memcached created

由此创建的几种资源：

ServiceAccount、ClusterRole以及ClusterRoleBoinding，用于为Flux Pod提供运行所需的验证/授权
Flux操作程序
用于memcached的Service与Deployment，由Flux用于缓存镜像元数据

$ kubectl get pods
NAMESPACE NAME                       READY  STATUS   RESTARTS  AGE
default   flux-dcb965db7-pn97k       1/1    Running  0         56s
default   memcached-554f994578-t2tss 1/1    Running  0         56s
...

查看Flux Pod日志，我们会看到一条错误消息，因为Flux无法读取项目的Git库。

“权限被拒绝（公钥）。严重：无法从远程库中读取。请确保您具有正确的访问权限，且目标库存在。”

为了解决这个问题，我们可以使用fluxctl实用程序检索安装期间所公开ssh密钥。

$ fluxctl identity
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCx4fk4YjcM7cP1FL/AKWtHpN+cg9/Qz1p5dzAlsFLMKilUUy0uCQQmaptXDZQGaZrbvNSyezgT5/yH6qau6W6ICoLYAzBku47PoWlqbUfcbPhMxHSfivjv7s4lSeUE+u3kR2opROxdyHHL+VQMI6n9Xc7qnTq6YC+VJ+RkoUUd0bgBC+Rg/aMURLD9mkAVzmWw6+Y8QAJMVNMzNDgId+8iSHKtOYsHqoxg4GqexdB1R5goE0ChBU9DPsiqLfk8jzuD2I3xuZeGW6or+/JHxa/6vO8lX+of1ZGZGZKr5i3E4OIehSwFUP2A/ypeqXEEI5gmO1s2YrM49jpS+jW4oUMP

接下来，将该密钥添加至我们的GitLab库，为其提供创建/更新所需要的读取/写入访问权限。

修改原有流水线

由于Flux负责对项目作出的变更进行部署，因此我们需要删除之前创建的.gitlab-ci.yml文件中的Deployment阶段，其它内容则保持不变。现在的.gitlab-ci.yml如下所示，其中与集群API Server交互的kubectl已经被删除：

stages:
  - package
  - test
  - pushbuild:
  image: docker:stable
  stage: package
  services:
    - docker:dind
  script:
   - docker build -t $CI_REGISTRY_IMAGE:tmp .
   - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN $CI_REGISTRY
   - docker push $CI_REGISTRY_IMAGE:tmp
  only:
  - mastertest:
  image: docker:stable
  stage: test
  services:
    - docker:dind
  script:
    - docker run -d --name hello $CI_REGISTRY_IMAGE:tmp
    - sleep 10s
    - TEST=$(docker run --link hello lucj/curl -s http://hello:8000)
    - $([ "${TEST:0:5}" = "Hello" ])
  only:
  - masterpush:
  image: docker:stable
  stage: push
  services:
    - docker:dind
  script:
   - docker image pull $CI_REGISTRY_IMAGE:tmp
   - docker image tag $CI_REGISTRY_IMAGE:tmp $CI_REGISTRY_IMAGE:$CI_BUILD_REF
   - docker image tag $CI_REGISTRY_IMAGE:tmp $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_NAME
   - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN $CI_REGISTRY
   - docker push $CI_REGISTRY_IMAGE:$CI_BUILD_REF
   - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_NAME
  only:
  - master

此外，我们也可以删除k8s/deploy.tpl模板文件，因为我们不再需要利用该文件对Deployment manifest进行更新。相反，我们将在Deployment中使用以下k8s/deploy.yml，确保Flux在每次检测到新的镜像标签时都会执行更新。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
  annotations:
    flux.weave.works/automated: "true"
    flux.weave.works/tag.hello: regexp:^((?!tmp).)*$
  labels:
    app: hello
spec:
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - name: hello
        image: registry.gitlab.com/lucj/hello:master

用于该Deployment的Flux配置在annotations键内完成：

flux.weave.works/automated: “true”, 用于激活该资源的自动重新部署
flux.weave.works/tag.hello: regexp:^((?!tmp).)*$, 确保具有tmp标签的临时镜像不会被纳入使用

实际测试

我们对app.py中的代码进行了如下变更，因此其现在会返回“Hello from Flux”。

from flask import Flask
app = Flask(__name__)@app.route("/")
def hello():
    return "Hello from Flux"if __name__ == "__main__":
    app.run(host='0.0.0.0', port=8000)

接下来将修改后的内容push至GitLab。

$ git rm k8s/deploy.tpl
$ git add k8s/deploy.yml .gitlab-ci.yml app.py
$ git commit -m 'CD with Flux'
$ git push origin master

查看GitLab界面，我们会看到该流水线已经被触发了多次。

已经创建的多条流水线（其中几条被直接跳过）

有条流水线的触发原因是我们做出了变更，其它几条则由Flux在对master分支上的Deployment manifest（k8s/deploy.yml）以及flux-sync分支上的标签进行更新时触发。除了这两项操作之外的其它被触发流水线被直接跳过（相关操作并未执行），这是因为我们在Flux配置当中使用了—git-ci-skip选项（如果不这样，流水线将一直循环运行）。

然后，我们可以再次刷新浏览器以查看应用程序的最新版本。

可以看到，当Flux操作程序定期检查新的镜像标签时，其会发现CI流水线执行期间出现的代码变更，并据此自动更新Deployment。

总结

在本文当中，我希望向大家介绍GitOps，并通过一个简单的示例说明它如何与GitLab CI流水线配合起效。大家也可以根据需求增强其中某些功能，例如在流水线当中定义更多阶段，使用sermver命名镜像标签等……总之，我希望这篇简单的文章能够让大家对整个方法拥有基本的了解。

GitOps在很长一段时间内得到了行业的高度关注，感兴趣的朋友可以点击此处通过官方文档了解更多细节信息。

您已经开始使用GitOps方案了吗？希望在评论中看到您的分享心得。

创作场景

实战攻略：利用 GitOps 在 Kubernetes 上实现持续交付