0-基础篇-基于serverless容器实现JenkinsCI的相关流程和价值介绍
【摘要】 基于serverless容器实现CI的相关流程和价值介绍
一 背景
持续集成CI
是机器、平台、构建工具链和操作系统的混合体。理想情况下,用户希望在管理这些环境时具有尽可能多的灵活性,例如构建机器可以互换,并且不希望将构建绑定到特定机器。使用Kubernetes容器作为构建代理是获得更快、更有效地创建应用程序所需的灵活性的有效方法。
持续集成CI和持续交付CD在现代软件开发中变得非常重要,可确保更快、更可靠地交付应用程序。 Jenkins 和 Kubernetes 结合起来,提供了一个强大的解决方案,用于自动化容器化应用程序的构建、测试和部署。本文将探讨使用 Jenkins 和 Kubernetes 构建强大的 CI/CD 流程,创建无缝且高效的软件开发生命周期。
二 Jenkins on Kubernetes
Jenkins 是一个具有悠久历史且不断发展的 CI/CD 工具。其master/slave架构非常适合运行分布式构建的可扩展性场景。集成和使用 Jenkins 代理的方法有很多:从使用物理机(裸机)到虚拟机、Docker 容器或 Kubernetes 集群。
2.1 Jenkins工作流程
开发者提交代码变更
: 开发人员通过向源代码仓库提交变更启动软件开发周期。Jenkins Master 检查代码仓库
:Jenkins Master 持续监听代码仓库中新提交的变更 以启动持续集成 (CI)Jenkins Agent 编译代码
: Jenkins Slave 执行构建任务,拉取最新代码进行编译和测试等任务。拉取代码后,它将被编译为可执行文件,并启动构建过程。如Jenkins Agent推送镜像
: Jenkins Slave节点会根据配置的Dockerfile文件进行容器镜像的制作,然后推送到镜像仓库,以供后续应用部署
2.2 Jenkins部署架构
Jenkins部署分为以下两种模式:
- 一种是直接使用单Master安装Jenkins,直接进行任务管理和业务构建发布,操作简单,但任务管理和执行没有分离,可能存在一定的生产安全风险。
- 一种是Master加Agent模式。Master节点主要是处理调度构建作业,把构建分发到Agent实际执行,监视Agent的状态。业务构建发布的工作交给Agent进行,即执行Master分配的任务,并返回任务的进度和结果。
其中Jenkins的Master和Agent均可安装在虚拟机或容器中,组合形式多种多样。
传统虚机/物理机部署的Jenkins Slave 一主多从方式会存在一些痛点,比如:
- 主 Master 发生单点故障时,整个流程都不可用了
- 每个 Slave 的配置环境不一样,来完成不同语言的编译打包等操作,但是这些差异化的配置导致管理起来非常不方便,维护起来也是比较费劲
- 资源分配不均衡,有的 Slave 要运行的 job 出现排队等待,而有的 Slave 处于空闲状态
资源有浪费,每台 Slave 可能是物理机或者虚拟机,当 Slave 处于空闲状态时,也不会完全释放掉资源。 - 一般建议无论是Master或者Agent都建议部署在容器上,可以利用K8s的容器调度机制实现master自愈能力,同时动态agent的使用方式还能提高资源利用率
2.3 Jenkins 容器化部署的优势
Jenkins 和 Kubernetes 集群的集成是一个很好的解决方案:Kubernetes 上的动态 Jenkins agent是轻量级的,可在几秒钟内按需初始化;同时借助 Kubernetes 节省资源/成本(Jenkins agent Pod仅在构建任务时存在)。
- 动态扩展: Kubernetes 支持根据工作负载需求动态扩展 Jenkins 实例。凭借自动扩展资源的能力,Jenkins 可以有效地处理不同的工作负载,确保在高需求期间实现最佳资源利用率,并在活动较低期间缩减规模。这种弹性提高了 CI/CD 管道的整体效率。
- 优化资源效率使用:利用 Kubernetes 允许 Jenkins 在可以快速实例化或终止的轻量级容器中运行。这种方法优化了资源利用率,因为容器共享底层主机操作系统内核,从而减少开销并更有效地利用计算资源。 Jenkins 工作负载可以在容器内隔离,防止干扰并增强整体系统稳定性。
- 声明式配置: Kubernetes 允许通过 YAML 文件对 Jenkins 实例进行声明性配置,从而实现基础设施即代码实践。这简化了 Jenkins 环境的设置和维护,因为配置更改可以进行版本控制并在不同的集群或环境中一致应用。声明性方法可确保一致性并降低配置漂移的风险。
- 高可用性和可靠性:Kubernetes 的架构通过将 Jenkins master实例和Jenkins agent实例分布在集群中的多个节点上来提升高可用性。在发生故障事件时,Kubernetes 自动将 Jenkins 工作负载重新调度到健康节点,确保 CI/CD 流程不间断。这种弹性有助于提高基于 Jenkins 的工作流程的整体可靠性。
- 轻松实现更新和回滚:Kubernetes 促进 Jenkins 实例的无缝更新和回滚。借助滚动升级等功能,可以在不停机的情况下逐步引入新的 Jenkins 版本。如果出现问题,可以快速执行回滚,最大限度地减少对开发流程的影响。这种灵活性增强了基于 Jenkins 的 CI/CD 工作流程的敏捷性。
- 统一环境:Kubernetes 为运行 Jenkins 提供了一致的环境,无论底层基础设施如何。这种一致性简化了开发和测试流程,因为 Jenkins 作业可以跨各种集群、云提供商或本地数据中心统一执行。这种一致性减少了潜在的兼容性问题并简化了整个工作流程。
三 Jenkins on serverless
与任何新的技术一样,“serverless”一词通常具有不同的含义。serverless是一种技术模式,它提供服务和概念,以最大限度地减少管理服务器带来的维护开销。它是一个强大的抽象,使用时可以只聚焦应用专注于构建和部署应用,无需管理集群底层基础设施 。有时,serverless被过度简化为功能即服务function-as-a-service (faas)。另外,很少有用户谈论使用serverless进行 CI/CD,现实情况就是有代码的地方仍然需要持续集成CI和持续交付CD。
3.1 CCE AutoPilot集群介绍
- CCE Autopilot 是云容器引擎服务推出的Serverless版集群,提供免运维的容器服务,Autopilot 在托管 Kubernetes 控制平面的基础上,把工作节点的管理也全部托管起来,实际上也就相当于是一个提供 Kubernetes API 的 PAAS 服务,或者也可以称之为 Serverless Kubernetes。
- 托管节点和控制平面的好处是显而易见的,大幅降低了用户的 SRE 和运维成本,提高应用程序的可靠性和可扩展性。
- 计费模式主要是以Pod为单位,按规格收费
3.2 Jenkins on CCE Autopilot
- 由于Jenkins agent 容器工作的特性:当Jenkins master接收到构建请求时,才会根据当会根据配置的 agent 模板 动态创建一个运行在 Pod 中的 Jenkins Agent容器 并注册到 Jenkins Master容器上,当执行完构建任务后,这个 Jenkins agent 容器会被注销并且这个 Pod 也会自动删除。
- 这种任务型的Pod完美适用于CCE Autopilot集群,最大力度节省了用户的开销,没有任务时Autopilot集群几乎零开销,再加上一般Jenkins构建任务耗时都比较短,即使存在大量构建任务,也不会有开销负担。
四 实战篇
【声明】本内容来自华为云开发者社区博主,不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱:
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
作者其他文章
评论(0)