前言
前端部署的方式有很多种，可以使用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: pullvariables $引用变量
可以使用如${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成功之后可以自动发消息给飞书测试人员；待补充
