酷酷是懒虫

这个屌丝很懒，什么也没留下！

热门标签

【基于 GitLab 的 CI/CD 实践】01、GitLab CI/CD 基础概念_gitlab cicd

作者：酷酷是懒虫 | 2024-08-25 14:15:24

踩

gitlab cicd

2.5 GitLab CI/CD 工作原理

三、GitLabCI VS Jenkins

一、为什么要做 CI/CD ？

1.1 背景-传统的应用开发发布模式

开发团队：在开发环境中完成软件开发，单元测试，测试通过，提交到代码版本管理库。
运维团队：把应用部署到测试环境，供QA团队测试，测试通过后部署生产环境。
QA 团队：进行测试，测试通过后通知部署人员发布到生产环境。

问题

错误发现不及时：很多错误在项目的早期可能就存在，到最后集成的时候才发现问题。
人工低级错误发生：产品和服务交付中的关键活动全都需要手动操作。
团队工作效率低：需要等待他人的工作完成后才能进行自己的工作。
开发运维对立： 开发人员想要快速更新，运维人员追求稳定，各自的针对的方向不同。

经过上述问题我们需要作出改变，如何改变？

1.2 持续集成与持续交付

软件开发的连续方法基于自动执行脚本，以最大程度地减少在开发应用程序时引入错误的机会。从开发新代码到部署新代码，他们几乎不需要人工干预，甚至根本不需要干预。

它涉及到在每次小的迭代中就不断地构建，测试和部署代码更改，从而减少了基于错误或失败的先前版本开发新代码的机会。

此方法有三种主要方法，每种方法都将根据最适合您的策略的方式进行应用。

持续集成（CI）

持续合并开发人员正在开发编写的所有代码的一种做法。通常一天内进行多次合并和提交代码，从存储库或生产环境中进行构建和自动化测试，以确保没有集成问题并及早发现任何问题。

开发人员提交代码的时候一般先在本地测试验证，只要开发人员提交代码到版本控制系统就会触发一条提交流水线，对本次提交进行验证。

持续交付（CD）

持续交付是超越持续集成的一步。不仅会在推送到代码库的每次代码更改时都进行构建和测试，而且，作为附加步骤，即使部署是手动触发的，它也可以连续部署。此方法可确保自动检查代码，但需要人工干预才能从策略上手动触发更改的部署。

持续部署（CD）

通常可以通过将更改自动推送到发布系统来随时将软件发布到生产环境中。持续部署会更进一步，并自动将更改推送到生产中。类似于持续交付，持续部署也是超越持续集成的又一步。不同之处在于，您无需将其手动部署，而是将其设置为自动部署。部署您的应用程序完全不需要人工干预。

1.3 CI/CD 的价值体现

尽早反馈，尽早发现错误。
减少集成问题，每次发现问题当时解决，避免问题堆积。
每次更改都能成功发布，降低发布风险。
更加频繁的交付价值，客户反馈。

1.4 推荐常用的 CI/CD 工具

Jenkins

专业的 CI 工具，可扩展自动化服务器、安装配置简单、丰富的插件库、分布式架构设计、支持所有的平台、可视化的管理页面。

GitLab

端到端 DevOps 工具，常用功能：代码审查、问题跟踪、动态订阅、易于扩展、项目 wiki、多角色项目管理、项目代码在线编译预览、CI 工具集成。

提交合并代码集成：通过 git push 进行操作或者在 GitLab Web 页面操作。
发布应用到服务器：获取制品库中的应用，然后用 salt、ansible 发布部署到服务器。
完全自动化：提交代码 -> 构建部署 -> 发布

二、GitLab CI/CD 功能简介

2.1 GitLab 内置持续集成功能

持续集成（CI）

集成团队中每个开发人员提交的代码到代码存储库中。
开发人员在 Merge 或者 Pull 请求中合并拉取新代码。
在提交或者合并更改到代码存储库之前，会触发了构建，测试和新代码验证的管道。
CI 可帮助您在开发周期的早期发现并减少错误。

连续交付（CD）

可通过结构化的部署管道确保将经过 CI 验证的代码交付给您的应用程序。
CD 可以将经过验证的代码更快地移至您的应用程序。

CI/CD 一起可以加快团队为客户和利益相关者交付成果的速度。CI 和 CD 必须无缝协作，以使您的团队快速有效地进行构建，并且对于确保完全优化的开发实践至关重要。

2.2 GitLab CI/CD 优势

开源：CI/CD 是开源 GitLab 社区版和专有 GitLab 企业版的一部分。
易于学习：具有详细的入门文档。
无缝集成：GitLab CI/CD 是 GitLab 的一部分，支持从计划到部署,具有出色的用户体验。
可扩展：测试可以在单独的计算机上分布式运行，可以根据需要添加任意数量的计算机。
更快的结果：每个构建可以拆分为多个作业，这些作业可以在多台计算机上并行运行。
针对交付进行了优化：多个阶段，手动部署，环境和变量。

2.3 GitLab CI/CD 特点

多平台：Unix，Windows，macOS 和任何其他支持 Go 的平台上执行构建。
多语言：构建脚本是命令行驱动的，并且可以与 Java，PHP，Ruby，C 和任何其他语言一起使用。
稳定构建：构建在与 GitLab 不同的机器上运行。
并行构建：GitLab CI/CD 在多台机器上拆分构建，以实现快速执行。
实时日志记录：合并请求中的链接将您带到动态更新的当前构建日志。
灵活的管道：您可以在每个阶段定义多个并行作业，并且可以触发其他构建。
版本管道：一个 .gitlab-ci.yml 文件包含您的测试，整个过程的步骤，使每个人都能贡献更改，并确保每个分支获得所需的管道。
自动缩放：您可以自动缩放构建机器，以确保立即处理您的构建并将成本降至最低。
构建工件：您可以将二进制文件和其他构建工件上载到 GitLab 并浏览和下载它们。
Docker 支持：可以使用自定义 Docker 镜像，作为测试的一部分启动服务，构建新的Docker 镜像，甚至可以在 Kubernetes 上运行。
容器注册表：内置的容器注册表，用于存储，共享和使用容器镜像。
受保护的变量：在部署期间使用受每个环境保护的变量安全地存储和使用机密。
环境：定义多个环境。

2.4 GitLab CI/CD 架构

GitLab CI/CD

GitLab 的一部分，GitLab 是一个 Web 应用程序，具有将其状态存储在数据库中的 API。除了 GitLab 的所有功能之外，它还管理项目/构建并提供一个不错的用户界面。

GitLab Runner

是一个处理构建的应用程序。它可以单独部署，并通过 API 与 GitLab CI/CD一起使用。

.gitlab-ci.yml

定义流水线作业运行，位于应用项目根目录下。

为了运行测试，我们后面至少需要一个 GitLab 实例、一个 GitLab Runner、一个 gitlab-ci 文件。

2.5 GitLab CI/CD 工作原理

将代码托管到 Git 存储库。
在项目根目录创建 ci 文件 .gitlab-ci.yml ，在文件中指定构建，测试和部署脚本。
GitLab 将检测到它并使用名为 GitLab Runner 的工具运行脚本。
脚本被分组为作业，它们共同组成了一个管道。

管道状态也会由 GitLab 显示：

最后，如果出现任何问题，可以轻松地回滚所有更改：

三、GitLabCI VS Jenkins

Jenkins 是一个广泛用于持续集成的可视化 web 自动化工具，jenkins 可以很好的支持各种语言的项目构建，也完全兼容 ant、maven、gradle等多种第三方构建工具，同时跟 svn、git能无缝集成，也支持直接与知名源代码托管网站，比如 github、bitbucket直接集成，而且插件众多，在这么多年的技术积累之后，在国内大部分公司都有使用 Jenkins。

gitlab-CI是 gitlab8.0之后自带的一个持续集成系统，中心思想是当每一次 push到 gitlab的时候，都会触发一次脚本执行，然后脚本的内容包括了测试，编译，部署等一系列自定义的内容。

gitlab-CI的脚本执行，需要自定义安装对应 gitlab-runner来执行，代码 push之后，webhook检测到代码变化，就会触发 gitlab-CI，分配到各个 Runner来运行相应的脚本 script。这些脚本有的是测试项目用的，有的是部署用的。

3.1 差异点对比

分支的可配置性

使用 GitLabCI，新创建的分支无需任何进一步配置即可立即使用 CI 管道中的已定义作业。
Jenkins 2 基于 gitlab 的多分支流水线可以实现。相对配置来说 gitlab 更加方便一些。

定时执行构建

有时，根据时间触发作业或整个管道会有所帮助。例如，常规的夜间定时构建。

使用 Jenkins 2 可以立即使用。可以在应执行作业或管道的那一刻以 cron 式语法定义。
GitLab CI 没有此功能。但是，可以通过一种变通办法来实现：通过 WebAPI 使用同一台或另一台服务器上的 cronjob 触发作业和管道。

尽管使用 GitLab CI 无法做到这一点，其实如果配置了提交代码即触发流水线，那么最后一次提交的构建在什么时候没有什么不同，反而减少未提交代码的定时构建资源浪费。

拉取请求支持

如果很好地集成了存储库管理器和 CI / CD 平台，您可以看到请求的当前构建状态。使用这种功能，可以避免将代码合并到不起作用或无法正确构建的主分支中。

Jenkins 没有与源代码管理系统进一步集成，需要管理员自行写代码或者插件实现。
GitLab 与其 CI 平台紧密集成，可以方便查看每个打开和关闭拉动请求的运行和完成管道。

权限管理

从存储库管理器继承的权限管理对于不想为每个服务分别设置每个用户的权限的大型开发人员或组织团体很有用。大多数情况下，两种情况下的权限都是相同的，因此默认情况下应将它们配置在一个位置。

由于 GitLab 与 GitLabCI 的深度整合，权限可以统一管理。
由于 Jenkins 2 没有内置的存储库管理器，因此它无法直接在存储库管理器和 CI / CD 平台之间合并权限。

存储库交互

GitLab CI 是 Git 存储库管理器 GitLab 的固定组件，因此在 CI / CD 流程和存储库功能之间提供了良好的交互。
Jenkins 2 与存储库管理器都是松散耦合的，因此在选择版本控制系统时它非常灵活。此外，就像其前身一样，Jenkins 2 强调了对插件的支持，以进一步扩展或改善软件的现有功能。

插件管理

扩展 Jenkins 的本机功能是通过插件完成的。插件的维护，保护和升级成本很高。
GitLab 是开放式的，任何人都可以直接向代码库贡献更改，一旦合并，它将自动测试并维护每个更改。

3.2 优势与劣势

GitLabCI

轻量级，不需要复杂的安装手段。
配置简单，与 gitlab可直接适配。
实时构建日志十分清晰，UI交互体验很好
使用 YAML 进行配置，任何人都可以很方便的使用。
没有统一的管理界面，无法统筹管理所有项目
配置依赖于代码仓库，耦合度没有 Jenkins低

Jenkins

编译服务和代码仓库分离，耦合度低
插件丰富，支持语言众多。
有统一的 web管理界面。
插件以及自身安装较为复杂。
体量较大，不是很适合小型团队。

3.3 实际应用

GitLabCI 有助于 DevOps 人员，例如敏捷开发中，开发与运维是同一个人，最便捷的开发方式。（小团队）
JenkinsCI 适合在多角色团队中，职责分明、配置与代码分离、插件丰富。

四、安装部署 GitLab 服务

GitLab 官方安装方法：GitLab下载安装_GitLab最新中文免费版下载安装-极狐GitLab

4.1 rpm 方式

清华源地址：Index of /gitlab-ce/yum/el7/ | 清华大学开源软件镜像站 | Tsinghua Open Source Mirror


# 下载安装包
wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-15.3.3-ce.0.el7.x86_64.rpm
 
# 安装
yum install -y curl policycoreutils-python openssh-server perl
rpm -ivh gitlab-ce-15.3.3-ce.0.el7.x86_64.rpm
 
# 编辑站点地址（服务器节点的 ip）
vim /etc/gitlab/gitlab.rb
external_url 'http://192.168.170.133' 
 
# 重载配置（过程会比较久，耐心等待）
gitlab-ctl reconfigure  
 
# GitLab 服务控制
gitlab-ctl start      # 启动服务   
gitlab-ctl status     # 查看状态
gitlab-ctl stop       # 停止服务

注：此方式安装的 GitLab 服务是开机自启的服务。

4.2 Docker 方式

参考官方文档：极狐GitLab Docker 镜像 | 极狐GitLab

4.3 Kubernetes 部署

参考官方文档：使用 Helm 安装极狐GitLab | 极狐GitLab

下一篇文章：【基于 GitLab 的 CI/CD 实践】02、gitlab-runner 实践_Stars.Sky的博客-CSDN博客

声明：本文内容由网友自发贡献，转载请注明出处：【wpsshop】