前端的gitlab的ci初嘗試

時間  2019-11-07
標籤 前端 gitlab 嘗試 欄目 Git 简体版
原文   原文鏈接

本文記錄一個前端部署Gitlab的CI。不是在本身的服務器上面搭建的Gitlab。使用的是Gitlab.com的Gitlab的CI，在騰訊雲擼的羊毛的小水管也搭不起Gitlab，作個CI的服務器仍是能勉勉強強的。php

Gitlab和Github

Github 一個網站，提供給用戶空間建立git倉儲，保存用戶的一些數據文檔或者代碼等。html

Gitlab 一個基於git實現的在線代碼倉庫軟件，你能夠用Gitlab本身搭建一個相似於Github同樣的系統，通常用於在企業、學校等內部網絡搭建Git私服。前端

什麼是持續集成

阮一峯的這個文章寫的挺好的持續集成是什麼？vue

持續集成指的是，頻繁地（一天屢次）將代碼集成到主幹。node

持續集成的目的，就是讓產品能夠快速迭代，同時還能保持高質量。它的核心措施是，代碼集成到主幹以前，必須經過自動化測試。只要有一個測試用例失敗，就不能集成。linux

Gitlab的CI

從 GitLab 8.0 開始，GitLab CI 就已經集成在 GitLab 中，咱們只要在項目中添加一個 .gitlab-ci.yml 文件，而後添加一個 Runner，便可進行持續集成。 並且隨着 GitLab 的升級，GitLab CI 變得愈來愈強大。nginx

首先明白Gitlab CI 幾個基本的概念git

GitLab-CI

這個是一套配合GitLab使用的持續集成系統，是GitLab自帶的，也就是你裝GitLab的那臺服務器上就帶有的。無需多考慮。.gitlab-ci.yml的腳本解析就由它來負責。github

GitLab-Runner

這個是腳本執行的承載者，.gitlab-ci.yml的script部分的運行就是由runner來負責的。GitLab-CI瀏覽過項目裏的.gitlab-ci.yml文件以後，根據裏面的規則，分配到各個Runner來運行相應的腳本script。這些腳本有的是測試項目用的，有的是部署用的。vue-cli

.gitlab-ci.yml

這個是在git項目的根目錄下的一個文件，記錄了一系列的階段和執行規則。GitLab-CI在push後會解析它，根據裏面的內容調用runner來運行。

簡單來講就是，你利用Git版本管理Push了本地代碼到Remote上(這裏就是你gitlab.com)，而後Gitlab，就通知你的服務器，也就是Gitlab-runner來運行構建任務。而後跑測試用例，測試用例經過了就生成Build出相應的環境的代碼，自動部署上不一樣的環境服務器上面去。

安裝Gitlab Runner

若是想要使用Docker Runner，則須要安裝Docker。（可選）

curl -sSL https://get.docker.com/ | sh
複製代碼

安裝 GitLab Runner 太簡單了，按照着 官方文檔 的教程來就好拉！ 下面是 Debian/Ubuntu/CentOS 的安裝方法，其餘系統去參考官方文檔：

# For Debian/Ubuntu
$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash
$ sudo apt-get install gitlab-ci-multi-runner
# For CentOS
$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash
$ sudo yum install gitlab-ci-multi-runner
複製代碼

而後註冊Gitlab Runner Runner須要註冊到Gitlab才能夠被項目所使用，一個gitlab-ci-multi-runner服務能夠註冊多個Runner。

在 GNU/Linux 系統上註冊 Runner:

運行下面命令啓動註冊程序:

sudo gitlab-runner register
複製代碼

輸入 GitLab 實例 URL:

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
https://gitlab.com
複製代碼

輸入獲取到的用於註冊 Runner 的 token:

Please enter the gitlab-ci token for this runner
xxx //這個token在你gitlab.com的項目的 setting >> CI/CD >> Runners settings 下
複製代碼

輸入該 Runner 的描述，稍後也可經過 GitLab's UI 修改: 

Please enter the gitlab-ci description for this runner
一個配置很低的服務器
複製代碼

給該 Runner 指派 tags, 稍後也能夠在 GitLab's UI 修改:

Please enter the gitlab-ci tags for this runner (comma separated):
tengxun // 這個就至關於每個runner的惟一id，記住這個tag。
複製代碼

選擇 Runner 是否接收未指定 tags 的任務（默認值：false）， 稍後能夠在 GitLab's UI 修改：

Whether to run untagged jobs [true/false]:
[false]: true
複製代碼

選擇是否爲當前項目鎖定該 Runner， 以後也能夠在 GitLab's UI 修改。 該功能一般用於被指定爲某個項目的 Runner （默認值：true）：

Whether to lock Runner to current project [true/false]:
[true]: true
複製代碼

選擇 Runner executor:

Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
docker  // 我選擇的docker，請記住，選擇docker的以前要把docker啓動，docker的使用就不是本文所講的了
複製代碼

若是你選擇 Docker 做爲你的 executor，註冊程序會讓你設置一個默認的鏡像， 做用於 .gitlab-ci.yml 中未指定鏡像的項目：

Please enter the Docker image (eg. ruby:2.1):
alpine:latest
複製代碼

而後，你刷新你setting下面的配置

有個綠色的小圓點，這就代表你已經註冊Runner成功了。

配置.gitlab-ci.yml

配置好 Runner 以後，咱們要作的事情就是在項目根目錄中添加 .gitlab-ci.yml 文件了。 當咱們添加了 .gitlab-ci.yml 文件後，每次提交代碼或者合併 MR 都會自動運行構建任務了。

在.gitlab-ci.yml有一些須要講解的概念

Pipeline

一次 Pipeline 其實至關於一次構建任務，裏面能夠包含多個流程，如安裝依賴、運行測試、編譯、部署測試服務器、部署生產服務器等流程。咱們的任何提交或者 Merge Request 的合併均可以觸發 Pipeline。以下圖：

+------------------+           +----------------+
|                  |  trigger  |                |
|   Commit / MR    +---------->+    Pipeline    |
|                  |           |                |
+------------------+           +----------------+
複製代碼

Stages

Stages 表示構建階段，說白了就是上面提到的流程。 咱們能夠在一次 Pipeline 中定義多個 Stages，每一個Stage能夠完成不一樣的任務。 Stages有下面的特色：

  • 全部 Stages 會按照順序運行，即當一個 Stage 完成後，下一個 Stage 纔會開始
  • 只有當全部 Stages 完成後，該構建任務 (Pipeline) 纔會成功
  • 若是任何一個 Stage 失敗，那麼後面的 Stages 不會執行，該構建任務 (Pipeline) 失敗

所以，Stages 和 Pipeline 的關係就是：

+--------------------------------------------------------+
|                                                        |
|  Pipeline                                              |
|                                                        |
|  +-----------+     +------------+      +------------+  |
|  |  Stage 1  |---->|   Stage 2  |----->|   Stage 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  |   |
|  +---------+  +---------+  +---------+   |
|                                          |
+------------------------------------------+
複製代碼

這些是部署腳本里面的一些基本結構，接下來講一些.gitlab-ci.yml的基本構成

下面是一個最簡單的Node項目的部署腳本。

image: node:alpine  // 默認的ci部署的docker鏡像

stages:  // 首先按順序定義有幾個步驟。步驟下面的全部job是同步執行的
 - test  
 - build
  
job1:
 stage: test  // 屬於test的stage
 script:
 - npm run test // 這個job執行的腳本
 only:
 - master  // 只監聽master分支的代碼提交
 tags:
 - tengxun  // 要使用哪一個runner

job2:
 stage: build
 script:
 - npm run build
 only:
 - master
 tags:
 - tengxun

複製代碼

注意這裏的job1，job2名字是隨便取的，沒有關係，只要不用Gitlab-CI的關鍵字就能夠。

列出一些經常使用的關鍵字，掌握了這些就能夠開發了。

關鍵字 是否必須 描述
image 否 用於docker鏡像，查看docker文檔
services 否 用於docker服務，查看docker文檔
stages 否 定義構建階段
types 否 stages 的別名(已廢除)
before_script 否 定義在每一個job以前運行的命令
after_script 否 定義在每一個job以後運行的命令
variable 否 定義構建變量
cache 否 定義一組文件列表，可在後續運行中使用

發現這篇文章對每一個關鍵字對解釋的好清楚，算是個拋磚引玉吧。比我寫的都還要清楚。

Gitlab CI yaml官方配置文件翻譯

配置以前，你還要在你gitlab.com的對應項目裏面的setting >> CI/CD >> Secret variables 定義一些構建變量，由於你的Gitlab-CI要去自動的登陸服務器，而後把打包出來的文件自動更新上去。

Runner 登陸你的服務器是不能用傳統輸入帳號密碼的形式，（由於都自動化了，還須要輸入密碼，那還叫什麼自動化）。只能經過走SSH登陸的形式，若是不懂SSH登陸，請自行谷歌。私鑰這些東西確定不能寫在yml文件裏面，由於yml文件是每一個人都能看見的，因此Gitlab-CI就能夠在項目裏面自定義私有的變量名。至少項目開源出去以後，不是每一個人都能看見部署服務器的私鑰的。

這裏的$SSH_PRIVATE_KEY 是你開發機（也就是你的的開發電腦）生成的私鑰。 注意必定要複製

-----BEGIN RSA PRIVATE

-----END RSA PRIVATE KEY-----
複製代碼

這些東西。（這裏是個坑。。。由於不多會讓你複製私鑰的） 下面配置的${CI_COMMIT_REF_NAME}，是Gitlab CI 的默認關鍵字。詳情見文檔

最後貼上我那個騰訊雲小水管的配置，親測有用。

還真是一個很簡單的vue項目。就用vue-cli生成，而後發佈到服務器上面指定的目錄，服務器上面的nginx配置已經配置好了。

stages:
  - test
  - build
  - deploy

cache:
  key: ${CI_COMMIT_REF_NAME}
  paths:
  - node_modules/

test_dev:
  image: node:alpine
  stage: test
  only:
    - dev
  tags:
    - tengxun
  script:
    - npm run test


build:
  image: node:alpine
  stage: build
  only:
    - master
    - dev
  tags:
    - tengxun
  script:
    - npm set registry https://registry.npm.taobao.org # 設置淘寶鏡像地址
    - npm install --progress=false
    - npm run build
  artifacts:  
    expire_in: 1 week
    paths:
      - dist

deploy_dev:
  image: alpine
  stage: deploy
  only:
    - dev
  tags:
    - tengxun
  script:
    - echo "http://mirrors.aliyun.com/alpine/v3.7/main/" > /etc/apk/repositories
    - apk add --no-cache rsync openssh
    - mkdir -p ~/.ssh
    - echo "$SSH_PRIVATE_KEY" >> ~/.ssh/id_dsa
    - chmod 600 ~/.ssh/id_dsa
    - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
    - rsync -rav --delete dist/ "$SERVER_USER_HOST:$SERVER_DEV_PATH"

deploy_master:
  image: alpine
  stage: deploy
  only:
    - master
  tags:
    - tengxun
  script:
    - echo "http://mirrors.aliyun.com/alpine/v3.7/main/" > /etc/apk/repositories
    - apk add --no-cache rsync openssh
    - mkdir -p ~/.ssh
    - echo "$SSH_PRIVATE_KEY" >> ~/.ssh/id_dsa
    - chmod 600 ~/.ssh/id_dsa
    - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
    - rsync -rav --delete dist/ "$SERVER_USER_HOST:$SERVER_MASTER_PATH"
  when: manual
複製代碼

這裏用rsync來同步Build出來的代碼，其實也很簡單的。

rsync 是一個開源工具，能夠進行快速的增量的文件傳輸。相關文章

簡單來講就是讓你源計算機和目標計算機進行文件的同步。

附上rsync的翻譯的文檔 點我

在GitLab-CI中, cache與artifacts比較容易混淆.

其中 cache 指的是緩存, 經常使用於依賴安裝中, 如幾個jobs都須要安裝相同的依賴, 可使用依賴, 此時能夠加快依賴的安裝進度; 對於artifacts則是將某個工件上傳到GitLab提供下載或後續操做使用, 因爲每一個job啓動時, 都會自動刪除.gitignore中指定的文件, 所以對於依賴安裝目錄, 便可以使用cache, 也可使用artifacts.

兩個主要有如下幾個區別:

  • 雖然定義了cache, 可是若是cache和.gitignore中重複的這部分, 仍然須要從新安裝
  • 從新安裝時由於使用的是緩存, 因此頗有可能不是最新的
  • 特別是開發環境, 若是每次都但願使用最新的更新, 應當刪除cache, 使用artifacts, 這樣能夠保證肯定的更新
  • artifacts中定義的部分, 會自動生成, 並能夠傳到下面的job中解壓使用, 避免了重複依賴安裝等工做 若是使用Docker運行Gitlab-Runner, cache會生成一些臨時容器, 不容易清理
  • artifacts能夠設置自動過時時間, 過時自動刪除
  • artifacts會先傳到GitLab服務器, 而後須要時再從新下載, 因此這部分也能夠在GitLab下載和瀏覽

由於咱們這裏要重複使用以前job打包出來在dist下面的文件，因此我會使用artifacts。

when: manual

這裏master通常是值穩定的代碼版本，因此最好手動執行的。when: manual就是須要手動部署，全部job默認都是自動執行的。

魯迅曾經說過：有國內加速鏡像地址的必定要用國內鏡像地址

這裏的鏡像地址配置包括Docker，APK，NPM。必定要設置啊，當時就卡在這裏了好久。

而後咱們push代碼到master，點擊你項目的CI/CD面板。

而後小水管過了2分鐘才跑完Build，扎心了。

點擊右面的那個播放三角形，就能夠部署到個人那個騰訊雲服務器上面去了。（固然，dev分支是默認自動部署和的），這就開始構建了。

好啦，一個簡單的前端CI嘗試就完了。

that's all。

參考資料

gitlab之gitlab-ci自動部署 GitLab 中文文檔 Gitlab CI yaml官方配置文件翻譯 用 GitLab CI 進行持續集成

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程