目錄

1、GitLabCI & Runner 介紹

GitLab-CI 是一套 GitLab 提供給使用者使用的持續整合系統，GitLab 8.0 版本以後是預設整合並且預設啟用。GitLab-Runner 是配合 GitLab-CI 進行使用的，GitLab 裡面每個工程都會定義一些該工程的持續整合指令碼，該指令碼可配置一個或多個 Stage 例如構建、編譯、檢測、測試、部署等等。當工程有程式碼更新時，GitLab 會自動觸發 GitLab-CI，此時 CitLab-CI 會找到事先註冊好的 GitLab-Runner 通知並觸發該 Runner 來執行預先定義好的指令碼。

傳統的 GitLab-Runner 我們一般會選擇某個或某幾個機器上，可以 Docker 安裝啟動亦或是直接原始碼安裝啟動，都會存在一些痛點問題，比如發生單點故障，那麼該機器的所有 Runner 就不可用了；每個 Runner 所在機器環境不一樣，以便來完成不同型別的 Stage 操作，但是這種差異化配置導致管理起來很麻煩；資源分配不平衡，有的 Runner 執行工程指令碼出現擁塞時，而有的 Runner 缺處於空閒狀態；資源有浪費，當 Runner 處於空閒狀態時，也沒有安全釋放掉資源。因此，為了解決這些痛點，我們可以採用在 Kubernetes 叢集中執行 GitLab-Runner 來動態執行 GitLab-CI 指令碼任務，它整個流程如下圖：

這種方式帶來的好處有：

• 服務高可用，當某個節點出現故障時，Kubernetes 會自動建立一個新的 GitLab-Runner 容器，並掛載同樣的 Runner 配置，使服務達到高可用。
• 動態伸縮，合理使用資源，每次執行指令碼任務時，Gitlab-Runner 會自動建立一個或多個新的臨時 Runner，當任務執行完畢後，臨時 Runner 會自動登出並刪除容器，資源自動釋放，而且 Kubernetes 會根據每個節點資源的使用情況，動態分配臨時 Runner 到空閒的節點上建立，降低出現因某節點資源利用率高，還排隊等待在該節點的情況。
• 擴充套件性好，當 Kubernetes 叢集的資源嚴重不足而導致臨時 Runner 排隊等待時，可以很容易的新增一個 Kubernetes Node 到叢集中，從而實現橫向擴充套件。

2、環境、軟體準備

通過之前的文章 Kubernetes 叢集使用 Helm 搭建 GitLab 並配置 Ingress 和 Docker搭建自己的Gitlab CI Runner，我們已經演示瞭如何在本地安裝並配置 GilLab-Runner，同時也能夠在 Kubernetes 叢集中安裝 GitLab 服務。本次演示環境，我依舊是在本機 MAC OS 上操作，不過，需要將 GitLab-Runner 也安裝 Kubernetes 中，以下是安裝的軟體及版本：

• Docker: version 17.09.0-ce
• Oracle VirtualBox: version 5.1.20 r114628 (Qt5.6.2)
• GitLab: 10.6.2-ce.0
• GitLab-Runner：11.0.2
• Minikube: version v0.22.2
• Helm: version v2.8.0
• Kuberctl:
  
  • Client Version: v1.7.5
  • Server Version: v1.7.5

注意：這裡 Kubernetes 叢集搭建我使用 Minikube 來完成，Minikube 啟動的單節點 k8s Node 例項是需要執行在本機的 VM 虛擬機器裡面，所以需要提前安裝好 VM，這裡我選擇 Oracle VirtualBox。k8s 執行底層使用 Docker 容器，所以本機需要安裝好 Docker 環境，這裡忽略 Docker、VirtualBox、Minikube、Kuberctl 和 Helm 的安裝過程，著重介紹下 GitLab-Runner 的安裝並測試使用。

3、GitLab Runner 在 MacOS 上升級

繼上一篇文章，我們已經在 Kubernetes 叢集中搭建好了 GitLab 服務，我本地測試下是否能夠正常註冊 GitLab-Runner，注意：由於未更新，此時我本地的 GitLab-Runner 版本為 1.11.2，算是比較老的版本了。註冊前，我們得先去 GitLab 上新建一個專案去，這裡偷個懶，建立時選擇 Create from template，然後直接選擇 Spring 這個模板專案，並命名為 spring-devops 專案。後續操作都是基於此模板專案，就不在重複描述了。

$ sudo gitlab-runner register
Running in system-mode.

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://my.gitlag.com/
Please enter the gitlab-ci token for this runner:
g-1YUWB4_JoLgshuPJ6y
Please enter the gitlab-ci description for this runner:
my-gitlab
Please enter the gitlab-ci tags for this runner (comma separated):
kubernetes
Whether to run untagged builds [true/false]:
[false]: true
ERROR: Registering runner... failed                 runner=g-1YUWB4 status=404 Not Found
PANIC: Failed to register this runner. Perhaps you are having network problems 

註冊失敗，報錯了。其實這是因為 GitLab 跟 GitLab Runner 版本相容性不匹配導致的。詳細相容性列表可以點選 這裡 檢視。所以，我們需要先升級一下本地 GitLab-Runner 到最新版本，可參考 GitLab-Runner 安裝文件 執行。

1. 第一步：停止 GitLab-Runner 服務

   $ gitlab-runner stop

2. 第二步：下載 GitLab-Runner 原始碼，並覆蓋現有檔案

   $ curl -o /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64

3. 第三步：對檔案賦可執行許可權

   $ chmod +x /usr/local/bin/gitlab-runner

4. 第四步：啟動 GitLab-Runner 服務

   $ gitlab-runner start

OK，升級完畢後，通過 gitlab-runner --version 命名可以檢視當前安裝版本，我們再來執行一下注冊看下，妥妥沒有問題了。

# 註冊 runner
$ sudo gitlab-runner register
WARNING: Running in system-mode.

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://my.gitlab.com/
Please enter the gitlab-ci token for this runner:
g-1YUWB4_JoLgshuPJ6y
Please enter the gitlab-ci description for this runner:
my-gitlab
Please enter the gitlab-ci tags for this runner (comma separated):
kubernetes
Registering runner... succeeded                     runner=g-1YUWB4
Please enter the executor: virtualbox, docker+machine, docker-ssh+machine, docker, docker-ssh, parallels, shell, ssh, kubernetes:
kubernetes
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

# 檢視 Runner 列表
$ gitlab-runner list
Listing configured runners            ConfigFile=/Users/wanyang3/.gitlab-runner/config.toml
my-gitlab                             Executor=kubernetes Token=71c294dafefcd12358a773bb35d0ea URL=http://my.gitlab.com/

# 檢視 Runner 配置檔案
$ cat /Users/wanyang3/.gitlab-runner/config.toml
concurrent = 2
check_interval = 0

[[runners]]
  name = "my-gitlab"
  url = "http://my.gitlab.com/"
  token = "71c294dafefcd12358a773bb35d0ea"
  executor = "kubernetes"
  [runners.cache]
  [runners.kubernetes]
    host = ""
    bearer_token_overwrite_allowed = false
    image = ""
    namespace = ""
    namespace_overwrite_allowed = ""
    privileged = false
    service_account_overwrite_allowed = ""
    pod_annotations_overwrite_allowed = ""
    [runners.kubernetes.volumes]

注意：這裡 executor 執行型別，我特意選擇了 kubernetes，主要是看下選擇了 Kubernetes 作為執行型別的話，生成的 runner 配置有那些不同。通過 config.toml 檔案，我們可以看到 [runners.kubernetes] 下邊有很多配置，這些配置我就不在挨個介紹了，詳細配置可參考文件 [runners.kubernetes] section of advanced configuration 以及 Kubernetes executor。

4、Kubernetes 叢集中執行 GitLab Runner、 GitLab 並測試

好了，本地通過 GitLab-Runner 註冊 Kubernetes 叢集中的 GitLab 服務沒有問題，現在，我們需要將 GitLab-Runner 也安裝到 Kubernetes 叢集中，看下是否能夠註冊並執行 GitLab-CI 成功。根據 Run GitLab Runner on a Kubernetes cluster 文件，我們需要建立一個 ConfigMap 和 Deployment，並部署到 Kubernetes 叢集中。

新建 ConfigMap 檔案 gitlab-runner-configmap.yaml

$ vim gitlab-runner-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: gitlab-runner
  namespace: default
data:
  config.toml: |
    concurrent = 2

    [[runners]]
      name = "Kubernetes Runner"
      url = "http://my.gitlab.com/"
      token = "71c294dafefcd12358a773bb35d0ea"
      executor = "kubernetes"
      [runners.kubernetes]
        namespace = "default"
        image = "busybox"

注意：這裡有個坑，那就是 token 欄位，該欄位在 runner 註冊成功後，在容器的 /etc/gitlab-runner/config.toml 配置檔案中可以找到，而且該 token 跟 GitLab 上專案的 Settings > CI/CD > Runners settings > registration token 是不一致的，這個沒有問題。但是下邊 GitLab-Runner 的 Deployment 需要使用該 ConfigMap 配置 config.toml，此時，GitLab-Runner 還沒有執行 register 操作呢，如何獲取的到 token，而且每個 runner 註冊時，生成的 token 是不一樣的，沒法直接使用已存在的別的 runner 的 token。最後，我的方案是，可以不使用該 ConfigMap，下邊啟動了 GitLab-Runner 後，進入到容器內部，手動執行註冊。

新建 Deployment 檔案 gitlab-runner-deployment.yaml

$ vim gitlab-runner-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: gitlab-runner
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      name: gitlab-runner
  template:
    metadata:
      labels:
        name: gitlab-runner
    spec:
      containers:
      - args:
        - run
        image: gitlab/gitlab-runner:latest
        imagePullPolicy: IfNotPresent
        name: gitlab-runner
        volumeMounts:
        - mountPath: /etc/gitlab-runner
          name: config
        - mountPath: /etc/ssl/certs
          name: cacerts
          readOnly: true
      restartPolicy: Always
      volumes:
      - configMap:
          name: gitlab-runner
        name: config
      - hostPath:
          path: /usr/share/ca-certificates/mozilla
        name: cacerts

執行 kubectl 命令部署到 Kubernetes 中。

$ kubectl create -f gitlab-runner-configmap.yaml
configmap "gitlab-runner" created
$ kubectl create -f gitlab-runner-deployment.yaml
deployment "gitlab-runner" created
$ kubectl get pods
NAMESPACE     NAME                                 READY     STATUS    RESTARTS   AGE
default       gitlab-gitlab-ce-2349088227-z1nkn    1/1       Running   1          1d
default       gitlab-postgresql-1290581213-jbm0s   1/1       Running   1          1d
default       gitlab-redis-2286670209-dfrks        1/1       Running   1          1d
default       gitlab-runner-3178994166-1c10d       1/1       Running   0          13m

OK 服務已經啟動起來了，接下來，我們進入到 gitlab-runner-3178994166-1c10d 容器內部，註冊一下試試看。

$ kubectl exec -it gitlab-runner-3178994166-1c10d /bin/bash
root@gitlab-runner-3178994166-1c10d:/# gitlab-runner register
Running in system-mode.

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://my.gitlab.com/
Please enter the gitlab-ci token for this runner:
g-1YUWB4_JoLgshuPJ6y
Please enter the gitlab-ci description for this runner:
[gitlab-runner-3178994166-1c10d] : kubernetes-runner
Please enter the gitlab-ci tags for this runner (comma separated):
kubernetes
ERROR: Registering runner... failed                 runner=g-1YUWB4 status=couldn't execute POST against http://my.gitlab.com/api/v4/runners: Post http://my.gitlab.com/api/v4/runners: dial tcp: lookup my.gitlab.com on 10.0.0.10:53: no such host
PANIC: Failed to register this runner. Perhaps you are having network problems

額，註冊失敗了！看日誌，應該是找不到 my.gitlab.com 這個域名，也是，這個域名是我本地繫結 host 來完成了，不是一個正確的域名地址。那麼，我們在容器內繫結 host 試試看吧！

$ echo "192.168.99.100 my.gitlab.com" >> /etc/hosts

root@gitlab-runner-3178994166-1c10d:/# gitlab-runner register
Running in system-mode.

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://my.gitlab.com/
Please enter the gitlab-ci token for this runner:
g-1YUWB4_JoLgshuPJ6y
Please enter the gitlab-ci description for this runner:
[gitlab-runner-3178994166-1c10d] : kubernetes-runner
Please enter the gitlab-ci tags for this runner (comma separated):
kubernetes
Registering runner... succeeded                     runner=g-1YUWB4
Please enter the executor: kubernetes, docker, ssh, docker-ssh+machine, virtualbox, docker+machine, docker-ssh, parallels, shell:
kubernetes
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

[email protected]:/# gitlab-runner list
Listing configured runners                          ConfigFile=/etc/gitlab-runner/config.toml
kubernetes-runner                                   Executor=kubernetes Token=bb64a2fa634084d169b2c9dd992d45 URL=http://my.gitlab.com/

註冊成功，目前看來一切還是比較順利的，在 GitLab 裡 spring-devops 專案下 Setting > CI/CD Settings > Runners settings 下也是可以看到該 runner 的，並且是 active 可用狀態。

接下來，我們測試一下 GitLab-CI 觸發 GitLab-Runner 好不好使吧！首先，我們得有一個 .gitlab-ci.yml 的指令碼檔案，剛好這個 spring-devops 專案使用的模板就存在這個檔案，不過我們還需要修改一下，增加 tags 標籤，指明使用剛註冊的 tag 為 kubernetes 的 runner 來執行，不然執行時會報錯 This build is stuck.... 這樣的資訊，我貼一下修改之後的檔案如下：

$ cat .gitlab-ci.yml
image: maven:3.5-jdk-8

variables:
  MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=WARN -Dorg.slf4j.simpleLogger.showDateTime=true -Djava.awt.headless=true"
  MAVEN_CLI_OPTS: "--batch-mode --errors --fail-at-end --show-version -DinstallAtEnd=true -DdeployAtEnd=true"

cache:
  paths:
    - .m2/repository

compile:
  stage: build
  script:
    - 'mvn $MAVEN_CLI_OPTS test-compile'
  tags:
    - kubernetes

verify:
  stage: test
  script:
    - 'mvn $MAVEN_CLI_OPTS verify'
  artifacts:
    paths:
    - target/*.jar
  tags:
    - kubernetes

這個 CI 指令碼檔案很簡單，只有 compile 和 verify 兩步，而且是基於 maven:3.5-jdk-8 映象執行，tags: - kubernetes 就是我剛新加的配置。提交併 Push 修改到 GitLab 倉庫，將會自動觸發可用並且匹配 tag 的 runner 執行（如果，沒有自動觸發，請到專案 Setting > CI/CD > General pipelines settings > Auto DevOps > 選擇 Instance default (disabled) 選項，其他項按實際需求配置）。CI/CD 流程可以啟動啦！不過很遺憾，第一步 compile 就失敗了。

看日誌，顯示 Clone 倉庫時不能識別 my.gitlab.com host。好吧，還是避不開這個問題。不過，從日誌，我們還可以得到幾個明顯的資訊。

...
Using Kubernetes namespace: default
Using Kubernetes executor with image maven:3.5-jdk-8 ...
Waiting for pod default/runner-bb64a2fa-project-1-concurrent-0gwxbd to be running, status is Pending
Running on runner-bb64a2fa-project-1-concurrent-0gwxbd via gitlab-runner-3178994166-mz5pq...
...

• 首先，當 GitLab-Runner 註冊時選擇 kubernetes 型別沒有指定 namespace 時，預設選擇 default 作為名稱空間。
• 其次，它使用了指令碼指定的映象 maven:3.5-jdk-8 來執行，如果指令碼沒指定，那麼它會使用配置檔案中的預設 image 來使用。
• 最後，我們會發現，真正執行 Job 指令碼的不是 gitlab-runner Pod，而是它建立的新的臨時 runner pod 來執行，執行完任務指令碼後，臨時 runner 會自動銷燬，而 gitlab-runner 依舊存在，那我們就明白了，Kubernetes 叢集中的 gitlab-runner 主要是完成註冊、接受並分配任務的工作，充當一箇中介者的作用。也正是因為這個設計，才能帶來文章之前說的種種好處。

好了，言歸正傳，還是得看看那個問題。原因也很明顯，之前配置的 ingress 是外部訪問叢集內部服務時指定的 host，容器內訪問肯定是不認的，容器內服務可以通過 Cluster_ip 進行訪問或 DNS 訪問。然而，這個 Cluster_ip 只有 gitlab-ce 服務啟動之後才能獲取的到，它每次啟動都是變化的，我們通過 Helm 安裝 GitLab 時沒法指定這個 Cluster_ip，而且，臨時 runner Pod 是由 gitlab-runner Pod 建立的，不受我們的控制，也沒法給它繫結 host。當然，如果我們的 Gitlab 服務執行在 LoadBalancer 型別 Service 或者有真正的域名來繫結該服務時，上邊的問題就迎刃而解了。

那麼，在沒有上述條件的情況下，我們就真的沒法解決了嗎？

==========================這裡是分界線==========================

我們可以，通過安裝 GitLab 服務到非 Kubernetes 叢集，比如本地、伺服器、虛擬機器等，只要是 Kubernetes 叢集內 Pod 可以訪問的到 GitLab 服務的地方都可以。

5、GitLab 服務安裝在非 Kubernetes 叢集測試

這裡我在本地虛擬機器上以 Docker 方式安裝 GitLab 服務，安裝命令很簡單，安裝完畢，外部和 Kubernetes 內部可以通過 http://10.222.78.79/ 地址訪問的到。

$ sudo docker run --detach \
    --hostname 10.222.78.79 \
    --publish 443:443 --publish 80:80 --publish 22:22 \
    --name gitlab \
    --restart always \
    --volume /data0/gitlab/config:/etc/gitlab:Z \
    --volume /data0/gitlab/logs:/var/log/gitlab:Z \
    --volume /data0/gitlab/data:/var/opt/gitlab:Z \
    gitlab/gitlab-ce:10.6.2-ce.0

啟動成功後，同樣的操作，新建一個 spring-devops 專案，以及修改 .gitlab-ci.yml 檔案。接下來，在 Kubernete 叢集中 gitlab-runner 容器內走一波 register 操作，同樣沒問題哈！

[email protected]3178994166-mz5pq:/etc/gitlab-runner# gitlab-runner register
Running in system-mode.

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://10.222.78.79/
Please enter the gitlab-ci token for this runner:
rJQEh4d-M_g-K2SLPLJw
Please enter the gitlab-ci description for this runner:
[gitlab-runner-3178994166-mz5pq]: kubernetes-runner
Please enter the gitlab-ci tags for this runner (comma separated):
kubernetes
Registering runner... succeeded                     runner=rJQEh4d-
Please enter the executor: kubernetes, docker, parallels, virtualbox, docker+machine, docker-ssh+machine, docker-ssh, shell, ssh:
kubernetes
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

註冊成功，看下新 GitLab 中 Runner Setting 是否顯示成功吧！

提交修改到 GitLab 倉庫，自動觸發 CI 指令碼任務，這次看下能不能過吧！

這次，終於不用擔心 Clone 不到專案的問題啦！我們可以看到 build 和 test 兩步都正常完成，整個流程可以跑通。

這裡，我要在提一下，上邊第一步 build 和第二步 test，通過日誌輸出，我們可以看到 gitlab-runner 啟動了兩個臨時 runner 來分別完成這兩步任務。它的執行順序是 gitlab-runner 建立臨時 runner Pod 執行 build 任務，任務完成後該 Pod 自動銷燬，然後，建立另一個臨時 runner Pod 執行 test 任務，任務完成後該 Pod 自動銷燬。通過日誌中臨時 runner 名稱可以看到它們是不同的 Pod。

test：Running on runner-8804ad3f-project-1-concurrent-09hcq8 via gitlab-runner-3178994166-mz5pq

build：Running on runner-8804ad3f-project-1-concurrent-0vzrjw via gitlab-runner-3178994166-mz5pq

其實，通過 kubectl 命令也可以看到。

# test 任務執行時，建立臨時 runner。
$ kubectl get pods
NAME                                          READY     STATUS    RESTARTS   AGE
gitlab-runner-3178994166-mz5pq                1/1       Running   0          5h
runner-8804ad3f-project-1-concurrent-09hcq8   2/2       Running   0          21s

# test 任務執行完畢後，會發現臨時 runner 已經自動銷燬了。
$ kubectl get pods
NAME                             READY     STATUS    RESTARTS   AGE
gitlab-runner-3178994166-mz5pq   1/1       Running   0          5h

最後，附帶說一下，日誌開頭處顯示 WARNING: Namespace is empty, therefore assuming 'default'. 這個，是因為沒有設定預設 namespace 導致的，我們可以通過到 gitlab-runner 容器內部修改 config.toml 檔案。

# gitlab-runner 容器內執行
$ vim /etc/gitlab-runner/config.toml
concurrent = 2
check_interval = 0

[[runners]]
  name = "kubernetes-runner"
  url = "http://10.222.78.79/"
  token = "8804ad3fc5eaf0cc3fadf3f719f427"
  executor = "kubernetes"
  [runners.cache]
  [runners.kubernetes]
    host = ""
    bearer_token_overwrite_allowed = false
    image = "busybox"
    namespace = "default"
    namespace_overwrite_allowed = ""
    privileged = false
    service_account_overwrite_allowed = ""
    pod_annotations_overwrite_allowed = ""
    [runners.kubernetes.volumes]

• namespace 處指定為 “default”，也可以是其他名稱空間，如果指定其他名稱空間，要提前建立好該 namespaces。
• Image 處可以指定臨時 runner 使用的基礎映象，當 .gitlab-ci.yml 中未指定映象時，預設使用該映象，例如我填寫為 busybox。
• [runners.kubernetes.volumes] 處可以指定掛載 host_path、pvc、config-map、empty_dir、secret 等幾種 Kubernetes 掛載方式，
• [runners.kubernetes.node_selector] 處可以指定 key=value 方式，來將 runner 排程到匹配值的節點上。

參考資料