淘宝客网站建设视频频频教程,开发者模式是干什么的,大石桥网站建设公司,铜陵市建设工程管理局网站长话短说经过长时间实操验证#xff0c;终于完成基于Gitlab的CI/CD实践#xff0c;本次实践的坑位很多#xff0c; 实操过程尽量接近最佳实践#xff08;不做hack, 不做骚操作#xff09;#xff0c;记录下来加深理解。看过博客园《docker-compose真香》一文的园友留意到… 长话短说经过长时间实操验证终于完成基于Gitlab的CI/CD实践本次实践的坑位很多 实操过程尽量接近最佳实践不做hack, 不做骚操作记录下来加深理解。看过博客园《docker-compose真香》一文的园友留意到文中[把部署dll文件拷贝到生产机器]现场打包成镜像并启动容器并没有完成CI/CD. P1Gitlab CI/CD原理和Gitlab Runner安装这里使用shell执行器 P2基于Docker-compose的Gitlab CI/CD 实践宏观业务架构图.gitlab-ci.yml文件项目部署文件Gitlab CI/CD部署准备Gitlab CI/CD原理Gitlab CI/CD 存储[构建]、[构建状态]的api应用程序, 提供友好的管理界面, 构建过程由 .gitlab-ci.yml文件定义该文件一般置于代码仓库的根目录Gitlab Runner 执行构建任务的应用程序可独立部署如上图所示其通过api与Gitlab Server交互搭建Gitlab CI/CD环境Gitlab CI/CD提供配置界面(项目菜单栏-设置-CI/CD),可指定 将要使用何种形式的Runner 配置Runner要用到环境变量界面配置权限取决于你在Gitlab Server的角色 https://docs.gitlab.com/ee/user/permissions.html本次手动设置特定Gitlab RunnerRunner安装完毕注册Runner(与Gitlab Projects实例建立绑定关系)注册时要关注的两个配置Tags 与此Runner相关的任务标签, 用于在共享Runner中区分不同的Project,.gitlab-ci.yml会用到Runner Executor 执行构建任务的方式这里使用shell方式Shell是最简单的配置执行器需要将构建所需的所有依赖项手动安装在安装了Runner的同一台计算机上。注册过程和结果请参考下图Gitlab CI/CD实践宏观业务架构图原则上不允许自动部署Prod本次使用Gitlab Runner服务器作为Gitlab CD的部署机器。Gitlab-CI Pipeline构建ReceiverAPP、webAPP镜像(附带本次git:tag)并推送到hub.docker.comGitlab-CD docker-compose拉取远端nginx、ReceiveAPP、webapp镜像启动容器。 Pipeline对每一次提交或合并都会执行build任务形成Continous IntergationPipeline对git: tag会触发build_Image任务成功之后构建deploy:staging任务这样就能形成基于gittag的部署版本管理(部署出错也能很快回滚到上次的部署tag).gitlab-ci.yml文件 以上Gitlab Pipeline定义build-build_image-deploy3个任务某些任务还包括不同分支Job,写.gitlab-ci.yml 的过程就是将以上执行动作脚本化。stages:- build- build_image- deployvariables:
# CI_DEBUG_TRACE: true deploy_path: /home/xxxx/eqidmanager # CI变量用于配置部署目录before_script:- docker infobuild:stage: buildscript: - for d in $(ls src);do echo $d;prog$(pwd)/src/$d/$d.csproj; dotnet build $prog; donetags: - another-tagbuild_image:EqidManager:stage: build_imagescript:- dotnet publish src/EqidManager/EqidManager.csproj -c release -o ../../container/app/publish/ - docker build --pull -t $CI_REGISTRY_USER/eqidmanager:$CI_COMMIT_REF_NAME container/app- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD - docker push $CI_REGISTRY_USER/eqidmanager:$CI_COMMIT_REF_NAME tags: - another-tagonly: #Pipeline Job构建策略代码仓库打tag会执行该任务 支持正则- tagsbuild_image:EqidReceiver:stage: build_imagescript:- dotnet publish src/EqidReceiver/EqidReceiver.csproj -c release -o ../../container/receiver/publish- docker build -t $CI_REGISTRY_USER/eqidreceiver:$CI_COMMIT_REF_NAME container/receiver- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD- docker push $CI_REGISTRY_USER/eqidreceiver:$CI_COMMIT_REF_NAMEtags: - my-tagonly:- tagsdeploy:staging:stage: deployscript:- cd $deploy_path- export TAG$CI_COMMIT_REF_NAME # 引入本次CI的gittag名称覆盖.env文件默认配置- docker-compose -f docker-compose.yml -f docker-compose.prod.yml build - docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d tags: - my-tagdeploy:prod:stage: deployscript:- # TODO 需要写脚本登陆到Prod机器上- export TAG$CI_COMMIT_REF_NAME - cd $deploy_path- docker-compose -f docker-compose.yml -f docker-compose.prod.yml build- docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d tags:- my-tagwhen: manual
这里有些知识点、坑位需要指出第8行预先定义的环境变量该变量定义gitlab CD的部署目录第16行: 对src开发目录下两个程序执行dotnet build命令第17行tags定义具备该tags的Runner可以执行该任务注意这里的tags必须是字符串数组第23-26行构建镜像并推送到镜像仓库的过程用到两类CI变量 - 密钥变量CI_REGISTRY_USER、CI_REGISTRY_PASSWORD可在Gitlab-CI界面配置 - 预定义变量CI_COMMIT_REF_NAME该变量标记构建项目的git:branch或git:tag名称用于生成Image:Tag注意变量可被重写重写优先级http://www.ttlsa.com/auto/gitlab-cicd-variables-zh-document/第29行only定义此Job只在产生git:tag时被触发与上面我们使用CI-COMMIT_REF_NAME 变量相呼应第47行Gialab-CI pipeline每个Job会重新拉取git源码执行Job任务(可登录到Gitlab Runner工作目录下观察Runner执行过程)CD时需要选择合适目录这是deploy_staging上使用deploy_path CI变量的原因第48行注入本次Gitlab-CI git:tag名称实际上是覆盖了.env同名环境变量第49行若存在docker-compose.yml、docker-compose.override.yml 两个文件docker-compose命令会自动merge这2个文件(使用docker-compose config命令查看merge之后的结果)。第64行前置任务未出错会自动执行后继任务而when指令定义该任务需要界面上手动执行 部署目录 在Gitlab Runner服务器的{deploy_path}路径下建立了如下部署文件├── appsettings.secrets.json
├── docker-compose.prod.yml
├── docker-compose.yml
├── .env
├── EqidManager.db
├── nginx
│ ├── Dockerfile
│ └── nginx.conf
└── receiver.secrets.json
部署目录定义docker-compose.yml、docker-compose.prod.yml 两个yml文件前者定义常规容器服务后者定义适用于本部署环境的附加服务密钥文件不要进入代码管理因此我们定义appsetting.secrets.json 和 receiver.secrets.json密钥文件由dccker-compose.yml挂载进入容器env文件存储相对固定且与本次docker-compose命令相关的环境变量docker-compose命令默认寻找同级目录下.env文件------.env 文件----
TAGmaster # 该TAG变量会在Pipelinedeploy_staging任务中被覆盖形成基于git:tag的imageName:tag
docker_host172.16.1.1
COMPOSE_PROJECT_NAMEEqidManager
DOCKER_REGISTRY***
Project打上git:tag之后触发Gitlab Runner CI/CD Pipeline: 跳转到部署目录-应用本次git:tag-执行docker-compose命令拉取指定tag镜像并启动容器。Thatall, 本次应用Gitlab Runner(shell执行器)实践CI/CD, Gitlab菜单界面有所有构建构成的日志(便于排查构建问题)另外上文对于关键知识均附带传送门可进一步对比研究。 https://www.cnblogs.com/JulianHuang/p/10919346.html https://docs.gitlab.com/runner/register/index.html https://docs.gitlab.com/runner/executors/README.html往期精选 实例解读Docker Swarmdocker stack,docker-compose前世今生据说点赞的朋友2020都加薪了
