docker安裝gitlab_gitlab-ci&gitlab-runner完整自動化部署過程

前言

Gitlab-ci 可以簡化的項目部署操作，講究自動化部署。隻需要動動手指，在你的終端敲下

git commit -m 'update'
           

即可更新倉庫代碼并且直接釋出到線上去。

1、本機環境

1. Centos 7
2. Docker version 19.03.5
3. Gitlab-ce --version lastest 最新
4. Nginx 版本不重要
5. Gitlab-runner version 12.8

除此之外：還需要在部署的服務上，處理好 免密碼登陸。自動化部署，自然不需要手動操。做好免密登陸，就可以将打包的dist檔案夾 scp 到伺服器上的nginx 指定路徑，就可以直接通路了。

2、安裝說明

2.1 nginx 配置

nginx 安裝過程也略過。vim nginx.conf,進行修改。

Nginx 配置路徑,轉發；然後 部署腳本 要将 打包好的dist 檔案夾，複制到部署的伺服器上

/opt/project/web/

此檔案夾下。

nginx -s reload

2.2 部署的伺服器要做ssh 免密碼登陸

1. 登陸 要将項目釋出的伺服器上。
2. 跟目錄下處理

shell s sh-keygen -t rsa # 輸入後一直回車 預設操作即可，不加密，不改變生成檔案的位置

1. 拷貝公鑰到認證檔案-指令：cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

1. Ssh localhost 看看有沒有成功
2. ssh-copy-id [email protected]部署的伺服器ip

此處我是部署環境，和 gitlab-runner 環境在同一個伺服器上。一般情況下是兩台，在開發環境下有即可配置可以。

scp 的時候 我寫的是 122端口，這是我的端口，如果沒有改過，預設是22

shell ssh-copy-id [email protected]

2.3 在自己的gitlab倉庫上建立一個倉庫，例如本機測試的。

倉庫：

線下環境：

2.3 環境安裝

本文重點在于 gitlab-runnner的內建自動化部署

，是以docker的安裝，gitlab的安裝，nginx 的安裝過程跳過。

當你看到此文的時候，這些環境相信你也應該有了。主要是 gitlab-runner的配置問題。

2.21 基于Docker安裝 gitlab-runner

1、安裝

目前我安裝的時候是最新版本：

版本選擇，移步--->

docker pull gitlab/gitlab-runner
           

啟動指令： 我這是一個腳本

path=/usr/local/software/docker/gitlab-runner
docker stop gitlab-runner && docker rm gitlab-runner
docker run -d --name gitlab-runner 
 --restart always 
 -v /usr/local/software/docker/gitlab-runner/config/gitlab-runner:/etc/gitlab-runner 
 430012f3776d
           

• -v:将配置檔案挂載到主控端上
• 430012f3776d: 鏡像ID

啟動成功後，如果

/usr/local/software/docker/gitlab-runner/config/gitlab-runner

下沒有 配置檔案

config.toml

檔案的話。

先停掉

docker stop gitlab-runner && docker rm gitlab-runner

直接執行：

docker run -d gitlab-runner 430012f3776d

然後将容器中的資料複制出來：

docker cp gitlab-runner /etc/gitlab-runner :/usr/local/software/docker/gitlab-runner/config

再次 執行啟動腳本。

或者等會，到注冊的那一步也會生成的。

2、先到倉庫拿到Token

3、注冊

進入容器：

docker exec -it gitlab-runner bash
           

輸入

gitlab-runner register
           

• Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/): 輸入你的gi tlab通路位址，上一步有說到
• Please enter the gitlab-ci token for this runner: 通路token,如何擷取上一步有說到
• Please enter the gitlab-ci description for this runner: 輸入描述，自定義
• Please enter the gitlab-ci tags for this runner (comma separated): tags,在後面寫腳本的時候需要用到，請先寫上，我此處分兩個，是在寫腳本的時候，也分來個 job 來執行，是以也對應兩個。非必要的，gitlab倉庫上可以設定，是不是要填寫，tags标簽上運作。是可以限制
• Please enter the executor: docker+machine, custom, docker, virtualbox, ssh, docker-ssh+machine, kubernetes, docker-ssh, parallels, shell:

這裡比較重要，做java開發的，主要還是使用 ssh、shell、Docker多，至于其它那些個暫不提。

此處建構的是，vue項目，vue項目所需的是 node 環境。因為這個 gitlab-runner是基于Docker安裝的，是一個獨立的容器，你的伺服器上的 node , git 都是無法使用的，如果此時，選擇的是 shell 或者 ssh,的話，後邊寫執行腳本的時候

npm run build

就會報 npm not found,因為我的gitlab-runner是Docker裝的，是以沒有內建，其它環境。是以此時我們選擇一個執行環境 為 Docker ,可以很好的管理依賴，也可以自己做一個鏡像，将所需依賴放一起。

中文官網說明

• Please enter the default Docker image (e.g. ruby:2.6): 選擇了Docker 執行，那就需要寫上 需要的docker 鏡像，此處需要node環境，就直接填寫：node 即可，也可以加上版本好。此處也可以通過，自己寫一個Dockerfile，制作一個容器。将環境依賴都寫上Dockerfile裡。

4、此時是已經注冊成功了，回到gitlab倉庫看看

已經成功了。這裡點選進去可以修改一些屬性操作

5、編寫腳本

編寫腳本要在項目的根目錄下編寫；

# 如果是第一次看這個檔案，看不明白先不要緊，先看明白它的關系先
# yml格式編寫
## stages：通俗講：就是将項目，從打包部署，分幾個步驟，比如我這裡就分兩個步驟，一個 build,打包編譯， deploy：部署
## 如果有更多步驟就寫上，比如 先 clean build test deploy ；如Java的項目： 先 mvn clean , mvn test ,mvn package
# image: node # 就是所依賴的環境 在 gitrunner-cli注冊的時候，已經寫了此處可以省略不寫
stages:
    - build    
    - deploy

before_script:
  - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
  - eval $(ssh-agent -s)
  - ssh-add <(echo "$SSH_KEY")
  - mkdir -p ~/.ssh
  - '[[ -f /.dockerenv ]] && echo -e "Host *ntStrictHostKeyChecking nonn" > ~/.ssh/config'

   # 第一步打包， 
   build: # build:這個名稱自定義
     stage: buil  # 這一個stage：的值就是上面的 stages下的第一個 build
     tags: # tag 在注冊的時候，有提到過，分兩步驟，第一個是 buil,是以這裡也對應上，注冊的時候是自定義的名稱
      - buil
     script: # 這個就是 操作指令 或者寫腳本路徑
      - npm install -g cnpm --registry=https://registry.npm.taobao.org # 切換cnpm 提升速度
      - echo `pwd` # 我隻是輸出下觀察寫路徑
      - cnpm install  # 安裝 nodemodus
      - cnpm run build  # 打包生成 dist 檔案夾

 # 緩存，因為是容器執行，每次執行的時候都會重新打包，緩存起來就不需要安裝一次  
cache:
  paths:
   - node_modules/
   - dist/

   # 第二個任務 就是 專業詞語 job ,第一個是先 build ,這個跟上面的build一樣名稱自定義
   deploy:
     stage: deploy  # 這一個stage：的值就是上面的 stages下的第一個 deploy
     tags:
       - deploy # tag 在注冊的時候，有提到過，分兩步驟，第二個個是 deploy,是以這裡也對應上，注冊的時候是自定義的名稱
     script:
      - pwd #  也輸出下路徑
      - mv dist vue-ci # 修改檔案夾名字，對應上nginx 配置的 路徑名字，不然nginx 無法正确轉發 
      - scp -R 122 -r /dist/ [email protected]:/opt/project  # 将打包好的檔案上到釋出項目的伺服器中的。放到nginx能通路到的檔案夾下
      #  我寫的是 122端口，這是我的端口，如果沒有改過，預設是22  ,scp 不需要 寫 `—R 122`
           

腳本寫好了，就将此檔案更新到gitlab的倉庫上去吧，git push之後，就會執行此腳本檔案了，然後進入浏覽器檢視過程有沒有問題。

⚠️yaml文法檢測：http://你的gitlab通路位址/賬戶/vue-ci/-/ci/lint

本文正确的文法

stages:
 - build    
 - deploy

before_script:
  - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
  - eval $(ssh-agent -s)
  - ssh-add <(echo "$SSH_KEY")
  - mkdir -p ~/.ssh
  - '[[ -f /.dockerenv ]] && echo -e "Host *ntStrictHostKeyChecking nonn" > ~/.ssh/config'
build:
 stage: build 
 tags: 
  - buil
 script:
  - npm install -g cnpm --registry=https://registry.npm.taobao.org 
  - echo `pwd`
  - cnpm install 
  - cnpm run build
cache:
  paths:
   - node_modules/
   - dist/
deploy:
 stage: deploy  
 tags:
   - deploy 
 script:
  - pwd
  - ls -l
  - mv dist vue-ci 
  - scp -P 122 -r vue-ci [email protected]:/opt/project/web
           

• before_script: 就是在執行腳本或者指令前，先執行的操縱。比如需要預先處理，環境問題，此處是要咋dock er内配置好與伺服器的免密登陸。
• -ssh-add <(echo "$SSH_KEY")： $SSH_KEY，這是一個變量，需要到gitlab-ci 頁面裡面設定。

  cat /root/.ssh/id_rsa

  檢視密鑰，記下來,填到下面去。

檢視結果：

進入第一個job build:

這圖檔已經不是第一次build了，前面有好幾次測試，因為腳本的錯 tags:buil 寫錯了 buid, 注冊的時候，想寫的是 build 卻寫成了 buil 。 在途中，是第已經有了nodemoduls的緩存了。

第一次build:

第二次build,糾正腳本後。

build成功了。

第一個job,成功，現在看看第二個，deploy job

第一個job比編譯打包完成

看看伺服器上看看

看已經有了：

打封包件已經成功上傳

先浏覽器看看成功了沒有：

傳回上一頁看，步驟結果：

pass:兩個job已成功執行

此時，項目的自動化部署一套流程跑完了，從依賴的安裝到編譯打包，釋出，就跑完了。把腳本寫好後，下次送出代碼或者更新的時候，就不需要每次手動打包上傳了；

這樣子看似有什麼問題呢？

如果在多人合作的情況下，我每個人都送出代碼到倉庫，更新一點點，都要打包部署嗎？

當然不需要，隻需要在配置檔案中，指定好，哪個分支，更新代碼時候，再進行打包部署就好了。一般是指定master分支，更新的時候。

流程跑通了，此次配置檔案配了兩個，job 任務，配置檔案中有詳情注釋 stages:标簽下的就是 job。第一個是 編譯打包，第二個就是 釋出上傳進行部署。

現在已經部署成功；

先跑流程跑通再來看；配置檔案參數詳解：

script 必須 定義由Runner執行的shell腳本或指令

extends 非必須 定義此作業将繼承的配置條目

image 非必須 需要使用的docker鏡像，請查閱該文檔

services 非必須 定義所需的docker服務，請查閱該文檔

stage 非必須 定義一個工作場景階段，預設是test

type 非必須 stage的别名,不贊成使用

variables 非必須 在job級别上定義的變量

only 非必須

**就是上面所說的，任務 jobs下的配置，only: - master 這個配置的是在倉庫的哪個分支上執行的。**

except 非必須 定義job所不适用的git分支

tags 非必須 定義job所适用的runner，tags為runner标簽

allow_failure 非必須 允許任務失敗，但是如果失敗，将不會改變送出狀态

when 非必須 定義了job什麼時候執行，可以是on_success、on_failure、always和manual

dependencies 非必須 定義了該job依賴哪一個job，如果設定該項，可以通過artifacts設定

artifacts 非必須 工件，在依賴項之間傳遞的東西，類似cache，但原理與cache不同

cache 非必須 定義需要被緩存的檔案、檔案夾清單

before_script 非必須 覆寫在作業之前執行的腳本或指令

after_script 非必須 覆寫在作業之後執行的腳本或指令

environment 非必須 定義讓job完成部署的環境名稱

coverage 非必須 定義job設定代碼覆寫率

retry 非必須 定義job失敗後的自動重試次數

不同的項目需要不同的配置

Gitlab-ci

更多的功能，等你來深究～

中文官網說明​s0docs0gitlab0com.icopy.site

掃碼關注公衆号