Ansible Tower 3.8 以降では、Automation Hub は、Ansible Tower のコンテンツプロバイダーとして機能します。これには、Ansible Tower デプロイメントと Automation Hub デプロイメントの両方を実行する必要があります。Ansible Automation Platform インストーラーには 、その両方が含まれます。以下のセクションでは、アップグレードプロセスの各コンポーネントを説明します。
注釈
3 つ以上先のメジャーバージョンに対して、アップグレードはできません。たとえば、Ansible Tower 3.7.x にアップグレードする場合は、3.4.x 以前から直接アップグレードすることはできないため、まず 3.5.x にアップグレードする必要があります。Red Hat カスタマーポータルの「recommended upgrade path article」を参照してください。
Ansible Tower 3.8 を実行するには、Ansible 2.9 も設定する必要があります。
以下のセクションでは、Ansible Tower インスタンスのアップグレードを試行する際に留意する変更事項を説明します。
以前のバージョンからの有効なライセンスがすでにある場合でも、Ansible Tower 3.8 にアップグレードするときに認証情報またはサブスクリプションマニフェストを再度指定する必要があります。Ansible Tower User Guide の サブスクリプションのインポート を参照してください 。
Red Hat Enterprise Linux および Ansible Tower をアップグレードする必要がある場合は、Tower データをバックアップして復元する必要があります。詳細は、『Ansible Automation Platform Installation and Reference Guide』の「Upgrading an Existing Tower Installation」を参照してください。
クラスター形式のアップグレードでは、アップグレード前にインスタンスとインスタンスグループに特に留意が必要です。「インベントリーファイルの設定」および「クラスタリング」のセクションを参照してください。
Ansible Tower の以前のバージョンでは、インストール時に変数名 rabbitmq_host を使用していました。以前のバージョンの Tower からアップグレードし、インベントリーに rabbitmq_host を指定している場合は、アップグレードの前に、名前を rabbitmq_host から routable_hostname に変更してください。詳細は「クラスタリング」を参照してください。
詳細は、Ansible Automation Platform Installation and Reference Guide の Ansible Automation Platform インストールプログラムの取得 を参照してください。
インベントリーファイルの編集時には、複数の点を念頭に置く必要があります。
インベントリーファイルの内容は ./setup.sh インストーラー Playbook の隣りにある ./inventory で定義する必要があります。
インストールおよびアップグレード: 外部データベースを使用する必要がある場合には、インベントリーファイルのデータベースのセクションが正しく設定されていることを確認する必要があります。このファイルを編集して、外部データベースの情報を追加してから設定スクリプトを実行してください。
Ansible Automation Platform または Automation Hub: [automationhub] グループに自動化ハブホストを追加するようにしてください (Tower と Automation Hub は同じノードにインストールできません)。
Tower は、使用しているレプリケーションと連携しますが、使用するデータベースのレプリケーションやフェイルオーバーを構成しません。
パフォーマンス上の理由から、データベースサーバーは、Tower サーバーと同じネットワーク上または同じデータセンターに置く必要があります。
既存クラスターをアップグレード する場合: クラスターのアップグレード時に、既存のインスタンスやインスタンスグループを除いて、クラスターを再設定する場合があります。インベントリーファイルからインスタンスやインスタンスグループを削除しても、クラスターからインスタンスやインスタンスグループは削除されません。インベントリーファイルからインスタンスやインスタンスファイルを削除するだけでなく、アップグレード前に、「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 で特殊文字を使用しないでください。セットアップが失敗する場合があります。
新規ノードのプロビジョニング: 新規ノードのプロビジョニングの際には、現在のノードすべてを使用してインベントリーファイルにノードを追加し、すべてのパスワードがインベントリーファイルに含まれていることを確認してください。
単一ノードのアップグレード: アップグレード時には、インベントリーファイルと現在のリリースバージョンを比較するようにしてください。アップグレードを実行する際でも、ここにパスワードを保存することを推奨します。
[automationhub]
automationhub.acme.org
[all:vars]
automationhub_admin_password='<password>'
automationhub_pg_host=''
automationhub_pg_port=''
automationhub_pg_database='automationhub'
automationhub_pg_username='automationhub'
automationhub_pg_password='<password>'
automationhub_pg_sslmode='prefer'
# The default install will deploy a TLS enabled Automation Hub.
# If for some reason this is not the behavior wanted one can
# disable TLS enabled deployment.
#
# automationhub_disable_https = False
# The default install will generate self-signed certificates for the Automation
# Hub service. If you are providing valid certificate via automationhub_ssl_cert
# and automationhub_ssl_key, one should toggle that value to True.
#
# automationhub_ssl_validate_certs = False
# SSL-related variables
# If set, this will install a custom CA certificate to the system trust store.
# custom_ca_cert=/path/to/ca.crt
# Certificate and key to install in Automation Hub node
# automationhub_ssl_cert=/path/to/automationhub.cert
# automationhub_ssl_key=/path/to/automationhub.key
[tower]
tower.acme.org
[automationhub]
automationhub.acme.org
[database]
database-01.acme.org
[all:vars]
admin_password='<password>'
pg_host='database-01.acme.org'
pg_port='5432'
pg_database='awx'
pg_username='awx'
pg_password='<password>'
pg_sslmode='prefer' # set to 'verify-full' for client-side enforced SSL
# Automation Hub Configuration
#
automationhub_admin_password='<password>'
automationhub_pg_host='database-01.acme.org'
automationhub_pg_port='5432'
automationhub_pg_database='automationhub'
automationhub_pg_username='automationhub'
automationhub_pg_password='<password>'
automationhub_pg_sslmode='prefer'
# The default install will deploy a TLS enabled Automation Hub.
# If for some reason this is not the behavior wanted one can
# disable TLS enabled deployment.
#
# automationhub_disable_https = False
# The default install will generate self-signed certificates for the Automation
# Hub service. If you are providing valid certificate via automationhub_ssl_cert
# and automationhub_ssl_key, one should toggle that value to True.
#
# automationhub_ssl_validate_certs = False
# Isolated Tower nodes automatically generate an RSA key for authentication;
# To disable this behavior, set this value to false
# isolated_key_generation=true
# SSL-related variables
# If set, this will install a custom CA certificate to the system trust store.
# custom_ca_cert=/path/to/ca.crt
# Certificate and key to install in nginx for the web UI and API
# web_server_ssl_cert=/path/to/tower.cert
# web_server_ssl_key=/path/to/tower.key
# Certificate and key to install in Automation Hub node
# automationhub_ssl_cert=/path/to/automationhub.cert
# automationhub_ssl_key=/path/to/automationhub.key
# Server-side SSL settings for PostgreSQL (when we are installing it).
# postgres_use_ssl=False
# postgres_ssl_cert=/path/to/pgsql.crt
# postgres_ssl_key=/path/to/pgsql.key
[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」を参照してください。
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