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

几年前，第一次接触了敏捷开发模式。由合作伙伴安排讲师培训了两周，每天五节课，据吹牛说，对外一节课每人一千多块大洋。由于时间关系项目马上要开始，半个月仅培训了部分重点内容，挺厚的材料也就挑了几个必须的重点章节。第一次接触，比较全面，比较新意，比较系统，认识到有很多新的不同的理念，个人感觉有好多很有用的部分，把团队也管理了，把技术也培养了，把规则也统一了，把流程也优化了。。。自己学到了很多东西，致使我以后在新的工作环境中有很明显的变化和效果。当然更确切的说，它更契合或接近我原本对团队开发的轮廓或展望。有新的东西可以尝试和体会也挺不错的，从中吸收到的东西可以去运用，这就是每个人的经验。会用它，用好它，才能发挥出乎意料的效果。当然也许会说敏捷开发过时了，这都没什么，这段旅程让我收获不少。关于敏捷开发宣言。
说了这么多，还不是本章要阐述的内容啦，嘿嘿。在敏捷开发的过程中，由于是用的收费平台辅助管理，挺贵的，所以我一直在关注免费的CI/CD这块的相关产品，市面上会有很多不同品牌的免费产品组合着运用，以完成开发的整个流程。所以本章要阐述的是(GitLab)同一个平台下完成源代码托管并且CI/CD自动化部署的过程。
不好的地方多提建议，接下来，让我阐述给你听 ...
我先个人理解下：
Continuous Integration 持续集成 CI：持续追加，持续改善，持续完善。
Continuous Delivery 持续交付 / Continuous Deployment 持续部署 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，则可以跳过它。

1. # OpenSSH 的安装
2. dnf install -y curl policycoreutils openssh-server openssh-clients
3. # 开启开机自启动
4. systemctl enable sshd
5. # 启动 OpenSSH 服务
6. systemctl start sshd
7. #
8. # 配置永久开启防火墙 http、https
9. firewall-cmd --permanent --add-service=http
10. firewall-cmd --permanent --add-service=https
11. # 配置生效
12. systemctl reload firewalld

复制代码

(可选) GitLab 通过 Postfix 发送电子邮件通知，或者跳过此步骤使用其他解决方案发送电子邮件。

1. # Postfix 的安装
2. dnf install postfix
3. # 开启开机自启动
4. systemctl enable postfix
5. # 启动 Postfix 服务
6. systemctl start postfix

复制代码

3.2.2 下载 GitLab 软件源镜像

先下载官方 GitLab 镜像仓库，为了便于后续从此镜像库中安装 GitLab 应用。

1. # 命令下载安装包
2. 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 应用到系统

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

复制代码

3.2.4 登录到 GitLab 管理页面

安装成功后，首次登陆自动生成的密码存放于：/etc/gitlab/initial_root_password 中（只有24H的保留期限）

1. # 查看初始密码
2. 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 工具来远程拉取源代码，以便于后续的编译发布动作。

1. dnf install git -y

复制代码

3.5 dotnet 环境

在自动化部署时，需要有编译发布过程，所以这里需要安装 dotnet-sdk（SDK包括：build、publish、runtime等）
首先安装微软官方提供的镜像库，以便于从微软镜像库中安装所需的 dotnet-sdk 等。
微软官方提供的镜像站：https://packages.microsoft.com/config/

1. # 这里选用与环境适配的软件库 RHEL8版 下载到 /etc/yum.repos.d/ 中
2. curl -o /etc/yum.repos.d/prod.repo https://packages.microsoft.com/config/rhel/8/prod.repo
3. # 重建镜像库缓存
4. dnf clean packages && dnf clean all && dnf makecache
5. #
6. # 先安装运行 dotnet 时必要的 libicu 工具
7. dnf install libicu -y
8. # 安装适合于开发环境的 dotnet-sdk-6.0
9. dnf install dotnet-sdk-6.0 -y

复制代码

后续站点部署完成后，计划的站点访问端口定为5000，这里预先开启防火墙5000的端口：

1. # 开放测试站点访问的5000端口
2. firewall-cmd --zone=public --add-port=5000/tcp --permanent
3. firewall-cmd --reload
4. # 查看已开放的端口
5. firewall-cmd --list-ports

复制代码

3.6 GitLab-runner 安装

这里 GitLab-runner 主要是通过 GitLab 的项目中 CI/CD 自定义的流水线步骤，来完成自动化部署的任务。
依据GitLab官网安装说明：https://docs.gitlab.com/runner/install/linux-manually.html

1. # 按GitLab官网的方式，做以下步骤：
2. #
3. # 下载安装包到bin目录
4. curl -Lo /usr/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
5. # 授予安装包可运行的权限
6. chmod +x /usr/bin/gitlab-runner
7. # 创建 GitLab-runner 的运行账号
8. useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
9. # 用指定账号安装 gitlab-runner
10. gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
11. # 安装后的 gitlab-runner 服务管理
12. gitlab-runner start     # 启动
13. gitlab-runner stop      # 停止

复制代码

3.7 注册 GitLab-runner

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

接下来开始注册 GitLab-runner：

1. # 按照官网的描述，注册完成后，才可以使用GitLab-runner的实例
2. # 启动后的注册命令（注册过程中，需要按提示填写几项内容）
3. gitlab-runner register

复制代码

注册过程中，填写的内容如下图所示：

注册完成后，页面 Runner 区域会多出一个 。
四、自动化部署配置

4.1 指定作业目录及权限

首先指定一个存放部署文件的目录，假设创建 /opt/gitlab-devops-app 作为部署的目录。
计划在此目录下，用 gitlab-runner 来执行流水线中的命令，完成远程克隆源代码、编译发布、启动站点等动作。
因此 gitlab-runner 需要拥有对此目录的可操作权限：

1. # 安装 gitlab-runner 时，已经创建了名为 gitlab-runner 的用户名
2. # 这里授予 gitlab-runner 的所属用户对部署文件夹的操作权限
3. # 赋予所属用户为 gitlab-runner
4. chown -R gitlab-runner:gitlab-runner /opt/gitlab-devops-app
5. # 并授予可执行权限
6. chmod -R +x /opt/gitlab-devops-app

复制代码

在后续流水线的配置中，计划所有的操作以此为根目录。4.2 CI/CD 中的流水线配置

在项目菜单CI/CD > 编辑器中，先选择对应的项目分支，再配置流水线按钮；自动生成名为 .gitlab-ci.yml 的文件于此项目的根目录；
在此流水线编辑器中，GitLab会给出一个配置模板，按指定格式，编写 Shell script 作业命令，达到自动化部署的目标。
所以，分支流水线配置文件 .gitlab-ci.yml 中编写的作业命令，决定了自动化部署的步骤过程。
这里将自定义配置好的内容如下：

1. # 总流程 - 按序运行
2. # 这里自定义了六个步骤，可按实际情况自定义名称和顺序，通过命令完成部署
3. stages:           # List of stages for jobs, and their order of execution
4.   - erase         # Job1：停止/清除原有应用
5.   - clone         # Job2：远程克隆源代码
6.   - test          # Job3：单元测试
7.   - build         # Job4：编译源代码
8.   - publish       # Job5：发布项目
9.   - deploy        # Job6：重新启动站点运行
10. #
11. #
12. #
13. # 以下每个作业(步骤节点)对应上述总流程的步骤名称，如下示例每个作业格式：
14. # {自定义作业名称}:
15. #   stage: {对应上述总流程定义的作业节点名称}
16. #   script:
17. #   - {按序执行的命令行}
18. #   - {按序执行的命令行}
19. #   - {按序执行的命令行}
20. #
21. #
22. #
23. # Job1：停止/清除原有应用
24. erase-job:
25.   stage: erase
26.   script:
27.     - ps -ef | grep Web.dll | grep -v grep | awk '{print $2}' | xargs -r kill -9 && true=0 || false=1
28.     - cd /opt/gitlab-devops-app/
29.     - rm -rf my-project-test
30. #
31. # Job2：远程克隆源代码
32. clone-job:
33.   stage: clone
34.   script:
35.     - cd /opt/gitlab-devops-app/
36.     - git clone -b {分支名称} http://{用户名}:{密码}@{ServerIP}/{project-url}/my-project-test.git
37. #
38. # Job3：单元测试；对克隆下来的源代码进行操作
39. unit-test-job:
40. stage: test
41. script:
42.    - cd /opt/gitlab-devops-app/my-project-test/Web/
43.    - dotnet test Web.csproj
44. #
45. # Job4：编译源代码
46. build-job:
47.   stage: build
48.   script:
49.     - cd /opt/gitlab-devops-app/my-project-test/Web/
50.     - dotnet build --configuration Release
51. #
52. # Job5：发布项目
53. publish-job:
54.   stage: publish
55.   script:
56.     - mkdir /opt/gitlab-devops-app/my-project-test/publish/
57.     - cd /opt/gitlab-devops-app/my-project-test/Web/
58.     - dotnet publish --configuration Release --no-build --output ../publish/
59. #
60. # Job6：重新启动站点运行
61. deploy-job:
62.   stage: deploy
63.   environment: production
64.   script:
65.     - cd /opt/gitlab-devops-app/my-project-test/publish/
66.     - 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 自动化部署后的测试站点访问效果

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！