实战：从 0 到 1 GitLab CI/CD 前端持续部署

「爱情、让人受尽委屈。」 2022-09-05 11:24 790阅读 0赞

### 文章目录 ###

*   *   *  写在前面
         *  服务器配置
         *  环境安装
         *   *  安装 Docker
             *  安装 GitLab
         *  测试 GitLab
         *  GitLab Runner
         *  前端项目 CI/CD 流程的设计
         *  正式开始编写 .gitlab-ci.yml 的内容
         *   *  介绍 .gitlab-ci.yml
             *  镜像的使用
             *  stages 执行顺序的定义
             *  job 内容的编写
             *  在 CI/CD 中使用 SSH keys
             *  前端项目部署到阿里云OSS
         *  前端项目 CI/CD 最佳业务配置思路
         *  常见问题排查及修复
         *   *  相关参考链接

### 写在前面 ###

首先感谢大家能来参加我的 Chat，能来参加的同学都是想在业余有一些其他知识的补充，最好能够对现在工作有帮助的，能帮助自己在下一次的职级评比中获得更多的绩效。

作为一名前端开发人员，除了掌握基本三大主流前端框架，如果业余时间能够再学习一点运维知识，能够自己搭建一套完成的前端自动化部署流程，对个人或者对公司都是一个不小的进步和收获。特别是在小公司，没有固定的运维岗位，很多都是会一些 Linux 命令的后端临时充当，这个时候如果你能把前端的自动化部署，CI/CD 一个人搭建起来，那老板和同事都会高看你一眼，因为你用规范的部署流程高效快速地解决了公司项目部署问题。

本篇文章是以实战为主，注重在搭建完整的自动化持续部署流程，会解释相关的概念，以及扩展一些其他平台，并分享一些业内比较广泛的 Devops 的应用。为了写这篇文章，我把服务器的系统重装了一下，目的就是为了能够大家能够从 0 来认识整个流程所有的步骤，知道了所有的步骤就不会因为缺少什么软件没有安装就流程走不下去。完完全全的实战类，跟着教程一步一步走，自己也能够搭建一套。如果你没有服务器也没关系，可以在本地安装一个虚拟机。相信各位读完文章一定会有所收获的。

最后有任何问题都可以微信私我（demon\_0212）或[查阅我的博客][Link 1]。

### 服务器配置 ###

这里简单介绍一下我的服务器和应用品台，为了由于硬件，平台差异导致的一些错误，对硬件，平台一概不提的软件是没办法用的。

服务器是腾讯的 2 核 4G，CentOS 7.7 64 位，带宽比较小 1M 的，所以在拉镜像的时候还是很慢的。服务器 IP 是 115.159.52.223，已经搭建了 GitLab，大家也可以创建项目去试一下。

这里我重置一下服务器：

![重置服务器][035e13174b869d50e785b8d11f4819fb.png]

### 环境安装 ###

服务器重置完成后，我们需要安装一些软件，来支撑我们的 CI/CD 流程，首先我们需要 Docker，然后使用 Docker 安装 GitLab，至于 Docker 的安装，其实在[我的博客][Link 2]和上一篇的 Chat[前端开发需要掌握的 Docker 知识][Docker] 都有讲解过，关注我的博客的人都比较清楚。

为什么要用 Docker 去安装 GitLab？

首先 Docker 的安装，卸载，更新应用的指令都是统一的，而且卸载后除了本地卷以外不会留下什么缓存，或者影响下一次操作的内容。安装软件就怕一些流氓软件，卸载后始终占有很大内存，如果改变了一些系统配置，还有可能影响到其他软件的安装，用 Docker 就不会，因为他是使用封闭的线程去启动的应用。

#### 安装 Docker ####

安装 Docker 都是安装的 CE 版本，即社区版，是免费的，还有一个是 EE 版，即企业版，强调安全，付费使用。

在 CentOS 上安装 Docker 很简单，其实任何一个 Linux 平台上安装 Docker 都是比较简单的，不会超过 3 条命令。

以下是在所有 Linux 平台安装 Docker 的指令：

curl -fsSL get.docker.com -o get-docker.sh
    
    sudo sh get-docker.sh --mirror Aliyun

首先是在当前目录，使用 curl 从 get.docker.com 获取一个 shell 脚本，执行完第一步可以当前目录多了一个 get.docker.sh 的文件。这个是 Docker 官方提供的一键安装 Docker 的脚本，下载完脚本就要执行这个脚本，由于这个脚本可能会操作一些系统配置，所以要使用 sudo 来提升执行的权限。`--mirror` 是指定安装源脚本，会去自动检查系统的环境，来安装一下相应的包，并且整个过程不需要询问用户。方便时真方便，就是怕不安全。

如果出于安全和稳定考虑，可以去使用[官方提供的常规安装方法][Link 3]。

执行完脚本后，还需要配置开启服务和权限配置。

sudo groupadd docker  # 创建 docker 用户组
    sudo usermod -aG docker $USER  # 将当前用户加入到 docker 的用户组中

启动 Docker：

sudo systemctl enable docker
    sudo systemctl start docker

验证 Docker 环境安装成功：

docker info

执行以上命令会打印出 Docker 的配置信息，如下图：

![Docker info][]

#### 安装 GitLab ####

安装完成 Docker 后，我们就要安装 GitLab 了，Docker 和 Docker 镜像让一切复杂的软件安装都变得不能再简单了，简单到只有一条命令。这是软件开发的一个福音，不用再为各种环境安装而烦恼，去看各种软件安装的说明书。

GitLab 作为一个代码托管，项目管理平台，凭借着免费，稳定，功能丰富吸引了无数大小公司使用。然而就是这个一个大型的软件，使用 Docker 安装只需要一条命令,让我们来看下这条命令。

sudo docker run --detach \
      --hostname 115.159.52.223 \
      --publish 443:443 --publish 80:80 --publish 222:22 \
      --name gitlab \
      --restart always \
      --volume /srv/gitlab/config:/etc/gitlab \
      --volume /srv/gitlab/logs:/var/log/gitlab \
      --volume /srv/gitlab/data:/var/opt/gitlab \
      gitlab/gitlab-ce:latest

使用 root 权限 Docker 运行一个 gitlab/gitlab-ce:latest 镜像。就那么简单，中间的都是一些配置项。让我一个一个解释一下。

*  `--detach`：后台运行，如果去掉，会看到执行的整个过程日志。
 *  `--hostname`：指定运行的 hostname，可以是域名也可以是 IP。
 *  `--publish`：端口的映射，可以缩写成 `-p` 443 用于 HTTPS 协议访问，222 用户 SSH 协议访问，因为 22 端口已经被占用。
 *  `--name`：容器的名称。
 *  `--restart`：重启的方式，会自动重启。

> 有五种策略：
> 
>  *  no：默认策略，在容器退出时不重启容器
>  *  on-failure：在容器非正常退出时（退出状态非 0），才会重启容器
>  *  on-failure:3：在容器非正常退出时重启容器，最多重启 3 次
>  *  always：在容器退出时总是重启容器
>  *  unless-stopped：在容器退出时总是重启容器，但是不考虑在 Docker 守护进程启动时就已经停止了的容器

*  `--volume`：指定本地卷，配置、日志、数据，使用本地卷后，删除容器，不会删除配置、数据。

启动一个 GitLab 就是那么简单。

执行完命令需要稍等一会，GitLab 的镜像 800M 左右，第一次运行需要下载镜像。启动之后直接打开配置的 hostname 115.159.52.223，你会看到这样一个页面，说明启动成功了。

![图片待定][7de505ca10937da365b712ed41e6efaa.png]

这个页面是要你输入超级管理员 root 的密码。root 超管可以看到 GitLab 的所有信息，如用户、项目、流水线。

### 测试 GitLab ###

GitLab 安装成功了，现在我们需要创建一个项目测试一下，能否正常使用。首先使用邮箱注册一个账号，创建一个空的 public 项目，注意空的项目就可以了，不需要创建任何内容，起名为 hello-cicd。

如下图：

![图片待定][209e0125c7f3b01911d5e065dbdedf44.png]

项目地址为：

http://115.159.52.223/pmc/hello-cicd.git

在本地，我们使用 vue-cli 创建一个空的项目：

vue create hello-cicd

创建成功后我们推送到远程服务器，使用以下命令：

cd hello-cicd
    git init
    git remote add origin http://115.159.52.223/pmc/hello-cicd.git
    git add .
    git commit -m "Initial commit"
    git push -u origin master

第一次推送时需要输入账号和密码，推送完成后，就能在 GitLab 看到代码了。

至此，GitLab 算是安装成功了。

这里安装 GitLab 是直接使用 IP 访问的，在实际的生产环境中，可能就没那么简单了，不管需要域名访问，可能还要配置 HTTPS。

我们在 Docker 启动 GitLab 的时候，选择了一些本地卷，其中 /srv/gitlab/config 就是存放 GitLab 的配置文件的目录。其中有一个 gitlab.rb 的配置文件非常重要，我们可以进入看一下 `cat /srv/gitlabe/config/gitlab.rb` 如果你要配置 HTTPS，就只需要修改这里的选项，指定证书即可。在比如，更改上传文件大小的限制，关于此文件更多属性的描述，可以[查阅这里][Link 4]，这里就不一一展开解释了。

### GitLab Runner ###

现在我们安装好了 GitLab，也能正常使用了，但对于怎样去自动化部署，怎样在我一提交代码，GitLab 就把最新的代码发布到测试环境或者生产环境，这里边就不得不说 CI/CD、DevOps、pipeline 以及 GitLab Runner 这些概念了。

**DevOps**

Development 和 Operations 的组合，传统的软件组织讲开发和 IT 运营以及质量保障设为分离的部门，Devops 是在敏捷开发模型上进一步发展而来的。满足了产品研发所要求的持续开发、持续测试、持续集成、持续部署。

**CI/CD**

即 Continuous Integration（持续集成）和 Continuous Delivery（持续交付）Continuous Deployment（持续部署）。

**pipeline**

是我们配置好的 CI/CD 的流程，比如安装依赖包，进行代码 review、构建、编译、发布等一整套的流程。

**GitLab Runner**

执行流水线的环境，所有 CI/CD 的任务都是在他内部去进行执行的，他和 GitLab 是两个不同的软件，虽然都是 GitLab 发布的，但功能是不要的，一个代码管理，一个是流水线，CI/CD 的执行环境，二组搭配工作。

所以如果我们要使用 CI/CD，就要安装 GitLab Runner，由它来执行我们的构建，部署流程。GitLab Runner 可以安装在很多平台上，也可以使用很多工具安装，可以在 GNU/Linux、macOS 和 Windows 上工作。可以在 K8s 环境安装，也可以在 Docker 环境安装。这里我们只介绍如何使用 Docker 去安装 GitLab Runner，以及如何配置。

在已安装了 Docker 的环境中，使用下面一条命令来安 GitLab Runner：

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

将外部的 gitlab-runer 的配置挂在到 gitlab-runner 容器的内部，并将外部的 docker.sock 挂在到容器内部。执行完成，我们使用 `docker container ls` 可以看到一个容器名为 gitlab-runner 的容器。

到这里 GitLab Runner 安装成功了。

我的 GitLab 和 GitLab Runner 都用 Docker 启动了，目前为止他们是两个毫无联系的软件，可能在一台电脑上，也可能不在。

那怎么让两个产生联系，然后让 GitLan Runner 去构建我们的任务？

这就是我要讲的下一步，安装完了 GitLan Runner 之后，我们还要在 GitLab Runnner 为 GitLab 的某个项目，或者整个 GitLab 注册一个 Runner。Runner 才是真正执行我们 CI/CD 任务的环境。一个 GitLab Runner 可以注册多个 Runner，每个 Runner 只能服务于一个 GitLab 环境，但可以服务于同一个 GitLab 的多个项目。

**一个项目也可以使用多个 Runner。**

这样说可能有点绕，你只需要了解这是两个完全独立的东西。让我们真正注册一个 Runner 试试吧。

要注册一个 Runner，需要有两个东西，一个是 GitLab 的地址，一个是注册 Runner 的 token，缺一不可。

这两个东西在这里获取：

> 项目 => Setting => CI/CD => Runners

你会在这里看到：

![gitlab-url  token][gitlab-url token]

这里就是我们需要的东西。

怎么使用的？使用下面这个命令：

docker run --rm -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register \
      --non-interactive \
      --executor "docker" \
      --docker-image alpine:latest \
      --url "http://115.159.52.223/" \
      --registration-token "FJdr8Hg4mroxJBpbZ4bv" \
      --description "docker-runner" \
      --tag-list "docker,aws" \
      --run-untagged="true" \
      --locked="false" \
      --access-level="not_protected"

这条命令中有两个关键属性，url 和 registration-token，分别对应我们的 GitLab 地址和 Runner 的注册 token。

有了这两个我们就能把 Runner 和 GitLab 的项目进行绑定了。

除了 url 和 registration-token 还有几个属性：

*  executor：执行器，可选 docker、k8s、shell
 *  description：runner 的描述
 *  tag-list：runner 的 tag，使用逗号分隔，如果一个项目有多个 Runner，需要根据 tag 来指定使用那个 Runner 来运行任务
 *  locked：是否锁定，锁定后，只能适用于被项目，不能被其他项目使用

注册成功后我们会看到这样一句话：

![注册 runner 成功][runner]

然后我们在 GitLab 刷新页面，就能看到有个绿色在线标识的 Runner 已经被注册成功了。

![在线 runner 显示][runner 1]

好了，目前所有环境基本都已经安装配置成功了，接下来就要写 CI/CD 的配置了。

### 前端项目 CI/CD 流程的设计 ###

在为项目做 CI/CD 时，我们一般都要使用 docker 镜像，比如你要使用 npm 指令，那就需要在 CI/CD 中指明使用 node 的镜像。

此外 GitLab 的 CI/CD 默认有五个阶段 stages，从先后执行顺序为：

> .pre => build => test => deploy => .post

当然你可以自定义更多的阶段。stages 是定义了一组 job 的任务列表，内部的 job 并行执行。

一条 Pipeline 有多个 stages，一个 stages 有多个 job，不太懂三者的关系的可看下下图：

![三者关系图][73b15b885b1cb55ebe5e2078b7e59721.png]

首先这是一条流水线，是在某个分支上提交了代码而触发的，他的内容全部都是由 .gitlab-ci.yml 文件定义的。

然后这条流水线有三个 stages 分别是 Install、Test、Build-dist。

三个 stages 一共有四个 job，其中 stages Install 有两个 job，分别是 install、installA。如果不太明白这三者的关系，初学可能会晕。

前端项目做 CI/CD 其实还是蛮好做的，如果部署的是静态页面，直接放到对应的服务器里就行了，如果是像 hello-cicd 这样的 Vue 单页面应用，就需要下载 node 的包 install 阶段，然后进入 eslint 验证代码 test 阶段，然后就是 build 项目，build 阶段，最后是发布部署，deployment 阶段。

但是发布和部署，又分很多场景。test 环境、uat 环境、预发布环境、正式环境。

除了发布阶段，其他阶段都是需要 node\_modules 的支持，所以我们可以将下载的包缓存起来。最简单的缓存方案是直接在 runner 本地缓存，此外还有 s3 缓存、ceph 缓存，这就有点扯的远了。每个阶段都是可以使用不同的 runner，只需要在每个阶段指明 tag 即可，没有指明的默认使用共享 runner，为了方便我们使用了同一个 runner。

在做前端 CI/CD 时，如果只有一个环境，我们可以简单点将编译和部署放到一起，编译之后将编译出来的 dist 目录上传到服务器上。

如下图就是一个最简单的流水线效果图：

![流水线效果图][1961fb4a1db72c38d330a2411e98211a.png]

### 正式开始编写 .gitlab-ci.yml 的内容 ###

前面说了那么多，都是为了编写.gitlab-ci.yml 这个文件做准备。让我们看一下.gitlab-ci.yml 文件到底是个什么东西。

#### 介绍 .gitlab-ci.yml ####

首先这是一个 YAML 文件，所以在写之前，我们最好有一些 YAML 文件的语法的基本知识，比如缩进,清单的使用。有关 yaml 文件的语法，大家可以参考[阮一峰 YAML 教程][YAML]。

其次这个文件是定义 CI/CD 所有流程，包括 stage，job。每一个项目都有自己的.gitlab-ci.yml 文件，一般存放在项目的根目录。如果不存放在根目录，则需要特殊配置一下 CI/CD 才能被 runner 调用。

其中最常用的对象有 stages、job、cache、script、image。

在.gitlab-ci.yml 中最小的单元是 job，所以我们可以将.gitlab-ci.yml 的内容看做是一组 job 的集合。

看下面一个简单的例子：

installA:
      stage: install # 定义 job 的阶段 必须属于 stages 中的一个
      script:
        - echo Hello installA

这里定义了一个 job，名称叫做 installA，此外这个 job 属于一个叫做 install 的 stage（阶段），这个 job 的具体内容是定义在 script 中的，内容是 `echo Hello installA`，打印出 Hello installA。当然这里的 echo Hello installA 我们可以替换成 npm install 这样在 runner 中安装项目的依赖包。所有的 script 的脚本都是在项目的根目录去执行的，在 pipelines 被触发后，runner 会自动帮你把项目下载到 runner 机器的工作目录中。

在一个 job 中 job 的名称和 script 是必须的，其他的都不是必须的。如一个最简单的 job：

job1:
      script: "execute-script-for-job1"

默认 stage 是 default。目前没有限制 job 的数量。

但 job 的名称不能是这些单词，image、services、stages、types、before\_script、after\_script、variables、cache、include，除了这些都可以，你可以设置为中文。

一个 job 的配置参数其实有很多，但大部分做一个前端项目用不到那么多，下面是罗列的 job 的配置参数：

*  script 被 runner 执行的 shell script
 *  after\_script 在 job 之后执行的脚本
 *  allow\_failure 是否允许 job 失败
 *  artifacts 在 job 成功后将一个文件列表或目录列表制成制品上传
 *  before\_script 在 job 之前执行的脚本
 *  cache 缓存在随后的 job 的一些文件、目录
 *  coverage 代码覆盖率设置
 *  dependencies 依赖某个 job 的制品并下载到当前的 job 中
 *  environment job 依赖的环境变量
 *  except 限制那些情况 job 不会被触发
 *  extends job 的继承的配置项
 *  image 依赖的 Docker 镜像
 *  include 运行 job 包含额外的 yml 文件
 *  interruptible 定义当作业因较新的运行而变得冗余时是否可以取消。
 *  only 限制 job 何时可以被触发
 *  pages 上传 job 的结果到 GitLab Pages
 *  parallel 一个 job 应该并行运行多少个实例。
 *  release 通知 runner 生成一个 release
 *  resource\_group 限制 job 的并发性
 *  retry 是否重试 重试几次
 *  rules 与 only/except 类似，限制 job 的调起
 *  services 使用 Docker 镜像服务
 *  stage 阶段
 *  tags 选择 runner 的 tag
 *  timeout 超时
 *  trigger 定义下游 pipelines 触发器
 *  variables 定义 job 级别的变量
 *  when 何时触发任务

一个 job 中的变量还是蛮多的，这足矣看出 GitLab CI/CD 的强大，但我们平时配置项目的 CI/CD 时，用不到那么多属性。很多属性我们可以作为简答了解。

文末我会给出官方的关于 job 的变量解释。

懂了一个 job 之后，我们来看一下整个 pipelines：

image: node:latest
    
    # 定义阶段的执行顺序 分为 4 个阶段
    stages:
      - install
      - test
      - build
      - deploy
    
    # 定义 install 的 job
    install: # job 的名称
      stage: install # 定义 job 的阶段 必须属于 stages 中的一个
      script:
        - echo Hello install
    
    installA:
      stage: install # 定义 job 的阶段 必须属于 stages 中的一个
      script:
        - echo Hello installA
    
    # 定义部署远程服务的 job 名称
    deploy-server:
      stage: deploy
      script:
        - echo Hello deploy-server
      only:
        - master
    
    
    # 定义代码验证的 job
    code-lint:
      stage: test
      script:
        - echo Hello code-lint
      allow_failure: true # 运行失败,代码验证失败后仍然会执行后续 job
    
    # 编译生成文件的 job
    build-dist:
      stage: build
      script:
        - echo Hello build-dist
      artifacts:
        dist

#### 镜像的使用 ####

第一行的 `image: node:latest` 表明使用 Node.js 最新版本作为基础镜像，当 pipelines 被触发后，runner 会去 pull Node.js 的镜像，并不是每次都会 pull，只有本地没有的时候才会去拉取。因为我们要使用 npm 去执行一些任务，比如 `npm install` 或 `npm run build`，就需要拉取 Node.js 的镜像。

#### stages 执行顺序的定义 ####

stages:
      - install
      - test
      - build
      - deploy

上面这部分代码定义了 pipelines 中使用到的 stage 的执行顺序。

先执行 install 阶段的 job，随后执行 test => build => deploy。最后执行的一个阶段是 deploy 这样定义之后，在写 job 的时候，可以将 deploy 阶段的 job 放到 test 阶段之前。

#### job 内容的编写 ####

job 的真正执行内容都是定义在 script 中的，这里可以执行 shell 脚本，比如`npm install`、`mkdir code && cd code`。

stage 属性定义当前 job 属于哪个 stages 从而能够确定该 job 的执行顺序。此外还有 `allow_failure: true`，这句话的意思是，此 job 允许失败，失败后会继续执行后续 job。如果团队对代码要求不严格的话，在用 ESLint 验证代码时可以加上这个。如果出现了错误，会有一个黄色的感叹号显示。

如下图：

![警告 job][job]

此外每一个 job 都可以指定一个 runner 作为执行器。

使用 tags 来指定运行 job 的 runner，如：

code-lint:
      stage: test
      tags:
        - docker
      script:
        - npm run lint

使用标签为 docker 的 runner 作为 job 的执行器，这个的 docker 对应这里的信息：

![在这里插入图片描述][6cebd3d84e655dc6ff77fae2391a360a.png]

only:
        - master

这句话是表明，此 job 的执行的限定条件，只能在 master 分支运行，使用 only 关键字可以限定 job 的运行 ，如限定某些分支、某些 push、pr 合并、触发 job。还有一个关键词 except 可以限定排除那些情况都执行该 job。比如说，只有 master 分支可以发布生成环境，打了 tag 再去触发 job。

when: manual

这句话定义该 job 是手动触发的，默认不写是自动执行触发的。手动触发的 job 是这样子的：

![手动触发的 job][job 1]

此外 when 的取值还可以是以下几个属性：

*  on\_success
 *  on\_failure
 *  always
 *  delayed
 *  never

当 job 执行错误时自定义通知，就可以使用 `when: on_failure`。

了解了 .gitlab-ci.yml 的具体写法后，我们来真正地为 hello-cicd 做 CI/CD。

首先 pipelines 有以下结果阶段，安装依赖包的 install，测试代码的 code-lint 阶段，和编译项目阶段 build，以及部署阶段 deploy  
应该换成 node\_modules，此外还需要使用 node 的镜像。

那么内容如下：

我们使用 Node.js 最新的版本的镜像，另外需要注意的是，在安装依赖包是，只能使用 npm，不能使用 yarn，要使用 yarn 换 Node.js 的镜像，此外，在安装依赖包是一定要配置 npm 的源，要不然下来依赖包是非常慢的。这里的部署部分我还没有写完，因为这部分还需要配置一些额外的东西。

将内容保存到.gitlan-ci.yml 中，提交后，我们就能看到触发了流水线：

![在这里插入图片描述][5604edbab06f32d39bf4e147ba5bd837.png]

上面的图片是流水线的页面，点其中的一个 job 可以看到 job 的具体日志，如下图：

![在这里插入图片描述][e7c2b0df6a8c1ae4dee0eef0a1a5c401.png]

现在我们已经做好了项目的 CI、CD 持续部署，还没有做，具体前端这边有多重部署方式，最常用的是将 build 后的静态文件直接跌到 CDN 上，或者一种做成一个 Docker 镜像，可以运行在任何一个服务器上。

下面先介绍一下使用 Docker 镜像部署前端项目的。

这里涉及到一些隐秘变量的使用，先来介绍一下啊，比如你要在 .gitlab-ci.yml 中使用一些密码、私钥，直接使用时非常不安全的。

GitLab 提供了一种在 CI/CD 中安全使用隐秘变量的方式，如下图添加变量：

![在这里插入图片描述][c98615fc74d831e0053747fe78a33752.png]

添加变量后在 .gitlab-ci.yml 中使用 `$+变量名` 的方式来使用，我们要在 Variables 中配置我们要把镜像推送的地方，是 docker hub 还是 harbor，以及用户名、密码、镜像名、运行的容器名。

使用 Docker 的方式不是必须要在项目中添加 Dockerfile，用于构建镜像，Dockerfile 内容如下：

# 使用 nodejs 的缩小版作为镜像,因为需要 npm 安装依赖包和执行命令
    FROM node:alpine as builder
    
    # 设置工作目为/app
    WORKDIR /app
    
    # 将 package.json 复制到根目录
    COPY package.json .
    
    # 设置 node-sass 的下载源 并设置 npm 的源 下载依赖包
    RUN npm config set sass_binary_site https://npm.taobao.org/mirrors/node-sass/ && \
        npm install --registry=http://registry.npm.taobao.org
    
    # 复制所有源代码到根目录
    COPY . .
    
    # 执行 npm run build 进行编译
    RUN npm run build
    
    # 使用 nginx 缩小版作为基础镜像
    FROM nginx:alpine
    
    # 将构建的 dist 目录复制到/usr/share/nginx/html 此目录后进行 nginx 代理,启动 nginx 后可以访问
    COPY --from=builder /app/dist /usr/share/nginx/html

完成了配置变量和 Dockerfile 我们就来完成最后阶段的 CD：

# 定义构建镜像
    build-image:
      image: docker # 依赖的基础镜像
      stage: build
      script:
        - docker login -u $HARBOR_USERNAME -p $HARBOR_PWD $HARBOR_URL # 登录镜像仓库
        - docker build -t $APP_IMAGE_NAME . # 构建镜像
        - docker push $APP_IMAGE_NAME # 推送镜像
        - docker rmi $APP_IMAGE_NAME # 删除本地镜像
      only:
        - master
    
    deploy:
      image: docker
      stage: deploy
      script:
        # 如果有容器名为$APP_CONTAINER_NAME 的容器在运行则强行上删除
        - if [ $(docker ps -aq --filter name=$APP_CONTAINER_NAME) ]; then docker rm -f $APP_CONTAINER_NAME; docker image rm -f $APP_IMAGE_NAME;fi
    
        # 登录镜像仓库
        - docker login -u $HARBOR_USERNAME -p $HARBOR_PWD $HARBOR_URL
    
        # 使用 8001 端口,镜像名为$APP_CONTAINER_NAME 的后台方式 运行一个镜像
        - docker run -d -p 8001:80 --name $APP_CONTAINER_NAME $APP_IMAGE_NAME
        - echo 'deploy product websit success'
      only:
        - master
      when: manual # 手动执行,需要点击

build 阶段，用于构建镜像。每一行代码都有注释，这里就不多做解释了。

变量解释：

*  `$HARBOR_URL`：harbor 地址
 *  `$HARBOR_USERNAME`：harbor 用户名
 *  `$HARBOR_PWD`：harbor 密码
 *  `$APP_CONTAINER_NAME`：容器名称
 *  `$APP_IMAGE_NAME`：镜像名称

完整的内容是：

image: node:latest
    
    stages:
      - install
      - code-lint
      - build
      - deploy
    
    cache:
      paths:
        - node_modules
    
    install:
      stage: install
      script:
        - npm config set sass_binary_site https://npm.taobao.org/mirrors/node-sass/
        - npm install --registry=http://registry.npm.taobao.org
    
    code-lint:
      stage: code-lint
      script:
        - npm run lint
      allow_failure: true
    
    # 定义构建镜像
    build-image:
      image: $DOCKER_IMG # 依赖的基础镜像
      stage: build
      script:
        - docker login -u $HARBOR_USERNAME -p $HARBOR_PWD $HARBOR_URL # 登录镜像仓库
        - docker build -t $APP_IMAGE_NAME . # 构建镜像
        - docker push $APP_IMAGE_NAME # 推送镜像
        - docker rmi $APP_IMAGE_NAME # 删除本地镜像
      only:
        - master
    
    deploy:
      image: $DOCKER_IMG
      stage: deploy
      script:
        # 如果有容器名为$APP_CONTAINER_NAME 的容器在运行则强行上删除
        - if [ $(docker ps -aq --filter name=$APP_CONTAINER_NAME) ]; then docker rm -f $APP_CONTAINER_NAME; docker image rm -f $APP_IMAGE_NAME;fi
    
        # 登录镜像仓库
        - docker login -u $HARBOR_USERNAME -p $HARBOR_PWD $HARBOR_URL
    
        # 使用 8001 端口,镜像名为$APP_CONTAINER_NAME 的后台方式 运行一个镜像
        - docker run -d -p 8001:80 --name $APP_CONTAINER_NAME $APP_IMAGE_NAME
        - echo 'deploy product websit success'
      only:
        - master
      when: manual # 手动执行,需要点击

以上例子如何公司没有部署 harbor 的话，可以使用 dokerhub 代替。或者构建之后，直接在本地运行，省去了登录，和推送阶段。效率更高。

以上是使用 Docker 镜像的方式去部署而且部署主机与 runner 是不分离的，接下来再演示一种方式，使用 ssh 将编译后的前端静态文件上传到服务器。

部署效果如图：

![在这里插入图片描述][da00b71dff7a9b10f6d03a83bc824e57.png]

#### 在 CI/CD 中使用 SSH keys ####

常规的部署方案是，Runner 跑在一台单独的机器上，部署应用的机器是另一台，这个就能做到职责单一，互不影响，防止因为某一个任务负载过大而导致机器宕机。

那么问题来了，如果 Runner 跑在机器 A，应用部署在机器 B，那么 Runner 对前端项目 build 之后，怎样将 build 后的静态文件，上传到机器 B 那?这是一个问题，但 GitLab 的团队早就想到了这个，并提供了解决方案，那就是使用 SSH keys。简单就是在机器 A 和机器 B 之间创建一个免密登录，在机器 A build 项目之后，静默地调用指令将文件上传到机器 B，从而实现部署。

思路很清晰，方向很明确，那就开始干吧。

首先构建免密复制，免密上传的方向是机器 A 到机器 B。并且机器 A 的 Runner 是用 Docker 镜像启动的，所有配置免密登录还是需要搞清楚的。

配置步骤如下：

*  在机器 A 创建 SSH key（注意不是在 Runner 的内部，而是在机器 A 本地）
 *  上传公钥到机器 B，一般是 `~/.ssh/authorized_keys`

创建 SSH key：

ssh-keygen -t rsa -b 2048 -C "email@example.com"

生成过程：

![图片待定][9f0eaf28fc4cbf8b55b9713bba5b1759.png]

生成 ssh key 之后就要上传到服务器了。使用以下命令上传。

scp -r id_rsa.pub root@1.2.3.4:/root/.ssh/authorized_keys

上传过程：

![图片待定][af67f42391eb6b01e959ab9d80ebdd39.png]

将公钥 id\_rsa.pub 上传到服务器 authorized\_keys 文件中，第一次会保存 known hosts，并且要求输入密码，上传成功后，再次执行上面的命令就不需要输入密码了。

免密构建成功，就要配置 CI/CD 了。

首先创建一个 SSH\_PRIVATE\_KEY 的变量，将秘钥复制进去。接着修改.gitlab-ci.yml 文件。

修改部署的 job 为以下内容：

deploy-server:
      stage: deploy
      before_script:
        # 如果没有安装 `ssh-agent`,就安装，基于 RPM 的镜像可以将 apt-get 替换为 yum
        - 'command -v ssh-agent >/dev/null || ( apt-get update -y && apt-get install openssh-client -y )'
        - eval $(ssh-agent -s) # 运行 ssh-agent
        - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
    
        # 创建对应的目录并给相应的权限
        - mkdir -p ~/.ssh
        - chmod 700 ~/.ssh
    
        - ssh-keyscan 115.159.52.223 >> ~/.ssh/known_hosts
        - chmod 644 ~/.ssh/known_hosts
      script:
        - npm run build
        - scp -r dist/* root@115.159.52.223:/usr/local/www/hello-vue
      only:
        - master

代码解释：

*  任务是在 Docker 容器中运行的，所以要使用 ssh 必须要确保已经安装必要的软件。
 *  如果没有安装 ssh-agent，就安装，基于 RPM 的镜像可以将 apt-get 替换为 yum。
 *  注意目录 /usr/local/www/hello-vue 需要配置了 Nginx 映射才能够访问。

完整的 .gitlab-ci.yml 内容：

image: node:latest
    
    stages:
      - install
      - code-lint
      - build
      - deploy
    
    cache:
      paths:
        - node_modules
    
    install:
      tags:
        - ubuntudocker
      stage: install
      script:
        - npm config set sass_binary_site https://npm.taobao.org/mirrors/node-sass/
        - npm install --registry=http://registry.npm.taobao.org
    
    code-lint:
      tags:
        - ubuntudocker
      stage: code-lint
      script:
        - npm run lint
    
    deploy-server:
      tags:
        - ubuntudocker
      stage: deploy
      before_script:
        # 如果没有安装 `ssh-agent`,就安装，基于 RPM 的镜像可以将 apt-get 替换为 yum
        - 'command -v ssh-agent >/dev/null || ( apt-get update -y && apt-get install openssh-client -y )'
        - eval $(ssh-agent -s) # 运行 ssh-agent
        - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
    
        # 创建对应的目录并给相应的权限
        - mkdir -p ~/.ssh
        - chmod 700 ~/.ssh
    
        - ssh-keyscan 115.159.52.223 >> ~/.ssh/known_hosts
        - chmod 644 ~/.ssh/known_hosts
      script:
        - npm run build
        - scp -r dist/* root@115.159.52.223:/usr/local/www/hello-vue
      only:
        - master

部署效果：

![在这里插入图片描述][617ec9d7dae608b6c6dae239659f33a2.png]

部署日志：

![在这里插入图片描述][e2f678b7220e2460cca6aeca635e9db0.png]

pipeline 走完之后刷新一下页面就能看到结果了。

#### 前端项目部署到阿里云OSS ####

前端的项目还有一种部署方式就是使用各大云厂商的对象存储,然后设置为网站静态资源托管,并且开启CDN加速,以达到最好的用户体验。下面就说下怎么将前端项目部署到阿里云OSS。  
首先需要购买一个OSS服务，创建一个Bucket

[购买OSS标准服务套餐][OSS]后进入[OSS管理控制台][OSS 1]  
  
创建一个Bucket之后，需要将此Bucket设置为静态页面，开启网站托管。并将权限设置为公共读写。

部署OSS的job如下

deploy-oss:
      stage: deploy
      script:
        - npm run build
        - wget http://gosspublic.alicdn.com/ossutil/1.6.18/ossutil64
        - chmod 755 ossutil64
        - ./ossutil64 config -e ${endPoint} -i ${accessKeyID} -k ${accessKeySecret} -L CH --loglevel debug -c ~/.ossutilconfig
        - ./ossutil64 -c ~/.ossutilconfig cp -r dist oss://fizzz/
      only:
        - master
      when: manual

使用的是官方提供的OSS命令行工具ossutil， 具体文档可以[查阅此处][Link 5]  
endPoint 是Bucket所在区域的入口  
accessKeyID与accessKeySecret 是阿里云的用户凭证。[创建文档][Link 6]

脚本的最后一句 `- ./ossutil64 -c ~/.ossutilconfig cp -r dist oss://fizzz/`  
是将编译后的dist上传到 oss://fizzz/ 地址上。

OSS可以配置域名访问，HTTPS访问，目前还不支持转发，就是单页面应该目前还无法使用history路由。

我的博客里有更多关于部署方案的，如部署到华为云的OBS,大家可以查阅。

### 前端项目 CI/CD 最佳业务配置思路 ###

一个好的 CI/CD 流程，应该包含以下几点

*  权限可控
 *  缓存使用得当
 *  分支作用明确
 *  根据 tag 创建稳定的 release
 *  GitLab Runner 可伸缩
 *  流水线异常多渠道通知
 *  支持多个微服务一键同步部署
 *  隐秘信息使用声明变量
 *  使用镜像时要配置 .dockerignore

分开来讲，权限可控是指发布正式环境，或者预发布环境只有指定的人才能发布，合并代码必须要经过 CI 验证后才能合并。

缓存使用得当，可以加快流水线的构建，也使的发布流程更加顺畅，缓存可以使用第三方的，也可以用本地，另外需要指定缓存的删除策略，不然一直增加缓存机器会爆掉的。缓存可以使用单个文件的 hash 值来缓存，也可以直接缓存一个目录，分支作用明确之后才能规划分支的发布流程，有些分支只能发布开发环境，有些分支只能发布 test 环境，而且只有一个分支才能发布正式环境。

一个版本发布后需要给代码的打一个 tag，标注增加了那些功能，修复了那些问题，做了那些优化，然后发布一个 release。这部分也可以使用 CI/CD 自动构建，流水线异常多渠道通知是指，发布或构建过程中出错了，要能及时让人及时感知，快速解决问题，一个流水线构建有的需要 10 分钟，不可能每次都要一直等在哪里，所有可以接入钉钉通知、邮件通知，或接入第三方应用通知。

微服务的流行使 CI/CD 迎来了更大的挑战，目前 GitLab 已经支持了多流水线构建，方便一次版本同时发布多个应用，避免有的应用丢失。使用.dockerignore 将不需要的文件在构建镜像时忽略，以加快构建速度。

### 常见问题排查及修复 ###

**问题 1：使用 GitLab 时，项目的 ssh 地址不是 ip 或域名，而是一串字符串**

![错误 clone 项目地址][clone]

出现这个问题，是因为你在运行 GitLab 镜像时，没有指明 hostname，或者没有配置 Host，run 镜像时指明 hostname 添加参数 `--hostname 115.159.52.223`，没有配置 Host，则进入配置文件修改。

vim /srv/gitlab/config/gitlab.rb

在文件底部加上 `external_url 'http://115.159.52.223'`。

**问题 2：yum:not found apt-get:not found**

![yum not found][]

一般是出现免密部署资源时出现，原因是由于使用 `:alpine` 版本的镜像，将版本 `:alpine` 去掉即可。

**问题 3：Error response from daemon: OCI runtime create failed: container\_linux.go:349: starting container process caused**

![容器错误][bbf15542c3714fd6506560975442705d.png]

这是由于注册以 Docker 为执行器的 runner，配置文件没有配置好。找到对应的 Runner，将 volumes 改为

volumes = ["/cache","/usr/lib64/libltdl.so.7:/usr/lib/x86_64-linux-gnu/libltdl.so.7:rw", "/usr/bin/docker:/usr/bin/docker", "/var/run/docker.sock:/var/run/docker.sock"]

有时候不需要 `"/usr/lib64/libltdl.so.7:/usr/lib/x86_64-linux-gnu/libltdl.so.7:rw"` 这一句，需要看具体机器。这句配置，就是挂在缓存和 docker 的配置。

**问题 4：Host key verification failed. lost connection**

![ssh-key 配置错误][ssh-key]

这是由于配置免密 SSH-KEY 的时候出来问题，在使用免密登录的 job 中，before\_script 需要是以下内容，115.159.52.223 是要部署的机器。

before_script:
      - 'command -v ssh-agent >/dev/null || ( apt-get update -y && apt-get install openssh-client -y )'
      - eval $(ssh-agent -s)
      - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
      - mkdir -p ~/.ssh
      - chmod 700 ~/.ssh
    
      - ssh-keyscan 115.159.52.223 >> ~/.ssh/known_hosts
      - chmod 644 ~/.ssh/known_hosts

**问题 5：cache:key config should be a string or symbol**

![版本问题][deaf0972e7b134e275284f1732079110.png]

低版本的 GitLab cache 的 key 必须是一个字符串或者 symbol，而高版本可以指向一个文件，如 package.json。

**问题 6：scp: /usr/local/temp: Permission denied**

当 copy 文件的时候，由于配置的免密登录的用户没有目标目录的权限，导致出现 Permission denied，出现这种情况，要么重新配置一个高权限的免密登录用户，要么更换目标目录。

**问题 7：/dist: No such file or directory**

![路径错误][9581eb3e6c9ee9ac6d85c6b2366a59be.png]

当程序执行 `scp -r /dist root@115.159.52.223:/usr/local/wwww` 时，找的 dist 目录是在系统的根目录寻找的，加上 `/` 就是一个决定路径，去掉 `/` 是相对路径，正确的写法是去掉 `/`，写成 `scp -r dist root@115.159.52.223:/usr/local/wwww`。

**问题 8：error during connect: Post http://docker:2375/v1.40/auth: dial tcp: lookup docker on…**

![docker 配置问题][docker]

这是由于在 CI/CD 中使用了 Docker 命令，但在 runner 中没有配置 Docker 的卷。在 runner 的配置中配置：

volumes = ["/cache","/usr/lib64/libltdl.so.7:/usr/lib/x86_64-linux-gnu/libltdl.so.7:rw", "/usr/bin/docker:/usr/bin/docker", "/var/run/docker.sock:/var/run/docker.sock"]

**问题 9：应用发布成功但却无法访问**

检查防火墙、安全组。端口是否对外开发。

#### 相关参考链接 ####

*  [Docker 安装 GitLab][Docker _ GitLab]
 *  [Docker 安装 GitLab Runner][Docker _ GitLab Runner]
 *  [Runner 配置][Runner]
 *  [.gitlab-ci.yml 的语法][.gitlab-ci.yml]
 *  [在 CI/CD 中使用 SSH keys][CI_CD _ SSH keys]

--------------------

本文首发于 GitChat，未经授权不得转载，转载需与 GitChat 联系。

[Link 1]: https://fizzz.blog.csdn.net/
[035e13174b869d50e785b8d11f4819fb.png]: /images/20220829/32af59857b084766bc9626046eea30bd.png
[Link 2]: https://blog.csdn.net/github_35631540/article/details/107282211
[Docker]: https://gitbook.cn/gitchat/activity/5ee44de842f9cf10afd4695d
[Link 3]: https://docs.docker.com/engine/install/centos/
[Docker info]: /images/20220829/3d7d9def76fc4a1aac724a5d0a6cb4fc.png
[7de505ca10937da365b712ed41e6efaa.png]: /images/20220829/fb4d4f2b6eb14b7e99c93b59c4794702.png
[209e0125c7f3b01911d5e065dbdedf44.png]: /images/20220829/04df333d6f274e3fa7097d4b353b3e31.png
[Link 4]: https://docs.gitlab.com/omnibus/settings/README.html
[gitlab-url token]: /images/20220829/4a8b670515e843aeb77ecb18d5529ec9.png
[runner]: /images/20220829/006e915245a24c9e93515bbf91f86dc6.png
[runner 1]: /images/20220829/9f943fd5298f421eacd5755fb0edafce.png
[73b15b885b1cb55ebe5e2078b7e59721.png]: /images/20220829/d6c7c87e4bdf489ba41cde71e5abd881.png
[1961fb4a1db72c38d330a2411e98211a.png]: /images/20220829/c27765d2e3084b87ae6d0b0c502cea5e.png
[YAML]: http://www.ruanyifeng.com/blog/2016/07/yaml.html
[job]: /images/20220829/84c1196137334544bf2307c27372fa82.png
[6cebd3d84e655dc6ff77fae2391a360a.png]: /images/20220829/d241ac63f92a4a08912c670f330df59c.png
[job 1]: /images/20220829/3c2bc29fc80744c8a2e4e9b1fc507ea1.png
[5604edbab06f32d39bf4e147ba5bd837.png]: /images/20220829/6f40698456ad4789ac594d9688242c41.png
[e7c2b0df6a8c1ae4dee0eef0a1a5c401.png]: /images/20220829/2c117aa3907b41b793b72c946a5cacc5.png
[c98615fc74d831e0053747fe78a33752.png]: /images/20220829/2a5a636134df4f83a87508ff69a7bb6f.png
[da00b71dff7a9b10f6d03a83bc824e57.png]: /images/20220829/b2b000e46a134dbdb1e663c67590b4d3.png
[9f0eaf28fc4cbf8b55b9713bba5b1759.png]: /images/20220829/1f1929d883e1439d92b483493fee2c19.png
[af67f42391eb6b01e959ab9d80ebdd39.png]: /images/20220829/fae9b775d04f46f8a35c62df6bbf9201.png
[617ec9d7dae608b6c6dae239659f33a2.png]: /images/20220829/5a194904c4194e198e2ee25a120e407f.png
[e2f678b7220e2460cca6aeca635e9db0.png]: /images/20220829/8cee71f310fc44b0bd21a3e90a300c7f.png
[OSS]: https://common-buy.aliyun.com/?spm=5176.7933691.1309819..25502a66amfMYU&commodityCode=ossbag&request=%7B%22region%22%3A%22china-common%22%7D#/buy
[OSS 1]: https://oss.console.aliyun.com/overview
[Link 5]: https://help.aliyun.com/document_detail/120075.html?spm=a2c4g.11186623.6.733.320d7c575h2YKj
[Link 6]: https://help.aliyun.com/document_detail/53045.html#task-1715673
[clone]: /images/20220829/d74dcd534e5d4e25b2b8e25a906bba6b.png
[yum not found]: /images/20220829/2887bdf005a0450fa9592c76ef8c7cc0.png
[bbf15542c3714fd6506560975442705d.png]: /images/20220829/12358974d0f94dc0bfd5bee6744adbd9.png
[ssh-key]: /images/20220829/77a86b15eda84d38bb3d66da3d1b75ad.png
[deaf0972e7b134e275284f1732079110.png]: /images/20220829/0c834e6fd61246d7a6f7bbe24c1c257d.png
[9581eb3e6c9ee9ac6d85c6b2366a59be.png]: /images/20220829/e37ee6e87f714228b72e6c476788fe69.png
[docker]: /images/20220829/1b7b5ebb4ce24605b9fb31271176a34e.png
[Docker _ GitLab]: https://docs.gitlab.com/omnibus/docker/#install-gitlab-using-docker-engine
[Docker _ GitLab Runner]: https://docs.gitlab.com/runner/install/docker.html#option-1-use-local-system-volume-mounts-to-start-the-runner-container
[Runner]: https://docs.gitlab.com/runner/configuration/advanced-configuration.html
[.gitlab-ci.yml]: https://docs.gitlab.com/ee/ci/yaml/README.html
[CI_CD _ SSH keys]: https://docs.gitlab.com/ee/ci/ssh_keys/README.html#using-ssh-keys-with-gitlab-cicd