圖文詳解k8s自動化持續集成之GitLab CI/CD

 

前言

持續集成的好處主要有兩個:

• 快速發現錯誤

　　每完成一點更新，就集成到主干，可以快速發現錯誤，定位錯誤也比較容易

• 防止分支大幅偏離主干

　　如果不是經常集成，主干又在不斷更新，會導致以后集成的難度變大，甚至難以集成。持續集成的目的，就是讓產品可以快速迭代，同時還能保持高質量。它的核心措施是，代碼集成到主干之前，必須通過自動化測試。只要有一個測試用例失敗，就不能集成。

 

一、環境准備

首先需要有一台 GitLab 服務器，然后需要有個項目；這里示例項目以 golang 項目為例，然后最好有一台專門用來 Build 的機器，實際生產中如果 Build 任務不頻繁可適當用一些業務機器進行 Build；本文示例所有組件將采用 Docker 啟動， GitLab HA 等不在本文闡述范圍內

• Docker Version : 1.13.1
• GitLab Version : 10.1.4-ce.0
• GitLab Runner Version : 10.1.0

二、GitLab CI 簡介

GitLab CI 是 GitLab 默認集成的 CI 功能，GitLab CI 通過在項目內 .gitlab-ci.yaml 配置文件讀取 CI 任務並進行相應處理；GitLab CI 通過其稱為 GitLab Runner 的 Agent 端進行 build 操作；Runner 本身可以使用多種方式安裝，比如使用 Docker 鏡像啟動等；Runner 在進行 build 操作時也可以選擇多種 build 環境提供者；比如直接在 Runner 所在宿主機 build、通過新創建虛擬機(vmware、virtualbox)進行 build等；同時 Runner 支持 Docker 作為 build 提供者，即每次 build 新啟動容器進行 build；GitLab CI 其大致架構如下

Runner可以分布在不同的主機上，同一個主機上也可以有多個Runner。

 

 

三、搭建 GitLab 服務器

3.1、GitLab 搭建

已經有gitlab的同學，可以跳過。GitLab 搭建這里直接使用 docker compose 啟動，compose 配置如下

version: '2'
services:
  gitlab:
    image: 'gitlab/gitlab-ce:10.1.4-ce.0'
    restart: always
    container_name: gitlab
    hostname: 'gitlab.test'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'http:/gitlab.test'
        # Add any other gitlab.rb configuration here, each on its own line
    ports:
      - '80:80'
      - '443:443'
      - '8022:22'
    volumes:
      - './data/gitlab/config:/etc/gitlab'
      - './data/gitlab/logs:/var/log/gitlab'
      - './data/gitlab/data:/var/opt/gitlab'

 

直接啟動后，首次登陸需要設置初始密碼如下，默認用戶為 root

登陸成功后創建一個用戶(該用戶最好給予 Admin 權限，以后操作以該用戶為例)，並且創建一個測試 Group 和 Project.

3.2、增加示例項目

這里示例項目采用 Golang 的 Fingerprint 項目，並采用 go module 構建，其他語言原理一樣；如果不熟悉 golang 的沒必要死磕此步配置，任意語言整一個能用的項目就行，並不強求特定語言、框架構建，以下只是一個樣例項目，如下所示：

 

最后將項目提交到 GitLab 后如下

 

四、GitLab CI 配置

針對這一章節創建基礎鏡像以及項目鏡像，這里僅以 Go 項目為例；其他語言原理相通，按照其他語言對應的運行環境修改即可

4.1、增加 Runner

GitLab CI 在進行構建時會將任務下發給 Runner，讓 Runner 去執行；所以先要添加一個 Runner，Runner 這里采用 Docker in docker 啟動，build 方式也使用 Docker 方式 Build；命令如下：

#!/usr/bin/env bash

#清空掛載目錄
rm -rf /srv/gitlab-runner/config/

#啟動gitlab-runner
docker run -d --name gitlab-runner --restart always \
   -v /srv/gitlab-runner/config:/etc/gitlab-runner \
   -v /var/run/docker.sock:/var/run/docker.sock \
   gitlab/gitlab-runner:latest


# 向gitlab server注冊
docker run --rm -t -i -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register \
  --non-interactive \
  --executor "docker" \
  --docker-image alpine:stable \
  --url "https://git.xxx.com.cn/" \ #請修改成實際地址
  --registration-token "xxx" \ #請修改成實際token， 從gitlab設置里copy
  --description "cms-runner" \
  --tag-list "docker,cms,runner" \ #指定標簽，類似k8s的label,后續selector會用得到
  --run-untagged="true" \
  --locked="false" \
  --docker-privileged #開啟特權模式

在執行上一條激活命令后，會按照提示讓你輸入一些信息；首先輸入 GitLab 地址，然后是 Runner Token，Runner Token 可以從 GitLab 設置中查看，如下所示

注冊完成后，在 GitLab Runner 設置中就可以看到剛剛注冊的 Runner，如下所示

 

 

注意，這里聲明的 Volumes 會在每個運行的容器中都生效；也就是說 build 時新開啟的每個容器都會被掛載這些目錄；修改完成后重啟 runner 容器即可。

4.2、創建項目鏡像

針對於項目每次 build 都應該生成一個包含發布物的 docker 鏡像，所以對於項目來說還需要一個項目本身的 Dockerfile；項目的 Dockerfile 有兩種使用方式；一種是動態生成 Dockerfile，然后每次使用新生成的 Dockerfile 去 build；還有一種是寫一個通用的 Dockerfile，build 時利用 ARG、onbuild、CMD 參數傳入變量；這里采用第二種方式，以下為一個可以反復使用的 Dockerfile：

FROM registry.api.weibo.com/cms-auto/debian:stable

LABEL maintainer="sunsky303<[e-mail]>"

ARG TZ="Asia/Shanghai"

ENV TZ ${TZ}

VOLUME /data1/ms/log
#RUN yum -y update && yum clean all
ADD docker/debian_apt_source.list /etc/apt/sources.list
#RUN ["apt-get", "update"]
#RUN ["apt-get", "install", "-y", "vim"] #for debug
ENV WORKSPACE /data1/ms/FingerprintGo
#RUN ["mkdir","-p", "/data1/ms/FingerprintGo"]
WORKDIR /$WORKSPACE

#RUN rm  -rf $WORKSPACE/*   #clean
COPY ./fingerprint $WORKSPACE/fingerprint
COPY ./dict $WORKSPACE/dict
COPY ./config $WORKSPACE/config
RUN mkdir -p $WORKSPACE/_vgo
COPY example.env $WORKSPACE/.env
ENV GOPATH /data1/ms/FingerprintGo/_vgo #使用go module，它已經事先被push到git了
#RUN rm -rf $WORKSPACE/_vgo/* $WORKSPACE/benchmark
#RUN printf "mode=prod\nlog_dir=$WORKSPACE/" > .env
RUN sed -i  's/mode=test/mode=prod/' .env
EXPOSE 3334

CMD ["./fingerprint"]

 

4.3、創建 CI 配置文件

一切准備就緒以后，就可以編寫 CI 文件了；GitLab 依靠讀取項目根目錄下的 .gitlab-ci.yml 文件來執行相應的 CI 操作：

#image: registry.api.weibo.com/article/golang.image:1.11
image: golang:1.12

#only:
#  - master

variables:
  IMAGE_TAG_NAME: "registry.api.weibo.com/cms-auto/fingerprint:${CI_COMMIT_SHORT_SHA}"

cache:
  untracked: true #cache all files that are untracked in your Git
  key: $CI_COMMIT_REF_NAME #-$CI_COMMIT_REF_NAME #-$CI_COMMIT_SHA
  paths:
    - .goBinTmp


after_script:
  - echo "after_script"

before_script:
  - echo "before_script"
  - hostname && cat /etc/*lease && ip a && env && pwd && ls -al
  - export GOPROXY=https://goproxy.io
  - export GOPATH="$CI_PROJECT_DIR/_vgo"
  - mkdir -p .goBinTmp

# 定義 stages
stages:
  - test
  - build
  - push_image
  - deploy


# 定義 job
job_test:
  stage: test
  script:
    - echo "Testing is starting"
    - printf "mode=test\nlog_dir=/data1/ms/log/fingerprintGo/" > .env
    - go vet ./... #語法錯誤檢查
    - ping -c1  redis  #
#    - go test $(go list ./...)
    - go test -v  ./...  # -benchmem -bench=.
  services: #docker link
    - name: redis
      alias: redis.test
  tags:
    - cms

# 定義 job
job_build:
  stage: build
  script:
    - echo "Building is starting"
    - go build -race
    - cp fingerprint .goBinTmp/
  tags:
    - cms

# 定義 deploy
push_image:
  variables:
     # When using dind service we need to instruct docker, to talk with the
     # daemon started inside of the service. The daemon is available with
     # a network connection instead of the default /var/run/docker.sock socket.
     #
     # The 'docker' hostname is the alias of the service container as described at
     # https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#accessing-the-services
     #
     # Note that if you're using Kubernetes executor, the variable should be set to
     # tcp://localhost:2375 because of how Kubernetes executor connects services
     # to the job container
     DOCKER_HOST: tcp://docker:2375/
     # When using dind, it's wise to use the overlayfs driver for
     # improved performance.
     DOCKER_DRIVER: overlay2
  image: docker:stable
  services:
     - docker:dind
#  before_script:
#     - docker info
#     - echo "${DOCKER_DRIVER} ${DOCKER_HOST}"
  stage: push_image
#  when: manual #只能手動觸發
  script:
    - echo "Deploy to staging server "
#    - docker pull $CI_REGISTRY_IMAGE:latest || true
    - cp .goBinTmp/fingerprint fingerprint
    - docker build -f docker/Dockerfile -t ${IMAGE_TAG_NAME} .  #--cache-from $CI_REGISTRY_IMAGE:latest
    - docker login registry.api.weibo.com --username "${REGISTRY_USER}" --password "${REGISTRY_PWD}"
    - docker push ${IMAGE_TAG_NAME}
    - docker run --name fingerprint-test -d -v /data1/ms/log:/data1/ms/log  ${IMAGE_TAG_NAME}
    - sleep 5
    - docker ps |grep -q 'fingerprint-test'
    - docker stop fingerprint-test && docker rm fingerprint-test
  environment:
      name: deploying
  only:
    - master
  tags:
    - cms

deploy:
  stage: deploy
  when: manual #只能手動觸發
  variables:
    CI_DEBUG_TRACE: "true"  #debug tracing
  script:
    - docker run -it alpine/git clone 'https://${REGISTRY_USER}:${REGISTRY_PWD}@git.staff.sina.com.cn/cms/backend/FingerprintGo.git'
    - cd FingerprintGo
    - docker run -it alpine/git tag -a "${VERSION}" -m "${VERSION}"
    - docker run -it alpine/git push origin --tags
    - echo "kubectl set image deployment/fingerprint fingerprint=${IMAGE_TAG_NAME} -n fingerprint"
  tags:
    - cms
  only:
    - master
  artifacts:
    name: "$CI_JOB_NAME"
    paths:
      - .goBinTmp/* #go test will ignore

4.4 CI 配置的常用概念：

stages
stages 字段定義了整個 CI 一共有哪些階段流程，以上的 CI 配置中，定義了該項目的 CI 總共分為 build、deploy 兩個階段；GitLab CI 會根據其順序執行對應階段下的所有任務；在正常生產環境流程可以定義很多個，比如可以有 test、publish，甚至可能有代碼掃描的 sonar 階段等；這些階段沒有任何限制，完全是自定義的，上面的階段定義好后在 CI 中表現如下圖

 

 

task
task 隸屬於stages 之下；也就是說一個階段可以有多個任務，任務執行順序默認不指定會並發執行；對於上面的 CI 配置來說 auto-build 和 deploy 都是 task，他們通過 stage: xxxx 這個標簽來指定他們隸屬於哪個 stage；當 Runner 使用 Docker 作為 build 提供者時，我們可以在 task 的 image 標簽下聲明該 task 要使用哪個鏡像運行，不指定則默認為 Runner 注冊時的鏡像(這里是 debian)；同時 task 還有一個 tags 的標簽，該標簽指明了這個任務將可以在哪些 Runner 上運行；這個標簽可以從 Runner 頁面看到，實際上就是 Runner 注冊時輸入的哪個 tag；對於某些特殊的項目，比如 IOS 項目，則必須在特定機器上執行，所以此時指定 tags 標簽很有用，當 task 運行后如下圖所示

除此之外 task 還能指定 only 標簽用於限定那些分支才能觸發這個 task，如果分支名字不滿足則不會觸發；默認情況下，這些 task 都是自動執行的，如果感覺某些任務太過危險，則可以通過增加 when: manual 改為手動執行；注意: 手動執行被 GitLab 認為是高權限的寫操作，所以只有項目管理員才能手動運行一個 task，直白的說就是管理員才能點擊；手動執行如下圖所示。

cache
cache 這個參數用於定義全局那些文件將被 cache；在 GitLab CI 中，跨 stage 是不能保存東西的；也就是說在第一步 build 的操作生成的執行文件，到第二部打包 docker image 時就會被刪除；GitLab 會保證每個 stage 中任務在執行時都將工作目錄(Docker 容器 中)還原到跟 GitLab 代碼倉庫中一模一樣，多余文件及變更都會被刪除；正常情況下，第一步 build 生成文件應當立即推送到文件服務器；但是這里測試沒有搭建，所以只能放到本地；但是放到本地下一個 task 就會刪除它，所以利用cache 這個參數將 build 目錄 cache 住，保證其跨 stage 也能存在。

關於 .gitlab-ci.yml 具體配置更完整的請參考：

Gitlab CI yaml官方配置文件翻譯

五、其他相關

5.1、GitLab 內置環境變量

上面已經基本搞定了一個項目的 CI，但是有些變量可能並未說清楚；比如在創建的 PROJECT_ENV 文件中引用了$CI_COMMIT_REF_NAME、${CI_COMMIT_SHA} 等變量；這種變量其實是 GitLab CI 的內置隱藏變量，這些變量在每次 CI 調用 Runner 運行某個任務時都會傳遞到對應的 Runner 的執行環境中；也就是說這些變量在每次的任務容器 SHELL 環境中都會存在，可以直接引用，具體的完整環境變量列表可以從 官方文檔 中獲取；如果想知道環境變量具體的值，實際上可以通過在任務執行前用 env 指令打印出來，如下所示

 

5.2、GitLab 自定義環境變量

在某些情況下，我們希望 CI 能自動的發布或者修改一些東西；比如將生成文件上傳到鏡像庫、將 docker 鏡像 push 到私服；這些動作往往需要一個高權限或者說有可寫入對應倉庫權限的賬戶來支持，但是這些賬戶又不想寫到項目的 CI 配置里；因為這樣很不安全，誰都能看到；此時我們可以將這些敏感變量寫入到 GitLab 自定義環境變量中，GitLab 會像對待內置變量一樣將其傳送到 Runner 端，以供我們使用；GitLab 中自定義的環境變量可以有兩種，一種是項目級別的，只能夠在當前項目使用，如下

 

另一種是組級別的，可以在整個組內的所有項目中使用，如下

 

這兩種變量添加后都可以在 CI 的腳本中直接引用。

5.3、Kubernetes 集成

對於 Kubernetes 集成實際上有兩種方案，一種是對接 Kubernetes 的 api，純代碼實現；另一種取巧的方案是調用 kubectl 工具，用 kubectl 工具來實現滾動升級；這里采用后一種取巧的方式，將 kubectl 二進制文件封裝到鏡像中，然后在 deploy 階段使用這個鏡像直接部署就可以：

我用的是harbor, 鏡像很方便搜索、維護：

 

手動觸發完部署后，

 

最后， kubectl set image在產生環境使用時，需要經過領導審批、驗證確認，所以暫不會直接上線，但這句命令隨時可上線，哈哈。

 

5.4、GitLab CI 總結

關於 GitLab CI 上面已經講了很多，但是並不全面，也不算太細致；因為這東西說起來實際太多了，現在目測已經 1W 多字了；以下總結一下 GitLab CI 的總體思想，當思路清晰了以后，我想后面的只是查查文檔自己試一試就行了

CS 架構
GitLab 作為 Server 端，控制 Runner 端執行一系列的 CI 任務；代碼 clone 等無需關心，GitLab 會自動處理好一切；Runner 每次都會啟動新的容器執行 CI 任務

容器即環境
在 Runner 使用 Docker build 的前提下；所有依賴切換、環境切換應當由切換不同鏡像實現，即 build 那就使用 build 的鏡像，deploy 就用帶有 deploy 功能的鏡像；通過不同鏡像容器實現完整的環境隔離

CI即腳本
不同的 CI 任務實際上就是在使用不同鏡像的容器中執行 SHELL 命令，自動化 CI 就是執行預先寫好的一些小腳本

敏感信息走環境變量
一切重要的敏感信息，如賬戶密碼等，不要寫到 CI 配置中，直接放到 GitLab 的環境變量中；GitLab 會保證將其推送到遠端 Runner 的 SHELL 變量中

 

6. 思考心得

• 什么情況下需要注冊Shared Runner？
  比如，GitLab上面所有的工程都有可能需要在公司的服務器上進行編譯、測試、部署等工作，這個時候注冊一個Shared Runner供所有工程使用就很合適。

• 什么情況下需要注冊Specific Runner？
  比如，我可能需要在我個人的電腦或者服務器上自動構建我參與的某個工程，這個時候注冊一個Specific Runner就很合適。

• 什么情況下需要在同一台機器上注冊多個Runner？
  比如，我是GitLab的普通用戶，沒有管理員權限，我同時參與多個項目，那我就需要為我的所有項目都注冊一個Specific Runner，這個時候就需要在同一台機器上注冊多個Runner。
  
  
• 什么情況適合用dind模式 （docker in docker）
  項目測試、構建需要特殊的依賴，如依賴DB/java/go/libs..，或者同一項目需要並發CI/CD，再或者項目間有端口、文件等上的干擾、沖突，這里適合用dind。
  
  
• 這么好的東西沒有沒缺點？
  創建、調試.gitlab-ci.yml時，可能需要到docker run/log/exec里，或者很有耐心的跑完整個pipeline。小技巧是：開啟tracing， 讓直接retry失敗的環節，可在docker中復現所有問題。