2016-11-29 20 views
0

何かがインストールされているかどうかを確認し、必要に応じてインストールしてからもう一度チェックするコンパクトな方法はありますか?任意の関数install_thingis_installedため不可能:チェックして、再度確認してください

- name: check whether X is installed. 
    shell: is_installed >/dev/null || echo nope 
    register: thing_is_installed 
    - name: install something 
    shell: install_thing 
    when: thing_is_installed=="nope" 
    - name: check that the install succeeded 
    shell: is_installed 

:現時点では私はこの詳細な混乱がありますか?大きな問題は、is_installedが2回起こることです。そのため、不注意、監督など何らかの理由で、誰かが1つの関数呼び出しを変更するが、他の関数呼び出しを変更するリスクがあります。シェルは単なる例です。そのパターンを認識するかもしれません - それはidenpotentビルド関数の中核ビルディングブロックです。 is_installedは所望の状態を定義し、install_thingは所望の状態に到達する方法を定義する。私はこのようになりますフォームがあることを期待して、私はちょうどそれを見つけることができません:それはテストの任意の数で使用することができるという利点がある

- name: Install boondoggle 
    shell: 
    check: is_installed 
    install: install_thing 

あるいはこれを、単にシェルではない:

- name: Install bongle 
    check: 
    shell: is_installed 
    install: 
    shell: install_thing 
+1

MarkdownエンジンはGitHub風味ではありません。三重引用符は複数行のコードブロックを開始しません。 '{}'ボタンを使用して、その目的のために4つのスペースインデントを追加します。 –

+0

ありがとう@CharlesDuffy –

+0

ところであなたのコマンド/スクリプトの終了ステータス値は?理想的な世界では、「すでに完了しました」、「完了する必要があります」、「正常に完了しました」、「試行錯誤しました」などの別個の値があります。 –

答えて

1

不在NOOPモード(つまり、あなたが失敗したことを報告したががあなたの目的の状態ではまだいないよ場合に任意のインストールでフォロースルーしていないモードである)、あなたにかもしれません2つをうまく組み合わせます。私は次のように似たパターンを使用する傾向がある:

- name: "enforce-foo" 
    command: /path/to/enforce-foo-script 
    register: enforce_foo 
    failed_when: "(enforce_foo.rc != 0) and (enforce_foo.rc != 2)" 
    changed_when: "enforce_foo.rc != 2" 

...ここで、我々は何もする必要なしに終了し、終了ステータス2は、我々が行われたことを示すためにあることを示すために、終了ステータス0を使用しています変更。

+0

興味深いですが、ほとんどの既存の機能は0/1/2の終了コードに従っていないので、基本的には希望の状態がチェックされている現実にシェルに押し出されます。だから、なぜ使えないの? –

+1

あなたは$ @#%が(そしてパペットとソルトスタックとcfengine)無能な人を嫌っている人と話しているので、その答えを私には見ないでください。私はパレットを愛することができればと思っています。その実装言語は私が好きな言葉ですが、残念ながら、それは「仕事にならない」カテゴリでも終わります。 –

+0

しかし、あなたは明らかにブロックの周りにいたので、私はあなたの入力を感謝します! –

2

既存のシェルスクリプトがたくさんある場合は、オプションが制限されます。特に、パラメータと戻り値に矛盾がある場合

Ansibleのシェルモジュールを使用するのが最後の手段です。時々あなたはそれを使用する必要がありますが、最初に 'package'と 'pip'のようなモジュールを考えてください。あなたが必要とするかもしれない完全な役割については、ansible-galaxyもチェックしてください。試してみるのは簡単ですが、仕事がすでに他の人によって行われていることがあります。必要なものの50%に過ぎない場合もあります。それでも時間が節約されます。

シェルオプションでは、 'creates'オプションがあります。これは、シェルスクリプトによって作成されたファイルの存在をチェックし、場合によっては 'check' - > 'do' - > 'check'の代わりに使用することができます。また、ドキュメントには便利なtest strategiesの詳細があります。明らかにそれはすべてあなたの特定のニーズに依存します。

シェルスクリプトが一様である場合は、write your ownラッパーモジュールを使用することもできます。少しのPythonの知識で、これは非常に簡単です。もう一度、open source examplesを見つけて、最初からやり直すのではなく、必要なものに似たものから作業することができます。モジュールの内部処理は、まだチェック - >修正 - >チェックを行う必要がありますが、アノニムのプレイブックの中では、コードは非常にきちんとしていて、再送を避けます。

+0

戻り値は、テストでは一貫性があり、インストーラには一貫性がありません。シェルスクリプトはたくさんの関数のペアであり、関数の1つが「希望の状態にあります」関数であり、2つ目は「目的の状態にする」関数であるという点で構造化されています。したがって、論理的な手順はきれいです。疑問は、Ansibleで同じロジックを表現する方法です。 –

+0

私は自分のモジュールのために行くかもしれない。このようなモジュールがすでに存在していれば、私はその車輪を再発明したくない。 –

+0

私のスクリプトとanusibleの組み込みモジュールとの間には、いくつかの哲学的な違いがあります。例えば。私のaptインストーラは、aptを更新するかどうかの決定は、受け入れ可能なキャッシュ時代(state of expression)で表現されます。可能な限り、更新キャッシュは不可欠なブール値です。それは奇妙に思える。 –

関連する問題