Ansible Automation Platform 2.1 の導入
概要
コメントとフィードバック
オープンソースの精神を大切にしています。リファレンスアーキテクチャーに関するフィードバックやコメントをお聞かせください。文書は社内で確認していますが、何らかの問題や誤字脱字があるかもしれません。フードバックにより、当社は作成文書の品質を向上でき、読者も改善点や内容の拡充などについてご意見いただけます。文書に関するフィードバックは、電子メールで ansible-feedback@redhat.com に送信してください。その際には、メール本文内で文書のタイトルを記載してください。
第1章 概要
Ansible Automation Platform 2.1 リファレンスアーキテクチャーは、可用性の高い Ansible Automation Platform 環境をデプロイするための独創的な設定を提供します。また、Ansible Automation Platform 2.1 をインストールおよび設定するための最新のベストプラクティスを含む段階的なデプロイメント手順について説明しています。これは、Ansible Automation Platform のデプロイを検討しているシステムおよびプラットフォーム管理者に最適です。
このリファレンス環境で使用される環境は、図1.1「リファレンスアーキテクチャーの概要」 の図に示されています。
図1.1 リファレンスアーキテクチャーの概要
上のイメージでは、高可用性のために Ansible サイト 1 および Ansible サイト 2 の 2 つのサイトが含まれています。サイト 1 はアクティブな環境であり、サイト 2 はパッシブな環境です。各サイトには以下が含まれます。
- 1 つの PostgreSQL データベースを備えた 3 つのノード自動化コントローラークラスター
- 1 つの PostgreSQL データベースを備えた 3 つのノード自動化ハブクラスター
- 自動化コントローラークラスターごとに 2 つの実行ノード
- Red Hat Insights やサービスカタログなどの console.redhat.com サービスへのアクセス
PostgreSQL データベースの HA を実現するために、Git リポジトリーでプッシュイベントまたはマージイベントがトリガーされる際に、Configuration as Code と Git Webhook を組み合わせて使用します。これにより、Ansible サイト 1 と Ansible サイト 2 の両方で指定されたイベントが設定されます。
最後に、ロギングの一貫性を確保するために、両方の Ansible Automation Platform 環境が使用する高可用性の集中型ロギング環境がインストールされます。
第2章 前提条件
この高可用性 Ansible Automation Platform 2.1 リファレンス環境のインストールでは、各サイトで以下を使用します。
- 3 つのコントロールプレーンノード。
- 1 つのコントロールプレーンデータベースノード
- 2 つの実行ノード
- 3 つの自動化ハブノード
- 1 つの自動化ハブデータベースノード
- 自動化ハブのインストールで使用する共有ファイルシステム (/var/lib/pulp)
これらのノードは、物理サーバーである必要はありません。
2.1. ノードの要件
表2.1 実行ノード
| 実行ノード | 必須 | 注記 |
| RAM | 16 Gb | |
| CPU | 4 |
|
表2.2 Automation Controller ノード
| コントロールノード | 必須 | 注記 |
| RAM | 16 Gb | |
| CPU | 4 |
|
| ディスク: サービスノード | 40 GB の専用ハードディスク領域 |
|
| ディスク: データベースノード | 20 GB の専用ハードディスク領域 |
|
| ブラウザー | Mozilla Firefox または Google Chrome の現行のサポートバージョン | |
| データベース | PostgreSQL バージョン 12 |
表2.3 自動化ハブノード
| 自動化ハブノード | 必須 | 注記 |
| RAM | 最小 8GB |
|
| CPU | 最小 2 つ |
|
| ディスク: サービスノード | 40 GB の専用ハードディスク領域 |
|
| ディスク: データベースノード | 20 GB の専用ハードディスク領域 |
|
| ブラウザー | Mozilla Firefox または Google Chrome の現行のサポートバージョン | |
| データベース | PostgreSQL バージョン 12 |
表2.4 データベースノード 3 台
| データベースノード 3 台 | 必須 | 注記 |
| RAM | 16 GB | |
| CPU | 4 | |
| ディスク | 20 GB の専用ハードディスク領域 |
|
すべての自動化コントローラーデータは PostgreSQL データベースに保存されます。データベースストレージは、マネージドホストの数、ジョブ実行数、ファクトキャッシュに保存されているファクトの数、および個別ジョブのタスク数と共に増加します。たとえば、ホスト 250 台で 1 時間ごと (1 日に 24 回) に 20 個のタスクの Playbook を実行する場合は、毎週 800,000 を超えるイベントを保存します。
データベースに十分な容量が確保されていない場合は、以前のジョブ実行やファクトを定期的に消去する必要があります。詳細は、Management Jobs を参照してください。
2.2. ネットワーク要件
Ansible Automation Platform 2.1 には、Ansible Automation Platform クラスター内のすべてのノードに少なくとも 1 つのネットワークが必要です。
Ansible Automation Platform ダッシュボードにアクセスするには、コントロールプレーンノードが存在するネットワークにアクセスできるブラウザーが必要です。Ansible Automation Platform ダッシュボードに外部からアクセスする場合は、コントロールプレーンノードにパブリック IP アドレスを追加してください。
ネットワーク管理者は、すべてのノードの静的 DHCP アドレスと適切な DNS レコードを設定することを推奨します。これにより、DHCP サーバーがない場合でも、各ノードの IP アドレスが一定に保たれます。静的 IP アドレスを使用するには、IP アドレスを無限リースで予約します。
このリファレンスアーキテクチャーの目的上、DHCP サーバーの設定、DNS レコードの設定、およびロードバランサーの設定は範囲外です。
ネットワーク管理者は、少なくとも次の数の IP アドレスを予約する必要があります。
- コントロールプレーンノードごとに 1 つの IP アドレス。
- 実行ノードごとに 1 つの IP アドレス。
- 自動化ハブノードごとに 1 つの IP アドレス。
- コントロールプレーンデータベース用に 1 つの IP アドレス。
- 自動化ハブデータベース用に 1 つの IP アドレス。
- Ansible Automation Platform サイト 1 のロードバランサー自動化コントローラークラスターアドレス用に 1 つの IP アドレス。
- Ansible Automation Platform サイト 2 のロードバランサー自動化コントローラークラスターアドレス用に 1 つの IP アドレス。
- Ansible Automation Platform サイト 1 のロードバランサープライベート自動化ハブクラスターアドレス用に 1 つの IP アドレス。
- Ansible Automation Platform サイト 2 のロードバランサープライベート自動化ハブクラスターアドレス用に 1 つの IP アドレス。
このリファレンス環境では、サイトごとに 12 個の IP アドレスが予約されています。
次の表は、リファレンス環境の Ansible サイト 1の例を示しています。
| 使用方法 | ホスト名 | IP |
| コントロールプレーン 1 | controlplane-1.site1.example.com | 192.168.0.10 |
| コントロールプレーン 2 | controlplane-2.site1.example.com | 192.168.0.11 |
| コントロールプレーン 3 | controlplane-3.site1.example.com | 192.168.0.12 |
| コントロールプレーンデータベース | controlplane-db.site1.example.com | 192.168.0.13 |
| コントロールプレーンクラスターのアドレス | controlplane-cluster.site1.example.com | 192.168.0.14 |
| 実行ノード 1 | executionnode-1.site1.example.com | 192.168.0.15 |
| 実行ノード 2 | executionnode-2.site1.example.com | 192.168.0.16 |
| 自動化ハブノード 1 | automationhub-1.site1.example.com | 192.168.0.17 |
| 自動化ハブノード 2 | automationhub-2.site1.example.com | 192.168.0.18 |
| 自動化ハブノード 3 | automationhub-3.site1.example.com | 192.168.0.19 |
| 自動化ハブデータベース | automationhub-db.site1.example.com | 192.168.0.20 |
| 自動化ハブクラスター | automationhub-cluster.site1.example.com | 192.168.0.21 |
2.3. ノードの検証チェックリスト
以下は、すべての要件の要約です。
- ❏ コントローラーノードと実行ノード用に 16 GB の RAM
- ❏ プライベート自動化ハブノード用に 8 GB の RAM
- ❏ コントローラーノードと実行ノード用に 4 つの CPU
- ❏ プライベート自動化ハブノード用に 2 つの CPU
- ❏ データベースノード用に 20 GB 以上のディスク容量
- ❏ データベースノード以外のノード用に 40 GB 以上のディスク容量
- ❏ DHCP 予約では、無限リースを使用して、静的 IP アドレスを持つクラスターをデプロイメント。
- ❏ すべてのノードの DNS レコード
- ❏ すべてのノードで Red Hat Enterprise Linux 8.4 以降 64 ビット (x86) がインストール済み
- ❏ すべてのノードに Chrony を設定済み
- ❏ すべてのノードに ansible-core バージョン 2.11 以降がインストール済み
第3章 Ansible Automation Platform コントローラーの設定の詳細
このリファレンスアーキテクチャーは、Red Hat Enterprise Linux 8.4 x86_64 における自動化メッシュを使用した Ansible Automation Platform 2.1 のデプロイに焦点を当てています。この設定は、包括的な Ansible Automation Platform ソリューションを提供することを目的としています。このリファレンスアーキテクチャーでカバーされている主要なソリューションコンポーネントには、以下が含まれます。
- Red Hat Enterprise Linux 8.4
- Ansible Automation Platform 2.1
- 自動化メッシュ
- プライベート自動化ハブ
3.1. Network Configuration
3.1.1. Chrony 設定
クラスター内の各 Ansible Automation Platform ノードは NTP サーバーにアクセスできる必要があります。chronyd は、システムクロックを同期するためのデーモンです。クロックを NTP サーバーと同期できます。これにより、クラスターノードが検証を必要とする SSL 証明書を使用する場合、ノード間の日付と時刻が同期していなくても失敗しません。
すべてのノードで実行:
インストールされていない場合は、次のように
chronyをインストールします。# dnf install chrony --assumeyes
viなどのテキストエディターで/etc/chrony.confファイルを編集します。# vi /etc/chrony.conf
次のパブリックサーバープールセクションを見つけ、適切なサーバーを含めるように変更します。必要なサーバーは 1 つだけですが、3 つを推奨します。サーバーと適切に同期するのにかかる時間を短縮するために、iburst オプションが追加されました。
# Use public servers from the pool.ntp.org project. # Please consider joining the pool (http://www.pool.ntp.org/join.html). server <ntp-server-address> iburst-
/etc/chrony.confファイル内にすべての変更を保存します。 ホストの起動時に
chronydデーモンが起動するように起動して有効にします。# systemctl --now enable chronyd.service
chronyd デーモンのステータスを確認します。
# systemctl status chronyd.service
3.2. OS 設定
3.2.1. Red Hat Subscription Manager
subscription-manager コマンドは、システムを Red Hat Network (RHN) に登録し、システムのサブスクリプションエンタイトルメントを管理します。--help オプションは、コマンドラインで使用可能なオプションをコマンドにクエリーするように指定します。--help オプションがコマンドディレクティブとともに発行された場合、特定のコマンドディレクティブで使用可能なオプションがリスト表示されます。
Red Hat Subscription Management を使用してシステムにパッケージを提供するには、最初にシステムをサービスに登録する必要があります。システムを登録するには、subscription-manager コマンドを使用して、register コマンドディレクティブを渡します。--username および --password オプションが指定されている場合、コマンドは RHN ネットワーク認証情報の入力を求めません。
以下に、subscription-manager を使用してシステムを登録する例を示します。
# subscription-manager register --username [User] --password '[Password]' The system has been registered with id: abcd1234-ab12-ab12-ab12-481ba8187f60
システムを登録したら、エンタイトルメントプールに接続する必要があります。このリファレンス環境の目的上、Red Hat Ansible Automation Platform は選択されたプールになります。Red Hat Ansible Automation Platform エンタイトルメントプールを特定してサブスクライブします。次のコマンドディレクティブが必要です。
# subscription-manager list --available | grep -A8 "Red Hat Ansible Automation Platform"
---
Subscription Name: Red Hat Ansible Automation Platform, Premium (5000 Managed Nodes)
Provides: Red Hat Ansible Engine
Red Hat Single Sign-On
Red Hat Ansible Automation Platform
SKU: MCT3695
Contract: <contract>
Pool ID: <pool_id>
Provides Management: No
Available: 9990
Suggested: 1
Service Type: L1-L3
Roles:# subscription-manager attach --pool <pool_id>
Successfully attached a subscription for: Red Hat Ansible Automation Platform, Premium (5000 Managed Nodes)# subscription-manager repos --enable=ansible-automation-platform-2.1-for-rhel-8-x86_64-rpms
3.2.2. ユーザーアカウント
Ansible Automation Platform 2.1 をインストールする前に、デプロイメントプロセスの sudo 権限を持つ非 root ユーザーを作成することを推奨します。このユーザーは以下で使用されます。
- SSH 接続
- インストール時中のパスワードレス認証
このリファレンス環境の目的上、ユーザー ansible が選択されていますが、任意のユーザー名を使用できます。
すべてのノードで、ansible という名前のユーザーを作成し、ssh キーを生成します。
非 root ユーザーを作成します。
# useradd ansible
ansibleユーザーのパスワードを設定します。# passwd ansible
ansibleユーザーとしてsshキーを生成します。$ ssh-keygen -t rsa
ansibleユーザーとしてsudoを使用する場合は、パスワード要件を無効にします。# echo "ansible ALL=(ALL) NOPASSWD:ALL" | sudo tee -a /etc/sudoers.d/ansible
3.2.3. SSH キーをすべてのノードにコピー
ansible ユーザーを作成したら、ansible ユーザーとして ssh キーをすべてのノードにコピーします。これにより、Ansible Automation Platform のインストールが実行されたときに、パスワードなしですべてのノードへの ssh が可能になります。
これは、次のように ssh-copy-id コマンドを使用して実行できます。
$ ssh-copy-id ansible@hostname.example.com
クラウドプロバイダー内で実行している場合は、代わりに、すべてのノードに ansible ユーザーの公開鍵を含む ~/.ssh/authorized_keys ファイルを作成し、読み取りおよび書き込み権限 (権限 644) を持つ所有者 (ansible) のみに authorized_keys ファイルへのアクセス権限を設定する必要があります。
3.2.4. ファイアウォールの設定
ファイアウォールへのアクセスと制限は、Ansible Automation Platform 2.1 環境を保護する上で重要なロールを果たします。Red Hat Enterprise Linux 8.4 を使用すると、デフォルトで動的ファイアウォールデーモンである firewalld が使用されます。firewalld は、ネットワークゾーンを割り当てて、ネットワークとそれに関連する接続およびインターフェイスに信頼レベルを割り当てることによって機能します。
Ansible Automation Platform 2.1 のインストールを成功させるために、適切なサービスとポートへのアクセスを許可するようにファイアウォール設定を設定することを推奨します。
すべてのノードで、firewalld がインストール、起動、および有効化されていることを確認します。
firewalldパッケージをインストールします。# dnf install firewalld --assumeyes
firewalldサービスを開始します。# systemctl start firewalld
Firewalldサービスを有効にします。# systemctl enable firewalld
第4章 Ansible Automation Platform コントローラーデータベースの設定の詳細
4.1. コントローラーデータベースのファイアウォールの設定
Ansible Automation Platform のインストールを成功させるための前提条件の 1 つは、データベースノードでデータベースポートを有効にすることです。使用されるポートは、インベントリーファイル内の pg_port によって設定されます。
インベントリーファイルのスニペット
pg_port='5432'
データベースノード内で、ansible ユーザーとして、インストールに使用する firewalld ポートを設定します。
firewalldが実行されていることを確認します。$ sudo systemctl status firewalld
コントローラーデータベースノードに
firewalldポートを追加します (例: ポート 5432)。$ sudo firewall-cmd --permanent --zone=public --add-port=5432/tcp
firewalldをリロードします。$ sudo firewall-cmd --reload
ポートが開いていることを確認します。
$ sudo firewall-cmd --list-ports
第5章 Ansible Automation Platform の実行とホップノード設定の詳細
5.1. 実行ノードとホップノードのファイアウォール設定
Ansible Automation Platform のインストールを成功させるための前提条件の 1 つは、メッシュノード (実行ノードおよびホップノード) で自動化メッシュポートを有効にすることです。すべてのノードのメッシュネットワークに使用されるデフォルトポートは 27199/tcp に設定されていますが、インベントリーファイル 内の各ノードの変数として receptor_listener_port を指定することで、別のポートを使用するように設定できます。
インベントリーファイルのスニペット
receptor_listener_port=27199
このリファレンス環境では、すべての Ansible Automation Platform 2 コントローラーノードはノードタイプ control として指定されます。コントロールノードが hybrid ノード (デフォルトのノードタイプ) として指定されている場合、メッシュポート (デフォルト: 27199/tcp) を有効にする必要があります。
ホップおよび実行ノード内で、ansible ユーザーとして以下を実行します。
firewalldが実行されていることを確認します。$ sudo systemctl status firewalld
ホップおよび実行ノードに
firewalldポートを追加します (ポート 27199 など)。$ sudo firewall-cmd --permanent --zone=public --add-port=27199/tcp
firewalldをリロードします。$ sudo firewall-cmd --reload
ポートが開いていることを確認します。
$ sudo firewall-cmd --list-ports
第6章 Ansible Automation Platform 2.1 のインストール
Ansible Automation Platform 2.1 のインストールでは、自動化コントローラーと自動化メッシュを使用して、自動化ワークロードを処理するためのシンプルで安全かつ柔軟な方法を提供します。
自動化コントローラーは、UI、Restful API、RBAC ワークフロー、および CI/CD インテグレーションを通じて自動化のためのコントロールプレーンを提供します。
自動化メッシュは、既存ネットワークを使用して互いにピアツーピア接続を確立しているノードを介して、大規模な分散ワーカーのコレクション全体で作業分散を容易にできるオーバーレイネットワークです。
自動化メッシュを配置すると、以下が可能になります。
- ダウンタイムなしでクラスター容量を動的に拡張する。
- 実行プレーンとコントロールプレーンを切り離す。
- 停止が自動的に存在する可能性がある場合は、実行を別のパスに再ルーティングする。
以下は、自動化メッシュを使用してクラスター化された Ansible Automation Platform 2.1 をデプロイする手順です。
次のインストールは、このリファレンス環境において Ansible Automation Platform クラスターの Ansible サイト 1 で実行されます。完了後、 Ansible サイト 2 でも同じ手順を実行してください。
controlplane-1.site1.example.com で、ansible ユーザーとして以下を実行します。
- Ansible Automation Platform 2.1Setup tar (する ansible-automation-platform-setup-2.1.0-1.tar.gz) をダウンロードします。
ansible-automation-platform-setup-2.1.0-1.tar.gz をデプロイメントします。
$ tar zxvf ansible-automation-platform-setup-2.1.0-1.tar.gz
ディレクトリーを ansible-automation-platform-setup-2.1.0-1.tar.gz に変更します。
cd ansible-automation-platform-setup-2.1.0-1/
既存のインベントリーファイルをバックアップします。
$ cp inventory inventory.bkup
ansible-coreパッケージをインストールします。$ sudo dnf install ansible-core --assumeyes
インベントリーを変更して、環境に関する適切な情報を含めます。以下は、このリファレンス環境の例です。
[automationcontroller] controlplane-1.site1.example.com ansible_connection=local controlplane-2.site1.example.com controlplane-3.site1.example.com [automationcontroller:vars] node_type=control 1 peers=execution_nodes 2 [execution_nodes] executionnode-1.site1.example.com peers=executionnode-2.site1.example.com 3 executionnode-2.site1.example.com [database] controldatabase.site1.example.com 4 [all:vars] #Handled by Ansible Vault admin_password='' 5 pg_host='controldatabase.site1.example.com' 6 pg_port='5432' 7 pg_database='awx' pg_username='awx' #Handled by Ansible Vault pg_password='' 8 pg_sslmode='prefer' registry_url=’registry.redhat.io’ 9 registry_username='myusername' 10 #Handled by Ansible Vault registry_password='' 11
- 1
- コントロールノードは、プロジェクトおよびインベントリーの更新およびシステムジョブを実行しますが、実行ジョブは実行しません。これらのノードでは実行機能は無効になります。
- 2
- ピアの関係はノード間の接続を定義します。コントロールプレーンノードと実行ノード間のピア関係を設定します。
- 3
- 実行ノード間のピア関係を設定します。
- 4
- コントローラーをインストールするために PostgreSQL データベースをインストールするノードを設定します。
- 5
- インストール完了時に管理者ユーザーが UI にアクセスするためのパスワードを設定します。
- 6
- PostgreSQL ホスト (データベースノード) を設定します。
- 7
- データベースノードに使用する PostgreSQL ポートを設定します。
- 8
- PostgreSQL データベースのパスワードを設定します。
- 9
- 実行環境イメージがダウンロードされ、インストールに含まれます。イメージをダウンロードするには適切な認証情報が必要です。
- 10
- registry_url にアクセスするためのユーザー認証情報。
- 11
- registry_url にアクセスするためのパスワード認証情報。
暗号化された認証情報を保存する credentials.yml というラベルのファイルを作成します。
$ cat credentials.yml
admin_password: my_long_admin_pw pg_password: my_long_pg_pw registry_password: my_long_registry_pw
ansible-vaultを使用して credentials.yml ファイルを暗号化します。$ ansible-vault encrypt credentials.yml
New Vault password: Confirm New Vault password: Encryption successful
警告暗号化された vault パスワードを安全な場所に保管します。
credentials.yml ファイルが暗号化されていることを確認します。
$ cat credentials.yml
$ANSIBLE_VAULT;1.1;AES256 36383639653562386534316333333961383336306465336465613831353435313530376464616539 3765393063303065323466663330646232363065316666310a373062303133376339633831303033 34313534383962613632303761636632623932653062343839613639653635643365616233313365 3636616639313864300a353239373433313339613465326339313035633565353464356538653631 63346434383534643237663862353361366632613634333231316334363939396461326561643336 3430633534303935646264633034383966336232303365383763
Ansible Automation Platform 2.1 をインストールするために
setup.shを実行し、credentials.yml および --ask-vault-pass オプションを渡します。$ ANSIBLE_BECOME_METHOD='sudo' ANSIBLE_BECOME=True ANSIBLE_HOST_KEY_CHECKING=False ./setup.sh -e @credentials.yml -- --ask-vault-pass
注記インストールを成功させるために、次の ANSIBLE*_ 変数が設定されています。
注記インベントリーファイルに設定できるさまざまな値の詳細は、インベントリーファイルの設定 を参照してください。
- Ansible Automation Platform ダッシュボード (例: controlplane-cluster.site1.example.com) にログインします。
サブスクリプションマニフェストまたはユーザー名/パスワードを使用して、Ansible Automation Platform サブスクリプションをアクティブ化します。
注記サブスクリプションマニフェストを生成する手順については、付録D サブスクリプションマニフェストの生成 を参照してください。
第7章 プライベート自動化ハブ
自動化ハブは、認定されたコレクションの中心的な場所です。信頼、テスト、およびサポートされているコンテンツの主なソースとして機能します。プライベート自動化ハブは、自動化開発者が独自の自動化コンテンツで協力し、それを公開し、組織内での Ansible コードの配信を合理化する機能を提供します。
Ansible Automation Platform 2.1 のプライベート自動化ハブは、主に自動化実行環境のサポートを提供します。実行環境は、自動化が実行される環境を定義、構築、および配布するための標準化された方法です。一言で言えば、自動化実行環境は、プラットフォーム管理者による Ansible の管理を容易にするコンテナーイメージです。
7.1. 高可用性自動化ハブの要件
7.1.1. ファイアウォールサービスの有効化
高可用性自動化ハブ環境の一部として、共有ファイルシステムを使用する必要があります。そのため、次のセクションに示すとおり、ファイルシステムを正常にマウントするには、以下のファイアウォールサービスを有効にする必要があります。
各自動化ハブノードで、ansible ユーザーとして以下を行います。
次の
firewalldサービス (nfs、mountd、rpc-bind) が有効になっていることを確認します。$ sudo firewall-cmd --zone=public --add-service=nfs $ sudo firewall-cmd --zone=public --add-service=mountd $ sudo firewall-cmd --zone=public --add-service=rpc-bind
変更を有効にするには、
firewalldをリロードします。$ sudo firewall-cmd --reload
firewalldサービスが有効になっていることを確認します。$ sudo firewall-cmd --get-services
第8章 プライベート自動化ハブのインストール
すべての前提条件が設定されたら、最後の手順としては、クラスター化された自動化ハブのインストール用にインベントリーファイルを変更し、setup.sh を実行します。
このリファレンス環境内では、すべてのノードにアクセスできる controlplane-1.site1.example.com システムを使用して、クラスター化された自動化ハブ環境の setup.sh を実行します。
次のインストールは、このリファレンス環境において Ansible Automation Platform クラスターの Ansible サイト 1 で実行されます。完了後、 Ansible サイト 2 でも同じ手順を実行してください。
controlplane-1.site1.example.com で、ansible ユーザーとして以下を実行します。
ディレクトリーを ansible-automation-platform-setup-2.1.0-1.tar.gz に変更します。
cd ansible-automation-platform-setup-2.1.0-1/
既存のインベントリーファイルをバックアップします。
$ cp inventory inventory-controller.bkup
インベントリーファイルを変更して、環境に関する適切な情報を含めます。以下は、このリファレンス環境の例です。
[automationcontroller] [automationcontroller:vars] [execution_nodes] [automationhub] ahub-1.site1.example.com 1 ahub-2.site1.example.com ahub-3.site1.example.com [database] ahub-db.site1.example.com 2 [servicescatalog_workers] [sso] [all:vars] admin_password='' pg_host='' pg_port='' pg_database='' pg_username='' pg_password='' pg_sslmode='' # set to 'verify-full' for client-side enforced SSL registry_url= 'registry.redhat.io' 3 registry_username='myusername' 4 #Handled by Ansible vault registry_password='' 5 receptor_listener_port=27199 #Handled by Ansible vault automationhub_admin_password='' 6 automationhub_pg_host='ahub-db.site1.example.com' 7 automationhub_pg_port='5432' 8 automationhub_pg_database='automationhub' automationhub_pg_username='automationhub' #Handled by Ansible vault automationhub_pg_password='' 9 automationhub_pg_sslmode='prefer' sso_console_admin_password=''
- 1
- 自動化ハブノード。
- 2
- 自動化ハブのインストール用に PostgreSQL データベースをインストールするノードを設定します。
- 3
- 実行環境イメージがダウンロードされ、インストールに含まれます。イメージをダウンロードするには適切な認証情報が必要です。
- 4
- registry_url にアクセスするためのユーザー認証情報。
- 5
- registry_url にアクセスするためのパスワード認証情報。
- 6
- インストール完了時に管理者ユーザーが UI にアクセスするためのパスワードを設定します。
- 7
- PostgreSQL ホスト (データベースノード) を設定します。
- 8
- 自動化ハブデータベースノードに使用する PostgreSQL ポートを設定します。
- 9
- PostgreSQL データベースのパスワードを設定します。
注記Ansible Automation Platform コントローラーのインストールに関するすべての情報が削除されました。
暗号化された認証情報を保存する credentials_ah.yml というラベルのファイルを作成します。
$ cat credentials_ah.yml
automationhub_admin_password: my_long_ahub_pw automationhub_pg_password: my_long_ahub_pw registry_password: my_long_registry_pw
ansible-vaultを使用して credentials_ah.yml ファイルを暗号化します。$ ansible-vault encrypt credentials_ah.yml
New Vault password: Confirm New Vault password: Encryption successful
警告暗号化された vault パスワードを安全な場所に保管します。
credentials_ah.yml ファイルが暗号化されていることを確認します。
$ cat credentials_ah.yml
$ANSIBLE_VAULT;1.1;AES256 36383639653562386534316333333961383336306465336465613831353435313530376464616539 3765393063303065323466663330646232363065316666310a373062303133376339633831303033 34313534383962613632303761636632623932653062343839613639653635643365616233313365 3636616639313864300a353239373433313339613465326339313035633565353464356538653631 63346434383534643237663862353361366632613634333231316334363939396461326561643336 3430633534303935646264633034383966336232303365383763
Ansible Automation Platform 2.1 をインストールするために
setup.shを実行し、credentials_ah.yml および --ask-vault-pass オプションを渡します。$ ANSIBLE_BECOME_METHOD='sudo' ANSIBLE_BECOME=True ANSIBLE_HOST_KEY_CHECKING=False ./setup.sh -e @credentials_ah.yml -- --ask-vault-pass
注記インストールを成功させるために、次の ANSIBLE*_ 変数が設定されています。
注記インベントリーファイルに設定できるさまざまな値の詳細は、インベントリーファイルの設定 を参照してください。
- プライベート自動化ハブダッシュボードにログインします (例: automationhub-cluster.site1.example.com)。
第9章 集中ロギング
ロギングについて考えるとき、ほとんどの人の頭にまず浮かぶのは、特定の問題をトラブルシューティングする能力です。テクノロジーが進化し続け、多くのアプリケーションが膨大な量のデータをキャプチャーするに伴い、ログはデータをキャプチャーするだけでなく、運用インテリジェンスメソッドの適用を可能にする上で重要なロールを果たします。
Ansible Automation Platform は、詳細なログを数種類のサードパーティー製外部ログ集約サービスに送信できるロギング機能を提供します。このデータフィードに接続されたサービスは、自動化コントローラーの使用や技術の傾向に関する洞察を得るための有用な手段として機能します。このデータを使用して、インフラストラクチャー内のイベントを分析し、異常をモニタリングし、あるサービスのイベントを別のサービスのイベントと関連付けることができます。
自動化コントローラーに最も役立つデータのタイプは、ジョブファクトデータ、ジョブイベント/ジョブ実行、アクティビティーストリームデータ、およびログメッセージです。データは、カスタムハンドラーで、またはインポートされたライブラリーを介して設計された最小限のサービス固有の調整を使用して、HTTP 接続を介して JSON 形式で送信されます。
現在、Ansible Automation Platform のログ機能は、Splunk、Logstash、Loggly、Sumologic と簡単に連携できるように設定されており、別のサードパーティーの外部ログ集約サービスを使用する場合は他の オプションを提供します。
このリファレンス環境の目的上、Splunk Enterprise 8.2.2 を使用して、両方の Ansible Automation Platform サイトに集中ログを設定することに重点を置いています。
Splunk Enterprise のインストールは、このリファレンスアーキテクチャーの範囲外です。詳細は、How to install Splunk Enterprise を参照してください。
9.1. Splunk HTTP イベントコレクター (HEC) の設定
HTTP イベントコレクターは、開発者がトークンベースの認証モデルを使用して、HTTP または HTTPS を介してアプリケーションイベントを Splunk プラットフォームに直接送信できるようにするエンドポイントです。
HEC を使用するための最初の手順は、Splunk デプロイメント内で HEC を有効にすることです。
Splunk 管理者として、以下を実行します。
- Splunk ダッシュボードにログインします。
- Settings → Data Inputs → HTTP Event Collector をクリックします。
- 右上隅にある Global Settings をクリックします。
- All Tokens トグルオプションで Enabled (デフォルト) を選択します。
-
すべての HEC トークンの Default Source Type を選択します (例:
_json)。 - Splunk デプロイメントで HTTPS を使用している場合は、Enable SSL をにチェックマークを付けます。
- HTTP Port Number を介して HTTP 入力専用のポートを設定します。デフォルトは 8088 です。
- Save をクリックします。
図9.1 グローバル設定
Splunk デプロイメントでポート 8088 (または割り当てられたポート) が開いていることを確認します。
Splunk デプロイメントで HEC を有効にして、Splunk での自動化コントローラー認証に使用される HEC トークンを生成します。
HTTP 経由でデータを受信するためにトークンを設定する方法は多くありますが、このリファレンス環境では以下の設定が使用されます。
HEC の詳細は、HTTP Event Collector を参照してください。
- Settings → Add Data をクリックします。
- ページ下部で Monitor を選択します。
- HTTP Event Collector をクリックします。
- Name フィールドにトークン名を入力します (例: AAP)。
- Source Type を Select に変更し、ドロップダウンに _json と入力します。
- Index 内で、ansible というラベルの付いたインデックスを作成します。
新しく作成したインデックスを選択したアイテムボックスに追加します。
右上隅にある Review をクリックします。
- Submit をクリックします。
作成されたトークン値は、Ansible Automation Platform で Splunk の認証に使用されるため保存します。
緑色の Start Search ボタンをクリックし、提供されたサンプルクエリーをコピーして後で使用できるようにします。
source="http:AAP" (index="ansible") sourcetype="_json"
9.2. Ansible Automation Platform 自動化コントローラーの設定
HEC を有効にして HEC トークンを作成すると、Splunk 環境は Ansible Automation Platform からイベントを受信する準備が整います。
最後の手順として、以下に示すとおり、集中ログに Splunk 環境を使用するために Ansible Automation Platform 化コントローラークラスターを設定します。
各 Ansible Automation Platform 環境で、以下を行います。
-
adminユーザーとして Ansible Automation Platform ダッシュボードにログインします。 - ページの一番下までスクロールして、Settings をクリックします。
System で、Logging settings を選択します。
Logging Aggregator 内で、ログの送信先となる場所を入力します。
この Splunk 環境では https://splunk.example.com:8088/services/collector/event を使用します。
注記デフォルトの 8088 を使用していない場合は、ロケーションプロトコル (HTTP/HTTPS) とポートを変更します。
- Logging Aggregator Type 内で、ドロップダウンから splunk を選択します。
- Logging Aggregator Password/Token 内で、以前に作成した HEC トークンをコピーして貼り付けます。
- Logging Aggregator Protocol 内で、ドロップダウンから HTTPS/HTTP を選択します。
- Logging Aggregator Level Threshold 内で、環境に適したログのレベルを選択します (例: INFO)。
図9.2 リファレンス環境のログ設定
上記の設定には、Splunk でロギングを実現するための最小値が含まれています。環境に最適になるようにログ設定を調整してください。
完了したら、サイト 2 でログ機能の設定を繰り返します。そうすることで、両方のサイトで確実に同じ集中型ロギング環境が使用されます。
9.3. Splunk に送信されたイベントの検証
最後に、Ansible Automation Platform イベントが Splunk に適切に送信されていることを確認します。これは、Ansible Automation Platform フヂ y じ化コントローラーを介したアドホックコマンドを実行して確認します。
Ansible Automation Platform ダッシュボード内で、以下を行います。
- Resources → Inventories で、Demo Inventory を選択します。
- Details で Hosts を選択します。
- Run Command ボタンをクリックします。
- Run command Details ウィンドウセクションで、ドロップダウンからモジュール ping を選択して Next をクリックします。
- Run command Execution Environment セクション内で、Default execution environment を選択して Next をクリックします。
- Run command Credential セクション内で、Demo Credential を選択して Next をクリックします。
- Run command Preview セクション内で、青い Launch ボタンをクリックします。
出力は次のようになります。
localhost | SUCCESS => {
"changed": false,
"ping": "pong"
}Splunk ダッシュボードに移動し、検索内で Ansible Automation Platform イベントが Splunk 内でトリガーされたか確認します。
検索では、次のような 1 つのイベントが表示されます。
Ansible Automation Platform のサイト設定ごとに、同じ検証プロセスを繰り返します。
第10章 複数の Ansible Automation Platform デプロイメントにおける設定の一貫性
10.1. Configuration as Code を使用する理由
これまで、複数の Ansible Automation Platform デプロイメントサイトで一貫性を維持する場合、データベースレプリケーションを使用して 1 つの Ansible Automation Platform 環境からデータをコピーし、そのデータを別の Ansible Automation Platform サイトにインポートする方法を考慮してきました。
これは、スクリプト、専用ソフトウェア、データベースの手動エクスポートを実行してから Ansible Automation Platform データベースを新しいサイトにインポートするか、同様のことを行うカスタム Ansible Playbook を実行することで達成できました。
多くの異なる方法がありますが、通常、これらの方法には不利な点があります。
たとえば、データベースレプリケーションにはストレージインフラストラクチャーへの投資が必要であり、適切な専門知識がなければ並行処理は難しい場合があります。
10.2. Configuration as Code とは
Configuration as Code は、リポジトリー内の設定ファイルを管理する方法として定義されています。Ansible Automation Platform の場合、これらの設定ファイルは、Ansible Automation Platform 環境全体に適用する設定を確立します。
Ansible Automation Platform 設定ファイルをコードとして保存および管理することで、以下が可能になります。
- すべての Ansible Automation Platform 環境に適用される設定を標準化する
- 設定のバージョン管理の利点を継承する
- 追加の Ansible Automation Platform デプロイメントを簡単にスケーリングして同じ設定を使用する
- 設設定の変更を簡単に追跡して、問題の修正を容易にする
Configuration as Code には、Ansible Automation Platform 環境全体に適用できる多くの利点とベストプラクティスがありますが、複数の Ansible Automation Platform サイトへの設定の配信をすぐに、一貫性を持って合理化および自動化するには、Configuration as Code ソリューションと Git Webhook をペアリングする必要があります。
10.3. Git Webhook とは
Git Webhook は、リポジトリーまたは組織で特定のアクションが発生するたびに通知を外部 Web サーバーに配信する方法として定義されています。
たとえば、リポジトリーが更新されると、CI ビルドをトリガーしたり、環境をデプロイしたり、この場合は設定を Ansible Automation Platform 環境に更新したりするイベントがトリガーされる可能性があります。
Configuration as Code および Git Webhook のソリューションを使用すると、すべてのプラットフォームの正確な設定と同時に、すべての Ansible Automation Platform サイトを即座に更新する Ansible Automation Platform ワークフローを設定できます。
事実上、データベースのバックアップを維持したり、高価なデータベースレプリケーションソリューションを有効にしたりするオーバーヘッドを排除しながら、これらのソリューションの長所を実現します。
この方法を念頭に置いて、次のセクションでは、管理者が Git Webhook を使用して複数の Ansible Automation Platform 環境間で一貫性を確保するために、Configuration as Code を利用する方法に焦点を当てます。
10.4. Webhook の使用
Webhook は、Web 上のアプリ間で指定されたコマンドを実行する機能を提供します。Ansible 自動化コントローラーは現在、GitHub および GitLab との Webhook インテグレーションを提供しています。このリファレンス環境では、GitHub を使用して自動化コントローラーで Webhook を設定する手順について説明します。
10.4.1. GitHub Webhook の設定
自動化コントローラーには、トリガーされた Webhook イベントに基づいてジョブを実行する機能があります。以下に、その設定手順を示しています。
GitHub パーソナルアクセストークンの作成
自動化コントローラーで使用するパーソナルアクセストークン (PAT) を生成します。
- GitHub アカウントのプロファイル設定で、Settings をクリックします。
Personal 設定の下の Developer Settings をクリックします。
- Developer 設定で Personal access tokens をクリックします。
- Personal アクセストークンの画面から、Generate new token ボタンをクリックします。
- プロンプトが表示されたら、GitHub アカウントのパスワードを入力して続行します。
- Note フィールドに、この PAT の用途に関する簡単な説明を入力します。
- Expiration ドロップダウンで、No expiration を選択します。
Scope フィールドでは、自動化コントローラー Webhook はリポジトリースコープへのアクセスのみ (ただし招待を除く) 必要とします。その他のスコープについては、表のすぐ上にあるリンクをクリックしてドキュメントにアクセスしてください。
ページの下部にある Generate Token ボタンをクリックします。
警告トークンが生成されたら、必ず PAT をコピーしてください。後の手順で Ansible Automation Platform 自動化コントローラークラスターが使用します。GitHub でこのトークンに再度アクセスすることはできなくなります。
GitHub リポジトリーの作成
PAT を配置したら、次の手順として、リポジトリーが変更されると GitHub Webhook によってトリガーされる Git リポジトリーを作成します。
自動化コントローラーの設定を簡単に更新または変更できるようにすることに重点が置かれているため、このリファレンス環境では redhat_cop.controller_configuration という名前の Ansible コレクションを利用します。
この Ansible コレクションを使用すると、コントローラーコレクションモジュールを使用し、Ansible ロールを介して Ansible コントローラーサーバーと簡単に対話できます。
このコレクションを使用することで、これらの既存のロールを使用して、すべてのサイトで自動化コントローラー環境を変更または更新できます。
redhat_cop.controller_configuration コレクションはコミュニティープロジェクトであり、Red Hat では正式にサポートされていません。
GitHub で、new repository を作成します。
適切な 所有者を選択し、リポジトリー名を指定します。
- このリファレンス環境では、リポジトリー名として aap_refarch を使用します。
- リポジトリーを説明するためのオプションの説明を提供します。
リポジトリーをパブリックまたはプライベートに設定します。
- このリファレンス環境では、リポジトリーをパブリックに設定します。
- Add a README file を使用してリポジトリーを初期化します。
- create repository ボタンをクリックします。
新しく作成された GitHub リポジトリー内に、3 つのファイルが作成されます。
- playbook.yml - 自動化コントローラーを更新または変更するためのすべての適切なロールを備えた Playbook。
- requirements.yml - Playbook の実行に必要なすべてのコレクションを備えた requirements.yml。
- group_vars/all.yml - 特定の設定 (ロール) 用に変更するすべての変数を含む all.yml ファイル。
これらの 3 つのファイルの目的は、group_vars/all.yml が変更されてリポジトリーに更新されたときに、Ansible Automation Platform 自動化コントローラークラスター内のジョブテンプレートを開始して、適切な変更または更新を行うメソッドを提供することです。
これらの 3 つのファイルのサンプルは、このガイドの 付録C 補足 セクションか、https://github.com/ansible/aap_refarch にあります。
Ansible Automation Platform 自動化コントローラークラスター内におけるリソース認証情報の設定
リポジトリーを Configuration as Code として使用する前に、Ansible Automation Platform サイト内に適切な認証情報リソースを設定します。
これにより、新しいプロジェクト、ワークフロー、およびジョブテンプレートが作成されたときに、それらのリソースに認証情報をかんたんに割り当てることができるようになります。
次の手順は、2 つの必須認証情報を作成する方法を示しています。
1 つは以前に作成した GitHub (PAT) トークンに関連付けられた認証情報です。
もう 1 つは、更新される Ansible Automation Platform サイトに関連付けらている認証情報です。各 Ansible Automation Platform サイトは、独自の環境によって更新されます。たとえば、サイト 1 はサイト 1 によって更新されます。
それぞれの Ansible Automation Platform サイトで、以下を実行します。
- Ansible Automation Platform 自動化コントローラーダッシュボードにログインします。
Resources→ Credentials で、青色の Add ボタンをクリックします。
- Name を入力します (例: GitHub PAT)。
- Credential Type として GitHub Personal Access Token を選択します。
- Type Details で、以前に GitHub から生成されたトークンを使用してシークレットを追加します。
Save をクリックします。
注記GitHub にポストバックするジョブテンプレートで使用するので、この認証情報の名前をメモしてください。
GitHub PAT ク認証情報セットを使用して、既存の Ansible Automation Platform 環境の用に 2 つめの認証情報を作成します。
Resources→ Credentials で、青色の Add ボタンをクリックします。
- Name を入力します (例: AAP_Site1)。
- Credential Type として Red Hat Ansible Automation Platform を入力します。
Type Details 内に、適切な詳細を追加します。
- Red Hat Ansible Automation Platform (例: controlplane-cluster.site1.example.com)
- Username (例: admin)
- Password (例: redhat)
- SSL 証明書が署名されている場合は、Options 内の Verify SSL を選択します。
- Save をクリックします。
Ansible Automation Platform サイト 2 でこのセクションを繰り返します。
このリファレンス環境はロードバランサーを利用するため、controlplane-cluster.site1.example.com が使用されます。ロードバランサーの設定は、このリファレンス環境の範囲外です。
Configuration as Code プロジェクトの作成
Configuration as Code プロジェクトの目的は、Configuration as Code リポジトリーが更新されるたびに自動的に実行されるジョブテンプレートを含むワークフローを作成することです。
これにより、変数の設定などの変更を行うときに、Git リポジトリー Playbook が多数の自動化コントローラー設定に対して適切なロールを実行することが保証されます。
このセクションでは、上記を実現するためのプロジェクト、ワークフロー、およびジョブテンプレートを作成します。
Ansible Automation Platform サイト 1 のダッシュボード内で以下を行います。
- Resources→ Projects で、青色の Add ボタンをクリックします。
- Name を指定します (例: Configuration as Code Project)。
- Organization として Default を選択します。
- Execution Environment として Default execution environment を選択します
- Source Control Credential Type として Select Git を選択します。
Type Details で、以下を実行します。
- Source Control URL (GitHub リポジトリー) を追加します。
Options 内で、以下を実行します。
- Clean、Delete、Update Revision on Launch を選択します。
- Save をクリックします。
次に、ワークフローテンプレートを作成します。
- Resources→ Templates で、青色の Add → Add workflow template をクリックします。
- Name を指定します (例: Configuration as Code Workflow)。
Options で、 Enable Webhook のチェックをオンにします。
- Webhook details 内で、Webhook Service として GitHub を選択します。
- Webhook details 内で、以前に作成した GitHub PAT トークンを Webhook Credential として選択します (例: GitHub PAT)。
- Save をクリックします。
- Please click the Start button to begin ウィンドウ内で、右上隅の Save をクリックします。
- 後で使用するため、Webhook URL と Webhook Key をコピーします。
Ansible Automation Platform サイト 2 で上記のプロセスを繰り返します。
リポジトリー用 GitHub Webhook の有効化
Ansible Automation Platform ワークフローテンプレートを作成し、必要なファイルを格納した GitHub リポジトリーを配置したら、次の手順としてリポジトリー用の Webhook (例: aap_refarch) を有効にします。
- GitHub リポジトリーのホームページで、Settings タブを選択します。
Settings タブで Webhooks を選択します。
- Webhooks セクションで、Add webhook ボタンを選択します。
- Payload URL (ワークフローの Webhook URL) を入力します。
- Content type ドロップダウンを application/json に変更します。
- Secret (ワークフローの Webhook キー) を入力します。
プッシュイベントを使用するようにデフォルトのままにして、Add webhook ボタンをクリックします。
警告デフォルトでは、GitHub はペイロードを配信するときに SSL 証明書を検証します。自動化コントローラーの SSL 証明書が署名されていない場合は、必ず SSL verfication を無効にしてください。
Ansible Automation Platform サイト 2 で上記のプロセスを繰り返します。
Configuration as Code ジョブテンプレートの作成
Configuration as Code プロジェクト用に作成されるジョブテンプレートは、Git リポジトリーが更新されるたびに playbook.yml ファイルを自動的に実行します。
これにより、設定の変更が必要になったときに、Ansible Automation Platform コントローラー API を使用して適切に変更することができます。すべての Ansible Automation Platform サイトで同じ方法を組み合わせると、設定されたサイト全体ですべての変更がグローバルになります。
- Resources→ Templates で、青色の Add → Add job template をクリックします。
- Name を指定します (例: Configuration as Code Job)。
- Job Type として Run を選択します。
- Inventory として Demo Inventory を選択します。
- Project として Configuration as Code Project を選択します。
- Execution Environment として Default execution environment を選択します
- Playbook として playbook.yml を選択します。
- Credentials を選択し、カテゴリーを Machine から Red Hat Ansible Automation Platform に切り替えます。
- Ansible Automation Platform サイトの適切な認証情報 (例: AAP_Site1) を選択します。
- Options で、 Enable webhook を選択します。
- Webhook Service として GitHub を選択します。
- 以前に作成した GitHub PAT トークンを Webhook Credential として選択します (例: GitHub PAT)。
- Save をクリックします。
Ansible Automation Platform サイト 2 で上記のプロセスを繰り返します。
作成した Configuration as Code ワークフローの更新
以前は、Configuration as Code ワークフローが作成されていました。このワークフローの目的は、Configuration as Code プロジェクトが常に同期され、リポジトリーに変更が加えられるたびに Configuration as Code ジョブが Configuration as Code Playbook を実行するように保証することです。
- Resources→ Templates で、テンプレートを選択します (例: Configuration as Code Workflow)。
- Details セクションで、 Visualizer タブを選択し、緑色の Start をクリックします。
- Node Type で Project Sync を選択し、適切なプロジェクト (例: Configuration as Code Project) を選択して Save をクリックします。
- Configuration as Code Project にカーソルを合わせ、プラス (+) 記号を選択します。
- Add Node ウィンドウで、このノードを実行するタイミングとして Always を選択し、Next をクリックします。
- Node Type として Configuration as Code Job を選択し、Save をクリックします。
- Visualizer に戻ったら、右上隅にある Save ボタンを選択します。
Configuration as Code 設定の検証
多くのロールがすでに redhat_cop.controller_configuration に含まれているため、group_vars/all.yml ファイルを適切な yaml で更新してユーザーを作成すると、すべてが期待どおりに機能しているかかんたんに検証できます。
ユーザーを作成する場合は、ユーザーロールのドキュメント で、使い捨ての変数をすべて詳しく確認します。
詳細を確認し、John という名前の非管理者ユーザーを作成すると次のようになります。
group_vars/all.yml
---
controller_user_accounts:
- user: "john"
is_superuser: false
password: "redhat"
上記の操作で group_vars/all.yml ファイルが更新され、Git リポジトリーにプッシュされると、Ansible Automation Platform 自動化コントローラー内のジョブが開始されます。
これは、自動化コントローラーダッシュボードの Views セクションで Jobs を選択すると確認できます。参照するジョブには、ジョブ番号の後にジョブ名を付ける必要があります。この参照環境では、TypePlaybook Run の 8-Configuration as Code Job に似たものが表示されます。
ジョブが完了すると、ステータスは Successful になります。
管理者としてログアウトし、パスワード redhat を使用して john というユーザーとして再ログインすると、ジョブが成功したことを確認できます。
この章の内容すべてに従い Ansible Automation Platform サイトごとに Webhook を適切に設定すると、対応する Ansible Automation Platform によってユーザー john が同時に作成されたことがわかります。
これは単純化された例ですが、Ansible Automation Platform 自動化コントローラーで許可されている設定 (ロール) の多くは、redhat_cop.controller_configuration 内に提供されています。
追加の例は、Example configs で見つけることができます。
Ansible コレクションには、多くの必要となる重要なロールがありますが、Ansible コレクション内にあるものだけに限定されるわけではありません。組織が新しいロールを実装または作成して、機能をさらに強化することもできます。
付録A 著者について
付録B コントリビューター
多くの時間を割いて、忍耐強くこのプロセスに協力してくださった次の方々に感謝申し上げます。その多大な貢献なしに、このドキュメントは実現しませんでした。
| コントリビューター | 役職 | 貢献内容 |
|---|---|---|
| Landon Holley | シニアコンサルティングアーキテクト | テクニカルレビュー |
| Ajay Chenampara | プリンシパルスペシャリストソリューションアーキテクト | テクニカルレビュー |
| Will Tome | プリンシパルスペシャリストソリューションアーキテクト | テクニカルレビュー |
| Sean Sullivan | シニアコンサルタント | テクニカルレビュー |
| Vinny Valdez | シニアマネージングアーキテクト | テクニカルレビュー |
| Chris Budzilowicz | プリンシパルテクニカルライター | コンテンツレビュー |
| Phil Avery | シニア Ansible スペシャリストソリューションアーキテクト | テクニカルレビュー |
付録C 補足
C.1. 自動化コントローラー Playbook の設定
---
- name: Playbook to configure ansible Controller post installation
hosts: localhost
connection: local
vars:
controller_validate_certs: false
collections:
- awx.awx
- redhat_cop.controller_configuration
roles:
- {role: settings, when: controller_settings is defined, tags: settings}
- {role: organizations, when: controller_organizations is defined, tags: organizations}
- {role: labels, when: controller_labels is defined, tags: labels}
- {role: users, when: controller_user_accounts is defined, tags: users}
- {role: teams, when: controller_teams is defined, tags: teams}
- {role: credential_types, when: controller_credential_types is defined, tags: credential_types}
- {role: credentials, when: controller_credentials is defined, tags: credentials}
- {role: credential_input_sources, when: controller_credential_input_sources is defined, tags: credential_input_sources}
- {role: notification_templates, when: controller_notifications is defined, tags: notification_templates}
- {role: projects, when: controller_projects is defined, tags: projects}
- {role: execution_environments, when: controller_execution_environments is defined, tags: execution_environments}
- {role: applications, when: controller_applications is defined, tags: applications}
- {role: inventories, when: controller_inventories is defined, tags: inventories}
- {role: instance_groups, when: controller_instance_groups is defined, tags: instance_groups}
- {role: project_update, when: controller_projects is defined, tags: projects}
- {role: inventory_sources, when: controller_inventory_sources is defined, tags: inventory_sources}
- {role: inventory_source_update, when: controller_inventory_sources is defined, tags: inventory_sources}
- {role: hosts, when: controller_hosts is defined, tags: hosts}
- {role: groups, when: controller_groups is defined, tags: inventories}
- {role: job_templates, when: controller_templates is defined, tags: job_templates}
- {role: workflow_job_templates, when: controller_workflows is defined, tags: workflow_job_templates}
- {role: schedules, when: controller_schedules is defined, tags: schedules}
- {role: roles, when: controller_roles is defined, tags: roles}C.2. 自動化コントローラー設定用の group_vars/all.yml vars ファイル (ユーザー作成サンプル)
---
controller_user_accounts:
- user: "colin"
is_superuser: false
password: "redhat"C.3. 自動化コントローラー設定用の requirements.yml
collections: - name: redhat_cop.controller_configuration - name: awx.awx
付録D サブスクリプションマニフェストの生成
サブスクリプションマニフェストを正常に生成するには、以下を実行します。
- access.redhat.com にログインし、左上隅にある Subscriptions をクリックします。
- Subscriptions Allocations タブを選択します。
New Subscription Allocation のラベルが付いたボタンを選択します。
Create a New subscription allocation ページで、Name を入力し、Type のドロップダウンボックスから Subscription Asset Manager 1.4 を選択して Create をクリックします。
- 作成したら、Subscriptions タブを選択し、Ansible Automation Platform サブスクリプションと提供するエンタイトルメントの数を選択します。
Details タブをクリックし、エンタイトルメントの数が正しいことを確認してから Export Manifest ボタンを選択します。
Ansible Automation Platform ダッシュボードに戻り、manifest.zip をインポートして Next をクリックします。
- (推奨) Red Hat または Red Hat Satellite の認証情報を提供し、Next をクリックして、Ansible Automation Platform のユーザー分析とインサイトを有効にします。
- エンドユーザー使用許諾契約に同意します。
付録E 参考資料
- Red Hat Ansible Automation Platform Installation Guide
- Aggregating Ansible Tower logs to Splunk by Joseph Tejal
- Centralize your Automation Logs with Ansible Tower and Splunk Enterprise by Leonardo Araujo
- Tower Logging and Aggregation
- Set up and use HTTP Event Collector in Splunk Web
- Splunk - Managing Indexers and Clusters of Indexers
- Fun with Private Automation Hub by Daniel Leroux
- Fun with Private Automation Hub Part II by Daniel Leroux
- Automation Controller Workflow Deployment as Code by Sean Sullivan
付録F Revision History
| 改訂履歴 | ||
|---|---|---|
| 改訂 1.2-0 | 2022-05-03 | Anshul Behl,Roger Lopez |
| ||
| 改訂 1.1-0 | 2022-04-11 | Roger Lopez |
| ||
| 改訂 1.0-0 | 2021-12-02 | Roger Lopez |
| ||
