由于容器只是位于该环境上，所以我的假设是我们仍将需要适当地维护配置幂等性，但这与使用容器的容器有何不同？
#1 楼
这取决于您愿意租用什么并允许由其他人管理。如果看这张图：
它显示了各种选项。一方面是使用本地硬件自己动手做，并设置网络等。其次是“ co-lo”，这意味着您购买的服务器安装在某个机架/网络/数据中心中。接下来是IaaS，您通常会在纯软件定义的网络上租用VM，并请人来管理物理服务器和物理网络。
那么容器放在哪里呢？好吧，我已经看到大型组织通过在云中设置网络和防火墙来完全匹配本地与到云数据中心的私有网络连接，从而将云IaaS有点像在实时上。因此获得云的优势很少。他们主要管理的是数十个遗留系统，作为“数百万美元”云合同的一部分，它们已从本地“提升并转移”到云提供商。显然，他们仍然需要所有配置管理，就像使用本地管理VM一样。然后他们安装Kubernetes来管理容器，并且必须对其进行管理。他们需要聘请的所有工程师来维持它们的全部运转都需要付出巨大的代价。在这样的设置中，很明显，他们需要在每个级别进行配置管理，而容器集群只是他们需要配置和管理的又一新事物。
另一端是SaaS，您不知道它们是否使用VM或容器。这样，您就没有传统的配置管理，并且通常没有开发人员。从devop的角度来看，CaaS + PaaS是一个有趣的选择，您可以在托管的Kubernetes服务上租用容量，该服务具有devop扩展，例如OpenShift。首先，您只需在共享群集上租用内存，即可通过OpenShift Kubernetes中的软件定义网络将您与其他租户隔离。然后，您将云中虚拟机的管理和配置外包了，还外包了修补和扩展在虚拟机上运行的Kubernetes集群。然后，您可以专注于Kubernetes上容器的配置管理。 （注意：您仍然需要对容器运行时进行安全补丁。我们有一个脚本，用于检查RHOAR容器的新安全补丁，并使用最新版本重建我们的容器。）您可以并且愿意放弃控制权。它很容易开始租用一小部分共享托管集群，然后升级到仍由其他人管理的专用集群。一旦开始在公共云上执行此操作，就很难想象再回到管理云中的VM的任何其他优势。除非您被迫运行旧版应用程序或软件，否则您必须购买不支持在容器中运行的软件。如果必须配置VM，则应应用配置管理的最佳实践。
#2 楼
欢迎使用容器，这确实是一个非常令人兴奋的方向。您提到的软件配置管理工具可以通过多种方式满足容器的需求，如果您已经熟悉Terraform，那么您可能已经知道了。
例如，Kubernetes可以管理（容器；“ pods”的）部署和复制集，并且像Puppet一样的节点也可以管理虚拟机和微服务。
我个人说，在容器世界，但相信容器基础结构中仍然需要配置管理，尽管您可能会改变容器随附的本机工具（而不是Puppet）的配置方式。
Dockerfile是相当自我解释，可以满足Puppet提供的基础架构作为代码的观点；如果您随后进入Kubernetes集群和节点，那么对于YAML文件也可以这样说。
容器是可重复基础结构的捆绑。我发现此堆栈溢出答案也支持我的答案；过去肯定对我有帮助。
https://stackoverflow.com/a/41472271/1524645
评论
我今天读过这篇文章，并想起了回答您的问题。当然值得一读。 opensource.com/article/19/2/configuration-management-camp