べき等性と不変性の比較


8

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

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

回答:


9

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

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

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

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

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


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

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


1
べき等は、反復性があるため、疑似全能性も意味します。ユーザーが構成管理システムの外で何かを変更した場合、おそらくそれは元に戻されます(構成管理システムがrootとして実行されている場合)。したがって、それは単にthe state is not changed.状態を意味するのではなく、状態は構成管理システムが指示する方法のままであることを意味します。したがって、1つの方法の
べき

構成管理システムの特性、おそらく「約束の理論」について説明します。しかし、それはべき等の意味ではありません。べき等は、構成管理システムの武器の単なるツールです。状態の変更を開始し、いずれかの方法で変更を行うと、不変性に似た状態になることはありません。それは矛盾です。
エフゲニー

@JamesShewey全能は無制限のパワーを意味し、べき等性がそれに関連する何かを意味することは疑わしいです。
エフゲニー

onmi = many | idem = repeated | 効力=力。どちらも同じルートを共有し、何か(構成)が完了したことを示します。したがって、同じことを何度も行う場合、変更が試みられると、構成管理システムによって変更が無効になり、全能になります。(これは、たとえば、構成管理サービスを無効にすることでハッキングされる可能性があるため、本当に onmi ではありません)。このプロパティを使用して、不変の状態を設定できます。
James Shewey 2017年

1
Once you start changing state- 場合は、構成管理システムと状態を変更する、はい、そしてそれは、矛盾になります。構成管理システムの存在と使用は、不変性と相互に排他的ではありません。それは、使用方法の選択にすべてあります。
James Shewey 2017年

2

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

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

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

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


あなたはあなたがリンクできる話のビデオを偶然持っていますか?
James Shewey 2017年

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.