🐳 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流程以适应你的工作流程和环境。

828华为云征文｜Flexus X实例GitLab部署&构建流水线-私人一体化代码仓库~

前言Gitlab