一种DevOpts的实现方式:基于gitlab的CICD(二)

写在之前

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

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

环境依赖: gitlab+gitlab runner(docker版本) 环境达吉安完毕
本地已经有nodejs和npm的基础环境(建议安装最新的nodejs版本)

步骤一:在UI界面上创建一个基础的项目
一种DevOpts的实现方式:基于gitlab的CICD(二)_第1张图片

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

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

步骤三:利用npm生成前端项目
在本地的项目目录下执行以下命令,命令会需要显示填写的具体配置信息,我们全部选择默认选项即可。

npm init docusaurus

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

一种DevOpts的实现方式:基于gitlab的CICD(二)_第2张图片
步骤四:修改配置文件
修改文件docusaurus.config.js,将url配置成自己的gitlab地址,将baseUrl配置成项目路径。

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

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

步骤六:创建CICD配置文件

cicd文件的语法

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:是将上一步骤生成的文件切换了路径
npm install
npm run build

一种DevOpts的实现方式:基于gitlab的CICD(二)_第3张图片
我们观察一下runner所在的机器上发生了什么变化,我们来回顾一下如何使用docker容器的方式安装gitlab-runner,这里将docker.sock挂载进入了runner所在的容器。

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的指令

一种DevOpts的实现方式:基于gitlab的CICD(二)_第4张图片
容器内已经clone了git仓库的文件
在这里插入图片描述
注意:这里有npm install卡住报错的解决方案
npm WARN tarball tarball data for xxxx@^0.25… npm项目依赖安装卡住
当两个阶段执行完毕后,可以下载打包完毕完成的静态web界面
一种DevOpts的实现方式:基于gitlab的CICD(二)_第5张图片

写在之后

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

你可能感兴趣的:(gitlab)