Documentation

3. Ansible Tower のインストール

Tower のインストールにはあらゆる方法があるので、お使いの環境に最適なモードを選択して、インベントリーファイルに必要な変更を加えてください。OpenShift ベースのデプロイメントについては、「OpenShift Deployment and Configuration」を参照してください。

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 データベースをインストールします。

注釈

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.

従来の 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 (またはワイルドカード、サブジェクトの別名など) が必要です。

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 データベースをインストールします。

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

注釈

クラスター設定で実行するには、Tower は外部のデータベースを使用する必要があります。PostgreSQL はプライマリーまたはセカンダリーの Tower ノードではないマシンにインストールする必要があります。冗長設定の場合の要件として、リモートの PostgreSQL バージョンは PostgreSQL 10 でなければなりません。

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

注釈

インストールプロセスに変更を加えるには、インベントリーファイルのパスワードフィールドをすべて入力する必要があります。この値は以下で確認できます。

admin_password='' <--- Tower のローカルの管理者パスワード

pg_password='' <---- /etc/tower/conf.d/postgres.py にあります。

警告

pg_password で特殊文字を使用しないでください。セットアップが失敗する場合があります。

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

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

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

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

[tower]
localhost ansible_connection=local

[database]

[all:vars]
admin_password='password'

pg_host=''
pg_port=''

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

警告

pg_password で特殊文字を使用しないでください。セットアップが失敗する場合があります。

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

[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'

警告

pg_password で特殊文字を使用しないでください。セットアップが失敗する場合があります。

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

[tower]
node.example.com ansible_connection=local

[database]

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


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

pg_database='awx'
pg_username='awx'

警告

pg_password で特殊文字を使用しないでください。セットアップが失敗する場合があります。

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

[tower]
node.example.com ansible_connection=local


[database]
database.example.com

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

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

pg_database='awx'
pg_username='awx'

警告

pg_password で特殊文字を使用しないでください。セットアップが失敗する場合があります。

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

注釈

リモートマシンには root アクセスが必要です。Ansible では、複数の方法で実行できます。

  • ansible_user=root ansible_ssh_pass="your_password_here" inventory host or group variables

  • ansible_user=root ansible_ssh_private_key_file="path_to_your_keyfile.pem" inventory host or group variables

  • ANSIBLE_BECOME_METHOD='sudo' ANSIBLE_BECOME=True ./setup.sh

  • ANSIBLE_SUDO=True ./setup.sh (対象は Ansible 2.7 のみ)

DEFAULT_SUDO Ansible 設定パラメーターは Ansible 2.8 で削除されたため、昇格された権限での ANSIBLE_SUDO=True ./setup.sh メソッドが機能しなくなりました。become プラグインに関する詳細は、「 Understanding Privilege Escalation 」と「 list of become plugins」を参照してください。

3.3. 設定用の Playbook

注釈

Ansible Tower 3.0 はインストールが簡素化され、インストール設定の一部として ./configure/ を実行する必要性がなくなりました。以前のバージョンを使用している方は、http://docs.ansible.com/ に v.2.4.5 リリース (以前) の Tower ドキュメントに記載の説明に従うようにしてください。

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

注釈

Tower 3.0.0 および 3.0.1 で、正常なシステムのバックアップと復元を阻止する問題が検出されている点に注意してください。

Tower v3.0.0 または v3.0.1 インストールをバックアップまたは復元する必要がある場合は v3.0.2 のインストーラーを使用してください。

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

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

Login form

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

3.4. パスワードの変更

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

awx-manage changepassword admin

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