最专业的做音乐网站,编程做网站,app源码开发公司,设计网页代码源代码引言看过docker-compose真香的园友可能留意到当时是【把部署dll文件拷贝到生产机器】#xff0c;即时打包成镜像并启动容器#xff0c;并没有完成CI/CD。经过长时间实操验证#xff0c;终于完成基于Gitlab的CI/CD实践#xff0c;本次实践的坑位很多#xff0c; 实操过程尽… 引言 看过docker-compose真香的园友可能留意到当时是【把部署dll文件拷贝到生产机器】即时打包成镜像并启动容器并没有完成CI/CD。 经过长时间实操验证终于完成基于Gitlab的CI/CD实践本次实践的坑位很多 实操过程尽量接近最佳实践不做hack, 不做骚操作记录下来加深理解。 第一部分Gitlab CI/CD 原理 和 Gitlab Runner 安装这里使用shell执行器 第二部分Gitlab CI/CD 实践 宏观项目架构图 .gitlab-ci.yml 文件 项目部署目录第一部分gitlab CICD原理 ① Gitlab CI/CD架构Gitlab CI/CD 存储【构建】和【构建状态】的api应用程序 提供友好的管理界面, 构建过程由 .gitlab-ci.yml文件定义而这个文件一般置于代码仓库的根目录。Gitlab Runner 执行构建过程的应用程序可与Gitlab Server 形成分布式部署 如上图所示 其通过api 与Gitlab Server交互 ② Gitlab CI/CD 配置界面 Gitlab Runner 安装 Gitlab CICD的界面配置权限取决于你在Gitlab Server 中的角色我的角色是maintainer 足够创建自定义的runner。 本次演示【自定义Runner】gitlab runner安装------ gitlab runner注册 (与Gitlab Project建立联系的过程) 注册时需要关注的两个配置是 tags 可理解为与这个Runner有关的Pipeline任务 在.gitlab-ci.yml用到 runner executor可理解为执行的初始环境这里使用shell方式 注册过程和结果请参考下图 第二部分基于docker-compose的Gitlab-CI 实践 ① 项目架构图 Gitlab-CI Pipeline构建ReceiverAPP, webAPP镜像附带本次git:tag并推送到hub.docker.com Gitlab-CD docker-compose拉取远端nginx、ReceiveAPP、webapp镜像启动容器。 Pipeline对每一次提交或合并都会执行build任务 形成Continous Intergation Pipeline对git: tag会执行build_Image任务自动构建至deploy_staging任务这样就能形成基于gittag的部署版本管理部署出错也能很快回滚到上次的部署tag本处使用Gitlab Runner 服务器作为staging部署机器原则上不允许自动随意部署Prod实践中登陆到 Prod机器上执行部署命令以下GitLab-CD也没有完成Prod的自动部署过程自行补上登陆终端的脚本即可 ③ .gitlab-ci.yml 文件 对比架构Gitlab Pipeline定义了 build--build_image--deploy 三个任务 某些任务还包括不同分支Job写.gitlab-ci.yml 的过程就是以上执行动作脚本化。 更多Gitlab-CI的资料 1 stages:2 - build3 - build_image4 - deploy5 6 variables: 7 #CI_DEBUG_TRACE: true # 增加调试追踪8 deploy_path: /home/xxxx/eqidmanager9 10 before_script:11 - docker info12 13 build:14 stage: build15 script:16 - for d in $(ls src);do echo $d;prog$(pwd)/src/$d/$d.csproj; dotnet build $prog; done17 tags:18 - another-tag19 20build_image:EqidManager:21stage: build_image22script:23 - dotnet publish src/EqidManager/EqidManager.csproj -c release -o ../../container/app/publish/24 - docker build --pull -t $CI_REGISTRY_USER/eqidmanager:$CI_COMMIT_REF_NAME container/app25 - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD26 - docker push $CI_REGISTRY_USER/eqidmanager:$CI_COMMIT_REF_NAME27tags:28 - another-tag29 only: # Pipeline Job构建策略30 -tags31 32build_image:EqidReceiver:33stage: build_image34script:35 - dotnet publish src/EqidReceiver/EqidReceiver.csproj -c release -o ../../container/receiver/publish36 - docker build -t $CI_REGISTRY_USER/eqidreceiver:$CI_COMMIT_REF_NAME container/receiver37 - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD38 - docker push $CI_REGISTRY_USER/eqidreceiver:$CI_COMMIT_REF_NAME39tags:40 - my-tag41only:42 -tags43 44deploy:staging:45stage: deploy46script:47 -cd $deploy_path48 - export TAG$CI_COMMIT_REF_NAME # 引入本次CI的gittag名称覆盖.env 文件默认配置49 - docker-compose build # 根据docker-compose命令用法, 会自动merge docker-compose.yml和override文件50 - docker-compose up -d 51tags:52 - my-tag53 54deploy:prod:55stage: deploy56script:57 -# TODO 需要写脚本登陆到Prod机器上58 - export TAG$CI_COMMIT_REF_NAME59 -cd $deploy_path60 - docker-compose build61 - docker-compose up -d 62tags:63 - my-tag64 when: 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名称用于生成镜像tag 注意变量可被重写重写有优先级 http://www.ttlsa.com/auto/gitlab-cicd-variables-zh-docum ent/第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 之后的结果)。 ③ Continous Deploy 在Gitlab Runner服务器的{deploy_path}路径下建立了如下部署文件├── appsettings.secrets.json├── docker-compose.override.yml├── docker-compose.yml├── .env├── EqidManager.db├── nginx│ ├── Dockerfile│ └── nginx.conf└── receiver.secrets.json最佳实践定义docker-compose.yml、docker-compose.override.yml 两个yml文件前者定义相对易变的容器服务后者定义基础容器服务docker-compose 命令在执行时会自动merge软件工作有种最佳实践 密钥文件不要进入代码管理因此我们定义appsetting.secrets.json 和 receiver.secrets.json密钥文件又dccker-compose.yml挂载进入容器.env文件存储相对固定、与本次docker-compose命令相关的环境变量dockee-compose命令默认可寻找同级目录下的.env文件----- .env 文件----TAGmaster # 该TAG变量会在Pipelinedeploy_staging任务中被覆盖形成基本git:tag的imageName:tagdocker_host172.16.1.1COMPOSE_PROJECT_NAMEEqidManagerDOCKER_REGISTRY*** 依据.gitlab-ci.yml 文件定义的 deploy_staging脚本 跳转到部署目录----应用本次Gitlab-CD要用的git : tag---- 执行docker-compose 命令拉取指定tag镜像并启动容器。原文链接https://www.cnblogs.com/JulianHuang/p/11346615.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
