システムのバックアップやリストア機能が Tower の設定 Playbook に統合されました。さらなる情報は、「クラスター環境のバックアップおよび復元」を参照してください。
注釈
復元するには、バックアップしたバージョンと同じバージョンに復元するようにしてください。ただし、Tower インストールのバージョンをバックアップおよび復元する場合は、最新のマイナーバージョンを必ず使用するようにしてください。たとえば、現在使用している Tower のバージョンが 3.0.0、3.0.1 または 3.0.2 の場合は、3.0.2 のインストーラーのみを使用してください。
また、バックアップと復元は、現在の Ansible Tower バージョンでサポートされている PostgreSQL バージョンで のみ 機能します。詳細は、Ansible Tower Installation and Reference Guide の「要件」を参照してください。
Tower の設定 Playbook は、Tower のインストーラーの tar ファイルを展開したパスから setup.sh として呼び出されます。このシェルは、インストール playbook で使用したものと同じインベントリーファイルを使用します。設定スクリプトでは、以下の引数を指定してバックアップと復元を行うことができます。
-b: データベースのインストールではなくバックアップを実行します。
-r: データベースのインストールではなく復元を実行します。
root ユーザーとして、適切なパラメーターを指定して setup.sh と設定通りに Tower のバックアップと復元を呼び出します。
root@localhost:~# ./setup.sh -b
root@localhost:~# ./setup.sh -r
バックアップファイルは、setup.sh スクリプトが存在するパスと同じところに作成されます。以下の EXTRA_VARS を指定すると変更できます。
root@localhost:~# ./setup.sh -e 'backup_dest=/path/to/backup_dir/' -b
以下の例に記載されているように、EXTRA_VARS でデフォルト以外のパスを指定しない限り、デフォルトの復元パスが使用されます。
root@localhost:~# ./setup.sh -e 'restore_backup_file=/path/to/nondefault/backup.tar.gz' -r
オプションで、設定スクリプトに引数として渡すことで使用したインベントリーファイルを上書きすることができます。
setup.sh -i <inventory file>
setup.sh の設定 Playbook が含まれる install.yml ファイルの他に、 バックアップや復元用の backup.yml と restore.yml ファイルもあります。
これらの Playbook にはバックアップと復元の 2 つの機能があります。
システム全体のバックアップは以下をバックアップします。
データベース
SECRET_KEY ファイル
システム毎のバックアップには以下が含まれます。
カスタムのユーザー設定ファイル
ジョブの標準出力
手動のプロジェクト
復元では、バックアップしたファイルおよびデータを新規インストールした Tower または 2 つ目の機能する Tower インスタンスに復元します。
システムを復元する際には、Tower はバックアップファイルが存在するかどうか確認してから復元を開始します。バックアップファイルがない場合には、復元に失敗します。
注釈
ホストファイル内で SSH キーまたはユーザー/パスワード変数を指定して、Tower ホストが正しく設定されており、そのユーザーに sudo アクセスが設定されていることを確認します。
ディスクの容量: 設定ファイル、キー、その他の関連ファイル、Tower システム設定のデータベースをバックアップするために必要な容量があるように、ディスク領域の要件を確認します。
システムの認証情報: ローカルデータベースまたはリモートデータベースを使用している場合には必要なシステムの認証情報があることを確認します。ローカルシステムでは、認証情報の設定方法によっては root または sudo アクセスが必要です。リモートシステムでは、バックアップまたは復元しようとしているリモートシステムへのアクセス権を付与するために異なる認証情報が必要になる場合があります。
Tower インストールのバージョンをバックアップおよび復元する場合は、最新のマイナーバージョンを必ず使用するようにしてください。たとえば、現在使用している Tower のバージョンが 3.0.0、3.0.1 または 3.0.2 の場合は、3.0.2 のインストーラーのみを使用してください。
setup.sh を使用して、デフォルトの復元ファイルパス /var/lib/awx から、復元を行う場合には、依然として -r を指定して復元する必要がありますが、それ以上引数を受け入れなくなります。デフォルト以外の復元パスを指定する必要がある場合には、ユーザーは追加変数としてこれを指定する必要があります (root@localhost:~# ./setup.sh -e 'restore_backup_file=/path/to/nondefault/backup.tar.gz' -r)。
バックアップファイルを setup.sh インストーラーと同じディレクトリーに配置している場合は、復元 Playbook は自動的に復元ファイルの場所を特定します。この場合には、バックアップファイルの場所を指定するときに、restore_backup_file の追加変数を使用する必要はありません。
クラスター環境のバックアップおよび復元の手順は、このセクションで説明されている留意事項を以外は、単一インストールとほぼ同じです。
新規クラスターに復元する場合は、データベースにアクセスする際にはそれぞれのクラスター間で競合状態になる可能性があるので、以前のクラスターをシャットダウンしてから続行するようにしてください。
ノードごとのバックアップは、バックアップと同じホスト名のノードのみに復元されます。
既存のクラスターに復元する場合には、復元には以下が含まれます。
PostgreSQL データベースのダンプ
(データベースダンプに含まれる) UI アーティファクト
Tower 設定 (/etc/tower から取得)
Tower 秘密鍵
手動のプロジェクト
別のインスタンスまたはクラスターにバックアップを復元する場合には、ホスト固有の設定 (手動プロジェクト、ジョブの出力、/etc/tower のカスタム設定) は新しい環境のホストには復元されません。
復元プロセスは、復元の前に存在するインスタンスグループを変更しません (また、新規インスタンスグループの導入もありません)。複数のインスタンスグループに関連づけられていた Tower リソースを復元した後には、新しい Tower クラスターに存在するインスタンスグループに再度割り当てる必要があります。