Kubernetes世界中的一个常见调侃是,你并不是DevOps工程师或站点可靠性工程师,而是YAML工程师。无论你看到哪里,都有另一个YAML清单需要注意。
创建、编辑、更新和应用这些清单是YAML工程师的日常工作。用于检查和理解集群中的对象的工具很多,但用于与创建、编辑、验证和调试清单相关的部署前任务的集成工具很少。随着这些清单的大小和复杂性的增加,试图管理样板代码并在当前上下文和你试图修复的生产集群之间找到细微差异几乎是不可能的。人们可以花上数小时来寻找琐碎的错误,而且当难以捉摸的YAML缩进占用你的生产环境时,一切都将停滞。
试图手动管理YAML文件正使我们从DevOps理想中的“牛”基础设施转向“宠物”基础设施。处理每一个胖手指错误或CVE更新恢复健康是一个艰苦的过程。YAML工程师好比兽医,护理每只YAML宠物恢复健康。
必须有更好的方法来管理清单,将YAML工程师变成YAML牛的牧民。
从云原生DevX到OpX
看着云原生开发人员,我们看到了一个完全不同的世界。现代集成开发环境,如Github Codespaces和Gitpod,都是为了加速开发人员的“内部循环”,因此他们可以专注于编写代码,而不是纠缠细节。使用基于云的IDE,即使是帮助同事或查看代码,也只需单击鼠标即可。
暂态的开发环境不会使你丢失当前的上下文。只需打开一个新的工作区及其环境,进行编辑或评论,然后切换回工作。能够用代码描述这个过程有很多好处——从减少配置漂移到为自动化创造许多可能性。
我们需要找到一种方法,将云原生开发人员体验(DevX)的优势转化为更好的运维体验(OpX)。YAML工程师没有相同数量的选择来加速他们的内部循环。代码编辑器将获得一些支持,可以是原生支持,也可以是通过插件支持(这些插件可能无法很好地协同工作),或者他们可以选择使用另一个CLI。真正需要的是一个“manifest IDE”,它以一种良好集成和一致的方式帮助完成所有这些任务,创建云原生OpX。
Monokle:将OpX引入云原生
Monokle是开源YAML IDE,可将真正的OpX带到云原生世界。Monokle使得在将YAML清单部署到集群之前,可以轻松地管理和调试它们。
首先,Monokle可以帮助你快速获得清单及其包含的资源和关系的高级视图。它允许你可视化和导航集群内外的资源,并根据你想要进行的任何更改区分它们。它验证资源之间的引用,以确保你没有拼写错误的对象名称或命名空间,并允许你以交互方式修复这些名称或命名空间,以确保更改能够完成任务。
一旦你了解了清单是如何工作的,Monokle就可以让你轻松地编辑资源,而无需学习或查找YAML语法。你可以重构清单,同时在所有清单中保持名称和引用的完整性。最后,如果你使用kustomize或Helm,你可以预览和调试它们生成的资源;验证它们的链接、值等。你甚至可以将一组生成的资源与集群中已经运行的资源进行比较,以确保当点击“deploy”(部署)按钮时,所有资源都会像你在发布前承诺的那样顺利进行。
Monokle将OpX带给YAML工程师,他们希望将YAML清单变成牛,而不需要像对待宠物一样对待它们。
Monokle正好位于传统的开发人员IDE和运维集群仪表板之间。IDE非常擅长管理单个清单,但在提供以清单为中心的已定义资源及其关系和相关工作流视图时,通常无法提供“全局视图”。另一方面,集群仪表盘通常不提供任何用于处理清单的功能。它们都是关于检查和管理集群中已经运行的资源,而不是关注预部署工件或工作流。
Monokle通过提供Kubernetes清单的整体视图并直接关注相关的工作流(编辑、验证、调试、差异化、部署等)来填补这一空白。Monokle与IDE和集群仪表板配合良好,并通过以清单为中心的功能和工作流来提供补充。
Monokle正处于开源初期,它有很多的发展方向,可以解决问题,给YAML工程师带来快乐!不过,最终还是要让管理清单的人的生活更轻松。如果你希望改进云原生OpX,请尝试Monokle。
原文链接:
https://thenewstack.io/from-yaml-engineer-to-yaml-herder/