システムのバックアップやリストア機能が Tower の設定 Playbook に統合されました。さらなる情報は、「クラスター環境のバックアップおよび復元」を参照してください。
注釈
復元時、バックアップには最新のマイナーリリースを使用し、バックアップを取得したバージョンと同じバージョンに復元できるようにします。
Tower の設定 Playbook は、Tower のインストーラーの tar ファイルを解凍したパスから setup.sh として呼び出されます。このシェルは、インストール playbook で使用したものと同じインベントリーファイルを使用します。設定スクリプトでは、以下の引数を指定してバックアップと復元を行うことができます。
-b データベースのインストールではなくバックアップを実行します。-r データベースのインストールではなく復元を実行します。root ユーザーとして、適切なパラメーターを指定して setup.sh と設定通りに Tower のバックアップと復元を呼び出します。
root@localhost:~# ./setup.sh -b
root@localhost:~# ./setup.sh -r
以下の例に記載されているように、EXTRA_VARS でデフォルト以外のパスを指定しない限り、デフォルトの復元パスが使用されます。
root@localhost:~# ./setup.sh -e 'restore_backup_file=/path/to/nondefault/backup.tar.gz' -r
オプションで、設定スクリプトに引数として渡すことで使用したインベントリーファイルを上書きすることができます。
setup.py -i <inventory file>
setup.sh の設定 Playbook が含まれる install.yml ファイルの他に、 バックアップや復元用の backup.yml と restore.yml ファイルもあります。
これらの Playbook にはバックアップと復元の 2 つの機能があります。
SECRET_KEY ファイルシステムを復元する際には、Tower はバックアップファイルが存在するかどうか確認してから復元を開始します。バックアップファイルがない場合には、復元に失敗します。
注釈
ホストファイル内で SSH キーまたはユーザー/パスワード変数を指定して、Tower ホストが正しく設定されており、そのユーザーに sudo アクセスが設定されていることを確認します。
sudo アクセスが必要です。リモートシステムでは、バックアップまたは復元しようとしているリモートシステムへのアクセス権を授与するために異なる認証情報が必要になる場合があります。setup.sh を使用してデフォルトの復元ファイルパス (/var/lib/awx) から復元を行う場合には -r を指定して復元する必要がありますが、それ以上引数を受け入れなくなります。デフォルト以外の復元パスを指定する必要がある場合には、ユーザーは extra var として指定する必要があります (root@localhost:~# ./setup.sh -e 'restore_backup_file=/path/to/nondefault/backup.tar.gz' -r)。setup.sh インストーラーと同じディレクトリーに配置している場合は、復元 Playbook は自動的に復元ファイルの場所を特定します。この場合には、バックアップファイルの場所を指定する際に restore_backup_file の追加変数を使用する必要はありません。クラスター環境のバックアップおよび復元の手順は、このセクションで説明されている留意事項を以外は、単一インストールとほぼ同じです。
既存のクラスターに復元する場合には、復元には以下が含まれます。
/etc/tower から取得)別のインスタンスまたはクラスターにバックアップを復元する場合には、ホスト固有の設定 (手動プロジェクト、ジョブの出力、/etc/tower のカスタム設定) は新しい環境のホストには復元されません。
復元プロセスは、復元の前に存在するインスタンスグループを変更しません (また、新規インスタンスグループの導入もありません)。複数のインスタンスグループに関連づけられていた Tower リソースを復元した後には、新しい Tower クラスターに存在するインスタンスグループに再度割り当てる必要があります。