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

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

- [Astra Control Service(ACS)の導入](https://qiita.com/yshimizu22/items/11967a351e3b1ddde00f)
- Astra Control Service(ACS)の使い方
    1. **アプリケーションの登録 ←イマココ**
    1. [アプリケーションのスナップショット&バックアップ](https://qiita.com/yshimizu22/items/9e021dabc7db3c30a07b)
    1. [アプリケーションのリストア&クローニング](https://qiita.com/yshimizu22/items/9fd7935e7d78ba2f51ea)

# 前回までのおさらい
検証環境の構成図はこちら。
![スクリーンショット 2022-10-14 11.04.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/436161/0771a474-5592-9398-5a01-82856bb5d04b.png)

検証用のEKSクラスタは既にACS上に登録された状態になっています。
![スクリーンショット 2022-10-12 9.58.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/436161/f941a444-5a05-6e7f-031e-d6b12755a4bc.png)


# k8sアプリケーションをACS上に登録してみた
ここからが本編です。

## 検証用アプリケーションのデプロイ
何はともあれアプリケーションが無いと始まりませんので、まずはテスト用のアプリをEKS上にデプロイしていきます。
今回はこちらの[helmチャート](https://github.com/bitnami/charts/tree/master/bitnami/wordpress)を使って、定番のwordpressをデプロイします。

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

まずは検証用のnamespaceを作成。
```sh
$ kubectl create ns prod
```

そして作ったnamespaceにhelmチャートをデプロイ
```sh
$ 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)
```

無事デプロイ完了し、サービスにアクセスできました。
![スクリーンショット 2022-10-12 11.28.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/436161/5a842f99-3624-b28d-d78f-f80925c734f6.png)

あとは適当なブログ記事を書いたら下準備は完了です。
![スクリーンショット 2022-10-12 15.48.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/436161/fe74a0a4-8c14-6d17-9c09-3e2577f74401.png)

## アプリケーションの登録
次に先ほどの検証用アプリケーションをACSに登録していきます。
[公式ドキュメント](https://docs.netapp.com/us-en/astra-control-service/use/manage-apps.html)も併せてご覧ください。

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

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

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

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

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

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

```sh
# リリース名の確認
$ 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の外に格納されています。
![スクリーンショット 2022-10-13 13.14.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/436161/003a32e4-ae9e-64a5-c2e9-82b0bb9f1070.png)

それではACSの操作を行なっていきます。
まずはACSのGUIにログインし、**Applications**メニューから**Define**をクリックします。
- New application: 対象のアプリケーションに対してACS上の管理名を付与
- Cluster: 対象のアプリケーションがデプロイされたEKSのクラスタを選択
- Namespace: 対象のアプリケーションがデプロイされたnamespaceを選択
- Kubernetes label selector: 管理対象のリソース群をラベルセレクタで指定（上記で確認した内容）
    - **ここでラベルセレクタの指定を省略すると、namespace内のすべてのリソースをアプリケーションとして管理することになります**(上記のパターン①)

![スクリーンショット 2022-10-12 12.09.10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/436161/84ed40c9-1d80-2965-7219-5459123e0a68.png)

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

StorageタブにはアプリケーションがマウントしているPVの情報が表示されています。
![スクリーンショット 2022-10-12 13.24.05.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/436161/bf82a7a0-a3a0-7915-cc29-75fb944d80a5.png)

ResourcesタブにはDeploymentやPVCなど、アプリケーションの構成情報が表示されています。
![スクリーンショット 2022-10-12 13.26.44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/436161/0d9ecfa8-f66d-94d1-343f-0c55369086b8.png)

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

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

**次回記事** -> [EKS上のステートフルアプリケーションをまるごとバックアップ・リストアしてみた【③スナップショット&バックアップ篇】](https://qiita.com/yshimizu22/items/9e021dabc7db3c30a07b)