持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第8天，点击查看活动详情

兄弟们第九、十章来啦！！！

第九章：前端应用域名配置

[ 将前端应用配置域名 ]
[ 启动服务 ]
[ 如何配置多域名 ]
[ 小结 ]

将前端应用配置域名

在上一篇文章，我们已成功搭建了 traefik 网关。

回到我们的 create-react-app 部署示例，我们如何将此项目可使他们在互联网通过域名进行访问？

我们将它部署到 cra.shanyue.tech (opens new window)中作为示例。在此之前，我需要做两件事

cra.shanyue.tech 域名属于我个人。域名可自行在域名提供商进行购买。
cra.shanyue.tech 域名通过 A 记录指向搭建好 traefik 网关的服务器的 IP 地址。此处需要通过域名提供商的控制台进行配置。

启动服务

我们在容器中配置 labels 即可配置域名，启动容器域名即可生效。而无需像传统 nginx 方式需要手动去配置 proxy_pass。

而在 traefik，在 container labels 中配置 traefik.http.routers 可为不同的路由注册域名。

labels:
  - "traefik.http.routers.cra.rule=Host(`cra.shanyue.tech`)"

编辑 domain.docker-compose.yaml，配置文件如下。

PS: 该配置文件位于 [cra-deploy/domain.docker-compose.yaml(opens new window)]

version: "3"
services:
  domain:
    build:
      context: .
      dockerfile: router.Dockerfile
    labels:
      # 为 cra 配置我们的自定义域名
      - "traefik.http.routers.cra.rule=Host(`cra.shanyue.tech`)"
      # 设置 https，此时我们的 certresolver 为 le，与上篇文章配置保持一致
      - traefik.http.routers.cra.tls=true
      - traefik.http.routers.cra.tls.certresolver=le

networks:
  default:
    external:
      name: traefik_default

根据 docker-compose up 启动服务，此时可在互联网访问。

$ docker-compose -f domain.docker-compose.yaml up domain

访问 cra.shanyue.tech (opens new window)成功。

如何配置多域名

在 nginx 中可以通过 server_name (opens new window)配置多域名。

在 traefik 中通过 traefik.https.routers 可配置多域名。

cra.shanyue.tech
preview.cra.shanyue.tech
feature-a.cra.shanyue.tech

labels:
  - "traefik.http.routers.cra.rule=Host(`cra.shanyue.tech`)"
  - "traefik.http.routers.cra-preview.rule=Host(`preview.cra.shanyue.tech`)"
  - "traefik.http.routers.cra-feature-a.rule=Host(`feature-a.cra.shanyue.tech`)"

在我们启动 traefik 时，traefik 容器将 /var/run/docker.sock 挂载到容器当中。

通过 docker.sock 调用 Docker Engine API (opens new window)可将同一网络下所有容器信息列举出来。

# 列举出所有容器的标签信息
$ curl --unix-socket /var/run/docker.sock http:/containers/json | jq '.[] | .Labels'

小结

目前为止，终于将一个前端应用使用域名进行部署。此时除了一些部署知识外，还需要一些服务器资源，包括

一台拥有公网IP地址的服务器
一个自己申请的域名

当然，针对前端开发者而言，更重要的还是

如何使用 docker 将它跑起来
如何将它更快地跑起来
如何自动将它跑起来

下一篇文章内容便是 CICD 相关。

第十章：CICD简介与自动部署

[ CICD 工具与产品 ]
[ 基础概念与术语 ]
[ 基本功能介绍 ]
[ 分支的合并策略 (主分支保护规则) ]
[ 使用 CICD 进行自动部署 ]
[ 自建 Runner ]
[ 小结 ]

CICD 工具与产品

在前边的篇章中，我们在服务器中搭建了 Traefik 网关，并使用 docker-compose 部署前端并发布成功。

但前边的部署流程都是基于手动部署，那我们如何将部署进行自动化:

即每当我们将前端代码更新到仓库后，代码将会拉取仓库代码并自动部署到服务器。

这就是 CICD 要做的事情。

CI，Continuous Integration，持续集成。
CD，Continuous Deployment，持续部署。(或者 Continuous Delivery，持续交付)

CICD 与 git 集成在一起，可理解为服务器端的 git hooks: 当代码 push 到远程仓库后，借助 WebHooks 对当前代码在构建服务器(即 CI 服务器，也称作 Runner)中进行自动构建、测试及部署等。

为了方便理解，我们将上篇篇章中所指的服务器称为部署服务器，而 CI 中所指的服务器，称为构建服务器。

部署服务器: 对外提供服务的服务器，容器在该服务器中启动。
构建服务器: 进行CI构建的服务器，一般用以构建、测试和部署，构建镜像以及自动部署服务。一般也可以是 Docker 容器。

在以前的篇章中，相当于构建服务器和部署服务器为同一个服务器，而在工作中，二者往往为独立服务器。但是为了更好的 CICD，构建服务器会赋予控制部署服务集群的权限，在构建服务器中通过一条命令，即可将某个服务在部署服务器集群中进行管理。

在 CICD 中，构建服务器往往会做以下工作，这也是接下来几篇篇章的内容:

功能分支提交后，通过 CICD 进行自动化测试、语法检查、npm 库风险审计等前端质量保障工程，如未通过 CICD，则无法 Code Review，更无法合并到生产环境分支进行上线
功能分支提交后，通过 CICD 对当前分支代码构建独立镜像并生成独立的分支环境地址进行测试如对每一个功能分支生成一个可供测试的地址，一般是 <branch>.dev.shanyue.tech 此种地址
功能分支测试通过后，合并到主分支，自动构建镜像并部署到生成环境中 (一般生成环境需要手动触发、自动部署)

如下图，当所有 Checks 通过后，Merge pull request 才会变绿允许进行合并。

CI Checks

由于近些年来 CICD 的全面介入，项目开发的工作流就是 CICD 的工作流，请看一个比较完善的 CICD Workflow。

PS: 改图出自 Gitlab CICD Workflow(opens new window)

CI: 切出功能分支，进行新特性开发。此时为图中的 Verify、Package 阶段
CD: 合并功能分支，进行自动化部署。此时为图中的 Release 阶段。

CICD 工具与产品

国内公司一般以 gitlab CI 作为 CICD 工具，此时需要自建 Gitlab Runner 作为构建服务器。

如果你们公司没有 CICD 基础设置，但是个人对 CICD 有极大兴趣，那么可以尝试 github 免费的 CICD 服务: github actions (opens new window)。

基础概念与术语

每一家 CICD 产品，都有各自的配置方式，但是总体上用法差不多。我们了解下 CICD 的基本术语

Runner: 用来执行 CI/CD 的构建服务器
workflow/pipeline: CI/CD 的工作流。(在大部分 CI，如 Gitlab 中为 Pipeline，而 Github 中为 Workflow，但二者实际上还是略有不同)
job: 任务，比如构建，测试和部署。每个 workflow/pipeline 由多个 job 组成

在本系列专栏中，以 Github Actions 为主，并配有全部关于 Github Actions 的配置代码，并可成功运行，配置目录见 .github/workflows (opens new window)。以 Gitlab CI 为辅，并配有部分配置代码。

以下是关于 Github Actions 与 Gitlab CI 的配置文档，在以后篇章中可自行查阅。

基本功能介绍

在文首提到 CICD 的主要意义：

每当我们将前端代码更新到仓库后，代码将会拉取仓库代码并自动部署到服务器。

我们进行拆分成两个阶段，并在以下简单介绍如何对其进行配置

事件: push
命令: 前端部署

事件: on push

该 CI/CD 触发时的事件。如果需要上传代码自动部署的功能时，应该选择 on: push

on: push

更多 Github Actions Event 可以参考官方文档 Events that trigger workflows(opens new window)

# 仅仅当 master 代码发生变更时，用以自动化部署
on:
  push:
    branches:    
      - master

# 仅当 feature/** 分支发生变更时，进行 Preview 功能分支部署 (见 Preview 篇)
on:
  pull_request:
    types:
      # 当新建了一个 PR 时
      - opened
      # 当提交 PR 的分支，未合并前并拥有新的 Commit 时
      - synchronize
    branches:    
      - 'feature/**'

# 在每天凌晨 0:30 处理一些事情，比如清理多余的 OSS 资源，清理多余的功能分支 Preview (见 Preview 篇)
on:
  schedule:
    - cron:  '30 8 * * *'

命令: Job 与脚本

如，在 push 到最新代码时，使用 docker-compose up 进行部署。

name: push

on: [push]

jobs:
  test:
    # 将代码跑在 ubuntu 上
    runs-on: ubuntu-latest
    steps:
      # 切出代码，使用该 Action 将可以拉取最新代码
      - uses: actions/checkout@v2

      # 运行部署的脚本命令
      - run: docker-compose up -d

分支的合并策略 (主分支保护规则)

生产环境的代码必须通过 CI 检测才能上线，但这也需要我们进行手动设置。

一般而言，我们会设置以下策略加强代码的质量管理。

主分支禁止直接 PUSH 代码
代码都必须通过 PR 才能合并到主分支
分支必须 CI 成功才能合并到主分支
代码必须经过 Code Review (关于该 PR 下的所有 Review 必须解决)
代码必须两个人同意才能合并到主分支

在 Gitlab 与 Github 中均可进行设置:

如下示例，未通过 CI，不允许 Merge。可见示例 PR #22 (opens new window)。

使用 CICD 进行自动部署

终于到了最重要的内容了，如何使用 CICD 自动部署前端？

通过以前的篇章，我们了解到部署前端，仅仅需要在部署服务器执行一条命令即可 (简单环境下)

$ docker-compose up --build

以下是对于简单部署在个人服务器的一个 Github Actions 的案例，由于构建服务器无部署服务器管理集群应用的能力与权限 (kubernetes 拥有这种能力)。如果部署到服务器，只能简单粗暴地通过 ssh 进如服务器并拉取代码执行命令。

deploy:
  runs-on: ubuntu-latest
  steps:
    - |
      ssh root@shanyue.tech "
        # 假设该仓库位于 ~/Documents 目录
        cd ~/Documents/cra-deploy

        # 拉取最新代码
        get fetch origin master
        git reset --hard origin/master

        # 部署
        docker-compose up --build -d
      "

自建 Runner

在本次实践中，将构建服务器与部署服务器置于一起，则可以解决这个问题。在 Github Actions，可以在自有服务器中自建 Runner，文档如下。

Github Actions: Adding self hosted runners(opens new window)

此时部署仅仅需要一行 docker-compose up。

更详细关于自动部署的配置可见 cra-deploy/production.yaml(opens new window)

production:
  # 该 JOB 在自建 Runner 中进行运行
  runs-on: self-hosted
  steps:
    # 切出代码，使用该 Action 将可以拉取最新代码
    - uses: actions/checkout@v2
    - run: docker-compose up --build -d

而在真实的工作环境中，部署更为复杂，往往通过一些封装的命令来完成，分为三步:

构建镜像
推送镜像到自建的镜像仓库
将镜像仓库中的镜像拉取到部署服务器进行部署 (kubectl)

伪代码如下:

production:
  # 该 JOB 在自建 Runner 中进行运行
  runs-on: self-hosted
  steps:
    # 构建镜像
    - docker build -t cra-deploy-app .
    # 推送镜像
    - docker push cra-deploy-app
    # 拉取镜像并部署，deploy 为一个伪代码命令，在实际项目中可使用 helm、kubectl
    - deploy cra-deploy-app .

    # 或者通过 kubectl 进行部署
    # - kubectl apply -f app.yaml

    # 或者通过 helm 进行部署
    # - helm install cra-app cra-app-chart

小结

本篇文章介绍了 CICD 的基础概念，并通过自建 Runner 进行了简单部署。

在下一篇章，将会上手对 create-react-app 在 CICD 中进行前端质量保障。

前端应用域名配置&&CICD简介与自动部署

第九章：前端应用域名配置

将前端应用配置域名

启动服务

如何配置多域名

小结

第十章：CICD简介与自动部署

CICD 工具与产品

CICD 工具与产品

基础概念与术语

基本功能介绍

事件: on push

命令: Job 与脚本

分支的合并策略 (主分支保护规则)

使用 CICD 进行自动部署

自建 Runner

小结