Ansible Automation Platform のスタートガイド

手順

1. ターミナルで、コレクション内の roles ディレクトリーに移動します。

2. コレクション内に my_role というロールを作成します。

   $ ansible-galaxy role init my_role

   次の例に示すように、コレクションの roles ディレクトリー内に my_role という名前のロールが追加されます。

   ~/.ansible/collections/ansible_collections/<my_namespace>/<my_collection_name>
       ...
       └── roles/
           └── my_role/
               ├── .travis.yml
               ├── README.md
               ├── defaults/
               │   └── main.yml
               ├── files/
               ├── handlers/
               │   └── main.yml
               ├── meta/
               │   └── main.yml
               ├── tasks/
               │   └── main.yml
               ├── templates/
               ├── tests/
               │   ├── inventory
               │   └── test.yml
               └── vars/
                   └── main.yml

3. --role-skeleton 引数を使用して、カスタムロールのスケルトンディレクトリーを指定できます。これにより、組織はニーズに合わせて新しいロールの標準化されたテンプレートを作成できます。

   $ ansible-galaxy role init my_role --role-skeleton ~/role_skeleton

   これにより、~/role_skeleton の内容が my_role にコピーされて、my_role という名前のロールが作成されます。role_skeleton の内容は、ロールディレクトリー内で有効なファイルまたはフォルダーであれば、任意のものを使用できます。

手順

1. ナビゲーションパネルから、Automation Content → Namespaces を選択します。
2. My namespaces タブ内で、コレクションのアップロード先の名前空間を見つけてクリックします。
3. Collections タブを選択し、Upload collection をクリックします。
4. New collection モーダルで、Select file をクリックします。システムのファイルを見つけます。
5. Upload をクリックします。

手順

1. registry.redhat.io にログインします。

   $ podman login registry.redhat.io

2. レジストリーからベースイメージをプルします。

手順

1. ナビゲーションパネルから、Automation Execution → Infrastructure → Execution Environments を選択します。
2. Create execution environment をクリックして実行環境を作成します。

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

   1. Name (必須): 実行環境の名前を入力します。
   2. Image (必須): イメージ名を入力します。イメージ名には、完全な場所 (リポジトリー)、レジストリー、イメージ名、バージョンタグが必要です。たとえば、quay.io/ansible/awx-ee:latestrepo/project/image-name:tag のように入力します。

   3. オプション: Pull: ジョブを実行するときのプルのタイプを選択します。

      1. Always pull container before running: コンテナーの最新のイメージファイルをプルします。
      2. Only pull the image if not present before running: 何も指定されていない場合にのみ、最新のイメージをプルします。

      3. Never pull container before running: コンテナーイメージの最新バージョンをプルしません。

         注記

         プルのタイプを設定しなかった場合、値はデフォルトで Only pull the image if not present before running になります。

   4. オプション: Description: 必要に応じて説明を入力します。
   5. オプション: Organization: この実行環境を使用する組織を指定します。実行環境を複数の組織間で使用できるようにするには、このフィールドを空白のままにします。
   6. Registry credential: イメージに保護されたコンテナーレジストリーがある場合は、それにアクセスするための認証情報を提供します。
4. Create execution environment をクリックします。新しく追加した実行環境をジョブテンプレートで使用する準備ができました。
5. ジョブテンプレートに実行環境を追加するために、Automation Execution → Templates に移動してテンプレートを選択します。Edit template をクリックし、execution environment というラベルの付いたフィールドで実行環境を指定します。

手順

1. Automation Decisions → Decision Environments に移動します。
2. Create decision environment をクリックします。

3. 以下の設定を入力します。

   名前

   名前を入力します。

   Description

   このフィールドは任意です。

   Image

   これは、コンテナーレジストリー、イメージ名、およびバージョンタグを含む完全なイメージの場所です。

   Credential

   このフィールドは任意です。これは、決定環境イメージを使用するために必要なトークンです。

4. Create decision environment を選択します。

手順

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

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

   • Name: インベントリーの名前を入力します。
   • オプション: Description: 説明を入力します。
   • Organization: 利用可能な組織の中から選択します。
   • スマートインベントリーにのみ適用: Smart Host Filter: フィルターは、該当する名前を含む特定のホストをフィルタリングするために使用されるという点で、タグに似ています。したがって、このフィールドに入力する際には、ホスト自体ではなく、必要なホストを含むタグを指定します。フィルターでは大文字と小文字が区別されます。詳細は、「自動化実行の使用」ガイドの スマートホストフィルター を参照してください。
   • Instance groups: このインベントリーを実行するインスタンスグループを選択します。リストが膨大な場合は、検索を使用してオプションを絞り込みます。複数のインスタンスグループを選択し、実行する順序で並べ替えることができます。
   • オプション: Labels: このインベントリーを説明するラベルを追加します。これにより、ラベルを使用してインベントリーとジョブをグループ化およびフィルタリングできるようになります。
   • 構築型インベントリーにのみ適用: Input inventories: この構築型インベントリーに含めるソースインベントリーを指定します。入力インベントリーの空のグループが、構築型インベントリーにコピーされます。
   • 構築型インベントリーにのみ適用 (オプション): Cache timeout (seconds): キャッシュプラグインデータのタイムアウト時間を設定します。

   • 構築型インベントリーにのみ適用: Verbosity: 構築型インベントリーに関連付けられたインベントリーソースに関連する Playbook の実行時に Ansible が生成する出力のレベルを制御します。冗長性を標準からさまざまな冗長またはデバッグ設定まで選択します。これは "details" のレポートビューにのみ表示されます。

     • 詳細ログには、すべてのコマンドの出力が含まれます。
     • デバッグログは非常に詳細であり、特定のサポートインスタンスで役立つ SSH 操作に関する情報が含まれています。ほとんどのユーザーはデバッグモードの出力を確認する必要はありません。
   • 構築型インベントリーにのみ適用: Limit: 構築済みインベントリーに関連付けられたインベントリーソースに対して返されるホストの数を制限します。グループ名を limit フィールドに貼り付けて、そのグループ内のホストのみを含めることができます。詳細は、Source variables 設定を参照してください。

   • 標準インベントリーにのみ適用: Options: Instance groups フィールドにリストされているインスタンスグループのみがジョブを実行できるようにするには、Prevent instance group fallback の横にあるチェックボックスをオンにします。オフにすると、「自動化実行の設定」ガイドの ジョブ実行場所の制御 で説明されている階層に基づいて、実行プール内の使用可能なすべてのインスタンスが使用されます。詳細はツールチップをクリックしてください。

     注記

     スマートインベントリーの prevent_instance_group_fallback オプションは、API を介して設定します。

   • Variables (構築型インベントリーの場合は Source variables):

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

手順

1. 既存のテンプレートを確認するには、ナビゲーションパネルから Automation Execution → Templates を選択します。
2. Demo Job Template をクリックして、その詳細を表示します。

手順

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

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

   注記

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

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

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

   フィールド	オプション	Prompt on Launch
   Name	ジョブの名前を入力します。	該当なし
   Description	必要に応じて、任意の説明を入力します (オプション)。	該当なし
   Job Type	ジョブタイプを選択します。 Run: 起動時に Playbook を開始し、選択したホストで Ansible タスクを実行します。 Check: Playbook の「ドライラン」を実行します。実際に変更を加えずに、変更内容を報告します。チェックモードをサポートしていないタスクは無視され、変更予定の内容は報告されません。 ジョブタイプの詳細は、Ansible ドキュメントの Playbook セクションを参照してください。	はい
   Inventory	ログインしているユーザーが使用できるインベントリーから、このジョブテンプレートで使用するインベントリーを選択します。 システム管理者は、ジョブテンプレート内の特定のインベントリーを使用できるように、ユーザーまたはチームのパーミッションを割り当てる必要があります。	必須です。 インベントリーのプロンプトは、後続のプロンプトウィンドウに独自のステップとして表示されます。
   Project	ログインしているユーザーが利用できるプロジェクトから、このジョブテンプレートで使用するプロジェクトを選択します。	該当なし
   Source control branch	このフィールドは、ブランチの上書きを許可するプロジェクトを選択した場合にのみ表示されます。ジョブの実行で使用する上書きブランチを指定します。空白のままにすると、プロジェクトから指定された SCM ブランチ (またはコミットハッシュまたはタグ) が使用されます。 詳細は、ジョブブランチのオーバーライド を参照してください。	はい
   Execution Environment	このジョブの実行に使用するコンテナーイメージを選択します。実行環境を選択する前にプロジェクトを選択する必要があります。	必須です。 実行環境のプロンプトは、後続のプロンプトウィンドウに独自のステップとして表示されます。
   Playbook	使用可能な Playbook から、このジョブテンプレートで起動する Playbook を選択します。このフィールドには、選択したプロジェクトのプロジェクトベースパスにある Playbook の名前が自動的に入力されます。あるいは、Playbook がリストされていない場合は、その Playbook での実行に使用するファイル (foo.yml など) の名前など、Playbook の名前を入力することもできます。無効なファイル名を入力すると、テンプレートにエラーが表示されるか、ジョブが失敗します。	該当なし
   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 Tower ドキュメント (Defining variables at runtime) に説明されています。 YAML または JSON を使用してキーまたは値のペアを提供します。これらの変数には優先順位の最大値があり、他の場所で指定された他の変数をオーバーライドします。git_branch: production release_version: 1.5 は、値の例です。	必須です。 スケジュールで extra_vars を指定できるようにするには、ジョブテンプレートの変数に対して Prompt on launch を選択するか、ジョブテンプレートで Survey を有効にする必要があります。回答された Survey の質問は extra_vars になります。

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. 次のいずれかの方法を使用して、テンプレートを開いて編集します。

   • ジョブテンプレートの Details ページで Edit をクリックします。
   • ナビゲーションパネルから、Automation Execution → Templates を選択します。テンプレート名の横にある Edit をクリックし、適切な詳細を編集します。

2. 変更を保存します。

   
3. 保存後に終了して Templates リストビューに戻るには、パンくずリストのナビゲーションリンクを使用するか、Cancel をクリックします。Save をクリックしても Details ダイアログは終了しません。

手順

1. ナビゲーションパネルから、Automation Decisions → Rulebook Activations を選択します。
2. Create rulebook activation をクリックします。

3. 以下の情報を入力します。

   • Name: 名前を入力します。
   • Description: このフィールドは任意です。
   • Organization: このフィールドは任意です。
   • Project: このフィールドは任意です。
   • Rulebook: 選択したプロジェクトに応じてルールブックが表示されます。

   • Credential: このルールブックアクティベーションの認証情報を 0 個以上選択します。このフィールドは任意です。

     注記

     このフィールドに表示される認証情報は、ルールブックアクティベーションに基づいてカスタマイズされています。表示される認証情報のタイプは、Vault、Red Hat Ansible Automation Platform、または作成したカスタム認証情報タイプだけです。認証情報の詳細は、「自動化決定の使用」ガイドの 認証情報 を参照してください。

   • Decision environment: 決定環境は、Ansible ルールブックを実行するためのコンテナーイメージです。

     注記

     Event-Driven Ansible Controller では、決定環境のプルポリシーをカスタマイズすることはできません。デフォルトでは、always ポリシーの動作に従います。アクティベーションが開始されるたびに、システムはイメージの最新バージョンを取得しようとします。

   • Restart policy: これは、ソースプラグインを実行しているコンテナープロセスが終了した後にアクティベーションを再開する方法を決定するポリシーです。以下のオプションから選択します。

     • Always: ルールブックアクティベーションが正常に終了したかどうかに関係なく、ルールブックのアクティベーションを直ちに再開します。これは 5 回まで実行されます。
     • Never: コンテナープロセスが終了したときに、ルールブックアクティベーションを再開しません。
     • On failure: コンテナープロセスが失敗した場合にのみ、デフォルトで 60 秒後にルールブックアクティベーションを再開します。これは 5 回まで実行されます。

   • Log level: このフィールドでは、ログに記録するイベントの重大度とコンテンツのタイプを定義します。次のいずれかのオプションを選択します。

     • Error: アクティベーションの History タブに表示されるエラーメッセージを含むログ。
     • Info: 成功または失敗、トリガーされたアクション名と関連するアクションイベント、エラーなど、ルールブックアクティベーションに関する有用な情報を含むログ。
     • Debug: デバッグフェーズでのみ役立ち、運用時にはあまり有用でない可能性がある情報を含むログ。このログレベルでは、エラーデータとログレベルデータの両方が対象となります。
   • Service name: アクティベーションによってポートが公開される場合に、Kubernetes が受信接続を設定するためのサービス名を定義します。このフィールドは任意です。
   • Rulebook activation enabled?: ルールブックアクティベーションを自動的に有効にして実行するかどうかを切り替えます。
   • Variables: ルールブックの変数は JSON または YAML 形式です。内容は、ansible-rulebook コマンドの --vars フラグによって渡されるファイルと同等です。
   • Options: ルール監査にイベントを表示しない場合は、Skip audit events オプションをオンにします。
4. Create rulebook activation をクリックします。

手順

1. 行レベルのスイッチを選択して、選択したルールブックを有効または無効にします。
2. ウィンドウで、Yes, I confirm that I want to enable/disable these X rulebook activations を選択します。
3. Enable/Disable rulebook activation を選択します。

手順

1. Rulebook Activation enabled/disabled トグルの横にある More Actions アイコン ⋮ を選択します。
2. Restart rulebook activation を選択します。
3. ウィンドウで、Yes, I confirm that I want to restart these X rulebook activations を選択します。
4. Restart rulebook activations を選択します。

手順

1. Rulebook Activation enabled/disabled トグルの横にある More Actions アイコン ⋮ を選択します。
2. Delete rulebook activation を選択します。
3. ウィンドウで、Yes, I confirm that I want to delete these X rulebook activations を選択します。
4. Delete rulebook activations を選択します。

手順

1. サービスを公開するためのルートを (OpenShift Container Platform 上に) 作成します。以下は、決定環境 Pod のポート 5000 で POST を要求する ansible-rulebook ソースのルートの例です。

   kind: Route
   apiVersion: route.openshift.io/v1
   metadata:
     name: test-sync-bug
     namespace: dynatrace
     labels:
       app: eda
       job-name: activation-job-1-5000
   spec:
     host: test-sync-bug-dynatrace.apps.aap-dt.ocp4.testing.ansible.com
     to:
       kind: Service
       name: activation-job-1-5000
       weight: 100
     port:
       targetPort: 5000
     tls:
       termination: edge
       insecureEdgeTerminationPolicy: Redirect
     wildcardPolicy: None

2. ルートを作成したら、ルート URL へのポスト を使用してテストします。

   curl -H "Content-Type: application/json" -X POST
   test-sync-bug-dynatrace.apps.aap-dt.ocp4.testing.ansible.com -d
   '{}'

   注記

   ポートはルート (targetPort) で指定されているため、必要ありません。

手順

1. ターミナルで、コレクション内の roles ディレクトリーに移動します。

2. コレクション内に my_role というロールを作成します。

   $ ansible-galaxy role init my_role

   次の例に示すように、コレクションの roles ディレクトリー内に my_role という名前のロールが追加されます。

   ~/.ansible/collections/ansible_collections/<my_namespace>/<my_collection_name>
       ...
       └── roles/
           └── my_role/
               ├── .travis.yml
               ├── README.md
               ├── defaults/
               │   └── main.yml
               ├── files/
               ├── handlers/
               │   └── main.yml
               ├── meta/
               │   └── main.yml
               ├── tasks/
               │   └── main.yml
               ├── templates/
               ├── tests/
               │   ├── inventory
               │   └── test.yml
               └── vars/
                   └── main.yml

3. --role-skeleton 引数を使用して、カスタムロールのスケルトンディレクトリーを指定できます。これにより、組織はニーズに合わせて新しいロールの標準化されたテンプレートを作成できます。

   $ ansible-galaxy role init my_role --role-skeleton ~/role_skeleton

   これにより、~/role_skeleton の内容が my_role にコピーされて、my_role という名前のロールが作成されます。role_skeleton の内容は、ロールディレクトリー内で有効なファイルまたはフォルダーであれば、任意のものを使用できます。

手順

1. Red Hat Ansible Automation Platform にログインします。
2. ナビゲーションパネルから、Automation Content → Collections を選択します。Collections ページには、すべてのリポジトリーにわたるすべてのコレクションが表示されます。特定のコレクションを検索できます。
3. エクスポートするコレクションを選択します。コレクションの詳細ページが開きます。
4. Install タブから、Download tarball を選択します。.tar ファイルが、デフォルトのブラウザーのダウンロードフォルダーにダウンロードされます。これで、選択した場所にインポートできるようになります。

手順

1. ナビゲーションパネルから、Automation Content → Namespaces を選択します。
2. My namespaces タブ内で、コレクションのアップロード先の名前空間を見つけてクリックします。
3. Collections タブを選択し、Upload collection をクリックします。
4. New collection モーダルで、Select file をクリックします。システムのファイルを見つけます。
5. Upload をクリックします。

手順

1. registry.redhat.io にログインします。

   $ podman login registry.redhat.io

2. レジストリーからベースイメージをプルします。

手順

1. ナビゲーションパネルから、Automation Execution → Infrastructure → Execution Environments を選択します。
2. Create execution environment をクリックして、実行環境を追加します。

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

   • Name (必須): 実行環境の名前を入力します。
   • Image (必須): イメージ名を入力します。イメージ名には、完全な場所 (リポジトリー)、レジストリー、イメージ名、および quay.io/ansible/awx-ee:latestrepo/project/image-name:tag のサンプル形式のバージョンタグが必要です。

   • オプション: Pull: ジョブを実行するときのプルのタイプを選択します。

     • Always pull container before running: コンテナーの最新のイメージファイルをプルします。
     • Only pull the image if not present before running: 何も指定されていない場合のみ、最新のイメージをプルします。

     • Never pull container before running: コンテナーイメージの最新バージョンをプルしません。

       注記

       プルのタイプを設定しなかった場合、値はデフォルトで Only pull the image if not present before running になります。

   • オプション: 説明:
   • オプション: Organization: この実行環境を使用する組織を指定します。実行環境を複数の組織間で使用できるようにするには、このフィールドを空白のままにします。
   • Registry Credential: イメージに保護されたコンテナーレジストリーがある場合は、それにアクセスするための認証情報を指定します。

4. Create execution environment をクリックします。

   新しく追加した実行環境をジョブテンプレートで使用する準備ができました。

5. ジョブテンプレートに実行環境を追加するには、ジョブテンプレートの Execution Environment フィールドで実行環境を指定します。

1. ナビゲーションパネルから、Automation Execution → Projects を選択します。
2. プロジェクトをクリックして詳細を表示します。
3. リストされている各プロジェクトについて、各プロジェクトの横にあるアイコンを使用して、最新のリビジョンを同期したり、プロジェクトを編集したり、プロジェクトの属性をコピーしたりできます。

手順

1. ナビゲーションパネルから、Automation Execution → Templates を選択します。
2. テンプレートを選択して詳細を表示します。初期設定時に、作業を開始できるようにデフォルトのジョブテンプレートが作成されますが、独自のジョブテンプレートを作成することもできます。
3. Templates ページから起動アイコンをクリックしてジョブテンプレートを実行します。

手順

1. ナビゲーションパネルから Automation Execution → Infrastructure → Inventories を選択します。Inventories ウィンドウには、現在利用可能なインベントリーのリストと次の情報が表示されます。

   • Name: インベントリー名。

   • Status: ステータスには次のものがあります。

     • Success: インベントリーの同期が正常に完了しました。
     • Disabled: インベントリーにインベントリーソースが追加されていません。
     • Error: インベントリーソースが完了しましたが、エラーがあります。
   • Type: インベントリーが、標準インベントリー、スマートインベントリー、または構築型インベントリーのいずれであるかを示します。
   • Organization: インベントリーが属する組織。
2. インベントリー名を選択すると、インベントリーのグループとホストを含むインベントリーの Details ページが表示されます。

手順

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

   デフォルトのビューは折りたたまれて (コンパクト)、ジョブ名、ステータス、ジョブタイプ、開始時刻、終了時刻が表示されます。矢印アイコンをクリックすると、詳細を展開して表示できます。このリストをさまざまな基準で並べ替えたり、検索を実行して目的のテンプレートをフィルタリングしたりできます。

2. この画面から、次のタスクを実行できます。

   • ジョブの詳細と標準出力を表示する。
   • ジョブを再起動する。
   • 選択したジョブを削除する。

手順

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

2. ジョブを選択します。そのジョブの Output ビューが表示されます。このビューでは、次の基準でジョブ出力をフィルタリングできます。

   • Search output オプションを使用すると、キーワードで検索できます。
   • Event オプションを使用すると、エラー、ホストの障害、ホストの再試行、スキップされた項目などの関心のあるイベントによってフィルタリングできます。フィルターには、必要な数のイベントを含めることができます。