智能运维下的cmdb
In a recent report, Ovum described Fugue as “a CMDB for APIs.” A configuration management database (CMDB) is a single source of truth for configuration of complex systems. This is a crucial aspect of Fugue, one where running your operations with Fugue offers a lot of value to you.
Ovum在最近的一份报告中将Fugue描述为“用于API的CMDB”。 配置管理数据库（CMDB）是配置复杂系统的唯一事实来源。 这是赋格曲的关键方面，与赋格曲一起运行可以为您带来很多价值。
Fugue’s CMDB is an effect of our declarative model for configuration, built around our typesafe, compiled Ludwig language. The Fugue CMDB is not a proprietary store with a form-based interface; it is Ludwig code, managed in a VCS of your choice, like git or svn. That code is a declarative configuration of infrastructure (or other API) state. Once it is run as a process in Fugue, that declaration is made real and immutable with machine precision.
Fugue的CMDB是我们的声明式配置模型的结果，该模型围绕我们的类型安全的已编译Ludwig语言构建。 Fugue CMDB不是具有基于表单的界面的专有存储； 它是路德维希代码，在您选择的VCS中进行管理，例如git或svn 。 该代码是基础结构（或其他API）状态的声明性配置。 在Fugue中将其作为流程运行后，该声明将变为真实且不更改，且具有机器精度。
In this way, a well-managed body of Ludwig compositions and a Fugue runtime present a powerful CMDB. More precisely, it presents the inverse of a CMDB — declarative configuration control — which is far more powerful.
通过这种方式，路德维希作品的良好管理主体和赋格运行时提供了强大的CMDB。 更准确地说，它呈现了CMDB的反面（声明性配置控制），它的功能要强大得多。
传统CM模型 (The Traditional CM Model)
Configuration management (CM) is the process of tracking, detecting, and auditing changes made to components of an engineering system (configuration items, or CIs), in an effort to prevent configuration drift. Configuration drift is the accumulation of untracked or unwanted changes, and over time it results in wasted money, lost time, and lowered productivity.
配置管理（CM）是跟踪，检测和审核对工程系统的组件（配置项或CI）所做的更改的过程，旨在防止配置漂移。 配置漂移是未跟踪或不需要的更改的累积，随着时间的流逝，这会导致金钱浪费，时间浪费和生产率下降。
If you’ve done work in a team responsible for some amount of configuration management, you are probably familiar with this most basic model of CM:
如果您已经在负责一定数量配置管理的团队中完成工作，则您可能熟悉CM的最基本模型：
- Authorized people make changes to CIs
- The same people honestly and accurately report their changes in a CMDB
- Other maintainers & auditors trust the CMDB to reflect reality
- 授权人员对配置项进行更改
- 同一个人诚实，准确地在CMDB中报告他们的更改
- 其他维护者和审计师相信CMDB能够反映现实
The weak link in this chain is honesty and accuracy of human beings. Humans are famously non-deterministic in their honesty and accuracy. Moreover, they prove remarkably resistant to attempts to fix this. It is a problem which is both immeasurable and intractible, yet it plagues many organizations in their attempts to control configuration of the many things they own.
这条链中的薄弱环节是人类的诚实和准确性。 众所周知，人类的诚实性和准确性无法确定。 而且，事实证明，它们对解决此问题的尝试具有明显的抵抗力。 这是一个既不可衡量又难以解决的问题，但是它困扰着许多组织来控制他们所拥有的许多事物的配置。
Declarative configurations, long practiced around operating systems, go some way to remedy the problem just by themselves. This model is more sophisticated:
声明式配置（已在操作系统上长期使用）可以通过某种方式自行解决问题。 该模型更为复杂：
- Authorized people devise configuration files for an OS CM system
- OS agents read the configuration files and make changes to OS CIs reliably
- Other maintainers & auditors trust the configuration files as an accurate CMDB
- 授权人员为OS CM系统设计配置文件
- OS代理读取配置文件并可靠地更改OS CI
- 其他维护者和审核员相信配置文件是准确的CMDB
This is great. It has two shortcomings.
这很棒。 它有两个缺点。
First, it is generally practiced around computer operating systems, and not so often with APIs, especially eventually consistent ones (like AWS). The latter are particularly difficult to impose a declarative configuration state on.
首先，它通常是围绕计算机操作系统来实践的，而不是使用API的情况，尤其是最终一致的API（例如AWS）。 后者特别难于施加声明性配置状态。
Second, the initial model with manual changes affixed to human accuracy often creeps in. As Chad Fowler put it:
其次，最初带有手动更改并附加到人类精度的模型经常会出现。正如Chad Fowler所说：
[A]n old system inevitably grows warts. They start as one-time hacks during outages. A quick edit to a config file saves the day. “We’ll put it back into Chef later,” we say, as we finally head off to sleep after a marathon fire fighting session. […] The system becomes a house of cards. You fear any change and you fear replacing it since you don’t know everything about how it works.
旧系统不可避免地会产生疣。 它们是在停机期间的一次性入侵开始的。 快速编辑配置文件可以节省一天的时间。 我们说：“我们稍后再把它放回厨师手中。” […] 系统变成纸牌屋。 您担心任何更改，而且害怕替换它，因为您不了解更改的全部原理。
赋格倒置模型 (Fugue Inverts The Model)
The problem becomes even more significant when your infrastructure is in the cloud. It’s time-consuming to track CIs across so many different components at scale. It’s often a manual process of tallying up routes and interrogating servers with a console or command line. The temptation is strong for ad-hoc fixes and piecemeal scripting. Complexity increases with each new tool added. Configuration drift plagues the system. Frustration plagues the team. That is something Fugue fixes.
当您的基础架构位于云中时，问题变得更加严重。 大规模地跨多个不同组件跟踪配置项是很耗时的。 这通常是手动计算路线并使用控制台或命令行查询服务器的过程。 临时修复和零碎脚本的诱惑很大。 每添加一个新工具，复杂性就会增加。 配置漂移困扰着系统。 挫折困扰着团队。 那是赋格修复的问题。
The challenge with management and automation in the cloud is to make sure that the complexities and sheer volume of APIs can be managed and orchestrated. Fugue can be described as a cloud operating system, but Ovum prefers to describe it as a CMDB for APIs, where by using a declarative language the entire infrastructure can be codified.
云中的管理和自动化面临的挑战是确保可以管理和编排API的复杂性和庞大的数量。 Fugue可以描述为云操作系统，但是Ovum倾向于将其描述为API的CMDB，在其中通过使用声明性语言可以对整个基础架构进行编码。
Fugue’s way is to think of infrastructure as code, use immutable infrastructure wherever possible, and then enforce it. The result is a much more powerful inversion of the traditional configuration management model. With Fugue, first you build the CMDB, and then the Conductor uses the CMDB to build your CIs.
Fugue的方法是将基础架构视为代码，尽可能使用不可变的基础架构，然后加以实施。 结果是对传统配置管理模型的强大转换。 使用赋格曲，首先要构建CMDB，然后导体将使用CMDB来构建CI。
- Authorized personnel devise a CMDB for a complete controlled system (a Fugue composition)
- The Conductor makes the configuration in the CMDB a reality (a Fugue process)
- Other maintainers & auditors can view the configuration directly through Ludwig composition code
There are several advantages to this approach. You really know what is going on with your infrastructure. Unlike humans, Fugue’s Conductor is deterministic in its behavior, so in the rare event it exhibits flaws, we can find them and fix them.
这种方法有几个优点。 您真的知道您的基础架构正在发生什么。 与人类不同，赋格的导体在行为上是确定性的 ，因此在极少数情况下它表现出缺陷，我们可以找到并修复它们。
Configurations in compositions are reproducible, making scaling or recovery much easier. Configuration is easily shared and recomposed into new configurations. What’s more, it’s easy. Your CMDB is just code. It’s easy to explore and analyze.
合成中的配置是可重现的，从而使缩放或恢复变得更加容易。 配置易于共享并重新组成新的配置。 而且，这很容易。 您的CMDB只是代码。 很容易探索和分析。
In addition, Fugue’s Ludwig language includes a number of ways to validate configurations at compile time. We ship Fugue with lots of common validations, like subnet sizing. We also have libraries that test compliance with regulatory regimes, like HIPAA. And you can build your own custom validations. All of these validations are applied to your Ludwig code when it is compiled, and compilation is a required step before committing any changes to a process.
此外，Fugue的Ludwig语言包括多种在编译时验证配置的方法。 我们为Fugue提供了许多常见的验证方法，例如子网大小。 我们也有测试符合HIPAA等监管制度要求的库。 您可以建立自己的自定义验证。 所有这些验证都将在编译Ludwig代码时应用到您的Ludwig代码中，并且在将任何更改提交到流程之前，编译是必需的步骤。
When changes are required, Fugue doesn’t default to modification of complex components like operating systems. The preferred method of update is replacement, which is the essence of immutable infrastructure. You can, of course, integrate tools that update instance operating systems into Fugue if you wish. Where replacement doesn’t make sense — such as for security group rules — Fugue uses enforcement to ensure the CMDB and reality match. Constant monitoring of the configuration via API, and immediate correction of drift, ensures that your configuration is what you want it to be. All the time.
当需要更改时，Fugue不会默认更改诸如操作系统之类的复杂组件。 首选的更新方法是替换，这是不可变基础结构的本质。 当然，您可以根据需要将更新实例操作系统的工具集成到Fugue中。 在替换没有意义的地方（例如对于安全组规则），Fugue使用强制执行来确保CMDB与现实匹配。 通过API持续监控配置，并立即纠正漂移，可确保您的配置符合您的要求。 每时每刻。
翻译自: https://www.pybloggers.com/2016/11/the-next-generation-cloud-cmdb-ludwig-code/
智能运维下的cmdb
646
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
