学生作业做网站需要,县城网站怎么做,wordpress能放视频播放器,网站搭建平台云原生专栏大纲 文章目录 GitLab RunnerGitLab Runner 介绍Gitlab Runner工作流程 Gitlab集成Gitlab RunnerGitLab Runner 版本选择Gitlab Runner部署docker-compose方式安装kubesphere中可视化方式安装helm方式安装 配置gitlab-runner配置gitlab-ci.ymlgitlab-ci.yml 介绍编写…云原生专栏大纲 文章目录 GitLab RunnerGitLab Runner 介绍Gitlab Runner工作流程 Gitlab集成Gitlab RunnerGitLab Runner 版本选择Gitlab Runner部署docker-compose方式安装kubesphere中可视化方式安装helm方式安装 配置gitlab-runner配置gitlab-ci.ymlgitlab-ci.yml 介绍编写gitlab-ci.yml 测试 GitLab CICD 【待补充】 GitLab Runner GitLab Runner 介绍
GitLab Runner 是一个开源的持续集成/持续交付CI/CD工具用于在 GitLab CI/CD 环境中执行自动化构建、测试和部署任务。它是 GitLab CI/CD 的一部分负责管理和执行 CI/CD 作业。以下是 GitLab Runner 的一些关键特点和功能
多平台支持GitLab Runner 可以在多种操作系统上运行包括 Linux、macOS 和 Windows。这使得它非常灵活可以适应不同的开发环境。并行执行GitLab Runner 支持并行执行作业可以同时运行多个作业提高构建和测试的效率。多种执行器GitLab Runner 提供了不同类型的执行器包括 Shell、SSH、Docker、Kubernetes 等。这些执行器可以根据需要选择以便在不同的环境中执行作业。可扩展性GitLab Runner 可以通过添加自定义执行器来扩展其功能。这使得它可以与各种不同的工具和服务集成以满足特定的需求。安全性GitLab Runner 提供了各种安全功能包括作业隔离、安全沙盒和访问控制。这些功能可以确保作业的安全性和可靠性。配置灵活GitLab Runner 的配置非常灵活可以通过配置文件或命令行参数进行配置。你可以根据需要自定义执行器的行为和设置。
使用 GitLab Runner你可以轻松地将 CI/CD 流程集成到 GitLab 中实现自动化构建、测试和部署。它提供了强大的功能和灵活的配置选项使得开发团队能够更高效地交付软件。无论是小型项目还是大型企业级项目GitLab Runner 都是一个强大而可靠的 CI/CD 工具。
Gitlab Runner工作流程
GitLab Runner 的工作流程如下
注册 Runner首先你需要在 GitLab 中注册一个 Runner。这可以通过在 GitLab 项目设置中创建一个新的 Runner 配置来完成。在注册过程中你将为 Runner 分配一个唯一的 token用于与 GitLab 服务器进行身份验证。安装和配置 Runner在你的执行环境中安装 GitLab Runner并使用注册时获得的 token 进行身份验证。安装过程可能因操作系统而异请按照官方文档提供的说明进行安装。安装完成后你需要通过配置文件或命令行参数对 Runner 进行配置包括指定 Runner 的名称、token、执行器类型等信息。运行和监听启动 GitLab Runner 后它会连接到 GitLab 服务器并开始监听作业的出现。Runner 会定期向 GitLab 服务器发送心跳信号以保持连接。当有新的作业出现时GitLab 服务器会将作业分配给可用的 Runner。下载代码当 Runner 接收到作业时它会从 GitLab 服务器上获取项目的代码。这通常是通过克隆 Git 存储库或者拉取最新的代码变更来完成的。执行作业一旦代码下载完成Runner 将根据作业的定义执行相应的操作。这可以是构建项目、运行测试、生成文档、打包应用程序等等。Runner 可以使用预定义的执行器如 Shell、Docker、Kubernetes来运行作业。提交结果当作业执行完成后Runner 将结果提交回 GitLab 服务器。这包括构建日志、测试报告、生成的文件等。这些结果可以在 GitLab 的界面中查看和分析。清理和释放资源完成作业后Runner 将清理执行环境并释放使用的资源。这可以包括删除临时文件、停止容器、释放服务器资源等。
整个过程是自动化的GitLab Runner 负责管理作业的执行和结果的提交。它可以与 GitLab CI/CD 配合使用为开发团队提供一个强大的持续集成和持续交付平台。通过配置不同的执行器和作业定义你可以根据项目的需求和特定的环境设置来灵活地定义和执行作业。
Gitlab集成Gitlab Runner GitLab Runner 版本选择
https://docs.gitlab.com/runner/出于兼容性原因GitLab Runner major.minor 版本 应与 GitLab 主要和次要版本保持同步。年长的跑步者可能仍然可以工作 使用较新的 GitLab 版本反之亦然。但是功能可能不可用或无法正常工作 如果存在版本差异。 次要版本更新之间保证向后兼容性。然而有时轻微 GitLab 的版本更新可以引入需要 GitLab Runner 在同一个次要版本上的新功能 版本。 GitLab Runner 15.0 对 注册 API 请求格式。它可以防止 GitLab Runner 与低于 14.8 的 GitLab 版本进行通信。 您必须使用适合 GitLab 版本的 Runner 版本或者升级 GitLab 应用程序。
查看gitlab版本
gitlab-rake gitlab:env:infohttps://hub.docker.com/r/gitlab/gitlab-runner/tags查找跟gitlab版本对应的runner版本lpine Linux 和 Ubuntu 是两种常见的 Linux 发行版它们在一些方面有所不同。
大小和资源消耗Alpine Linux 是一个轻量级的发行版以小巧和高效而闻名。它的基本安装映像非常小通常只有几十兆字节因此占用的磁盘空间和内存消耗相对较少。这使得它在容器化环境中非常受欢迎因为它可以快速启动和部署。相比之下Ubuntu 是一个功能更全面的发行版提供了更多的软件包和功能。它的基本安装映像较大通常几个几百兆字节占用的磁盘空间和内存消耗也更高一些。软件包管理Alpine Linux 使用 apk 包管理器来管理软件包。它的软件包库相对较小但它专注于提供核心软件包和常用工具以满足大多数基本需求。Ubuntu 使用 apt 包管理器来管理软件包。它的软件包库非常庞大包含了广泛的软件选择包括开发工具、服务器应用、桌面环境等。默认配置和用户友好性Ubuntu 在默认配置和用户友好性方面更加注重。它提供了易于使用的图形界面和友好的安装程序适合桌面和服务器使用。Alpine Linux 更加精简更注重定制和自定义。它的默认配置较为简单适合专注于特定用途的部署如容器化环境或嵌入式系统。
选择使用 Alpine Linux 还是 Ubuntu 取决于你的具体需求。如果你需要一个轻量级、高效的发行版适用于容器化环境或资源受限的系统那么 Alpine Linux 是一个不错的选择。如果你需要更广泛的软件选择、更丰富的功能和更友好的用户体验那么 Ubuntu 可能更适合你。
Gitlab Runner部署
docker-compose方式安装
version: 3.8
services:gitlab-runner:image: gitlab/gitlab-runner:alpine-v11.11.4container_name: gitlab-runnerrestart: alwaysvolumes:- ./config:/etc/gitlab-runner- /var/run/docker.sock:/var/run/docker.sock # 这一行是固定写法 不要随便改kubesphere中可视化方式安装
创建PVC 配置镜像地址 挂载配置
注意/var/run/docker.sock挂载使用HostPath卷
helm方式安装
https://www.jianshu.com/p/2eb12252e4ee注意helm仓库中维护的版本都大于11若想使用helm部署请升级gitlab
添加仓库
# 添加 chart 存储库
$ helm repo add gitlab https://charts.gitlab.io# 查看存储库
$ helm repo list
NAME URL
gitlab https://charts.gitlab.io在kubesphere应用仓库中部署 修改values.yaml 文件
#以下两个在gitlab页面获取
gitlabUrl: http://gitlab.base.svc.cluster.local # 使用k8s内部gitlab svc地址
runnerRegistrationToken: gitlab-runner-tocken #gitlab-runner注册用到的tockenconcurrent: 10 #最大作业并发数
checkInterval: 30 #新作业检查间隔
tags: k8s-runner #runner的标签
#rbac权限打开
rbac:create: true## Define specific rbac permissions.## DEPRECATED: see .Values.rbac.rulesresources: [pods, pods/exec, secrets,configmaps]verbs: [get, list, watch, create, patch, delete,update]配置gitlab-runner
注册-gitlab-runner官网参考
查看gitlab中token和地址 进入gitlab-runner容器命令行执行
/ # gitlab-runner register
Runtime platform archamd64 oslinux pid33 revisione828d3bc version11.11.4
Running in system-mode.
# gitlab地址
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
https://xxx.xxx.shop:99/
# 项目token
Please enter the gitlab-ci token for this runner:
cp6KwLn3KDTLWN8SD3ax
Please enter the gitlab-ci description for this runner:
[gitlab-runner-8575578f55-d8bfh]: ci
Please enter the gitlab-ci tags for this runner (comma separated):
ci
Registering runner... succeeded runnercp6KwLn3
# 选择执行器从给出列表选择
Please enter the executor: parallels, shell, kubernetes, docker, docker-ssh, ssh, virtualbox, dockermachine, docker-sshmachine:
[ci]: shell
Runner registered successfully. Feel free to start it, but if its running already the config should be automatically reloaded!上述操作会生成配置文件如下
验证runner配置
登录gitlab项目中CI/CD面板出现绿色可用runner表示配置生效
配置gitlab-ci.yml
gitlab-ci.yml 介绍
gitlab-ci.yml 是 GitLab CI/CD 的配置文件用于定义项目的持续集成和持续交付流程。它采用 YAML 格式位于项目的根目录或指定的目录中。gitlab-ci.yml 文件包含了一系列的作业jobs和阶段stages定义了项目在不同情况下的构建、测试、部署等操作。以下是一些常见的 gitlab-ci.yml 配置项
image指定用于作业执行的 Docker 镜像。可以选择现有的镜像也可以自定义镜像。stages定义项目的阶段顺序。每个阶段包含一组作业。before_script在每个作业执行之前运行的脚本命令。可以用于设置环境、安装依赖等操作。after_script在每个作业执行之后运行的脚本命令。可以用于清理环境、收集结果等操作。variables定义作业的环境变量。可以在作业的脚本中使用这些变量。jobs定义项目的作业。每个作业包含一个或多个脚本命令用于执行具体的操作。 script指定作业要执行的脚本命令。可以是单个命令或多个命令的序列。artifacts定义作业产生的构建产物可以在后续的作业中使用。only 和 except指定作业执行的条件。可以基于分支、标签、变量等进行条件判断。
gitlab-ci.yml 文件的配置可以根据项目的需求进行自定义。你可以定义多个作业和阶段根据需要设置依赖关系以及在不同的条件下执行不同的操作。这使得你能够构建灵活、可扩展的 CI/CD 流程提高开发效率和软件质量。需要注意的是一旦 gitlab-ci.yml 文件发生变化GitLab 会自动检测并开始执行新的 CI/CD 流程。执行结果和日志可以在 GitLab 的界面中查看和分析。
编写gitlab-ci.yml 测试
编写gitlab-ci.yml
stages:- build- test- deploybuild_job:stage: buildscript:- echo Building the project... test_job:stage: testscript:- echo Running tests...deploy_job:stage: deployscript:- echo Deploying the project...登录gitlab查看流水线
查看详情提示作业卡住运行者有标签但你的工作没有
解决作业卡住问
登录gitlab点击runner下图按钮进入编辑勾选运行没有标签的作业
再次查看流水线流水线运行完成 GitLab CICD 【待补充】
重新注册gitlab runner执行器选择kubernetes使用参考Kubernetes executor官网 runner 的 k8s 执行器工作流程
runner 会通过 RBAC 认证获取到调用 k8s 集群 API 的权限。runner 会监听 gitlab当有合适的 job 时runner 会自动抓取任务执行。 请注意一个流水线中可以有很多个 stage这些 stage 是串行执行的而一个 stage 中又可以有多个并行的 jobrunner 抓取的任务是以 job 为单位而不是 stage更不是 pipline。 随后runner 会调用 k8s API创建一个用于执行该 job 的 pod。 通常来说runner 创建的所有 pod 有一个通用模板我们需要在 runner 的 config.toml 配置文件中配置这个模板。但 pod 中具体使用什么镜像、在 pod 中执行什么命令这些都是在后续的 .gitlab-ci.yml 文件中配置并且随着 job 的不同而不同。 在完成了 job 内的工作后runner 会将这个临时 pod 删除。
