幂等性与不可变性的比较

Question

DevOps中的许多人通过实现不变的基础设施并在需要更改时重新部署(而不是修改)来应用牛-不-宠物思想。

配置管理有着与幂等性相似的原理。不变性和阳痿有什么比较的好处、相似之处和缺点，哪个更有效率？这些是否可以协同使用(例如，使用配置管理定期删除和重新部署VM或Docker容器？)

Answer 1

这两个术语是非常不同的。

让我们从immutability开始，它的字面意思是“没有突变”或“没有变化”。在DevOps的意义上，这意味着一旦您创建了一个工件，无论是容器映像、VM映像，还是编译代码中的包，您都将声明永远不会更改它。通常，如果需要进行任何更改，则声明将创建"thing“的新版本。

术语idempotence意味着，当多次应用更改时，状态只会发生一次突变(更改)。首先，它已经假定将有应用的更改，这意味着您不能拥有既不可变又具有幂等操作的东西(没有通过合同对其执行任何操作)。

在配置管理工具的使用中，在某些情况下，当多次应用相同的更改时，会使用idempotence。就像向localhost文件中添加表示/etc/hosts的行一样，您实际上不需要多个这样的行，如果已经存在这样的行，那么不尝试再次添加是安全的。

idempotent也是一个术语，用来描述试图改变事物的行为，而immutable则用来描述针对对其所做的更改而设置的名词(对象)。

为什么immutable对象有用？因为当您将其复制时，例如从dev环境复制到产品。关于它的行为，你已经知道了很多(但不是所有的)。在许多情况下，正在工作的部分将是一致的，而被破坏的部分也将是一致的。

为什么idempotent操作是有用的？因为当您想要更改某个对象的状态时，在许多情况下，只验证已应用更改并在需要时应用更改是有用的。例如，当文件中的配置项丢失或值错误时，只添加一次或在多次应用该操作时只更改一次是有用的。在许多其他情况下，比如日志文件，您不希望有幂等的操作，因为您通常希望在每次发生事件时都附加另一行。

Answer 2

在我看来，不可变的基础设施是配置管理的另一种模式。虽然它们可以一起使用，但它们以两种不同的方式自然地处理问题。

不可变构件的概念由来已久，Unix系统几十年来一直使用它们来部署软件包。但是一旦它们被部署，配置文件就会改变，所以事情就变得可变了。Idempotency提供了一些对可变文件的很好的保证，我们可以知道什么时候事情发生了变化，并且只更新了需要更新的内容。然而，它并不能解决所有可变对象的问题，我们仍然需要满足看似无限多的边缘情况。因为事物是可变的，而且我们是幂等的，所以我们需要首先确定需要做什么改变，然后按照非常具体的顺序执行它们。在部署软件包时，特别是在零停机时间部署时，我们需要仔细安排更改，以防止任何请求被删除。

这种复杂性最终可以通过部署不可变的工件来避免，而不是对它们进行适当的变异，因为我们只需将某个对象替换为另一个对象(不管它是二进制的，还是容器的，还是虚拟机的)，将其投入服务并退出旧的对象。这只是零停机时间部署的一个例子。

随着工具的进步，允许我们在非常短的时间内将不变的工件部署到数千个系统上，我们看到使用不可变的工具来管理系统比配置管理更可行。然而，工具还没有出现，而且仍然有一个用于这两个方面的用例。我在这个主题上做了一次谈话，它解释了从完全可变到完全不变的线性过程，这是一个光谱，每个公司都会选择最适合它们的地方。