这是一个创建于 2158 天前的主题，其中的信息可能已经有所发展或是发生改变。
Jenkins 非常灵活，如今已成为实现 CI/CD 的事实标准，同时拥有一个活跃的社区来维护几乎所有工具和用例的插件。但是灵活也是要付出代价的：除了 Jenkins 核心之外，许多插件需要一些系统级别的设置才能正常工作。
在某些情况下，“ Jenkins 管理员”是一个全职职位。Jenkins 管理员在负责维护基础设施的同时，还要为一个巨大的 Jenkins master 提供数百个已安装的插件和数千个托管作业。维护最新的插件版本是一项挑战，故障转移（ failover ）也会是一场噩梦。
这就像几年前系统管理员必须要为每个服务管理特定的机器一样。 在 2018 年，通过使用基础架构自动化工具和虚拟化，一切都可以作为代码进行管理。需要一个新的应用服务器作为你的应用的暂存环境吗？那你只需要部署一个 Docker 容器。基础设施缺少资源吗？那就在你喜欢的云服务上分配更多资源来使用 Terraform。
在这种情况下，Jenkins 管理员的角色怎么样？他们是否还要花费数小时来点击网页表单上的复选框？也许他们已经采用了一些自动化、依赖于 Groovy 脚本或一些自己写的 XML 模板。
今年早些时候我们发布了第一个 alpha 版本的 “ Jenkins Configuration-as-Code ” （ JCasC ），它是一种基于 YAML 配置文件和自动模型发现的 Jenkins 配置管理新方法。Jenkins 已经升级为 Jenkins 顶级项目。 同时，对应的 Jenkins 增强提案已经被接受。
JCasC 能为 Jenkins 管理员做些什么？
JCasC 允许我们在启动时或通过 web UI 按需在 Jenkins master 上应用一组 YAML 文件。与 Jenkins 用于实际储存配置的详细 XML 文件相比，这些配置文件非常简洁易读。这些文件还有用户友好的命名约定，使管理员能够轻松地配置所有 Jenkins 组件。
下面是一个例子：jenkins: systemMessage: "Jenkins managed by Configuration as Code"
securityRealm: ldap: configurations:
server: ldap.acme.com rootDN: dc=acme,dc=fr managerPasswordSecret: ${LDAP_PASSWORD} cache: size: 100 ttl: 10 userIdStrategy: CaseInsensitive groupIdStrategy: CaseSensitive 如你所见，不需要很长的解释你就可以理解这个 YAML 文件如何配置你的 Jenkins master。 优点
JCasC 最直接的好处就是可重复性。管理员现在可以使用完全相同的配置通过一个简单的设置来引导新的 Jenkins master。这允许他们创建一个测试实例并检查升级插件在沙盒环境中的影响。这也使他们对故障转移和灾难恢复方案更有信心。
当管理员开始在源代码管理中管理 Jenkins 的 YAML 配置文件时，他们也会感受到类似使用 Terraform 一样的好处。这样做可以让他们对 Jenkins master 配置进行审核，使其具有可逆性。他们可以建立一个合理的配置改变运行 Jenkins 实例的工作流，并确保在实际应用任何修改到他们的 Jenkins master 之前配置是健康的。
最后也是最重要的是，由于能够快速设置 Jenkins master 并且能用一组共享的 YAML 配置文件控制它们，管理员现在可以给每个团队提供一个 Jenkins 实例，并且在安装插件有更高的灵活性。只要他们还在使用 Jenkinsfiles 管理构建定义（ build definition ），master 就会或多或少地成为你们团队的短期的基础架构。
使用 Configuration-as-Code，我们可以不再像对待宠物那样对待我们的 Jenkins master，而像对待牛那样管理它们，你也可以毫不费力地替换它们。 欢迎来到 “ as-code ” 的世界。
他们仍然很可爱，对吧?
Ok, 那么之后呢? 你可以在项目中阅读有关 Jenkins Configuration-as-Code 插件的更多信息。与社区和贡献者们交流，加入我们的 gitter 频道，或者来我们的 Jenkins World 一起讨论 JCasC 项目及其未来！
另外，不要错过 Configuration-as-Code 系列的下一篇文章，我们将会了解 JCasC 如何处理密码及其他凭据等敏感数据。
目前尚无回复
Select Language