我如何用JFrog管道向前跳跃我的Jenkins构建
通过
9分钟阅读
詹金斯是当今市场上最流行的开源CI工具。作为早期进入市场的人，Jenkins推广了CI。像其他CI工具一样Jenkins允许开发人员在将代码提交到源存储库后立即自动构建、集成和测试代码。这允许开发人员快速捕获错误，并最终更快地部署。
现在，距离电影初次上映已经过去了十多年，《詹金斯》正处于一个十字路口。对于詹金斯社区的很大一部分人来说，这已经成为他们“容忍”的工具。术语“Jenkins sprawl”已经成为IT术语的一个常见部分。当使用大量插件并且这些插件开始相互碰撞时，Jenkins遇到了复杂性墙。摆脱这种“插件地狱”的一种方法是将工作负载(和插件)分散到更多的服务器和实例上。随着开发团队添加更多的Jenkins实例，他们面临着管理激增的孤立的Jenkins配置的挑战。不幸的是，你最终只是把一种复杂性换成了另一种。此外，Jenkins是为前容器和前微服务时代而构建的。任何工具要保持其价值，都必须与这些更广泛的技术趋势保持一致。
在这篇博文中，我将介绍不同的加速和提高的方法你的CI/CD DevOps使用JFrog管道作为您的一部分SDLC．
JFrog管线是一个用于构建、测试和部署软件的自动化解决方案。它提供了所有密钥的端到端编排和优化你的DevOps管道的进程，包括以下优点:
- 管道不仅仅是一个独立的CI/CD解决方案，它是JFrog平台，它的核心是Artifactory和你的二进制文件
- 免插件架构——我们都知道维护插件有多麻烦……
- 快速和简单的管道配置本机的步骤
- 中心化服务(与“Jenkins蔓延”相比)缩放到无限
- YAML的语法-简单易学
- 内置安全漏洞扫描和许可证遵从JFrog x光
作为JFrog的解决方案工程师，以下是我经常从客户那里得到的一些问题和担忧。特别是关于如何解决他们的Jenkins环境迁移到JFrog管道的过程。
- 为什么我们要冒着改变工作流程的风险来部署呢?
- 将我们所有的CI/CD进程迁移到JFrog管道将花费大量的时间!
- 我们有Jenkins的所有插件!我们会对JFrog提供同样的支持吗?
Jenkins Pipeline示例
我将使用下面的端到端Kubernetes CI/CDJenkins管道基线示例，展示如何以及为什么使用JFrog管道可以为您工作。这个管道构建了众所周知的宠物医院使用Docker对其进行容器化，并使用Helm图将创建的映像部署到K8s集群环境。它包括以下步骤:
持续集成(CI)
- 构建Maven项目(宠物诊所Spring应用程序)，并将结果二进制文件部署到Artifactory。
- 使用Docker容器化新应用程序，并将新映像部署到Artifactory。
持续部署(CD)
- 安装Helm, k8s的包管理器。
- 使用Artifactory中提供的Helm Chart，将承载应用程序的映像部署到基于k8s的生产环境中。
以上管道(Jenkinsfile & Dockerfile)的代码示例是可用的在这里．
让我们来看看可以为这个非常常见的CI/CD示例实现的可能技术。
使用JFrog管道飞跃前进
你可以选择三种基本的技术来启动JFrog管道。前两种方法实现了与Jenkins的集成，可以按任何顺序完成，或者您可以选择这两种集成方法中的一种。一旦你集成了Jenkins和JFrog管线，你就可以继续执行#3，并将你未来所有的投资集中在JFrog管线上:
- 使用Jenkins (CI)的触发器管道(CD)进来的人- JFrog管道公司一等公民。
- 迁移你的SDLC的部分是正确的方法;从JFrog管线(CI)触发你的Jenkins (CD)詹金斯集成．
增加更多的自动化来简化您的流程使用JFrog pipeline设计新的CI/CD流程．
1.Webhooks是JFrog管道的一等公民
一种方法是保留和维护Jenkins中的CI,但使用JFrog管线执行实际部署．
连接JFrog管道与Jenkins是可能的使用进来的人，它触发执行一个新的运行在JFrog管道在CI在Jenkins的最后一步，通过发送一个webhook请求到JFrog管道当码头工人形象而且建立信息部署在Artifactory中。
优点:
- 减少处理Helm &谷歌Cloud SDK安装的需要，从而更快地执行部署。
- 避免Jenkins蔓延和基于Kubernetes插件的“插件地狱”，使用JFrog pipeline本地步骤来部署到Kubernetes。
- 本机集成与Artifactory拉和管理舵图。
在Jenkins构建完成后，JFrog pipeline可以管理图表到k8s集群的部署。
这可以用HelmDeployJFrog管道中的原生步骤，一个预先打包的声明性步骤，不需要Helm脚本。
让我们记住，我们的集群运行在谷歌Kubernetes引擎上。因此谷歌云集成添加以允许部署步骤:
代码示例(Jenkinsfile & pipes .yml)可用在这里．
2.Jenkins集成与JFrog管道-部分迁移是要走的路
从头重写整个CI/CD实际上没有意义。到目前为止，您使用Jenkins所做的所有艰苦工作都是有价值的。与我们的詹金斯集成对于将要迁移的特定部分，您拥有充分的灵活性。你甚至可以选择与Jenkins集成，而不需要从Jenkins迁移任何当前的工作负载，而是将所有未来的工作负载集中在JFrog pipeline上。出于本文讨论的目的，我们假设您希望迁移部分工作负载。
例如，假设您对CD流程投入了大量资金，希望将当前的实现保留在Jenkins中，只迁移CI部分，以受益于JFrog pipeline的优势。
优点:
在JFrog管道上创建一个新的Jenkins集成:
Jenkins用户名，API令牌和URL将被JFrog管道用于通信，而回调URL将被Jenkins使用。
Jenkins中的配置如下所示:
“测试连接”根据在管道端创建的集成URL，验证从Jenkins端也可以实现通信。
然后，CI可以在JFrog管道中执行:
最后一步将触发一个新的部署(CD)，它在Jenkins中以相同的方式实现:
在Jenkins中，最后一步报告部署已成功完成。
代码示例(Jenkinsfile & pipes .yml)可用在这里．
3.Helm CI/CD -增加更多的自动化以简化您的流程
Helm是Kubernetes的包管理器。Helm部署了定义打包应用程序的图表。它是所有版本化的、预配置的应用程序资源的集合，可以作为一个单元部署。2022世界杯阿根廷预选赛赛程
我们经常改变部署软件的方式，这些变化反映在不同的Helm图表版本中，这些版本都可以存储在Artifactory中使用舵舵图资料库．
使用JFrog Pipelines，您可以自动将新的Helm图表部署到Artifactory的过程HelmPublish本机的一步。
优点:
- 打包图表不需要使用Helm编码，而是使用本机编写的步骤，该步骤还检查图表是否存在可能的问题(lint: true)。
- 减少了处理Helm安装的需要(版本可以根据需要选择v2/v3)。
更新现有的管道资源立即触发将此资源作为输入的其他管道。
代码示例(pipes .yml)是可用的在这里．
在这篇博文中，我们发现了三种不同的方法，可以让JFrog pipeline成为现有基于Jenkins的DevOps流程的一部分。希望这将鼓励您考虑同时使用多种方法。
看看JFrog管道如何为您工作，自己试试吧，>
