はじめに
今回は2024年末にGAされたVPCのPrivate Path機能を使ってサービスを公開する流れについて検証しましたので、その内容を整理しています。
Private Pathを使用することで、コンシューマー(エンドユーザー)はインターネットを経由せずに、直接IBM Cloudを介してサービスにアクセスすることが可能になるため、セキュアなサービス利用が可能になります。
本来はプロバイダーがIBM Cloud上にアプリやサービスを公開し、コンシューマーが利用することを想定していますが、検証の中でプロバイダー役として直接サービスを作成し、それをコンシューマー役としてアクセスする全体の流れが含まれています。
前提条件
今回の検証には以下の前提条件があります。
- プロバイダーとコンシューマーの両方のリソースをホストするためのIBM Cloud有料アカウントが必要です。
- プロビジョニングされたVirtual Server Instance(VSI)に接続するためのVPC用のSSH Keyが必要です。
- サービスの作成やアクセスには、Infrastructure as Code(IaC)を実現するためのTerraformベースの自動化ツールである「IBM Cloud Schematics(Schematics)」を利用します。それによってPrivate Pathサービスを含むプロバイダー側の環境、およびコンシューマー側の環境を自動的に構築して接続の確認します。
- Schematicsのリージョンは2025年現在、
ダラス(us-south)
、ワシントン(us-east)
、フランクフルト(eu-de)
、ロンドン(eu-gb)
の4箇所のみとなりますが、今回はフランクフルト(eu-de)で実施しました。
- Schematicsのリージョンは2025年現在、
- 今回使用するサービスはnginxベースのWebアプリサーバーです。
検証に使用するSSH KeyとVSIインスタンスは同じリージョンである必要があります。そのため、SSH Keyもフランクフルト(eu-de)
に作成ください。
プロバイダーとしてのサービス作成の流れ
まずは上記の通りプロバイダーとしてIBM Cloudにサービスを公開するため、Schematicsでワークスペースの作成、テンプレートの指定を行います。
コンソール
→ナビゲーション・メニュー
→Platform Automation
→Schematics
→Terraform
にアクセスします。
Terraform画面が表示されたら、ワークスペースの作成
をクリックします。
ワークスペース作成画面にてテンプレートを指定します。今回はすでにGithubに公開されているTerraformテンプレートのURLを使用しますので以下のURLを入力ください。
また、Terraformのバージョンを指定しますが、今回はterraform_v1.5
で実施しています。
設定が終わったら次へ
をクリックします。
https://github.com/IBM-Cloud/vpc-tutorials/tree/master/vpc-pps-basics/provider
完全リポジトリーを使用する
には必ずチェックを入れてください。
次は詳細を入力しますが、ここでワークスペース名とリソースグループ、リージョンを選択しいます。
ワークスペース名はなんでも大丈夫ですが、今回はプロバイダー役のワークスペースだとわかりやすくするためにpps-provider
にしています。
また、リージョンも前提で記載した通り、フランクフルトにしています。
設定が完了したら次へ
をクリックします。
全ての設定が完了したら作成
をクリックします。
作成されたワークスペースの設定
→変数
項目にて変数の修正を行います。前提条件として作成したSSH Keyやリージョンなどを指定します。デフォルトで値が設定されていますが、項目の右側の︙
にて編集を行います。
SSH Keyの値はexisting_ssh_key_name
にて設定できますが、ここではSSH KeyのIDや指紋、公開鍵などではなく、SSH Keyのインスタンス名をそのまま入力する必要があります。
Schematicsのワークスペースが作成されたら、テンプレートの設定を行います。
繰り返しとなりますが、SSH Keyのリージョンとワークスペースのリージョンは同じリージョンである必要があります。もし別のリージョンの場合、プランの適用が失敗になります。
なお、今回使ったアカウントの事情上、リソースグループの設定も行う必要がありました。似てような状況の方は必要に応じてリソースグループの変更も実施ください。
変数を全て設定したら、上端のプランの適用
をクリックします。
プランを適用することによって、スクリプト化されたコードが走り、変数で設定した項目通りにインスタンスがデプロイされるようになります。
なお、この作業にはデプロイのため数分ほど時間がかかる場合があります。
デプロイが完了したらリソース・リストにpps
という名前やタグでインスタンスがデプロイされていることがわかりますが、主に次のリソースが作成されます。
- 1つの仮想プライベートクラウド(VPC)
- 3つのサブネット(各ゾーンに1つずつ)
- 各サブネットに少なくとも1つの仮想サーバーインスタンス
- すべての仮想サーバーインスタンスを含むバックエンドプールで構成されたプライベートパスNLB
- Private Path Service
なお、作成されたVSIにアクセスし、ロードバランサーやPrivate Pass、SSH鍵がうまく紐づいたか確認ください。
Private Passの詳細に入るとCRNとサービス・エンドポイントを確認することができます。後ほどサービス公開の際に使用することになるので別途メモしてください。
ここまで実施したらプロバイダーとしてのサービス作成の流れは完了です。
コンシューマーとしてのサービスへアクセスの流れ
次はコンシューマーとしてのSchematicsワークスペースを作成します。全体的な流れはプロバイダー用のワークスペース作成と同じです。
以下のコンシューマー用リポジトリやTerraformのバージョン(terraform_v1.5)、ワークスペース名はコンシューマー用とわかりやすくpps-consumer
、リージョン(フランクフルト)などを入力し、作成
ボタンにてワークスペースを作成ください。
https://github.com/IBM-Cloud/vpc-tutorials/tree/master/vpc-pps-basics/consumer
また、ワークスペースが作成されたら、プロバイダー用ワークスペースと同様、SSH Keyやリージョン、リソースグループなどを入力します。
なお、その際にprovider_crn
変数にて、上でメモしたCRNを入力します。
その後、プランを適用
をクリックし、インスタンスデプロイを待ちます。
デプロイが完了したら、リソース・リストに名前やタグがconsumer
になったインスタンスが追加されていることがわかります。
なお、コンシューマー用インスタンスにはいかが作成されます。
- 1つの仮想プライベートクラウド(VPC)
- 2つのサブネット
- 各サブネットに1つのVSI
- プライベート パス サービス CRN と各サブネットに 1 つの IP アドレスが構成された 1 つのVirtual Private Endpoint(VPE)
この段階ではまだコンシューマーがプロバイダー提供のアプリにアクセスできない状況です。
Private Path サービスへの接続要求が審査され、許可されるのを待機している段階となります。
そのため、VPC用の仮装プライベート・エンドポイント・ゲートウェイにアクセスしたら状況
が処理待ち
になっていることを確認ください。
ここまでできたらコンシューマー用の作業は完了です。
コンシューマーのリクエストの承認
次はプロバイダー役に戻り、前の段階でコンシューマーが設定したアクセス申請を承認する必要があります。
Private Path Serviceリストに移動し、Schematicsで作成されたPrivate Pathの詳細画面にアクセスします。
その後接続要求
カテゴリーにて新たに入った承認待ちのリクエストを確認し、︙
にて許可をクリックします。
接続要求画面が表示されたら、再度許可
をクリックします。
その後、先ほどのVPC用の仮装プライベート・エンドポイント・ゲートウェイにアクセスすると処理待ち
が安定
に変わっていることがわかります。
コンシューマーからプロバイダーへの接続テストの流れ
プロバイダーから接続承認を行い、プライベートエンドポイントが有効になったら、最後にテストを行います。
仮装サーバーインスタンス(VSI)にアクセスし、割り当てられているFloating IP(浮動IP)を見つけます。
上記の通りVSIは3台作成されますが、その中で2台にFloating IPが割り当てられています。その二つのFloating IPをpingコマンドにて確認し、通信できるFloating IPを使用します。
私の場合は、以下の画面の中、vpc-pps-consumer-vsi-eu-de-2
がpingが飛んでいました。
ping <floating-ip>
pingコマンドにて通信できるFloating IPを見つけたら、次はSSH Keyで仮装サーバーにログインします。
ssh root@<floating-ip>
ログインできたら、サービスエンドポイントを呼び出してプロバイダー提供のアプリにアクセスします。
curl http://vpc-pps.example.com
Hello world from vpc-pps-provider-vsi-eu-de-1
もし以下のようにアクセスが失敗する場合、VSIに登録したSSH Keyが正しく指定されていない可能性があります。その時は以下の -i コマンドにてSSH Keyを指定する必要があります。
moonsy@moon ~ % ssh root@xxx.xxx.xxx.x
root@161.156.168.6: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
ssh -i ~/.ssh/key-moon-de_rsa.prv root@xxx.xxx.xxx.x
なお、上記のコマンドを入力しても再度以下のようなエラーが表示されることがあります。これはSSH KeyのPermissionが緩すぎるため、SSHが鍵を無視している状況です。
その場合にはchmod 600
コマンドにて解決できますが、こちらはSSH Keyの読み書きは所有者のみ可能にするPermissionを強化するコマンドです。
moonsy@moon ~ % ssh -i ~/.ssh/key-moon-de_rsa.prv root@xxx.xxx.xxx.x
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/Users/moonsungyun/.ssh/key-moon-de_rsa.prv' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/Users/moonsungyun/.ssh/key-moon-de_rsa.prv": bad permissions
root@xxx.xxx.xxx.x: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
moonsy@moon ~ % chmod 600 ~/.ssh/key-moon-de_rsa.prv
moonsy@moon ~ % ssh -i ~/.ssh/key-moon-de_rsa.prv root@xxx.xxx.xxx.x
Last login: Thu Jul 11 05:47:22 2024 from xxx.xxx.xx.xxx
[root@vpc-pps-consumer-vsi-eu-de-2 ~]#
ここまで実施したら、コンシューマーがプロバイダー提供のアプリにアクセスする流れは完了です。
全体公開の流れ
今回の検証は同一アカウント内、同一VPC内のコンシューマーに提供する検証でしたが、最後に別のVPCにいるコンシューマーに公開する流れは以下となります。
再度ナビゲーション・メニュー
→Infrastructure
→Network
→Private Path Service
にアクセスすると、先ほど作成されたPrivate Pathがあり、「公開済み」項目にいいえ
となっていることがわかります。右側の︙
にて公開
をクリックします。
再度公開
をクリックします。
すると、「公開済み」項目がはい
に変更になり、他のアカウントが仮想プライベート・エンドポイント (VPE) ゲートウェイを介してサービスに接続することができるようになります。
リソースの削除
最後にリソース削除についても簡単にご紹介したいと思います。
もしインスタンスが不要になった場合、本来であれば一つずつ削除を行う必要がありますが、Schematicsワークスペースで作成した場合には削除も一気に行うことができます。右上のアクション
ボタンをプルダウンし、リソースの破棄
をクリックし、インスタンスの削除を行います。
一つ注意点としては、こちらの画面でリソースの破棄
ではなくワークスペースの削除
をクリックしてもリソースは削除されません。あくまでもSchematicsのワークスペースはリソースをオーダーして削除する命令を行う道具であるため、ワークスペースを削除してしまうと一気に削除するように命令する道具がなくなることになります。そのため、もしリソース削除の前にワークスペースを削除した場合、手作業で一つずつリソースインスタンスを削除する必要があります。
リソースを破棄が完了したとのジョブメッセージが表示されると、リソースリストを確認してみます。ワークスペースインスタンス以外、全てのリソースが削除されたことがわかります。
その後最終的にアクション
→ワークスペースの削除
をクリックして、Schematicsのワークスペースを削除します。
参考
- IBM Cloud Docs