用語集¶

以下は、Ansible ドキュメントの各所で使用される用語の定義 (と再説) 一覧です。

全ドキュメント、および文脈で用語を確認するには、ドキュメントのホームページを参照してください。ここでは、Ansible のコンポーネントの知識を確認し、どのように使用するかを理解するのに適しています。復習のため、または用語がメーリングリストで使用されている時などに確認してください。

アクション

アクションはタスクの一部を指し、実行するモジュールや、そのモジュール渡す引数を指定します。各タスクには、アクションを 1 つのみ指定できますが、他に複数のパラメーターが指定されている可能性があります。

アドホック

/usr/bin/ansible-playbook というオーケストレーション言語ではなく、 Ansible を実行して /usr/bin/ansible を使用してクイックコマンドを実行することを意味します。 Ad hoc コマンドの例として、インフラストラクチャーで 50 台のマシンを再起動するコマンドなどが挙げられます。アドホックは、 playbook を記述することで行うことができます。また、 Playbook を使用して多数の操作を統合することも可能です。

非同期

完了まで待たずに、バックグラウンドで実行するように設定されているタスクを指します。 SSH タイムアウトの時間よりも長いプロセスがある場合に、非同期モードでタスクを実行すると合理的です。非同期モードでは、完了しているかを数秒ほどポーリングするか、「Fire and Forget」に設定して、 Ansible がタスクを再度確認せずに、実行だけして次のステップに進むことができます。非同期モードは、 /usr/bin/ansible および /usr/bin/ansible-playbook の両方で使用できます。

Callback プラグイン

Ansible から結果を傍受してその結果を使用し、作業を実行可能にする、ユーザー記述のコードを指します。 GitHub プロジェクトで提供されている例では、カスタムロギング、メールの送信、サウンドエフェクトの再生などさえも実行できます。

チェックモード

「 –check」オプションを使用して Ansible を実行することを指し、リモートシステムに変更を加えず、コマンドをこのフラグなしで実行した場合に発生する可能性のある変更のみを出力します。これは、他のシステムの「dry run」モードと類似していますが、コマンドが予期せずに失敗した場合や、カスケード効果 ( 他のシステムの同様のモードにも該当) について考慮されない点に注意が必要です。このモードを使用して、何が起こるかを確認できますが、適切なステージ環境の代わりとしては使用できません。

Connection プラグイン

デフォルトでは、Ansible は、プラグ可能なライブラリーを使用してリモートマシンと対話します。 Ansible は、ネイティブの OpenSSH (SSH (Native)) または paramiko と呼ばれる Python の実装を使用します。最新版を使用している場合には、 OpenSSH を使用することが推奨されます。また、OpenSSH を使用すると、Kerberos やジャンプホストなどの機能を利用できるようになります。この内容は、「はじめに」セクションで説明されています。また、 accelerate mode, モードなどの他の接続タイプは、 SSH ベースのいずれかの接続タイプでブートストラップする必要がありますが、非常に高速なローカルモードで、ローカルシステムで機能します。独自の Connection プラグインを記述することも可能です。

条件

条件は、True または False に評価して、指定のタスクを所定のマシンで実行するかどうかを決定する式のことです。 Ansible の条件は、「when」ステートメントで機能します。この内容は、 Playbook の使用で説明されています。

宣言

最終的な状態の達成に必要な手順のシーケンスの説明ではなく、最終的な状態の説明を使用するタスクを実現するアプローチです。実際の例では、タスクの宣言的な仕様は「put me in California」となります。現在の場所によって、カリフォルニアに到着するまでの手順は異なる可能性があり、カリフォルニアにすでにいる場合には、何も作業で行う必要がありません。Ansible のリソースは宣言的で、最終的な状態を実現するのに必要な手順を割り出します。また、最終的な状態に到達するのに必要な手順があるかどうかが分かります。

差分モード

Ansible に「–diff」フラグを渡すと、このフラグをサポートするモジュールでの変更内容を表示できます。--check と組み合わせると、適切な「dry run」が実行されます。ファイルの差分は、通常、統一された diff 形式にまとめられます。

エグゼキューター

/usr/bin/ansible を直接背後で機能し、 playbook の各タスクの呼び出しに対応する Ansible のコアとなるソフトウェアコンポーネント。エグゼキューターは、 Ansible の開発者が使用する用語で、ユーザー側が使用する用語ではありません。

ファクト

ファクトは、単にリモートノードで検出される内容です。ファクトは、変数と同様に、playbooks とテンプレートで使用できますが、ファクトは設定ではなく、推測される内容です。ファクトリモートノードで内部の setup module を実行して、プレイを起動すると Ansible により自動的に検出されます。 Ansible で、設定モジュールを呼び出す必要はありません。実行しますが、必要のない場合には、時間節約のため無効にできます。または、Ansible に対して、gather_subset: オプションを使用して完全なファクトのサブセットのみを収集するように指示できます。別の設定管理システムから簡易的に切り替えられるように、ファクトモジュールは、 ohai ツールおよび facter ツールがインストールされている場合に、そのツールからファクトをプルします。上記のプログラムはそれぞれ、Chef と Puppet からのファクトライブラリーです ( gather_subset: を使用して、無効にすることも可能です)。

Filter プラグイン

Filter プラグインについては、多くの場合理解する必要がありません。このフィルターを使用すると、新しい Jinja2 フィルターを作成できるようになります。そのため多くの場合は、Jinja2 フィルターを熟知するユーザーにのみ有用です。必要な場合には、API docs section で記述方法を確認できます。

フォーク

Ansible はリモートノードと並列して通話します。この並列レベルは、--forks を指定するか、設定ファイルのデフォルトを編集して設定できます。デフォルトはフォーク 5 個と非常に少なめですが、メモリーが多くある場合は、この値を簡単に 50 などに設定して、並列処理機能を増やすことができます。

ファクトの収集 (ブール値)

ファクトについては上記で説明しています。マルチプレイの playbook を実行するとき、これらの値をいずれも利用する必要がない場合は、ファクト計算に影響を受けないいくつかのプレイがあることが望ましい場合があります。 Playbook を gather_facts: False に設定すると、この暗黙のファクト収集をスキップできます。

グラッビング (Globbing)

グラッビングは、具体的にホストの名前やホストが属しているグループの名前ではなく、ワイルドカードに基づいて多数のホストを選択する方法です。たとえば、ww* を選択して、 www から始まるすべてのホストに一致させることができます。この概念は、 Michael DeHaan (Ansible 創立者) が作成したプロジェクトの 1 つである Func から直接引用されました。基本的なグラッビングに加え、「hosts in this group and not in another group」などのさまざまなセット操作があります。

グループ

グループは、プールに割り当てられた複数のホストで構成されます。これらのホストは、一緒に対象を絞ることができ、それらが共通して共有する特定の変数です。

グループ変数

group_vars/ ファイルは、インベントリーファイルと一緒にディレクトリーに存在するファイルで、オプションのファイル名が、各グループにちなんで名付けられています。これは、特定のグループに提供される変数、特に複雑なデータ構造を配置するのに便利な場所です。そのため、この変数を inventory ファイル、または playbook に埋め込む必要はありません。

ハンドラー

ハンドラーは、 Ansible playbook の通常のタスクのような機能を持ちます (Tasks を参照) が、タスクに notify (通知) ディレクティブが含まれ、変更があったことが示唆される場合にのみ実行されます。たとえば、設定ファイルが変更された後に、その設定ファイルのテンプレート操作を参照するタスクは、サービス再起動ハンドラーに通知する場合があります。これは、サービスを再起動する必要がある場合にのみバウンスできることを示しています。ハンドラーはサービスの再起動以外のタスクにも使用できますが、サービスの再起動が最も一般的な使用例になります。

ホスト

ホストは、Ansible が管理するリモートマシンです。個々の変数を割り当てることができ、グループに編成することもできます。すべてのホストには、到達可能な名前 (IP アドレスまたはドメイン名のいずれか) があり、デフォルトの SSH ポートでアクセスしない場合は、オプションでポート番号があります。

ホスト指定子

Ansible の各 Play は、一連の task (システムのロール、目的、または順序を定義する) を、システムセットに設定します。

各プレイの hosts: ディレクティブは、しばしばホスト指定子と呼ばれます。

1 つのシステム、複数のシステム、または 1 つ以上のグループを選択できます。さらには、あるグループに属し、別のグループには明示的に存在しないホストを選択することもできます。

ホスト変数

Group Vars と同様、 host_vars/ という名前のインベントリーファイルの横にあるディレクトリーには、 YAML 形式のインベントリーファイルの各ホスト名にちなんで名付けられたファイルを含めることができます。これにより、変数を inventory ファイルに埋め込むことなく、ホストに変数を割り当てる便利な場所を提供します。インベントリーファイルでは表現できない複雑なデータ構造を定義する際にも使用できます。

冪等性

操作を 1 回実行した結果が、何も介入せずに繰り返し実行した結果とまったく同じであれば、操作は冪等です。

インクルード (Include)

(プレイにすぎない) Playbook ファイルの概念は、他のプレイ一覧を含める (include) ことができます。また、タスク一覧は、tasks のリストを他のファイルに具体化し、同様にハンドラーを具体化できます。インクルードはパラメーター化できます。つまり、読み込まれたファイルは変数を渡すことができます。たとえば、 WordPress ブログを設定するためのインクルードプレイは、 user と呼ばれるパラメーターを受け取ることができ、そのプレイを複数回インクルードして、alice と bob の両方のブログを作成できます。

インベントリー

Ansible の Hosts および Groups を説明するファイル (デフォルトでは Ansible は簡単な INI 形式を使用)。インベントリーは、インベントリースクリプト (「外部インベントリースクリプト」と呼ばれることもあります) からも提供できます。

インベントリースクリプト

hosts、ホストの group メンバーシップおよび変数情報を、 SQL データベース、 CMDB ソリューション、または LDAP に類する外部リソースから参照する非常に簡単なプログラム (または複雑なプログラム) のことです。この概念は、 Puppet (「外部ノード分類子」と呼ばれています) から取られたもので、ほぼ同じ様に機能します。

Jinja2

Jinja2 は、 Ansible のテンプレートモジュールで推奨されるテンプレート言語です。これは非常にシンプルな Python テンプレート言語であり、一般的に読みやすく、簡単に記述できます。

JSON

Ansible は、JSON を使用してリモートモジュールからデータを返します。これにより、 Python だけでなく、任意の言語でモジュールを作成できます。

遅延評価

通常、Ansible は、できるだけ遅いタイミングで、 playbook 内の変数をすべて評価します。つまり、データ構造を定義すると、データ構造自体が変数値を定義でき、すべてが期待どおりに「機能するだけ」です。これは、変数文字列が、その文字列内に他の変数を含むことができることも意味します。

ライブラリー

/usr/bin/ansible、または Ansible playbook で利用できるモジュールのコレクション

グループの制限

--limit somegroup を ansible または ansible-playbook に渡すことで、コマンドは、hosts のサブセットに制限できます。たとえば、これは通常、サーバーのセット全体を 1つの特定のサーバーに向ける playbook を実行するために使用できます。

ローカルアクション

リモートマシンを対象とした playbook の local_action ディレクティブは、指定したステップが実際にローカルマシン上で発生することを意味しますが、そのステップで参照されるリモートホスト名を参照するために変数 {{ansible_hosutoname}} を渡すことができることを意味します。これは、たとえば、rsync 操作を発生させるために使用できます。

ローカル接続

playbook <playbooks> で connection: local を使用したり、/usr/bin/ansible に -c local を渡すことで、リモートマシンではなくローカルホストを管理していることを示しています。

lookup プラグイン

lookup プラグインとは、外部から Ansible にデータを取り込む方法です。lookup プラグインは Jinja2 の拡張機能であり、テンプレート内 ({{ lookup('file','/path/to/file') }} など) でアクセスできます。これらは、with_items のようなものが実装されています。また、ファイルからデータを読み込む``file`` などの lookup プラグインや、環境変数、DNS テキストレコード、キー値ストアなどを問い合わせるための lookup プラグインもあります。

ループ

通常、Ansible はプログラミング言語ではありません。loop のようなさまざまな構成要素により、リスト内の複数の項目に対して特定のタスクを繰り返すことができますが、より宣言的であることが望まれます。 yum、apt などの特定のモジュールは、実際にリストを直接取得し、そのリストで指定されているパッケージをすべて、1 つのトランザクションでインストールできます。このため、構成が終了するまでの合計時間が大幅に短縮されるため、ループなしで使用できます。

モジュール

モジュールは、 nsible がリモートマシンに送信する作業の単位です。モジュールは、 /usr/bin/ansible または /usr/bin/ansible-playbook ( 複数のタスクを組み合わせて多数の異なるモジュールを使用する場所) で開始します。モジュールは、Perl、Bash、Ruby などの任意の言語で実装できますが、 Pythonで作成すると、いくつかの有用な共有ライブラリコードを利用できます。モジュールは、JSON を返すだけです。モジュールがリモートマシンで実行すると削除されるため、長時間実行されているデーモンは使用されません。 Ansible は、利用可能なモジュールのコレクションを library と呼びます。

多層

IT システムは一度に 1 つのシステムではなく、複数のシステム間とシステムのグループ間の相互作用によって、明確に定義された順序で管理されるという概念です。たとえば、データベースサーバーの前に Web サーバーを更新する必要があり、そのデータベースサーバーとさまざまなロードバランサーおよび監視サーバーに接続する必要がある場合は、 Web サーバー上の一部を更新する必要があります。 Ansible は、「一度に1つのシステム」の観点から構成を見るのではなく、 IT トポロジー全体とワークフロー全体をモデル化します。

通知

変更イベントを登録し、プレイの最後に別のアクションを実行する必要があることを、 handler タスクに通知するタスクの動作。ハンドラーが複数のタスクにより通知されても、実行するのは一度だけです。ハンドラーは、通知された順番ではなく、リストされている順序で実行されます。

オーケストレーション

多くのソフトウェア自動化システムは、この単語を別の意味で使用しています。 Ansible は、この単語を、指揮者がオーケストラを指揮するものとして使用します。データセンターまたはクラウドアーキテクチャーには、 Web サーバー、データベースサーバー、さらにはロードバランサー、監視システム、継続的インテグレーションシステムなど、さまざまな役割を果たすシステムが多数あります。プロセスを実行する場合は、しばしばローリングアップデートをシミュレートしたり、ソフトウェアを正しくデプロイするために、特定の順序でシステムを操作する必要があります。システムによっては、いくつかのステップを実行し、その他を実行してから、すでに処理された以前のシステムで、追加の手順が必要になる場合があります。電子メールの送信や、Web サービスへの問い合わせが必要になる場合もあります。 nsible オーケストレーションとは、そのようなプロセスをモデル化することです。

Paramiko

デフォルトでは、Ansible は SSH 経由でマシンを管理します。 Ansible がデフォルトでこれを行うために使用するライブラリーは、 paramiko と呼ばれる Python 駆動のライブラリーです。 Paramiko ライブラリは一般的に高速で管理が簡単ですが、 Kerberos またはジャンプホストを使用する場合は、 playbooks に接続タイプを指定するか、-c ssh フラグを指定して、OpenSSH などの SSH バイナリーを切り替えます。

Playbook

Playbook は、Ansible がシステムのオーケストレーション、設定、管理、またはデプロイするための言語です。これが Playbook と呼ばれるのは、ある種スポーツに似ており、それを使用することで楽しめるはずだからです。したがって、ワークブックではありません。

プレイ

Playbook は、プレイの一覧を指します。最小単位のプレイは、ホスト指定子で選択されるホストのセット ( 通常はグループで選択されますが、ホスト名 globs で選択されることもある) と、システムが実行するロールを定義するためにホストで実行されるタスクとの間のマッピングです。Playbook には、 1 つまたは多数のプレイを追加できます。

プルモード

デフォルトでは、Ansible はプッシュモードで実行されます。これにより、各システムと通信するタイミングを非常にきめ細かく制御できます。プルモードは、特定のスケジュールで N 分ごとにノードをチェックインする場合に提供されます。 ansible-pull と呼ばれるプログラムを使用し、プッシュモードの Playbook を使用して設定 (または再構成)することもできます。ほとんどの場合はプッシュモードを使用しますが、多様性と選択のしやすさのために、プルモードが含まれています。

ansible-pull は、 crontab で git から構成の順序を確認し、 local connection プラグインを使用してマシンをローカルで管理することで機能します。

プッシュモード

プッシュモードは Ansible のデフォルトモードです。実際には、これは実際のモードではありません。何も考えていないのに Ansible が動くとはまさにこのことです。プッシュモードを使用すると、Ansible を細かく設定し、ノードがチェックインするのを待たずに、複雑なオーケストレーションプロセスを実行できます。

登録変数

Ansibleですべてのタスクを実行した結果は、テンプレートまたは条件ステートメントで使用する変数に保存できます。変数を定義するために使用されるキーワードは register と呼ばれ、アセンブリープログラミングにおけるレジスターの概念からその名前を取っています (ただし、 Ansible は、アセンブリープログラミングのように感じることはありません)。登録に使用できる変数名は無限にあります。

リソースモデル

Ansible モジュールはリソースの観点から機能します。たとえば、 file モジュールは、特定のファイルを選択し、そのリソースの属性が特定のモデルと一致することを保証します。たとえば、 /etc/motd の所有者が root に設定されていない場合は root に変更し、モードが 0644 に設定されていない場合は 0644 に設定します。リソースモデルは、冪等であり、変更コマンドは、必要でない限り実行されません。 Ansible は、実際の状態に関係なく、システムを目的の状態に戻します。状態を取得する方法を指示する必要はありません。

ロール

ロールは、Ansible の組織のユニットです。ロールを、ホスト (もしくはグループ、ホストパターンなどのセット) に割り当てると、特定の動作を実装する必要があることを示します。ロールには、特定の変数値、特定のタスク、および特定のハンドラー、またはこれらの 1 つ以上を適用することを含むことができます。ロールはファイル構造に関連付けられているため、ロールは再配布可能な単位になり、 Playbooks 間で、または別のユーザーとも動作を共有できます。

ローリングアップデート

グループ N 内の多数のノードを一度にアドレス指定して、すべてのノードを一度に更新してシステムをオフラインにすることを回避する行為。たとえば、非常に大きなボリュームを処理する 500 ノードの Web トポロジーでは、一度に 10 台または 20 台のマシンを更新し、完了したら次の 10 台または 20 台に移行するのが妥当です。 Ansible の playbooks の serial: キーワードは、ローリングアップデートプールのサイズを制御します。デフォルトでは、バッチサイズを一度に処理するため、オプトインする必要があります。 OS 構成 (構成ファイルが正しいことの確認など) では、通常、ローリングアップデートモデルを使用する必要はありませんが、必要に応じて使用できます。

シリアル