Tower のインストールにはあらゆる方法があるので、お使いの環境に最適なモードを選択して、インベントリーファイルに必要な変更を加えてください。OpenShift ベースのデプロイメントについては、 「OpenShift Deployment and Configuration」を参照してください。
Tower は、以下のシナリオの 1 つを使用してインストールすることができます。
単一マシン:
これは Tower を単一のマシンにインストールしたものです。Web フロントエンド、REST API バックエンド、データベースがすべて単一のマシンに含まれています。これは、Tower の標準インストールです。また、お使いの OS ベンダーリポジトリーから PostgreSQL もインストールされ、Tower サービスがデータベースとして使用するように設定されます。
リモートの DB 設定のある Tower: この構成では、単一マシンに Tower サーバーをインストールし、Tower のデータベースとして、PostgreSQL 9.6 のリモートのインスタンスと対話するように設定します。このリモートの PostgreSQL には自身で管理するサーバーを使用することも、Amazon RDS などのクラウドサービスで提供することも可能です。
Playbook でインストールされたリモートの Postgres システムを含む Tower: この構成では、単一のマシンに Tower サーバーをインストールし、(Tower が管理する) Playbook インストーラーでリモートの Postgres データベースをインストールします。
注釈
1). Tower は、設定済みの複製と連携することは可能ですが、お使いのデータベースの複製やフェイルオーバーの設定は行いません。2). データベースサーバーは、パフォーマンスの関係で Tower サーバーと同じネットワーク上、またはデータセンター内に配置する必要があります。
高可用性の複数マシンクラスター:
Tower は高可用性クラスターモードでインストールできます。このモードでは、複数の Tower ノードがインストールされ、アクティブ化されます。どのノードでも HTTP 要求を受信でき、すべてのノードがジョブを実行することができます。
リモートの DB 設定のある Tower: この構成では、単一マシンに Tower サーバーをインストールし、Tower のデータベースとして、PostgreSQL のリモートのインスタンスと対話するように設定します。このリモートの PostgreSQL は自身で管理するサーバーを使用することも、Amazon RDS などのクラウドサービスで提供することも可能です。
Playbook でインストールされたリモートの Postgres システムを含む Tower: この構成では、単一のマシンに Tower サーバーをインストールし、(Tower が管理する) Playbook インストーラーでリモートの Postgres データベースをインストールします。
クラスター化の設定に関する情報は、「ag_clustering」を参照してください。
注釈
クラスター設定で実行するには、Tower は外部のデータベースを使用する必要があります。Postgres はプライマリーまたはセカンダリーの Tower ノードではないマシンにインストールする必要があります。冗長設定の場合の要件として、リモートの Postgres バージョンは PostgreSQL 9.6 でなければなりません。
インベントリーファイルの編集時には、複数の点を念頭に置く必要があります。
インベントリーファイルの内容は ./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 にあります。
rabbitmq_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'
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
の準備が整います。
注釈
リモートマシンには root アクセスが必要です。Ansible では、複数の方法で実行できます。
ansible_user=root ansible_ssh_password="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」を参照してください。
注釈
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 も利用できる状態でなければなりません。
Tower のインストールに失敗し、Ansible Tower の有効なライセンスを購入済みのお客様は、Red Hat カスタマーポータル (https://access.redhat.com/) から Ansible までお問い合せください。
インストールの完了後に SSH 経由で Tower インスタンスにログインすると、デフォルトの管理パスワードがプロンプトに提示されます。(root または AWS ユーザーとして) 以下のコマンドを使用して変更することができます。
awx-manage changepassword admin
その後は入力したパスワードが Web UI の管理者パスワードとして機能します。