一种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_HOME/data /var/opt/gitlab 用于存储应用程序数据。
$GITLAB_HOME/logs /var/log/gitlab 用于存储日志。
$GITLAB_HOME/config /etc/gitlab 用于存储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

  1. 重新启动gitlab
gitlab-ctl reconfigure 

5)退出gitlab容器

exit

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

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

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

一种DevOpts的实现方式:基于gitlab的CICD(一)_第1张图片

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的入口

一种DevOpts的实现方式:基于gitlab的CICD(一)_第2张图片

创建runners

tags可以选择Run untagged jobs
一种DevOpts的实现方式:基于gitlab的CICD(一)_第3张图片
点击create runner会跳转都runner注册的引导页面
一种DevOpts的实现方式:基于gitlab的CICD(一)_第4张图片
我们在部署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

一种DevOpts的实现方式:基于gitlab的CICD(一)_第5张图片
这里有两点需要注意,首先是runner executor的类别,我们选择的是docker模式的gitlab runner,后续是gitlab-runner所在容器的基础镜像,我们选择centos

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

只是我们可以点击界面上的按钮,跳转到runner界面
一种DevOpts的实现方式:基于gitlab的CICD(一)_第6张图片

一种DevOpts的实现方式:基于gitlab的CICD(一)_第7张图片

基于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,查看执行结果

一种DevOpts的实现方式:基于gitlab的CICD(一)_第8张图片
一种DevOpts的实现方式:基于gitlab的CICD(一)_第9张图片
一种DevOpts的实现方式:基于gitlab的CICD(一)_第10张图片

写在之后

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

你可能感兴趣的:(gitlab)