65. Gitlab CI

上节课我们使用 Helm 快速的将 Gitlab 安装到了我们的 Kubernetes 集群中，这节课来和大家介绍如何使用 Gitlab CI 来做持续集成。

简介

从 Gitlab 8.0 开始，Gitlab CI 就已经集成在 Gitlab 中，我们只要在项目中添加一个.gitlab-ci.yml文件，然后添加一个Runner，即可进行持续集成。在介绍 Gitlab CI 之前，我们先看看一些 Gitlab CI 的一些相关概念。

Pipeline

一次 Pipeline 其实相当于一次构建任务，里面可以包含很多个流程，如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。任何提交或者 Merge Request 的合并都可以触发 Pipeline 构建，如下图所示：

  1. +------------------+           +----------------+
  2. |                  |  trigger  |                |
  3. |   Commit / MR    +---------->+    Pipeline    |
  4. |                  |           |                |
  5. +------------------+           +----------------+

Stages

Stages 表示一个构建阶段，也就是上面提到的一个流程。我们可以在一次 Pipeline 中定义多个 Stages，这些 Stages 会有以下特点：

  • 所有 Stages 会按照顺序运行，即当一个 Stage 完成后，下一个 Stage 才会开始
  • 只有当所有 Stages 完成后，该构建任务 (Pipeline) 才会成功
  • 如果任何一个 Stage 失败，那么后面的 Stages 不会执行，该构建任务 (Pipeline) 失败

Stages 和 Pipeline 的关系如下所示：

  1. |                                                        |
  2. |  Pipeline                                              |
  3. |                                                        |
  4. |  +-----------+     +------------+      +------------+  |
  5. |  |  Stage 1  |---->|   Stage 2  |----->|   Stage 3  |  |
  6. |  +-----------+     +------------+      +------------+  |
  7. |                                                        |
  8. +--------------------------------------------------------+

Jobs

Jobs 表示构建工作，表示某个 Stage 里面执行的工作。我们可以在 Stages 里面定义多个 Jobs，这些 Jobs 会有以下特点：

  • 相同 Stage 中的 Jobs 会并行执行
  • 相同 Stage 中的 Jobs 都执行成功时，该 Stage 才会成功
  • 如果任何一个 Job 失败，那么该 Stage 失败，即该构建任务 (Pipeline) 失败

Jobs 和 Stage 的关系如下所示：

  1. |                                          |
  2. |  Stage 1                                 |
  3. |                                          |
  4. |  +---------+  +---------+  +---------+   |
  5. |  |  Job 1  |  |  Job 2  |  |  Job 3  |   |
  6. |  +---------+  +---------+  +---------+   |
  7. |                                          |
  8. +------------------------------------------+

Gitlab Runner

如果理解了上面的基本概念之后，可能我们就会发现一个问题，我们的构建任务在什么地方来执行呢，以前用 Jenkins 在 Master 和 Slave 节点都可以用来运行构建任务，而来执行我们的 Gitlab CI 构建任务的就是 Gitlab Runner。

我们知道大多数情况下构建任务都是会占用大量的系统资源的，如果直接让 Gitlab 本身来运行构建任务的话，显然 Gitlab 的性能会大幅度下降的。GitLab CI 最大的作用是管理各个项目的构建状态，因此，运行构建任务这种浪费资源的事情交给一个独立的 Gitlab Runner 来做就会好很多，更重要的是 Gitlab Runner 可以安装到不同的机器上，甚至是我们本机，这样完全就不会影响到 Gitlab 本身了。

安装

安装 Gitlab Runner 非常简单，我们可以完全安装官方文档：https://docs.gitlab.com/runner/install/即可，比如可以直接使用二进制、Docker 等来安装。同样的，我们这里还是将 Gitlab Runner 安装到 Kubernetes 集群中来，让我们的集群来统一管理 Gitlab 相关的服务。

1.验证 Kubernetes 集群

执行下面的命令验证 Kubernetes 集群：

  1. $ kubectl cluster-info
  2. Kubernetes master is running at https://10.151.30.11:6443
  3. KubeDNS is running at https://10.151.30.11:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
  5. To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

cluster-info这个命令会显示当前链接的集群状态和可用的集群服务列表。

2.获取 Gitlab CI Register Token

前面的章节中我们已经成功安装了 Gitlab，在浏览器中打开git.qikqiak.com页面，然后登录后进入到管理页面http://git.qikqiak.com/admin，然后点击导航栏中的Runner，可以看到该页面中有两个总要的参数，一个是 URL，另外一个就是 Register Token，下面的步骤中需要用到这两个参数值。

gitlab runner

注意：不要随便泄露 Token

3.编写 Gitlab CI Runner 资源清单文件

同样我们将 Runner 相关的资源对象都安装到kube-ops这个 namespace 下面，首先，我们通过 ConfigMap 资源来传递 Runner 镜像所需的环境变量（runner-cm.yaml）:

  1. apiVersion: v1
  2. data:
  3.   REGISTER_NON_INTERACTIVE: "true"
  4.   REGISTER_LOCKED: "false"
  5.   METRICS_SERVER: "0.0.0.0:9100"
  6.   CI_SERVER_URL: "http://gitlab.kube-ops.svc.cluster.local/ci"
  7.   RUNNER_REQUEST_CONCURRENCY: "4"
  8.   RUNNER_EXECUTOR: "kubernetes"
  9.   KUBERNETES_NAMESPACE: "kube-ops"
  10.   KUBERNETES_PRIVILEGED: "true"
  11.   KUBERNETES_CPU_LIMIT: "1"
  12.   KUBERNETES_CPU_REQUEST: "500m"
  13.   KUBERNETES_MEMORY_LIMIT: "1Gi"
  14.   KUBERNETES_SERVICE_CPU_LIMIT: "1"
  15.   KUBERNETES_SERVICE_MEMORY_LIMIT: "1Gi"
  16.   KUBERNETES_HELPER_CPU_LIMIT: "500m"
  17.   KUBERNETES_HELPER_MEMORY_LIMIT: "100Mi"
  18.   KUBERNETES_PULL_POLICY: "if-not-present"
  19.   KUBERNETES_TERMINATIONGRACEPERIODSECONDS: "10"
  20.   KUBERNETES_POLL_INTERVAL: "5"
  21.   KUBERNETES_POLL_TIMEOUT: "360"
  22. kind: ConfigMap
  23. metadata:
  24.   labels:
  25.     app: gitlab-ci-runner
  26.   name: gitlab-ci-runner-cm
  27.   namespace: kube-ops

要注意CI_SERVER_URL对应的值需要指向我们的 Gitlab 实例的 URL（可以是外网地址，也可以是 Kubernetes 集群内部的 Service DNS 地址，因为 Runner 也是运行在 Kubernetes 集群中的），并加上/ci（ http://gitlab.kube-ops.svc.cluster.local/ci ）。此外还添加了一些构建容器运行的资源限制，我们可以自己根据需要进行更改即可。

注意：在向 ConfigMap 添加新选项后，需要删除 GitLab CI Runner Pod。因为我们是使用 envFrom来注入上面的这些环境变量而不是直接使用env的（envFrom 通过将环境变量放置到ConfigMaps或Secrets来帮助减小清单文件。

另外如果要添加其他选项的话，我们可以在 Pod 中运行gitlab-ci-multi-runner register --help命令来查看所有可使用的选项，只需为要配置的标志添加 env 变量即可，如下所示：

  1. gitlab-runner@gitlab-ci-runner-0:/$ gitlab-ci-multi-runner register --help
  2. [...]
  3. --kubernetes-cpu-limit value                          The CPU allocation given to build containers (default: "1") [$KUBERNETES_CPU_LIMIT]
  4. --kubernetes-memory-limit value                       The amount of memory allocated to build containers (default: "4Gi") [$KUBERNETES_MEMORY_LIMIT]
  5. --kubernetes-service-cpu-limit value                  The CPU allocation given to build service containers (default: "1") [$KUBERNETES_SERVICE_CPU_LIMIT]
  6. --kubernetes-service-memory-limit value               The amount of memory allocated to build service containers (default: "1Gi") [$KUBERNETES_SERVICE_MEMORY_LIMIT]
  7. --kubernetes-helper-cpu-limit value                   The CPU allocation given to build helper containers (default: "500m") [$KUBERNETES_HELPER_CPU_LIMIT]
  8. --kubernetes-helper-memory-limit value                The amount of memory allocated to build helper containers (default: "3Gi") [$KUBERNETES_HELPER_MEMORY_LIMIT]
  9. --kubernetes-cpu-request value                        The CPU allocation requested for build containers [$KUBERNETES_CPU_REQUEST]
  10. ...
  11. --pre-clone-script value                              Runner-specific command script executed before code is pulled [$RUNNER_PRE_CLONE_SCRIPT]
  12. [...]

如果定义的 Gitlab 域名并不是通过外网的 DNS 进行解析的，而是通过 /etc/hosts 俩进行映射的，那么我们就需要在 runner 的 Pod 中去添加 git.qikqiak.com 对应的 hosts 了，那么如何添加呢？我们可以想到的是 Pod 的 hostAlias 可以实现这个需求，但是 runner 的 Pod 是自动生成的，没办法直接去定义 hostAlias。这里我们就可以通过上面的--pre-clone-script参数来指定一段脚本来添加 hosts 信息，也就是在上面的 ConfigMap 中添加环境变量RUNNER_PRE_CLONE_SCRIPT的值即可：

  1. RUNNER_PRE_CLONE_SCRIPT = "echo 'xx.xx.xxx.xx git.qikqiak.com' >> /etc/hosts"

除了上面的一些环境变量相关的配置外，还需要一个用于注册、运行和取消注册 Gitlab CI Runner 的小脚本。只有当 Pod 正常通过 Kubernetes（TERM信号）终止时，才会触发转轮取消注册。 如果强制终止 Pod（SIGKILL信号），Runner 将不会注销自身。必须手动完成对这种被杀死的 Runner 的清理，配置清单文件如下：（runner-scripts-cm.yaml）

  1. apiVersion: v1
  2. data:
  3.   run.sh: |
  4.     #!/bin/bash
  5.     unregister() {
  6.         kill %1
  7.         echo "Unregistering runner ${RUNNER_NAME} ..."
  8.         /usr/bin/gitlab-ci-multi-runner unregister -t "$(/usr/bin/gitlab-ci-multi-runner list 2>&1 | tail -n1 | awk '{print $4}' | cut -d'=' -f2)" -n ${RUNNER_NAME}
  9.         exit $?
  10.     }
  11.     trap 'unregister' EXIT HUP INT QUIT PIPE TERM
  12.     echo "Registering runner ${RUNNER_NAME} ..."
  13.     /usr/bin/gitlab-ci-multi-runner register -r ${GITLAB_CI_TOKEN}
  14.     sed -i 's/^concurrent.*/concurrent = '"${RUNNER_REQUEST_CONCURRENCY}"'/' /home/gitlab-runner/.gitlab-runner/config.toml
  15.     echo "Starting runner ${RUNNER_NAME} ..."
  16.     /usr/bin/gitlab-ci-multi-runner run -n ${RUNNER_NAME} &
  17.     wait
  18. kind: ConfigMap
  19. metadata:
  20.   labels:
  21.     app: gitlab-ci-runner
  22.   name: gitlab-ci-runner-scripts
  23.   namespace: kube-ops

我们可以看到需要一个 GITLAB_CI_TOKEN，然后我们用 Gitlab CI runner token 来创建一个 Kubernetes secret 对象。将 token 进行 base64 编码：

  1. $ echo rcVZF-mdHt9qCyyrCDgS | base64 -w0
  2. cmNWWkYtbWRIdDlxQ3l5ckNEZ1MK

base64 命令在大部分 Linux 发行版中都是可用的。

然后使用上面的 token 创建一个 Secret 对象：(gitlab-ci-token-secret.yaml)

  1. apiVersion: v1
  2. kind: Secret
  3. metadata:
  4.   name: gitlab-ci-token
  5.   namespace: kube-ops
  6.   labels:
  7.     app: gitlab-ci-runner
  8. data:
  9.   GITLAB_CI_TOKEN: cmNWWkYtbWRIdDlxQ3l5ckNEZ1MK

然后接下来我们就可以来编写一个用于真正运行 Runner 的控制器对象，我们这里使用 Statefulset。首先，在开始运行的时候，尝试取消注册所有的同名 Runner，当节点丢失时（即NodeLost事件），这尤其有用。然后再尝试重新注册自己并开始运行。在正常停止 Pod 的时候，Runner 将会运行unregister命令来尝试取消自己，所以 Gitlab 就不能再使用这个 Runner 了，这个是通过 Kubernetes Pod 生命周期中的hooks来完成的。

另外我们通过使用envFrom来指定Secrets和ConfigMaps来用作环境变量，对应的资源清单文件如下：(runner-statefulset.yaml)

  1. apiVersion: apps/v1beta1
  2. kind: StatefulSet
  3. metadata:
  4.   name: gitlab-ci-runner
  5.   namespace: kube-ops
  6.   labels:
  7.     app: gitlab-ci-runner
  8. spec:
  9.   updateStrategy:
  10.     type: RollingUpdate
  11.   replicas: 2
  12.   serviceName: gitlab-ci-runner
  13.   template:
  14.     metadata:
  15.       labels:
  16.         app: gitlab-ci-runner
  17.     spec:
  18.       volumes:
  19.       - name: gitlab-ci-runner-scripts
  20.         projected:
  21.           sources:
  22.           - configMap:
  23.               name: gitlab-ci-runner-scripts
  24.               items:
  25.               - key: run.sh
  26.                 path: run.sh
  27.                 mode: 0755
  28.       serviceAccountName: gitlab-ci
  29.       securityContext:
  30.         runAsNonRoot: true
  31.         runAsUser: 999
  32.         supplementalGroups: [999]
  33.       containers:
  34.       - image: gitlab/gitlab-runner:latest
  35.         name: gitlab-ci-runner
  36.         command:
  37.         - /scripts/run.sh
  38.         envFrom:
  39.         - configMapRef:
  40.             name: gitlab-ci-runner-cm
  41.         - secretRef:
  42.             name: gitlab-ci-token
  43.         env:
  44.         - name: RUNNER_NAME
  45.           valueFrom:
  46.             fieldRef:
  47.               fieldPath: metadata.name
  48.         ports:
  49.         - containerPort: 9100
  50.           name: http-metrics
  51.           protocol: TCP
  52.         volumeMounts:
  53.         - name: gitlab-ci-runner-scripts
  54.           mountPath: "/scripts"
  55.           readOnly: true
  56.       restartPolicy: Always

可以看到上面我们使用了一个名为 gitlab-ci 的 serviceAccount，新建一个 rbac 资源清单文件：(runner-rbac.yaml)

  1. apiVersion: v1
  2. kind: ServiceAccount
  3. metadata:
  4.   name: gitlab-ci
  5.   namespace: kube-ops
  6. ---
  7. kind: Role
  8. apiVersion: rbac.authorization.k8s.io/v1
  9. metadata:
  10.   name: gitlab-ci
  11.   namespace: kube-ops
  12. rules:
  13.   - apiGroups: [""]
  14.     resources: ["*"]
  15.     verbs: ["*"]
  16. ---
  17. kind: RoleBinding
  18. apiVersion: rbac.authorization.k8s.io/v1
  19. metadata:
  20.   name: gitlab-ci
  21.   namespace: kube-ops
  22. subjects:
  23.   - kind: ServiceAccount
  24.     name: gitlab-ci
  25.     namespace: kube-ops
  26. roleRef:
  27.   kind: Role
  28.   name: gitlab-ci
  29.   apiGroup: rbac.authorization.k8s.io

4.创建 Runner 资源对象

资源清单文件准备好后，我们直接创建上面的资源对象：

  1. $ ls
  2. gitlab-ci-token-secret.yaml  runner-cm.yaml  runner-rbac.yaml  runner-scripts-cm.yaml  runner-statefulset.yaml
  3. $ kubectl create -f .
  4. secret "gitlab-ci-token" created
  5. configmap "gitlab-ci-runner-cm" created
  6. serviceaccount "gitlab-ci" created
  7. role.rbac.authorization.k8s.io "gitlab-ci" created
  8. rolebinding.rbac.authorization.k8s.io "gitlab-ci" created
  9. configmap "gitlab-ci-runner-scripts" created
  10. statefulset.apps "gitlab-ci-runner" created

创建完成后，可以通过查看 Pod 状态判断 Runner 是否运行成功：

  1. $ kubectl get pods -n kube-ops
  2. NAME                                           READY     STATUS    RESTARTS   AGE
  3. gitlab-7bff969fbc-k5zl4                        1/1       Running   0          4d
  4. gitlab-ci-runner-0                             1/1       Running   0          3m
  5. gitlab-ci-runner-1                             1/1       Running   0          3m
  6. ......

可以看到已经成功运行了两个（具体取决于StatefulSet清单中的副本数) Runner 实例，然后切换到 Gitlab Admin 页面下面的 Runner 页面：

gitlab runner list

当然我们也可以根据需要更改 Runner 的一些配置，比如添加 tag 标签等。

Gitlab CI

基本配置

接下来使用 Gitlab CI 所用到的代码库可以从 Github 上获得：cnych/presentation-gitlab-k8s，可以在 Gitlab 上新建一个项目导入该仓库，当然也可以新建一个空白的仓库，然后将 Github 上面的项目 Clone 到本地后，更改远程仓库地址即可：

  1. $ git clone https://github.com/cnych/presentation-gitlab-k8s.git
  2. $ cd presentation-gitlab-k8s
  3. # Change the remote of the repository
  4. $ git remote set-url origin ssh://git@git.qikqiak.com:30022/root/presentation-gitlab-k8s.git
  5. # Now to push/"import" the repository run:
  6. $ git push -u origin master

当我们把仓库推送到 Gitlab 以后，应该可以看到 Gitlab CI 开始执行构建任务了: gitlab ci

此时 Runner Pod 所在的 namespace 下面也会出现两个新的 Pod：

  1. $ kubectl get pods -n kube-ops
  2. NAME                                           READY     STATUS              RESTARTS   AGE
  3. gitlab-7bff969fbc-k5zl4                        1/1       Running             0          4d
  4. gitlab-ci-runner-0                             1/1       Running             0          4m
  5. gitlab-ci-runner-1                             1/1       Running             0          4m
  6. runner-9rixsyft-project-2-concurrent-06g5w4    0/2       ContainerCreating   0          4m
  7. runner-9rixsyft-project-2-concurrent-1t74t9    0/2       ContainerCreating   0          4m
  8. ......

这两个新的 Pod 就是用来执行具体的 Job 任务的，这里同时出现两个证明第一步是并行执行的两个任务，从上面的 Pipeline 中也可以看到是 test 和 test2 这两个 Job。我们可以看到在执行 image_build 任务的时候出现了错误：

pipeline

我们可以点击查看这个 Job 失败详细信息：

  1. $ docker login -u "${CI_REGISTRY_USER}" -p "${CI_REGISTRY_PASSWORD}" "${CI_REGISTRY}"
  2. WARNING! Using --password via the CLI is insecure. Use --password-stdin.
  3. Error response from daemon: Get https://registry-1.docker.io/v2/: unauthorized: incorrect username or password
  4. ERROR: Job failed: command terminated with exit code 1

出现上面的错误是因为我们并没有在 Gitlab 中开启 Container Registry，所以环境变量中并没有这些值，还记得前面章节中我们安装的 Harbor 吗？我们这里使用 Harbor 来作为我们的镜像仓库，这里我们只需要把 Harbor 相关的配置以参数的形式配置到环境中就可以了。

定位到项目 -> 设置 -> CI/CD，展开Environment variables栏目，配置镜像仓库相关的参数值：

gitlab ci env

配置上后，我们在上面失败的 Job 任务上点击“重试”，在重试过后依然可以看到会出现下面的错误信息：

  1. $ docker login -u "${CI_REGISTRY_USER}" -p "${CI_REGISTRY_PASSWORD}" "${CI_REGISTRY}"
  2. WARNING! Using --password via the CLI is insecure. Use --password-stdin.
  3. Error response from daemon: Get https://registry.qikqiak.com/v2/: x509: certificate signed by unknown authority
  4. ERROR: Job failed: command terminated with exit code 1

从错误信息可以看出这是因为登录私有镜像仓库的时候证书验证错误，因为我们根本就没有提供任何证书，所以肯定会失败的，还记得我们之前在介绍 Harbor 的时候的解决方法吗？第一种是在 Docker 的启动参数中添加上insecure-registries，另外一种是在目录/etc/docker/certs.d/下面添加上私有仓库的 CA 证书，同样，我们只需要在 dind 中添加 insecure 的参数即可：

  1. services:
  2. - name: docker:dind
  3.   command: ["--insecure-registry=registry.qikqiak.com"]

其中registry.qikqiak.com就是我们之前配置的私有镜像仓库地址。

然后保存.gitlab-ci.yml文件，重新提交到代码仓库，可以看到又触发了正常的流水线构建了，在最后的阶段deploy_review仍然可以看到失败了，这是因为在最后的部署阶段我们使用kubectl工具操作集群的时候并没有关联上任何集群。

我们在 Gitlab CI 中部署阶段使用到的镜像是cnych/kubectl，该镜像的Dockerfile文件可以在仓库https://github.com/cnych/docker-kubectl中获取：

  1. FROM alpine:3.8
  3. MAINTAINER cnych <icnych@gmail.com>
  5. ENV KUBE_LATEST_VERSION="v1.13.4"
  7. RUN apk add --update ca-certificates \
  8.  && apk add --update -t deps curl \
  9.  && apk add --update gettext \
  10.  && apk add --update git \
  11.  && curl -L https://storage.googleapis.com/kubernetes-release/release/${KUBE_LATEST_VERSION}/bin/linux/amd64/kubectl -o /usr/local/bin/kubectl \
  12.  && chmod +x /usr/local/bin/kubectl \
  13.  && apk del --purge deps \
  14.  && rm /var/cache/apk/*
  16.  ENTRYPOINT ["kubectl"]
  17.  CMD ["--help"]

我们知道kubectl在使用的时候默认会读取当前用户目录下面的~/.kube/config文件来链接集群，当然我们可以把连接集群的信息直接内置到上面的这个镜像中去，这样就可以直接操作集群了，但是也有一个不好的地方就是不方便操作，假如要切换一个集群还得重新制作一个镜像。所以一般我们这里直接在 Gitlab 上配置集成 Kubernetes 集群。

在项目页面点击Add Kubernetes Cluster -> Add existing cluster：

1.Kubernetes cluster name 可以随便填

2.API URL 是你的集群的apiserver的地址， 一般可以通过输入kubectl cluster-info获取，Kubernetes master 地址就是需要的

  1. $ kubectl cluster-info
  2. Kubernetes master is running at https://10.151.30.11:6443
  3. KubeDNS is running at https://10.151.30.11:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
  5. To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

3.CA证书、Token、项目命名空间

对于我们这个项目准备部署在一个名为gitlab的 namespace 下面，所以首先我们需要到目标集群中创建一个 namespace:

  1. $ kubectl create ns gitlab

由于我们在部署阶段需要去创建、删除一些资源对象，所以我们也需要对象的 RBAC 权限，这里为了简单，我们直接新建一个 ServiceAccount，绑定上一个cluster-admin的权限：(gitlab-sa.yaml)

  1. ---
  2. apiVersion: v1
  3. kind: ServiceAccount
  4. metadata:
  5.   name: gitlab
  6.   namespace: gitlab
  8. ---
  9. apiVersion: rbac.authorization.k8s.io/v1beta1
  10. kind: ClusterRoleBinding
  11. metadata:
  12.   name: gitlab
  13.   namespace: gitlab
  14. subjects:
  15.   - kind: ServiceAccount
  16.     name: gitlab
  17.     namespace: gitlab
  18. roleRef:
  19.   apiGroup: rbac.authorization.k8s.io
  20.   kind: ClusterRole
  21.   name: cluster-admin

然后创建上面的 ServiceAccount 对象：

  1. $ kubectl apply -f sa.yaml
  2. serviceaccount "gitlab" created
  3. clusterrolebinding.rbac.authorization.k8s.io "gitlab" created

可以通过上面创建的 ServiceAccount 获取 CA 证书和 Token：

  1. $ kubectl get serviceaccount gitlab -n gitlab -o json | jq -r '.secrets[0].name'
  2. gitlab-token-f9zp7
  4. # 然后根据上面的Secret找到CA证书
  5. $ kubectl get secret gitlab-token-f9zp7 -n gitlab -o json | jq -r '.data["ca.crt"]' | base64 -d
  6. xxxxxCA证书内容xxxxx
  8. # 当然要找到对应的 Token 也很简单
  9. $ kubectl get secret gitlab-token-f9zp7  -n gitlab -o json | jq -r '.data.token' | base64 -d
  10. xxxxxxtoken值xxxx

填写上面对应的值添加集群：

add k8s cluster

.gitlab-ci.yml

现在 Gitlab CI 的环境都准备好了，我们可以来看下用于描述 Gitlab CI 的.gitlab-ci.yml文件。

一个 Job 在.gitlab-ci.yml文件中一般如下定义：

  1. # 运行golang测试用例
  2. test:
  3.   stage: test
  4.   script:
  5.     - go test ./...

上面这个 Job 会在 test 这个 Stage 阶段运行。

为了指定运行的 Stage 阶段，可以在.gitlab-ci.yml文件中放置任意一个简单的列表：

  1. # 所有 Stage
  2. stages:
  3.   - test
  4.   - build
  5.   - release
  6.   - deploy

你可以指定用于在全局或者每个作业上执行命令的镜像：

  1. # 对于未指定镜像的作业，会使用下面的镜像
  2. image: golang:1.10.3-stretch
  3. # 或者对于特定的job使用指定的镜像
  4. test:
  5.   stage: test
  6.   image: python:3
  7.   script:
  8.     - echo Something in the test step in a python:3 image

对于.gitlab-ci.yml文件的的其他部分，请查看如下文档介绍：https：//docs.gitlab.com/ce/ci/yaml/README.html。

在我们当前的项目中定义了 4 个构建阶段：test、build、release、review、deploy，完整的.gitlab-ci.yml文件如下：

  1. image:
  2.   name: golang:1.10.3-stretch
  3.   entrypoint: ["/bin/sh", "-c"]
  5. # 为了能够使用go get，需要将代码放在 $GOPATH 中，比如你的 gitlab 域名是 mydomain.com，你的代码仓库是 repos/projectname，默认的 GOPATH 是 /go，然后你就需要将你的代码放置到 GOPATH 下面，/go/src/mydomain.com/repos/projectname，用一个软链接指过来就可以了
  6. before_script:
  7.   - mkdir -p "/go/src/git.qikqiak.com/${CI_PROJECT_NAMESPACE}"
  8.   - ln -sf "${CI_PROJECT_DIR}" "/go/src/git.qikqiak.com/${CI_PROJECT_PATH}"
  9.   - cd "/go/src/git.qikqiak.com/${CI_PROJECT_PATH}/"
  11. stages:
  12.   - test
  13.   - build
  14.   - release
  15.   - review
  16.   - deploy
  18. test:
  19.   stage: test
  20.   script:
  21.     - make test
  23. test2:
  24.   stage: test
  25.   script:
  26.     - sleep 3
  27.     - echo "We did it! Something else runs in parallel!"
  29. compile:
  30.   stage: build
  31.   script:
  32.     # 添加所有的依赖，或者使用 glide/govendor/...
  33.     - make build
  34.   artifacts:
  35.     paths:
  36.       - app
  38. image_build:
  39.   stage: release
  40.   image: docker:latest
  41.   variables:
  42.     DOCKER_DRIVER: overlay
  43.     DOCKER_HOST: tcp://localhost:2375
  44.   services:
  45.     - name: docker:17.03-dind
  46.       command: ["--insecure-registry=registry.qikqiak.com"]
  47.   script:
  48.     - docker info
  49.     - docker login -u "${CI_REGISTRY_USER}" -p "${CI_REGISTRY_PASSWORD}" registry.qikqiak.com
  50.     - docker build -t "${CI_REGISTRY_IMAGE}:latest" .
  51.     - docker tag "${CI_REGISTRY_IMAGE}:latest" "${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_NAME}"
  52.     - test ! -z "${CI_COMMIT_TAG}" && docker push "${CI_REGISTRY_IMAGE}:latest"
  53.     - docker push "${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_NAME}"
  55. deploy_review:
  56.   image: cnych/kubectl
  57.   stage: review
  58.   only:
  59.     - branches
  60.   except:
  61.     - tags
  62.   environment:
  63.     name: dev
  64.     url: https://dev-gitlab-k8s-demo.qikqiak.com
  65.     on_stop: stop_review
  66.   script:
  67.     - kubectl version
  68.     - cd manifests/
  69.     - sed -i "s/__CI_ENVIRONMENT_SLUG__/${CI_ENVIRONMENT_SLUG}/" deployment.yaml ingress.yaml service.yaml
  70.     - sed -i "s/__VERSION__/${CI_COMMIT_REF_NAME}/" deployment.yaml ingress.yaml service.yaml
  71.     - |
  72.       if kubectl apply -f deployment.yaml | grep -q unchanged; then
  73.           echo "=> Patching deployment to force image update."
  74.           kubectl patch -f deployment.yaml -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"ci-last-updated\":\"$(date +'%s')\"}}}}}"
  75.       else
  76.           echo "=> Deployment apply has changed the object, no need to force image update."
  77.       fi
  78.     - kubectl apply -f service.yaml || true
  79.     - kubectl apply -f ingress.yaml
  80.     - kubectl rollout status -f deployment.yaml
  81.     - kubectl get all,ing -l ref=${CI_ENVIRONMENT_SLUG}
  83. stop_review:
  84.   image: cnych/kubectl
  85.   stage: review
  86.   variables:
  87.     GIT_STRATEGY: none
  88.   when: manual
  89.   only:
  90.     - branches
  91.   except:
  92.     - master
  93.     - tags
  94.   environment:
  95.     name: dev
  96.     action: stop
  97.   script:
  98.     - kubectl version
  99.     - kubectl delete ing -l ref=${CI_ENVIRONMENT_SLUG}
  100.     - kubectl delete all -l ref=${CI_ENVIRONMENT_SLUG}
  102. deploy_live:
  103.   image: cnych/kubectl
  104.   stage: deploy
  105.   environment:
  106.     name: live
  107.     url: https://live-gitlab-k8s-demo.qikqiak.com
  108.   only:
  109.     - tags
  110.   when: manual
  111.   script:
  112.     - kubectl version
  113.     - cd manifests/
  114.     - sed -i "s/__CI_ENVIRONMENT_SLUG__/${CI_ENVIRONMENT_SLUG}/" deployment.yaml ingress.yaml service.yaml
  115.     - sed -i "s/__VERSION__/${CI_COMMIT_REF_NAME}/" deployment.yaml ingress.yaml service.yaml
  116.     - kubectl apply -f deployment.yaml
  117.     - kubectl apply -f service.yaml
  118.     - kubectl apply -f ingress.yaml
  119.     - kubectl rollout status -f deployment.yaml
  120.     - kubectl get all,ing -l ref=${CI_ENVIRONMENT_SLUG}

上面的.gitlab-ci.yml文件中还有一些特殊的属性，如限制运行的的when和only参数，例如only: ["tags"]表示只为创建的标签运行，更多的信息，我可以通过查看 Gitlab CI YAML 文件查看：https://docs.gitlab.com/ce/ci/yaml/README.html

由于我们在.gitlab-ci.yml文件中将应用的镜像构建完成后推送到了我们的私有仓库，而 Kubernetes 资源清单文件中使用的私有镜像，所以我们需要配置一个imagePullSecret，否则在 Kubernetes 集群中是无法拉取我们的私有镜像的：(替换下面相关信息为自己的)

  1. $ kubectl create secret docker-registry myregistry --docker-server=registry.qikqiak.com --docker-username=xxxx --docker-password=xxxxxx --docker-email=xxxx -n gitlab
  2. secret "myregistry" created

在下面的 Deployment 的资源清单文件中会使用到创建的myregistry。

接下来为应用创建 Kubernetes 资源清单文件，添加到代码仓库中。首先创建 Deployment 资源：（deployment.yaml）

  1. ---
  2. apiVersion: apps/v1
  3. kind: Deployment
  4. metadata:
  5.   name: gitlab-k8s-demo-__CI_ENVIRONMENT_SLUG__
  6.   namespace: gitlab
  7.   labels:
  8.     app: gitlab-k8s-demo
  9.     ref: __CI_ENVIRONMENT_SLUG__
  10.     track: stable
  11. spec:
  12.   replicas: 2
  13.   selector:
  14.     matchLabels:
  15.       app: gitlab-k8s-demo
  16.       ref: __CI_ENVIRONMENT_SLUG__
  17.   template:
  18.     metadata:
  19.       labels:
  20.         app: gitlab-k8s-demo
  21.         ref: __CI_ENVIRONMENT_SLUG__
  22.         track: stable
  23.     spec:
  24.       imagePullSecrets:
  25.         - name: myregistry
  26.       containers:
  27.       - name: app
  28.         image: registry.qikqiak.com/gitdemo/gitlab-k8s:__VERSION__
  29.         imagePullPolicy: Always
  30.         ports:
  31.         - name: http-metrics
  32.           protocol: TCP
  33.           containerPort: 8000
  34.         livenessProbe:
  35.           httpGet:
  36.             path: /health
  37.             port: 8000
  38.           initialDelaySeconds: 3
  39.           timeoutSeconds: 2
  40.         readinessProbe:
  41.           httpGet:
  42.             path: /health
  43.             port: 8000
  44.           initialDelaySeconds: 3
  45.           timeoutSeconds: 2

注意用上面创建的 myregistry 替换 imagePullSecrets。

这是一个基本的 Deployment 资源清单的描述，像__CI_ENVIRONMENT_SLUG__和__VERSION__这样的占位符用于区分不同的环境，__CI_ENVIRONMENT_SLUG__将由 dev 或 live（环境名称）和__VERSION__替换为镜像标签。

为了能够连接到部署的 Pod，还需要 Service。对应的 Service 资源清单如下（service.yaml）：

  1. ---
  2. apiVersion: v1
  3. kind: Service
  4. metadata:
  5.   name: gitlab-k8s-demo-__CI_ENVIRONMENT_SLUG__
  6.   namespace: gitlab
  7.   labels:
  8.     app: gitlab-k8s-demo
  9.     ref: __CI_ENVIRONMENT_SLUG__
  10.   annotations:
  11.     prometheus.io/scrape: "true"
  12.     prometheus.io/port: "8000"
  13.     prometheus.io/scheme: "http"
  14.     prometheus.io/path: "/metrics"
  15. spec:
  16.   type: ClusterIP
  17.   ports:
  18.     - name: http-metrics
  19.       port: 8000
  20.       protocol: TCP
  21.   selector:
  22.     app: gitlab-k8s-demo
  23.     ref: __CI_ENVIRONMENT_SLUG__

我们的应用程序运行8000端口上，端口名为http-metrics，如果你还记得前面我们监控的课程中应该还记得我们使用prometheus-operator为 Prometheus 创建了自动发现的配置，所以我们在annotations里面配置上上面的这几个注释后，Prometheus 就可以自动获取我们应用的监控指标数据了。

现在 Service 创建成功了，但是外部用户还不能访问到我们的应用，当然我们可以把 Service 设置成 NodePort 类型，另外一个常见的方式当然就是使用 Ingress 了，我们可以通过 Ingress 来将应用暴露给外面用户使用，对应的资源清单文件如下：（ingress.yaml）

  1. ---
  2. apiVersion: extensions/v1beta1
  3. kind: Ingress
  4. metadata:
  5.   name: gitlab-k8s-demo-__CI_ENVIRONMENT_SLUG__
  6.   namespace: gitlab
  7.   labels:
  8.     app: gitlab-k8s-demo
  9.     ref: __CI_ENVIRONMENT_SLUG__
  10.   annotations:
  11.     kubernetes.io/ingress.class: "traefik"
  12. spec:
  13.   rules:
  14.   - host: __CI_ENVIRONMENT_SLUG__-gitlab-k8s-demo.qikqiak.com
  15.     http:
  16.       paths:
  17.       - path: /
  18.         backend:
  19.           serviceName: gitlab-k8s-demo-__CI_ENVIRONMENT_SLUG__
  20.           servicePort: 8000

当然如果想配置 https 访问的话我们可以自己用 CA 证书创建一个 tls 密钥，也可以使用cert-manager来自动为我们的应用程序添加 https。

当然要通过上面的域名进行访问，还需要进行 DNS 解析的，__CI_ENVIRONMENT_SLUG__-gitlab-k8s-demo.qikqiak.com其中__CI_ENVIRONMENT_SLUG__值为 live 或 dev，所以需要创建dev-gitlab-k8s-demo.qikqiak.com 和 live-gitlab-k8s-demo.qikqiak.com 两个域名的解析。

我们可以使用 DNS 解析服务商的 API 来自动创建域名解析，也可以使用 Kubernetes incubator 孵化的项目 external-dns operator 来进行操作。

所需要的资源清单和.gitlab-ci.yml文件已经准备好了，我们可以小小的添加一个文件去触发下 Gitlab CI 构建：

  1. $ touch test1
  2. $ git add .
  3. $ git commit -m"Testing the GitLab CI functionality #1"
  4. $ git push origin master

现在回到 Gitlab 中可以看到我们的项目触发了一个新的 Pipeline 的构建：

gitlab pipeline

可以查看最后一个阶段（stage）是否正确，如果通过了，证明我们已经成功将应用程序部署到 Kubernetes 集群中了，一个成功的review阶段如下所示：

review success

整个 Pipeline 构建成功后，我们可以在项目的环境菜单下面看到多了一个环境：

env

如果我们点击终止，就会调用.gitlab-ci.yml中定义的钩子on_stop: stop_review，点击View deployment就可以看到这次我们的部署结果（前提是DNS解析已经完成）：

view deployment

这就是关于 Gitlab CI 结合 Kubernetes 进行 CI/CD 的过程，具体详细的构建任务还需要结合我们自己的应用实际情况而定。下节课给大家介绍使用 Jenkins + Gitlab + Harbor + Helm + Kubernetes 来实现一个完整的 CI/CD 流水线作业。