Jenkins是一个基于单个master和多个agent组合的单体应用。
一方面，Jenkins master可以看成是一个协调器。它监视源代码，在满足预先定义的条件时触发作业，存储日志和文件，并执行与CI/CD编排相关的其他大量任务。它不运行实际任务，但它能确保任务被执行。
另一方面，Jenkins agent完成实际的工作。当master触发作业执行时，实际工作由代理执行。我们不能扩展Jenkins master，至少不能像go-demo服务那样扩展。可以创建多个Jenkins master，但它们不能共享同一个文件系统。由于Jenkins使用文件来存储其状态，因此，创建多个实例会导致完全分离的应用程序。由于缩放背后的主要原因是容错性和性能优势，而这些目标都不会通过扩展Jenkins master来完成。
如果Jenkins不能缩放，那么如何满足性能要求？可以通过添加代理来增加容量。一个master可以处理许多代理。大多数情况下，代理是一整个服务器（物理的或虚拟的）。单个master拥有数十个甚至数百个代理（服务器）并不罕见，转而由每个代理运行多个执行任务的程序。
传统上，Jenkins的master和agent将在专用的服务器上运行。这本身就带来了一些问题。如果Jenkins正在专用服务器上运行，那么发生故障时会怎么样？要知道，故障迟早会发生。(www.xing528.com)
对于许多组织来说，Jenkins是关键任务。如果它不可操作，则不能发布新版本，无法运行计划任务，无法部署软件等。通常，Jenkins故障通过把软件和记录其状态的文件一起转移到健康的服务器来解决。如果这个过程是手动完成的，那么通常情况下，停机时间可能很长。
本章会充分利用到目前为止学到的知识，并努力使Jenkins能够容错。我们可能无法完成零宕机时间，但至少会尽最大可能减少宕机时间。我们还将探索应用学到的方法来以（几乎）全自动的方式创建master和Jenkins代理。我们将尽可能让master容错，以及代理可动态扩展。
废话少说！让我们进入本章的实践环节。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
