3. Ansible Tower のインストール¶

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

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

単一マシン:

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

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

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

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

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

従来の Tower のインストールに使用できる設定:

• pg_sslmode は、PostgreSQL クライアントの SSL 機能 (Tower サーバーがデータベースにどのように接続するか) を制御します。初期設定は、prefer です。この設定では、データベースサーバーに SSL がある場合は、クライアントで SSL を使用します。また、verify-full に設定して、SSL を有効にし、証明書の信頼を完全に検証することも可能です。

• web_server_ssl_cert および web_server_ssl_key では、Tower UI と API 向けの Web サーバーにインストールする証明書とキーをユーザーが指定できるようにします。この設定は、両方指定するか、両方指定しないようにしてください。指定しない場合には、自己署名 (信頼されていない) 証明書がインストール時に生成されます。

• postgres_use_ssl (true/false): SSL を必須として PostgreSQL サーバーを設定するかどうかを制御します。これは、内部/埋め込みデータベースでのみ (Tower インストールスクリプトがデータベースサーバーのデプロイメントを実行している場合) 効果があり、外部データベースには影響はありません。

• postgres_ssl_cert および postgres_ssl_key: postgres_use_ssl が true の場合に指定する必要があります。この証明書には、Tower ノードがデータベースサーバーへの接続に使用するホスト名と一致する CN (またはワイルドカード、サブジェクトの別名など) が必要です。

• rabbitmq_use_ssl (true/false): RabbitMQのノード間通信を暗号化するかどうかを制御します。これが true に設定されている場合には、インストールスクリプトで 1 回限りの「固定」CA とサーバー証明書が生成されます。RabbitMQ の証明書を指定する必要はありません。

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

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

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

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

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

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

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

3.2. インベントリーファイルの設定¶

インベントリーファイルの編集時には、複数の点を念頭に置く必要があります。

• インベントリーファイルの内容は ./setup.sh インストーラー Playbook の隣りにある ./inventory で定義する必要があります。

• インストールおよびアップグレード: 外部データベースを使用する必要がある場合には、インベントリーファイルのデータベースのセクションが正しく設定されていることを確認する必要があります。このファイルを編集して、外部データベースの情報を追加してから設定スクリプトを実行してください。

• 既存クラスターをアップグレード する場合: クラスターのアップグレード時に、既存のインスタンスやインスタンスグループを除いて、クラスターを再設定する場合があります。インベントリーファイルからインスタンスやインスタンスグループを削除しても、クラスターからインスタンスやインスタンスグループは削除されません。インベントリーファイルからインスタンスやインスタンスファイルを削除するだけでなく、アップグレード前に、「deprovision instances or instance groups」する必要があります。プロビジョニングを解除しなければ、削除したインスタンスまたはインスタンスグループは、クラスターへの通信を継続し、アップグレード時に Tower のサービスで問題が発生する可能性があります。

• クラスターインストール: クラスター設定を作成する場合には、localhost は全インスタンスのホスト名または IP アドレスに置き換える必要があります。ノード/インスタンスはすべて、このホスト名やアドレスを使用して他のノードやインスタンスに到達する必要があります。つまり、ノードでは localhost ansible_connection=local を使用できず、かつ 全ノードはホスト名と同じ形式を使用する必要があります。

  このように、以下は*機能しません*。

  [tower]
  localhost ansible_connection=local
  hostA
  hostB.example.com
  172.27.0.4
  

  代わりに以下の形式を使用します。

  [tower]
  hostA
  hostB
  hostC
  

  または

  hostA.example.com
  hostB.example.com
  hostC.example.com
  

  または

  [tower]
  172.27.0.2
  172.27.0.3
  172.27.0.4
  

• 全標準インストール: インストールを実行する際には、インベントリーファイルに必要なパスワードを提示する必要があります。

インベントリーファイルの例

• 新規ノードのプロビジョニング: 新規ノードのプロビジョニングの際には、現在のノードすべてを使用してインベントリーファイルにノードを追加し、すべてのパスワードがインベントリーファイルに含まれていることを確認してください。

• 単一ノードのアップグレード: アップグレード時には、インベントリーファイルと現在のリリースバージョンを比較するようにしてください。アップグレードを実行する際でも、ここにパスワードを保存することを推奨します。

単一ノードのインベントリーファイル例

[tower]
localhost ansible_connection=local

[database]

[all:vars]
admin_password='password'

pg_host=''
pg_port=''

pg_database='awx'
pg_username='awx'
pg_password='password'

rabbitmq_port=5672
rabbitmq_vhost=tower
rabbitmq_username=tower
rabbitmq_password='password'
rabbitmq_cookie=rabbitmqcookie

# Needs to be true for fqdns and ip addresses
rabbitmq_use_long_name=false
# Needs to remain false if you are using localhost

複数ノードのインベントリーファイル例

[tower]
clusternode1.example.com
clusternode2.example.com
clusternode3.example.com

[database]
dbnode.example.com

[all:vars]
ansible_become=true

admin_password='password'

pg_host='dbnode.example.com'
pg_port='5432'

pg_database='tower'
pg_username='tower'
pg_password='password'

rabbitmq_port=5672
rabbitmq_vhost=tower
rabbitmq_username=tower
rabbitmq_password=tower
rabbitmq_cookie=rabbitmqcookie

# Needs to be true for fqdns and ip addresses
rabbitmq_use_long_name=true

外部の既存データベースのインベントリーファイル例

[tower]
node.example.com ansible_connection=local

[database]

[all:vars]
admin_password='password'
pg_password='password'
rabbitmq_password='password'


pg_host='database.example.com'
pg_port='5432'

pg_database='awx'
pg_username='awx'

インストールを必要とする外部データベースのインベントリーファイル例

[tower]
node.example.com ansible_connection=local


[database]
database.example.com

[all:vars]
admin_password='password'
pg_password='password'
rabbitmq_password='password'

pg_host='database.example.com'
pg_port='5432'

pg_database='awx'
pg_username='awx'

必要な変更を加えたら、./setup.sh の準備が整います。

3.3. 設定用の Playbook¶

Tower の設定 Playbook のスクリプトでは inventory ファイルが使用され、Tower インストーラーの tarball を展開したパスから ./setup.sh として呼び出されます。

root@localhost:~$ ./setup.sh

設定スクリプトでは以下の引数を指定できます。

• -h -- ヘルプメッセージを表示して終了します。

• -i INVENTORY_FILE -- Ansible インベントリーファイルへのパス (デフォルト値: inventory)

• -e EXTRA_VARS -- 追加の Ansible 変数を key=value または YAML/JSON (つまり -e bundle_install=false は強制的にオンラインインストールを実行します) として設定します。

• -b -- インストールの代わりにデータベースのバックアップを実行します。

• -r -- インストールの代わりにデータベースの復元を実行します (以下のコード例に記載されているように、EXTRA_VARS でデフォルト以外のパスを指定しない限り、デフォルトの復元パスが使用されます)。

./setup.sh -e 'restore_backup_file=/path/to/nondefault/location' -r

適切なパラメーターで ./setup.sh を呼び出すと、Tower は設定どおりに適切なマシンにインストールされます。ansible.com でホストされているリポジトリーを使用して、Setup シェルは RPM または Deb パッケージから Tower をインストールします。

設定が完了したら、お使いの Web ブラウザーを使用して Tower サーバーにアクセスでき、Tower のログイン画面が表示されます。Tower サーバーは、ポート 80 (http://tower.company.com/) からアクセスできますが、ポート 443 にリダイレクトされるので、443 も利用できる状態でなければなりません。

Tower のインストールに失敗し、Ansible Tower の有効なライセンスを購入済みのお客様は、Red Hat カスタマーポータル (https://access.redhat.com/) から Ansible までお問い合せください。

3.4. パスワードの変更¶

インストールの完了後に SSH 経由で Tower インスタンスにログインすると、デフォルトの管理パスワードがプロンプトに提示されます。(root または AWS ユーザーとして) 以下のコマンドを使用して変更することができます。

awx-manage changepassword admin

その後は入力したパスワードが Web UI の管理者パスワードとして機能します。