在本系列的第一篇文章中，您已经了解了一些关于如何管理Jenkins的内容，主要是为无序的人带来秩序。在这篇文章中，我将更深入地探讨我效率低下的问题，提出我们工作流中一些安全性、治理和合规性的挑战。这不仅仅是你在网站上或展览横幅上看到的DevOps流行语——它们是保持软件交付速度的关键。我发现，如果我们的安全协议没有一致的治理或合规性，自动化就会变得不那么…自动化。
以下是我发现不受管理的Jenkins的另外两个缺点，一起来看看，说不定和你发现的一样。
问题3：缺乏一致性
在我之前的文章中，提到过一个主题：分散控制和缺乏可见性会产生混乱。有太多的人操控太多的变量，这就很难让每个人、每件事处于同一个起跑线。这带来了巨大的障碍。
**缺乏治理会阻碍最佳实践。**当随便什么人都可以启动、配置或修改服务器时，您实际上是没有治理能力的，并且几乎没有机会去持续地实施最佳实践（例如定期安全扫描、禁止不安全插件等）。
**插件划分了服务器、工作流程和团队。**如果没有插件管理，您的团队可能会在服务器中放入任何数量（和质量）的插件。这将给团队间带来相当大的兼容性和互操作性问题，他们将不可避免地使用有冲突的插件，并按照不同的时间表来更新和共享插件。
**缺乏一致性会导致更多的Bug。**流水线的一致性是避免错误的关键。由于不同配置的控制器、不同的插件集、灵活变化的工作流程以及基本上互不关联的团队，不受管理的Jenkins会增加您的工程师寻找Bug的时间。
**备份可能是零零散散的。**备份数据并验证这些备份的完整性都需要有组织、有纪律。如果缺少有意义的治理，您的备份策略可能会有漏洞，然后面临丢失数据的风险。
问题4：缺乏安全
网络安全是一项永无止境的挑战。云计算和业务转型带来了具有高度流动性(并不断扩大)的攻击范围，快速的创新步伐要求企业时刻保持警惕来击退潜在的攻击者。那么，这是如何对于已经陷入我所提到的困境的企业造成更大的影响的？
**没有授予任何人执行安全策略的权利。**如果没有集中的权力或可靠的治理，您将很难让团队遵守安全最佳实践（甚至遵循基本政策）。这将会给您的流水线带来有风险的插件、有风险的代码和有风险的做法。
**您的安全强度只达到了您最不安全的插件的水平。**随着插件在控制器中数量激增，这些插件中的任何安全漏洞都会成为您的负担。插件开发者是否修补了这些漏洞，以及你的团队是否为了更好地利用安全补丁而可靠地更新他们的插件，这些都是安全方面的通用常识。
**漏洞修复可能会很慢，甚至根本不存在。**由于厨房里有太多厨师，而且普遍缺乏可见性和协调，因此对发现的任何安全威胁进行修复将非常麻烦。
安全性混乱且薄弱，导致合规也变得困难。合规性就是要证明您是受控的，拥有可靠的保护措施，并且可以满足安全标准。由于上面列出的所有原因，如果想靠不受托管的Jenkins实现这一点，很难。
迈入标准化、自动化和优化的大门！
如果您阅读了第一篇文章，就已经知道是CloudBees CI帮助我控制不受管理的Jenkins实例的混乱局面，但现在，是我认真对待提高全面效率的时候了。这意味着一致性和自动化。以下是我确定对我和我的团队有帮助的项目：
快速上手
- 所有开发团队一开始就有一个值得信赖、经过验证且受到支持的Jenkins版本，和以及一套经过稳定性和安全性测试的精选插件。对我来说，支持是最重要的一点。在我有问题时，总有人在我身边帮助解决——无论问题多么简单；
- 使用自定义CasC捆绑包来配置可重复组件，使团队能够从从单一来源管理的预配置和测试环境开始。
流水线模板目录，用于在整个运营过程中执行一致性和稳定性
- 你拥有一个基于最佳实践的流水线集合，让团队永远不必从头开始，并且对模板的更改会从一个点推送到所有团队的流水线中；
- 每次运行job时都会获取最新的模板代码，因此job始终反映的是最新的标准。可以有选择性的把开发人员限制在特定的模板之中，来实现治理目标；
- 想要避免从头开始治理开发人员，可以通过修改现有模板来适应新议程；
- 自定义标记文件让您能够基于软件配置管理（SCM）标识符的基础上，即时选择构建模板。
自动备份和恢复
- 消除备份策略中的人为错误。我们团队中有很多独立的思考者，这对于功能开发这很有利，但对于一致的环境设置却不是很友好。所以自动备份和恢复有助于为他们创造一个可以启动和使用的环境，而不是每次都从头开始创建。
跨团队协作
- 使用一个强大的发布者/订阅者模型跨多个控制器管理事件，无论身处何处，团队都订阅流水线事件并对其采取行动；
- 流水线同步工作，不同的团队能够使用同步的自动化执行跨流水线的协作；
- 团队可以通过控制器分开工作，但他们仍然可以协同工作，实现流水线自动化；
- 每个团队都应该能够安全地使用不同的插件和技术，而不会有影响其他团队的风险。
提升开发人员的工作效率
- 直接在GitHub和Slack中接收细化的、可操作的构建数据。
轻松实现安全性和合规性
安全性和合规性对我们来说是一个巨大的挑战。毕竟，如果您不能完全控制开发环境，那么就很难实现这两个目标，但目前很少有开发人员能够做到。幸运的是，随着CloudBees的集中化和标准化，安全性和合规性变得相对来说更容易了。随着每个团队都使用安全的构建和批准的流水线配置，我的SDLC有了全面的护栏支持（guardrails supporting）。以下是一些使我的工作变得更轻松的项目：
集中管理的安全策略
- 授权控制器仅运行经过测试、验证且安全的Jenkins版本。如果构建中出现问题，可以更轻松地全局复制、修复和更新该构建。
- 从单一位置管理身份验证和授权功能： 在所有控制器上使用单点登录（SSO）；
- 使用基于角色的访问控制（RBAC）模型定义安全凭据，并在控制平面、文件夹或单个控制器级别对访问权限进行分组定义；
- 使用文件夹层次结构实施对控制器、代理或项目的访问；
- 将RBAC与文件夹限制相结合以提高安全性，并确定谁可以在文件夹层次结构中的每个位置创建、修改、删除和使用凭据。
- 基于每个团队确定安全的范围。 使用模板化的工作流程，将安全性落实到您的流水线中。
- 简化合规性
- 只需使用CasC捆绑包和流水线模板即可构建合规性。
- 将插件的风险降至最低
- 限制团队只能使用一组精心挑选过的插件（CloudBees保障计划 - CAP），这些插件经过稳定性和安全性测试，并确认符合合规性目标。
随着您团队的扩大而扩展
大规模自动化是Jenkins的追求。不受管理的Jenkins在自动化方面可能表现出色，但在大规模管理部分则不然。这里指的不是管理一个团队，而是管理很多团队。我需要为团队提供成长的空间和所需的支持，并计划随着我们投资组合的扩大创建新的团队。首先，需要考虑的就是对着人员的扩大而扩展，因为如果没人使用它，那么这个软件被开发出来的目的是什么呢？需要有一个人来确保所有人拥有他们完成工作所需的一切事物。在上述对我有用的功能中，有一些对扩展也有所帮助。
- 通过自动配置新团队/控制器、传播最佳实践（流水线模板、CasC等），以及为规模合适的基础设施管理资源，来实现大规模交付Jenkins。
- 团队能够自行快速启动新的控制器和工作区，同时确保SDLC保持一致、受管控、合规且安全。
- 如果您使用的是Kubernetes，请在扩展时利用Kubernetes配置来优化基础架构资源。这样，控制器可以根据需要启动，然后在不使用时可以休眠。
企业级支持
最后，要真正让使用Jenkins企业做好准备，我们必须解决房间里的大象：Jenkins缺乏结构化的支持。社区援助是非常好的解决方案，但是当灾难发生时，您是没有时间在论坛上挖掘出解决方法的。您要将弹性融入您的计划，您需要坚如磐石的专业支持，这样您才可以专注于构建应用程序，而不用为修复让步。
让CloudBees团队的Jenkins专家为您提供指导。你不必再依赖Rick——你可爱的Jenkins专家，他收集了1980年代的限量版星球大战人物（我们有着同样的热情，Rick）。相反，您要依靠专家的帮助，让Rick在其他地方大展拳脚吧。
CloudBees CI建立在Jenkins之上，并添加了额外的功能来满足企业的需求。我们了解Jenkins，并且因为我们为开源项目贡献了大量代码，所以我们在解决问题方面具有独特的优势——如果出现问题。
此外，CloudBees会主动解决Jenkins构建中的漏洞，确保它们在安装前就被搞定，而且我们还创建了Jenkins健康顾问。健康顾问在整个Jenkins环境中提供运行状况监控，在问题（安全漏洞、性能瓶颈、插件缺陷等）影响用户之前发送通知。健康顾问适用于所有Jenkins用户，而不仅仅是CloudBees CI用户，所以如果有专门支持Jenkins的精英团队，您也可以使用它。
在下一篇文章中，我将解决可怕的基础设施问题。基础设施就像地基，您房子下面的地下室。我既想知道什么时候有问题，又不想知道——因为解决这些问题需要做很多工作。我就是这样的人，在我们团队一瘸一拐的前进时，我否认自己有基础设施问题。就有点像我知道天花板上有一只蜘蛛…但也许如果我忽视它，它就能自行消失。但事实上是没有这种运气的——那些小生物会再次在某个地方出现。
作者：萨曼莎·弗罗斯特（Samantha Frost），CloudBees公司产品营销经理。
文章来源：https://www.cloudbees.com/blog/managed-jenkins-consistency-isnt-boring
