仮想マシンからプライベートCloud Functionsの呼び出し

はじめに

この記事は、
　Calling a private Cloud Function from a virtual machine
という動画を視聴し『実際にやってみた』という記事になります。

この記事でできるようになる事。

Compute Engine の VMインスタンス から、
SSH接続で、Cloud Functions を curl する。

Cloud Functions について簡単に理解しておく。

Cloud Functionsは、『イベント駆動』と呼ばれる、
特定のイベントやトリガーに応答して実行されるもので、
アプリケーションやサービスのバックエンドロジックを
サーバレスに実行する事が可能です。

このサーバーレスの特性により、開発者は関数のロジックにのみ
集中でき、インフラやサーバーの管理に関する手間が
大幅に減少し、開発の簡素化を実現することができます。

また、トラフィックの増減に応じたオートスケーリングや、
短い実行時間を持つ小さなタスク処理にも最適だとされています。

Google Cloud API を有効化

GCPプロジェクトのコンソールへ接続。

Compute Engine API
Cloud Functions API
Cloud Run Admin API
Cloud Build API
Cloud Logging API
Cloud Pub/Sub API

これらのAPIを有効化。
その他、APIの有効化は、必要に応じて、適宜行ってください。

仮想マシンがプライベートCloud Functions と通信できるようにするメリット。

• セキュリティ向上:
  プライベートCloud Functionsは、公開されていないプライベートな
  環境で実行されるため、外部からの不正なアクセスを避けることができる。
  仮想マシンからの専用通信路を利用することで、
  通信内容の保護やデータ漏洩のリスクを低減できます。

• レイテンシの低減:
  同一のクラウドプロバイダ内で通信が行われる場合、
  ネットワークの遅延が最小限に抑えられ、より迅速な応答が期待できる。

• データの一貫性:
  仮想マシンとCloud Functionsの間での直接の通信は、
  データの整合性や同期を維持しやすくなります。

• コスト削減:
  公開されているエンドポイントに対する
  外部トラフィックのコストが不要になる場合がある。
  特に、大量のデータを頻繁にやり取りする場合、
  このメリットは顕著になる可能性がある。

• 簡単な管理:
  プライベート接続を利用することで、
  公開エンドポイントの管理や、
  その他の公開に関する複雑さを排除できます。

• 拡張性:
  仮想マシンとプライベートCloud Functions間の通信は、
  システムの拡張やスケーリングが必要になった場合に、
  迅速かつ簡単に対応できるようになります。

内部トラフィックのリクエストのみを許可するCloud Functions を Deploy する。

まず、始めに、VMインスタンスが、プライベートCloud Functions を
呼び出せることを検証する為、内部トラフィックの
リクエストのみを許可するCloud Functions を Deploy します。

今回は、デフォルトのHello World 関数を使ってテストします。

Cloud Functions　に移動して、ファンクションを作成をクリック。

ファンクションの関数名の決定、およびリージョンの選択を行う。

トリガーはデフォルトで、HTTPSが選択されているので、
そのまま、『認証が必要』を選択する。

外部リクエストをブロックする為、接続は『内部トラフィックのみを許可する』を選択。

その他はデフォルトのまま、Cloud Functions の Deployを実行してください。

正常にDeployされたら、Cloud Functions の URL を
クリックして、リクエストが拒否される事を確認。

リクエストが拒否されていれば成功です。

GSAを作成して、適切なIAMロールを付与する。

動画では、デフォルトのサービスアカウントを使用していますが、
プラクティスは、編集者ロールや管理者ロールなどの強い権限を
付与するのではなく、その目的にあったカスタムロールを付与するのが
最良の選択ですので、必要最低限の権限の原則に基づいて、
サービスアカウントを作成し、必要なロールを付与します。

IAMと管理に移動して、『サービスアカウント』を作成をクリック。

『サービスアカウト名』と『サービスアカウントの説明』を
入力して、『作成して続行』をクリック。

ロールを付与する。
必要最低限の権限の原則に基づいて、
ロールは、
『Cloud Functions 起動元』
『Cloud Run 起動元』
を続けて選択して、『続行』をクリック、GSAを作成。

Cloud Functions 第2世代では、
Cloud Run 起動元 ロールが必要になります。

これは、Cloud Functions V2 の実行環境が内部的に
Cloud Run上で動いている事が理由に挙げられます。

仮想マシンからプライベートCloud Functions を呼び出す。

内部トラフィックのみを許可するように、Cloud Functions を
作成したら、仮想マシンから内部トラフィックを送信できるかを確認します。

Compute Engine から『インスタンスを作成』をクリック。

VMインスタンスの名前とリージョン、ゾーンを選択。

リージョンとゾーンは最寄りを選択する事。
リージョンとゾーンはVM作成後は変更できないので注意が必要。

適切なサービスアカウントを選択し、
その他はデフォルトのまま、作成を実行してください。

正常にVMインスタンスがDeployされればOK。

VMインスタンスをSSHで接続し、Cloud Functions を curl する。

SSHをクリック。

ブラウザでのSSHによるVMへの接続を許可。

DeployしたCloud Functions のURLをコピーしてください。

curl の後に続けて、先ほどコピーしたCloud Functions の
URLをペーストして、コマンドを実行してください。

サンプル

curl https://[REGION]-[PROJECT_ID].cloudfunctions.net/[FUNCTION_NAME]

ただし、この実行では、403エラーが返されます。

これは、Authorization ヘッダー による認証方法が選択されていない為です。
認証方法はいくつかありますが、今回は、『Bearerトークン』を使用します。

Bearerトークン については、詳細な説明は省きますが、
OAuth 2.0認証スキームの一部として使用されるアクセストークンの一つです。

詳しくは、こちらの記事を参考にしてください。

https://apidog.com/jp/blog/what-is-bearer-token/

Authorization ヘッダー で、認証方法にBearerトークンを
選択して、再度 curl コマンドを実行してください。

サンプル

curl https://[REGION]-[PROJECT_ID].cloudfunctions.net/[FUNCTION_NAME]　-H "Authorization: Bearer $(gcloud auth print-identity-token)"

『Hello World!』が表示されましたら、
仮想マシンからプライベートCloud Functionsの呼び出しは成功になります。

終わりに

今回の記事は、動画を視聴しまして、
実際に『手を動かしてみた』という内容でまとめました。

Cloud Functions でプライベート接続を
試してみようと思われていましたら、
参考にしていただけると幸いです。

あとで『じっくり読みたい』、『繰り返し読みたい』と
思ってくれましたら、『ストック』へ登録、
この記事が読まれている方にとって、
参考になる記事となりましたら、『いいね』を
付けていただけますと、励みになりますので、
よろしくお願いします。