这个一篇来自 DevOps World | Jenkins World 演讲者 Mandy Hubbard 的文章
最近我们构建和部署服务的方式与原来相比简直就是突飞猛进,像那种笨拙的、单一的、用于构建单体式应用程序的方式已经是过去式了。我们努力了这么久,终于达到了现在的效果。现在的应用为了提供更好的拓展性和可维护性,都会去拆解成各种相互依赖小、解耦性强的微服务,这些服务有各自的依赖和进度。如果你想去构建你所负责的服务,那么从一开始,就应该使用 CI/CD 的方式;当然,如果你走上了这条路, Jenkins 就是你的良师益友。
如果你是做微服务的话,那让我们在开始之前先花些时间想一想。如果你只在 Jenkins 上构建单体式应用程序,那你肯定每天都会运行很多 Jenkins job, 而且还要不厌其烦地运行很多次。所以,我们应该好好想清楚怎么样来做出一些改变来适应这种事情。其实只需要付出一些努力,Jenkins 就可以帮我们很好地解决这种事情。
我的 Jenkins 的进阶之路
作为一个 Devops 从业者,我遇到的最大问题是如何管理并优化自己的 Jenkins agent 结构。如果只是用 Jenkins 玩玩,实验性地跑一些流水线,那根本不用考虑 agent 的事情。如果你每天要跑成百上千条流水线的话,那考虑怎么去做优化就是一件非常非常重要的事情了。在 Jenkins 进阶之路中,我也尝试了各种不同的方式来寻找最好的 Jenkins agent 的使用方式。相信如果你也和我一样经历过,那下面这些事情你一定会很熟悉喽。
下面是我在这些年中使用 Jenkins 的各个阶段.
所有的构建都在 master 节点上跑,在这个节点上运行所有的组件.
(我给这个阶段起了个可爱的名字, Hello Jenkins)
创建一个 Jenkins EC2 代理,并且在这个代理上运行所有的构建,怎么说呢, 就是大而全,这个节点什么都能做。如果需要同时做多条任务,那就把这个大而全的节点克隆一份。
(这个阶段我起的名字是 Monster Agent.)
为每种服务创建不同的 Jenkins EC2 的节点
(这个阶段我起的名字叫做 Snowflake Agent.)
在容器中运行流水线的所有步骤。 打个比方,在 Jenkins 中使用Docker Plugin这个插件将代理挂载到容器中,或者使用 multi-stage Dockerfiles 把所有构建,测试打包的流程都封装起来。这两种方法都是很好的容器抽象化的开端,并且允许您轻松地将制品从一个容器复制到另一个容器。当然了,每一种方法都是需要访问 Docker engine 的。为了让我的...