Ansible を実行して、/usr/bin/ansible-playbook のオーケストレーション言語ではなく /usr/bin/ansible を使用してクイックコマンドを実行することを指します。アドホックコマンドの例には、インフラストラクチャー内での 50 台のマシンを再起動することなどが含まれます。アドホックに実行できるすべてのことは Playbook を作成して実行でき、Playbook は数多くの他の操作を 1 つにまとめることができます。
Ansible からの結果をインターセプトでき、それらについて何らかの処理を行うユーザー作成コードを指します。GitHub プロジェクトで提供されている一部のサンプルの実行内容には、カスタムロギングやメール送信、さらにはサウンド効果の再生などが含まれます。
コントロールグループは「cgroup」とも呼ばれる Linux カーネルの機能で、リソースをグループ化し、特定のプロセスを実行するために割り当てることができるようになります。プロセスへのリソースの割り当てに加えて、cgroup は、cgroup 内で実行されるすべてのプロセスによる実際のリソースの使用量の報告も行います。
--check オプションを指定して Ansible を実行することを指します。このオプションを選択してもリモートシステムに変更は加えられることはなく、コマンドがこのフラグなしに実行された場合に生じる可能性のある変更のみを出力します。これは、他のシステムでのいわゆる「ドライラン」モードに類似しています。ただし、この場合は予期しないコマンドの失敗やカスケード効果が考慮されないことに注意してください (他のシステムの同様のモードについても同じです)。このモードを使用すると、起こり得ることの概要を把握することはできますが、これが適切なステージング環境の代わりになる訳ではありません。
コンテナーグループはインスタンスグループの 1 種で、ジョブが実行される Kubernetes または OpenShift クラスター内での Pod のプロビジョニングに関する設定を指定します。これらの Pod はオンデマンドでプロビジョニングされ、Playbook が実行されている期間のみ存在します。
Tower がマシンに対してジョブを起動したり、インベントリーソースと同期したり、バージョン管理システムからプロジェクトコンテンツをインポートしたりする際に使用される可能性のある認証情報の詳細です。
外部の認証情報タイプ、メタデータフィールド、シークレット管理システムとの対話に必要なコードの定義を含む Python コード
ジョブテンプレート、インベントリー、スライスサイズで構成されるジョブ。実行されると、分散されたジョブは、各インベントリーを複数の「スライスサイズ」のチャンクにスライスし、これらをサイズの小さいジョブスライスの実行に使用します。
シークレット管理システムとの認証に使用する Tower の管理認証情報タイプ
端的に言うと、ファクトはリモートノードについて発見される事柄を指します。ファクトは変数のように Playbook やテンプレートで使用できますが、ファクトは設定される事柄というよりは推測される事柄と言えます。ファクトは、リモートノードで内部セットアップモジュールを実行することでプレイの実行中に自動的に検出されます。セットアップモジュールは明示的に呼び出さなくても実行されますが、実行する必要がない場合は時間を節約するために無効に設定できます。他の設定管理システムから切り替えを行われている場合の利点として、ファクトモジュールは Chef および Puppet のファクトライブラリーである 「ohai」および「facter」ツールから (インストールされている場合) ファクトを取り込みます。
Ansible および Tower は複数のリモートノードと同時に対話でき、並列処理のレベルは、ジョブテンプレートの作成または編集時に --forks を渡すか、または設定ファイルのデフォルトを編集するなどの複数の方法で設定することができます。デフォルトには非常に控え目な 5 つのフォークが設定されますが、多くの RAM がある場合は、並列処理のレベルを上げるために 50 などの値に設定することもできます。
セットとして対応可能な Ansible 内の一連のホストを指します。それらの内の多くが単一インベントリーに存在する場合があります。
group_vars/ ファイルは、各グループに由来するオプションのファイル名で、インベントリーファイルと共にディレクトリーに存在するファイルのことです。このファイルは、とくにデータ構造が複雑な場合などに、所定グループに提供される変数を配置できる便利な場所になります。これにより、これらの変数がインベントリーファイルまたは Playbook に埋め込まれる必要がなくなります。
ハンドラーは Ansible Playbook の通常のタスクのような機能を持ちます(「タスク」を参照) が、タスクに「notify (通知)」指示があり、変更があったことが示唆される場合にのみ実行されます。たとえば、設定ファイルが変更された後に、設定ファイルを参照するテンプレート作成操作のタスクはサービス再起動ハンドラーに通知する可能性があります。これは、サービスが再起動する必要がある場合にのみバウンスできることを意味します。ハンドラーはサービスの再起動以外のタスクに使用できますが、サービスの再起動が最も一般的な使用例になります。
Tower によって管理されるシステムで、物理、仮想、クラウドベースのサーバー、または他のデバイスが含まれる場合があり、通常はオペレーティングシステムインスタンスです。ホストはインベントリーに含まれます。ホストは「ノード」と呼ばれることもあります。
Ansible の各プレイは、(システムのロール、目的または順序を定義する) 一連のタスクをシステムのセットにマップします。各プレイにあるこの「hosts:」指示はホスト指定子と呼ばれることが多くあります。これは 1 つのシステム、数多くのシステム、1 つ以上のグループ、または １つのグループにあるが別のグループには明示的にないとされる一部のホストを選択することができます。
クラスター環境で使用するインスタンスで構成されるグループ。インスタンスグループでは、ポリシーをもとにインスタンスをグループ化できます。
ジョブの起動対象となるホストのコレクションです。
ホスト、ホストのグループメンバーシップおよび変数情報を、SQL データベース、CMDB ソリューションまたは LDAP に類する外部リソースから参照する非常に簡単なプログラム (または複雑なプログラム) のことです。この概念は Puppet (「外部ノード分類子」と呼ばれている) から取られたもので、ほぼ同じ様に機能します。
現在のインベントリーグループにマージする必要のあるクラウドまたは他のスクリプトについての情報のことです。グループ、ホストおよびグループやホストについての変数が自動的に設定されます。
Tower によって起動される数多くのバックグラウンドタスクの 1 つで、通常はジョブテンプレートのインスタンス化、または Ansible Playbook の起動を指します。他のジョブの種類には、インベントリーのインポート、ソースコントロールからのプロジェクトの同期または管理者のクリーンアップ操作が含まれます。
出力および成功/失敗を含む、特定ジョブの実行履歴のことです。
「Distributed Job」を参照してください。
Ansible Playbook とその起動に必要なパラメーターのセットの組み合わせです。
Ansible および Tower はリモートモジュールから返されるデータに JSON を使用します。モジュールは Python だけではなくすべての言語で作成することができます。
認証後に外部システムのシークレットの場所を特定する情報。外部認証情報とターゲットの認証情報フィールドをリンクするときにこの情報を使用します。
名前、説明および定義された設定を持つ通知タイプ (メール、Slack、Webhook など) のことを指します。
通知テンプレートの表示。たとえばジョブが失敗すると、通知テンプレートによって定義された設定を使用して、通知が送信されます。
変更イベントを登録し、ハンドラータスクにプレイの終了時に別の操作の実行が必要であることを知らせるタスクの行為を指します。ハンドラーが複数のタスクによる通知を受けても、ハンドラーは 1 回のみ実行されます。ハンドラーは、それらが通知を受けた順ではなく、一覧表示された順に実行されます。
ユーザー、チーム、プロジェクトおよびインベントリーの論理コレクションです。組織は、Tower のオブジェクト階層で最上位のオブジェクトです。
組織内での新規ユーザーおよびプロジェクトの作成を含む、組織のメンバーシップおよび設定を変更する権利を持つ Tower ユーザーのことを指します。組織管理者は組織内の他のユーザーにパーミッションを付与することもできます。
プロジェクト、インベントリーその他 Tower オブジェクトの読み取り、変更および管理を実行するためにユーザーおよびチームに割り当てられる権限のセットを指します。
Playbook はプレイのリストを指します。最小単位のプレイは、ホスト指定子で選択されるホストのセット (通常はグループで選択されますが、ホスト名 glob で選択されることもある) と、システムが実行するロールを定義するためにホストで実行されるタスク間のマッピングです。Playbook には 1 つまたは数多くのプレイが含まれる場合があります。
Ansible Playbook を指します。詳細は、http://docs.ansible.com/ を参照してください。
ポリシーは、インスタンスグループがどのように動作し、ジョブがどのように実行されるかを規定します。
Tower に表示される Ansible Playbook の論理コレクションです。
ロールは Ansible および Tower における組織単位です。ロールをホストのグループ (またはグループまたはホストパターンのセットなど) に割り当てることは、ホストのグループが特定の動作を実装することを意味します。ロールには特定の変数の値、特定のタスク、特定のハンドラー、またはこれらの 1 つまたは複数を適用することが含まれます。ファイル構造がロールに関連付けられていることから、ロールは再配布可能な単位であり、これを使って Playbook 間または他のユーザーとの間で動作を共有することができます。
トークン、パスワード、証明書、暗号化キー、他の機密データをセキュアに保存して、これらのデータへのアクセスを制御するサーバーまたはサービス
ジョブが自動的に実行される日時のカレンダーのことを指します。
「Distributed Job」を参照してください。
ターゲット認証情報のフィールドにリンクされる外部認証情報
Ansible では root ログインが不要であり、デーモンが不要のため root レベルのデーモンも要求されません(これは機密環境ではセキュリティー上の懸念点となる可能性があります)。Ansible は sudo コマンドでログインでき、このコマンドでラップされた数多くの操作を実行でき、パスワードなしか、またはパスワードを使用する sudo で機能します。通常 sudo で機能しない操作 (scp ファイル転送など) については、sudo モードで実行中の Ansible の copy、template、および fetch モジュールを使用して実行できます。
組織に関連付けられているかを問わず、システムのすべてのオブジェクトを編集するパーミッションを持つ Tower サーバーの管理者のことです。スーパーユーザーは組織および他のスーパーユーザーを作成することができます。
ジョブテンプレート上で設定可能な、ジョブ起動時にジョブテンプレートによって尋ねられる質問のことを指します。
外部認証情報にリンクされている入力フィールドが含まれる外部以外の認証情報
関連付けられたユーザー、プロジェクト、認証情報およびパーミッションを持つ組織の下位区分のことです。チームは、ロールベースのアクセス制御スキームを実装し、組織全体で責任を委任する手段となります。
パーミッションおよび認証情報が関連付けられた Tower オペレーターのことを指します。
Webhook は、アプリ間の通信と情報共有を可能にします。Webhook は、SCM にプッシュされたコミットに応答し、ジョブテンプレートまたはワークフローテンプレートを起動するために使用されます。
単一ユニットとして実行するためにリンクされたジョブテンプレート、プロジェクトの同期、およびインベントリーの同期の任意の組み合わせで構成されるセットのことを指します。
Ansible および Tower は YAML を使用して、Playbook の設定言語および変数ファイルを定義します。YAML には最小限の構文のみが含まれるため、簡単に確認できます。これは設定ファイルとして、また読みやすさの面でも優れたデータ形式ですが、機械による読み取り可能な形式でもあります。YAML は動的言語コミュニティーで比較的よく使用されており、この形式には多くの言語 (Python、Perl、Ruby など) でのシリアライズに利用できるライブラリーが含まれます。