#1 楼
这两个术语非常不同。让我们从
immutability开始，它的字面意思是“无突变”或“无变化”。从DevOps的角度讲，这意味着一旦创建了工件，即是容器映像，VM映像，还是来自已编译代码的程序包，即表明您永远不会更改它。通常，如果需要进行任何更改，您会声明将创建一个新版本的“事物”。一旦。首先，它已经假定将要应用更改，这意味着您既不能做一些不变的事情，又不能对其做幂等的操作（合同没有对它做任何操作）。使用配置管理工具时，在多次应用相同更改的情况下，有时会使用idempotence。就像在idempotence文件中添加显示localhost的行一样，您实际上并不需要多条这样的行，并且如果已经存在这行，可以避免再次尝试添加。 /etc/hosts也是一个术语，用于描述试图改变事物的动作，而idempotent则用于描述名词（对象），这些名词与对它们所做的更改相反。 为什么
immutable对象有用？因为当您进行复制时，例如从开发环境复制到质量保证再到生产。您已经对它的运行方式了解了很多（但不是全部）。在许多情况下，工作的零件将是一致的，而损坏的零件也将是一致的。为什么
immutable操作有用？因为当您要更改某个对象的状态时，在许多情况下，仅验证已应用更改并在需要时才应用更改很有用。例如，当文件中的配置项丢失或具有错误的值时，在多次应用操作时仅添加一次或更改一次是很有用的。在许多其他情况下，例如日志文件，您不想执行幂等操作，因为您经常希望每次发生某些事件时都添加另一行。#2 楼
在我看来，不变的基础架构是与配置管理不同的模式。尽管它们可以一起使用，但是它们以两种不同的方式本质上解决问题。不可变工件的概念由来已久，Unix系统已经使用它们数十年来部署软件包。但是，一旦部署了配置文件，它们便变得可变了。幂等性为可变文件提供了一些很好的保证，我们可以知道什么时候发生了更改，只更新需要更新的内容。但是，它不能解决可变对象的所有问题，我们仍然需要满足看似数量不定的边缘情况。因为事情是易变的，并且我们是幂等的，所以我们需要首先确定需要进行哪些更改，然后通常以非常特定的顺序执行它们。在部署软件包时，尤其是在零停机时间部署时，我们需要仔细地组织变更以防止任何请求被丢弃。因为我们只是用另一个对象（无论是二进制文件，容器还是虚拟机）替换了某个对象，将其投入使用并淘汰了旧的对象。这只是零停机时间部署的一个示例。
随着工具的进步，我们可以在很少的时间内将不可变的工件部署到数千个系统中，我们看到使用不可变的工具来管理系统远比配置管理更可行。但是，工具尚不存在，并且两者仍然都有用例。我在这个主题上做了一个演讲，解释了从完全可变到完全不可变的线性演进，这是一个频谱，每个公司都会选择最适合他们的。
评论
您是否碰巧有可以链接到的演讲视频？
–詹姆斯·谢威（James Shewey）
17年11月14日在16:48
它链接在youtube.com/watch?v=I3DuUzGC-SU帖子中
–机器人
17年11月15日在3:11
评论
由于幂等性具有重复性，因此它也暗示伪全能。如果用户在配置管理系统之外更改了某些内容，则很可能会将其改回（如果配置管理系统以root用户身份运行）。因此，这不仅意味着状态没有改变。但是状态仍然是配置管理系统指示状态的方式。因此，幂等系统和不变系统的一种相似的方法
–詹姆斯·谢威（James Shewey）
17年11月2日在17:08
您描述了配置管理系统的一个属性，也许是“承诺理论”。但这不是幂等的意思，幂等只是配置管理系统的工具库中的工具。一旦开始更改状态，以任何一种方式对事物进行变异，就不能以任何形式类似于不变性。这是一个矛盾。
– Evgeny Zislis
17年11月2日在17:46
@JamesShewey万能意味着无限的力量，我怀疑幂等意味着任何与此相关的东西。
– Evgeny Zislis
17年3月3日，19：24
onmi =许多| idem =重复|效能=力量。它们共享相同的根，表示已完成某项操作（配置）。因此，在一遍又一遍地执行相同的操作时，如果尝试进行更改，则配置管理系统会将其覆盖，从而使更改变得无所不能。 （而且我敢肯定，可以通过禁用配置管理服务来破解它，因此不是真正的onmi）。此属性可用于设置不可变状态。
–詹姆斯·谢威（James Shewey）
17年3月3日在20:19
一旦开始更改状态-如果使用配置管理系统更改状态，是的，那么它将变得矛盾。配置管理系统的存在和使用与不变性不是互斥的，而是选择使用它的方式。
–詹姆斯·谢威（James Shewey）
17年11月3日在20:22