在上一个篇文章中，我们解释了配置管理和编排工具的简单使用。但是，CM领域正在发生一些新的变化。虽然CM演进的道路仍在继续，但在配置级别上有一些有趣的发展，公共和私有云计算导致模型驱动自动化的出现，其中底层系统的声明模型可用于创建系统。
亚马逊拥有云计算，Azure拥有Azure资源管理器模板等。出现了一个非常合理的问题，为什么我的系统使用一个模型，我的操作系统配置使用另一个模型，我的应用程序使用另一个模型？无论如何，这还不是最理想的。 James和我实际上参与了在公司中编写统一模型工具，并且能够从同一模型实例化和控制您的系统和应用程序，功能非常强大。
PS: 举例一个我经历过的例子，在传统的IT配置管理中。上面提到的模型或者模板，其实可以理解为一个定制开发板的系统镜像。这个模板可以实例化，也就是安装到很多人的电脑上，这些人的系统都是一样的，方便IT进行管理和监控，最常见的就是自动安装系统补丁，文件备份和其他安全策略的工作。这些都依赖于一个模板或者系统模型。
容器的兴起加速了这个问题。在基于容器的体系结构中，服务器变得越来越少。应用程序打包在一个容器中，该容器具有足够的操作系统和依赖关系以支持它们，然后在简单的物理基础架构中出现。出于效率原因，即使像Netflix这样的非常大的云播放器也开始回归黄金图像模型。如果您有足够的自动工件管理，那么我们可能只是希望将JAR打包到WAR文件中并将WAR文件打包到DEB文件中进行分发，该图像只是另一层工件。
Netflix将整个Amazon映像作为其构建工件进行烘焙，并在部署时执行最少的配置，因为在1000个节点上运行相同的升级活动实际上只需要一个或多个节点解决这些故障，然后同步到其他节点，部署过程较慢。在容器世界中，这变得更加习惯，被称为系统的不可变基础设施，以及应用程序的不可变交付。·
如果整个容器，操作系统依赖项和应用程序代码都是您的工件，那么没有理由通过配置管理来更改其状态。部署后，它是不可变的。在升级时，您引入了一个全新的系统。当然，这并不总是适用于您的数据存储，但事实上，一些较新的无SQL数据存储可以在此模型中完成，这样可以保留数据的多个副本以实现弹性。此外，虽然没有好的工具来处理当天的VM黄金图像，但这种情况正在发生变化。
Docker存储库看起来很像任何其他计费工件存储库，具有您期望的所有相同版本控制和语义。在我目前的工作中，我们使用Maven构建，生成DEB文件和docker容器，然后将它们推送到Artifactory中。配置云实例时，它会获取两者的当前版本。我们一直在使用Rundeck和Puppet根据需要升级这些系统中的DEB和容器，但随着我们的系统越来越多地迁移到容器中，我们发现它的需求减少了。
我预计有一天我们将退出我们的CM并切换到仅在基本操作系统云映像上运行的容器。让我们暂停并谈谈配置管理数据库。回到ITIL时代，中央CMDB的想法诞生了。 CMDB应该是一个数据仓库，其中包含有关所有IT资产及其之间关系的信息。这听起来像是一个超级想法。但实际上，CMDB的实现是可预见的。
它们通常是手动更新的，但即使是自动化方法也无法跟上现实世界系统不断变化的步伐。除了顽固的公司，这些公司已经失宠了。 Chef和Puppet服务器有一个基本的节点注册表，并且能够存储其他数据，所以人们只是这样做，调用它就足够了，但需要更多的实时内容。 Apache Hadoop项目要求工作人员严格管理和协调mapreduce作业，并且他们构建了许多内部编排工具，包括一个名为ZooKeeper的项目，用于状态管理和配置。
这引起了很多关注，人们开始将其作为其他业务流程解决方案的中心。实际上，NI和我在NI上构建的模型驱动的CM工具使用ZooKeeper作为其中心协调器。然后，围绕这个概念出现了更多的项目，专为高速中央状态和配置源和服务发现机制的简单存储而设计。随着容器变得越来越流行，实际上需要集中供应和管理这些商店等，HashiCorp的领事是一个可能的选择。
PS：说了一大堆，核心的部分就是，把一些不变的配置部分，提取出来，放到容器里，做成镜像。这个如果你学习了Dcoker，就很容易接受这个想法和思维。Docker的最大特点就是把环境和程序代码打包成一个包，这个包可以制作成镜像。