次の一覧は、Ansible Automation Platform 2.0 で利用可能なツールの配置と使用、およびその使用方法を示しています。

Playbook は、特定の人間が判読可能な命令のセットを含む YAML で書かれたファイルです。これには、単一ターゲットまたはターゲットグループで実行するように送信されます。

Playbook を使用して、リモートマシンの設定とデプロイメントを管理したり、ローリング更新を含む多層ロールアウトを順序付けたりすることができます。Playbook を使用して、アクションを他のホストに委譲し、途中で監視サーバーやロードバランサーと対話します。作成した Playbook は、自動化のために企業全体で繰り返し使用できます。

ロールは、自動化コンテンツをバンドルするだけでなく、既知のファイル構造を利用して関連する変数、ファイル、タスク、ハンドラー、およびその他のアーティファクトを自動的に読み込む Ansible の方法です。何百ものタスクで巨大な Playbook を作成する代わりに、ロールを使用して、タスクをより小さく、より個別のコンポーザブルな作業単位に分割することができます。

インフラストラクチャーのプロビジョニング、アプリケーションのデプロイ、および Ansible Galaxy で各タスクを実行するすべてのタスクにロールがあります。検索を でフィルタリングします。Type を選択します。Role をクリックします。対象のロールを見つけたら、Ansible に同梱されている ansible-galaxy コマンドを使用してダウンロードできます。

$ ansible-galaxy role install username.rolename

Ansible Content Collection は、自動化用の使いやすいツールキットです。Playbook、ロール、モジュール、プラグインなど、複数の種類のコンテンツがすべて 1 か所に含まれています。以下の図は、コレクションの基本構造を示しています。

collection/
├── docs/
├── galaxy.yml
├── meta/
│   └── runtime.yml
├── plugins/
│   ├── modules/
│   │   └── module1.py
│   ├── inventory/
│   ├── lookup/
│   ├── filter/
│   └── .../
├── README.md
├── roles/
│   ├── role1/
│   ├── role2/
│   └── .../
├── playbooks/
│   ├── files/
│   ├── vars/
│   ├── templates/
│   ├── playbook1.yml
│   └── tasks/
└── tests/
    ├── integration/
    └── unit/

Red Hat Ansible Automation Platform では、自動化ハブは、Ansible 認定コンテンツコレクションのソースとして機能します。

自動化実行環境は、Ansible コントロールノードとして機能する一貫性のある共有可能なコンテナーイメージです。自動化実行環境は、外部の依存関係のある Ansible コンテンツを共有する際の課題を軽減します。

自動化実行環境には、以下が含まれます。

Ansible Builder を使用して自動化実行環境を定義および作成することができます。

Ansible Builder は、さまざまな Ansible Collection で定義されたメタデータと、ユーザーが定義したメタデータを使用して、自動化実行環境を構築するプロセスを自動化するコマンドラインツールです。

自動化コンテンツナビゲーターは、テキストベースのユーザーインターフェイスを備えたコマンドラインのコンテンツクリエーターに焦点を当てたツールです。自動化コンテンツナビゲーターを使用して、以下を実行できます。

自動化実行環境などのコンテナーでは、ansible-playbook などの Ansible コアの一部である Ansible コマンドを実行できません。自動化実行環境と互換性がある Ansible CLI コマンドセットが含まれる、自動化コンテンツナビゲーターを使用します。Automation コンテンツナビゲーターでは、テキストベースのユーザーインターフェイス内にさらに詳細な出力も含まれます。

Automation Hub は、Red Hat サブスクリプションをお持ちのお客様が、Red Hat および弊社のテクノロジーパートナーがサポートするコンテンツをすばやく見つけて使用できる場所を提供し、最も要求の厳しい環境にさらなる安心を提供します。

大まかには、Automation Hub はプログラムに参加し認定されサポートされるコンテンツを提供する全パートナーの概要を説明します。

中央のビューから、ユーザーは各パートナーをより深く掘り下げ、コレクションをチェックアウトできます。

さらに、利用可能なすべてのコレクションの検索可能な概要が利用可能です。

コマンドラインで Ansible を使用すると、非常に頻繁に繰り返されないタスクを実行するために便利な方法になります。タスクを繰り返す場合は、Playbook を作成することが推奨されます。

コマンドラインにおける Ansible 用のアドホックコマンドは、以下の構造に従います。

$ ansible [pattern] -m [module] -a "[module options]"

Red Hat Subscription Management (RHSM) を使用して Ansible Builder をインストールし、Red Hat Ansible Automation Platform サブスクリプションをアタッチできます。Red Hat Ansible Automation Platform サブスクリプションをアタッチ すると、ansible-builder のインストールに必要なサブスクリプションのみのリソースにアクセスできます。サブスクリプションをアタッチすると、ansible-builder に必要なリポジトリーが自動的に有効になります。

RPM から、Red Hat Enterprise Linux (RHEL) に自動化コンテンツナビゲーターをインストールできます。

以下の例は、インストールの成功を示しています。

AAP 2.0 に同梱されるベースイメージは、Red Hat Ecosystem Catalog (registry.redhat.io) でホストされているものです。

Playbook には、1 つ以上のプレイが含まれます。基本的なプレイには以下のセクションが含まれます。

- name: Set Up a Project and Job Template
  hosts: host.name.ip
  become: true

  tasks:
    - name: Create a Project
      awx.awx.project:
        name: Job Template Test Project
        state: present
        scm_type: git
        scm_url: https://github.com/ansible/ansible-tower-samples.git

    - name: Create a Job Template
      awx.awx.job_template:
        name: my-job-1
        project: Job Template Test Project
        inventory: Demo Inventory
        playbook: hello_world.yml
        job_type: run
        state: present

Ansible Galaxy CLI ツールを使用して、独自のコレクションをローカルで作成できます。コレクション固有のコマンドはすべて、collection サブコマンドを使用してアクティベートできます。

上記のコマンドは、上記の名前空間引数から名前が付けられたディレクトリーが存在しない場合は作成し、そのディレクトリーに Collection 名を指定してディレクトリーを作成します。そのディレクトリー内では、デフォルトまたはスケルトン Collection になります。ここでは、ロールまたはプラグインを追加し、独自の Collection 開発に取り掛かることができます。

実行環境に関連して、コレクション開発者は Ansible Builder で適切なメタデータを提供することで、コンテンツの要件を宣言できます。

Collection からの要件は、以下の方法で認識できます。

コレクションメンテナーは、introspect コマンドを使用して、ansible-builder が想定する要件を認識していることを確認できます。

$ ansible-builder introspect --sanitize ~/.ansible/collections/

Ansible Galaxy CLI ツールを使用してロールを作成できます。ロール固有のコマンドは、roles サブコマンドからアクセスできます。

ansible-galaxy role init <role_name>

コレクション外部のスタンドアロンロールは引き続きサポートされますが、Ansible Automation Platform が提供するすべての機能を活用するには、新しいロールをコレクション内にを作成する必要があります。

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

環境に Collection のセットを指定する概念は、依存関係を解決し、インストールすることです。Collection 自体は、自動化実行環境を生成するマシンにインストールする必要はありません。

自動化実行環境は、この定義から構築され、コンテナーイメージが作成されます。これらのイメージの作成手順については、Ansible Builder のドキュメントを参照してください。

Red Hat Ansible Automation Platform 2.0 および自動化コントローラー 4.0 にアップグレードしたら、移行プロセスの追加手順について、以下のセクションを使用します。

# Discovered virtual environments:
/var/lib/awx/venv/testing
/var/lib/venv/new_env

To export the contents of a virtual environment, re-run while supplying the path as an argument:
awx-manage export_custom_venv /path/to/venv

inventory_sources:
- id: 15
  name: celery
job_templates:
- id: 9
  name: Demo Job Template @ 2:40:47 PM
- id: 13
  name: elephant
organizations
- id: 3
  name: alternating_bongo_meow
- id: 1
  name: Default
projects: []

numpy==1.20.2
pandas==1.2.4
python-dateutil==2.8.1
pytz==2021.1
six==1.16.0

To list all available custom virtual environments run:
awx-manage list_custom_venvs

Ansible Core のバージョン間で移行するには、Playbook、プラグイン、その他の Ansible インフラストラクチャーの他の部分を更新して、最新バージョンで機能するようにする必要があります。このプロセスでは、変更が Ansible Core の連続する各バージョンに対して行われる更新に対して検証されている必要があります。Ansible 2.9 から Ansible 2.11 に移行する場合は、最初に Ansible 2.10 の要件を満たしていることを確認し、そこから 2.11 に更新する必要があります。

コンテンツ作成者は、自動化コンテンツナビゲーターを使用して Ansible Playbook を実行し、各プレイとタスクの結果をインタラクティブに調べて、Playbook を検証またはトラブルシューティングできます。また、実行環境内で Ansible Playbook を実行すれば、実行環境がなくても、問題を比較してトラブルシューティングできます。