Red Hat Ansible Automation Platform Creator ガイド

次の一覧は、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-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/

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 では、Automation Hub は、Ansible 認定コンテンツコレクションのソースとして機能します。

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

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

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

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

Ansible Builder が開発される前に、Red Hat Ansible Automation Platform ユーザーは、必要なすべての依存関係がインストールされているカスタムの仮想環境またはコンテナーの作成時に、依存関係の問題およびエラーを実行することができました。

Ansible Builder を使用すると、コレクション、サードパーティーの Python 要件、システムレベルパッケージなど、自動化実行環境に含めるコンテンツを指定する、カスタマイズ可能な自動化実行環境定義ファイルを簡単に作成できます。これにより、ジョブの実行に必要な要件と依存関係をすべて満たすことができます。

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

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

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

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

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

頻繁に繰り返さないタスクの実行には、コマンドラインで Ansible を使用すると便利です。繰り返しタスクの処理には、Playbook を作成することが推奨されます。

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

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

$ 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) にAutomation content navigator をインストールできます。

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

View larger image

Ansible Automation Platform 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
      ansible.controller.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
      ansible.controller.job_template:
        name: my-job-1
        project: Job Template Test Project
        inventory: Demo Inventory
        playbook: hello_world.yml
        job_type: run
        state: present

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

  tasks:
    - name: Create a Project
      ansible.controller.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
      ansible.controller.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 開発に取り掛かることができます。

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

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

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

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

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

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

ansible-galaxy role init <role_name>

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 および Automation Controller 4.0 にアップグレードしたら、移行プロセスの追加手順について、以下のセクションを使用します。

Discovered virtual environments:

# 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: []

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

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 に更新する必要があります。

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