一种DevOpts的实现方式：基于gitlab的CICD（一）

写在之前

笔者最近准备开始入坑CNCF毕业的开源项目，看到其中有一组开源项目的分类就是DevOpts。这个领域内比较出名的项目是Argocd，Argo CD 是一个用于 Kubernetes 的持续交付 (Continuous Delivery) 工具，它以声明式的方式实现了应用程序的自动化部署和持续集成。Argo CD 借助 Kubernetes 的资源对象来定义应用程序，提供了一个直观的 Web 用户界面以及一个命令行界面（CLI）来管理和监控 Kubernetes 上的应用。

Argo CD 是基于 GitOps 的持续交付工具。GitOps 是一种由 Weaveworks 发明的持续交付方法，它结合了 Git 和 Kubernetes，以实现一种强大的基础设施即代码（Infrastructure as Code，IaC）模式。
在 GitOps 中，对基础设施的任何更改都应该以 Git 上的代码提交的形式实现。Argo CD 能够与 Git 存储库进行集成，自动从Git 存储库拉取与预期状态相符的应用程序描述，并自动将该应用程序部署到 Kubernetes 中。Argo CD 还实现了自动同步和协调机制来确保应用程序的运行状态与 Git 中定义的期望状态保持一致。
通过 GitOps 和 Argo CD，用户可以快速构建、测试和管理他们的应用程序，并快速进行版本控制和回滚。以这种方式管理基础设施，可以大大提高应用程序的可靠性、安全性和可重复性。

基于github+argocd的这套流程中，其实有有一个东西没有闭环，那就是argocd本身是可以私有化部署的，但是github本身是不提供私有化部署版本的，这就导致我们在实际开发的时候，必须将代码托管到github上。好在gitlab提供了私有化部署的方式，且gitlab本身也具有cicd的完整解决方案。本文将围绕gitlab官网的描述，逐步阐述自己的实现过程，期望能够带给大家一定的启发。

gitlab的官方文档：https://docs.gitlab.com/ee/

概念

CICD：是持续集成与持续交付（Continuous Integration and Continuous Delivery）的简称。它是一种软件开发实践，通过自动化的构建、测试和部署过程，实现团队快速交付高质量的软件。持续集成（CI）指在代码开发过程中，频繁地将代码集成到共享代码仓库，并进行自动化的构建和测试。持续交付（CD）则是在持续集成的基础上，将经过测试的代码自动部署到生产环境中。

DevOps：是开发（Development）与运维（Operations）的组合词，它是一种软件开发文化和工作方式。DevOps的目标是通过开发团队和运维团队之间的合作与整合，提高软件开发和运维的效率和质量。通过自动化工具和流程，DevOps实践着持续集成、持续交付和持续部署，促进开发与运维之间的协作和沟通，加速软件开发和部署的速度，提高软件的稳定性和可靠性。

我的理解是：
ci的过程就是代码的集成、打包、将制品分发到不同的私有物料仓库
cd：将代码打包的镜像等物料，批量部署到指定的机器上

gitlab的版本许可

gitlab的版本即许可
建议大家在安装gitlab的时候能够正确辨别不同版本的权限边界；
ps：吐槽一下，官方文档非常详细，但是文章大多篇幅不大，数量太多了，文档中那个的链接层层嵌套，按理说这个版本应该放在文档开头提供的，结果笔者找了半天

gitlab的安装

官方文档中给出了多种安装方式（Helm、docker、二进制），本文选择使用docker安装gitlab的测试环境。

步骤一：初始化gitlab的工作目录

# 设置gitlab的工作目录
GITLAB_HOME=/srv/gitlab
mkdir -p $GITLAB_HOME
echo "export GITLAB_HOME=$GITLAB_HOME" >> ~/.bash_profile
source ~/.bash_profile

gitlab容器和宿主机的目录映射关系如下表所示：

步骤二：启动gitlab容器

#运行如下命令启动gitlab的docker容器
sudo docker run --detach 
  --hostname gitlab.example.com 
  --publish 443:443 --publish 80:80 --publish 22:22 
  --name gitlab 
  --restart always 
  --volume $GITLAB_HOME/config:/etc/gitlab 
  --volume $GITLAB_HOME/logs:/var/log/gitlab 
  --volume $GITLAB_HOME/data:/var/opt/gitlab 
  --shm-size 256m registry.gitlab.cn/omnibus/gitlab-jh:latest

上述命令有几点需要注意：

• 如果机器没有配置域名解析的话，建议hostname可以不用传递
• 如果机器的443或22、80端口被占用了可以仿照笔者执行如下步骤修改gitlab的端口

1）修改gitlab容器的启动命令

sudo docker run --detach 
  --publish 8000:8000 --publish 2200:22 
  --name gitlab 
  --restart always 
  --volume $GITLAB_HOME/config:/etc/gitlab 
  --volume $GITLAB_HOME/logs:/var/log/gitlab 
  --volume $GITLAB_HOME/data:/var/opt/gitlab 
  --shm-size 256m  gitlab/gitlab-ce:latest

2）进入容器内部

#进入容器
sudo docker exec -it gitlab /bin/bash

3）修改/etc/gitlab/gitlab.rb文件

vi /etc/gitlab
#修改值
external_url "http://gitlab.example.com:8000"
#添加值
gitlab_rails['gitlab_shell_ssh_port'] = 2200

4. 重新启动gitlab

gitlab-ctl reconfigure 

5）退出gitlab容器

exit

步骤三：获取root账户的初始密码

#在宿主机上执行
sudo docker exec -it gitlab grep 'Password:' /etc/gitlab/initial_root_password

此时，我们可以在ui界面上验证我们部署的gitlab程序了

gitlab-runner安装

gitLab Runner 是一个与 GitLab CI/CD 集成的开源项目，用于执行自动化构建和部署任务。它允许您在 GitLab上创建管道 (pipeline)，并使用配置文件定义和管理不同的阶段和任务。GitLab Runner 可以安装在各种操作系统上，并作为一个代理程序运行，负责执行 GitLab CI/CD 中定义的作业。它可以与 GitLab服务器进行通信，接收要执行的作业，并将结果返回给 GitLab。

下面给出两中安装方式：

• 一种是二进制安装方式，该方式主要是利用gitlab-runner的宿主机环境执行cicd的工作流程
• 一种是docker安装方式，该方式主要是采用了类似于docker in docker的形式，gitlab-runner被包装在docker容器内，整个工作流程是在docker容器内执行的，其中每一个作业都可以定制的在不同的容器镜像环境下执行。该方式后文演示demo的时候会详细解读。
• 官方文档不建议gitlab和gitlab-runner部署在同一台机器上，所以后文的gitlab-runner是部署在另一台机器上的。

二进制安装方式

下面给出ubuntu下的安装脚本，其余操作系统可以从下面的链接中找到对应的二进制包进行安装

# 选择合适的deb包
curl -LJO "https://gitlab-runner-downloads.s3.amazonaws.com/latest/deb/gitlab-runner_amd64.deb"
# 安装deb文件
dpkg -i gitlab-runner_amd64.deb

docker安装方式

此设置将对 Docker 守护进程的完全控制权委托给每个 GitLab Runner 容器。其效果是，如果你在还运行其他有效负载的 Docker 守护进程中运行 GitLab Runner，隔离保证会中断。所以不能在有k8s纳管的机器上部署docker版本的gitlab-runner容器。

docker run -d --name gitlab-runner --restart always 
    -v /var/run/docker.sock:/var/run/docker.sock 
    -v gitlab-runner-config:/etc/gitlab-runner 
    gitlab/gitlab-runner:latest

gitlab-runner的注册

上文中我们安装了gitlab-runner，但是有一个问题我们一直没有解决：gitlab-runner和gitlab部署在不同的机器上，两者是怎么建立关联的。

在UI界面上创建分组后找到runner的入口

创建runners

tags可以选择Run untagged jobs

点击create runner会跳转都runner注册的引导页面

我们在部署gitlab-runner的机器上依次执行上述命令。我们以docker容器启动的gitlab-runner为例，详细展示注册流程，二进制安装的gitlab-runner的注册流程一致
step1：注册gitlab-runner

#首先我们需要先进入到容器内部
docker exec -it gitlab-runnner /bin/bash
#执行注册命令，该命令从UI界面上copy
gitlab-runner register  --url http://XXX --token xxx

这里有两点需要注意，首先是runner executor的类别，我们选择的是docker模式的gitlab runner，后续是gitlab-runner所在容器的基础镜像，我们选择centos

#注册成功后退出容器
exit
#重启容器
docker restart gitlab-runner

只是我们可以点击界面上的按钮，跳转到runner界面

基于gitlab的简单实践

官方文档给出的demo:https://docs.gitlab.com/ee/ci/quick_start/

前置条件： 基于前文描述，诸位如果已经搭建好gitlab+gitlab-runner的环境后，可基于此来验证gitlab cicd的完整执行流程

步骤一： 从UI界面上已经绑定runner的group分组中创建一个项目,并在项目的根目录下创建.gitlab-ci.yml文件，文件内容如下：

build-job:
  stage: build
  script:
    - echo "Hello, $GITLAB_USER_LOGIN!"

test-job1:
  stage: test
  script:
    - echo "This job tests something"

test-job2:
  stage: test
  script:
    - echo "This job tests something, but takes more time than test-job1."
    - echo "After the echo commands complete, it runs the sleep command for 20 seconds"
    - echo "which simulates a test that runs 20 seconds longer than test-job1"
    - sleep 20

deploy-prod:
  stage: deploy
  script:
    - echo "This job deploys something from the $CI_COMMIT_BRANCH branch."
  environment: production

步骤二：点击pipelines，查看执行结果

写在之后

期望本文可以为大家揭开基于gitlab的cicd的神秘面纱。笔者没有详细介绍gitlab-ci.yaml的语法规范，也没有部署高可用的gitlab和gitlab-runner，这些在gitlab官网中均有详细的介绍。笔者实践后的是：基于gitlab的cicd流程能够很好的契合小团队的并行开发和部署。后续文章将介绍官网的一个前端部署实例

代码007普通

打赏 收藏 海报 链接