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

目录

前言Gitlab

环境准备

GitLab部署

拉取GitLab镜像

创建映射目录

运行GitLab容器

修改gitlab.rb配置

开放端口

切换语言

创建项目

添加ssh密钥

克隆代码

CICD

什么是CICD

Gitlab中使用CICD

什么是Runner

[安装GitLab Runner](#安装GitLab Runner)

获取注册令牌

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各部分的详细解释:

  1. 持续集成(Continuous Integration, CI)
  • 定义:持续集成是一种软件开发实践,团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,意味着每天可能会发生多次集成。
  • 核心过程:包括代码编译、代码打包、单元测试、代码静态扫描分析、UI和接口自动化测试等。这些步骤都通过自动化的方式进行,以确保每次集成都稳定可靠。
  • 目的:通过自动化构建和测试来快速发现集成中的错误,从而减少开发后期发现和修复错误的成本。
  1. 持续交付(Continuous Delivery, CD)
  • 定义:持续交付是一种将软件的新版本自动发布到存储代码库(如Git仓库)的能力,但不会自动部署到生产环境。
  • 核心过程:在持续交付中,每个阶段(从代码更改的合并到生产就绪型构建版本的交付)都涉及测试自动化和代码发布自动化。这确保了软件的每个版本都经过充分的测试,并可以随时部署到生产环境。
  • 目的:通过自动化测试和集成,减少部署新代码时所需的工作量,并降低部署风险。
  1. 持续部署(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

因为使用的是交互式注册,接下来会提示我们需要输入一些注册信息:

  1. 输入GitLab实例的URL(例如我的是:http://121.37.28.189)。这是你的GitLab服务器的地址,GitLab Runner将与之通信以接收任务并报告结果。
  2. 输入注册令牌(registration token):上一个步骤中获取的注册令牌,例如我的是:wmEKkxbL7NvjkC-ExwN2。这是一个由GitLab生成的唯一令牌,用于验证新注册的Runner的身份。
  3. 为新注册的Runner提供一个描述,例如:"共享runner"。这个描述可以帮助您识别和管理不同的Runner实例。
  4. 为新注册的Runner添加标签,用逗号分隔,例如:"share,demo"。这些标签可以用于将Runner分配给特定的项目或任务组,以便它们只处理具有相应标签的任务。例如我这里新注册的Runner添加了"share,demo"这两个标签。这意味着这个Runner将只处理带有"share"或"demo"标签的CI/CD任务。如果某个项目的.gitlab-ci.yml文件中指定了这些标签,那么该项目的构建、测试等任务就会由这个Runner来执行
  5. 可选地为新注册的Runner提供一个维护说明,例如:"共享runner"。这个说明可以是任何有助于了解Runner用途的信息。
  6. 选择要使用的执行器(executor),这里选择了"shell"。执行器决定了Runner如何在其环境中执行任务。在这个例子中,我们选择了"shell"执行器,这意味着Runner将在本地主机上的命令行环境中运行任务。
  7. 成功注册Runner后,会显示一条消息提示Runner已成功注册,并建议启动它,如果已经在运行,则配置应该会自动重新加载。这意味着您可以立即开始使用新的Runner来处理任务。
  8. 最后,将带有认证令牌的配置保存在"/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流程以适应你的工作流程和环境。

相关推荐
wowocpp5 小时前
ubuntu 22.04 硬件配置 查看 显卡
linux·运维·ubuntu
山河君5 小时前
ubuntu使用DeepSpeech进行语音识别(包含交叉编译)
linux·ubuntu·语音识别
knighthood20015 小时前
解决:ros进行gazebo仿真,rviz没有显示传感器数据
c++·ubuntu·ros
川石课堂软件测试5 小时前
性能测试|docker容器下搭建JMeter+Grafana+Influxdb监控可视化平台
运维·javascript·深度学习·jmeter·docker·容器·grafana
追风林13 小时前
mac 本地docker-mysql主从复制部署
mysql·macos·docker
A ?Charis14 小时前
Gitlab-runner running on Kubernetes - hostAliases
容器·kubernetes·gitlab
城南vision14 小时前
Docker学习—Docker核心概念总结
java·学习·docker
wclass-zhengge15 小时前
Docker篇(Docker Compose)
运维·docker·容器
wowocpp17 小时前
ubuntu 22.04 server 安装 anaconda3
linux·运维·ubuntu
IT-民工2111017 小时前
CI/CD 实践总结
运维·ci/cd·自动化