目录
[安装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流程以适应你的工作流程和环境。