docker镜像部署前端项目 CI/CD

前言

前端部署的方式有很多种，可以使用docker镜像，可以使用阿里云css部署，也可以使用apex部署，以及使用其他华为云的obs部署；我使用的是docker镜像；

先说一下部署流程
在无容器的情况下：我们会生成dist文件夹之后，把它压缩，然后通过scp发布到远程服务器上；
在有容器的情况下：我们会生成dist文件，通过dockerfile生成本地镜像，然后推送到远程仓库上；
使用容器的优点就在于： 我在一个服务器上部署前端项目之后，假设我另一个服务器也想要部署这个前端项目，我执行docker pull 镜像就可；

顺便补充一下我自己对镜像的理解【防止日后忘记haha】
在服务器上容器就相当于虚拟机；可以有多个虚拟机；
多个容器可以依赖一个镜像启动；

runner是gitlab负责cicd的服务；
我们想要在gitlab上跑cicd就需要注册runner；需要在服务器上安装runner服务，注册到gitlab仓库上【设置- CI/CD下】，runner有很多模式shell、docker等；

gitlab.yml编写

使用docker模式的时候，一个stage生成一个容器【依赖于gitlab.yml的image定义的镜像 启动】，运行之后就被删掉；这里我们使用的docker in docker 模式【容器里面使用了docker命令，默认是不可以使用docker命令的】；
先来讲讲gitlab.yml的常用参数吧
参考视频

参数	含义
image	指定基础运行环境的docker镜像
stages	YML中的数组写法 stages定义在YML文件的最外层，它的值是一个数组，用于定义一个pipeline不同的流程节点
cache	重复运行pipeline的时候不会重复安装 1在不同pipeline之间重用资源 2在同一pipeline的不同Job之间重用资源
variables	定义全局变量
stage	是一个字符串，且是stages数组的一个子项，表示的是当前的pipeline节点。
script	当前pipeline节点运行的shell脚本（以项目根目录为上下文执行）
tags	当前Job的标记 这个关键字是很重要，因为gitlab的runner会通过tags去判断能否执行当前这个Job，我们在gitlab的面板中能看到当前激活的runner的信息Gitlab项目首页=> setting => CI/CD => Runners. 如果一个Job没有tag或者tag不是sss,那么即使这个Runner是激活且空闲的，也不会去执行！
only	指定当前Job仅仅只在某些tag或者branch上触发
refs	基于分支名称或者pipeline类型运行
paths	哪个文件或目录
policy	更改缓存操作 开始时下载缓存pull 结束时上传更改push，默认是pull-push
artifacts	将生成的资源作为pipeline运行成功的附件上传，并在gitlab交互界面上提供下载
except	排除某些分支和某些tag
expire_in	过期时间
environment	job部署到哪个环境
when	什么时候运行作业
policy	更改缓存操作 开始时下载缓存pull 结束时上传更改push，默认是pull-push

使用 **&**符号可以定义一个片段的别名
使用 **<<**符号和 ** * ** 符号可以将别名对应的YML片段导入

属性额外说明

参考文档

stages

定义流水线全局阶段，默认有3个阶段，build、test、deploy。如果作业未定义stage阶段，默认使用test阶段

when

用于实现在作业失败时或发生故障时运行的作业，可以设置下面几个值

• on_success ：只有前面的阶段的所有作业都成功时才执行，这是默认值。
• on_failure ：当前面阶段的作业至少有一个失败时才执行
• always : 无论前面的作业是否成功，一直执行本作业。
• manual ：手动执行作业，作业不会自动执行，需要人工手动点击启动作业。
• delayed : 延迟执行作业，配合 start_in 关键字一起作用， start_in 设置的值必须小于或等于1小时，start_in 设置的值示例： 10 seconds 、 30 minutes 、 1 hour ，前面的作业结束时计时器马上开始计时。

.符号

对于不想执行的job，可以在前面加“.”符号表示跳过

.job_tmpl_cache: &job_tmpl_cache     # 用”&”【别名】符号和"<<:*”【引入】符号共同可以实现的片段导入的功能
  cache:
    paths: &cache_paths
      - node_modules
    policy: pull

variables $引用变量

可以使用如${DATABASE_URL}来引用定义的变量

only 和 except

only 和 except 中可以使用特殊的关键字，如 branches 、 tags 、 api 、 external 、 pipelines 、 pushes 、 schedules 、 triggers 、 web 、 merge_requests 、 chats 等

关键字	描述
branches	当一个分支被push上来
tags	当一个打了tag标记的Release被提交时
api	当一个pipline被第二个piplines api所触发调起(不是触发器api
external	当使用了GitLab以外的外部CI服务，如Jenkins
pipelines	针对多项目触发器而言，当使用CLJOB_TOKEN，并使用gitlab所提供的api创建多个pipelines的时候
pushes	当pipeline被用户的git push操作所触发的时候
schedules	针对预定好的piplinet划而言（每日构建一类）
triggers	用触发器token创建 piplines的时候
web	在GitLab WEB页面上Pipelines 标签页下，按下run pipline的时候
merge_requests	当合并请求创建或更新的时候
chats	当使用GitLab Chatops 创建作业的时候

only 和 except 支持高级策略，refs 、 variables 、 changes 、 kubernetes 四个关键字可以使用

CI预定义变量

image: xxx

# 定义全局变量
variables:
  IMAGE: xxxxx:$CI_COMMIT_SHORT_SHA

stages:
  - install
  - lint-code
  - docker_build_push
  - deploy

cache: # 缓存
  paths:
    - node_modules

install:
  stage: install
  script:
    - npm install
  only:
    refs:
      - merge_requests
    changes:
      - package.json
      - package-lock.json

lint:
  stage: lint-code
  script:
    - NODE_ENV=production npm run lint -- --no-fix
  only:
    - merge_requests

docker_build_push:
  stage: docker_build_push
  image: xxxx
  tags:
    - deploy
  script:
  	# docker build搭建容器 -t就是tag 指定镜像名称 .代表DockerDFile的目录在那里
    - docker build -t $IMAGE .
    - docker push $IMAGE
  only:
    - master
    # 方便自己在ci分支测试流程
    - ci
deploy:
  stage: deploy
  image: xxxx
  tags:
    - deploy
  variables:
    DOCKER_NAME: ants_dev-web-e6687f5f630251632763d31150ae8578
  script:
    #  把上次的容器删除掉 然后在重新创建
    - docker rm -f $DOCKER_NAME
    # -v 挂载 --name起别名 --net指定网络模式 -d 后台运行
    - docker run --name=$DOCKER_NAME -v /opt/system_dir/ants_dev/ants/files:/usr/share/nginx/files --net=container:ants_dev-pause-e6687f5f630251632763d31150ae8578 -d $IMAGE
  only:
    - master
    - ci

因为公司内部使用的是飞书平台，所以希望deploy成功之后可以自动发消息给飞书测试人员；待补充