AWX Operator による AWX のバックアップとリストア

はじめに

前回のエントリ では、AWX をほどほどの使用感でシングルノード K3s 上にホストする方法を紹介しました。

この中では、バックアップとリストアのごく簡易的な例として、PV の実体をフルバックアップする考え方や pg_dump での運用を紹介しましたが、エントリ中でも記述していた通り、AWX の 0.10.0 からは、組み込みで バックアップ と リストア の機能が追加されています。

本エントリでは、この AWX Operator によるバックアップとリストアを実践します。

仕組み

AWX の 0.10.0 から、カスタムリソース AWXBackup と AWXRestore が追加 されました。バックアップとリストアは、これら AWXBackup リソースと AWXRestore リソースの作成によって実行できます。

バックアップを取得するには、AWXBackup リソースを作成します。ひとつの AWXBackup リソースがひとつのバックアップに相当し、実際には指定した PV 内に次のファイル群を含んだディレクトリが作成されます。

• AWX インスタンスの構成情報
• 構成に必要なシークレット情報
• PostgreSQL のダンプ

リストアを実行するには、リストアしたいバックアップに対応する AWXBackup リソースを指定して AWXRestore リソースを作成します。新規環境へのリストア時など AWXBackup リソースが存在していない場合でも、前述のファイル群があれば、PV 名やディレクトリ名を直接指定してリストアが行えます。

具体的な利用方法や設定は、それぞれ対応するロールの README.md で確認できます。

• backup ロールの README.md
• restore ロールの README.md

バックアップの取得

今回は、前回のエントリ の構成を前提にします。必要なファイルは前回同様 GitHub 上のリポジトリ にも配置しています。

バックアップの準備

バックアップの保存先となる PV を準備します。PV の実体のディレクトリをローカルで作成し、これに対応する PV と PVC を事前に作成しておきます。

sudo mkdir -p /data/backup

---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: awx-backup-volume
spec:
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  capacity:
    storage: 2Gi
  storageClassName: awx-backup-volume
  hostPath:
    path: /data/backup

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: awx-backup-claim
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 2Gi
  storageClassName: awx-backup-volume

今回は外部ストレージを利用しないシングルノード構成なので、PV は hostPath で構成しています。

バックアップの取得

AWXBackup リソースのマニフェストを作成して kubectl apply -f すると、バックアップが実行できます。ここでは次のようなマニフェストを作成します。細かいパラメータは ドキュメント に記載があります。

---
apiVersion: awx.ansible.com/v1beta1
kind: AWXBackup
metadata:
  name: awxbackup-2021-06-06
  namespace: awx
spec:
  deployment_name: awx
  backup_pvc: awx-backup-claim
  postgres_label_selector: app.kubernetes.io/instance=postgres-awx

ひとつの AWXBackup リソースがひとつのバックアップに相当するため、metadata.name はそのバックアップを特定できるユニークな名称にします。ここではハードコードしていますが、実際には実行日時などを外部の仕組みで埋め込んで実行するとよさそうです。また、spec.backup_pvc で、事前に作成した PVC を指定しています。

なお、spec.postgres_label_selector は、0.10.0 の段階ではデフォルトの値に誤りがあるため、postgres-<AWX 名> の文字列での明示が必須のようでした。アップストリームでは修正済みなので、次期リリースではデフォルトでよければ不要になるでしょう（追記： 0.11.0 で修正されました）。

マニフェストができたら、apply します。

kubectl apply -f awxbackup.yaml

進捗は AWX Operator のログで確認できます。

$ kubectl logs -f deployment/awx-operator
...
--------------------------- Ansible Task Status Event StdOut  -----------------
PLAY RECAP *********************************************************************
localhost                  : ok=4    changed=0    unreachable=0    failed=0    skipped=7    rescued=0    ignored=0
-------------------------------------------------------------------------------

これで、AWXBackup リソースができあがります。実際の PV の中身を探索すると、実行日時を含むディレクトリにバックアップファイルが保存されていることもわかります。なお、AWXBackup リソースと実際の PV 内のディレクトリの対応付けは、describe などで確認できます。

$ kubectl -n awx get awxbackup
NAME                   AGE
awxbackup-2021-06-06   6m47s

$ ls -l /data/backup/tower-openshift-backup-2021-06-06-10\:51\:49/
total 736
-rw-r--r--. 1 root             root    749 Jun  6 06:51 awx_object
-rw-r--r--. 1 root             root    482 Jun  6 06:51 secrets.yml
-rw-------. 1 systemd-coredump root 745302 Jun  6 06:51 tower.db

これでバックアップは取得できた…… のですが、構築時に事前に手動で作成したシークレット の中身は、AWX Operator でのバックアップには 0.10.0 の段階では 含まれない ようです（Issue は上がっているので、将来的には是正されそうではあります）。このため、今回の構成 では、Ingress で利用する TLS のシークレットは、別途取得が必要です。YAML ファイルでエクスポートしてもよいですし、もしくは構築時に利用したもともとのファイルを取っておくのもよいでしょう（追記： 0.13.0 以降では、この問題は修正されています）。

kubectl -n awx get secret awx-secret-tls -o yaml > awx-secret-tls.yaml

リストアの実行

リストアも、ここでは 前回のエントリ の構成を前提にします。必要なファイルはバックアップ同様 GitHub 上のリポジトリ にも配置しています。

リストアの準備

既存の環境に対して上書きリストアをするのであれば、特別な事前準備は不要です。

新規環境に対してゼロからリストアをするのであれば、少なくともリストア先の PV と PVC は 前回のエントリ などを参照して事前に作成しておきます。面倒であれば、初期構築時のファイル一式をそのまま使って、新しいインスタンスをいちどデプロイしてしまうのも手です。

また、バックアップデータが保存されている PV も存在しない場合は、前述のバックアップの準備と同様の手法で用意し、必要なファイルを配置しておきます。

リストアの実行

リストアの実行には、バックアップのときと同様に、AWXRestore リソースのマニフェストを作成して apply するだけですが、AWXBackup リソースの残存有無でマニフェストに含むべき内容が少し変わります。

AWXBackup リソースが残存している状態でのリストア

マニフェスト中で、リストアする AWXBackup リソースを指定します。

---
apiVersion: awx.ansible.com/v1beta1
kind: AWXRestore
metadata:
  name: awxrestore-2021-06-06
  namespace: awx
spec:
  deployment_name: awx

  backup_pvc_namespace: awx
  backup_name: awxbackup-2021-06-06

AWXBackup リソースが残存していない状態でのリストア

マニフェスト中で、バックアップデータを含む PV に対応する PVC と、その中のパスを指定します。

---
apiVersion: awx.ansible.com/v1beta1
kind: AWXRestore
metadata:
  name: awxrestore-2021-06-06
  namespace: awx
spec:
  deployment_name: awx

  backup_pvc_namespace: awx
  backup_pvc: awx-backup-claim
  backup_dir: /backups/tower-openshift-backup-2021-06-06-10:51:49

なお、指定した PVC は Pod の /backup にマウントされるため、パスはその前提で記載が必要です。

実行

apply します。

kubectl apply -f awxrestore.yaml

結果はバックアップ時と同様にログで確認できます。インスタンスがまるごと再作成されるようで、初期構築と同等かそれ以上の時間がかかります。

$ kubectl logs -f deployment/awx-operator
--------------------------- Ansible Task Status Event StdOut  -----------------
PLAY RECAP *********************************************************************
localhost                  : ok=53   changed=2    unreachable=0    failed=0    skipped=30   rescued=0    ignored=0
-------------------------------------------------------------------------------

Ingress の TLS など、別途取得していたバックアップがあれば、併せてリストアして、完了です（追記： 0.13.0 以降ではこの手順は不要です）。

kubectl apply -f awx-secret-tls.yaml

リストアのオブジェクトは残りますが、不要なら削除できます。

$ kubectl -n awx get awxrestore
NAME                    AGE
awxrestore-2021-06-06   137m

まとめ

AWX Operator を使った AWX のバックアップとリストアを紹介しました。まだ GA していないので今後実装が大きく変わる可能性は当然ありますが、今回のようにシンプルな構成であれば、充分に使っていけそうです。