収束とべき等は、シェフ固有ではありません。それらは一般に構成管理理論に起因しますが、他の分野、特に数学で使用されています。
より基本的なべき等から始めましょう。べき等の数学的な使用を無視し、代わりに、構成管理の人々がそれについて話すときの意味に焦点を当てます。つまり、「同じアクションを複数回適用しても、システムの状態に悪影響はありません」。べき等演算の簡単な例はmkdir -pです。
mkdir -p /var/lib/statedir/myapp
このコマンドを何度実行しても、そのツリーが作成されます。べき等操作についてこれを述べる別の方法は、「ツールを何度も実行しても、最初からシステムが変更されない」というものです。
それを収束と対比します。一般的に、収束するということは、[人や]物事をまとめることを意味します。構成管理では、コンバージェンスとは、システムの状態を定義されたポリシーに一致させることを意味します。つまり、変更が必要な場合にのみ、システムに変更が加えられます。収束操作の簡単な例は次のとおりです。
if [ ! -d /var/lib/statedir/myapp ]; then
mkdir -p /var/lib/statedir/myapp
fi
目的のディレクトリが存在しない場合にのみmkdirコマンドを実行するため、これは収束します。これを「テストと修復」操作とも呼びます。つまり、管理している特定のものの現在の状態をテストし、その状態でない場合は特定のコマンドまたは操作で修復します。これは、Chefが次のようなリソースを使用して舞台裏で行うことです。
directory '/var/lib/statedir/myapp' do
recursive true
end
私たち（Chef）がこれについて話す方法は、Chefが冪等なアクションを実行して、システムをさまざまなリソースによって宣言された状態に収束させることです。 Chefのすべてのリソースは宣言型であり、リソースの現在の状態についてテストを実行してから、それに一致するようにシステムを修復します。
Chefがどのように機能するかについて雑草を深く理解するために、Chefの実行には「コンパイル」フェーズと「収束」フェーズがあります。 「コンパイル」フェーズでは、ノード上のRubyレシピを評価し、「リソースコレクション」に追加するリソースオブジェクトを探します。すべてのレシピを評価したら、次に、「収束」フェーズに入り、リソースコレクションを繰り返し、適切なアクションを実行してリソースを目的の状態にします。これにより、ユーザーの作成、ファイルの書き込み、パッケージのインストールなどが行われます。
免責事項：私は構成管理コミュニティの部外者であり、次のことを理解するのに何時間もかかりました。私はこの回答で構成管理コミュニティを批判しているので、彼らの世界は私の世界ではなく、現在の仕事では構成管理ツールも使用しておらず、私が見つけたものだけで判断していることに注意してください。 Googleで。
定義
操作が収束）であると言うことは、大まかに言って、それが管理するシステムのあらゆる部分を指定された状態にすることを意味します。
構成管理の人々が操作がべき等）であると言うとき、それらは通常、一度実行した直後に2回実行すると、冗長な作業を行わずに2回目の実行がすぐに終了することを意味します。
リソースがChefのコンテキストでべき等として記述されている場合、それは、リソースがすでに目的の状態になっている後に後続のChefが実行されることを意味し、xで更新済み」としてカウントされません。/yリソースが更新されました実行の最後にメッセージが表示されます。
ほとんどの組み込みリソースは、デフォルトでこの最後の最も厳密なべき等の定義を満たし、 only_ifおよびnot_if を使用して、独自のレシピおよびカスタムリソースでそれを実現できることに注意してください。警備員と converge_if_changed 。
いくつかの解説、および他の定義についてのメモ
紛らわしいことに、インターネットで見つけた「べき等」の定義の大部分は私が今与えたもののどちらにも一致しません。専門家が何であるかを信頼するのではなく定義が何であるか、私は彼らがどのように実際に用語を使用するか。誰かが「べき等」の定義を与え、数段落後にその定義と明らかに一致しない方法で単語を使用するのを見つけることは腹立たしいほど一般的です。 。
これを探求するために、構成管理の分野の外に存在する「べき等」の定義を探求することから始めましょう。そのような定義の多くは、ウィキペディアの https://en.wikipedia.org/wiki/Idempotence にリストされています。構成管理のコンテキストでべき等の意味として最も頻繁に（間違って）与えられるものは次のとおりです。
- 数学では、関数fは、f(f(x)) = f(x)の場合、べき等であると言われます。 xのすべての可能な値に対して。
- 数学では、他の種類の数学的対象の多くは、それらが何らかの形式的な定義または他のものを満たしている場合、べき等であると言われます（一般に、「操作を繰り返し行うことは、一度行うことと同じ効果があります」という共通のテーマがあります）。
- プログラミングでは、関数またはプロシージャがべき等であると言うことは、次の2つのいずれかを意味します。
- 引数を取り、値を返す関数の場合、数学的な意味とまったく同じです。
- 副作用のある関数の場合、関数を1回呼び出した後、後続の呼び出しでシステム状態が変更されないままになります。
多くの混乱したソースは、これらの定義の1つを構成管理コンテキストでの「べき等」の意味として示し、すぐに、実際に使用している定義ではないことを明確にする方法でこの用語を使用します。いくつかの例：
ペースの この質問に対する競合する答え 。そこで彼は次のように主張しています。
システム（基礎となる状態が変更されていない）でステップを複数回実行した後、結果がステップが1回実行された場合と同じである場合、ステップはべき等です。
しかし、次に、べき等ではないステップの例としてこれを示します。
rm -rf /var/log/myapp mkdir -p /var/log/myapp明らかに、このステップはPaceのべき等の定義を満たしています。これは、連続して複数回実行すると、1回実行した場合と同じ最終状態（つまり、
/var/log/myappが存在し、空の状態）になるためです。ただし、2回目の実行時に冗長な作業を行うため、Paceはそれをべき等ではないと説明しています。MischaTaylorとSethVargoの本Learning Chef：A Guide to Configuration Management and Automation。そこで、彼らは次のように主張しています。
Chefコードがidempotentの場合、同じシステムで複数回実行でき、意図しない副作用を発生させることなく、結果は常に同じになります。
しかし後で、彼らのレシピ例の1つにコメントします。
私たちのレシピはべき等性テストに合格していますか？悲しいことに、いいえ。 ...シェフは、やらなければならないことがまだあると誤って考えています。この2回目の実行で2/3のリソースが更新されました。レシピが本当にべき等である場合、0/3のリソースが更新されます。 Chefはシステムの状態を検査し、前回の実行以降何も変更されていないことを認識し、2つの実行の間に誰もノードに触れず、リソースの更新を実行しませんでした
繰り返しになりますが、レシピが複数回実行されたときにシステム状態が変更されないことに基づくべき等の定義を述べていますが、実際にはWordを使用して、不要な作業が回避されることを意味します。
ベンフォードの べき等：大きくて怖い言葉だけではない Puppetブログで、彼は最初にこのべき等の定義を示しています...
べき等は、1回実行しても10,001回実行しても同じ効果を持つ操作を説明する単なる単語です。結果が増加し続けるため、1を加算することはべき等ではありませんが、1を乗算することは、何回乗算しても答えが同じであるため、べき等です。
次に、彼はこの例のべき等を示します。これは上記の定義と一致していますが、少し疑わしいです-後続の実行に焦点を合わせているため冗長な作業を行わないではなく）それらに同じ結果に達する：
あなたが12歳で、お母さんがゴミを出すように頼んだときを想像してみてください。あなたはいい子だったので、ゲームボーイを落とし、尋ねられたとおりにジャンプしてやりましたね。
しかし、30分後、彼女が居間を歩いて戻って、あなたが「スーパーマリオランド」を演奏しているソファで丸くなっているのを見たとき、彼女は再びあなたにゴミを出すように言いました。空のゴミ袋を取り出そうと跳ね上がったのではないかと強く思います。代わりに、あなたは「お母さん、もうやった！」と言いました。それはべき等です。ゴミを出すように一度言われた場合の効果は、二度言われた場合の効果と同じです。それはすでに行われているので、あなたはそれを再びしませんでした。
それから最後に、彼は自分の定義を風に投げ、それを繰り返し実行すると同じ結果に達するという事実にもかかわらず、べき等ではないと主張する操作の例を示します。
では、冪等ではない幹部を書いたことで非難されたときはどうでしょうか。 Puppetを初めて使用する人は、通常、置き換えるシェルスクリプトを持っており、次のようなコードを記述します。
exec { '/usr/bin/curl http: //server.net/packages/package.tar.gz -o /tmp/package.tar.gz ': } -> exec { 'tar -xf /tmp/package.tar.gz -C /tmp/package': } -> exec { '/tmp/package/installer.sh': } file { '/tmp/package': ensure => absent, force => true, require => Exec[ '/tmp/package/installer.sh'], } file { '/tmp/package.tar.gz': ensure => absent, force => true, require => Exec[ '/tmp/package/installer.sh'], }それで、それの何が問題になっていますか？うまくいきますよね？ tarballをダウンロードして解凍し、インストールしてから、自分でクリーンアップします。タイプミスやネットワークの問題がないと仮定すると、完全に実行されるはずです。そしてそれはそうなるでしょう。ただし、Puppetが実行されるたびに完全に実行されます。つまり、30分ごとにインストーラースクリプトをダウンロードして実行します。
しかし、結果は同じになります、ベン！以前、それはべき等の定義が中心になっているとあなたが私たちに言った詳細です！
明らかに、ベンは本当に彼が主張していることにもかかわらず、べき等の「冗長な作業を避ける」定義を適用しています。
操作はべき等であるが収束しないことはできますか？
はい。このような操作は、システムを指定された終了状態にしない操作ですが、does連続実行での冗長な作業を回避します。 ペースの答え は、このような操作の例を示し、 シェフのように考える 別のものを提供します：
システムは、収束することなくべき等になることができます。たとえば、べき等である疑似コード
if file X does not exist, write the current timestamp to file Xがあったとしても、特定の終了状態に収束するとは言えません。
べき等であるが収束していないと見なすことができる操作について考えることができる最も実用的な例は、一般的なパッケージマネージャーのinstallコマンドを使用してパッケージをインストールすることです。
- パッケージがインストールされていない場合は最新バージョンをインストールしますが、
- すでにインストールされている場合、古いバージョンは更新されません。
状態（取得するパッケージのバージョン）はレシピによって決定されないため、おそらく収束しませんが、不要な作業を回避することに成功します。
操作は収束できますが、べき等ではありませんか？
そのとおり！簡単な例は、すでに上で引用したベンフォードの、ファイルをローカルパスに無条件にダウンロードするものです。終了状態は常に同じ（ファイルが存在する）であるため収束しますが、実行するたびにファイルを再ダウンロードするという不必要な作業を行うため、べき等ではありません。
価値のあることとして、構成管理コミュニティが、プログラミングのより広い世界ですでに明確な意味を持っていた用語を流用し、それを関連しているがまだ明らかに異なる方法で、提供することなく）使用していることに不満を感じています。彼らの世界でそれが何を意味するかについての正式な定義。Chefドキュメントの検索（ https://www.google.co.uk/search?q=site%3Ahttps%3A%2F%2Fdocs.chef。 io + idempotent ）は、この用語の多くの使用法をもたらしますが、定義はありません。このトピックが、浮かんでいる用語の定義のほとんどが使用法と一致しない場合に人々を混乱させるのは当然のことです。
私は、この用語の使用方法と一致するべき等の定義を与えたことがある人を1人だけ見つけることができました。それは、コーダーレンジャー（別名ノアカントロウィッツ）です。以前に引用した Thinking Like A Chef で、彼は次のように書いています。
「理想的に」...とは、アクターが目的の状態を達成するためにできる限り少ないことを意味します。
そして an IRC 2015年からの会話 彼はこう書いています：
べき等とは、必要のないときにアクションを実行しないことを意味し、収束とは、特定の最終状態に「落ち着く」ことを意味します。
この一人以外に、構成管理コミュニティ全体がどのように使用しているかに一致する用語の定義を与えた人を文字通り見つけることができませんでした。
@Mark Ameryは、2つの違いのより満足のいく例を求めたので、それを提供するよう努めます。
ステップは収束ステップが正常に終了したときに、システムが既知の状態になっている場合です。
ステップはべき等システム（基礎となる状態が変更されていない）でステップを複数回実行した後、結果がステップが1回実行された場合と同じである場合。
べき等のない収束
収束するがべき等ではないステップは次のとおりです。
rm -rf /var/log/myapp
mkdir -p /var/log/myapp
手順が正常に終了すると、/var/log/myappが存在する空のディレクトリであることがわかります。
毎回/var/log/myappディレクトリを吹き飛ばすため、べき等ではありません。べき等は、システムの不要なチャーンを減らすため、望ましいものです。明らかに、/var/log/myappディレクトリに書き込むアプリケーションは、上記の手順に満足しません。
収束のないべき等
べき等であるが収束しないステップは次のとおりです。
test "$(ls -A /home/foo 2>/dev/null)" || tempfile -d /home/foo
そのスクリプトは、/home/fooにファイルがない場合にのみ、/home/fooにランダムな名前のファイルを作成します。これはべき等です。最初の実行後、ディレクトリは空にならないため、以降の実行では何も実行されません。
ただし、収束していません。作成されるファイルにはランダムな名前が付けられるため、この手順でシステムが既知の状態になっているとは言えません。
収束は、同一の状態にあり、したがって予測どおりに動作する可能性が高いシステムを作成するのに役立つため、望ましいものです。
注意
これらの用語は抽象化のようなものであり、正確ではなく、リークする可能性があります。たとえば、CPUサイクルを消費するため、演算はべき等ではないと述べることができます。高価なテストを実行する1つのべき等テストおよび修復操作は、「べき等性が低い」というのは事実ではありませんが、安価なテストを実行する別の操作よりも「べき等性が低い」と言えます。
MySQLバージョンXをインストールするステップは、異なるマシンで実行するとファイルに異なるタイムスタンプが残るため、収束しないと言うことができます。あるいは、上記で投稿したステップIS収束していると言えます。これは、システムが「/ home/fooが存在し、ファイルが1つだけ含まれている」状態のままになるためです。
これは、数学が黒板から逃げるときに起こることです。