目录
[安装GitLab Runner](#安装GitLab Runner)
前言Gitlab
🚀 828 B2B企业节盛大启幕,GitLab赋能自动化流程,引领创新部署新时代!在这个瞬息万变的数字时代,我们激动地推出整合GitLab、Docker的顶尖解决方案,为您的软件开发项目注入前所未有的效率与灵活性。专为追求卓越的一体化开发流程设计,这一方案将彻底改变您从代码提交到生产上线的全过程。
🐳 GitLab是一个基于Git的开源分布式版本控制系统,也是一个用于仓库管理系统的Web服务。它由Dmitriy Zaporozhets和Valery Sizov于2011年创建,旨在构建企业自托管Git平台,减少对外部依赖。GitLab提供了丰富的功能,包括代码托管、版本控制、代码审查、项目管理、持续集成/持续部署(CI/CD)等
🐤 本实践指南将引领您深入体验GitLab CI/CD与GitLab Runner的完美融合,以构建一套高效、自动化的.NET控制台应用程序部署流程。您将学习到如何通过GitLab CI/CD功能配置Runner来监听GitLab的Webhooks,从而实现在代码提交后自动触发构建和部署流程;如何利用Docker容器技术来快速打包和运行您的.NET控制台应用;以及如何通过编写.gitlab-ci.yml
脚本来管理整个自动化部署流程。
环境准备
本实验环境是Flexus X实例自定义模式,使用了4vCPUs | 12GiB,镜像是最高版本的ubuntu,我已经提前在服务器中安装了docker环境,在之前的实验中使用xshell连接了服务器,随后在服务器中安装了dokcer。可自行操作或参考下面实验(完成购买服务器以及安装docker步骤)!
828华为云征文|Flexus X实例C#/.Net Core 结合(git代码管理、docker自定义镜像)快速发布部署-让你的项目飞起来~-CSDN博客
GitLab部署
拉取GitLab镜像
GitLab提供了免费的社区版(CE),适合中小型公司和个人开发者使用。同时,它也提供了收费的企业版(EE),为企业用户提供更多的高级功能和支持。下面实验中我们使用社区版。
首先,从Docker Hub上拉取GitLab的镜像。使用以下命令拉取最新版本的GitLab CE(社区版)镜像:
docker pull gitlab/gitlab-ce
如果你需要特定版本的GitLab,可以将latest
替换为具体的版本号,例如gitlab/gitlab-ce:14.10.0
。
创建映射目录
GitLab在容器内部会生成配置文件、日志文件和数据文件。为了方便管理和持久化这些文件,你需要在宿主机上创建相应的目录,并将它们映射到容器内部。通常,你会创建以下三个目录:
/srv/gitlab/config
:用于存放GitLab的配置文件。/srv/gitlab/logs
:用于存放GitLab的日志文件。/srv/gitlab/data
:用于存放GitLab的数据文件。
可以使用以下命令创建这些目录:
mkdir -p /srv/gitlab/config
mkdir -p /srv/gitlab/logs
mkdir -p /srv/gitlab/data
运行GitLab容器
接下来,使用docker run
命令运行GitLab容器。你需要指定容器的一些运行参数,如主机名、端口映射、容器名称、重启策略以及数据卷映射等。以下是一个基本的运行命令示例:
docker run --detach --publish 443:443 --publish 80:80 --publish 2222: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
--detach
:在后台运行容器。
--publish
:将容器内部的端口映射到宿主机的端口上,便于外部访问。
--name
:为容器指定一个名称。
--restart always
:设置容器总是自动重启。
--volume
:将容器内的数据卷映射到宿主机的指定目录上。
修改gitlab.rb配置
(因为文件内容比较多,不熟悉的话建议将服务器上的配置拉下来全局搜索修改)
执行命令 vim srv/gitlab/config/gitlab.rb 找到下面这个配置
external_url 'GENERATED_EXTERNAL_URL'(大约在32行位置)
去掉注释,并修改为我们服务器的地址!!!
配置ssh使用的访问地址和端口
gitlab_rails['gitlab_ssh_host'] = 'ssh.host_example.com'(大约在66行位置)
修改gitlab_rails['gitlab_shell_ssh_port'] 为 = 2222,因为上面docker run的时候,我们避免端口冲突,设置端口映射配置为--publish 2222:22(大约在698行位置)
主要修改的地方就上面三处,我们还可以修改如下配置设置SMTP服务器,配置SMTP的作用有:
如当新用户注册GitLab账户时,系统可以通过SMTP发送一封确认邮件给用户,以确保用户邮箱的有效性,并允许用户完成注册过程。
或是当项目中有新的合并请求(Merge Request)时,GitLab可以自动通过SMTP向相关用户发送通知邮件,提醒他们审查或处理合并请求等等等~~~
可根据需求自行选择是否配置
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.gmail.com"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_user_name'] = "your_email@gmail.com"
gitlab_rails['smtp_password'] = "your_password"
gitlab_rails['smtp_domain'] = "gmail.com"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_tls'] = false
接下来我们进入容器内部设置root用户的密码!
# 进入容器内部
docker exec -it gitlab /bin/bash
# 进入控制台
gitlab-rails console -e production
# 查询id为1的用户,id为1的用户是超级管理员
user = User.where(id:1).first
# 修改密码为1qazZAQ
user.password='1qazZAQ!'
# 保存
user.save!
# 退出
exit
# 继续退出容器内部
exit
# 重启容器
docker restart gitlab
开放端口
老样子,打开服务器控制台,添加80端口!
添加完80端口后,我们还要再添加一个2222的端口,用于ssh访问。
使用 IP+端口 访问我们服务器上的GitLab
切换语言
为了方便操作,我们可以在用户设置的偏好设置中,将语言换成中文!
在偏好设置中找到语言,选择简体中文,保存更改,然后刷新页面!
创建项目
接下来我们回到主页面中,点击新建项目,创建一个项目用于后续测试。
这里我选择创建空白项目。
填写项目名称等相关信息,可见性选择私有的。
添加ssh密钥
创建项目后,系统提示我们还没添加SSH公钥,点击添加公钥去添加公钥
打开cmd 输入ssh-keygen -t rsa -C "******@qq.com"(换成你的邮箱)然后回车回车跳过设置密码等步骤。出现下图信息即公钥生成成功了
Git的SSH密钥通常存储在用户的~/.ssh
目录下,在Windows中,这通常对应于C:\Users\Your-Username\.ssh
,其中Your-Username
是你的Windows用户名。打开id_rsa.pub,复制里面的公钥。
复制到gitlab的配置密钥界面中,保存,至此我们的公钥就添加成功了!
克隆代码
在公钥配置完成后,我们打开刚刚创建的项目,使用SSH克隆,复制链接,然后可以在本地将仓库克隆下来!
使用git clone 将代码克隆下来!
将代码克隆下来后,只有一个包含Readme.md的空文件夹,我们在此目录下新建一个c#控制台项目,用于测试,然后推送上去!
回到gitlab的可视化平台,代码已经成功被推送上来了!
CICD
什么是CICD
CICD是持续集成(Continuous Integration)、持续交付(Continuous Delivery)和持续部署(Continuous Deployment)的简称。它是一种在开发过程中自动执行一系列从开发到部署的任务,以减少人工介入、提高软件交付速度和质量的方法。以下是对CICD各部分的详细解释:
- 持续集成(Continuous Integration, CI)
- 定义:持续集成是一种软件开发实践,团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,意味着每天可能会发生多次集成。
- 核心过程:包括代码编译、代码打包、单元测试、代码静态扫描分析、UI和接口自动化测试等。这些步骤都通过自动化的方式进行,以确保每次集成都稳定可靠。
- 目的:通过自动化构建和测试来快速发现集成中的错误,从而减少开发后期发现和修复错误的成本。
- 持续交付(Continuous Delivery, CD)
- 定义:持续交付是一种将软件的新版本自动发布到存储代码库(如Git仓库)的能力,但不会自动部署到生产环境。
- 核心过程:在持续交付中,每个阶段(从代码更改的合并到生产就绪型构建版本的交付)都涉及测试自动化和代码发布自动化。这确保了软件的每个版本都经过充分的测试,并可以随时部署到生产环境。
- 目的:通过自动化测试和集成,减少部署新代码时所需的工作量,并降低部署风险。
- 持续部署(Continuous Deployment, CD)
- 定义:持续部署是持续交付的延伸,它自动将生产就绪型构建版本发布到生产环境,以供客户使用。
- 核心过程:在持续部署中,自动化测试完成后,如果没有发现问题,代码将自动部署到生产环境。这实现了从开发到生产环境的无缝衔接。
- 目的:通过自动化部署,进一步缩短软件交付周期,提高客户响应速度,并允许开发团队更频繁地接收和整合用户反馈。
Gitlab中使用CICD
什么是Runner
在GitLab中的Runner是一个重要的组件,用于自动化执行在项目中预定义的任务。它作为GitLab CI/CD流程的关键执行者,负责运行构建、测试和部署等作业,并将结果发送回GitLab。Runner可以以多种类型存在,如shared(共享)、group(组)和specific(特定),允许根据项目需求进行灵活配置。通过Runner,开发者可以定义自动化的CI/CD流程,减少手动操作,提高开发效率。
安装GitLab Runner
拉取GitLab Runner的Docker镜像
docker pull gitlab/gitlab-runner:latest
启动容器,将/srv/gitlab-runner/config
目录挂载到容器内的/etc/gitlab-runner
目录,以便保存Runner的配置文件。同时还将Docker的socket文件挂载到容器内,以便Runner能够使用Docker执行CI/CD作业。
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
获取注册令牌
在gitlab首页的菜单栏中点击"搜索或转到..."
选择Admin areea
菜单栏中切换到CI/CD下的Runner
在Runner界面中,点击右上角的扩展标志,选择复制注册令牌,此令牌用于我们下面进行注册runner
runner注册
因为我们的GitLab Runner是部署在docker中,因此需要通过docker exec
命令进入容器内部来执行gitlab-runner register
命令
docker exec -it gitlab-runner /bin/bash
交互式运行
gitlab-runner register --non-interactive --executor "docker" --url http://121.37.28.189 --registration-token "wmEKkxbL7NvjkC-ExwN2" --docker-image "mcr.microsoft.com/dotnet/sdk:8.0" description "共享runner"
非交互式运行
运行gitlab-runner register
命令来注册一个新的GitLab Runner。GitLab Runner是一个用于执行CI/CD任务的程序,它可以在不同的环境中运行构建、测试和其他自动化任务。
# gitlab-runner register --url 你的服务器地址 --registration-token 上一个步骤中获取的注册令牌
示例:gitlab-runner register --url http://121.37.28.189 --registration-token wmEKkxbL7NvjkC-ExwN2
# 退出容器内部
exit
因为使用的是交互式注册,接下来会提示我们需要输入一些注册信息:
- 输入GitLab实例的URL(例如我的是:http://121.37.28.189)。这是你的GitLab服务器的地址,GitLab Runner将与之通信以接收任务并报告结果。
- 输入注册令牌(registration token):上一个步骤中获取的注册令牌,例如我的是:wmEKkxbL7NvjkC-ExwN2。这是一个由GitLab生成的唯一令牌,用于验证新注册的Runner的身份。
- 为新注册的Runner提供一个描述,例如:"共享runner"。这个描述可以帮助您识别和管理不同的Runner实例。
- 为新注册的Runner添加标签,用逗号分隔,例如:"share,demo"。这些标签可以用于将Runner分配给特定的项目或任务组,以便它们只处理具有相应标签的任务。例如我这里新注册的Runner添加了"share,demo"这两个标签。这意味着这个Runner将只处理带有"share"或"demo"标签的CI/CD任务。如果某个项目的.gitlab-ci.yml文件中指定了这些标签,那么该项目的构建、测试等任务就会由这个Runner来执行
- 可选地为新注册的Runner提供一个维护说明,例如:"共享runner"。这个说明可以是任何有助于了解Runner用途的信息。
- 选择要使用的执行器(executor),这里选择了"shell"。执行器决定了Runner如何在其环境中执行任务。在这个例子中,我们选择了"shell"执行器,这意味着Runner将在本地主机上的命令行环境中运行任务。
- 成功注册Runner后,会显示一条消息提示Runner已成功注册,并建议启动它,如果已经在运行,则配置应该会自动重新加载。这意味着您可以立即开始使用新的Runner来处理任务。
- 最后,将带有认证令牌的配置保存在"/etc/gitlab-runner/config.toml"文件中。这个文件包含了Runner的配置信息,包括与GitLab服务器通信所需的认证令牌和其他设置。
操作示例截图
回到我们gitlab中的Runner界面,可以看到Runner下面有一个实例,且是在线状态,证明已经创建成功了!
点击编辑示例!
我们可以在这里对刚刚创建的Runner进行配置修改。
编辑流水线
进入到我们创建的用于测试的项目中,打开"构建"下的流水线编辑器
这里我们先只脚本打印控制台进行测试!
stages:
- build
- image
- deploy
build-job:
stage: build
script:
- echo "正在build项目"
image-job:
stage: image
script:
- echo "正在生成镜像"
deploy-job:
stage: deploy
script:
- echo "正在运行容器"
保存后会自动触发一次流水线
我们可以对刚刚设置的三个阶段进行查看输出
点击build查看控制台,可以看到已经输出了我们设置的打印信息!
因为主要目的是测试提交代码自动部署,并且我的测试案例是控制台应用,因此我这里直接在第一阶段中使用.net 8.0的镜像运行项目!
stages:
- build
build-job:
stage: build
image: mcr.microsoft.com/dotnet/sdk:8.0 # 使用.NET SDK镜像
script:
- cd ConsoleApp1
- dotnet run # 运行应用
在修改完流水线编辑器后,选择保存会自动再构建一次,可以看到我们的项目是运行成功的 !
修改代码并提交
上面的部署流程已经走通,接下来我们在本地修改一下代码,并通过git提交上去。
代码提交后,gitlab会自动触发构建流水线!
在作业的控制台中看到成功输出我们刚刚打印的内容!
以上只是一个监听gitlab代码提交自动触发构建和部署的简单案例,在GitLab CI/CD的实际开发场景中,使用.gitlab-ci.yml
文件来定义构建、测试、部署等流程远比上述简单的示例复杂和多样化。根据你的具体需求和项目规模,你可以通过调整CI/CD流程以适应你的工作流程和环境。