自動化実行の使用

手順

1. サービスアカウントの認証情報を入力して、プロファイルに関連付けられているサブスクリプションを確認します。

   1. サブスクリプションを見つけるには、Service Account というタブをクリックします。
   2. Client ID フィールドに、サービスアカウントの作成時に受け取ったクライアント ID を入力します。
   3. Client secret フィールドに、サービスアカウントの作成時に受け取ったクライアントシークレットを入力します。サブスクリプションが、Subscription というラベルの付いたリストメニューに表示されます。サブスクリプションを選択します。
2. サブスクリプションを追加したら、Next をクリックします。
3. End User License Agreement に同意することを示すボックスをチェックします。
4. 情報を確認して、Finish をクリックします。

1. name:localhost この例では、name 属性で文字列 localhost を検索します。この文字列が Fields または Related Fields の内容と一致しない場合は、検索全体が文字列として扱われます。
2. Organization.name:Default この例は、関連フィールドの検索を示しています。organization.name のピリオドは、モデルとフィールドを区切ります。検索の深さまたは複雑さに応じて、クエリーの対象部分に複数のピリオドを含めることができます。

3. foobar これは、単純な文字列 (キーワード) 検索で、名前および説明フィールドに対して icontains 検索を使用して検索用語のすべてのケースを検出します。foo bar のように用語の間にスペースを使用すると、両方の用語を含む結果が返されます。"foo bar" のように用語が引用符で囲まれている場合、Automation Controller は、これらの用語が一緒に出現する文字列を検索します。

   固有名の検索は、API 名に対して検索を行います。たとえば、ユーザーインターフェイスの Management job は、API の system_job と同じです。

4. Organization:Default この例は、関連フィールドの検索を示していますが、組織に関連するフィールドは指定されていません。これは API でサポートされており、単純な文字列検索に似ていますが、組織に対して実行されます (icontains は名前と説明の両方に対する検索が含まれます)。

手順

1. ナビゲーションパネルから、Automation Execution → Jobs または Automation Execution → Templates を選択します。
2. ページ見出しの下、Domains の横にトピック関連のラベルのリストがあります。ラベルを選択してジョブとジョブテンプレートをフィルタリングし、ラベルに関連するコンテンツのみを表示します。複数のラベルを選択できます。
3. 選択をクリアするには、X をクリックします。
4. ドメインオプションをカスタマイズするには、 アイコンを選択します。表示されるモーダルで、Add Domain を選択して、フィルタリングに使用する新しいドメインを追加します。

手順

1. ナビゲーションパネルから、Automation Execution → Templates を選択します。
2. Automation Templates ページで、Create template リストから Create job template を選択します。

3. 次のフィールドに適切な詳細を入力します。

   注記

   フィールドで Prompt on launch を表示するチェックボックスがオンになっている場合、ジョブを起動すると、起動時にそのフィールドの値の入力を求めるプロンプトが表示されます。

   ほとんどのプロンプト値は、ジョブテンプレートに設定されている値をオーバーライドします。

   次の表に例外を示します。

   Expand

   フィールド	オプション	Prompt on Launch
   Name	ジョブの名前を入力します。	該当なし
   Description	必要に応じて、任意の説明を入力します (オプション)。	該当なし
   Job type	ジョブタイプを選択します。 Run: 起動時に Playbook を開始し、選択したホストで Ansible タスクを実行します。 Check: Playbook の「ドライラン」を実行します。実際に変更を加えずに、変更内容を報告します。チェックモードをサポートしていないタスクは無視され、変更予定の内容は報告されません。 ジョブタイプの詳細は、Ansible ドキュメントの Playbooks セクションを参照してください。	はい
   Inventory	ログインしているユーザーが使用できるインベントリーから、このジョブテンプレートで使用するインベントリーを選択します。 システム管理者は、ジョブテンプレート内の特定のインベントリーを使用できるように、ユーザーまたはチームのパーミッションを割り当てる必要があります。	必須です。 インベントリーのプロンプトは、後続のプロンプトウィンドウに独自のステップとして表示されます。
   Project	ログインしているユーザーが利用できるプロジェクトから、このジョブテンプレートで使用するプロジェクトを選択します。	該当なし
   Source control branch	このフィールドは、ブランチのオーバーライドを許可するプロジェクトを選択した場合にのみ表示されます。ジョブの実行で使用するオーバーライドブランチを指定します。空白のままにすると、プロジェクトから指定された SCM ブランチ (またはコミットハッシュまたはタグ) が使用されます。 詳細は、ジョブブランチのオーバーライド を参照してください。	はい
   Playbook	使用可能な Playbook から、このジョブテンプレートで起動する Playbook を選択します。このフィールドには、選択したプロジェクトのプロジェクトベースパスにある Playbook の名前が自動的に入力されます。あるいは、Playbook がリストされていない場合は、その Playbook での実行に使用するファイル (foo.yml など) の名前など、Playbook の名前を入力することもできます。無効なファイル名を入力すると、テンプレートにエラーが表示されるか、ジョブが失敗します。	該当なし
   Execution Environment	このジョブの実行に使用するコンテナーイメージを選択します。実行環境を選択する前にプロジェクトを選択する必要があります。	必須です。 実行環境のプロンプトは、後続のプロンプトウィンドウに独自のステップとして表示されます。
   Credentials	アイコンを選択すると、別のウィンドウが開きます。 利用可能なオプションから、このジョブテンプレートで使用する認証情報を選択します。 リストが膨大な場合は、ドロップダウンメニューリストを使用して認証情報タイプでフィルタリングします。一部の認証情報タイプは、特定のジョブテンプレートに適用されないため、リストされていません。	選択した場合、デフォルトの認証情報が含まれるジョブテンプレートが起動したときに、別の認証情報を指定すると、デフォルトの認証情報が置き換えられます (認証情報が同じタイプの場合)。以下はこのメッセージの例です。 Job Template default credentials must be replaced with one of the same type.Please select a credential for the following types in order to proceed: Machine. 必要に応じて、さらに認証情報を追加できます。 認証情報のプロンプトは、後続のプロンプトウィンドウに独自のステップとして表示されます。
   Labels	必要に応じて、このジョブテンプレートを説明するラベル (dev や test など) を指定します。 ラベルを使用して、表示内のジョブテンプレートと完了したジョブをグループ化およびフィルタリングします。 ラベルはジョブテンプレートの追加時に作成されます。ラベルは、ジョブテンプレートで指定されたプロジェクトを使用して、単一の組織に関連付けられます。組織のメンバーは、編集パーミッション (管理者ロールなど) を持っている場合、ジョブテンプレートにラベルを作成できます。 ジョブテンプレートを保存すると、Expanded ビューの Job Templates の概要にラベルが表示されます。 ラベルの横にある を選択して削除します。ラベルが削除されると、そのラベルはその特定のジョブまたはジョブテンプレートとの関連付けが解除されますが、ラベルを参照する他のジョブには関連付けられたままになります。 ジョブは、起動時にジョブテンプレートからラベルを継承します。ジョブテンプレートからラベルを削除すると、ジョブからも削除されます。	選択すると、デフォルト値が指定されている場合でも、必要に応じて起動時に追加のラベルを指定するようにプロンプトが表示されます。 既存のラベルを削除することはできません。 を選択しても、新しく追加されたラベルだけが削除され、既存のデフォルトのラベルは削除されません。
   Forks	Playbook の実行中に使用する並列または同時プロセスの数です。値 0 は、/etc/ansible/ansible.cfg でオーバーライドされない限り、Ansible のデフォルト設定 (5 つの並列プロセス) を使用します。	はい
   Limit	Playbook が管理または影響を与えるホストのリストをさらに制限するためのホストのパターンを指定します。複数のパターンをコロン (:) で区切ることができます。コア Ansible と同じです。 a:b は「a または b のグループに含まれる」という意味です。 a:b:&c は、「a または b に含まれるが、c には必ず含まれなければならない」という意味です。 a:!b は「a にはあるが、b には絶対にない」という意味です。 詳細は、Ansible ドキュメントの Patterns: targeting hosts and groups を参照してください。	はい 選択されていない場合、ジョブテンプレートがインベントリー内のすべてのノードに対して実行されるか、または Limit フィールドで事前定義されたノードに対してのみ実行されます。ワークフローの一部として実行する場合は、代わりにワークフロージョブテンプレートの制限が使用されます。
   Verbosity	Playbook の実行時に Ansible が生成する出力レベルを制御します。Normal やさまざまな Verbose または Debug 設定から詳細度を選択します。これは details レポートビューにのみ表示されます。詳細ログには、すべてのコマンドの出力が含まれます。デバッグログは非常に詳細で、一部のサポート事例に役立つ SSH 操作に関する情報が含まれています。 詳細の値が 5 の場合、Automation Controller はジョブの実行時にブロックを実行し、これによりジョブが終了したことを示すレポートが遅延するため (レポートが作成されている場合でも)、ブラウザータブがロックアップする可能性があります。	はい
   Job slicing	このジョブテンプレートを実行するスライスの数を指定します。各スライスは、インベントリーの一部に対して同じタスクを実行します。ジョブスライスの詳細は、ジョブスライス を参照してください。	はい
   Timeout	ジョブがキャンセルされるまでの実行時間 (秒単位) を指定できます。タイムアウト値を設定するには、次の点を考慮してください。 設定にはグローバルタイムアウトが定義されており、デフォルトは 0 で、タイムアウトがないことを示します。 ジョブテンプレートの負のタイムアウト (<0) は、ジョブの "タイムアウト" はありません。 ジョブテンプレートのタイムアウトが 0 の場合、ジョブはデフォルトでグローバルタイムアウトになります (デフォルトではタイムアウトなし)。 正のタイムアウトは、そのジョブテンプレートのタイムアウトを設定します。	はい
   Show changes	Ansible タスクによって加えられた変更を確認できます。	はい
   Instance groups	このジョブテンプレートに関連付ける インスタンスおよびコンテナーグループ を選択します。リストが膨大な場合は、 アイコンを使用してオプションを絞り込みます。ジョブテンプレートのインスタンスグループは、ジョブのスケジュール基準に影響します。ルールは、ジョブランタイムの動作 および ジョブ実行場所の制御 を参照してください。システム管理者は、ジョブテンプレート内のインスタンスグループを使用できるように、ユーザーまたはチームのパーミッションを割り当てる必要があります。コンテナーグループを使用するには管理者権限が必要です。	必須です。 選択すると、ジョブの優先インスタンスグループが優先順に提供されます。最初のグループの容量が不足している場合は、容量のあるグループが見つかるまでリスト内の後続のグループが検討され、見つかった時点でそのグループが選択されてジョブが実行されます。 インスタンスグループの入力を求めるプロンプトが表示された場合は、入力した内容が通常のインスタンスグループ階層を置き換え、組織とインベントリーのすべてのインスタンスグループをオーバーライドします。 インスタンスグループのプロンプトは、後続のプロンプトウィンドウに独自のステップとして表示されます。
   Job tags	Create メニューを入力して選択し、Playbook のどの部分を実行するかを指定します。詳細と例は、Ansible ドキュメントの Tags を参照してください。	はい
   Skip tags	Create メニューを入力して選択し、スキップする Playbook の特定のタスクまたは部分を指定します。詳細と例は、Ansible ドキュメントの Tags を参照してください。	はい
   Extra variables	追加のコマンドライン変数を Playbook に渡します。これは、ansible-playbook の "-e" または "-extra-vars" コマンドラインパラメーターです。このパラメーターは、Ansible ドキュメントの Defining variables at runtime で説明されています。 YAML または JSON を使用してキーまたは値のペアを提供します。これらの変数には優先順位の最大値があり、他の場所で指定された他の変数をオーバーライドします。git_branch: production release_version: 1.5 は、値の例です。	必須です。 スケジュールで extra_vars を指定できるようにするには、ジョブテンプレートの変数に対して Prompt on launch を選択するか、ジョブテンプレートで Survey を有効にする必要があります。回答された Survey の質問は extra_vars になります。

   Show more

4. 必要に応じて、このテンプレートを起動するための次のオプションを設定できます。

   • Privilege escalation: オンにすると、この Playbook を管理者として実行できるようになります。これは、--become オプションを ansible-playbook コマンドに渡すことと同じです。
   • Provisioning callback: オンにすると、ホストが REST API 経由で Automation Controller にコールバックし、このジョブテンプレートからジョブを起動できるようになります。詳細は、プロビジョニングコールバック を参照してください。

   • Enable webhook: オンにすると、ジョブテンプレートの起動に使用される事前定義された SCM システム Web サービスとのインターフェイス機能が有効になります。GitHub と GitLab がサポートされている SCM システムです。

     • Webhook を有効にすると、他のフィールドが表示され、以下の追加情報の入力を求められます。
     • Webhook service: Webhook からリッスンするサービスを選択します。
     • Webhook URL: POST 要求を送信する Webhook サービスの URL が自動的に入力されます。
     • Webhook key: Webhook サービスが Automation Controller に送信するペイロードに署名する際に使用するための、生成された共有シークレット。Automation Controller がこのサービスから Webhook を受け入れるようにするには、Webhook サービスの設定で指定する必要があります。

     • Webhook credential: オプションで、Webhook サービスにステータス更新を送信するために使用する認証情報として、GitHub または GitLab の Personal Access Token (PAT) を指定します。

       選択する前に、認証情報が存在している必要があります。

       認証情報を作成するには、認証情報タイプ を参照してください。

     • Webhook の設定の関連情報は、Webhook の使用 を参照してください。
   • Concurrent jobs: オンにすると、キュー内のジョブが相互に依存していない場合に同時に実行されるようになります。ジョブスライスを同時に実行する場合は、このボックスをオンにします。詳細は、Automation Controller の容量決定とジョブへの影響 を参照してください。
   • Enable fact storage: オンにすると、ジョブの実行に関連するインベントリー内のすべてのホストについて収集されたファクトを Automation Controller が保存します。
   • Prevent instance group fallback: このオプションをオンにすると、Instance Groups フィールドにリストされているインスタンスグループのみがジョブを実行できます。オフの場合、ジョブの実行場所の制御 で説明されている階層に基づいて、実行プール内の使用可能なすべてのインスタンスが使用されます。
5. ジョブテンプレートの詳細の設定が完了したら、Create job template をクリックします。

1. ナビゲーションパネルから、Automation Execution → Templates を選択します。
2. 新しく作成したテンプレートが Templates ページに表示されることを確認します。

手順

1. ナビゲーションパネルから、Automation Execution → Templates を選択します。
2. テンプレートを選択し、Team Access または User Access タブで Add roles をクリックします。

3. Teams または Users を選択し、Next をクリックします。

   • リストから 1 つまたは複数のユーザーを選択します。これには、メンバーとして追加するユーザーの隣にあるチェックボックスをクリックして、Next をクリックします。
4. ユーザーまたはチームに割り当てるロールを選択します。ロールの完全なリストを確認するには、必ず下にスクロールしてください。各リソースには、使用可能なさまざまなオプションがあります。
5. Finish をクリックして、選択したユーザーまたはチームにロールを適用し、メンバーとして追加します。

手順

1. 次の方法を使用してジョブテンプレートを削除します。

   • ⋮ アイコンをクリックして、Delete Template を選択します。
   • または、必要なジョブテンプレートを選択します。Details ページで ⋮ アイコンをクリックし、 Delete template を選択します。

手順

1. ナビゲーションパネルから、Automation Execution → Templates を選択します。

2. 複製するテンプレートに関連する {MoreActionIcon} アイコンをクリックし、 Duplicate Template アイコンを選択します。

   • 複製元のテンプレートの名前とタイムスタンプが付いた新しいテンプレートがテンプレートのリストに表示されます。
3. クリックして新しいテンプレートを開き、Edit template をクリックします。
4. Name フィールドの内容を新しい名前に置き換え、他のフィールドのエントリーを入力または変更して、このページを完成させます。
5. Save job template をクリックします。

手順

1. ナビゲーションパネルから、Automation Execution → Templates を選択します。
2. Automation Templates ページで、Create template リストから Create workflow job template を選択します。

3. 次のフィールドに適切な詳細を入力します。

   注記

   フィールドで Prompt on launch チェックボックスがオンになっている場合、ワークフローテンプレートを起動するか、別のワークフローテンプレート内でワークフローテンプレートを使用すると、そのフィールドの値の入力を求めるプロンプトが表示されます。ほとんどのプロンプト値は、ジョブテンプレートに設定されている値をオーバーライドします。次の表に例外を示します。

   Expand

   フィールド	オプション	Prompt on Launch
   Name	ジョブの名前を入力します。	該当なし
   Description	必要に応じて、任意の説明を入力します (オプション)。	該当なし
   Organization	ログインしているユーザーが使用できる組織から、このテンプレートで使用する組織を選択します。	該当なし
   Inventory	必要に応じて、ログインしたユーザーが使用できるインベントリーから、このテンプレートで使用するインベントリーを選択します。	はい
   Limit	Playbook が管理または影響を与えるホストのリストをさらに制限するためのホストのパターンを指定します。複数のパターンをコロン (:) で区切ることができます。コア Ansible と同じです。 a:b は「a または b のグループに含まれる」という意味です。 a:b:&c は、「a または b に含まれるが、c には必ず含まれなければならない」という意味です。 a:!b は「a にはあるが、b には絶対にない」という意味です。 詳細は、Ansible ドキュメントの Patterns: targeting hosts and groups を参照してください。	はい 選択すると、デフォルト値が指定されている場合でも、起動時に制限を選択するように求めます。
   Source control branch	ワークフローのブランチを選択します。このブランチは、ブランチを要求するすべてのワークフロージョブテンプレートノードに適用されます。	はい
   Labels	必要に応じて、このワークフロージョブテンプレートを説明するラベル (dev や test など) を指定します。ラベルを使用して、表示内のワークフロージョブテンプレートと完了したジョブをグループ化およびフィルタリングします。 ラベルは、ワークフローテンプレートの追加時に作成されます。ラベルは、ワークフローテンプレートで提供されるプロジェクトを使用して、単一の組織に関連付けられます。組織のメンバーは、編集パーミッション (管理者ロールなど) を持っている場合、ジョブテンプレートにラベルを作成できます。 ジョブテンプレートを保存すると、ワークフロージョブテンプレートの Details ビューにラベルが表示されます。 ラベルはワークフローテンプレートにのみ適用され、ワークフローで使用されるジョブテンプレートノードには適用されません。 ラベルの横にある を選択して削除します。ラベルが削除されると、そのラベルはその特定のジョブまたはジョブテンプレートとの関連付けが解除されますが、ラベルを参照する他のジョブには関連付けられたままになります。	はい 選択すると、デフォルト値が指定されている場合でも、必要に応じて起動時に追加のラベルを指定するように求められます。- 既存のラベルは削除できません。 を選択すると、新たに追加されたラベルだけが削除され、既存のデフォルトラベルは削除されません。
   Job tags	Create ドロップダウンを入力して選択し、Playbook のどの部分を実行するかを指定します。詳細と例は、Ansible ドキュメントの Tags を参照してください。	はい
   Skip tags	Create ドロップダウンを入力して選択し、スキップする Playbook の特定のタスクまたは部分を指定します。詳細と例は、Ansible ドキュメントの Tags を参照してください。	はい
   Extra variables	追加のコマンドライン変数を Playbook に渡します。 これは、Ansible ドキュメントの Controlling how Ansible behaves: precedence rules に記載されている ansible-playbook の "-e" または "-extra-vars" コマンドラインパラメーターです。- YAML または JSON を使用してキーまたは値のペアを指定します。これらの変数には優先順位の最大値があり、他の場所で指定された他の変数をオーバーライドします。git_branch: production release_version: 1.5 は、値の例です。	はい スケジュールで extra_vars を指定できるようにするには、ワークフロージョブテンプレートで Extra variables の Prompt on launch を選択するか、ジョブテンプレートで Survey を有効にする必要があります。回答された Survey の質問は extra_vars になります。追加変数の詳細は、追加変数 を参照してください。

   Show more

4. 必要に応じて、このテンプレートを起動するための次の Options を指定します。

   • ワークフロージョブテンプレートの起動に使用する定義済みの SCM システム Web サービスと接続する機能をオンにするには、Enable webhook をオンにします。GitHub と GitLab がサポートされている SCM システムです。

     • Webhook を有効にすると、他のフィールドが表示され、以下の追加情報の入力を求められます。

       • Webhook service: Webhook からリッスンするサービスを選択します。
       • Webhook URL: POST 要求を送信する Webhook サービスの URL が自動的に入力されます。
       • Webhook key: Webhook サービスが Automation Controller に送信するペイロードに署名する際に使用するための、生成された共有シークレット。このサービスからの Webhook が Automation Controller で受け入れられるように、Webhook サービスの設定で指定する必要があります。Webhook の設定の関連情報は、Webhook の使用 を参照してください。
   • このワークフローの同時実行を許可するには、Enable concurrent Jobs をオンにします。詳細は、Automation Controller の容量決定とジョブへの影響 を参照してください。
5. ワークフローテンプレートの設定が完了したら、Create workflow job template をクリックします。

手順

1. ナビゲーションパネルから、Automation Execution → Templates を選択します。

2. 複製するテンプレートに関連する アイコンをクリックし、 Duplicate template アイコンを選択します。

   • 複製元のテンプレートの名前とタイムスタンプが付いた新しいテンプレートがテンプレートのリストに表示されます。
3. クリックして新しいテンプレートを開き、Edit template をクリックします。
4. Name フィールドの内容を新しい名前に置き換え、他のフィールドのエントリーを入力または変更して、このページを完成させます。
5. Save job template をクリックします。

1. 統合結果の内容は Web 上にアップロードされます。
2. 次に、invoke_set_stats Playbook を通じて set_stats が呼び出され、アップロードされた integration_results.txt の URL が、Ansible 変数 integration_results_url に成果物として保存されます。
3. ワークフローの 2 番目の Playbook は、Ansible の追加変数 integration_results_url を使用します。URI モジュールを使用して Web を呼び出し、前のジョブテンプレートジョブによってアップロードされたファイルの内容を取得します。次に、取得したファイルの内容を出力します。

手順

1. ナビゲーションパネルから、Automation Execution → Schedules を選択します。
2. Create schedule をクリックします。Create schedule ウィンドウが開きます。

3. このスケジュールを適用する Resource type を選択します。

   以下から選択します。

   • Job template

     • Job template の場合は、メニューから Job template を選択します。

   • Workflow job template

     • Workflow job template の場合は、メニューから Workflow job template を選択します。

   • Inventory source

     • Inventory source の場合は、適切なメニューから Inventory と Inventory source を選択します。

   • Project sync

     • Project sync の場合は、メニューから Project を選択します。

   • Management job template

     • Management job template の場合は、メニューから Workflow job template を選択します。

4. Job template と Project sync の場合は、次のフィールドに適切な詳細を入力します。

   • Schedule name: 名前を入力します。
   • オプション: Description: 説明を入力します。
   • Start date/time: スケジュールを開始する日時を入力します。

   • Time zone: タイムゾーンを選択します。入力する Start date/time は、このタイムゾーンの日時である必要があります。

     スケジュールを設定すると Schedule Details が表示され、スケジュールの設定や、選択した Local Time Zone でのスケジュールの発生状況を確認することができます。

     重要

     ジョブは UTC でスケジュールされます。特定の時間に実行される繰り返しのジョブは、夏時間への切り替えまたは夏時間からの切り替えが発生すると、ローカルタイムゾーンに合わせて移動できます。スケジュールが保存されると、システムはローカルタイムゾーンベースの時刻を UTC に解決します。スケジュールが正しく作成されていることを確認するには、スケジュールを UTC 時間で設定します。

5. Next をクリックします。Define rules ページが表示されます。

手順

1. 設定しているリソースの Schedules タブをクリックします。これには、テンプレート、プロジェクト、またはインベントリーソースを指定できます。
2. Create schedule をクリックします。Create schedule ウィンドウが開きます。

3. 以下のフィールドに該当する詳細を入力します。

   • Schedule name: 名前を入力します。
   • オプション: Description: 説明を入力します。
   • Start date/time: スケジュールを開始する日時を入力します。

   • Time zone: タイムゾーンを選択します。入力する Start date/time は、このタイムゾーンの日時である必要があります。

     スケジュールを設定すると Schedule Details が表示され、スケジュールの設定や、選択した Local Time Zone でのスケジュールの発生状況を確認することができます。

     重要

     ジョブは UTC でスケジュールされます。特定の時間に実行される繰り返しのジョブは、夏時間への切り替えまたは夏時間からの切り替えが発生すると、ローカルタイムゾーンに合わせて移動できます。スケジュールが保存されると、システムはローカルタイムゾーンベースの時刻を UTC に解決します。スケジュールが正しく作成されていることを確認するには、スケジュールを UTC 時間で設定します。

4. Next をクリックします。Define rules ページが表示されます。

手順

1. ナビゲーションパネルから、Automation Execution → Projects を選択します。
2. Projects ページで、Create project をクリックして、Create Project ウィンドウを起動します。

3. 以下の必須フィールドに適切な情報を入力します。

   • Name (必須)
   • オプション: Description
   • Organization (必須): プロジェクトには少なくとも 1 つの組織が必要です。ここで組織を 1 つ選択してプロジェクトを作成します。プロジェクトの作成時に、組織を追加できます。
   • オプション: Execution environment: このプロジェクトを実行するための実行環境の名前を入力するか、既存の環境のリストから検索します。詳細は、実行環境の作成と使用 を参照してください。
   • Source control type (必須): このプロジェクトに関連付けられた SCM タイプをメニューから選択します。選択したタイプに応じて、次のセクションのオプションが使用可能になります。詳細は、Playbook の手動管理 または ソースコントロールを使用した Playbook の管理 を参照してください。
   • オプション: Content signature validation credential: このフィールドを使用して、コンテンツ検証を有効にします。プロジェクトの同期中にコンテンツの署名を検証するために使用する GPG キーを指定します。コンテンツが改ざんされている場合、ジョブは実行されません。詳細は、プロジェクトの署名と検証 を参照してください。
4. Create project をクリックします。

手順

1. ナビゲーションパネルから、Automation Execution → Projects を選択します。

2. 更新するプロジェクトの横にある同期アイコン をクリックします。

   注記

   ソースコントロールを使用するためのプロジェクト設定を追加すると、設定したソースコントロールからプロジェクトの詳細を取得する同期がすぐに開始します。

   • 更新プロセスの詳細は、Status 列の下にあるプロジェクトのステータスをクリックしてください。Jobs セクションの Output タブが表示されます。

1. プロジェクトリポジトリーがすでに設定されており、ファイルに変更を加えるとします。

2. 変更を加えて、次のコマンドを実行します。

   ansible-sign project gpg-sign /path/to/project

   このコマンドは、チェックサムマニフェストを更新し、署名します。

3. 変更、更新されたチェックサムマニフェスト、および署名をリポジトリーにコミットします。

1. ナビゲーションパネルから、Automation Execution → Infrastructure → Credentials を選択します。
2. Create credential をクリックします。
3. 新しい認証情報にわかりやすい名前を付けます (例: "インフラストラクチャーチーム GPG 公開鍵")。
4. Credential type フィールドで、GPG Public Key を選択します。
5. Browse をクリックして、公開鍵ファイル (my_public_key.asc など) を見つけて選択します。

6. Create credential をクリックします。

   この認証情報は projects <ug_projects_add> で選択できるようになり、今後のプロジェクト同期時にコンテンツ検証が自動的に実行されます。

手順

1. 次のコマンドを実行して ansible-sign をインストールします。

   $ dnf install ansible-sign

2. 次のコマンドを使用して、ansible-sign が正常にインストールされたことを確認します。

   $ ansible-sign --version

   次のような出力は ansible-sign が正常にインストールされたことを示します。

   ansible-sign 0.1

手順

1. ナビゲーションパネルから、Automation Execution → Infrastructure → Topology View を選択します。Topology View が開き、各 receptor ノード間のリンクがグラフィック表示されます。

2. ズームレベルを調整したり、グラフィックビューを操作したりするには、ツールバーにあるズームイン ( )、ズームアウト ( )、拡大 ( )、リセット ( ) のコントロールアイコンを使用します。

   クリックおよびドラッグして移動したり、マウスやトラックパッドでスクロールすることでズームしたりすることもできます。画面に合わせる機能は、画面に合わせて自動的にグラフィックを拡大縮小し、中央に再配置します。これは、大きなメッシュ全体を表示する場合に特に便利です。

   ビューをデフォルトのビューにリセットするには、Reset view ( ) アイコンをクリックします。

3. 表示されているノードのタイプを特定するには、Legend を参照します。

   仮想マシンベースのインストール環境の場合は、コントロールプレーンおよび実行プレーン を参照してください。

   Operator ベースのインストール環境の場合は、コントロールプレーンおよび実行プレーン で各タイプのノードの詳細を参照してください。

   Legend には、node status <node_statuses> が色別に表示され、ノードの健全性を示します。Legend の Error ステータスには、Unavailable 状態 (Instances リストビューに表示されるもの) に加えて、Automation Controller の新しいバージョンで生じる今後のエラー状態が含まれます。

   Legend には、次のリンクステータスも表示されます。

   • Established: このリンク状態は、準備完了、使用不可、または無効であるノード間のピア接続を示します。
   • Adding: このリンク状態は、メッシュトポロジーに追加するように選択されたノード間のピア接続を示します。
   • Removing: このリンク状態は、トポロジーから削除するように選択されたノード間のピア接続を示します。
4. ノードにカーソルを合わせると、コネクターが強調表示され、そのノードに直接接続されているノード (ピア) が表示されます。また、ノードをクリックすると、そのホスト名、ノードタイプ、ステータスなどの詳細が取得されます。

5. 表示された詳細からインスタンスのホスト名のリンクをクリックすると、Details ページにリダイレクトされ、そのノードに関する詳細情報、特に Error ステータスに関する情報が表示されます。次の例を参照してください。

   Details ページを使用して、インスタンスを削除したり、必要に応じてインスタンスのヘルスチェックを実行したり、インスタンスからジョブの割り当てを解除したりできます。デフォルトでは、ジョブを各ノードに割り当てることができます。ただし、これを無効にして、ノードでジョブが実行されないようにすることもできます。

6. 関連情報: 新しいノードの作成とメッシュのスケーリングの詳細は、インスタンスによる容量の管理 を参照してください。

手順

1. ナビゲーションパネルから Automation Execution → Infrastructure → Inventories を選択します。Inventories ウィンドウには、現在使用可能なインベントリーのリストが表示されます。
2. Create inventory をクリックし、作成するインベントリーのタイプを選択します。

3. 以下のフィールドに該当する詳細を入力します。

   • Name: このインベントリーに適した名前を入力します。
   • オプション: Description: 任意の説明を入力します (オプション)。
   • Organization: 必須。利用可能な組織の中から選択します。

   • スマートインベントリーにのみ適用されます: Smart host filter: 検索フィルターを使用して、このインベントリーのホストを入力します。

     たとえば、"name__icontains=RedHat" などです。

     これらのオプションは、選択した組織に基づいています。

     フィルターは、タグがそれらの名前を含む特定のホストをフィルタリングするために使用されるという点でタグに似ています。したがって、Smart host filter フィールドに入力するには、ホスト自体ではなく、必要なホストを含むタグを指定します。

     フィルターでは大文字と小文字が区別されます。

   • Instance groups: このインベントリーを実行するインスタンスグループを選択します。

     複数のインスタンスグループを選択し、実行する順序で並べ替えることができます。

   • オプション: Labels: このインベントリーを説明するラベルを指定するため、インベントリーとジョブのグループ化とフィルタリングに使用できます。
   • 構築型インベントリーにのみ適用: Input inventories: この構築型インベントリーに含めるソースインベントリーを指定します。入力インベントリーの空のグループが、構築型インベントリーにコピーされます。
   • オプション: (構築型インベントリーにのみ適用): Cached timeout (seconds): キャッシュプラグインデータのタイムアウト時間を設定します。

   • 構築型インベントリーにのみ適用: Verbosity: 構築型インベントリーに関連付けられたインベントリーソースに関連する Playbook の実行時に Ansible が生成する出力のレベルを制御します。

     詳細レベルを次から選択します。

   • Normal
   • Verbose
   • More verbose
   • Debug
   • Connection Debug

   • WinRM Debug

     • Verbose ロギングには、すべてのコマンドの出力が含まれます。
     • More verbose では、Verbose よりも詳細な情報が提供されます。
     • Debug ロギングは非常に詳細で、特定のサポートインスタンスで役立つ SSH 操作に関する情報が含まれています。ほとんどのユーザーはデバッグモードの出力を確認する必要はありません。
     • Connection Debug により詳細モードで SSH を実行でき、SSH 接続の進行状況に関するデバッグ情報を提供します。

     • WinRM Debug は、Windows リモート管理に特有の詳細レベルに使用されます。

       構築型インベントリープラグインの使用方法 に関する情報を参照するには、 アイコンをクリックします。

   • 構築型インベントリーにのみ適用: Limit: 構築済みインベントリーに関連付けられたインベントリーソースに対して返されるホストの数を制限します。グループ名を limit フィールドに貼り付けて、そのグループ内のホストのみを含めることができます。詳細は、Source vars 設定を参照してください。
   • 標準インベントリーにのみ適用されます。オプション: Prevent Instance Group Fallback オプションをオンにして、Instance Groups フィールドにリストされているインスタンスグループのみがジョブを実行できるようにします。オフの場合、ジョブの実行場所の制御 で説明されている階層に基づいて、実行プール内の使用可能なすべてのインスタンスが使用されます。

   • Variables (構築型インベントリーの Source vars):

     • Variables このインベントリー内のすべてのホストに適用する変数の定義と値。JSON または YAML 構文を使用して変数を入力します。ラジオボタンを使用して、その 2 つを切り替えます。
     • 構築型インベントリーの Source vars は、データの groups キーの下にグループを作成します。Jinja2 テンプレート構文を受け入れ、すべてのホストに対してレンダリングし、true または false の評価を行い、結果が true の場合はそのホストを (エントリーのキーから) グループに含めます。これは、そのグループ名を limit フィールドに貼り付けて、そのグループ内のホストのみを含めることができるため、特に便利です。
4. Create inventory をクリックします。