簡介

原理

GitLab-CI 這個是一套配合GitLab使用的持續整合系統，是GitLab自帶的，也就是你裝GitLab的那臺伺服器上就帶有的。無需多考慮。.gitlab-ci.yml的指令碼解析就由它來負責。

GitLab-Runner 這個是指令碼執行的承載者，.gitlab-ci.yml的script部分的執行就是由runner來負責的。GitLab-CI瀏覽過專案裡的.gitlab-ci.yml檔案之後，根據裡面的規則，分配到各個Runner來執行相應的指令碼script。這些指令碼有的是測試專案用的，有的是部署用的。

GitLab-CI與GitLab-Runner關係示意圖

步驟

安裝GitLab-Runner 在centOS上安裝gitlab-ci-multi-runner

這樣就裝好了gitlab-ci-multi-runner，然而我們只是裝好了gitlab-runner，當然我們要接著向gitlab-CI註冊這個runner，不然gitlab-CI在push事件到來的時候怎麼知道要呼叫誰呢？這裡也可以發現和webhook方式的區別，webhook方式是我們主動配置了一個連線給gitlab；gitlab-runner只要註冊一下就好了。

那麼我們就註冊一下

然後就註冊好了，在gitlab中相應的位置就可以看到你註冊好的runner資訊。

• $ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash

• $ yum install gitlab-ci-multi-runner

• $ gitlab-ci-multi-runner register

• #引導會讓你輸入gitlab的url，輸入自己的url，例如http://gitlab.example.com/

• #引導會讓你輸入token，去相應的專案下找到token，例如ase12c235qazd32

• #引導會讓你輸入tag，一個專案可能有多個runner，是根據tag來區別runner的，輸入若干個就好了，比如web,hook,deploy

• #引導會讓你輸入executor，這個是要用什麼方式來執行指令碼，圖方便輸入shell就好了。

編寫.gitlab-ci.yml
在專案根目錄下編寫.gitlab-ci.yml這樣在push之後，gitlab-ci就會自動識別來解析了

stages:
  - deploy
  - build
  - ops
 
deploy-web1_job:
  stage: deploy
  tags:
    - gitRunner的tag標籤
  only:
    - master
  script:
    - bash deploy 專案分組名 專案名 master
 
build-web1_job:
  stage: build
  tags:
    - gitRunner的tag標籤
  only:
    - master
  script:
    - source /etc/profile
    - cd /data/wwwroot/master/專案分組名/專案名
    - /data/wwwroot/apache-maven-3.6.0/bin/mvn clean package -Dmaven.test.skip=true
 
ops-web1_job:
  stage: ops
  tags:
    - gitRunner的tag標籤
  only:
    - master
  script:
    - rm -f /data/wwwroot/tomcat/apache-tomcat-8.5.35/webapps/專案名.war
    - cp /data/wwwroot/master/專案分組名/專案名/target/專案名.war /data/wwwroot/tomcat/apache-tomcat-8.5.35/webapps/專案名.war

這裡我們只有一個stage是deploy。only指定了只有在master分支push的時候才會被執行。tags是shell，對應了剛才註冊runner的時候的tags。

最重要的script部分deploy Example_Group Example_Project，這裡是一條shell指令，為了方便通用性，deploy是我在伺服器上編寫的一個指令碼，傳入引數是Example_Group Example_Project分別是專案組名和專案名。執行這一條指令就能夠自動部署到/xxx/Example_Group/Example_Project的伺服器目錄下。那麼隨便什麼專案都用這個格式去套就好了，這樣新專案的自動部署也不需要登入到伺服器上去修改了。

編寫deploy指令碼
在gitlab-runner的~/.local/bin/目錄下新建deploy檔案

$ su gitlab-runner

$ mkdir ~/.local/bin

$ cd ~/.local/bin

$ touch deploy
 

並編輯成如下內容

if [ $# -ne 3 ]
then
      echo "arguments error!"
      exit 1
else
      deploy_path="/data/wwwroot/$3/$1/$2"
      if [ ! -d "$deploy_path" ]
      then
              git clone "gitlab伺服器地址:${1}/${2}.git" $deploy_path
          cd $deploy_path
              git checkout $3
      else
              cd $deploy_path
              git pull
      fi
fi

• 這個指令碼的大意就是，如果目錄不存在，那麼就git clone一個，如果存在了就git pull一個到指定目錄下。這樣就達到了自動部署的目的。記得修改裡面的gitlab.example.com的地址哦。

加上執行許可權，然後把這個指令碼放在gitlab-runner的~/.local/bin下就可以生效了（為了不用寫難看的./deploy）

$ chmod +x ~/.local/bin/deploy

並且把~/.local/bin加到$PATH路徑中（使用者執行命令時候能夠查詢到這個目錄），只要在~/.profile末尾加入這一句話

PATH="$HOME/.local/bin:$PATH"

配置ssh登入
上面的deploy指令碼是用ssh方式來和gitlab聯絡的。所以要給gitlab-runner這個使用者配置一個gitlab上能ssh的使用者。首先在gitlab-runner下生成一個金鑰對

$ mkdir ~/.ssh

$ cd ~/.ssh

$ ssh-keygen

# 提示輸入一直按回車預設就可以了

$ cat id_rsa.pub

移交部署目錄許可權
有些同學可能說指令碼執行失敗了，有一個原因是/var/example的所有者是root，gitlab-runner並沒有許可權新建檔案。所以我們把/var/example目錄的所有者交給gitlab-runner

$ chown -hR gitlab-runner:gitlab-runner /var/www

如果還是不成功，可以在伺服器上手工deploy XX XX一次，第一次訪問這個伺服器的時候，有個命令列提示是要把sign新增進已知伺服器列表，需要手工輸入個yes。如果在伺服器上能夠正常deploy，那麼
這樣就大功告成了。

注:如果在釋出執行的過程中一直報ssh的金鑰驗證不通過 則執行這個：   ssh-keyscan -H 伺服器ip >> ~/.ssh/known_hosts