问题描述
在DevOps中，许多人通过实施不可变基础设施和在需要更改时重新部署（而不是修改）来应用“牛群而非宠物”的理念。配置管理具有幂等性的类似原则。不可变性和幂等性的比较优势、相似之处和缺点是什么？它们可以协同使用吗（例如，使用配置管理定期删除和重新部署VM或Docker容器）？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
不可变性
不可变性（immutability）的字面意思是“没有变化”或“没有改变”。在DevOps中，它意味着一旦创建了一个构件，无论是容器镜像、虚拟机镜像还是编译代码的软件包，你声明你将永远不会对其进行更改。通常，如果需要进行任何更改，你会声明将创建一个新版本的“事物”。
幂等性
幂等性（idempotence）意味着当多次应用更改时，状态只会发生一次变化。首先，它已经假设将会应用更改，这意味着你不能同时拥有不可变性和对其进行幂等操作（按合同，不对其进行任何操作）。
在配置管理工具中，幂等性在某些情况下用于多次应用相同的更改。例如，向/etc/hosts文件添加一行localhost，你不需要多个这样的行，如果已经存在一行，安全起见不需要尝试再次追加。
此外，幂等性是用来描述试图改变事物的“动作”，而不可变性用来描述不希望被改变的“名词”（对象）。
不可变性的优势
不可变性对象之所以有用，是因为当你将其从开发环境复制到QA环境再到生产环境时，你已经对其行为有了相当多的了解（但并非全部）。在许多情况下，工作正常的部分将保持一致，而损坏的部分也将保持一致。
幂等性操作的优势
幂等性操作之所以有用，是因为当你想要更改某个对象的状态时，通常只需验证已应用更改并在需要时应用更改。例如，当文件中的配置项缺失或值错误时，只需添加一次或更改一次，而应用多次操作。在许多其他情况下，如日志文件，你不希望有幂等性操作，因为你通常希望每次发生某个事件时追加另一行。
不可变性和幂等性的比较
不可变性和幂等性是两个非常不同的概念。不可变性用于描述对象，而幂等性用于描述操作。不可变性意味着对象不会被改变，而幂等性意味着操作在多次应用时只会改变状态一次。它们可以在某些情况下一起使用，但它们的目标和应用方式不同。
可协同使用
不可变性和幂等性可以在一些场景中协同使用。例如，使用配置管理定期删除和重新部署VM或Docker容器，可以通过重新部署不可变的容器来实现不可变性，同时使用幂等性操作来确保状态的正确性。
然而，需要注意的是，不可变性和幂等性并不是完全互斥的。它们可以在不同的层次和不同的场景中使用，具体取决于你的需求和偏好。