私は他の人の Ansible コードをたくさんレビューし、自分でもたくさん書きます。 間違い (他人と私自身の両方) を分析し、また多くのインタビューを行っているうちに、Ansible ユーザーが犯す主な間違い、つまり基本的なものを習得せずに複雑な作業に手を染めてしまうことに気づきました。

この普遍的な不公平を正すために、Ansible をすでに知っている人向けに Ansible の入門書を書くことにしました。 警告しておきますが、これは人間の再話ではありません。文字が多く、写真は一切含まれていない長文です。

読者が期待するレベルは、すでに数千行の yamla が書かれており、何かがすでに制作されているものの、「どういうわけかすべてが歪んでいる」ということです。

タイトル

Ansible ユーザーが犯す主な間違いは、何かが何と呼ばれているかを知らないことです。 名前が分からないと、ドキュメントに何が書かれているかを理解できません。 生きた例: インタビュー中、Ansible でたくさんのことを書いていると言っていたように見える人は、「プレイブックはどのような要素で構成されていますか?」という質問に答えることができませんでした。 そして私が「そのプレイブックは遊びで構成されているという答えが予想される」と示唆したところ、「私たちはそんなものは使いません」というひどいコメントが続きました。 人々はお金のために Ansible を作成しており、Play は使用しません。 彼らは実際にそれを使っていますが、それが何であるか知りません。

それでは、簡単なことから始めましょう。それは何と呼ばれるものですか。 このことを知っているかもしれませんし、ドキュメントを読んだときに注意を払わなかったために知らないかもしれません。

ansible-playbook はプレイブックを実行します。 Playbook は yml/yaml 拡張子を持つファイルで、その中には次のようなものが含まれます。

---
- hosts: group1
  roles:
    - role1

- hosts: group2,group3
  tasks:
    - debug:

このファイル全体がプレイブックであることはすでに認識しています。 役割がどこにあるのか、タスクがどこにあるのかを示すことができます。 しかし、遊びはどこにあるのでしょうか？ そして、遊びと役割またはプレイブックの違いは何ですか?

すべてドキュメントに記載されています。 そして彼らはそれを見逃します。 初心者 - 内容が多すぎて、一度にすべてを覚えられないからです。 経験豊富 - なぜなら「些細なこと」だから。 経験がある場合は、これらのページを少なくとも XNUMX か月に XNUMX 回読み直してください。そうすれば、コードはクラスをリードするものになります。

したがって、覚えておいてください: プレイブックは、プレイと import_playbook.
これは XNUMX つの遊びです:

- hosts: group1
  roles:
    - role1

これもまた別の遊びです。

- hosts: group2,group3
  tasks:
    - debug:

遊びとは何ですか？ なぜ彼女が？

Play および Only Play は、ロールおよび/またはタスクのリストを、それらを実行する必要があるホストのリストに関連付けるため、Play は Playbook の重要な要素です。 ドキュメントの奥深くに次の記述があります。 delegate_to、ローカル ルックアップ プラグイン、ネットワーク CLI 固有の設定、ジャンプ ホストなど。 これらを使用すると、タスクが実行される場所をわずかに変更できます。 でも、それは忘れてください。 これらの賢いオプションにはそれぞれ非常に特殊な用途があり、決して万能ではありません。 そして、私たちは誰もが知って使用すべき基本的なことについて話しています。

「どこか」で「何か」を演奏したい場合は、playと書きます。 役割ではありません。 モジュールとデリゲートを使用するロールではありません。 あなたはそれを受け取って遊びを書きます。 その中で、ホストフィールドには実行する場所をリストし、ロール/タスクには何を実行するかをリストします。

シンプルですよね？ そうでなければどうしてあり得ますか？

遊び以外で「これをしたい」という欲求が生まれる特徴的な瞬間の一つが、「すべてを整える役割」です。 最初のタイプのサーバーと XNUMX 番目のタイプのサーバーの両方を構成する役割が必要です。

典型的な例はモニタリングです。 監視を構成する監視ロールが必要です。 監視の役割は、(プレイに応じて) 監視ホストに割り当てられます。 しかし、監視するには、監視対象のホストにパッケージを配信する必要があることがわかりました。 なぜデリゲートを使用しないのでしょうか? iptables も設定する必要があります。 代表？ 監視を有効にするには、DBMS の構成を作成/修正する必要もあります。 代表！ 創造性が欠けている場合は、代表団を作ることもできます include_role グループのリストに対してトリッキーなフィルターを使用するネストされたループ内、および内部 include_role もっとできることがある delegate_to また。 そして出発します...

「すべてを実行する」単一の監視ロールを持ちたいという良い願いは、私たちを完全な地獄に導きます。ほとんどの場合、そこから抜け出す方法は XNUMX つだけです。それは、すべてを最初から書き直すことです。

ここでどこで間違いが起こったのでしょうか？ ホスト X でタスク "x" を実行するには、ホスト Y に移動してそこで "y" を実行する必要があることがわかった瞬間、単純な演習を実行する必要がありました。移動して play を書き込み、これをホスト Y で実行します。 「x」に何かを加えるのではなく、最初から書きます。 ハードコードされた変数を使用する場合でも。

上記の段落のすべてが正しく述べられているようです。 しかし、これはあなたの場合ではありません! DRY でライブラリに似た再利用可能なコードを書きたいと考えており、それを行う方法を探す必要があるからです。

ここに別の重大な間違いが潜んでいます。 このエラーにより、多くのプロジェクトが許容範囲で書かれたもの (もっと良くなる可能性はありますが、すべてが機能し、簡単に完了できます) から、作成者ですら理解できない完全な恐怖に変わりました。 それは機能しますが、何も変更することは神から禁じられています。

エラー: ロールはライブラリ関数です。 この例えによって、多くの良い始まりが台無しになってしまったので、見ているのがただただ悲しくなります。 このロールはライブラリ関数ではありません。 彼女は計算ができず、プレーレベルの決定を下すことができません。 遊びがどのような決断を下すかを思い出させてください。

ありがとう、その通りです。 Play は、どのホストでどのタスクとロールを実行するかを決定します (より正確には、Play には情報が含まれています)。

この決定を役割に委任し、計算を伴う場合でも、あなた自身 (そしてあなたのコードを解析しようとする人) が悲惨な運命に陥ることになります。 役割はそれがどこで実行されるかを決定しません。 この決定は遊びによって行われます。 役割は、言われた場所で、言われたことを実行します。

Ansible でプログラミングすることがなぜ危険なのか、そしてなぜ COBOL が Ansible よりも優れているのかについては、変数と jinja についての章で説明します。 とりあえず、一つだけ言っておきます。各計算はグローバル変数の変更の消えない痕跡を残し、それについては何もできません。 二つの「痕跡」が交わった瞬間、すべては消え去った。

気難しい人向けの注意: この役割は確かに制御フローに影響を与える可能性があります。 食べる delegate_to そしてそれは合理的な用途があります。 食べる meta: end host/play。 しかし！ 基本を教えたことを覚えていますか? 忘れました delegate_to。 私たちは最もシンプルで最も美しい Ansible コードについて話しています。 これは、読みやすく、書きやすく、デバッグしやすく、テストしやすく、完了するのも簡単です。 そこで、もう一度:

play と play のみが、どのホストで何を実行するかを決定します。

このセクションでは、遊びと役割の対立について取り上げました。 次に、タスクと役割の関係について説明します。

タスクと役割

遊びを考えてみましょう:

- hosts: somegroup
  pre_tasks:
    - some_tasks1:
  roles:
     - role1
     - role2
  post_tasks:
     - some_task2:
     - some_task3:

foo を実行する必要があるとしましょう。 そしてそれは次のようになります foo: name=foobar state=present。 これはどこに書けばいいのでしょうか？ プレで？ 役職？ 役割を作成しますか?

...それで、タスクはどこへ行ったのでしょうか?

もう一度基本である再生デバイスから始めます。 この問題に浮いていると、プレーを他のすべての基礎として使用できなくなり、結果は「不安定」になります。

再生デバイス: hosts ディレクティブ、再生自体の設定、および pre_tasks、タスク、ロール、post_tasks セクション。 プレイのための残りのパラメータは、今のところ私たちにとって重要ではありません。

タスクと役割を含むセクションの順序: pre_tasks, roles, tasks, post_tasks。 意味的には実行順序は次のとおりです。 tasks и roles が明確でない場合、ベスト プラクティスによれば、セクションを追加しています tasks、そうでない場合にのみ roles。 ある場合 roles、添付されたすべてのタスクがセクションに配置されます pre_tasks/post_tasks.

残っているのは、すべてが意味的に明確であるということだけです。 pre_tasksそれから rolesそれから post_tasks.

しかし、モジュール呼び出しはどこにあるのか?という質問にはまだ答えていません。 foo 書く？ 各モジュールのロール全体を記述する必要がありますか? それとも全てに厚い役割を持たせた方が良いのでしょうか？ また、役割ではない場合、事前または事後、どこに書けばよいのでしょうか?

これらの質問に対する合理的な答えがない場合、それは直観力の欠如、つまり同じ「不安定な基礎」の兆候です。 それを理解しましょう。 まず、秘密の質問: プレイに問題がある場合 pre_tasks и post_tasks (タスクやロールはありません)、最初のタスクを実行すると何かが壊れる可能性があります。 post_tasks 最後まで移動させていただきます pre_tasks?

もちろん、質問の文言はそれが壊れることを示唆しています。 しかし、正確には何でしょうか？

...ハンドラー。 基本を読むと、すべてのハンドラーが各セクションの後に自動的にフラッシュされるという重要な事実がわかります。 それらの。 からのすべてのタスク pre_tasks、次に通知されたすべてのハンドラー。 その後、すべてのロールと、ロール内で通知されたすべてのハンドラーが実行されます。 後 post_tasks そしてそのハンドラーたち。

したがって、タスクをドラッグすると、 post_tasks в pre_tasks場合、ハンドラーが実行される前にそれを実行する可能性があります。 たとえば、次の場合 pre_tasks Web サーバーがインストールおよび構成されていること、および post_tasks 何かが送信された場合、このタスクをセクションに転送します pre_tasks 「送信」時点ではサーバーはまだ実行されておらず、すべてが壊れるという事実につながります。

もう一度考えてみましょう、なぜ必要なのか pre_tasks и post_tasks? たとえば、役割を実行する前に必要なもの (ハンドラーを含む) をすべて完了するためです。 あ post_tasks これにより、ロール (ハンドラーを含む) の実行結果を操作できるようになります。

洞察力のある Ansible 専門家が、それが何であるかを教えてくれます。 meta: flush_handlers、しかし、プレイ中のセクションの実行順序に依存できるのに、なぜフラッシュハンドラーが必要なのでしょうか? さらに、meta:flush_handlers を使用すると、重複したハンドラーで予期せぬ事態が発生し、使用時に奇妙な警告が表示される可能性があります。 when у block 等Ansible についての知識が深まるほど、「難しい」ソリューションに対してより多くのニュアンスを指定できるようになります。 そして、事前/役割/事後間の自然な分割を使用するという単純な解決策では、ニュアンスが生じることはありません。

そして、「フー」の話に戻りましょう。 どこに置けばいいですか？ 前、後、それとも役割ですか? 明らかに、これは foo のハンドラーの結果が必要かどうかによって決まります。 これらが存在しない場合は、foo を pre または post に配置する必要はありません。これらのセクションには特別な意味があり、コード本体の前後でタスクを実行します。

ここで、「役割またはタスク」という質問に対する答えは、すでに実行されているものに帰着します。そこにタスクがある場合は、それらをタスクに追加する必要があります。 ロールがある場合は、(XNUMX つのタスクからでも) ロールを作成する必要があります。 タスクとロールは同時に使用されないことに注意してください。

Ansible の基本を理解すると、一見好みの問題に適切な答えが得られます。

タスクと役割 (パート XNUMX)

ここで、プレイブックを書き始めたばかりの状況について説明します。 foo、bar、baz を作成する必要があります。 これら XNUMX つのタスクは XNUMX つの役割ですか、それとも XNUMX つの役割ですか? 質問を要約すると、どの時点で役割を書き始める必要がありますか? タスクを書くことができるのに、ロールを書くことに何の意味があるのでしょうか?... ロールとは何ですか?

最大の間違いの XNUMX つは (これについてはすでに話しました)、ロールをプログラムのライブラリ内の関数のようなものと考えることです。 一般的な関数の説明はどのようなものですか? 入力引数を受け入れ、副次的な原因と対話し、副次的な影響を及ぼし、値を返します。

さて、注意してください。 この役割において、これから何ができるでしょうか？ いつでも副作用を呼び出すことができます。これは、副作用を作成するという Ansible 全体の本質です。 副次的な原因がありますか? 初級。 しかし、「値を渡して返す」のでは、それが機能しません。 まず、ロールに値を渡すことはできません。 ロールの vars セクションで、プレイの存続期間サイズを含むグローバル変数を設定できます。 ロール内で有効期間を指定したグローバル変数を設定できます。 あるいは、Playbook の存続期間があっても (set_fact/register）。 ただし、「ローカル変数」を使用することはできません。 「値を取得」して「値を返す」ことはできません。

ここから重要なことがわかります。副作用を引き起こさずに Ansible で何かを書くことはできないということです。 グローバル変数の変更は常に関数の副作用となります。 たとえば、Rust では、グローバル変数を変更することは次のようになります。 unsafe。 Ansible では、これがロールの値に影響を与える唯一の方法です。 使用されている言葉に注意してください。「ロールに値を渡す」ではなく、「ロールが使用する値を変更する」ということです。 役割間に分離はありません。 タスクと役割の間に分離はありません。

合計： 役割は機能ではありません.

役柄の良いところは何ですか？ まず、ロールにはデフォルト値があります(/default/main.yaml)、第 XNUMX に、このロールにはファイルを保存するための追加のディレクトリがあります。

デフォルト値の利点は何ですか? マズローのピラミッド (Ansible のかなり歪んだ変数の優先順位の表) では、ロールのデフォルトの優先順位が最も低くなります (Ansible コマンドライン パラメーターを除く)。 これは、デフォルト値を指定する必要があり、インベントリ変数やグループ変数の値がオーバーライドされることを心配しない場合は、ロールのデフォルトが唯一の適切な場所であることを意味します。 (少し嘘をついていますが、他にもたくさんあります) |d(your_default_here)、ただし、静止した場所について話す場合は、ロールのみがデフォルトになります）。

役柄について他に素晴らしい点は何ですか? 専用のカタログがあるからです。 これらは変数のディレクトリであり、定数 (つまり、ロールに対して計算される) と動的 (パターンまたはアンチパターンのいずれかが存在します) の両方です。 include_vars 一緒に {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml。）。 これらは次のディレクトリです files/, templates/。 また、独自のモジュールとプラグインを持つこともできます (library/）。 ただし、プレイブック内のタスク (これらすべてを含めることもできます) と比較した場合、ここでの唯一の利点は、ファイルが XNUMX つの山ではなく、複数の別々の山にダンプされることです。

もう XNUMX つの詳細: (Galaxy 経由で) 再利用できるロールの作成を試みることができます。 コレクションの出現により、役割の分散はほとんど忘れ去られたと考えられます。

したがって、ロールには XNUMX つの重要な機能があります。XNUMX つはデフォルト (独自の機能) があり、もう XNUMX つはコードを構造化できることです。

元の質問に戻ります。いつタスクを実行し、いつ役割を実行するかです。 プレイブック内のタスクは、ほとんどの場合、ロールの前後の「接着剤」として、または独立した構築要素として使用されます (その場合、コード内にロールは存在しないはずです)。 役割が混在した通常のタスクの山は、明らかにいい加減です。 タスクまたは役割など、特定のスタイルに従う必要があります。 ロールによりエンティティとデフォルトが分離され、タスクによりコードをより速く読み取ることができます。 通常、より「固定的な」(重要かつ複雑な) コードがロールに配置され、補助スクリプトがタスク スタイルで記述されます。

import_role をタスクとして実行することも可能ですが、これを記述する場合は、なぜこれを実行するのかを自分の美意識に基づいて説明できるように準備してください。

洞察力のある読者は、ロールはロールをインポートでき、ロールは galaxy.yml 経由で依存関係を持つことができ、さらにひどいひどい問題も存在する、と言うかもしれません。 include_role — 私たちはフィギュア体操のスキルではなく、基本的な Ansible のスキルを向上させていることを思い出してください。

ハンドラーとタスク

もう XNUMX つの明らかな事柄、ハンドラーについて説明しましょう。 それらを正しく使用する方法を知ることは、ほとんど芸術です。 ハンドラーとドラッグの違いは何ですか?

基本を覚えているので、例を示します。

- hosts: group1
  tasks:
    - foo:
      notify: handler1
  handlers:
     - name: handler1
       bar:

ロールのハンドラーは、rolename/handlers/main.yaml にあります。 ハンドラーはすべてのプレイ参加者間を探索します。pre/post_tasks はロール ハンドラーをプルでき、ロールはプレイからハンドラーをプルできます。 ただし、ハンドラーへの「クロスロール」呼び出しは、単純なハンドラーを繰り返すよりもはるかに厄介な問題を引き起こします。 (ベスト プラクティスのもう XNUMX つの要素は、ハンドラー名を繰り返さないようにすることです)。

主な違いは、タスクが常に (べき等に) 実行されることです (プラス/マイナス タグと when)、およびハンドラー - 状態変更による (通知は、変更された場合にのみ起動されます)。 これはどういう意味ですか？ たとえば、再起動したときに変更がなかった場合、ハンドラーは存在しません。 生成タスクに変更がないのにハンドラーを実行する必要があるのはなぜでしょうか? たとえば、何かが壊れて変更されたが、実行がハンドラーに到達しなかった場合などです。 たとえば、ネットワークが一時的にダウンしたためです。 構成が変更されましたが、サービスは再起動されていません。 次回起動すると、構成は変更されなくなり、サービスは古いバージョンの構成のままになります。

構成に関する状況は解決できません (より正確には、ファイルフラグなどを使用して特別な再起動プロトコルを自分で発明できますが、これはどの形式でも「基本的な Ansible」ではなくなります)。 しかし、もう XNUMX つのよくある話があります。アプリケーションをインストールし、それを記録したということです。 .service-file、そして今それが必要です daemon_reload и state=started。 そして、これが自然に行われるのはハンドラーであると思われます。 ただし、ハンドラーではなく、タスクリストまたはロールの最後にあるタスクにすると、毎回冪等に実行されます。 たとえプレイブックが途中で壊れたとしても。 これは再起動の問題をまったく解決しません (冪等性が失われるため、再起動属性を使用してタスクを実行することはできません) が、state=started を実行する価値は間違いなくあり、プレイブックの全体的な安定性が向上します。 接続数と動的状態が減少します。

ハンドラーのもう XNUMX つの利点は、出力を詰まらせないことです。 変更はありませんでした。出力に余分なスキップや OK はなく、読みやすくなりました。 これはマイナスの特性でもあります。最初の実行時に線形に実行されるタスクでタイプミスを見つけた場合、ハンドラーは変更されたときのみ実行されます。 状況によっては - 非常にまれです。 たとえば、XNUMX年後の人生で初めて。 そしてもちろん、名前にタイプミスがあれば、すべてが壊れてしまいます。 XNUMX 回目に実行しない場合は、何も変わりません。

それとは別に、変数の可用性について話す必要があります。 例えばループでタスクを通知した場合、変数には何が入るでしょうか？ 分析的に推測することはできますが、特に変数が異なる場所から来た場合には、必ずしも自明ではありません。

... つまり、ハンドラーは見た目よりもはるかに役に立たず、はるかに問題が多いのです。 ハンドラーなしで (余分な装飾なしで) 何かを美しく書くことができるのであれば、ハンドラーなしでそれを行う方が良いでしょう。 それがうまくいかなくても、彼らと一緒にやったほうが良いのです。

悪意のある読者は、私たちが議論していないことを正しく指摘しています listenハンドラーは別のハンドラーの通知を呼び出すことができること、ハンドラーには import_tasks (with_items で include_role を実行できる) を含めることができること、Ansible のハンドラー システムはチューリング完全であること、include_role のハンドラーがプレイのハンドラーと興味深い方法で交差すること、など。d。 - これらすべては明らかに「基本」ではありません）。

ただし、実際には覚えておく必要がある特別な機能が XNUMX つあります。 タスクが次のように実行される場合 delegate_to 通知がある場合、対応するハンドラーは何もせずに実行されます。 delegate_to、つまりプレイが割り当てられているホスト上で。 (もちろん、ハンドラーは delegate_to 同じ）。

それとは別に、再利用可能なロールについて少しお話したいと思います。 コレクションが登場する前は、普遍的な役割を作ることができるというアイデアがありました。 ansible-galaxy install そして、行ってきました。 あらゆる状況のあらゆるバリアントのすべての OS で動作します。 したがって、私の意見は、それは機能しません。 質量のあるあらゆる役割 include_vars100500 件のケースをサポートしているが、例外的なバグが多発する運命にあります。 これらは大規模なテストでカバーできますが、他のテストと同様に、入力値のデカルト積と関数全体を用意するか、「個別のシナリオをカバー」するかのどちらかです。 私の意見は、役割が線形 (循環的複雑さ 1) である方がはるかに優れているということです。

if が少なくなるほど (明示的または宣言的 - 形式で) when またはフォーム include_vars 変数のセットによって）、役割がより良くなります。 場合によっては分岐を作成する必要がありますが、繰り返しますが、分岐の数は少ないほど良いのです。 したがって、ギャラクシーでは良い役割のように思えます（うまくいきます！）。 when XNUMX つのタスクからなる「自分自身の」役割よりも好ましくない可能性があります。 galaxy の役割がより優れているのは、何かを書き始めたときです。 状況がさらに悪化するのは、何かが壊れ、それが「銀河との役割」のせいではないかと疑われるときです。 それを開くと、XNUMX つのインクルージョン、XNUMX つのタスク シート、およびスタックが存在します。 when'ov... そして、これを理解する必要があります。 5 つのタスクの代わりに、破るものが何もない直線的なリストです。

以下の部分では

• インベントリー、グループ変数、host_group_vars プラグイン、hostvars について少し説明します。 スパゲッティを使ったゴルディアンノットの結び方。 スコープと優先順位変数、Ansible メモリ モデル。 「では、データベースのユーザー名はどこに保存すればよいのでしょうか?」
• jinja: {{ jinja }} — nosql notype nosense ソフト粘土。 それはどこにでもあり、予想外の場所にもあります。 について少し !!unsafe そして美味しいヤムイム。

出所： habr.com