Understanding SaltStack State Compiler Ordering-State状態コンパイルの順序を理解する

9932 ワード

テキストリンク:https://docs.saltstack.com/en/latest/ref/states/compiler_ordering.html
注:このチュートリアルは中級チュートリアルです.状態システムとsalt式の作成についていくつかの基本的な理解があると仮定します.
Githubで保守されているこの技術資料も参照できます.Understanding State Compiler Orderingです.
Saltのステータスシステムは、シンプルさを犠牲にすることなく、構成管理システムのすべての機能を提供することを目的としています.このチュートリアルでは、Saltがステータス実行の順序をどのように定義するかをユーザーに詳細に説明します.
このチュートリアルは、バージョン0.17.0からSaltの動作を説明するために作成されました.
Compiler Basics-コンパイラの基礎知識
ステータスコンパイルの順序を深く理解するには、ステータスコンパイラに関する非常に基礎的な知識が役立ちます.
High Data and Low Data-高度なデータと低レベルのデータ
YAMLでSalt式を定義する場合、コンパイラは表すデータを「High Data-Advanced Data」と呼びます.コンパイラに最初にデータをロードすると、次のコマンドを実行して辞書を表示できる大規模なpython辞書です.

salt '*' state.show_highstate

そして、この「High Data-Advanced Data」構造を「Low Data-Low Data-Low Data」にコンパイルする.低レベルのデータは、Saltの構成管理システムで単一の実行アクションを作成することに相当し、実行する単一のステータス呼び出しのシーケンステーブルである.低レベルデータがコンパイルされると,評価順序の結果が見られる.
次のコマンドを実行して、下位レベルのデータを表示します.

salt '*' state.show_lowstate

注:ステータス実行モジュールには、ステータスシステムを評価するための多くの関数が含まれており、非常に読む価値があります.これらのルーチンは、ステータスをデバッグしたり、Saltステータスシステムの理解を深めるのに役立ちます.
たとえば、次のように書かれています.

apache:
  pkg.installed:
    - name: httpd
  service.running:
    - name: httpd
    - watch:
      - file: apache_conf
      - pkg: apache

apache_conf:
  file.managed:
    - name: /etc/httpd/conf.d/httpd.conf
    - source: salt://apache/httpd.conf

上の状態構成では、次のようなjson形式のHighデータが生成されます.

{
    "apache": {
        "pkg": [
            {
                "name": "httpd"
            },
            "installed",
            {
                "order": 10000
            }
        ],
        "service": [
            {
                "name": "httpd"
            },
            {
                "watch": [
                    {
                        "file": "apache_conf"
                    },
                    {
                        "pkg": "apache"
                    }
                ]
            },
            "running",
            {
                "order": 10001
            }
        ],
        "__sls__": "blah",
        "__env__": "base"
    },
    "apache_conf": {
        "file": [
            {
                "name": "/etc/httpd/conf.d/httpd.conf"
            },
            {
                "source": "salt://apache/httpd.conf"
            },
            "managed",
            {
                "order": 10002
            }
        ],
        "__sls__": "blah",
        "__env__": "base"
    }
}

次のLow Dataデータは次のように見えます.

[
    {
        "name": "httpd",
        "state": "pkg",
        "__id__": "apache",
        "fun": "installed",
        "__env__": "base",
        "__sls__": "blah",
        "order": 10000
    },
    {
        "name": "httpd",
        "watch": [
            {
                "file": "apache_conf"
            },
            {
                "pkg": "apache"
            }
        ],
        "state": "service",
        "__id__": "apache",
        "fun": "running",
        "__env__": "base",
        "__sls__": "blah",
        "order": 10001
    },
    {
        "name": "/etc/httpd/conf.d/httpd.conf",
        "source": "salt://apache/httpd.conf",
        "state": "file",
        "__id__": "apache_conf",
        "fun": "managed",
        "__env__": "base",
        "__sls__": "blah",
        "order": 10002
    }
]

このチュートリアルでは、Low Dataデータ評価とstateステータス実行時について説明します.
Ordering Layers-実行順序を定義する階層
Saltは,状態実行時にコマンド実行順序を評価する2つのインタフェースを定義し,この実行順序を複数回伝達することで最終的に定義する.
Definition Order-順序を定義する機能システム
注意:Masterプロファイルのstate_auto_orderオプションをFalseに設定することで、「順序の定義」のシステム機能を無効にできます.
ソートの最上位レベルは「順序の定義」システムです.定義順序システム機能は、Salt式で状態の実行順序を定義します.include文またはtopファイルを含まない基本状態では、ステータスはファイルの上部からソートされるだけであるため、includeシステムは定義順序のためにより多くのルールを導入し始める.
上記の「Low Data」と「High Data」を振り返ると、「order」キーがデータに透過的に追加され、「順序の定義」機能が有効になります.
The Include Statement-Include文
基本的に、式にinclude文が含まれている場合、含まれる式は式の内容を含む前に実行されます.また、include文の値はリストであるため、それらを含む順序で順次ロードされます.
次の例では、foo.sls

include:
  - bar
  - baz

bar.sls

include:
  - quo

baz.sls

include:
  - qux

上記の場合、stateが呼び出す.apply fooでは、式が次の順序でロードされます.

quo

bar

qux

baz

foo

The order Flag-Orderキーワードフラグ
「順序を定義する」機能システムはバックグラウンドで透過的に実行されるが、ステータスのorderフラグを使用して順序を明示的に上書きすることもできる.

apache:
  pkg.installed:
    - name: httpd
    - order: 1

この「order」フラグは、「definition order」システムを超え、作成が常に最初に実行されます.最後に実行されるか、または特定のフェーズで実行されるステータスが非常に簡単になることを指定します.良い例は、他の操作の前に設定する必要がある多くのパッケージ・リポジトリを定義したり、ステータス実行の終了時にorder：lastまたはorder：-1を使用して実行する必要がある最終チェック操作を定義したりすることです.
orderフラグが明示的に設定されている場合、「definition order」システムは、このステータスの実行順序の設定を省略し、定義されたorderフラグを直接使用します.
Lexicographical Fall-back-辞書に戻る順序
Saltステータスは常に同じ順序で実行されます.バージョン0.17.0で「順序の定義」機能を導入する前に、ステータス名に基づいてすべてのコンテンツを辞書順にソートし、関数をソートし、id順にソートします.
これはSaltがステータスが常に同じ順序で実行されることを保証する方法であり、それらがどこに配置されているかにかかわらず、追加の定義順序方法により、この順序がより容易に従うことができます.
ディクショナリ順序は依然として適用されますが、2つの順序文が競合している場合にのみ有効です.これは、複数のステータスに同じ順序番号が割り当てられている場合、辞書順序に戻り、実行するたびに限られた順序で行われることを保証することを意味します.
注:state_auto_order：Falseが有効になっている場合、orderキーは自動的に設定されず、辞書の順序は他のキーから派生することができます.
Requisite Ordering-依存順
Salt状態は完全に宣言され、システムが存在するべき状態を宣言するように記述されています.これは、コンポーネントが他のコンポーネントに正常に設定されていることを要求する可能性があることを意味します.他の管理システムと異なり、SaltのRequisiteシステムは実行時に評価されます.
このためにrequisiteシステムも構築され、所与のステータスセットに対して常に同じ実行順序が変更されないことを保証した.これは、状態を完全に予測可能な順序で処理する実行時に、他の宣言構成管理システムのようにイベントループベースのシステムを使用しないことによって達成される.
Runtime Requisite Evaluation-ランタイム依存性の評価
コンポーネントが見つかると、Requisiteシステムが評価され、Requisite条件は常に同じ順序で評価されます.この説明の後に例を挙げるが、元の説明は、線形相関評価シーケンスを作成したため、最初はめまいがする可能性がある.
「Low Data」は、辞書の順序付けされたリストまたは辞書であり、各辞書は、ステータス実行時に辞書のリスト内の順序で評価されます.単一の辞書を評価する場合、必須条件を検査し、順序に従って必須条件を評価し、まずrequir e、それからwatchを行い、最後にprereq検査を行う.
注意:require_inとwatch_inなどの文でRequiredを使用すると、実行時評価の前にrequireとwatch文にコンパイルされます.
各条件には、辞書リストで検索して実行する順序付き条件リストが含まれます.すべての要件を評価して実行すると、要件のステータスを安全に実行できます(要件が満たされていない場合は実行しません).
これは、常に同じ順序で需要を評価しなければならないことを意味し、Saltステータスシステムのコア設計原則の1つを再確保し、実行結果が常に限られていることを保証します.
Simple Runtime Evaluation Example-単純な状態実行順序評価分析例
上記の「低データ」を指定すると、ステータスは次の順序で評価されます.

はpkgを実行する.installedは、apacheパッケージがインストールされていることを確認します.このパッケージには必須項目が含まれていないため、実行する最初の定義ステータスです.

サービスを評価します.runningステータスは実行されていませんが、監視条件が見つかりました.そのため、順番に読み取り、実行時にまずファイルをチェックし、まだ実行されていないことを確認し、評価するファイルステータスを呼び出します.

ファイル状態は、pkg状態のように必要な条件が含まれていないため、評価され、実行される.

は、サービス状態を評価し続け、pkgの必要条件を確認し、その条件を満たし、すべての条件を満たしていると判断し、サービス状態を実行する.

ベストプラクティス-ベストプラクティス
Saltのベストプラクティスは、すべての条件が明確で、遡及可能な依存関係が作成され、ほとんどの移植可能な式に適用されるため、すべての関連条件を使用して正式なstates状態を記述する方法を選択し、継続することです.古典的なコマンドシステムの動作と同様の動作を完了するために、すべての必要条件を省略し、master構成でfailhardオプションをTrueに設定すると、最初の障害が発生したときにすべての状態の動作を停止します.
最後に、Requisiteの必要条件を使用すると、非常に緊密で微細な状態が作成され、必要条件を使用しないと、完全なシーケンスが実行され、記述が少し容易になり、実行の制御がより少なくなります.

NeHeチュートリアルQt実装-lesson 11

numpyにおける配列の配列型インデックスとブール型インデックス