gitlab-cicd 快来打我* 2022-09-05 15:44 281阅读 0赞 ### 文章目录 ### * * * 安装gitlab * * 安装包方式安装 * docker方式部署gitlab-ce * 修改默认的管理员密码 * doceker方式部署docker-runner * docker-runner注册到gitlab * 注册命令解释 * gitlab-runner的执行器 * 命令解释（help为主 man手册有待补充） * * gitlab-runner的命令解释 * gitlab-ctl的命令解释 * gitlab-backup * gitlab-psql * gitlab-rails * gitlab-rake * gitlab的config * gitlab-runner的config * gitlab-ci的理论 * * gitlab-ci的工作流程 * gitlab-ci的工作原理 * gitalb-ci的工作流程图 * gitlab-runner简介 * gitlab-runner的特点 * gitlab-runner类型与状态 * job的运行流程 * .gitlab-ci.yml的编写语法 * * pipeline语法1 * pipeline语法2 * pipeline语法3 * pipeline语法4 * pipeline语法5 * 总结->.gitlab-ci.yml文件中共有27个关键词 * 问题记录 * 补充 CI概念以及CI常规流程 * gitlab-ci的工具链集成 ### 安装gitlab ### #### 安装包方式安装 #### 修改配置后的初始化 gitlab-ctl reconfigure 启动 sudo gitlab-ctl start 停止 sudo gitlab-ctl stop 重启 sudo gitlab-ctl restart 开机启动 systemctl enable gitlab-runsvdir.service 禁止开机自启动 systemctl disable gitlab-runsvdir.service #### docker方式部署gitlab-ce #### sudo docker run --detach \ --hostname 10.0.0.6 \ --publish 443:443 --publish 80:80 --publish 222:22 \ --name gitlab \ --restart always \ --volume /srv/gitlab/config:/etc/gitlab \ --volume /srv/gitlab/logs:/var/log/gitlab \ --volume /srv/gitlab/data:/var/opt/gitlab \ gitlab/gitlab-ce:latest #### 修改默认的管理员密码 #### 默认用户名密码： root 除非您在安装过程中提供了自定义密码，否则将随机生成一个密码并在/etc/gitlab/initial_root_password. 使用此密码和用户名root登录 docker exec -it gitlab bash gitlab-rails console user = User.where(id: 1).first user.password = '12345678' user.password_confirmation = '12345678' user.save! 用户名：admin@example.com 密码：12345678 #### doceker方式部署docker-runner #### sudo docker run -d --name gitlab-runner --restart always \ -v /srv/gitlab-runner/config:/etc/gitlab-runner \ -v /var/run/docker.sock:/var/run/docker.sock \ gitlab/gitlab-runner:latest #### docker-runner注册到gitlab #### docker run --rm -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register \ --non-interactive \ --executor "docker" \ --docker-image python:latest \ --url "http://10.0.0.6/" \ --registration-token "Sui6mVh96k2HXzJAhcGW" \ --tag-list "docker" \ --run-untagged="true" \ --locked="false" \ --access-level="not_protected" #### 注册命令解释 #### docker run --rm -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register \ --non-interactive \ --executor "docker" \ 执行方式 docker （docker\shell\k8s） --docker-image alpine:latest \ 指定docker使用的基础镜像 --url "http://10.0.0.6/" \ gitlab的url地址 --registration-token "Sui6mVh96k2HXzJAhcGW" \ token值 --tag-list "test-cicd2,docker-cicd2" \ 标签 --run-untagged="true" \ 是否运行没有标签的任务 --locked="false" \ 是否为锁定状态 --access-level="not_protected" 运行级别 #### gitlab-runner的执行器 #### shell docker K8S 完整版如下图： 对支持的执行器功能进行了对比 ✗ 为不支持 ✓ 为支持 <table> <thead> <tr> <th>Executor</th> <th>SSH</th> <th>Shell</th> <th>VirtualBox</th> <th>Parallels</th> <th>Docker</th> <th>Kubernetes</th> <th>Custom</th> </tr> </thead> <tbody> <tr> <td>Clean build environment for every build</td> <td>✗</td> <td>✗</td> <td>✓</td> <td>✓</td> <td>✓</td> <td>✓</td> <td>conditional (4)</td> </tr> <tr> <td>Reuse previous clone if it exists</td> <td>✓</td> <td>✓</td> <td>✗</td> <td>✗</td> <td>✓</td> <td>✗</td> <td>conditional (4)</td> </tr> <tr> <td>Runner file system access protected (5)</td> <td>✓</td> <td>✗</td> <td>✓</td> <td>✓</td> <td>✓</td> <td>✓</td> <td>conditional</td> </tr> <tr> <td>Migrate runner machine</td> <td>✗</td> <td>✗</td> <td>partial</td> <td>partial</td> <td>✓</td> <td>✓</td> <td>✓</td> </tr> <tr> <td>Zero-configuration support for concurrent builds</td> <td>✗</td> <td>✗ (1)</td> <td>✓</td> <td>✓</td> <td>✓</td> <td>✓</td> <td>conditional (4)</td> </tr> <tr> <td>Complicated build environments</td> <td>✗</td> <td>✗ (2)</td> <td>✓ (3)</td> <td>✓ (3)</td> <td>✓</td> <td>✓</td> <td>✓</td> </tr> <tr> <td>Debugging build problems</td> <td>easy</td> <td>easy</td> <td>hard</td> <td>hard</td> <td>medium</td> <td>medium</td> <td>medium</td> </tr> </tbody> </table> ### 命令解释（help为主 man手册有待补充） ### #### gitlab-runner的命令解释 #### gitlab-runner exec 在本地执行构建 list 此命令列出了保存在配置文件中的所有运行程序 run 运行多程序服务 register 默认交互模式下使用，非交互模式添加--non-interactive install 下载服务 uninstall 卸载服务 start 启动服务 stop 停止服务 restart 重新启动服务 status 获取服务的状态 run-single 单程起跑 unregister 使用令牌注销 gitlab-runner unregister --ur http://10.0.0.6/ --token xxxx gitlab-runner unregister --name test-runner 使用名称注销 gitlab-runner unregister --all-runners 注销所有 verify 此命令检查注册的runner是否可以连接，但不验证gitlab服务是否正在使用runner。 --delete 删除 artifacts-downloader 下载并提取构建工件 artifacts-uploader 创建和上传构建工件 cache-archiver 创建和上载缓存工件 cache-extractor 下载并提取缓存工件（内部） cache-init 已更改缓存路径的权限（内部） health-check 检查特定地址的运行状况 read-logs 从kubernetes执行器使用的文件读取作业日志 help, h gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner #--user 指定将用于执行构建的用户 #--working-directory 指定将使用shell executor 运行构建时所有数据都将存储在其中的根目录 gitlab-runner uninstall #该命令停止运行并从服务中卸载gitlab runner gitlab-runer start #该命令启动gitlab-runner服务 gitlab-runer stop #停止gitlab-runner服务 gitlab-runer restart #重启gitlab-runner服务 gitlab-runer status #此命令显示gitlab-runner服务。当服务正在运行时，退出代码为0；当服务未运行时，退出代码未非零。 #### gitlab-ctl的命令解释 #### omnibus-ctl: command (subcommand) check-config 检查gitlab.rb中是否有在指定版本中删除的任何配置 deploy-page 打开部署页面 diff-config 将用户配置与软件包可用配置进行比较 prometheus-upgrade 将Prometheus数据升级至受支持的最新版本 remove-accounts 删除此包使用的*所有*用户和组 reset-grafana 通过删除数据目录将Grafana实例重置为其初始状态 set-grafana-password 重置Grafana的管理员密码 upgrade 在包升级后运行迁移 General Commands: cleanse 删除*所有*gitlab数据，从头开始。 help Print this help message. reconfigure 重新配置应用程序。 show-config 显示重新配置将生成的配置。 uninstall 终止所有进程并卸载进程管理器（数据将被保留）。 Service Management Commands: graceful-kill 尝试优雅的停止，然后关闭整个进程组。 hup 发送服务一个HUP。 int 向服务发送一个INT。 kill 发送服务一个杀手锏。 once 如果服务关闭，请启动服务。如果它们停止，请不要重新启动它们。 restart 如果服务正在运行，请停止服务，然后重新启动它们。 service-list 列出所有服务（启用的服务显示为*） start Start services if they are down, and restart them if they stop. status 显示所有服务的状态。 stop 停止服务，不要重新启动它们。 tail 查看所有已启用服务的服务日志。 term 发送服务一个期限。 usr1 将服务发送到USR1。 usr2 将服务发送到USR2。 Backup Commands: backup-etc 备份GitLab配置[接受目录路径] Let's Encrypt Commands: renew-le-certs 续订现有证书让我们加密证书 Database Commands: pg-password-md5 以PostgreSQL格式生成用户密码的MD5哈希 pg-upgrade 将PostgreSQL数据库升级至受支持的最新版本 revert-pg-upgrade 运行此操作以还原到数据库的早期版本 set-replication-password 设置数据库复制密码 Container Registry Commands: registry-garbage-collect #### gitlab-backup #### Usage: gitlab-backup COMMAND [OPTIONS] OPTIONS: -h, --help Display this help message and exits. Use `COMMAND --help` for more information on a command. COMMANDS: create 创建新备份。 restore 从备份中恢复 #### gitlab-psql #### psql is the PostgreSQL interactive terminal. Usage: psql [OPTION]... [DBNAME [USERNAME]] General options: -c, --command=COMMAND 仅运行单个命令（SQL或内部）并退出 -d, --dbname=DBNAME 要连接到的数据库名称（默认值：“gitlab psql”） -f, --file=FILENAME 从文件中执行命令，然后退出 -l, --list 列出可用的数据库，然后退出 -v, --set=, --variable=NAME=VALUE 将psql变量名设置为VALUE (e.g., -v ON_ERROR_STOP=1) -V, --version 输出版本信息，然后退出 -X, --no-psqlrc 不读取启动文件（~/.psqlrc） -1（“一”），--单笔交易 作为单个事务执行（如果非交互式） -?, --help[=options] show this help, then exit --help=commands 列出反斜杠命令，然后退出 --help=variables 列出特殊变量，然后退出 Input and output options: -a, --echo-all 从脚本回显所有输入 -b, --echo-errors 回显失败的命令 -e, --echo-queries 发送到服务器的回显命令 -E, --echo-hidden 显示内部命令生成的查询 -L, --log-file=FILENAME 将会话日志发送到文件 -n, --no-readline 禁用增强的命令行编辑（readline） -o, --output=FILENAME 将查询结果发送到文件（或|管道） -q, --quiet 安静运行（无消息，仅查询输出） -s, --single-step 单步模式（确认每个查询） -S, --single-line 单行模式（行尾终止SQL命令） Output format options: -A, --no-align 未对齐表输出模式 -F, --field-separator=STRING 未对齐输出的字段分隔符（默认值：“|”） -H, --html HTML表格输出模式 -P, --pset=VAR[=ARG] 将打印选项VAR设置为ARG（请参阅\pset命令） -R, --record-separator=STRING 未对齐输出的记录分隔符（默认值：换行符） -t, --tuples-only 仅打印行 -T, --table-attr=TEXT 设置HTML表格标记属性（例如，宽度、边框） -x, --expanded 打开扩展表输出 -z, --field-separator-zero 将未对齐输出的字段分隔符设置为零字节 -0, --record-separator-zero 将未对齐输出的记录分隔符设置为零字节 Connection options: -h, --host=HOSTNAME 数据库服务器主机或套接字目录（默认值：“本地套接字”） -p, --port=PORT 数据库服务器端口（默认值：“5432”） -U, --username=USERNAME 数据库用户名（默认值：“gitlab psql”） -w, --no-password 从不提示输入密码 -W, --password 强制密码提示（应自动发生） For more information, type "\?" (for internal commands) or "\help" (for SQL commands) from within psql, or consult the psql section in the PostgreSQL documentation. Report bugs to <pgsql-bugs@postgresql.org>. #### gitlab-rails #### The most common rails commands are: generate 生成新代码（简写别名：“g”） console 启动Rails控制台（快捷别名：“c”） server 启动Rails服务器（快捷别名：“s”） test 运行系统测试以外的测试（简写别名：“t”） test:system 运行系统测试 dbconsole 为config/database.yml中指定的数据库启动控制台 (short-cut alias: "db") new 创建一个新的Rails应用程序。”rails new my_应用程序“创建一个 “/my_应用程序”中名为MyApp的新应用程序 #### gitlab-rake #### rake [-f rakefile] { options} targets... Options are ... --backtrace=[OUT] 启用完全回溯。OUT可以是stderr（默认值）或stdout。 --comments 仅显示已评论的任务 --job-stats [LEVEL] 显示作业统计信息。级别=历史记录显示完整的作业列表 --rules 跟踪规则解决方案。 --suppress-backtrace PATTERN 抑制与regexp模式匹配的回溯线。如果--trace打开，则忽略。 -A, --all 显示所有任务，即使是未注释的任务（与-T或-D组合使用） -B, --build-all 构建所有先决条件，包括最新的先决条件。 -D, --describe [PATTERN] 描述任务（匹配可选模式），然后退出。 -e, --execute CODE 执行一些Ruby代码并退出。 -E, --execute-continue CODE 执行一些Ruby代码，然后继续正常的任务处理。 -f, --rakefile [FILENAME] 使用FILENAME作为要搜索的rakefile。 -G, --no-system, --nosystem 使用标准项目Rakefile搜索路径，忽略系统范围的Rakefile。 -g, --system 使用系统范围（全局）rakefile（通常为“~/.rake/*.rake”）。 -I, --libdir LIBDIR 在所需模块的搜索路径中包括LIBDIR。 -j, --jobs [NUMBER] 指定并行执行的最大任务数(默认值为CPU核心数+4） -m, --multitask 将所有任务视为多任务。 -n, --dry-run 在不执行操作的情况下进行试运行。 -N, --no-search, --nosearch 不要在父目录中搜索Rakefile。 -P, --prereqs 显示任务和依赖项，然后退出。 -p, --execute-print CODE 执行一些Ruby代码，打印结果，然后退出。 -q, --quiet 不要将消息记录到标准输出 -r, --require MODULE 在执行rakefile之前需要模块。 -R, --rakelibdir RAKELIBDIR, 自动导入RAKELIBDIR中的任何.rake文件(默认值为“rakelib”） --rakelib -s, --silent 比如--quiet，但也会抑制“目录中”公告。 -t, --trace=[OUT] 启用调用/执行跟踪，启用完全回溯跟踪。OUT可以是stderr（默认值）或stdout。 -T, --tasks [PATTERN] 显示带有描述的任务（匹配可选模式），然后退出-AT组合显示不包含任何说明的所有任务。 -v, --verbose 将消息记录到标准输出。 -V, --version Display the program version. -W, --where [PATTERN] 描述任务（匹配可选模式），然后退出。 -X, --no-deprecation-warnings 禁用弃用警告 #### gitlab的config #### 文件名gitlab.rb 实在太长详细另一文件<gitlab配置文件-gitlab.rb详解> #### gitlab-runner的config #### 文件名config.toml 官方解释链接<https://docs.gitlab.com/runner/configuration/advanced-configuration.html> 配置默认在/etc/gitlab-runner/config.toml,配置文件更改时不需要重启服务，每隔三秒gitlab runner会检查配置修改并重新加载。 [全局配置] concurrent 限制可以同时运行的作业数量 log_level 日志级别 log_format 日志格式 check_interval 检查作业的间隔长度，默认为3秒 sentry_dsn 启用Sentry错误跟踪 listen_address http服务监听地址 [session_server] listen_address 会话服务器的内部URL advertise_address 访问会话服务器URL session_timeout 作业完成后会话可以保持活动状态的秒数，默认值为1800秒 [runners] name 描述 url GitLab 实例 URL token runner的的特殊令牌（不是注册令牌） tls-ca-file 使用 HTTPS 时验证对等方的证书的文件 tls-cert-file 使用 HTTPS 时与对等方进行身份验证的证书的文件 tls-key-file 使用 HTTPS 时要与对等方进行身份验证的私钥的文件 limit 限制同时处理作业数量，0（默认）表示不限制 executor 选择应如何构建项目 shell 生成脚本的 shell 的名称，默认值取决于平台。 builds_dir 构建存储在所选执行程序上下文中的目录的绝对路径。例如，本地、Docker 或 SSH cache_dir 构建缓存存储在所选执行程序上下文中的目录的绝对路径。例如，本地、Docker 或 SSH。如果使用dockerexecutor，则需要在其volumes参数中包含该目录 environment 追加或覆盖环境变量。 request_concurrency 限制来自 GitLab 的新作业的并发请求数，默认为1 output_limit 最大构建日志大小，默认值为4096(4MB) pre_clone_script 在克隆 Git 存储库之前执行的命令 pre_build_script 在克隆 Git 存储库之后但在执行构建之前执行的命令 post_build_script 在执行构建之后执行的命令 clone_url 覆盖 GitLab 实例的 URL debug_trace_disabled 禁用CI_DEBUG_TRACE特性。当设置为true时，即使用户将CI_DEBUG_TRACE设置为true，调试日志(跟踪)也将保持禁用状态 referees 额外的工作，将结果作为工作工件传递给 GitLab [executors] shell 默认执行器 docker docker容器 docker-windows Windows的docker容器 docker-ssh docker容器 使用ssh连接 ssh 远程ssh parallels Parallels VM，使用 SSH 连接 virtualbox VirtualBox VM，但使用 SSH 连接 docker+machine 类似docker，但使用自动缩放的 Docker 机器 docker+ssh+machine 类似docker-ssh，但使用自动缩放的 Docker 机器 kubernetes Kubernetes pods [runners.docker] allowed_images 可以在.gitlab-ci.yml文件中指定的镜像的通配符列表；如果不存在，则允许所有镜像（相当于["/:*"]） allowed_services 可以在.gitlab-ci.yml文件中指定的服务的通配符列表；如果不存在，则允许所有镜像（相当于["/:*"]） cache_dir 缓存目录，此路径可以是绝对路径，也可以是路径 cap_add 向容器添加额外的 Linux 功能 cap_drop 从容器中删除其他 Linux 功能 cpuset_cpus 对照组的CpusetCpus cpu_shares 用于设置相对 CPU 使用率的 CPU 份额数，默认为1024 cpus CPU数量（在 Docker 1.13 或更高版本中可用） devices 与容器共享其他主机设备 disable_cache 执行器有两个级别的缓存：全局缓存和基于 Docker 卷的本地缓存，此配置标志仅作用于禁用自动创建（未映射到主机目录）缓存卷的本地配置标志 disable_entrypoint_overwrite 禁用镜像覆盖entrypoint dns 供容器使用的 DNS 服务器列表 dns_search DNS 搜索域列表 extra_hosts 应该在容器环境中定义的主机 gpus Docker容器的GPU设备使用与dockercli相同的格式查看Docker 文档中的详细信息 helper_image （高级）用于克隆存储库和上传工件的默认帮助程序镜像 helper_image_flavor 设置辅助镜像风格（alpine或ubuntu）默认为alpine. host 自定义 Docker 端点默认为DOCKER_HOST环境或unix:///var/run/docker.sock. hostname Docker 容器的自定义主机名 image 用于运行作业的镜像 links 应与运行作业的容器链接的容器 memory 内存限制 memory_swap 总内存限制 memory_reservation 内存软限制 network_mode 将容器添加到自定义网络 oom_kill_disable 如果发生内存不足 (OOM) 错误，不终止容器中的进程 oom_score_adjust OOM分数调整 privileged 使容器以特权模式运行 pull_policy 镜像拉取策略：never，if-not-present或always（默认）查看拉取策略文档中的详细信息您还可以添加多个拉取策略 runtime Docker 容器的运行时 security_opt 安全选项（–security-opt in docker run）获取:分隔键/值的列表 shm_size 镜像的共享内存大小（以字节为单位） sysctls sysctl选项 tls_cert_path存储 ca.pem、cert.pem 或 key.pem 的目录，用于与 Docker 建立安全的 TLS 连接。在 boot2docker 中很有用。 tls_verify启用或禁用对 Docker 守护程序连接的 TLS 验证，默认禁用 userns_mode启用用户命名空间重新映射选项时，容器和 Docker 服务的用户命名空间模式，在 Docker 1.10 或更高版本中可用 volumes安装挂载卷与 Docker-v标志的语法相同 volumes_from从另一个容器继承挂载卷，访问级别默认为读写，但可以手动设置为ro（只读）或rw（读写） volume_driver用于容器的挂载卷驱动程序 wait_for_services_timeout等待 Docker 服务的时间设置0为禁用默认为30 ### gitlab-ci的理论 ### #### gitlab-ci的工作流程 #### gitlab的ci流程的组成部分: code:开发人员推送的代码 .gitlab-ci.yml 指定构建、测试和部署的脚本。 GitLab Runner 运行.gitlab-ci.yml脚本 gitlab-ci的工作流程： ①开发人员推送代码到指定分支 ②触发gitlab-pipeline，自动检测运行.gitlab-ci.yml文件 ③gitlab runner运行脚本，根据脚本内容进行build test deploy #### gitlab-ci的工作原理 #### ①将代码托管到git存储库 ②在项目根目录创建ci文件 .gitlab-ci.yml，在文件中指定构建，测试和部署脚本。 ③gitlab将检测到他并使用名为gitlab-runner的工具运行脚本 ④脚本被分组为作业，他们共同组成一个pipeline #### gitalb-ci的工作流程图 #### ![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-If6k5d1p-1629288433710)(C:\\Users\\shiya.liu\\AppData\\Roaming\\Typora\\typora-user-images\\image-20210818171625082.png)\]][img-If6k5d1p-1629288433710_C_Users_shiya.liu_AppData_Roaming_Typora_typora-user-images_image-20210818171625082.png] #### gitlab-runner简介 #### 1、gitlab-runner是一个开源项目，用于运行作业并将结果返回给gitlab 2、与gitlab-ci结合使用，gitlab-ci是gitlab随附的用于协调作业的开源持续集成服务。 3、gitlab-runner是使用go语言写的，可以在Linux macos Windows操作系统上进行运行 4、容器部署需要使用最新docker版本。gitlab-runner需要最少的docker v1.13版本 5、gitlab-runner版本应和gitlab版本进行同步（避免版本不一致导致差异化） 6、可以根据需要配置任意数量的runner PS：ditlab-runner类似于Jenkins的agent，执行CI持续集成、构建的脚本任务。 #### gitlab-runner的特点 #### 作业运行控制：同时执行多个作业 作业运行环境： ①在本地、使用docker容器、使用docker容器并通过SSH执行作业 ②使用docker容器在不用的云和虚拟化管理程序上自动缩放 ③连接到远程SSH服务器 支持bash、Windows batch和Windows powershell 允许自定义作业运行环境 自动重新加载配置，无需重启 易于安装，可作为Linux，macos和Windows的服务 #### gitlab-runner类型与状态 #### 类型： shared 共享类型，运行整个平台项目的作业（gitlab） group 项目组类型，运行特定group下的所有项目的作业（group） specific 项目类型，运行指定的项目作业（project） 状态： locked 锁定状态，无法运行项目作业 pause的 暂停状态，暂时不会接受新的作业 #### job的运行流程 #### （根据job的输出日志进行分析） Running with gitlab-runner 14.1.0 (8925d9a0) on c088e5ef43f3 RXcgCdUx #选择的gitlab-runner准备运行pipeline Preparing the "shell" executor #准备“shell”执行器 Using Shell executor... #正在使用Shell执行器 Preparing environment #准备环境 Running on ea06ddae5852... #正在ea06ddae5852（container id）上运行 Getting source from Git repository #从Git存储库获取源代码 Fetching changes with git depth set to 50... #正在获取git深度设置为50的更改 Reinitialized existing Git repository in /home/gitlab-runner/builds/RXcgCdUx/0/root/shell/.git/ #在/home/gitlab runner/builds/rxgcdux/0/root/shell/.Git中重新初始化现有Git存储库/ Checking out 5b8e0163 as main... #查找对比 Skipping object checkout, Git LFS is not installed. #正在跳过对象签出未安装Git LFS。 Skipping Git submodules setup #正在跳过Git子模块安装程序 Executing "step_script" stage of the job script #执行作业脚本的“步骤脚本”阶段 $ ls python-demo.py test $ ls python-demo.py test $ sleep 10 $ echo "mvn clean" mvn clean $ sleep 3 $ touch /home/gitlab-runner/builds/RXcgCdUx/0/root/shell/test.txt $ pwd /home/gitlab-runner/builds/RXcgCdUx/0/root/shell $ sleep 30 Job succeeded (gitlab两大要素：gitlab-runner;.gitlab-ci.yml) ### .gitlab-ci.yml的编写语法 ### #### pipeline语法1 #### job： 在每个项目中，使用名为.gitlab-ci.yml的问价配置gitlab ci cd 的pipeline。在文件中可以定义一个或多个job。每个job必须具有唯一的名称（不能使用关键字），每个job都是独立执行的。作业定义了在约束条件下进行的相关操作，每个job至少包含一个script。 例如： job1: script: "execute-script-for-job1" job2: script: "execute-script-for-job2" 这里在pipeline中定义了两个作业，每个作业运行不同的命令，命令可以是shell脚本。 script: 用于运行命令 before_script： 用于定义一个命令，该命令在每个作业之前运行，必须是一个数组。指定的是script与主脚本中指定的任何脚本串联在一起，并在单个shell中一起执行； 类似于before_script&&script 这样在一个shell中执行，如果before_script失败则script不会执行。 befor_script失败导致整个作业失败，其他作业将不再执行。作业失败不会影响after_script运行。 after_script与before_script&&script不是在一个shell中执行，所以他们的失败不会影响到after_script的执行。 after_script: 用于定义将每个作业（包括失败的作业）之后运行的命令。 这必须是一个数组。 指定的脚本在新的shell中执行，与任何before_script或script脚本分开。、 after_script失败不会导致作业失败。 举例： build: stage: build tags: - shell only: - main before_script: - echo "这是before_script脚本，表示要和script进行串行执行命令了" script: - echo "mvn clean" - echo "mvn install" after_script: - echo "这是after_script脚本，表示before_script&&script脚本执行顺序已经过了，但是并不代表他们是否执行成功，这个job即将执行完成" stages: 用于定义作业可以使用的阶段，并且是全局定于的 同一阶段的作业并行运行，不同界阶段按顺序运行。 阶段的名字可以随意起名 .pre和.post .pre始终是整个管道的第一个运行阶段，.post始终是整个管道的最后一个运行阶段。用户定义的阶段都在两者之间运行。.pre和.post的顺序无法更改。如果pipeline仅包含.pre和.post阶段的作业，则不会创建pipeline。 stage: 是按照job定义的，并且依赖于全局定义的stages。它允许将作业分为不同的阶段，并且同一个stage作业可以并行执行（取决特定条件） 举例： stages: - build - deploy 编译: stage: build #使用stages定义的阶段，进行执行。 ... ... variabls 定义变量，pipeline变量、job变量。job变量优先级最大。 举例： variabls: DOMAIN: example.com #### pipeline语法2 #### pipeline语法2 tags: 用于允许运行该项目的所有runner列表中选择特定的runner，在runner注册期间，可以指定runner的标签 allow_failure： 允许失败 allow_faulure允许作业失败，默认值是false。启用后，如果job失败，该job将在用户界面显示橙色警告，到那是，pipeline的逻辑流程将认为job执行通过，并且不会阻塞。假设所有其他job均为成功，则该job的阶段以及他的pipeline将显示相同的橙色警告。但是，关联的提交将被标记为“通过”，而不会发出警告。不会影响下个job的执行。 when： on_success 前面阶段中的所有job都成功时才执行job，是默认值 on_failure 当前面阶段出现失败时执行 always 总是执行job manual 手动执行job delayed 延迟执行job retry： 重试 配置在失败的情况下重试job的次数 当job失败并配置了retry，将再次处理该作业，直到达到retry关键字指定的次数 如果retry设置为2，并且job在第二次运行成功（第一次重试），则不会再次重试，retry值必须是一个整数，等于或大于0，但小于等于2（最多两次重试，总共运行3次）。 retry也可以设置精确匹配错误 默认情况下，在失败情况下重试job。max:最大重试次数 when：重试失败的错误类型。 always ：在发生任何故障时重试（默认）. unknown_failure ：当失败原因未知时。 script_failure ：脚本失败时重试。 api_failure ：API失败重试。 stuck_or_timeout_failure ：作业卡住或超时时。 runner_system_failure ：运行系统发生故障。 missing_dependency_failure: 如果依赖丢失。 runner_unsupported ：Runner不受支持。 stale_schedule ：无法执行延迟的作业。 job_execution_timeout ：脚本超出了为作业设置的最大执行时间。 archived_failure ：作业已存档且无法运行。 unmet_prerequisites ：作业未能完成先决条件任务。 scheduler_failure ：调度程序未能将作业分配给运行scheduler_failure。 data_integrity_failure ：检测到结构完整性问题。 timeout： job级别的超时可以超过项目级别的超时，但不能超过runner特定的超时。 三个超时：job的超时、项目的超时、runner的超时 示例1： runner超时时间设置为24小时，项目的CICD超时设置为2小时，该工作将在2小时后超时； 示例2： runner不设置超时时间，项目的CICD超时设置为2小时，该工作将在24小时后超时 示例3： runner超时设置为30分钟，项目的CICD超时设置为2小时，该工作在30分钟后将超时 timeout的应用场景： 防止某个项目占用runner时间过长，防止runner被长时间占用 parallel： 并行作业 配置要并行运行的作业实例数，此值必须大于等于2并且小于等于50 这将创建N个并行运行的同一作业实例，他们从job_name_1到job_name_N依次命名。 举例： codescan: tags: - training stage: codescan script: - echo "run codesacn" - sleep 3; when: on_success parallel: 5 before_script: #全局设定执行job前的输出（优先级小于job内定义的before_script） - echo "before-script!!" #输出内容 variables: #定义的全局变量 DOMAIN: example.com #变量内容的key:value stages: #定义job要执行的内容 配合stage进行选定，定义了执行顺序 - build - test - codescan - deploy build: #注意 这里的build是job的名字 stages中的要真正执行的内容 before_script: #job内定义的要执行前输出的内容 - echo "before-script in job" stage: build #选定执行的内容 script: - echo "mvn clean " - echo "mvn install" - echo "$DOMAIN" after_script: #执行完成后输出的内容 - echo "after script in buildjob" unittest: #job名字 stage: test #选择的执行内容 script: - ech "run test" when: delayed #设置延时30秒的job start_in: '30' allow_failure: true #开启允许job运行失败 deploy: #job名 stage: deploy #选择要执行的内容 script: - echo "hello deploy" - sleep 2; when: manual #设定手动执行 codescan: #job名 stage: codescan #绑定stages中设置的阶段名 script: - echo "codescan" - sleep 5; when: on_success #当前面都执行成功再执行这个job after_script: #全局定义job执行完成后输出的语句，如果job中没定义则会执行全局的after_script - echo "after-script" - ech #### pipeline语法3 #### pipeline语法3 only： 定义那些分支和标签的git项目将会被job执行（用分支策略来限制job的构建，写在那个步骤，那个步骤就不会执行） except： 定义那些分支和标签的git项目将不会被执行（用分支策略来限制job的构建） rules： 构建规则 rules允许按顺序评估单个规则，直到匹配并为工作动态提供属性 rules不能和only/except进行组合使用 可用规则： if（如果条件匹配） changes（指定文件发生变化） exists（指定文件存在） rules-if条件匹配 如果DOMAIN的值匹配，则需要手动执行 不匹配on_success 条件判断从上到下，匹配即停止 多条件匹配可以使用&& || 举例： codescan: tags: - training stage: codescan script: - echo "run codesacn" - sleep 3; rules: - if: '$DOMAIN == "example.com"' when: manual - if: '$DOMAIN == "aexample.com"' when: delayed start_in: '5' - when: on_success rules-changes 文件变化 接受文件路径数组 如果提交中文件发生的变化则为true rules-exists 文件存在 接受文件路径数组 当仓库中存在指定的文件时操作 workflow： 控制pipeline的运行 顶级workflow关键字适用于整个pipeline，并将确定是否运行pipeline when 可以设置为always或never，如果未提供，则默认值为always #### pipeline语法4 #### pipeline语法4 cache:缓存 存储编译项目所需的运行时依赖想项，指定项目工作空间中需要在job之间缓存的文件或目录 全局cache定义在job之外，针对所有job生效。job中cache优先于全局中的cache。 cache：paths 在job build中定义缓存，将会缓存target目录下的所有.jar文件 当在全局定义了cache:paths会被job中定义的cache所覆盖。 问题： 由于缓存是在job之间共享的，如果不同的job使用不同的路径就出现了缓存覆盖的问题 如何让不同的job缓存不同的cache呢？ 解决：设置不同的cache:key cache:key-缓存标记 为缓存做个标记，可以配置job，分支为key来实现分支、作业特定的缓存。 为不同job定义了不同的cache:key时，会为每个job分配一个独立的cache。 cache:key变量可以使用任何预定义变量，默认default 从gitlab9.0开始，默认情况下所有内容都在pipeline和作业之间共享。 按照发分支设置缓存 cache: key: ${CI_COMMIT_REF_SLUG} cache:key:files 文件变化自动创建缓存 files:文件发生变化自动重新生成缓存（files最多指定两个文件），提交的时候检查指定的文件。根据指定的文件生成密钥计算SHA校验，如果文件未改变，值就为default cache:policy 缓存策略 默认：在执行开始下载时下载文件，并在结束时重新上传文件 policy:pull跳过下载步骤，policy：push，跳过上传步骤 artifacts： 制品 用于指定在作业成功或者失败时应附加到作业的文件或目录的列表。作业完成后，工件将被发送到gitlab，并在gitlab ui中提供下载 artifacts:expose_as关键字可用于在合并请求UI中公开作业工件，每个合并请求最多可以公开10个作业工件 artifacts:name 制品名称 通过name指令定义所创建的工件存档的名称。可以为每个档案使用唯一的名称。 artifacts:name默认名称是artifacts，下载artifacts改为artifacts.zip artifacts:when 制品创建条件 用于在作业失败时或者成功后再上传工件 on_success仅在作业成功时上传工件，默认值 on_faulure仅在作业失败时上传工件 always 上传工件，无论作业状态如何 artifacts:expire_in 制品保留时间 制品的有效期，从上传和存储到gitlab的时间开始计算。如果未定义过期时间，则默认30天 expire_in的值以秒为单位的经过时间，除非提供了单位。 artifacts:reports:junit 单元测试报告 单元测试报告功能默认关闭（因为消耗资源严重） 收集junit单元测试报告，收集的junit报告将组为工件上传到gitlab，并将自动显示在合并请求中。 开启artifacts:reports:junit单元测试报告功能步骤： $gitlab-rails console $Feature.enable(:junit_pipeline_view) => true artifacts:reports:cobertura-覆盖率 需要做maven集成cobertura插件 在maven中配置完成后执行mvn cobertura:cobertura 运行测试并产生Cobertura覆盖率 dependencies获取制品 定义要获取工件的作业列表，只能从当前结点之前执行的节点定义作业，定义一个空数组将跳过下载该作业的任何工件不会考虑先前作业的状态，因此，如果他是失败或者未运行的手动作业，则不会发生错误。如果设置为依赖项的作业的工件已过期或者删除，那么依赖项作业将失败。 #### pipeline语法5 #### pipeline语法5 needs：（parallel是并行运行job，needs是并行运行阶段） 阶段并行 可无序执行作业，不需要按照阶段顺序运行某些作业，可以让多个阶段同时运行。如果needs设置为指向因only/execpt规则而未实例化的作业，或者不存在，则创建pipeline时会出现yaml错误。 include: local引入本地配置，引入同一存储库中的文件，使用相对于根目录的完整路径进行引用，与配置文件在同一分支上使用。 可以允许引入外部yaml文件，文件具有扩展名.yml 使用合并功能可以自定义和覆盖包含本地定义的CI/CD配置 引入同一存储库中的文件，使用相对于根目录的完整路径进行引用，与配置文件在同一分支上使用。 file: 引入其他项目的文件 template：https://gitlab.com/gitlab-org/gitlab/tree/master/lib/gitlab/ci/templates 只能使用官方提供的模板 remote:引入远程配置 用于通过HTTP/HTTPS包含来自其他位置的文件，并使用完整URL进行引用，远程文件必须可以通过简单的GET请求公开访问，因为不支持远程URL中的身份验证框架。 extends: 继承作业配置 举例： stages: - test variables: RSPEC: 'test' .test: script: echo "mvn test" stage: test only: refs: - branches testjob: extends: .test script: echo "mvn clean test" only: variables: - $RSPEC trigger: 当gitlab从trigger定义创建的作业启动时，将创建一个下游管道。允许创建多项目和子管道。将trigger与when: manual一起使用会导致错误。 多项目管道：跨多个项目设置流水线，以便一个项目中的管道可以触发另一个项目中的管道。 父子管道：在同一个项目中管道可以触发一组同时运行的子管道，子管道仍然按照阶段顺序执行其每个作业，但是可以自由地继续执行各个阶段，而不必等待父管道中无关的作业完成。 image: 默认在注册runner的时候需要填写一个基础的镜像，只要使用执行为docker类型的runner所有的操作都会在容器中运行。如果全局指定了image则所有作业使用此image创建容器并在其中运行。全局未指定image，再次查看job中是否有指定，如果job中有指定则按照指定镜像创建容器运行，没有则使用注册runner时指定的镜像。 services 工作期间运行的另一个docker镜像，并link到image关键字定义的docker镜像，这样就可以再构建期间访问服务镜像。 服务镜像可以运行任何应用程序，但是最常见的用例是运行数据库容器，例如MySQL。于每次按照项目时都安装MySQL相比，使用现有镜像并将其作为附加容器运行更容易，更便捷。 services: - name: msyql:latest alias: mysql-1 environment 工作期间运行的另一个docker镜像，并link到image关键字定义的docker镜像，这样就可以再构建期间访问服务镜像。 inherit 使用或禁用全局定义的环境变量（variables）或默认值（default） 使用true和false决定是否使用，默认是true ### 总结->.gitlab-ci.yml文件中共有27个关键词 ### job #要运行的任务 script #指定脚本内容 before_script #执行job前运行脚本 分为全局和局部 after_script #执行job后运行脚本 分为全局和局部 stages #全局定义作业可用阶段 .pre&.post #.pre始终是第一个运行的阶段；.post始终是最后以一个运行的阶段 stage #配合stages进行引用，按照job进行定义的 variables #定义变量 tags #用于指定runner的标签 allow_failure #允许失败 不影响下一个job的运行 when (manual\on_success\on_failure\always\delayed) #设置触发运行的方式（手动、当前面job成功、当前面job失败、总是执行、延时执行） retry(max\when) #重试 timeout #设置允许超时时间 parallel #并行作业 only&except #定义运行策略跳过某个执行或者进行某个执行 rules(rules:if\rules:changes\rules:exists\rules:allow_faulure\workflow:rules) 定义构建规则 cache(cache:paths\cache:key\cache:policy) #设置缓存 artifacts(artifacts:paths\artifacts:expose_as\artifacts:name\artifacts:when\artifacts:exp ire_in\artifacts:reports\artifacts:reports:cobertura) #用于指定在作业成功或者失败时应附加到作业的文件或目录的列表。 dependencies #定义特定的job运行规则 needs #阶段并行 （parallel是并行运行job，needs是并行运行阶段） include(local\file\template\remote) #引入配置 extends #集成配置 trigger #当gitlab从trigger定义创建的作业启动时，将创建一个下游管道。 image #定义job执行时使用的镜像 services #工作期间运行的另一个docker镜像，并link到image关键字定义的docker镜像。 environment #定义此作业完成部署的环境名称 inherit #使用或禁用全局定义的环境变量 设置gitlab-runner运行job时不每次都拉取镜像 [[runners]] name = "26fe27c2cc92" url = "http://10.0.0.6/" token = "okWxn2xa6cdAbyR8oLCM" executor = "docker" [runners.custom_build_dir] [runners.cache] [runners.cache.s3] [runners.cache.gcs] [runners.cache.azure] [runners.docker] pull_policy = "if-not-present" #此配置是设置先检查本地是否有此镜像，没有再去拉取。 tls_verify = false image = "python:latest" privileged = false disable_entrypoint_overwrite = false oom_kill_disable = false disable_cache = false volumes = ["/cache"] shm_size = 0 自定义CI配置文件路径 默认情况下，在项目的根目录中查找，.gitlab-ci.yml文件，如果需要，可以指定备用路径和文件名，包括项目外部的位置。 .gitlab-ci.yml .my-custom-flie.yml my/path/.gitlab-ci.yml my/path/.my-custom-file.yml http://example.com/generate/ci/config.yml .gitlab-ci.yml@mygroup/another-project my/path/.myu-custom-file.yml@mygroup/anothner-project 将配置文件托管在单独的项目中，可以更严格地控制配置文件，创建一个公共项目来承载配置文件，仅向被允许编辑文件的用户授予对项目的写权限。其他用户和项目将能够访问配置文件而无需对其进行编辑。 \[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Nab8BUAj-1629288433718)(C:\\Users\\shiya.liu\\AppData\\Roaming\\Typora\\typora-user-images\\image-20210816162616153.png)\] ### 问题记录 ### Q:gitlab-runner和gitlab是什么关系？ A:gitlab-runner是跑gitlab上的pipelines的 Q.gitlab-ci.yml的作用是什么？ A:控制job的运行逻辑顺序，定义pipeline，定义job的工作方式、具体细节等。 Q:gitlab的cicd 与gitlab(只存储代码)+Jenkins cicd的方式目的是一样的嘛？两者区别是什么？ A: 只能说目的是一样的，查阅了一些devops的博客、书籍，其实这是两个不同的工具而已， 目的都是更好的服务公司业务的便捷。 Q:燧原公司内部是选择gitlab-cicd做ci工具的，但是燧原公司也有Jenkins，Jenkins在燧原公司的ci流程中是作为什么角色呢？这两个结合使用嘛？ A:是在做迁移，之前是Jenkins（应该是遇到了瓶颈），后转为gitlab-ci。如果是这样的，那么gitlab-ci为什么比Jenkins更适合燧原的业务？（需要慢慢了解） Q:在gitlab-runner中结合docker进行目标机器的deploy是怎么选择指定机器的？ A:应该是根据gitlab-runner的所在机器，类似于gitlab-runner是agent，gitlab-ci是server。 Q:在gitlab-ci中是不是常常结合docker进行一个交付部署，在不适用docker的场景下gitlab-ci还适用嘛？ 支持shell（Jenkins就是基于shell的方式进行的cicd）;具体支持的执行器见上面<gitlab-runner的执行器> Q：在gitlab-ci中 使用的基础镜像是aplin:latest 可以更改吗？ A:可以的，关键字image执行gitlab-runner执行时运行的镜像。 共分为三部分 ①注册gitlab-runner时指定的镜像：runner的镜像； ②在.gitlab-ci.yml中分为全局变量：定义在job外的image关键词为全局变量：job中没有定义时使用此镜像； ③在job中image关键词指定了镜像，则执行job内的镜像； Q：默认的提交代码后触发pipeline的方式是什么？ A:修改文件后会触发pipeline的执行\也可以设置计划任务来进行\手动点击执行 Q:执行docker的解释器时 是怎么执行的，比如我执行echo.sh脚本，pipeline会自动把脚本拷贝到镜像中吗？脚本的执行位置是container还是宿主机？ A:不是拷贝到镜像中，而是拉取项目代码。关于脚本执行的位置，是需要看docker-runner的执行器类型的。如果是shell执行器 则是在gitlab-runner上运行 如果是docker类型的执行器，则会在gitblab-ci上启动新的容器来完成阶段性任务，完成后退出。 Q:指定机器运行 是靠指定gitlab-runner来实现的吗？ A：gitlab-ci 在.gitlab-ci.yml中指定要在那个gitlab-runner上运行。前提是需要在目标机器上运行并注册了gitlab-runner Q:stage中设置并行执行 是真正的并行吗 我通过观察pipeline运行来看，是串行执行的。 A:进行并行运行需要修改配置文件 vim /srv/gitlab-runner/config/config.toml concurrent = 10 不需要重启就可生效 ![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Lac0xLwG-1629288433722)(C:\\Users\\shiya.liu\\AppData\\Roaming\\Typora\\typora-user-images\\image-20210812152746026.png)\]][img-Lac0xLwG-1629288433722_C_Users_shiya.liu_AppData_Roaming_Typora_typora-user-images_image-20210812152746026.png] Q:.gitlab-ci.yml中怎么设置stages进行并行运行，怎么设置 跳过某个stage进行下面的job A:设置并行运行就是将一个stages中设置的阶段，在多个job中进行指定stage 进行运行。 stages: - build - deploy 编译: stage: build tags: - shell only: - main before_script: - echo "这是before_script脚本，表示要和script进行串行执行命令了" script: - echo "mvn clean" - echo "mvn install" after_script: - echo "这是after_script脚本，表示before_script&&script脚本执行完成了，这个job即将执行完成" 部署: stage: build tags: - docker only: - main script: - echo "hello deploy" ### 补充 CI概念以及CI常规流程 ### CI:持续集成简称CI ，指的是频繁的将代码集成到主干，持续集成的目的就是让产品可以快速迭代同时能保证高质量。核心是必须通过自动化测试，只要有一个测试用例失败，就不能集成。 从代码提交到生产有几个步骤： 1、提交 流程的第一步，是开发者向代码仓库提交代码，所有后面的步骤都始于本地代码的一次提交 2、测试 代码仓库对提交操作配置了钩子，只要提交代码或者合并主干，就会跑自动化测试 3、构建 通过第一轮测试，代码就可以合并主干，算是可以交付了 交付后，就先进行构建，再进入第二轮测试。所谓构建，指的是将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源。 4、部署 通过了第二轮测试，当前代码就是一个可以直接部署的版本。将这个版本的所有文件打包存档，发到生产服务器。 5、回滚 一旦当前版本发生问题，就要回滚到上一个版本的构建结果。最简答的做法就是修改一下符号连接，指向上一个版本的目录。 CD:持续交付和持续部署称为CD ### gitlab-ci的工具链集成 ### 模板库规划 SonarQube代码扫描 Artifactory制品库（gitlab中也有制品库） 阿里云镜像仓库/harbor等 jmeter接口测试简介 gitlab集成自动化测试 minion对象存储 邮件通知pipeline结果 未完待续 [img-If6k5d1p-1629288433710_C_Users_shiya.liu_AppData_Roaming_Typora_typora-user-images_image-20210818171625082.png]: /images/20220829/d1faa50b4241413fa1d34ff796c6d665.png [img-Lac0xLwG-1629288433722_C_Users_shiya.liu_AppData_Roaming_Typora_typora-user-images_image-20210812152746026.png]: /images/20220829/fb77c50df951482780e3ec7b3eac7bc8.png
还没有评论，来说两句吧...