前端VUE基於gitlab的CI_CD

CI

持續集成指的是,頻繁地(一天多次)將程式碼集成到主幹。

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

1.Gitlab的CI

從 GitLab 8.0 開始,GitLab CI 就已經集成在 GitLab 中,我們只要在項目中添加一個 .gitlab-ci.yml 文件,然後添加一個 Runner,即可進行持續集成。 而且隨著 GitLab 的升級,GitLab CI 變得越來越強大。
首先明白Gitlab CI 幾個基本的概念

1.1 GitLab-Runner

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

1.2 .gitlab-ci.yml

這個是在git項目的根目錄下的一個文件,記錄了一系列的階段和執行規則。GitLab-CI在push後會解析它,根據裡面的內容調用runner來運行。
簡單來說就是,你利用Git版本管理Push了本地程式碼到Remote上(這裡就是你gitlab.com),然後Gitlab,就通知你的伺服器,也就是Gitlab-runner來運行構建任務。然後跑測試用例,測試用例通過了就生成Build出相應的環境的程式碼,自動部署上不同的環境伺服器上面去。

1.3 配置.gitlab-ci.yml

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

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

1.3.1 Pipeline概念

一次 Pipeline 其實相當於一次構建任務,裡面可以包含多個流程,如安裝依賴、運行測試、編譯、部署測試伺服器、部署生產伺服器等流程。我們的任何提交或者 Merge Request 的合併都可以觸發 Pipeline。如下圖:

+------------------+           +----------------+
|                  |  trigger  |                |
|   Commit / MR    +---------->+    Pipeline    |
|                  |           |                |
+------------------+           +----------------+

1.3.2 Stages

Stages 表示構建階段,說白了就是上面提到的流程。
我們可以在一次 Pipeline 中定義多個 Stages,每個Stage可以完成不同的任務。
Stages有下面的特點:

所有 Stages 會按照順序運行,即當一個 Stage 完成後,下一個 Stage 才會開始
只有當所有 Stages 完成後,該構建任務 (Pipeline) 才會成功
如果任何一個 Stage 失敗,那麼後面的 Stages 不會執行,該構建任務 (Pipeline) 失敗

因此,Stages 和 Pipeline 的關係就是:

+--------------------------------------------------------+
|                                                        |
|  Pipeline                                              |
|                                                        |
|  +-----------+     +------------+      +------------+  |
|  |  Stage 1  |---->|   Stage 2  |----->|   Stage 3  |  |
|  +-----------+     +------------+      +------------+  |
|                                                        |
+--------------------------------------------------------+

1.3.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  |   |
|  +---------+  +---------+  +---------+   |
|                                          |
+------------------------------------------+

2.CI/CD VUE應用

2.1 創建dockfile文件

FROM node:lts-alpine as build-stage
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# production stage
FROM nginx:stable-alpine as production-stage
COPY --from=build-stage /app/dist /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

該docker配置摁鍵拉取node鏡像,用來編譯我們的生產環境的應用,第二階段拉取nginx的鏡像用來運行我們第一階段構建的編譯應用。

執行daemon off的原因
加上了daemon off,nginx才能一直在後台持續運行,否則就會被docker進程終止,因為docker默認會終止pid為1的進程。Docker 容器啟動時,默認會把容器內部第一個進程,也就是pid=1的程式,作為docker容器是否正在運行的依據,如果 docker 容器pid=1的進程掛了,那麼docker容器便會直接退出。

Docker未執行自定義的CMD之前,nginx的pid是1,執行到CMD之後,nginx就在後台運行,bash或sh腳本的pid變成了1。

所以一旦執行完自定義CMD,nginx容器也就退出了。

2.2 創建.gitlab-ci.yml文件

image: docker
services:
  - docker:dind
stages:
  - deploy
step-deploy-prod:
  stage: deploy
  script:
    - docker build  -t app/sgms.web  .
        # 這裡是查看當前的伺服器上有沒有正在運行或者存在我們之前運行過的項目容器,如果有刪除了
    - if [ $(docker ps -aq --filter name=sgmsweb) ];then docker rm -f sgmsweb;fi
    - docker run -d -p 81:80 --rm  --name sgmsweb app/sgms.web
  only:
    refs:
      - main
  tags:
    - sgmsweb

2.3 註冊git runner

網上資料很多,自行解決。

2.4 流水線編譯成功

線上也出現了我們想要的登錄頁面

參考文章
How to auto deploy a Vue application using GitLab CI/CD on Ubuntu 18.04
前端的gitlab的ci初嘗試