kubernetes(37)：持續集成(6)-部署gitlab-runner實現GitlabCI-k8s+gitlab+harbor

本文轉載自查看原文 2019-10-24 10:50 1000 git/ docker-kubernetes

Gitlab CI-k8s+gitlab+harbor

https://www.qikqiak.com/k8s-book/docs/65.Gitlab%20CI.html

1 簡介

從 Gitlab 8.0 開始，Gitlab CI 就已經集成在 Gitlab 中，我們只要在項目中添加一個.gitlab-ci.yml文件，然后添加一個Runner，即可進行持續集成。在介紹 Gitlab CI 之前，我們先看看一些 Gitlab CI 的一些相關概念。

1.1 Pipeline

可以參考Jenkins-pipeline(2)：開發階段pipeline：gitlab和Jenkins-pipeline自動集成

一次 Pipeline 其實相當於一次構建任務，里面可以包含很多個流程，如安裝依賴、運行測試、編譯、部署測試服務器、部署生產服務器等流程。任何提交或者 Merge Request 的合並都可以觸發 Pipeline 構建，如下圖所示：

+------------------+           +----------------+
|                  |  trigger  |                |
|   Commit / MR    +---------->+    Pipeline    |
|                  |           |                |
+------------------+           +----------------+

1.2 Stages

Stages 表示一個構建階段，也就是上面提到的一個流程。我們可以在一次 Pipeline 中定義多個 Stages，這些 Stages 會有以下特點：

所有 Stages 會按照順序運行，即當一個 Stage 完成后，下一個 Stage 才會開始
只有當所有 Stages 完成后，該構建任務 (Pipeline) 才會成功
如果任何一個 Stage 失敗，那么后面的 Stages 不會執行，該構建任務 (Pipeline) 失敗

Stages 和 Pipeline 的關系如下所示：

|                                                        |
|  Pipeline                                              |
|                                                        |
|  +-----------+     +------------+      +------------+  |
|  |  Stage 1  |---->|   Stage 2  |----->|   Stage 3  |  |
|  +-----------+     +------------+      +------------+  |
|                                                        |
+--------------------------------------------------------+

1.3 Jobs

Jobs 表示構建工作，表示某個 Stage 里面執行的工作。我們可以在 Stages 里面定義多個 Jobs，這些 Jobs 會有以下特點：

相同 Stage 中的 Jobs 會並行執行
相同 Stage 中的 Jobs 都執行成功時，該 Stage 才會成功
如果任何一個 Job 失敗，那么該 Stage 失敗，即該構建任務 (Pipeline) 失敗

Jobs 和 Stage 的關系如下所示：

|                                          |

|  Stage 1                                 |

|                                          |

|  +---------+  +---------+  +---------+   |

|  |  Job 1  |  |  Job 2  |  |  Job 3  |   |

|  +---------+  +---------+  +---------+   |

|                                          |

+------------------------------------------+

2 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 相關的服務。

2.1 驗證 Kubernetes 集群

執行下面的命令驗證 Kubernetes 集群：

# kubectl cluster-info
Kubernetes master is running at https://10.6.76.25:6443
Alertmanager is running at https://10.6.76.25:6443/api/v1/namespaces/kube-system/services/alertmanager:http/proxy
KubeDNS is running at https://10.6.76.25:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
kube-state-metrics is running at https://10.6.76.25:6443/api/v1/namespaces/kube-system/services/kube-state-metrics:http-metrics/proxy
NodeExporter is running at https://10.6.76.25:6443/api/v1/namespaces/kube-system/services/node-exporter:metrics/proxy
Prometheus is running at https://10.6.76.25:6443/api/v1/namespaces/kube-system/services/prometheus:http/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

#cluster-info這個命令會顯示當前鏈接的集群狀態和可用的集群服務列表。

2.2 獲取 Gitlab CI Register Token

kubernetes(36)：持續集成(5)-k8s集群中搭建gitlab

前面我們已經成功安裝了 Gitlab，在瀏覽器中打開gitlab.xxx.com頁面，然后登錄后進入到管理頁面http://gitlab.xxx.com/admin，然后點擊導航欄中的Runner，可以看到該頁面中有兩個總要的參數，一個是 URL，另外一個就是 Register Token，下面的步驟中需要用到這兩個參數值。

注意：不要隨便泄露 Token

2.3 編寫 Gitlab CI Runner 資源清單文件

runner-cm.yaml

同樣將 Runner 相關的資源對象都安裝到kube-ops這個 namespace 下面，首先，我們通過 ConfigMap 資源來傳遞 Runner 鏡像所需的環境變量（runner-cm.yaml）:

apiVersion: v1
data:
  REGISTER_NON_INTERACTIVE: "true"
  REGISTER_LOCKED: "false"
  METRICS_SERVER: "0.0.0.0:9100"
  CI_SERVER_URL: "http://gitlab.kube-ops.svc.cluster.local/ci"
  RUNNER_REQUEST_CONCURRENCY: "4"
  RUNNER_EXECUTOR: "kubernetes"
  KUBERNETES_NAMESPACE: "kube-ops"
  KUBERNETES_PRIVILEGED: "true"
  KUBERNETES_CPU_LIMIT: "1"
  KUBERNETES_CPU_REQUEST: "500m"
  KUBERNETES_MEMORY_LIMIT: "1Gi"
  KUBERNETES_SERVICE_CPU_LIMIT: "1"
  KUBERNETES_SERVICE_MEMORY_LIMIT: "1Gi"
  KUBERNETES_HELPER_CPU_LIMIT: "500m"
  KUBERNETES_HELPER_MEMORY_LIMIT: "100Mi"
  KUBERNETES_PULL_POLICY: "if-not-present"
  KUBERNETES_TERMINATIONGRACEPERIODSECONDS: "10"
  KUBERNETES_POLL_INTERVAL: "5"
  KUBERNETES_POLL_TIMEOUT: "360"
kind: ConfigMap
metadata:
  labels:
    app: gitlab-ci-runner
  name: gitlab-ci-runner-cm
  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 變量即可，如下所示：

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

如果定義的 Gitlab 域名並不是通過外網的 DNS 進行解析的，而是通過 /etc/hosts 倆進行映射的，那么我們就需要在 runner 的 Pod 中去添加 git.qikqiak.com 對應的 hosts 了，那么如何添加呢？我們可以想到的是 Pod 的 hostAlias 可以實現這個需求，但是 runner 的 Pod 是自動生成的，沒辦法直接去定義 hostAlias。這里我們就可以通過上面的--pre-clone-script參數來指定一段腳本來添加 hosts 信息，也就是在上面的 ConfigMap 中添加環境變量RUNNER_PRE_CLONE_SCRIPT的值即可：

RUNNER_PRE_CLONE_SCRIPT = "echo 'xx.xx.xxx.xx git.qikqiak.com' >> /etc/hosts"
#這個后面就用到了

runner-scripts-cm.yaml

除了上面的一些環境變量相關的配置外，還需要一個用於注冊、運行和取消注冊 Gitlab CI Runner 的小腳本。只有當 Pod 正常通過 Kubernetes（TERM信號）終止時，才會觸發轉輪取消注冊。如果強制終止 Pod（SIGKILL信號），Runner 將不會注銷自身。必須手動完成對這種被殺死的 Runner 的清理，配置清單文件如下：（runner-scripts-cm.yaml）

apiVersion: v1
data:
  run.sh: |
    #!/bin/bash
    unregister() {
        kill %1
        echo "Unregistering runner ${RUNNER_NAME} ..."
        /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}
        exit $?
    }
    trap 'unregister' EXIT HUP INT QUIT PIPE TERM
    echo "Registering runner ${RUNNER_NAME} ..."
    /usr/bin/gitlab-ci-multi-runner register -r ${GITLAB_CI_TOKEN}
    sed -i 's/^concurrent.*/concurrent = '"${RUNNER_REQUEST_CONCURRENCY}"'/' /home/gitlab-runner/.gitlab-runner/config.toml
    echo "Starting runner ${RUNNER_NAME} ..."
    /usr/bin/gitlab-ci-multi-runner run -n ${RUNNER_NAME} &
    wait
kind: ConfigMap
metadata:
  labels:
    app: gitlab-ci-runner
  name: gitlab-ci-runner-scripts
  namespace: kube-ops

可以看到需要一個 GITLAB_CI_TOKEN，然后我們用 Gitlab CI runner token 來創建一個 Kubernetes secret 對象。將 token 進行 base64 編碼：

# echo "vjrZr36yypzdXnBSj6sy" |  base64 -w0
dmpyWnIzNnl5cHpkWG5CU2o2c3kK

gitlab-ci-token-secret.yaml

然后使用上面的 token 創建一個 Secret 對象：(gitlab-ci-token-secret.yaml)

apiVersion: v1
kind: Secret
metadata:
  name: gitlab-ci-token
  namespace: kube-ops
  labels:
    app: gitlab-ci-runner
data:
  GITLAB_CI_TOKEN: dmpyWnIzNnl5cHpkWG5CU2o2c3kK

# kubectl apply -f gitlab-ci-token-secret.yaml
secret/gitlab-ci-token created

runner-statefulset.yaml

然后接下來就可以來編寫一個用於真正運行 Runner 的控制器對象，我們這里使用 Statefulset。首先，在開始運行的時候，嘗試取消注冊所有的同名 Runner，當節點丟失時（即NodeLost事件），這尤其有用。然后再嘗試重新注冊自己並開始運行。在正常停止 Pod 的時候，Runner 將會運行unregister命令來嘗試取消自己，所以 Gitlab 就不能再使用這個 Runner 了，這個是通過 Kubernetes Pod 生命周期中的hooks來完成的。

另外通過使用envFrom來指定Secrets和ConfigMaps來用作環境變量，對應的資源清單文件如下：

(runner-statefulset.yaml)

apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: gitlab-ci-runner
  namespace: kube-ops
  labels:
    app: gitlab-ci-runner
spec:
  updateStrategy:
    type: RollingUpdate
  replicas: 2
  serviceName: gitlab-ci-runner
  template:
    metadata:
      labels:
        app: gitlab-ci-runner
    spec:
      volumes:
      - name: gitlab-ci-runner-scripts
        projected:
          sources:
          - configMap:
              name: gitlab-ci-runner-scripts
              items:
              - key: run.sh
                path: run.sh
                mode: 0755
      serviceAccountName: gitlab-ci
      securityContext:
        runAsNonRoot: true
        runAsUser: 999
        supplementalGroups: [999]
      containers:
      - image: gitlab/gitlab-runner:latest
        name: gitlab-ci-runner
        command:
        - /scripts/run.sh
        envFrom:
        - configMapRef:
            name: gitlab-ci-runner-cm
        - secretRef:
            name: gitlab-ci-token
        env:
        - name: RUNNER_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        ports:
        - containerPort: 9100
          name: http-metrics
          protocol: TCP
        volumeMounts:
        - name: gitlab-ci-runner-scripts
          mountPath: "/scripts"
          readOnly: true
      restartPolicy: Always

runner-rbac.yaml

可以看到上面我們使用了一個名為 gitlab-ci 的 serviceAccount，新建一個 rbac 資源清單文件：(runner-rbac.yaml)

apiVersion: v1
kind: ServiceAccount
metadata:
  name: gitlab-ci
  namespace: kube-ops
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: gitlab-ci
  namespace: kube-ops
rules:
  - apiGroups: [""]
    resources: ["*"]
    verbs: ["*"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: gitlab-ci
  namespace: kube-ops
subjects:
  - kind: ServiceAccount
    name: gitlab-ci
    namespace: kube-ops
roleRef:
  kind: Role
  name: gitlab-ci
  apiGroup: rbac.authorization.k8s.io

2.4 創建 Runner 資源對象

# ls gitlab-ci-token-secret.yaml runner-*
gitlab-ci-token-secret.yaml  runner-cm.yaml  runner-rbac.yaml  runner-statefulset.yaml  runner-scripts-cm.yaml

kubectl apply -f runner-cm.yaml
kubectl apply -f runner-scripts-cm.yaml
kubectl apply -f gitlab-ci-token-secret.yaml
kubectl apply -f runner-rbac.yaml
kubectl apply -f runner-statefulset.yaml

創建完成后，可以通過查看 Pod 狀態判斷 Runner 是否運行成功：

# kubectl -n kube-ops  get pod| grep gitlab-ci
gitlab-ci-runner-0                             1/1     Running   0          4m35s
gitlab-ci-runner-1                             1/1     Running   0          116s

以看到已經成功運行了兩個（具體取決於StatefulSet清單中的副本數) Runner 實例，然后切換到 Gitlab Admin 頁面下面的 Runner 頁面：

當然我們也可以根據需要更改 Runner 的一些配置，比如添加 tag 標簽等。

3 Gitlab CI

准備測試代碼

下載代碼上傳到gitlab

測試項目cnych/presentation-gitlab-k8s 我fork了一下

接下來使用 Gitlab CI 所用到的代碼庫可以從 Github 上獲得：https://github.com/wangxu01/gitlab-ci-k8s-demo ，可以在 Gitlab 上新建一個項目導入該倉庫，當然也可以新建一個空白的倉庫，然后將 Github 上面的項目 Clone 到本地后，更改遠程倉庫地址即可：

[root@k8s-master test]# git clone https://github.com/wangxu01/gitlab-ci-k8s-demo.git
正克隆到 'gitlab-ci-k8s-demo'...
remote: Enumerating objects: 2036, done.
remote: Total 2036 (delta 0), reused 0 (delta 0), pack-reused 2036
接收對象中: 100% (2036/2036), 3.29 MiB | 767.00 KiB/s, done.
處理 delta 中: 100% (787/787), done.
[root@k8s-master test]# cd gitlab-ci-k8s-demo/
[root@k8s-master gitlab-ci-k8s-demo]# ls
Dockerfile  Gopkg.lock  Gopkg.toml  LICENSE  main.go  Makefile  manifests  README.md  vendor  VERSION
[root@k8s-master gitlab-ci-k8s-demo]# git remote set-url origin ssh://git@gitlab.wangxu.com:30022/root/presentation-gitlab-k8s.git
[root@k8s-master gitlab-ci-k8s-demo]# git push -u origin master
Counting objects: 2036, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (1133/1133), done.
Writing objects: 100% (2036/2036), 3.29 MiB | 0 bytes/s, done.
Total 2036 (delta 787), reused 2036 (delta 787)
remote: Resolving deltas: 100% (787/787), done.
remote:
remote: The private project root/presentation-gitlab-k8s was successfully created.
remote:
remote: To configure the remote, run:
remote:   git remote add origin git@gitlab.wangxu.com:root/presentation-gitlab-k8s.git
remote:
remote: To view the project, visit:
remote:   http://gitlab.wangxu.com/root/presentation-gitlab-k8s
remote:
To ssh://git@gitlab.wangxu.com:30022/root/presentation-gitlab-k8s.git
 * [new branch]      master -> master
分支 master 設置為跟蹤來自 origin 的遠程分支 master。
[root@k8s-master gitlab-ci-k8s-demo]#

自動觸發部署

當我們把倉庫推送到 Gitlab 以后，應該可以看到 Gitlab CI 開始執行構建任務了:

此時 Runner Pod 所在的 namespace 下面也會出現兩個新的 Pod：

# kubectl get pods -n kube-ops
……
runner-aczwwb3k-project-2-concurrent-0chkmk    0/2     ContainerCreating   0          2m14s
runner-aczwwb3k-project-2-concurrent-1nbfbv    0/2     ContainerCreating   0          2m13s

錯誤1-gitlab域名

這兩個新的 Pod 就是用來執行具體的 Job 任務的，這里同時出現兩個證明第一步是並行執行的兩個任務，從上面的 Pipeline 中也可以看到是 test 和 test2 這兩個 Job。我們可以看到在執行 image_build 任務的時候出現了錯誤：

可以點擊查看這個 Job 失敗詳細信息：

Running with gitlab-runner 12.4.0 (1564076b)
  on gitlab-ci-runner-1 DQisyaVT
Using Kubernetes namespace: kube-ops
Using Kubernetes executor with image golang:1.10.3-stretch ...
Waiting for pod kube-ops/runner-dqisyavt-project-2-concurrent-07lr98 to be running, status is Pending
Running on runner-dqisyavt-project-2-concurrent-07lr98 via gitlab-ci-runner-1...
Fetching changes with git depth set to 50...
Initialized empty Git repository in /builds/root/presentation-gitlab-k8s/.git/
Created fresh repository.
fatal: unable to access 'http://gitlab-ci-token:[MASKED]@gitlab.wangxu.com/root/presentation-gitlab-k8s.git/': Could not resolve host: gitlab.wangxu.com ERROR: Job failed: command terminated with exit code 1

這是因為我的gitlab域名沒有在 run pod進行解析

# cat runner-cm.yaml
apiVersion: v1
data:
  REGISTER_NON_INTERACTIVE: "true"
  REGISTER_LOCKED: "false"
  METRICS_SERVER: "0.0.0.0:9100"
  CI_SERVER_URL: "http://gitlab.kube-ops.svc.cluster.local/ci"
  RUNNER_REQUEST_CONCURRENCY: "4"
  RUNNER_EXECUTOR: "kubernetes"
  KUBERNETES_NAMESPACE: "kube-ops"
  KUBERNETES_PRIVILEGED: "true"
  KUBERNETES_CPU_LIMIT: "1"
  KUBERNETES_CPU_REQUEST: "500m"
  KUBERNETES_MEMORY_LIMIT: "1Gi"
  KUBERNETES_SERVICE_CPU_LIMIT: "1"
  KUBERNETES_SERVICE_MEMORY_LIMIT: "1Gi"
  KUBERNETES_HELPER_CPU_LIMIT: "500m"
  KUBERNETES_HELPER_MEMORY_LIMIT: "100Mi"
  KUBERNETES_PULL_POLICY: "if-not-present"
  KUBERNETES_TERMINATIONGRACEPERIODSECONDS: "10"
  KUBERNETES_POLL_INTERVAL: "5"
  KUBERNETES_POLL_TIMEOUT: "360"
  RUNNER_PRE_CLONE_SCRIPT : "echo '10.6.76.23 gitlab.wangxu.com' >> /etc/hosts"
  RUNNER_PRE_CLONE_SCRIPT : "echo '10.6.76.24 gitlab.wangxu.com' >> /etc/hosts"
kind: ConfigMap
metadata:
  labels:
    app: gitlab-ci-runner
  name: gitlab-ci-runner-cm
  namespace: kube-ops

#重啟runner
kubectl apply -f  runner-cm.yaml
kubectl delete -f  runner-statefulset.yaml
kubectl apply -f  runner-statefulset.yaml

錯誤2-代碼配置文件

下載代碼通過了，但在執行 image_build 任務的時候出現了錯誤：

WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Error response from daemon: Get http://registry.qikqiak.com/v1/users/: dial tcp: lookup registry.qikqiak.com on 10.96.0.10:53: no such host

這里調用的還是原git的地址

我們把原項目的registry.qikqiak.com 改成自己的gitlab.wangxu.com 再提交一下

[root@k8s-master gitlab-ci-k8s-demo]# grep -r   registry.qikqiak.com  *
manifests/deployment.yaml:        image: registry.qikqiak.com/gitdemo/gitlab-k8s:__VERSION__
[root@k8s-master gitlab-ci-k8s-demo]# vim manifests/deployment.yaml
[root@k8s-master gitlab-ci-k8s-demo]# grep -r   image:  *
manifests/deployment.yaml:        image: harbor.wangxu.com/gitdemo/gitlab-k8s:__VERSION__
vendor/golang.org/x/crypto/openpgp/packet/userattribute_test.go:                        t.Errorf("Error decoding JPEG image:%v", err)
[root@k8s-master gitlab-ci-k8s-demo]# git add .
[root@k8s-master gitlab-ci-k8s-demo]# git commit -m 'change image'
[master 532d6d0] change image
 1 file changed, 1 insertion(+), 1 deletion(-)
(reverse-i-search)`': ^C
[root@k8s-master gitlab-ci-k8s-demo]# git push origin master
Counting objects: 7, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 357 bytes | 0 bytes/s, done.
Total 4 (delta 3), reused 0 (delta 0)
To ssh://git@gitlab.wangxu.com:30022/root/presentation-gitlab-k8s.git
   3fec16d..532d6d0  master -> master
[root@k8s-master gitlab-ci-k8s-demo]#

我們也沒有在 Gitlab 中開啟 Container Registry，所以環境變量中並沒有這些值，我們這里使用 Harbor 來作為我們的鏡像倉庫，這里我們只需要把 Harbor 相關的配置以參數的形式配置到環境中就可以了。

定位到項目 -> 設置 -> CI/CD，展開Environment variables欄目，配置鏡像倉庫相關的參數值：

配置上后，我們在上面失敗的 Job 任務上點擊“重試”，在重試過后依然可以看到會出現下面的錯誤信息：

$ docker login -u "${CI_REGISTRY_USER}" -p "${CI_REGISTRY_PASSWORD}" registry.qikqiak.com
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Error response from daemon: Get http://registry.qikqiak.com/v1/users/: dial tcp: lookup registry.qikqiak.com on 10.96.0.10:53: no such host
ERROR: Job failed: command terminated with exit code 1

原地址還是沒有改過來，這個其實是配置在.gitlab-ci.yml文件

[root@k8s-master gitlab-ci-k8s-demo]# sed -i 's/git.qikqiak.com/gitlab.wangxu.com/g' .gitlab-ci.yml
[root@k8s-master gitlab-ci-k8s-demo]# sed -i 's/registry.qikqiak.com/harbor.wangxu.com/g' .gitlab-ci.yml
[root@k8s-master gitlab-ci-k8s-demo]# git add .
[root@k8s-master gitlab-ci-k8s-demo]# git commit -m 'change 5'
[master dce9e4c] change 5
 1 file changed, 5 insertions(+), 5 deletions(-)
[root@k8s-master gitlab-ci-k8s-demo]# git push origin master
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 319 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 0 (delta 0)
To ssh://git@gitlab.wangxu.com:30022/root/presentation-gitlab-k8s.git
   acbed8f..dce9e4c  master -> master
[root@k8s-master gitlab-ci-k8s-demo]#

錯誤3-harbor域名

$ docker login -u "${CI_REGISTRY_USER}" -p "${CI_REGISTRY_PASSWORD}" harbor.wangxu.com
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Error response from daemon: Get http://harbor.wangxu.com/v1/users/: dial tcp: lookup harbor.wangxu.com on 10.96.0.10:53: no such host

還是域名的問題

#vim runner-cm.yaml
...
  RUNNER_PRE_CLONE_SCRIPT : "echo '10.6.76.23 gitlab.wangxu.com harbor.wangxu.com' >> /etc/hosts"
  RUNNER_PRE_CLONE_SCRIPT : "echo '10.6.76.24 gitlab.wangxu.com harbor.wangxu.com' >> /etc/hosts"
...

kubectl apply -f  runner-cm.yaml
kubectl delete -f  runner-statefulset.yaml
kubectl apply -f  runner-statefulset.yaml

錯誤4-配置環境變量

然后又失敗了

$ docker login -u "${CI_REGISTRY_USER}" -p "${CI_REGISTRY_PASSWORD}" harbor.wangxu.com
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Error response from daemon: Get https://harbor.wangxu.com/v2/: unauthorized: authentication required
ERROR: Job failed: command terminated with exit code 1

Harbor密碼寫錯了選中受保護

編譯完成

終於過去了

Running with gitlab-runner 12.4.0 (1564076b)
  on gitlab-ci-runner-0 ztHmfWd9
Using Kubernetes namespace: kube-ops
Using Kubernetes executor with image docker:latest ...
Waiting for pod kube-ops/runner-zthmfwd9-project-3-concurrent-06mlgk to be running, status is Pending
Running on runner-zthmfwd9-project-3-concurrent-06mlgk via gitlab-ci-runner-0...
$ echo '10.6.76.24 gitlab.wangxu.com harbor.wangxu.com' >> /etc/hosts
Fetching changes with git depth set to 50...
Initialized empty Git repository in /builds/root/presentation-gitlab-k8s/.git/
Created fresh repository.
From http://gitlab.wangxu.com/root/presentation-gitlab-k8s
 * [new branch]      master     -> origin/master
Checking out d4bfe70b as master...

Skipping Git submodules setup
Downloading artifacts for compile (126)...
Downloading artifacts from coordinator... ok        id=126 responseStatus=200 OK token=4yKS-1uT
$ mkdir -p "/go/src/gitlab.wangxu.com/${CI_PROJECT_NAMESPACE}"
$ ln -sf "${CI_PROJECT_DIR}" "/go/src/gitlab.wangxu.com/${CI_PROJECT_PATH}"
$ cd "/go/src/gitlab.wangxu.com/${CI_PROJECT_PATH}/"
$ docker info
Client:
 Debug Mode: false

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 0
 Server Version: 17.03.2-ce
 Storage Driver: overlay
  Backing Filesystem: xfs
  Supports d_type: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host macvlan null overlay
  Log: 
 Swarm: inactive
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 4ab9917febca54791c5f071a9d1f404867857fcc
 runc version: 54296cf40ad8143b62dbcaa1d90e520a2136ddfe
 init version: 949e6fa
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.2.10-1.el7.elrepo.x86_64
 Operating System: Alpine Linux v3.5 (containerized)
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 7.783GiB
 Name: runner-zthmfwd9-project-3-concurrent-06mlgk
 ID: S4QT:6C5I:BKXI:3HX3:FTRQ:ZGO2:2AUP:X5G5:YR2I:MHUV:XMYE:XTWU
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Experimental: false
 Insecure Registries:
  harbor.wangxu.com
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: overlay: the backing xfs filesystem is formatted without d_type support, which leads to incorrect behavior.
         Reformat the filesystem with ftype=1 to enable d_type support.
         Running without d_type support will not be supported in future releases.
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
$ docker login -u "${CI_REGISTRY_USER}" -p "${CI_REGISTRY_PASSWORD}" "${CI_REGISTRY}"
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded
$ docker build -t "${CI_REGISTRY_IMAGE}:latest" .
Sending build context to Docker daemon  28.63MB

Step 1/4 : FROM busybox:1.28.4-glibc
1.28.4-glibc: Pulling from library/busybox
5497949500d2: Pulling fs layer
5497949500d2: Verifying Checksum
5497949500d2: Download complete
5497949500d2: Pull complete
Digest: sha256:bda689514be526d9557ad442312e5d541757c453c50b8cf2ae68597c291385a1
Status: Downloaded newer image for busybox:1.28.4-glibc
 ---> 56cc512116c8
Step 2/4 : COPY app /bin/app
 ---> b97b889363e3
Removing intermediate container 197636a53e2a
Step 3/4 : RUN chmod +x /bin/app
 ---> Running in 0a69653107b2
 ---> d1ee3ebf5944
Removing intermediate container 0a69653107b2
Step 4/4 : CMD /bin/app
 ---> Running in 74ff2064d7c8
 ---> a3f04c58f4bd
Removing intermediate container 74ff2064d7c8
Successfully built a3f04c58f4bd
$ docker tag "${CI_REGISTRY_IMAGE}:latest" "${CI_REGISTRY}/library/${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_NAME}"
$ test ! -z "${CI_COMMIT_TAG}" && docker push "${CI_REGISTRY_IMAGE}:latest"
$ docker push "${CI_REGISTRY}/library/${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_NAME}"
The push refers to a repository [harbor.wangxu.com/library/gitlab-ci-k8s-demo]
b3ca74fc4d32: Preparing
e49dd1e534d9: Preparing
e49dd1e534d9: Pushed
b3ca74fc4d32: Pushed
master: digest: sha256:37e5a5d0935f69926e9fa66bc7b7488272c07cdbd7d26666f38e4ef24bd209dc size: 739
Job succeeded

可以看到鏡像傳到harbor上了

配置關聯的k8s集群

然后我們又失敗了

在最后的階段deploy_review可以看到失敗了，這是因為在最后的部署階段我們使用kubectl工具操作集群的時候並沒有關聯上任何集群。

我們在 Gitlab CI 中部署階段使用到的鏡像是cnych/kubectl，該鏡像的Dockerfile文件可以在倉庫https://github.com/cnych/docker-kubectl中獲取：

我們也fork一下 https://github.com/wangxu01/docker-kubectl

cnych/kubectl 我們下載 再上傳一個 到dockerHub wangxu01/kubelet

謝謝作者

#kubelet Dockerfile

FROM alpine:3.8

MAINTAINER cnych <icnych@gmail.com>

ENV KUBE_LATEST_VERSION="v1.13.4"

RUN apk add --update ca-certificates \
 && apk add --update -t deps curl \
 && apk add --update gettext \
 && apk add --update git \
 && curl -L https://storage.googleapis.com/kubernetes-release/release/${KUBE_LATEST_VERSION}/bin/linux/amd64/kubectl -o /usr/local/bin/kubectl \
 && chmod +x /usr/local/bin/kubectl \
 && apk del --purge deps \
 && rm /var/cache/apk/*

 ENTRYPOINT ["kubectl"]
 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 地址就是需要的

# kubectl cluster-info | grep 'Kubernetes master' | awk '/http/ {print $NF}'
https://10.6.76.25:6443

3.CA證書、Token、項目命名空間

對於我們這個項目准備部署在一個名為gitlab的 namespace 下面，所以首先我們需要到目標集群中創建一個 namespace:

kubectl create ns gitlab

由於我們在部署階段需要去創建、刪除一些資源對象，所以我們也需要對象的 RBAC 權限，這里為了簡單，我們直接新建一個 ServiceAccount，綁定上一個cluster-admin的權限：(gitlab-sa.yaml)

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: gitlab
  namespace: gitlab

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: gitlab
  namespace: gitlab
subjects:
  - kind: ServiceAccount
    name: gitlab
    namespace: gitlab
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin

然后創建上面的 ServiceAccount 對象：

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

可以通過上面創建的 ServiceAccount 獲取 CA 證書和 Token：

$ kubectl get serviceaccount gitlab -n gitlab -o json | jq -r '.secrets[0].name'
gitlab-token-f9zp7

然后根據上面的Secret找到CA證書

$ kubectl get secret gitlab-token-f9zp7 -n gitlab -o json | jq -r '.data["ca.crt"]' | base64 -d
xxxxxCA證書內容xxxxx

當然要找到對應的 Token 也很簡單

$ kubectl get secret gitlab-token-f9zp7  -n gitlab -o json | jq -r '.data.token' | base64 -d
xxxxxxtoken值xxxx

[root@k8s-master gitlab]# kubectl get serviceaccount gitlab -n gitlab -o json | jq -r '.secrets[0].name'
gitlab-token-lx7kn
[root@k8s-master gitlab]# kubectl get secret gitlab-token-lx7kn -n gitlab -o json | jq -r '.data["ca.crt"]' | base64 -d
-----BEGIN CERTIFICATE-----
MIICyDCCAbCgAwIBAgIBADANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDEwprdWJl
cm5ldGVzMB4XDTE5MDgyOTAxMjAzMVoXDTI5MDgyNjAxMjAzMVowFTETMBEGA1UE
AxMKa3ViZXJuZXRlczCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOff
fS97EVsrYu0WEJIjCYJ02rhrkGZEqXGF7M1O4jW+xqew+raT1DU+I3U+8KmntGgP
S88IWOeAsvu60d0i9I8W2X3wxwa+a0BrDOx+iUEawTl4X7lllJyN14CkLEc0L2WG
xybbvGfVYZXOuOL/v5xuo9O58VTmEXzXoMD9pk8jb4Qe0NzJKSmWdu5Mj4J0czSo
0tcq3F0kGDvYMbNZhYGbxxoImuPZU6ynp+RBAMMZX5PL2KWhTi5Yw5sf/siq/hN4
fi9O14eoGbIU460PC9yWYTNd6C3UGF2+MCiIg9uuTgZP/Uxhg3rYrnT+vys5D6z6
7QrFrLXh8U91wCUVPf0CAwEAAaMjMCEwDgYDVR0PAQH/BAQDAgKkMA8GA1UdEwEB
/wQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBAMTe4kAdIm0ZoZVqheDUGhjM1EPb
y0+837wtcdsOYjA7KjgioUuP+AvOkQkyXTPI9SDASmg062hMDPKeZ7KLt1mCLfvc
iQLcHpcYKnEoEOOAij1q3KKal454pOg6Bt21632ufO5ELqCfJJKKzbP53u02QDmv
Xlxe2paJqxAZL5wP7zkLzMiHc+YU4W1x0ppx1wlhMJfH2jxLra2T2EsSePvcLjOO
EsjyeDdpF7MqxS2R34Q38fe7/AeyJxyLOhrkRa5RMS8XWd/5CDxAkDB/ooNEUmUq
hqmrvEKPY9Z+BeulnHhpUOUHMNSSfrxjuAt2sbbv0UzK+7hePlBor+61kyc=
-----END CERTIFICATE-----
[root@k8s-master gitlab]# kubectl get secret  gitlab-token-lx7kn -n gitlab -o json | jq -r '.data.token' | base64 -d
eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJnaXRsYWIiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoiZ2l0bGFiLXRva2VuLWx4N2tuIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6ImdpdGxhYiIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjFhYWRjNzljLTQ2MGYtNDMwNy05MmI1LTNkOTgwMmIyOTExZiIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpnaXRsYWI6Z2l0bGFiIn0.04Kfa1xY0_g4xUE_CqMNvtAzJGlO7CICv1iicP7WzMiTEjKa6c031duYBP85-jeRdrHxnEX2VaUrqJIS5eT-GJajBMrUD6D55qa_N5OBrUdTwxe-NJZigYKL3xE1fpZKKoJg5ggGd239BJduUvp10Xo_V0hhwhgsGmHDzMyhtZEzWmty3DjiNFBNedxQwV2fNoOy0Z8UYq-A38hGpQl_zPt_TVdsMSgw2X8KIvgWetsOspfAl6DL0URUmjBSXhKqEl1g4YNGin-cZGyDWeUbjg3LpoXQzediyN5tmI2pwmW-tgRZqnK7vLZQQ1zQ7fmD27l8orMNmMhQmt6zVdLJng

is blocked: Requests to the local network are not allowed

https://blog.csdn.net/weixin_37417954/article/details/83106881

接着就保存成功了

.gitlab-ci.yml

現在 Gitlab CI 的環境都准備好了，我們可以來看下用於描述 Gitlab CI 的.gitlab-ci.yml文件。

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

# 運行golang測試用例
test:
  stage: test
  script:
    - go test ./...

上面這個 Job 會在 test 這個 Stage 階段運行。

為了指定運行的 Stage 階段，可以在.gitlab-ci.yml文件中放置任意一個簡單的列表：

# 所有 Stage
stages:
  - test
  - build
  - release
  - deploy

你可以指定用於在全局或者每個作業上執行命令的鏡像：

# 對於未指定鏡像的作業，會使用下面的鏡像
image: golang:1.10.3-stretch
# 或者對於特定的job使用指定的鏡像
test:
  stage: test
  image: python:3
  script:
    - 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文件如下：

image:
  name: golang:1.10.3-stretch
  entrypoint: ["/bin/sh", "-c"]

# The problem is that to be able to use go get, one needs to put
# the repository in the $GOPATH. So for example if your gitlab domain
# is mydomainperso.com, and that your repository is repos/projectname, and
# the default GOPATH being /go, then you'd need to have your
# repository in /go/src/mydomainperso.com/repos/projectname
# Thus, making a symbolic link corrects this.
before_script:
  - mkdir -p "/go/src/gitlab.wangxu.com/${CI_PROJECT_NAMESPACE}"
  - ln -sf "${CI_PROJECT_DIR}" "/go/src/gitlab.wangxu.com/${CI_PROJECT_PATH}"
  - cd "/go/src/gitlab.wangxu.com/${CI_PROJECT_PATH}/"

stages:
  - test
  - build
  - release
  - review
  - deploy

test:
  stage: test
  script:
    - make test

test2:
  stage: test
  script:
    - sleep 3
    - echo "We did it! Something else runs in parallel!"

compile:
  stage: build
  script:
    # Add here all the dependencies, or use glide/govendor/...
    # to get them automatically.
    - make build
  artifacts:
    paths:
      - app

image_build:
  stage: release
  image: docker:latest
  variables:
    DOCKER_DRIVER: overlay
    DOCKER_HOST: tcp://localhost:2375
  services:
    - name: docker:17.03-dind
      command: ["--insecure-registry=harbor.wangxu.com"]
  script:
    - docker info
    - docker login -u "${CI_REGISTRY_USER}" -p "${CI_REGISTRY_PASSWORD}" "${CI_REGISTRY}"
    - docker build -t "${CI_REGISTRY_IMAGE}:latest" .
    - docker tag "${CI_REGISTRY_IMAGE}:latest" "${CI_REGISTRY}/library/${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_NAME}"
    - test ! -z "${CI_COMMIT_TAG}" && docker push "${CI_REGISTRY_IMAGE}:latest"
    - docker push "${CI_REGISTRY}/library/${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_NAME}"

deploy_review:
  image: cnych/kubectl
  stage: review
  only:
    - branches
  except:
    - tags
  environment:
    name: dev
    url: https://dev-gitlab-k8s-demo.wangxu.com
    on_stop: stop_review
  script:
    - kubectl version
    - cd manifests/
    - sed -i "s/__CI_ENVIRONMENT_SLUG__/${CI_ENVIRONMENT_SLUG}/" deployment.yaml ingress.yaml service.yaml
    - sed -i "s/__VERSION__/${CI_COMMIT_REF_NAME}/" deployment.yaml ingress.yaml service.yaml
    - |
      if kubectl apply -f deployment.yaml | grep -q unchanged; then
          echo "=> Patching deployment to force image update."
          kubectl patch -f deployment.yaml -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"ci-last-updated\":\"$(date +'%s')\"}}}}}"
      else
          echo "=> Deployment apply has changed the object, no need to force image update."
      fi
    - kubectl apply -f service.yaml || true
    - kubectl apply -f ingress.yaml
    - kubectl rollout status -f deployment.yaml
    - kubectl get all,ing -l ref=${CI_ENVIRONMENT_SLUG}

stop_review:
  image: cnych/kubectl
  stage: review
  variables:
    GIT_STRATEGY: none
  when: manual
  only:
    - branches
  except:
    - master
    - tags
  environment:
    name: dev
    action: stop
  script:
    - kubectl version
    - kubectl delete ing -l ref=${CI_ENVIRONMENT_SLUG}
    - kubectl delete all -l ref=${CI_ENVIRONMENT_SLUG}

deploy_live:
  image: cnych/kubectl
  stage: deploy
  environment:
    name: live
    url: https://live-gitlab-k8s-demo.wangxu.com
  only:
    - tags
  when: manual
  script:
    - kubectl version
    - cd manifests/
    - sed -i "s/__CI_ENVIRONMENT_SLUG__/${CI_ENVIRONMENT_SLUG}/" deployment.yaml ingress.yaml service.yaml
    - sed -i "s/__VERSION__/${CI_COMMIT_REF_NAME}/" deployment.yaml ingress.yaml service.yaml
    - kubectl apply -f deployment.yaml
    - kubectl apply -f service.yaml
    - kubectl apply -f ingress.yaml
    - kubectl rollout status -f deployment.yaml
    - 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 集群中是無法拉取我們的私有鏡像的：(替換下面相關信息為自己的)

# kubectl create secret docker-registry myregistry --docker-server=harbor.wangxu.com --docker-username=admin --docker-password=Harbor12345 --docker-email=314144952@qq.com -n gitlab
secret/myregistry created

在下面的 Deployment 的資源清單文件中會使用到創建的myregistry。

創建k8s資源清單文件

接下來為應用創建 Kubernetes 資源清單文件，添加到代碼倉庫中。首先創建 Deployment 資源：（deployment.yaml）

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: gitlab-k8s-demo-__CI_ENVIRONMENT_SLUG__
  namespace: gitlab
  labels:
    app: gitlab-k8s-demo
    ref: __CI_ENVIRONMENT_SLUG__
    track: stable
spec:
  replicas: 2
  selector:
    matchLabels:
      app: gitlab-k8s-demo
      ref: __CI_ENVIRONMENT_SLUG__
  template:
    metadata:
      labels:
        app: gitlab-k8s-demo
        ref: __CI_ENVIRONMENT_SLUG__
        track: stable
    spec:
      imagePullSecrets:
        - name: myregistry
      containers:
      - name: app
 image: harbor.wangxu.com/library/gitlab-ci-k8s-demo:__VERSION__ #注意是harbor地址，原作者github有不一致的地方，注意看日志調整
        imagePullPolicy: Always
        ports:
        - name: http-metrics
          protocol: TCP
          containerPort: 8000
        livenessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 3
          timeoutSeconds: 2
        readinessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 3
          timeoutSeconds: 2

#注意用上面創建的 myregistry 替換 imagePullSecrets。

這是一個基本的 Deployment 資源清單的描述，像__CI_ENVIRONMENT_SLUG__和__VERSION__這樣的占位符用於區分不同的環境，__CI_ENVIRONMENT_SLUG__將由 dev 或 live（環境名稱）和__VERSION__替換為鏡像標簽。

為了能夠連接到部署的 Pod，還需要 Service。對應的 Service 資源清單如下（service.yaml）：

---
apiVersion: v1
kind: Service
metadata:
  name: gitlab-k8s-demo-__CI_ENVIRONMENT_SLUG__
  namespace: gitlab
  labels:
    app: gitlab-k8s-demo
    ref: __CI_ENVIRONMENT_SLUG__
  annotations:
    prometheus.io/scrape: "true"
    prometheus.io/port: "8000"
    prometheus.io/scheme: "http"
    prometheus.io/path: "/metrics"
spec:
  type: ClusterIP
  ports:
    - name: http-metrics
      port: 8000
      protocol: TCP
  selector:
    app: gitlab-k8s-demo
    ref: __CI_ENVIRONMENT_SLUG__

我們的應用程序運行8000端口上，端口名為http-metrics，如果你還記得前面我們監控的課程中應該還記得我們使用prometheus-operator為 Prometheus 創建了自動發現的配置，所以我們在annotations里面配置上上面的這幾個注釋后，Prometheus 就可以自動獲取我們應用的監控指標數據了。

現在 Service 創建成功了，但是外部用戶還不能訪問到我們的應用，當然我們可以把 Service 設置成 NodePort 類型，另外一個常見的方式當然就是使用 Ingress 了，我們可以通過 Ingress 來將應用暴露給外面用戶使用，對應的資源清單文件如下：（ingress.yaml）

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: gitlab-k8s-demo-__CI_ENVIRONMENT_SLUG__
  namespace: gitlab
  labels:
    app: gitlab-k8s-demo
    ref: __CI_ENVIRONMENT_SLUG__
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: __CI_ENVIRONMENT_SLUG__-gitlab-k8s-demo.wangxu.com
    http:
      paths:
      - path: /
        backend:
          serviceName: gitlab-k8s-demo-__CI_ENVIRONMENT_SLUG__
          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.wangxu.com 和 live-gitlab-k8s-demo.wangxu.com 兩個域名的解析。

我們可以使用 DNS 解析服務商的 API 來自動創建域名解析，也可以使用 Kubernetes incubator 孵化的項目 external-dns operator 來進行操作。

觸發gitlab-CI

所需要的資源清單和.gitlab-ci.yml文件已經准備好了，我們可以小小的添加一個文件去觸發下 Gitlab CI 構建：

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

還是失敗了，我的node節點沒有配置harbor的域名

  Warning  Failed     1s (x2 over 16s)   kubelet, k8s-node-2  Failed to pull image "harbor.wangxu.com/library/gitlab-ci-k8s-demo:master": rpc error: code = Unknown desc = Error response from daemon: Get https://harbor.wangxu.com/v2/: x509: certificate signed by unknown authority
  Warning  Failed     1s (x2 over 16s)   kubelet, k8s-node-2  Error: ErrImagePull
[root@k8s-master gitlab-ci-k8s-demo]#

[root@k8s-node-1 ~]# tail /etc/hosts

10.6.76.23 gitlab.wangxu.com harbor.wangxu.com
10.6.76.24 gitlab.wangxu.com harbor.wangxu.com

[root@k8s-node-1 ~]# vim /etc/docker/daemon.json
[root@k8s-node-1 ~]# systemctl restart docker
[root@k8s-node-1 ~]# cat /etc/docker/daemon.json
{
    "registry-mirrors": ["http://hub-mirror.c.163.com"],
     "insecure-registries": ["harbor.wangxu.com"]
}
[root@k8s-node-1 ~]#

真是被自己坑死了，再重新構建

整個 Pipeline 構建成功后，我們可以在項目的環境菜單下面看到多了一個環境：

#解析 ingress域名
10.6.76.23  dev-gitlab-k8s-demo.wangxu.com
10.6.76.24  dev-gitlab-k8s-demo.wangxu.com

瑕疵和沒有解決的

終止操作無效啊。

按照設定

  - kubectl delete ing -l ref=${CI_ENVIRONMENT_SLUG}
  - kubectl delete all -l ref=${CI_ENVIRONMENT_SLUG}

但是無效，調試幾次還是不行，不過也不影響實現了 gitlac-CI部署。有緣看到的，看是否遇到

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 [k8s]jenkins配合kubernetes插件實現k8s集群構建的持續集成 gitlab-runner部署三萬字無坑搭建基於Docker+K8S+GitLab/SVN+Jenkins+Harbor持續集成交付環境 kubernetes(34)：持續集成(3)-JenkinsPipeline部署一個k8s應用微服務項目部署實踐：使用Gitlab Runner實現微服務項目的持續集成，持續交付和持續部署【K8S】基於Docker+K8S+GitLab/SVN+Jenkins+Harbor搭建持續集成交付環境（環境搭建篇）持續集成之應用k8s自動部署 K8S 上部署 jenkins[go的持續集成] 使用Gitlab實現自動化部署與持續集成持續集成Gitlab CICD Runner&Jenkins