1. Tower インストールの準備¶

1.1. インストールおよびリファレンスガイド¶

本ガイドは基本事項を対象としていますが、より詳しい情報が必要な場合には、『Installation and Reference Guide』を参照してください。

「General Installation Notes 」を参照してから、インストールを開始してください。

1.2. 前提条件および要件¶

プラットフォームの情報については、『 Ansible Tower Installation and Reference Guide 』の「ir_install_notes_reqs」を参照してください。

Ansible Tower には以下の要件があります。

• サポート対象のオペレーティングシステム:

  • Red Hat Enterprise Linux 8.0 以降 64 ビット (Ansible Tower 3.5 以降のバージョンのみインストール可能)

  • Red Hat Enterprise Linux 7.4 以降 64 ビット

  • CentOS 7.4 以降 64 ビット

  • Ubuntu 16.04 LTS 64 ビット (Ubuntu のサポートは非推奨になり、今後のリリースで削除予定です)

• Mozilla Firefox または Google Chrome の現行のサポートバージョン

  • その他の HTML 5 準拠の Web ブラウザーは機能する場合がありますが、完全にテストまたはサポートされていません。

• Tower のインストールには、最低でも CPU が 2 つ 必要です。特定の設定でのフォーク数に必要とされる CPU の容量を判断するには、『 Ansible Tower User Guide 』の「capacity algorithm」のセクションを参照してください。

• 最小 4 GB のメモリー *(Tower のインストール)

  • 4 GB のメモリー (Vagrant 試用版のインストールには推奨最小要件)

  • 4 GB メモリー (外部のスタンドアロン Postgres データベースには最小要件)

  • 固有のメモリー要件については、『 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 User Guide 』の「Management Jobs」を参照してください。

• 64 ビットのサポートが必要 (カーネルとランタイム)

• ** Ansible Tower 3.2 以降を実行するには PostgreSQL バージョン 9.6.X が必要**

• ** Ansible Tower バージョン 3.2 以降を実行するには (最低でも) Ansible バージョン 2.2 が必要**

• Amazon EC2 の場合:

  • インスタンスのサイズは m4.large 以上

  • ホスト 100 台以上ある場合には m4.xlarge 以上

1.3. Tower の要件に関する追加の注意点¶

他のオペレーティングシステムは技術的に機能する場合がありますが、現在 Ansible Tower インストールのホストをサポートするのは上記の一覧のみです。サポートのないオペレーティングシステムで Tower を実行するという確実な要件がある場合には Red Hat カスタマーポータル (https://access.redhat.com/) 経由で Ansible までお問い合わせください。他のオペレーティングシステム (ノード) の管理は、Ansible プロジェクト自体に文書でまとめられており、リストに追加することも可能です。

実際のメモリー要件は Tower が同時に管理するホスト数により異なります (これはジョブテンプレートまたはシステムの ansible.cfg ファイルの forks パラメーターにより制御されています)。発生する可能性のあるリソースの競合を回避するには、Ansible はフォーク 100 ごとにメモリー 1 GB を、さらに Tower 用に + 2GB 分搭載することを推奨しています。詳細は「 capacity algorithm」を参照してください。forks を 400 に設定した場合には、メモリー 40 GB を搭載することを推奨します。

Ansible Tower をインストールするホストでは、Tower により、umask=0022 が 0022 に設定されているかどうかが確認されます。設定に失敗する場合は、 に設定してこのエラーが発生しないようにしてください。

当然、より多くのホストに対応できますが、フォーク数がホストの総数より少ない場合は、ホスト間により多くのパスが必要です。設定を要求する各システムがキューに入り、できるだけ早く処理されるか、あるいは Tower が AMI などのイメージを作成またはデプロイする場合など、定期的な更新の使用、または Tower に含まれるプロビジョニングコールバックシステムを使用して、このようなメモリーの制限を回避することができます。これらすべては、大規模な環境を管理する優れたアプローチです。他に質問がある場合には、Red Hat カスタマーポータル (https://access.redhat.com) 経由で Ansible までお問い合わせください。

Tower が管理するシステムの要件は Ansible と同じです (http://docs.ansible.com/intro_getting_started.html)。

max_connections == 1000
shared_buffers == ansible_memtotal_mb*0.3
work_mem == ansible_memtotal_mb*0.3
maintenance_work_mem == ansible_memtotal_mb*0.04

1.4. Ansible のソフトウェア要件¶

Ansible Tower は Ansible Playbook に依存しており、インストール前に Ansible の最新安定版をインストールする必要がありますが、手動で Ansible をインストールする必要はなくなりました。

Ansible Tower バージョン 2.3 以降、Tower のインストールプログラムはインストールプロセスの一部として Ansible のインストールを試行します。以前の Tower では、Tower のインストールプログラムを実行する前に Ansible ソフトウェアリリースパッケージを手動でインストールする必要がありました。現在は Tower は、最新安定版の Ansible リリースパッケージのインストールを試行します。

バンドルの Tower インストールを実行する場合は、インストールプログラムにより、バンドルから Ansible およびその依存関係のインストールが試行されます (詳しい情報は「バンドルの Tower インストールプログラムの使用」を参照してください)。

Ansible をご自身でインストールすることにした場合には、Tower インストールプログラムは Ansible がインストールされていることを検出して、再インストールを試行しないようにします。Ansible Tower が正しく機能するようにするには、yum などのパッケージマネージャーを使用して Ansible をインストールし、最新安定版をインストールする必要がある点に注意してください。Ansible Tower バージョン 3.2 以降には、Ansible バージョン 2.2 が最小限必要です。

便宜上、これらの説明は以下で簡単にまとめています。

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

Tower は、留意すべき制限事項がいくつかありますが、FIPS モードが有効なシステムで実行できます。

• Enterprise Linux 7 以降のみがサポートされています。Ansible Tower を FIPS モードで機能させるには、RHEL に同梱されている標準の Python を使用する必要があります。標準以外の Python を使用すると、Tower のシステム以外の Python もサポートされません。

• デフォルトでは、Tower はパスワードベースの認証を使用して PostgreSQL を設定します。CREATE USER がインストール時に実行されている場合には、このプロセスでは md5 を使用している必要があります。FIPS が有効なシステムから Tower のインストーラーを実行する予定の場合は、インストール時に md5 ハッシュをご自身で事前にコンピュートし、「 インベントリーファイルの設定」で記載されているようにインベントリーファイルにその値を追加する必要があります。

  具体的には、FIPS を有効化 *せずに * システムでハッシュ化された値を事前にコンピュートする必要があります:

  $ python -c 'from hashlib import md5; print("md5" + md5("choose-a-password" + "awx").hexdigest())'
  md57d08dde7e95e862eaadfff09565e92e6
  

  さらに、インベントリーファイルで pg_password と pg_hashed_password 両方 を指定します。

  pg_password='choose-a-password'
  pg_hashed_password='md57d08dde7e95e862eaadfff09565e92e6'
  

• 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 モードが有効なシステムではサポートされません。

• Ansible Tower を RHEL 8 で実行するには、Ansible 2.8 以降をインストールする必要があります。RHEL 8 がサポートするのは、Ansible 2.8 以降のバージョンです。

• Ansible Tower 3.5 以降では Tower は Python 3 を使用して稼働します。Python 3 は、Tower インストール時に RHEL 8 に自動的にインストールされます。

• PackageKit は頻繁に、インストール/更新メカニズムを干渉する可能性があります。設定プロセスの実行前にインストールする場合は、PackageKit を無効または削除することを検討してください。

• "targeted" の SELinux ポリシーのみがサポートされます。targeted ポリシーは、disabled、permissive または enforcing に設定可能です。

• バンドルインストールを行う場合の詳細は、「 バンドルの Tower インストールプログラムの使用 」を参照してください。

• Ansible Tower のインストール時には、 のみを実行するだけで結構です。Tower で必要なリポジトリーは自動的にインストールされます。

• 設定プロセス時に、最新版の Ansible が自動的にインストールされ、追加のインストールや設定は必要ありません。

Ubuntu サポートは Ansible Tower 3.5 で非推奨になり、今後のリリースで削除予定です。Ubuntu に関する詳細は、Ansible Tower Installation and Reference Guide の以前のバージョンを参照してください。

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

1.6. Tower のインストールシナリオ¶

Tower は、以下のシナリオの 1 つを使用してインストールすることができます。

単一マシン:

• 統合インストールとして:

  • これは Tower を単一のマシンにインストールしたものです。Web フロントエンド、REST API バックエンド、データベースがすべて単一のマシンに含まれています。これは、Tower の標準インストールです。また、お使いの OS ベンダーリポジトリーから PostgreSQL もインストールされ、Tower サービスがデータベースとして使用するように設定されます。

• 外部データベースの使用 (利用可能なオプションは 2 つ):

  • リモートの DB 設定のある Tower: この構成では、単一マシンに Tower サーバーをインストールし、Tower のデータベースとして、PostgreSQL 9.6 のリモートのインスタンスと対話するように設定します。このリモートの PostgreSQL には自身で管理するサーバーを使用することも、Amazon RDS などのクラウドサービスで提供することも可能です。

  • Playbook でインストールされたリモートの Postgres システムを含む Tower: この構成では、単一のマシンに Tower サーバーをインストールし、(Tower が管理する) Playbook インストーラーでリモートの Postgres データベースをインストールします。

高可用性の複数マシンクラスター:

Tower は高可用性クラスターモードでインストールできます。このモードでは、複数の Tower ノードがインストールされ、アクティブ化されます。どのノードでも HTTP 要求を受信でき、すべてのノードがジョブを実行することができます。

• クラスター化された Tower の設定は、外部のデータベースでインストールする必要があります (利用可能なオプションは 2 つ)。

  • リモートの DB 設定のある Tower: この構成では、単一マシンに Tower サーバーをインストールし、Tower のデータベースとして、PostgreSQL のリモートのインスタンスと対話するように設定します。このリモートの PostgreSQL は自身で管理するサーバーを使用することも、Amazon RDS などのクラウドサービスで提供することも可能です。

  • Playbook でインストールされたリモートの Postgres システムを含む Tower: この構成では、単一のマシンに Tower サーバーをインストールし、(Tower が管理する) Playbook インストーラーでリモートの Postgres データベースをインストールします。

• クラスター化の設定に関する情報は、「ag_clustering」を参照してください。