预期目标
源代码管理
借助GitLab实现源代码托管,私有化部署版本,创建项目,创建用户组,分配权限,项目的签入/牵出等。
自动化部署
源代码产生变更时(如签入),自动化编译并发布到指定服务器中部署,借助GitLab-runner实现持续交付部署,供用户访问项目新版,这里用在开发环境。
环境说明
硬件基本要求:4核4GRHEL8 Linux operating system:这里用官网提到的 AlamLinux8(安装GitLab时,系统的 /boot 需要有1GB以上的空间)GitLab:用于源代码管理Git:用于远程自动拉取源代码GitLab-runner:用于实现自动化部署的实例dotnet 6.0:测试站点的运行环境
环境安装
最主要的两个安装 GitLab、GitLab-runner 通常会分开部署,这里计划所有的安装均在同一台服务器中。
AlmaLinux8.6 operating system 安装
AlmaLinux官网:https://almalinux.orgGitLab的安装包有800+MB,在安装GitLab时,遇到系统boot分区空间不足的现象,这里需要将系统的 /boot 分区调整为1GB以上的空间。 下图为安装Linux时的分区设置。
GitLab 安装
参考官方提供的安装要求 https://gitlab.cn/install/
安装前提
关于防火墙,需要打开 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
下载/安装 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 如下图所示:
安装 GitLab 应用到系统
# 按照上一步的说明 # 先创建镜像缓存(不是必须,为了后续的快速安装) dnf clean all && dnf makecache # 再安装 GitLab 应用到系统,并绑定访问地址 sudo EXTERNAL_URL="http://{所在服务器IP或域名}" dnf install -y gitlab-jh # 以上仅用 http 的方式,不用 https 方式。
登录到 GitLab 页面
# 安装成功后,首次登陆自动生成的密码存放于:/etc/gitlab/initial_root_password 中(只有24H的保留期限) # 查看密码 cat /etc/gitlab/initial_root_password # # 在浏览器中打开访问地址(安装时设置的 http://{所在服务器IP或域名}) # 启动慢,出现502,需要耐心等待几分钟 # # 然后使用默认管理员账号 root 和查找到的初始密码 进行登录
在 GitLab 中创建项目
为后续的测试效果,这里创建名为 my-project-test 的测试项目,登录页注册用户,管理员后台审核通过,为测试项目添加成员,设置项目成员的相应权限。这里成员设置为 Maintainer 角色。 或创建用户组,把用户组赋予项目,并赋予相应权限。
本地编写源代码,实现文件属性时间的读取功能,并签入到 GitLab 创建的 my-project-test 测试项目中。如下图所示:
到此,通过 GitLab 中提供的功能,实现了源代码的托管。
GitLab-runner 安装
这里 GitLab-runner 主要时通过 GitLab 的项目中 CI/CD 自定义的流水线步骤,来完成自动化部署的任务。 依据官网安装说明:https://docs.gitlab.com/runner/install/linux-manually.html
# 按官网的方式,做以下步骤: # # 下载安装包到指定目录 curl -L --output /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 # 停止
注册 GitLab-runner
首先查看在GitLab页面的 菜单 > 设置 > CI/CD > Runner 中提到的内容。如下图所示:
接下来开始注册 GitLab-runner:
# 按照官网的描述,注册完成后,才可以使用GitLab-runner的实例 # 启动后的注册命令,注册过程中,需要按提示填写几项内容 gitlab-runner register
注册过程中,填写的内容如下图所示:注册完成后,Runner 区域会多出一个 [可用的指定runner实例]。
配置 GitLab-runner
对 [可用的指定runner] 做一个简单的配置,这里设置自动部署的触发条件,以执行 CI/CD 中的流水线。如下图所示:
以上场景:当有新的签入变更时,触发 CI/CD 中流水线的执行。
Git 安装
在自动化部署时,这里计划用 Git 工具来远程拉取源代码,以便于后续的编译发布动作。
dnf install git -y
dotnet 环境
自动部署时,需要编译发布过程,所以这里安装 dotnet-sdk 微软官方提供的镜像站:https://packages.microsoft.com/config/
# 首先安装微软镜像库,以便于从微软镜像站中安装所需的 dotnet-sdk 等 # 这里选用与环境适配的软件库 RHEL8版 下载到 /etc/yum.repos.d/ 中 curl -O /etc/yum.repos.d/ 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(SDK版支持测试、编译、发布、运行等) dnf install dotnet-sdk-6.0 -y
自动化部署配置
首先自定义一个存放部署文件的目录,假设创建 /opt/gitlab-devops-app 作为部署的目录。
# 安装 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
自动化部署 - CI/CD 流水线配置
在CI/CD菜单的编辑器中,先选择对应的项目分支,再配置流水线按钮,自动生成名为 .gitlab-ci.yml 的文件于此项目的根目录; 在这里,流水线配置文件 .gitlab-ci.yml 决定了自动化部署的步骤过程。 起初GitLab会给出一个配置模板,这里将配置好的内容如下:
# 总流程 - 按序运行 # 这里自定义了七个步骤,可按实际情况自定义名称和顺序,通过命令完成部署 stages: # List of stages for jobs, and their order of execution - stop # Job1:停止原有站点运行 - clear # Job2:清除原有部署文件 - clone # Job3:远程克隆源代码 - test # Job4:单元测试 - build # Job5:编译源代码 - publish # Job6:发布项目 - deploy # Job7:重新启动站点运行 # # # # 以下每个作业(步骤节点)对应上述总流程的步骤名称,如下示例每个节点区块格式: # {自定义作业名称}: # stage: {对应上述总流程定义的作业节点名称} # script: # - {按序单行要执行的命令} # - {按序单行要执行的命令} # # # # Job1:停止原有站点运行 stop-job: stage: stop script: - ps -ef | grep Web.dll | grep -v grep | awk '{print $2}' | xargs -r kill -9 && true=0 || false=1 # # Job2:清除原有部署文件 clear-job: stage: clear script: - cd /opt/gitlab-devops-app/ - rm -rvf my-project-test # # Job3:远程克隆源代码 clone-job: stage: clone script: - cd /opt/gitlab-devops-app/ - git clone -b {分支名称} http://{用户名}:{密码}@{ServerIP}/{project-url}/my-project-test.git # # Job4:单元测试;对克隆下来的源代码进行操作 unit-test-job: stage: test script: - cd /opt/gitlab-devops-app/my-project-test/Web/ - dotnet test Web.csproj # # Job5:编译源代码 build-job: stage: build script: - cd /opt/gitlab-devops-app/my-project-test/Web/ - dotnet build --configuration Release # # Job6:发布项目 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/ # # Job7:重新启动站点运行 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 的流水线菜单中会显示一条变更后要执行的任务,并且自动按配置的作业节点执行,自动运行的原因是先前配置了runner的[运行未标记的作业]。效果如下图所示:
从以上配置得出,部署时的站点访问端口为5000,这里需要防火墙开启5000的访问端口。
# 开放测试站点访问的5000端口 firewall-cmd --zone=public --add-port=5000/tcp --permanent firewall-cmd --reload # 查看已开放的端口 firewall-cmd --list-ports
最终效果展示
自动化部署运行效果
部署后的测试站点访问效果
标签:
留言评论