3. インストール時の一般的な注意点¶

Ansible Tower および Automation Hub は、Ansible Automation Platform と呼ばれる統一されたプラットフォーム体験を提供するために統合されました。Ansible Tower 3.8 以降では、これまで Tower インストーラーだったものが、Automation Platform をまとめてインストールできるようになりました。詳細は Ansible Automation Platform のインストールを参照してください。

Automation Platform には Ansible2.9 が**必要です**。Ansible 2.9.x は、Tower3.8 にインストールできる唯一のサポート対象バージョンになります。
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) でサポートされています。
Ansible Tower 3.8 以降、Ansible Automation Platform のインストールと実行の前に有効なサブスクリプションがアタッチされている**必要があります**。**以前のバージョンから有効なライセンスをお持ちの場合でも、Tower 3.8 にアップグレードする際に、認証情報またはサブスクリプションマニフェストを再度提供する必要があります。有効なサブスクリプトは、Automation Hub ノードにだけ添付する必要があります。その他のノードには、有効なサブスクリプションやプールを割り当てる必要はありません。詳細は、「サブスクリプションの割り当て」を参照してください。
Satellite の背後で Tower をインストールする場合は、Satellite インスタンスに固有の Katello RPM をインストールして Tower ノードを準備します。詳細は、Tower への Satellite インスタンスのインストールを参照してください。
インベントリーソースに新規に作成された設定には、デフォルトのプラグイン設定値が含まれます。3.8 で新たに作成されたインベントリーソースを 3.7 ソースの出力に一致させるには、そのソースに特定の設定値セットを適用する必要があります。後方互換性を確保するために、Tower はこれらのソースごとに「テンプレート」を使用して、インベントリープラグインの出力をレガシー形式で使用します。新しいスタイルインベントリープラグインの出力に移行するのに役立つ各ソースおよびそのテンプレートについては、Ansible Automation Platform Installation and Reference Guide のサポートされているインベントリープラグインテンプレートを参照してください。
HTTP プロキシーにアクセスして OS ベンダーからのソフトウェアをインストールする必要がある場合には、setup.sh を実行する前に環境変数「HTTP_PROXY」が適切に設定されていることを確認してください。
Tower インストーラーは、HTTPS 通信ができるように自己署名の SSL 証明書と鍵ファイルを /etc/tower/tower.cert と /etc/tower/tower.key に作成します。これらは、インストール後に任意で独自のカスタム SSL 証明書と置き換えることができますが、ファイル名は同じままにしておく必要があります。「カスタム証明書の使用」を参照してください。
Ansible Automation Platform をインストールすると、自動的に、Tower ユーザーインターフェースの実行に必要な Node.js のバージョンがインストールされます。
Ansible バージョン 1.8 以降を使用する場合には、Tower マシンの ansible.cfg で、Redis を使用したファクトキャッシュが無効になっていることを確認してください。
Tower は、Ansible のソフトウェアリポジトリーや OS ベンダーのソフトウェアリポジトリーなど、信頼済みのサードパーティーが提供するソフトウェアをインストールできるようにインターネット接続のあるマシンからインストールを行う必要があります。場合によっては、Python Package Index (PyPI) にアクセスする必要があります。インターネット接続のない環境でインストールする必要がある場合は、バンドルのインストールプログラムは推奨のソリューションではありません (「バンドルの Ansible Automation Platform インストーラーの使用」参照)。Red Hat カスタマーポータル (https://access.redhat.com/) 経由で Ansible までお問い合せください。
OpenShift に Tower をインストールする場合は、「OpenShift Deployment and Configuration」を参照してください。

3.1. Tower で指定するフラグおよび追加の変数¶

Ansible Tower インストーラーで使用可能なフラグや追加の変数には以下が含まれます (ただし、以下に限定されません)。

Usage: setup.sh [Options] [-- Ansible Options]

Options:
  -i INVENTORY_FILE     Path to ansible inventory file (default: inventory)
  -e EXTRA_VARS         Set additional ansible variables as key=value or YAML/JSON
                        i.e. -e bundle_install=false will force an online install

  -b                    Perform a database backup in lieu of installing
  -r                    Perform a database restore in lieu of installing
  -k                    Generate and distribute a new SECRET_KEY

  -h                    Show this help message and exit

Ansible Options:
  Additional options to be passed to ansible-playbook can be added following the -- separator

-- の区切り文字を使用して、適用する Ansible 引数を追加します。例: ./setup.sh -i my_awesome_inventory.yml -e matburt_is_country_gold=True -- -K

以下の表では、Tower のインストール中に使用可能な追加変数を紹介します。

変数	説明	デフォルト
`upgrade_ansible_with_tower`	Tower のインストール時には、Ansible が最新の状態であることを確認します。	`False`
`create_preload_data`	Tower のインストール時に、デモ組織、プロジェクト、認証情報、ジョブテンプレートなども作成します。	`True`
`bundle_install_folder`	バンドルからインストールする場合に、バンドルされているリポジトリーを配置する場所	`/var/lib/tower-bundle`
`nginx_disable_https`	nginx で HTTPS トラフィックを無効にします。HTTPS の負荷をロードバランサーに分散する場合に便利です。	`False`
`nginx_disable_hsts`	Web セキュリティーポリシーメカニズム HSTS の無効化	`False`
`nginx_http_port`	nginx が HTTP をリッスンするように設定するポート	`80`
`nginx_https_port`	nginx が HTTPS をリッスンするように設定するポート	`443`
`backup_dest`	setup.sh -b からのバックアップを配置する場所	`{{ playbook_dir }}`
`backup_dir`	バックアップ時に使用する一時的な場所	`/var/backups/tower/`
`restore_backup_file`	復元元として使用する別のバックアップファイルを指定します。	(なし)
`required_ram`	Tower のインストールに必要な最小メモリー (テストインストール時のみ変更してください)	`3750`
`min_open_fds`	表示ファイルの説明に使用できる最小リソース (テストインストール時のみ変更してください)	`4096`
`ignore_preflight_errors`	プリフライトチェックを無視します。これはテンプレートや他のシステム以外のイメージにインストールするときに便利です (`required_ram` と `min_open_fds` をオーバーライドします)	`False`

3.1.1. 例¶

以下は一般的なシナリオ例です。個別のケースに適した値を指定するようにしてください。

**コアをアップグレードする方法*:

./setup.sh -e upgrade_ansible_with_tower=1

nginx で処理する https を無効化する方法:
```
./setup.sh -e nginx_disable_https=true
```
バックアップファイルから復元時にデフォルトではないパスを指定する方法:
```
./setup.sh -e 'restore_backup_file=/path/to/nondefault/location' -r
```
設定スクリプトに引数として渡すことで使用したインベントリーファイルを上書きする方法:
```
setup.sh -i <inventory file>
```

3.1.2. カスタム証明書の使用¶

デフォルトのインストールで独自の証明書を使用できるため、提供されている自己署名証明書は使用しないでください。Ansible Tower インストーラーは、タワーのデプロイメントを TLS 単位で構成できるようにする 3 つの変数を提供します。

`web_server_ssl_cert`	Tower Web サーバーが提供するカスタム証明書へのインストーラーノード上のパス。インストール時と同じように `/etc/tower/tower.cert` にコピーされます。
`web_server_ssl_key`	インストーラーノード上の、証明書が生成された秘密鍵へのパス。インストール時と同じように `/etc/tower/tower.key` にコピーされます。
`custom_ca_cert`	システムバンドルに信頼できるものとして追加するカスタム認証局。Tower CA 信頼ストアに読み込まれます。

3.2. インストールに関する追加のヒント¶

Websocket 設定を nginx/ロードバランサー設定に合わせるために、Ansible Tower のインストールの一部としてプロキシーおよび Websockets を設定する方法を検討してください。詳細は、本ガイドの「プロキシーのサポート」セクションを参照してください。

3.2.1. プラットフォーム固有のインストールに関する注意点¶

3.2.1.1. FIPS モードが有効になっているシステムへの Automation Platform のインストール¶

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'
```
詳細については、「インベントリーファイルの設定」を参照してください。

インストーラーのインベントリーファイルでパスワードを指定した場合 (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 モードが有効なシステムではサポートされません。

3.2.1.2. Red Hat Enterprise Linux と CentOS の設定に関する注意事項¶

PackageKit は頻繁に、インストール/更新メカニズムを干渉する可能性があります。設定プロセスの実行前にインストールする場合は、PackageKit を無効または削除することを検討してください。
"targeted" の SELinux ポリシーのみがサポートされます。targeted ポリシーは、disabled、permissive または enforcing に設定可能です。
バンドルインストールを行う場合の詳細は、「バンドルの Ansible Automation Platform インストーラーの使用」を参照してください。
Ansible Tower のインストール時には、setup.sh のみを実行するだけで結構です。Tower で必要なリポジトリーは自動的にインストールされます。
設定プロセス時に、最新版の Ansible が自動的にインストールされ、追加のインストールや設定は必要ありません。

3.2.1.3. Ubuntu の設定に関する注意¶

Ansible Tower では、Ubuntu のサポートがなくなりました。Ubuntu の詳細は、以前のバージョンの Ansible Automation Platform Installation and Reference Guide を参照してください。

3.2.1.4. OpenShift での設定およびインストール¶

OpenShift ベースのデプロイメントについては、「OpenShift Deployment and Configuration」を参照してください。

3.2.1.5. Tower への Satellite インスタンスのインストール¶

Satellite ユーザーは、Tower をインストールする前に、Towerノードに Satellite インスタンスの Katello RPM をインストールする必要があります。この RPM は、Satellite をコンテンツソースとして使用するように Subscription Manager を自動的に設定し、/etc/rhsm/rhsm.conf の hostname 値が更新されます。

注釈

Tower をインストールした後に Katello RPM をインストールする場合は、Tower には rhsm.conf へのアクセスがありません。これは、Satellite からサブスクリプションを適用するのに使用します。これは、Tower インストーラーが rhsm.conf ファイルに ACL ルールを設定するためです。そのため、このファイルが存在しない場合、サブスクリプションは適用できず、後で上書きされるか、ユーザーがファイルにアクセスする適切なパーミッションがありません。

Satellite サーバーにホストを登録する方法は、Satellite ドキュメントの「Registration」セクションを参照してください。