EKS上のステートフルアプリケーションをまるごとバックアップ・リストアしてみた【②アプリケーションの登録篇】

はじめに

前回の記事でk8sアプリケーションのバックアップや移行といった機能を持つAstra Control Service(以下、ACS)の導入を実施しました。
今回は検証用のEKSクラスタ上にステートフルアプリケーションをデプロイし、ACSの管理下に置くというところまでを試していきたいと思います。

• Astra Control Service(ACS)の導入
• Astra Control Service(ACS)の使い方
  1. アプリケーションの登録 ←イマココ
  2. アプリケーションのスナップショット&バックアップ
  3. アプリケーションのリストア&クローニング

前回までのおさらい

検証環境の構成図はこちら。

検証用のEKSクラスタは既にACS上に登録された状態になっています。

k8sアプリケーションをACS上に登録してみた

ここからが本編です。

検証用アプリケーションのデプロイ

何はともあれアプリケーションが無いと始まりませんので、まずはテスト用のアプリをEKS上にデプロイしていきます。
今回はこちらのhelmチャートを使って、定番のwordpressをデプロイします。

環境にhelm3がインストールされていない場合は以下の手順でインストールできます。
https://helm.sh/ja/docs/intro/install/

まずは検証用のnamespaceを作成。

$ kubectl create ns prod

そして作ったnamespaceにhelmチャートをデプロイ

$ helm install my-release my-repo/wordpress -n prod
NAME: my-release
LAST DEPLOYED: Wed Oct 12 02:18:03 2022
NAMESPACE: prod
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
CHART NAME: wordpress
CHART VERSION: 15.2.5
APP VERSION: 6.0.2

** Please be patient while the chart is being deployed **

Your WordPress site can be accessed through the following DNS name from within your cluster:

    my-release-wordpress.prod.svc.cluster.local (port 80)

To access your WordPress site from outside the cluster follow the steps below:

1. Get the WordPress URL by running these commands:

  NOTE: It may take a few minutes for the LoadBalancer IP to be available.
        Watch the status with: 'kubectl get svc --namespace prod -w my-release-wordpress'

   export SERVICE_IP=$(kubectl get svc --namespace prod my-release-wordpress --include "{{ range (index .status.loadBalancer.ingress 0) }}{{ . }}{{ end }}")
   echo "WordPress URL: http://$SERVICE_IP/"
   echo "WordPress Admin URL: http://$SERVICE_IP/admin"

2. Open a browser and access WordPress using the obtained URL.

3. Login with the following credentials below to see your blog:

  echo Username: user
  echo Password: $(kubectl get secret --namespace prod my-release-wordpress -o jsonpath="{.data.wordpress-password}" | base64 -d)

無事デプロイ完了し、サービスにアクセスできました。

あとは適当なブログ記事を書いたら下準備は完了です。

アプリケーションの登録

次に先ほどの検証用アプリケーションをACSに登録していきます。
公式ドキュメントも併せてご覧ください。

ACSでアプリケーションの保護を行う為には、まずACS上にアプリケーションを定義してあげる必要があります。
定義の仕方は以下の２通りがあります。

パターン①: namespace全体
namespace内のすべてのリソースをACSのバックアップ対象として定義

パターン②: namespace内の特定のリソース群
namespace内で特定のラベルが付いたリソース群をACSのバックアップ対象として定義

いずれのパターンにせよアプリケーションは特定の１つのnamespace内で完結している必要がある点に注意です。
つまり複数のnamespaceにまたがる様なアプリケーションはACSで管理ができません。

今回はパターン②、つまりnamespace内の特定のリソース群をアプリケーションとして登録します。
対象のラベルはhelmによって自動付与された"app.kubernetes.io/instance=<リリース名>"を利用します。

ACSへアプリを定義する前に念の為kubectlでリソースの内容を確認

# リリース名の確認
$ helm list -n prod
NAME      	NAMESPACE	REVISION	UPDATED                                	STATUS  	CHART           	APP VERSION
my-release	prod     	1       	2022-10-12 02:18:03.955440228 +0000 UTC	deployed	wordpress-15.2.5	6.0.2

# "app.kubernetes.io/instance=<リリース名>"というラベルが付いたリソースの一覧を確認
$ kubectl get all -n prod -l app.kubernetes.io/instance=my-release
NAME                                        READY   STATUS    RESTARTS      AGE
pod/my-release-mariadb-0                    1/1     Running   0             53m
pod/my-release-wordpress-6799967cb5-vgmng   1/1     Running   1 (49m ago)   53m

NAME                           TYPE           CLUSTER-IP       EXTERNAL-IP                                                                   PORT(S)                      AGE
service/my-release-mariadb     ClusterIP      10.100.47.177    <none>                                                                        3306/TCP                     53m
service/my-release-wordpress   LoadBalancer   10.100.128.152   a11be8760d14344e08c46c69949df1ce-743688330.ap-northeast-1.elb.amazonaws.com   80:32552/TCP,443:30615/TCP   53m

NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/my-release-wordpress   1/1     1            1           53m

NAME                                              DESIRED   CURRENT   READY   AGE
replicaset.apps/my-release-wordpress-6799967cb5   1         1         1       53m

NAME                                  READY   AGE
statefulset.apps/my-release-mariadb   1/1     53m

$ kubectl get pvc -n prod -l app.kubernetes.io/instance=my-release
NAME                        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
data-my-release-mariadb-0   Bound    pvc-4c2ea6b2-1f97-42fd-b342-3100db04907c   8Gi        RWO            fsx-nfs        53m
my-release-wordpress        Bound    pvc-2bc478fc-9bea-4374-bc18-506810c579aa   10Gi       RWO            fsx-nfs        53m

絵にするとこんな感じですね。
先ほど投稿したブログ記事などのアプリケーションデータはFSx上に払い出されたストレージボリュームの中、つまりk8sの外に格納されています。

それではACSの操作を行なっていきます。
まずはACSのGUIにログインし、ApplicationsメニューからDefineをクリックします。

• New application: 対象のアプリケーションに対してACS上の管理名を付与
• Cluster: 対象のアプリケーションがデプロイされたEKSのクラスタを選択
• Namespace: 対象のアプリケーションがデプロイされたnamespaceを選択
• Kubernetes label selector: 管理対象のリソース群をラベルセレクタで指定（上記で確認した内容）
  • ここでラベルセレクタの指定を省略すると、namespace内のすべてのリソースをアプリケーションとして管理することになります(上記のパターン①)

アプリケーションの定義が完了すると、k8sクラスタから取得したアプリケーションの情報が表示されます。
Application Protectionのセクションに警告マークがついていますが、これは該当のアプリに保護ポリシーが未設定のためです。
保護ポリシーの設定に関しては次回の記事で触れてみたい思います。

StorageタブにはアプリケーションがマウントしているPVの情報が表示されています。

ResourcesタブにはDeploymentやPVCなど、アプリケーションの構成情報が表示されています。

これでアプリケーションの登録作業は完了です。

まとめ&次回予告

今回の記事ではEKSクラスタにステートフルアプリケーションをデプロイし、ACSにそのアプリを登録しました。
これでACSでアプリケーションを保護することが可能となりましたので、次回はいよいよACSのメインの機能とも言えるスナップショット&バックアップを試してみたいと思います。

次回記事 -> EKS上のステートフルアプリケーションをまるごとバックアップ・リストアしてみた【③スナップショット&バックアップ篇】