べき等性と不変性の比較

DevOpsの多くは、不変のインフラストラクチャを実装し、変更が必要な場合に（変更するのではなく）再展開することで、ペットではなく牛の考え方を適用しています。

構成管理には、べき等の同様の原則があります。不変性と無力の比較の利点、類似点、欠点は何ですか？どちらがより効率的ですか？これらを相乗的に使用できますか（例：構成管理を使用したVMまたはDockerコンテナーの定期的な削除と再デプロイ？）

2つの用語は大きく異なります。

immutability文字通り「突然変異なし」または「変更なし」を意味するから始めましょう。DevOpsの意味では、アーティファクトを作成したら、コンテナーイメージ、VMイメージ、またはコンパイル済みコードのパッケージである可能性があります。決して変更しないことを宣言します。多くの場合、変更が必要な場合は、代わりに「もの」の新しいバージョンが作成されることを宣言します。

この用語idempotenceは、変更が複数回適用されたときに、状態が1回だけ変更（変更）されることを意味します。最初に、変更が適用されることをすでに想定しています。つまり、不変なものとべき等のアクションの両方を実行することはできません（コントラクトによってアクションは実行されません）。

構成管理ツールのidempotence使用において、同じ変更を複数回適用する場合に使用されます。行追加と同様localhostに/etc/hostsファイルを、あなたは本当にこのような複数の行を必要としないと1がすでに存在する場合は、再度追加しようとしないように安全です。

またidempotent、物事を変更しようとするアクションを説明するために使用される用語であり、それらに対して行われた変更に対して設定immutableされる名詞（オブジェクト）を説明するために使用されます。

なぜimmutableオブジェクトが役立つのですか？たとえば、開発環境からqaから本番環境にコピーする場合。あなたはそれがどのように振る舞うのかについてかなりたくさん（しかしすべてではない）を知っています。多くの場合、正常に機能している部分は一貫しており、壊れている部分も一貫しています。

idempotentアクションが役立つのはなぜですか？一部のオブジェクトの状態を変更したい場合、多くの場合、変更が適用されたことを確認し、必要な場合にのみ変更を適用すると便利です。たとえば、ファイル内の構成アイテムが欠落しているか、値が間違っている場合、アクションを複数回適用しながら、1回だけ追加するか、1回だけ変更すると便利です。他の多くの場合、ログファイルなど、イベントが発生するたびに別の行を追加したい場合が多いため、べき等のアクションは必要ありません。

不変のインフラストラクチャーは、私の考えでは、構成管理とは異なるパターンです。それらは一緒に使用できますが、2つの異なる方法で本質的に問題に取り組みます。

イミュータブルアーティファクトの概念には長い歴史があり、Unixシステムは何十年もそれらを使用してソフトウェアパッケージを展開しています。しかし、それらがデプロイされると、構成ファイルが変更されたため、状況が変化しやすくなりました。べき等性は、変更可能なファイルにいくつかの素晴らしい保証を提供します。物事がいつ変更されたかを知ることができ、更新が必要なものだけを更新します。ただし、変更可能なオブジェクトのすべての問題を解決するわけではありません。一見無限に見えるエッジケースに対応する必要があります。物事は変更可能であり、べき等であるため、最初にどのような変更を加える必要があるのか​​を確立してから、一般に非常に特定の順序でそれらを実行する必要があります。特にゼロダウンタイムの展開でソフトウェアパッケージを展開するときは、要求がドロップされないように変更を慎重に調整する必要があります。

この複雑さは、オブジェクトを変更する代わりに不変のアーティファクトをデプロイすることで最終的に回避できます。これは、オブジェクトを別のオブジェクト（バイナリ、コンテナー、仮想マシンのいずれか）に置き換えるだけで、サービスを開始して古いオブジェクトを廃棄するためです。 。これは、停止時間ゼロの導入の一例にすぎません。

非常に短い時間で不変のアーティファクトを数千のシステムにデプロイできるようにするツールの進歩により、不変のツールを使用して構成管理よりもはるかに実行可能なシステムを管理できるようになりました。ただし、ツールはまだ存在せず、両方のユースケースがまだあります。私はこのテーマについて、完全に可変から完全に不変への線形の進行を説明する講演を行いました。それはスペクトルであり、各企業はそれらに最適な場所を選択します。