本ガイドは、できるだけ早く Ansible Automation Platform のインストールと設定を行う際に役立ちます。
インストールの完了後に、Web ブラウザーを使用して、Automation Platform にアクセスして、すべての機能を利用することができます。
本ガイドは基本事項を対象としていますが、より詳しい情報が必要な場合には、『Installation and Reference Guide』を参照してください。
「General Installation Notes」を参照してから、インストールを開始してください。
プラットフォームの情報は、「プラットフォーム固有のインストールに関する注意点」を参照してください。
注釈
Tower は総合的なアプリケーションで、インストールプロセスでは PostgreSQL、Django、NGINX など、複数の依存関係をインストールします。スタンドアロンの仮想マシンまたはクラウドインスタンスに Tower をインストールし、そのマシンに別のアプリケーションを共存させることはできません (モニタリングまたはロギングソフトウェア以外)。Tower および Ansible は Python で記述されていますが、単純な Python ライブラリーではありません。そのため、Tower は Python virtualenv や類似したサブシステムにはインストールできません。本ガイドのインストールの方法に記載されているようにインストールする必要があります。OpenShift ベースのデプロイメントについては、「OpenShift Deployment and Configuration」を参照してください。
Ansible Tower には以下の要件があります。
|at|3.8 以降、|aap| をインストールする前に有効なサブスクリプションを割り当てる 必要があります。詳細は サブスクリプションの割り当て を参照してください。
サポート対象のオペレーティングシステム:
Red Hat Enterprise Linux 8.2 以降 64 ビット (x86)
Red Hat Enterprise Linux 7.7 以降 64 ビット (x86)
CentOS 7.7 以降 64 ビット (x86)
注釈
Automation Hub の場合は、バージョンが 3.13.1-268 以上の selinux-policy パッケージが必要です。
注釈
Ansible Tower の次のメジャーリリースでは、Red Hat Enterprise Linux 7 または CentOS (任意のバージョン) はインストールプラットフォームとしてサポートされません。
Mozilla Firefox または Google Chrome の現行のサポートバージョン
その他の HTML 5 準拠の Web ブラウザーは機能する場合がありますが、完全にテストまたはサポートされていません。
2 CPUs minimum for Automation Platform installations. Refer to the capacity algorithm section of the Ansible Tower User Guide for determining the CPU capacity required for the number of forks in your particular configuration.
最小 4 GB のメモリー *(Automation Platform のインストール)
4 GB のメモリー (Vagrant 試用版のインストールには推奨最小要件)
4 GB メモリー (外部のスタンドアロン PostgreSQL データベースには最小要件)
固有のメモリー要件については、Ansible Tower User Guide の「capacity algorithm」セクションを参照して、特定の設定で、フォーク数に必要とされる容量を判断してください。
Tower サービスモード専用の ハードディスク容量 20 GB
要件 20 GB 中で
/var/専用に 10 GB 分割り当てる必要があります。/var/ は Tower がファイルおよび作業ディレクトリーを保存する場所です。ストレージボリュームは、最低ベースラインとして IOPS が 750 となるようにする必要があります。
データベースを含むノード専用の ハードディスク容量 20 GB (150 GB 以上を推奨)
ストレージボリュームは、ベースライン IOPS (1000 以上) を高くする必要があります。
Tower データはすべてデータベースに格納されます。データベースストレージは、管理するホスト、実行するジョブ数、ファクトキャッシュに保存するファクト数、個別ジョブのタスク数に合わせて増加します。たとえば、ホスト 250 台とタスク 20 件に対して 1 時間毎 (1 日に 24 回) に実行される Playbook は毎週データベースに 80 万件以上のイベントを保存します。
データベースに十分な容量が確保されていない場合には、以前のジョブ実行やファクトを定期的に消去する必要があります。詳しい情報は、Ansible Tower Administration Guide の「Management Jobs」を参照してください。
64 ビットのサポートが必要 (カーネルとランタイム)
Ansible Tower 3.7 以降を実行するには、PostgreSQL バージョン 10 が必要です。バックアップと復元は、現在の Ansible Tower バージョンでサポートされている PostgreSQL バージョンで のみ 機能します。
Ansible Tower バージョン 3.8 以降を実行するには Ansible バージョン 2.9 が必要
注釈
上記に指定した PostgreSQL のバージョンと Ansible のバージョンよりも古いバージョンを使用して、Ansible Tower 3.7 以降を実行することはできません。PostgresSQL も Ansible も存在しない場合は、インストールスクリプトによりインストールされます。
オートメーションハブの場合: Ansible Tower 3.8 以降、Automation Hub は、Ansible Tower のコンテンツプロバイダーとして機能します。これには、Ansible Tower デプロイメントと Automation Hub デプロイメントがともに実行している必要があります。Tower および Automation Hub は、RHEL 7 または 8 のいずれかで実行できますが、(Automation Hub ではなく) Tower のみが、OpenShift Container Platform (OCP) でサポートされています。
Amazon EC2 の場合:
インスタンスのサイズは m4.large 以上
ホスト 100 台以上ある場合には m4.xlarge 以上
他のオペレーティングシステムは技術的に機能する場合がありますが、現在 Automation Platform インストールのホストをサポートするのは上記の一覧のみです。サポートのないオペレーティングシステムで Tower を実行するという確実な要件がある場合には Red Hat カスタマーポータル (https://access.redhat.com/) 経由で Ansible までお問い合わせください。他のオペレーティングシステム (ノード) の管理は、Ansible プロジェクト自体に文書でまとめられており、リストに追加することも可能です。
実際のメモリー要件は Tower が同時に管理するホスト数により異なります (これはジョブテンプレートまたはシステムの ansible.cfg ファイルの forks パラメーターにより制御されています)。発生する可能性のあるリソースの競合を回避するには、Ansible はフォーク 10 ごとにメモリーを 1 GB、さらに Tower 用に + 2GB 分搭載することを推奨しています。詳細は「capacity algorithm」を参照してください。forks を 400 に設定した場合には、メモリーを 40 GB 搭載することを推奨します。
Ansible Tower をインストールするホストでは、Tower により、umask が 0022 に設定されているかどうかが確認されます。設定に失敗する場合は、umask=0022 に設定してこのエラーが発生しないようにしてください。
当然、より多くのホストに対応できますが、フォーク数がホストの総数より少ない場合は、ホスト間により多くのパスが必要です。設定を要求する各システムがキューに入り、できるだけ早く処理されるか、あるいは Tower が AMI などのイメージを作成またはデプロイする場合など、定期的な更新の使用、または Tower に含まれるプロビジョニングコールバックシステムを使用して、このようなメモリーの制限を回避することができます。これらすべては、大規模な環境を管理する優れたアプローチです。他に質問がある場合には、Red Hat カスタマーポータル (https://access.redhat.com) 経由で Ansible までお問い合わせください。
Ansible Automation Platform が管理するシステムの要件は Ansible と同じです (http://docs.ansible.com/intro_getting_started.html)。
Automation Platform では、PostgreSQL 10 を使用します。PostgreSQL 10 は、RHEL 7 の SCL パッケージから、また、RHEL 8 のアプリケーションストリームから取得できます。PostgreSQL 10 へのアップグレード時には注意する必要のある変更点は以下のとおりです。
PostgreSQL ユーザーパスワードは、データベースに保存する前に SCRAM-SHA-256 のセキュアハッシュアルゴリズムでハッシュ化されます。
PostgreSQL 10 ではユーザーのパスワードをより安全に保存できるようになったため、インストール時にインベントリーファイルに pg_hashed_password を指定する必要はなくなりました。インストーラー用にインベントリーファイルでユーザーのパスワードを指定する (pg_password) 場合には、PostgreSQL がインストールプロセスの一部として、このパスワードを SCRAM-SHA-256 でハッシュ化します。セットアップが失敗する場合があるため、pg_password で特殊文字を 使用しないでください。
Ansible Tower および Automation Hub は、3.8 の PostgreSQL のソフトウェアコレクションバージョンを使用しているため、rh-postgresql10 scl を有効にしてデータベースにアクセスできるようにする必要があります。管理者は awx-manage dbshell コマンドを使用して、PostgreSQL SCL を自動的に有効にできます。
Tower インスタンスがデータベースにアクセスできるかどうかを判断する必要がある場合は、awx-manage check_db のコマンドで確認できます。
必要に応じて、Automation Platform インストーラーで管理されないように、個別ノードとして PostgreSQL データベースを設定することもできます。Automation Platform インストーラーがデータベースサーバーを管理する場合は、大半のワークロード向けに一般的に推奨されているデフォルト値を使用して、サーバーを設定します。ただし、スタンドアロンのデータベースサーバーノードについては、この PostgreSQL 設定を調整することができます。ansible_memtotal_mb は、データベースサーバーの合計メモリーサイズに置き換えてください。
max_connections == 1024
shared_buffers == ansible_memtotal_mb*0.3
work_mem == ansible_memtotal_mb*0.03
maintenance_work_mem == ansible_memtotal_mb*0.04
「tuning your PostgreSQL server」の詳細は、「PostgreSQL documentation 」を参照してください。
Automation Platform は Ansible Playbook に依存しており、インストール前に Ansible の最新安定版をインストールする必要がありますが、手動で Ansible をインストールする必要はなくなりました。
Upon new installations, Tower installs the latest release package of Ansible 2.9.
バンドルの Automation Platform インストールを実行する場合は、インストールプログラムにより、バンドルから Ansible およびその依存関係のインストールが試行されます (詳しい情報は「バンドルの Ansible Automation Platform インストーラーの使用」を参照してください)。
Ansible をご自身でインストールすることを選択すると、Ansible がインストールされていることを Automation Platform インストールプログラムが検出して、再インストールを行わないようにします。Automation Platform が正しく機能するようにするには、yum などのパッケージマネージャーを使用して Ansible をインストールし、最新安定版をインストールする必要がある点に注意してください。Ansible Tower バージョン 3.8 以降には、Ansible バージョン 2.9 以降が必要です。
便宜上、これらの説明は以下で簡単にまとめています。
Ansible Automation Platform は、留意すべき制限事項がいくつかありますが、FIPS モードが有効なシステムで実行できます。
Enterprise Linux 7 以降のみがサポートされています。Ansible Tower を FIPS モードで機能させるには、RHEL に同梱されている標準の Python を使用する必要があります。標準以外の Python を使用すると、Tower のシステム以外の Python もサポートされません。
デフォルトでは、Tower はパスワードベースの認証を使用して PostgreSQL を設定します。インストール時に CREATE USER を実行している場合は、このプロセスに md5 を使用している必要があります。FIPS 対応システムから Tower インストーラーを実行するには、インベントリーファイルで pg_password を指定します。セットアップが失敗する場合があるため、pg_password で特殊文字を 使用しないでください。
pg_password='choose-a-password'
詳細については、「setup_inventory_file」を参照してください。
インストーラーのインベントリーファイルでパスワードを指定した場合 (pg_password) に、このパスワードは、インストールプロセスの一部として PostgreSQL により SCRAM-SHA-256 にハッシュ化されます。
ssh-keygen コマンドは、RFC4716 形式のキーを生成し、プロセスの特定の時点で (入力したパスフレーズに実行する変換の一部として) md5 ダイジェストアルゴリズムを使用します。FIPS が有効なシステムでは md5 が完全に無効になっているので、このタイプの暗号化された SSH キー (パスフレーズで保護されている RFC4716 プライベートキー) は使用できません。FIPS モードが有効な場合には、Ansible Tower にインポートする暗号化された SSH キーは、 PKCS8 形式のキーを 使用する必要があります。既存の AES128 キーは、以下の openssl コマンドを使用して PKCS8 に変換できます:
$ openssl pkcs8 -topk8 -v2 aes128 -in <INPUT_KEY> -out <NEW_OUTPUT_KEY>
詳細は: https://access.redhat.com/solutions/1519083 を参照してください。
paramiko ライブラリーを使用する Ansible 機能を使用すると、FIPS に準拠しなくなります。たとえば、トランスポートとしての ansible_connection=paramiko の設定や ncclient NETCONF ライブラリーを使用するネットワークモジュールの使用などです。
TACACS+ プロトコルは md5 を使用して認証パケットのコンテンツを難読化します。FIPS モードが有効なシステムでは、「TACACS+ Authentication」はサポートされません。
RADIUS プロトコルは、md5 を使用して Access-Request クエリーのパスワードを暗号化します。「RADIUS Authentication」は、FIPS モードが有効なシステムではサポートされません。
PackageKit は頻繁に、インストール/更新メカニズムを干渉する可能性があります。設定プロセスの実行前にインストールする場合は、PackageKit を無効または削除することを検討してください。
"targeted" の SELinux ポリシーのみがサポートされます。targeted ポリシーは、disabled、permissive または enforcing に設定可能です。
バンドルインストールを行う場合の詳細は、「バンドルの Ansible Automation Platform インストーラーの使用」を参照してください。
Ansible Tower のインストール時には、setup.sh のみを実行するだけで結構です。Tower で必要なリポジトリーは自動的にインストールされます。
設定プロセス時に、最新版の Ansible が自動的にインストールされ、追加のインストールや設定は必要ありません。
Ansible Tower では、Ubuntu のサポートがなくなりました。Ubuntu の詳細は、以前のバージョンの Ansible Automation Platform Installation and Reference Guide を参照してください。
OpenShift ベースのデプロイメントについては、「OpenShift Deployment and Configuration」を参照してください。
Ansible Automation Platform は、以下のシナリオのいずれかを使用してインストールすることができます。
単一マシン:
Tower または非インストーラー管理データベースと同じノード上にデータベースがあるスタンドアロン Tower。これは Tower を単一のマシンにインストールしたものです。Web フロントエンド、REST API バックエンド、データベースがすべて単一のマシンに含まれています。これは、Tower の標準インストールです。また、お使いの OS ベンダーリポジトリーから PostgreSQL もインストールされ、Tower サービスがデータベースとして使用するように設定されます。
[tower]
host
外部管理データベースを備えたスタンドアロン Tower。この構成では、単一マシンに Tower サーバーをインストールし、Tower のデータベースとして、PostgreSQL 10 のリモートのインスタンスと対話するように設定します。このリモートの PostgreSQL には自身で管理するサーバーを使用することも、Amazon RDS などのクラウドサービスで提供することも可能です。
[tower]
host
[database]
host2
Automation Hub または非インストーラー管理データベースと同じノードにあるデータベース付きのスタンドアロン Automation Hub:
[automationhub]
host
外部管理データベースを使用するスタンドアロン Automation Hub: この構成では、単一のマシンに Automation Hub サーバーをインストールし、(Automation Platform インストーラーが管理する) Playbook インストーラーでリモートの PostgreSQL データベースをインストールします。
[automationhub]
host
[database]
host2
プラットフォームのインストール:
プラットフォームのインストールには Tower と Automation Hub が関与します。Platform インストーラーを使用すると、インベントリーごとに Automation Hub を 1 つだけデプロイできます。インストーラーを Automation Hub スタンドアロンインストーラーとして使用し、複数の Automation Hub ノードをデプロイする場合は、インストーラーを任意の数の異なるインベントリーで何度でも実行できます。プラットフォームインストールでサポートされている 2 つのオプションは次のとおりです。
Tower とまたは非インストーラー管理データベースと同じノード上のデータベースを使用するプラットフォーム (タワー + Automation Hub):
[tower]
host1
[automationhub]
host2
外部管理データベースを使用するプラットフォーム (Tower + Automation Hub) の場合:
[tower]
host1
[automationhub]
host2
[database]
host3
マルチマシンクラスター
このシナリオには、外部管理データベースを使用したプラットフォーム (クラスター化されたタワー + Automation Hub) インストールに関与します。このモードでは、複数の Tower ノードがインストールされてアクティブになります。すべてのノードが HTTP リクエストを受け取れるようになり、すべてのノードがジョブを実行できます。これにより、プラットフォームサーバーが単一のマシンにインストールされ、データベースとして PostgreSQL のリモートインスタンスと対話するように構成されます。このリモート PostgreSQL は、管理するサーバーにすることも、Amazon RDS などのクラウドサービスによって提供することもできます。
[tower]
host1
host11
host12
[automationhub]
host2
[database]
host3
注釈
クラスター設定で実行するには、Tower は外部のデータベースを使用する必要があります。PostgreSQL はプライマリーまたはセカンダリーの Tower ノードではないマシンにインストールする必要があります。冗長設定の場合の要件として、リモートの PostgreSQL バージョンは PostgreSQL 10 でなければなりません。
クラスター化の設定に関する情報は、「クラスタリング」を参照してください。
注釈
1). Tower will not configure replication or failover for the database that it uses, although Tower should work with any replication that you have. 2). The database server should be on the same network or in the same datacenter as the Tower server for performance reasons. 3). Tower and Automation Hub can not run on the same node, this is a scenario that is not supported. It means that any deployment of the Platform becomes at least a 2-node deployment topology.
Automation Platform インストールに利用可能な設定:
automationhub_importer_settings: galaxy-importer に渡す設定/構成のディクショナリー。これは、最終的に /etc/galaxy-importer/galaxy-importer.cfg に保存されます。
automationhub_require_content_approval: コレクションが利用可能になる前に、Automation Hub が承認メカニズムを実施するかどうか。
automationhub_disable_https: TLS を有効にして Automation Hub をデプロイする必要があるかどうか。
automationhub_disable_hsts: Transport Security (HSTS) Web セキュリティーポリシーメカニズムを有効にして Automation Hub をデプロイする必要があるかどうか。
automationhub_ssl_validate_certs: Platform は、デフォルトで自己署名証明書を使用してデプロイするため、Automation Hub は、自身を要求するときに証明書を検証する必要があるかどうか (デフォルト= False)。
automationhub_ssl_cert: web_server_ssl_cert と同じですが、Automation Hub の UI および API で使用。
automationhub_ssl_key: web_server_ssl_key と同じですが、Automation Hub の UI および API で使用。
automationhub_backup_collections: Automation Hub は /var/lib/pulp にアーティファクトを提供します。デフォルトでは、これは true に設定されています。そのため、Tower はデフォルトでアーティファクトを自動的にバックアップします。パーティション (LVM、NFS、CephFS など) がそこにマウントされている場合、企業組織はそれが常にバックアップされることを保証します。この場合は、automationhub_backup_collections = false を設定して、バックアップ/復元プロセスで /var/lib/pulp をバックアップ/復元する必要はありません。
OpenShift ベースのデプロイメントについては、「OpenShift Deployment and Configuration」を参照してください。