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

 

前言

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

• 快速發現錯誤

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

• 防止分支大幅偏離主幹

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

 

1、環境準備

首先須要有一臺 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

2、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。

 

 

3、搭建 GitLab 服務器

3.一、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.二、增長示例項目

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

 

最後將項目提交到 GitLab 後以下

 

4、GitLab CI 配置

針對這一章節建立基礎鏡像以及項目鏡像，這裏僅以 Go 項目爲例；其餘語言原理相通，按照其餘語言對應的運行環境修改便可

4.一、增長 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.二、建立項目鏡像

針對於項目每次 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<sunsky303@qq.com>"

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.三、建立 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、其餘相關

5.一、GitLab 內置環境變量

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

 

5.二、GitLab 自定義環境變量

在某些狀況下，咱們但願 CI 能自動的發佈或者修改一些東西；好比將生成文件上傳到鏡像庫、將 docker 鏡像 push 到私服；這些動做每每須要一個高權限或者說有可寫入對應倉庫權限的帳戶來支持，可是這些帳戶又不想寫到項目的 CI 配置裏；由於這樣很不安全，誰都能看到；此時咱們能夠將這些敏感變量寫入到 GitLab 自定義環境變量中，GitLab 會像對待內置變量同樣將其傳送到 Runner 端，以供咱們使用；GitLab 中自定義的環境變量能夠有兩種，一種是項目級別的，只可以在當前項目使用，以下

 

另外一種是組級別的，能夠在整個組內的全部項目中使用，以下

 

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

5.三、Kubernetes 集成

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

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

 

手動觸發完部署後，

 

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

 

5.四、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中復現全部問題。