GitLab私有化部署 - CI/CD - 持续集成/交付/部署 - 源代码托管 & 自动化部署 - 码农知识堂

GitLab私有化部署 - CI/CD - 持续集成/交付/部署 - 源代码托管 & 自动化部署
几年前，第一次接触了敏捷开发模式。由合作伙伴安排讲师培训了两周，每天五节课，据吹牛说，对外一节课每人一千多块大洋。由于时间关系项目马上要开始，半个月仅培训了部分重点内容，挺厚的材料也就挑了几个必须的重点章节。第一次接触，比较全面，比较新意，比较系统，认识到有很多新的不同的理念，个人感觉有好多很有用的部分，把团队也管理了，把技术也培养了，把规则也统一了，把流程也优化了。。。自己学到了很多东西，致使我以后在新的工作环境中有很明显的变化和效果。当然更确切的说，它更契合或接近我原本对团队开发的轮廓或展望。有新的东西可以尝试和体会也挺不错的，从中吸收到的东西可以去运用，这就是每个人的经验。会用它，用好它，才能发挥出乎意料的效果。当然也许会说敏捷开发过时了，这都没什么，这段旅程让我收获不少。

说了这么多，还不是本章要阐述的内容啦，嘿嘿。在敏捷开发的过程中，由于是用的收费平台辅助管理，挺贵的，所以我一直在关注免费的CI/CD这块的相关产品，市面上会有很多不同品牌的免费产品组合着运用，以完成开发的整个流程。所以本章要阐述的是(GitLab)同一个平台下完成源代码托管并且CI/CD自动化部署的过程。

不好的地方多提建议，接下来，让我阐述给你听 ...

作者：[Sol·wang] - 博客园，原文出处：https://www.cnblogs.com/Sol-wang/p/16775377.html

一、预期目标

1.1 源代码管理

借助 GitLab 实现源代码托管，私有化部署版本，创建项目，创建用户组，分配权限，项目的维护变更，团队间的协作等。

1.2 自动化部署

项目指定分支(源代码)产生变更时(如签入)，自动化编译并发布到指定服务器中部署，借助GitLab-runner实现持续及时部署，供用户访问项目更新的站点，这里用在开发环境。

1.3 目标总体运行图

二、环境说明
- 硬件基本要求：4核4G
- RHEL8 Linux operating system：这里用GitLab官网提到的 AlamLinux8
- GitLab v15：用于源代码托管
- Git：用于远程自动拉取源代码
- dotnet 6.0：测试站点的运行环境
- GitLab-runner：实现自动化部署的应用
最主要的两个安装 GitLab、GitLab-runner 通常会分开部署，这里计划所有的安装均在同一台服务器中。

三、环境安装
3.1 AlmaLinux8.6 operating system 安装

AlmaLinux官网：https://almalinux.org
Linux系统的安装过程中，这里只提一点，需要注意的是，后续在系统中安装GitLab时，GitLab的安装包有800+MB，遇到系统boot分区空间不足的现象，这里计划将系统的 /boot 分区调整为1GB以上的空间。

下图为安装AlmaLinux8.6时的boot分区设置：

以上现象有没有其它方式解决，咱不知晓，这里选择调整分区大小的方式解决。

3.2 GitLab 安装

参考官方提供的安装要求 https://gitlab.cn/install/

3.2.1 安装前提

关于防火墙，需要打开 HTTP、HTTPS 和 SSH 访问。通常Linux都会默认安装了SSH等常用工具。
(可选) 如果您打算仅从本地网络访问极狐GitLab，则可以跳过它。
```
# OpenSSH 的安装
dnf install -y curl policycoreutils openssh-server openssh-clients
# 开启开机自启动
systemctl enable sshd
# 启动 OpenSSH 服务
systemctl start sshd
#
# 配置永久开启防火墙 http、https
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
# 配置生效
systemctl reload firewalld
```
(可选) GitLab 通过 Postfix 发送电子邮件通知，或者跳过此步骤使用其他解决方案发送电子邮件。
```
# Postfix 的安装
dnf install postfix
# 开启开机自启动
systemctl enable postfix
# 启动 Postfix 服务
systemctl start postfix
```
3.2.2 下载 GitLab 软件源镜像

先下载官方 GitLab 镜像仓库，为了便于后续从此镜像库中安装 GitLab 应用。
```
# 命令下载安装包
curl -fsSL https://packages.gitlab.cn/repository/raw/scripts/setup.sh | /bin/bash
```
GitLab 镜像库下载完成后的说明：
1、镜像库文件 gitlab-jh.repo 保存于 /etc/yum.repos.d/ 目录中
2、生成 gitlab-jh 镜像的缓存
3、再安装 gitlab-jh
如下图所示：

3.2.3 安装 GitLab 应用到系统
```
# 按照上一步的说明：
# 先刷新镜像缓存（这步不是必须，为了后续的快速安装）
dnf clean all && dnf makecache
# 再安装名为 gitlab-jh 的应用到系统，并绑定访问地址
sudo EXTERNAL_URL="http://{所在服务器IP或域名}" dnf install -y gitlab-jh
# 以上仅用 http 的方式，这里不用 https 方式。
```
3.2.4 登录到 GitLab 管理页面

安装成功后，首次登陆自动生成的密码存放于：/etc/gitlab/initial_root_password 中（只有24H的保留期限）
```
# 查看初始密码
cat /etc/gitlab/initial_root_password
```
在浏览器中打开访问地址；安装时设置的 http://{所在服务器IP或域名}
启动慢，出现502，需要耐心等待几分钟。
然后使用默认管理员账号 root 和查找到的初始密码进行登录，记得修改初始密码。

3.3 在 GitLab 中创建项目

为后续的测试效果，这里创建名为 my-project-test 的测试项目，登录页注册用户，管理员后台审核通过，为测试项目添加成员，设置项目成员的相应权限。这里将成员授予 Maintainer 角色。
或创建用户组，把用户组赋予项目，并赋予相应权限。

本地编写源代码，实现文件属性时间的读取功能，并签入到 GitLab 创建的 my-project-test 测试项目中。如下图所示：

到此，通过 GitLab 中提供的功能，实现了源代码的托管。接下来，为自动部署做准备工作。

3.4 Git 安装

安装 Git 是为了，在自动化部署时，这里计划用 Git 工具来远程拉取源代码，以便于后续的编译发布动作。
```
dnf install git -y
```
3.5 dotnet 环境

在自动化部署时，需要有编译发布过程，所以这里需要安装 dotnet-sdk（SDK包括：build、publish、runtime等）
首先安装微软官方提供的镜像库，以便于从微软镜像库中安装所需的 dotnet-sdk 等。
微软官方提供的镜像站：https://packages.microsoft.com/config/
```
# 这里选用与环境适配的软件库 RHEL8版 下载到 /etc/yum.repos.d/ 中
curl -o /etc/yum.repos.d/prod.repo https://packages.microsoft.com/config/rhel/8/prod.repo
# 重建镜像库缓存
dnf clean packages && dnf clean all && dnf makecache
#
# 先安装运行 dotnet 时必要的 libicu 工具
dnf install libicu -y
# 安装适合于开发环境的 dotnet-sdk-6.0
dnf install dotnet-sdk-6.0 -y
```
后续站点部署完成后，计划的站点访问端口定为5000，这里预先开启防火墙5000的端口：
```
# 开放测试站点访问的5000端口
firewall-cmd --zone=public --add-port=5000/tcp --permanent
firewall-cmd --reload
# 查看已开放的端口
firewall-cmd --list-ports
```
3.6 GitLab-runner 安装

这里 GitLab-runner 主要是通过 GitLab 的项目中 CI/CD 自定义的流水线步骤，来完成自动化部署的任务。
依据GitLab官网安装说明：https://docs.gitlab.com/runner/install/linux-manually.html
```
# 按GitLab官网的方式，做以下步骤：
#
# 下载安装包到bin目录
curl -Lo /usr/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
# 授予安装包可运行的权限
chmod +x /usr/bin/gitlab-runner
# 创建 GitLab-runner 的运行账号
useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
# 用指定账号安装 gitlab-runner
gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
# 安装后的 gitlab-runner 服务管理
gitlab-runner start     # 启动
gitlab-runner stop      # 停止
```
3.7 注册 GitLab-runner

首先查看在GitLab项目页面的 菜单 > 设置 > CI/CD > Runner 中提到的内容，将在接下来的注册过程中用到。如下图所示：

接下来开始注册 GitLab-runner：
```
# 按照官网的描述，注册完成后，才可以使用GitLab-runner的实例
# 启动后的注册命令（注册过程中，需要按提示填写几项内容）
gitlab-runner register
```
注册过程中，填写的内容如下图所示：

注册完成后，页面 Runner 区域会多出一个 <可用的指定runner实例>。
四、自动化部署配置
4.1 指定作业目录及权限

首先指定一个存放部署文件的目录，假设创建 /opt/gitlab-devops-app 作为部署的目录。
计划在此目录下，用gitlab-runner来执行流水线中的命令，完成远程克隆源代码、编译发布、启动站点等动作。
因此gitlab-runner需要拥有对此目录的可操作权限：
```
# 安装 gitlab-runner 时，已经创建了名为 gitlab-runner 的用户名
# 这里授予 gitlab-runner 的所属用户对部署文件夹的操作权限
# 赋予所属用户为 gitlab-runner
chown -R gitlab-runner:gitlab-runner /opt/gitlab-devops-app
# 并授予可执行权限
chmod -R +x /opt/gitlab-devops-app
```
在后续流水线的配置中，计划所有的操作以此为根目录。
4.2 CI/CD 中的流水线配置

在项目菜单 CI/CD -> 编辑器中，先选择对应的项目分支，再配置流水线按钮；自动生成名为 .gitlab-ci.yml 的文件于此项目的根目录；
在此流水线编辑器中，GitLab会给出一个配置模板，按指定格式，编写 Shell script 作业命令，达到自动化部署的目标。
所以，分支流水线配置文件 .gitlab-ci.yml 中编写的作业命令，决定了自动化部署的步骤过程。
这里将自定义配置好的内容如下：
```
# 总流程 - 按序运行
# 这里自定义了六个步骤，可按实际情况自定义名称和顺序，通过命令完成部署
stages:           # List of stages for jobs, and their order of execution
  - erase         # Job1：停止/清除原有应用
  - clone         # Job2：远程克隆源代码
  - test          # Job3：单元测试
  - build         # Job4：编译源代码
  - publish       # Job5：发布项目
  - deploy        # Job6：重新启动站点运行
#
#
#
# 以下每个作业(步骤节点)对应上述总流程的步骤名称，如下示例每个作业格式：
# {自定义作业名称}:
#   stage: {对应上述总流程定义的作业节点名称}
#   script:
#   - {按序执行的命令行}
#   - {按序执行的命令行}
#   - {按序执行的命令行}
#
#
#
# Job1：停止/清除原有应用
erase-job:
  stage: erase
  script:
    - ps -ef | grep Web.dll | grep -v grep | awk '{print $2}' | xargs -r kill -9 && true=0 || false=1
    - cd /opt/gitlab-devops-app/
    - rm -rf my-project-test
#
# Job2：远程克隆源代码
clone-job:
  stage: clone
  script:
    - cd /opt/gitlab-devops-app/
    - git clone -b {分支名称} http://{用户名}:{密码}@{ServerIP}/{project-url}/my-project-test.git
#
# Job3：单元测试；对克隆下来的源代码进行操作
unit-test-job:
 stage: test
 script:
   - cd /opt/gitlab-devops-app/my-project-test/Web/
   - dotnet test Web.csproj
#
# Job4：编译源代码
build-job:
  stage: build
  script:
    - cd /opt/gitlab-devops-app/my-project-test/Web/
    - dotnet build --configuration Release
#
# Job5：发布项目
publish-job:
  stage: publish
  script:
    - mkdir /opt/gitlab-devops-app/my-project-test/publish/
    - cd /opt/gitlab-devops-app/my-project-test/Web/
    - dotnet publish --configuration Release --no-build --output ../publish/
#
# Job6：重新启动站点运行
deploy-job:
  stage: deploy
  environment: production
  script:
    - cd /opt/gitlab-devops-app/my-project-test/publish/
    - nohup dotnet Web.dll --urls http://*:5000 > /dev/null 2>&1 &
```
以上配置提交保存后，在 CI/CD 的流水线菜单中会显示一条等待执行的任务，如下图所示：

那么，分支流水线已经配置完成，在什么情况下运行流水线呢？

4.3 触发方式运行

假设的运用场景：在项目的DEV阶段，新的需求功能点开发完成签入后，能及时的呈现出效果。便于个人或团队的使用或测试等。
配置：对页面 runner 区域<可用的指定runner>做一个简单的配置，这里是设置自动部署的触发条件，以便于自动执行指定分支流水线。
如下图所示：

以上设置完成后，当项目变更(或签入)后触发分支流水线运行，以完成自动化部署。
效果如下图所示：

4.4 定时方式运行

假设的运用场景：在项目的UAT阶段，假定Spring的周期为三周，每三周向UAT用户更新版本，展示阶段性成果。
可通过项目菜单 CI/CD -> 计划 的方式，会在特定分支或标签上自动定期定时运行流水线，以完成周期部署的计划。
图例持续更新中...
五、最终呈现效果

5.1 CI/CD 自动化部署运行效果

5.2 自动化部署后的测试站点访问效果
相关阅读:
AT32F407裸机工程创建
 CRM系统销售自动化功能如何提高销售效率
 基于STM32的花卉温室控温系统设计
 数据结构开门篇
 Unity游戏开发基础之数据结构部分
 C++ 关于引用的思考
 【数字IC手撕代码】Verilog轮询仲裁器|题目|原理|设计|仿真
 12.OpenFeign 实例（springcloud）
python LeetCode 刷题记录 69
艾美捷Cas9核酸酶应用说明及实例展示
原文地址：https://www.cnblogs.com/Sol-wang/p/16775377.html

GitLab私有化部署 - CI/CD - 持续集成/交付/部署 - 源代码托管 & 自动化部署

一、预期目标

1.1 源代码管理

1.2 自动化部署

1.3 目标总体运行图

二、环境说明

三、环境安装

3.1 AlmaLinux8.6 operating system 安装

3.2 GitLab 安装

3.2.1 安装前提

3.2.2 下载 GitLab 软件源镜像

3.2.3 安装 GitLab 应用到系统

3.2.4 登录到 GitLab 管理页面

3.3 在 GitLab 中创建项目

3.4 Git 安装

3.5 dotnet 环境

3.6 GitLab-runner 安装

3.7 注册 GitLab-runner

四、自动化部署配置

4.1 指定作业目录及权限

4.2 CI/CD 中的流水线配置

4.3 触发方式运行

4.4 定时方式运行

五、最终呈现效果

5.1 CI/CD 自动化部署 运行效果

5.2 自动化部署后的测试站点访问效果

5.1 CI/CD 自动化部署运行效果