Deployable Architectureを使って環境構築

# はじめに：Deployable Architectureとは
Deployable Architectureとは、お客様が安心してIBMのソフトウェアを利用することができるよう、ベストプラクティスに基づいた環境を自動構築するものです。技術的にはTerraformが使われています。
![スクリーンショット_2025-04-03_14_14_21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/1c5b9f1c-bd1b-4386-b61d-50c2b7597ea4.png)
# 検証内容
こちらの記事では、実際に```VSI on VPC landing zone```というDeployable Architectureを使って、環境をデプロイする手順、デプロイされるリソースの一覧とアーキテクチャ、払い出される環境の各種設定について書きます。


# 手順
## ```VSI on VPC landing zone```を新規Projectに追加
カタログから構築したい環境を選択し、既存または新規のProjectに追加します。今回は```VSI on VPC landing zone```を構築します。
カタログから構築したい環境をクリックするとこちらの画面が出てきます。
![スクリーンショット_2025-04-03_14_24_29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/92e2a2af-e46d-4dbf-b197-1061273e87be.png)
今回は、以下を選択しました。
* Architecture
    * Product version: v7.2.2
    * 環境を新規作成
* Variation
    * QuickStart

Variationは、構築される環境の非機能要件が異なるようです。
今回はQuickStartを選択しましたが、StandardというVariationを選ぶと、例えば可用性を高めるためにMZR構成にする、Activity TrackerとFlow LogsでIPトラフィック情報を収集する、セキュアにアクセス出来るようsite-to-site VPNを張るなどの非機能要件を満たすようにリソースが払い出されます。


## ```VSI on VPC landing zone(QuickStart)```のアーキテクチャ
こちらの図のようなアーキテクチャで払い出されます。ユーザーが1つ1つのコンポーネントを選んで組み合わせるのではなく、自動でベストプラクティスに基づいたアーキテクチャが組まれています。
![スクリーンショット_2025-04-02_11_19_32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/6b90fbe5-8cb8-471e-bb0d-b304727f4d46.png)

画面右側に載っているリソースが払い出されるようです。
![スクリーンショット_2025-04-03_14_48_17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/27e072f4-ed7b-498c-9129-4e90f79b962c.png)


## 権限設定
上記のように環境を選んでいくと、この環境を構築する為に必要となる権限が"Platform roles"、"Service roles"のように分類されて表示されます。これら全ての権限を満たすように、IAMで設定変更を行う必要があります。

![スクリーンショット 2025-04-03 14.32.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/641925c1-7de6-4dcb-b916-afe1d3be1867.png)


(ご参考：今回の検証では、権限を充足する為にAccess Groupを作成し、権限設定を行いました。Access Groupで設定しておくと後で削除しやすい、権限設定が残らないというメリットがあります。)

ここまで完了したら、Add to projectをクリックします。

:::note info
Projectとは、コードベースのデプロイメントやアカウントのメンバー間でのコラボレーションを容易にする為の単位です。デプロイする前に、コンプライアンスやセキュリティーといった観点で問題がないかスキャンしたり、構成のバージョン管理およびガバナンスを追跡したりするためのツールが含まれています。
:::

Projectを作成します。
![スクリーンショット_2025-04-03_16_41_24-2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/b0c49eb8-5da0-4469-abfa-c042f432c179.png)
以下の必須項目を入力します。
* project名:```egawa-kensyo```
* region:```Dallas(us-south)```
* resource group:```egawa-test```

"Create"をクリックしてProjectを作成します。

## Configurationを編集
作成したProject内の```deploy-arch-ibm-slz-vsi-cac5```の
```Configure``` > ```Security```と```Required```の項目を入力する必要があります。
![スクリーンショット_2025-04-03_17_17_48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/4199b215-4835-4520-b21f-41d0c9a1c1b3.png)

### APIキーを作成・登録
![スクリーンショット_2025-04-03_17_25_06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/7126f288-5e5d-4934-9d1b-096507d4cff9.png)
```Security```の項目に、APIキーを登録する必要があります。
まずはAPIキーを作成し、Secrets ManagerにAPIキーを登録します。
```Manage```>```Access(IAM)```>```API keys```と進むとこちらの画面が出てきます。自分のユーザーIDに関連づけられた自分のAPIキーを作成するため、"My IBM Cloud API keys"と表示されている状態でCreateします。
![スクリーンショット_2025-04-04_10_44_15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/ef4b73f0-e8f6-46d1-ad08-027d0763b1ad.png)

![スクリーンショット 2025-04-04 11.03.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/73762385-7f7f-41a2-b702-ea3198cae6af.png)
* APIキーの名前
* 説明(任意)
* 鍵情報が漏れた時のアクション
* APIキーがCLIでセッションを作成するかどうか

項目を入力して、"Create"をクリック

![スクリーンショット 2025-04-04 11.34.51.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/a94bc76a-99cc-417c-be72-4211526ceb1f.png)
作成されたAPIキーをコピーしておきます。

続いて、Secrets Managerに作成したAPIキーを登録します。
Secrets Managerとはシークレットと呼ばれる「秘密にしておきたい情報」を管理・保管するIBM Cloudのサービスです。既存のSecrets ManagerにSecretとしてAPIキーを登録します。
![スクリーンショット_2025-04-04_11_36_17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/9e91afd0-5562-4146-8f5a-3b36e095d98d.png)

![スクリーンショット 2025-04-04 11.48.35.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/2a5ef49b-d78d-4a6c-b2eb-b316105687a6.png)
APIキーは```Other secret type``` 
![スクリーンショット 2025-04-04 11.51.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/cfc3b314-1ced-44f8-bfe3-53cf4b3761f2.png)
以下の項目を入力
* Secretの名前
* 説明(任意)
* Secret Group
* ラベル(任意)

![スクリーンショット 2025-04-04 11.54.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/6ed9d70a-c005-41dd-a0fb-fdf9cade1ad2.png)
コピーしておいたAPIキーを入力します。

![スクリーンショット 2025-04-04 11.55.53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/2693165b-4a67-43e4-a10b-8fe178ed8d3b.png)
ここまで入力した項目を確認し、Addをクリックします。
これで、Secrets ManagerにAPIキーの登録が出来ました。

Project> ```deploy-arch-ibm-slz-vsi-cac5```に戻ります。
"API key using Secrets Manager"を選択し、APIキーを入力します。
![スクリーンショット 2025-04-04 11.57.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/f059ada7-4b20-4186-bda0-6ec6784362da.png)

この時、IAMでの権限設定が足りない状態でAPIキーを作成・登録してしまうと、Projectの"Needs attention"の項目や"Draft status"にこのような表示が出てきます。これが表示されている場合はどこか足りない部分があるので注意してみてください。
![スクリーンショット_2025-04-03_17_36_36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/8b3cf324-9738-4ded-b4d3-c69976e48797.png)



### SSHキーを登録
![スクリーンショット_2025-04-03_17_34_38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/6458b2e2-90ec-47d7-b1d2-c15235e168fa.png)
```Required```の項目に、SSHキーを登録します。

# Configurationの編集が完了したら、Validate
必要な項目を埋めたら、ConfigurationをValidateします。
![スクリーンショット_2025-04-04_12_03_53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/f071b9a0-cd73-4e3b-bded-aa41cd917a54.png)
Validate開始。コードエラーやコンプライアンスなどを検証しています。
![スクリーンショット 2025-04-04 12.06.28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/2a5652b2-1d09-43ae-aff5-8e949604b567.png)

Validationが終わると、承認を求められるので承認します。
デプロイが始まります。13分ほどかかると書いてあります。
![スクリーンショット 2025-04-04 12.07.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/513394ba-45be-4b6c-b810-82bb6ce6961e.png)
私の場合は、IAMの権限設定でいくつか不足があったため2度ほど失敗しました。View logsからどの段階でデプロイが失敗しているのか確認できるため、そちらを参照するといいです。

![スクリーンショット 2025-04-04 17.52.06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/d412c266-5346-4f27-89e3-80c1af14d671.png)
デプロイが完了しました。

# デプロイ結果
自動的に作成されたリソース一覧はこちらです。
IBM Cloudのサービスリソースというより、Schematicsから見たデプロイ単位のコンポーネントが一覧になっているようです。VPC、VSI、security group、address prefixなどが含まれていることがわかります。
![スクリーンショット 2025-04-04 18.01.41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/0457f9d9-264c-4988-9962-ac9d4ad71d92.png)
![スクリーンショット 2025-04-04 18.02.10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/3210eb25-e3e8-4497-b2ae-852d6fbb9567.png)

IBM Cloudのリソースとして払い出された名前でまとめてみました。
![https___qiita-image-store_s3_ap-northeast-1_amazonaws_com_0_3523945_6b90fbe5-8cb8-471e-bb0d-b304727f4d46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/939c96ac-dd66-4942-8a84-eff89d448e50.png)

* VPC①: ```land-zone-vsi-qs-management-vpc```　10.10.10.0/24
    * Resource Group: ```land-zone-vsi-qs-management-rg```
    * Security Group: ```management```
    * Subnet: ```land-zone-vsi-qs-management-vsi-zone-1```
    * VSI: ```land-zone-vsi-qs-jump-box-6612-001``` Reserved IP:10.10.10.4　FIP: 52.116.143.94
    * VNI: ```land-zone-vsi-qs-jump-box-6612-001-vni```


* VPC②```land-zone-vsi-qs-workload-vpc``` 10.40.10.0/24
    * Resource group: ```land-zone-vsi-qs-workload-rg```
    * Security Group: ```workload```
    * Subnet: ```land-zone-vsi-qs-workload-vsi-zone-1```
    * VSI: ```land-zone-vsi-qs-workload-server-580a-001``` Reserved IP: 10.40.10.4 
    * VNI: ```land-zone-vsi-qs-workload-server-580a-001-vni```
* Transit Gateway: ```land-zone-vsi-qs-transit-gateway```
* Key Protect: ```slz-kms```
    * Key: ```slz-vsi-volume-key```

# 各種設定
* "management"、"workload"と2つVPCがあり、"management"側にはFloating IPがついています。"management"を踏み台サーバとしてアクセスする想定で"workload"はPrivate IPのみついています。
* セキュリティグループ：Floating IPのついているVSIのある"management"には、デフォルトで22番ポートが開いていました。どのIPアドレスからもアクセスできるようになっているので、こちらは最低限の必要なアクセス元PC等のIPアドレスに絞っておくことをお勧めします。
* セキュリティグループは、10.0.0.0/8と161.26.0.0/16からの通信がデフォルトで許可されています。前者はプライベートのネットワークからの通信を通すもので、後者はIBM CloudのIaaSサービスからの通信ができるIPレンジとなっています。
* 今回は実施しませんでしたが、Projectのデプロイ前、Configurationを編集するところでTerraformのjsonをオーバーライドすることが出来るようです。Security Groupやサブネット、OSのイメージなどをあらかじめ変更、追加したい場合はこちらもご確認ください。

# ミニ検証
## Client PCからVSI①にSSH接続
VSI① ```land-zone-vsi-qs-jump-box-6612-001``` にmacからSSH接続してみます。登録しておいたSSHキーの秘密鍵を使って、FIP: 52.116.143.94に接続します。
![スクリーンショット 2025-04-21 18.51.10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/ff1f40fe-fd2e-440a-a4d4-b65b9de1833e.png)
接続できました。

## VSI①からVSI②にPingで疎通確認
VSI①からVSI② ```land-zone-vsi-qs-workload-server-580a-001```にPingを打ってみます。
![スクリーンショット 2025-04-21 18.53.39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/873debb1-ba59-4eee-ab20-7590c3c6e86a.png)
疎通できていることがわかりました。

## Client PCからVSI①にSSHキーをコピーし、VSI②にSSH接続
Client PCから、scpコマンドで秘密鍵をVSI①にコピーします。
```rb
scp -i /Users/haruna452201/.ssh/id_rsa /Users/haruna452201/.ssh/id_rsa root@52.116.143.94:~/.ssh/id_rsa
```
続いてVSI①にログインし、.sshのディレクトリに配置した秘密鍵を使ってVSI②にSSH接続します。
```rb
ssh -i ~/.ssh/id_rsa root@10.40.10.4
```
![スクリーンショット 2025-04-24 10.28.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/60431536-7004-4948-b5a9-391143a8a19a.png)
![スクリーンショット 2025-04-24 10.34.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/b3ff4319-dc40-4c4d-b0da-27be2682dc30.png)
VSI②```land-zone-vsi-qs-workload-server-580a-001```にSSH接続できました。

# 削除手順
削除したいProject (```"egawa-kensyo"```)の名前をクリック
![スクリーンショット_2025-04-25_12_27_29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/6c6734e6-3f73-490c-be7d-f1481352230b.png)
"Configuration"> 削除したいデプロイメントの"Undeploy"をクリック
![スクリーンショット_2025-04-25_12_28_28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3523945/d0e69b00-62b0-4819-a488-555926fec653.png)
Undeployが始まります。
Undeployが無事実行されると、こちらのProjectから、Deployable Architectureで払い出されたリソースの表示が無くなります。

:::note warn
私の場合は、Resource Groupの削除権限が足りず、一度Undeployに失敗しました。このような場合、
1. IAMで権限変更
2. APIキーを作成し直す
3. Secrets Managerの既存Secret(APIキー)を __"Rotate"__ する

ことをお勧めします。2のあと、3で"Rotate"ではなく新たにSecretを作ってしまうと、その新Secretを適用して再度Deployable ArchitectureのValidationとデプロイメントをしなくてはいけなくなってしまいます。
:::

その他後片付け
* Deployable Architectureのデプロイ用に作成したAccess Groupを削除
* Deployable Architectureのデプロイ用に登録したSecretを削除