Deployable Architectureを使って環境構築

はじめに：Deployable Architectureとは

Deployable Architectureとは、お客様が安心してIBMのソフトウェアを利用することができるよう、ベストプラクティスに基づいた環境を自動構築するものです。技術的にはTerraformが使われています。

検証内容

こちらの記事では、実際にVSI on VPC landing zoneというDeployable Architectureを使って、環境をデプロイする手順、デプロイされるリソースの一覧とアーキテクチャ、払い出される環境の各種設定について書きます。

手順

VSI on VPC landing zoneを新規Projectに追加

カタログから構築したい環境を選択し、既存または新規のProjectに追加します。今回はVSI on VPC landing zoneを構築します。
カタログから構築したい環境をクリックするとこちらの画面が出てきます。

今回は、以下を選択しました。

• 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つのコンポーネントを選んで組み合わせるのではなく、自動でベストプラクティスに基づいたアーキテクチャが組まれています。

画面右側に載っているリソースが払い出されるようです。

権限設定

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

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

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

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

Projectを作成します。

以下の必須項目を入力します。

• project名:egawa-kensyo
• region:Dallas(us-south)
• resource group:egawa-test

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

Configurationを編集

作成したProject内のdeploy-arch-ibm-slz-vsi-cac5の
Configure > SecurityとRequiredの項目を入力する必要があります。

APIキーを作成・登録

Securityの項目に、APIキーを登録する必要があります。
まずはAPIキーを作成し、Secrets ManagerにAPIキーを登録します。
Manage>Access(IAM)>API keysと進むとこちらの画面が出てきます。自分のユーザーIDに関連づけられた自分のAPIキーを作成するため、"My IBM Cloud API keys"と表示されている状態でCreateします。

• APIキーの名前
• 説明(任意)
• 鍵情報が漏れた時のアクション
• APIキーがCLIでセッションを作成するかどうか

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

作成されたAPIキーをコピーしておきます。

続いて、Secrets Managerに作成したAPIキーを登録します。
Secrets Managerとはシークレットと呼ばれる「秘密にしておきたい情報」を管理・保管するIBM Cloudのサービスです。既存のSecrets ManagerにSecretとしてAPIキーを登録します。

APIキーはOther secret type

以下の項目を入力

• Secretの名前
• 説明(任意)
• Secret Group
• ラベル(任意)

コピーしておいたAPIキーを入力します。

ここまで入力した項目を確認し、Addをクリックします。
これで、Secrets ManagerにAPIキーの登録が出来ました。

Project> deploy-arch-ibm-slz-vsi-cac5に戻ります。
"API key using Secrets Manager"を選択し、APIキーを入力します。

この時、IAMでの権限設定が足りない状態でAPIキーを作成・登録してしまうと、Projectの"Needs attention"の項目や"Draft status"にこのような表示が出てきます。これが表示されている場合はどこか足りない部分があるので注意してみてください。

SSHキーを登録

Requiredの項目に、SSHキーを登録します。

Configurationの編集が完了したら、Validate

必要な項目を埋めたら、ConfigurationをValidateします。

Validate開始。コードエラーやコンプライアンスなどを検証しています。

Validationが終わると、承認を求められるので承認します。
デプロイが始まります。13分ほどかかると書いてあります。

私の場合は、IAMの権限設定でいくつか不足があったため2度ほど失敗しました。View logsからどの段階でデプロイが失敗しているのか確認できるため、そちらを参照するといいです。

デプロイが完了しました。

デプロイ結果

自動的に作成されたリソース一覧はこちらです。
IBM Cloudのサービスリソースというより、Schematicsから見たデプロイ単位のコンポーネントが一覧になっているようです。VPC、VSI、security group、address prefixなどが含まれていることがわかります。

IBM Cloudのリソースとして払い出された名前でまとめてみました。

• 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に接続します。

接続できました。

VSI①からVSI②にPingで疎通確認

VSI①からVSI② land-zone-vsi-qs-workload-server-580a-001にPingを打ってみます。

疎通できていることがわかりました。

Client PCからVSI①にSSHキーをコピーし、VSI②にSSH接続

Client PCから、scpコマンドで秘密鍵をVSI①にコピーします。

scp -i /Users/haruna452201/.ssh/id_rsa /Users/haruna452201/.ssh/id_rsa root@52.116.143.94:~/.ssh/id_rsa

続いてVSI①にログインし、.sshのディレクトリに配置した秘密鍵を使ってVSI②にSSH接続します。

ssh -i ~/.ssh/id_rsa root@10.40.10.4

VSI②land-zone-vsi-qs-workload-server-580a-001にSSH接続できました。

削除手順

削除したいProject ("egawa-kensyo")の名前をクリック

"Configuration"> 削除したいデプロイメントの"Undeploy"をクリック

Undeployが始まります。
Undeployが無事実行されると、こちらのProjectから、Deployable Architectureで払い出されたリソースの表示が無くなります。

私の場合は、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を削除