Documentation

2. Ansible Tower のアップグレード

注釈

Ansible Tower 2.4.4 (またはそれ以降) のシステムは Ansible Tower 3.0 にアップグレードしてから Ansible Tower 3.0 より後のバージョンにアップグレードしてください。

2.1. アップグレードのプランニング

以下のセクションでは、Ansible Tower インスタンスのアップグレードを試行する際に、留意する変更事項について説明します。

  • Ansible Tower のバージョン 3.2.0、3.2.1、または 3.2.2 とともに Ansible バージョン 2.5 を使用している場合は、クラウドインベントリーの同期が、メンバーホストの hostvars ではなく、元のグループまたはインベントリー変数で行われているいる可能性があります。Ansible Tower 3.2.3 へのアップグレード後、この変数は、各グループ内、またはインベントリー変数内に返されます。hostvars が優先されるため、移行前の変数は、新しい値に優先され、変数の順序が競合する可能性があります。回避策は「アップグレード変数の順序が競合している問題の修正手順」を参照してください。
  • 2.4.x バージョンの Ansible Tower を使用していない場合、Ansible Tower 3.0.x または 3.1.0 への直接のアップグレードは 実行しないでください。Tower 2.4.x バージョンがインストールされたシステムで実行しないとアップグレードは失敗します。
  • Ansible Tower のバージョン 3.0.x を使用していない場合には、3.0.x にアップグレードしてから Ansible Tower 3.0 より後のバージョンにアップグレードする必要があります。
  • Ansible Tower 3.0 ではインストールが簡素化され、初期設定の一部で ./configure/ を実行する必要がなくなりました。
  • ファイル tower_setup_conf.yml は使用されなくなり、今回のリリースでは /ansible-tower-setup-<tower_version>/ ディレクトリーの inventory ファイルを編集する必要があります。
  • 以前の Tower では、初期のデータベースの設定時に MongoDB を使用していましたが、Ansible Tower 3.0 では MongoDB は PostgreSQL に置き換えられました。

2.1.1. アップグレード変数の順序が競合している問題の修正手順

Ansible Tower 3.2.3 へのアップグレード後に、変数の順序が競合している問題が発生したら、インベントリーソースの overwrite_vars フィールドを一時的に True に設定して更新を実行すると解決できます。この問題が発生しているすべてのインベントリーソースにこの設定を適用します。

プロジェクトから提供されるインベントリーでは、overwrite_varsTrue に設定する必要があるため、影響は受けません。

2.2. Ansible Tower の取得

Ansible Tower インストール/アップグレードツールをダウンロードして展開してください (http://releases.ansible.com/ansible-tower/setup/)。

root@localhost:~$ tar xvzf ansible-tower-setup-latest.tar.gz
root@localhost:~$ cd ansible-tower-setup-<tower_version>

インストールまたはアップグレードを実行するには、ansible-tower-setup-<tower_version> ディレクトリーのインベントリーファイルを編集します。<tower_version>2.4.53.0.0. ディレクトリーなどのバージョン番号に置き換えてください。

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

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

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

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

  • クラスターインストール: クラスター設定を作成する場合には、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'
pg_password='password'

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

[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'
pg_password='password'

必要な変更を加えたら、 ./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

2.4. 設定用の 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 のインストーラーを使用してください。