一种DevOpts的实现方式：基于gitlab的CICD（二）

写在之前

前文已经搭建了基于gitlab的cicd环境，现在我们来更近一步，结合官网给出的案例来详细介绍如何一步一步实现CI的过程。

基于gitlab搭建一个前端静态页面

环境依赖： gitlab+gitlab runner（docker版本）环境达吉安完毕

本地已经有nodejs和npm的基础环境（建议安装最新的nodejs版本）

步骤一：在UI界面上创建一个基础的项目

步骤二:在本地clone项目地址

bash 复制代码

git clone http://xxxx:8000/cicddemo/cicd.git

步骤三：利用npm生成前端项目

在本地的项目目录下执行以下命令，命令会需要显示填写的具体配置信息，我们全部选择默认选项即可。

bash 复制代码

npm init docusaurus

步骤三:将上一步生成的静态页面文件放到根目录下

步骤四：修改配置文件

修改文件docusaurus.config.js，将url配置成自己的gitlab地址，将baseUrl配置成项目路径。

步骤五：推送本地文件到远程git仓库

bash 复制代码

git add .
git commit -m "Add simple generated Docusaurus site"
git push origin

步骤六：创建CICD配置文件

cicd文件的语法

bash 复制代码

stages:          # List of stages for jobs and their order of execution
  - build
  - deploy

build-job:
  stage: build   # Set this job to run in the `build` stage
  image: node:21
  script:
    - npm install
    - npm run build
  artifacts:
    paths:
      - "build/"

pages:
  stage: deploy  # Set this new job to run in the `deploy` stage
  script:
    - mv build/ public/
  artifacts:
    paths:
      - "public/"

还记得我们之前是怎么查看cicd的每个阶段的日志记录的吗？我们观察到每一个第一个stage正在运行。趁着docker在构建容器，我们首先读懂这个cicd的yaml的具体语义是什么：

stages：最常见的配置文件将作业分为多个阶段。同一阶段的作业可以并行运行，而后面阶段的作业则等待前面阶段的作业完成。如果作业失败，则认为整个阶段失败，后面阶段的作业不会开始运行。这里共分两个执行阶段：build和deploy
build：build阶段是在node容器内运行了一段脚本。并将生成的文件放到目录build/下
deploy：是将上一步骤生成的文件切换了路径

bash 复制代码

npm install
npm run build

我们观察一下runner所在的机器上发生了什么变化，我们来回顾一下如何使用docker容器的方式安装gitlab-runner，这里将docker.sock挂载进入了runner所在的容器。

bash 复制代码

docker run -d --name gitlab-runner --restart always \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v gitlab-runner-config:/etc/gitlab-runner \
    gitlab/gitlab-runner:latest

/var/run/docker.sock 是 Docker 的 Unix 套接字文件，用于与 Docker

守护进程进行通信。Docker 守护进程负责管理和运行容器化应用程序。

Unix 套接字文件是一种特殊类型的文件，用于进程间的通信。在 Docker 中，/var/run/docker.sock 文件用于Docker 客户端（如 Docker CLI）与 Docker 守护进程之间的通信。当您在命令行中运行 Docker 命令时，Docker 客户端会与 Docker 守护进程进行通信来执行相应的操作。通常情况下，Docker

客户端通过网络接口与 Docker 守护进程通信，但是当 Docker 客户端连接到 /var/run/docker.sock文件时，通信会通过 Unix 套接字进行。通过 Docker 命令行界面或使用 Docker API，您可以使用 /var/run/docker.sock 文件与 Docker守护进程进行交互，例如创建、启动、停止和删除容器，构建和推送镜像，查看日志等等。这种本地通信的方式对于管理和监控 Docker容器非常有用。

gitlab-runner应在是在这一步通过与docker的守护进程通信，从而调用容器创建接口，使得每一个阶段都可以在不同的容器中执行。

我们进到容器内，发现这个额外的容器内运行的是scripts的指令

容器内已经clone了git仓库的文件

注意：这里有npm install卡住报错的解决方案
npm WARN tarball tarball data for xxxx@^0.25... npm项目依赖安装卡住

当两个阶段执行完毕后，可以下载打包完毕完成的静态web界面

写在之后

本文仅介绍了gitlab的CI过程，至于如何基于上述生成的静态页面在不同节点上部署，答主给出一种最简单的实现步骤：利用ssh登录到一个发布节点，将上文中的public共享静态页面拷贝过去。由于答主不是前端出身，所以不太清楚这个静态页面如何暴露给用户查看，所以暂时没有实现cd的步骤，留一个坑在这里，后续有空补充上吧。