はじめに
Cloud Functions第２世代（以下第２世代）が一般公開されてから大分時間が経ました。第１世代と第２世代の違いは公式ドキュメントや多くの技術記事でまとめられているので詳しく触れませんが、料金面、同時実行、サポートしているEventarcトリガーなどで違いがあり、公式は第２世代の利用をすすめているものの、場合によっては第2世代が利用できないケースがあります。この記事ではCloud FunctionsをTerraform管理しているプロジェクトでの注意点について触れていきます。
以下のケースに当てはまる場合は要注意
- インフラのリソース管理にTerraformを利用している
- Cloud FunctionsからCloud SQLに接続したい
1と２の両方に当てはまる場合、第２世代の利用は考え直したほうがいいかもしれません。Terraformで第２世代のリソースを管理する際のCloud SQLへの接続設定に壁がありました。
第２世代からCloud SQLに接続する
公式ドキュメントにあるとおり、第２世代からCloud SQLに接続する場合はCloud Runサービスの構成でCloud SQLインスタンスへの接続を有効にする必要があります。Google Cloudコンソールから設定する場合はとても簡単です。
TerraformでCloud SQL接続設定はどのように行う？
Terraform公式ドキュメントにはいくつかサンプルがあるものの、Cloud SQLの接続設定らしきものが見当たりません。第２世代の本体であるCloud RunサービスにCloud SQL接続設定を行いたいところですが、第２世代デプロイ時に自動作成されるためTerraform管理外です（という認識です）。
TerraformでCloud SQL接続設定するのは諦めて、手動で接続設定すればいいのでは？
手間がかかりますが、CLoud SQL接続設定以外の必要な設定をTerraformで管理し、デプロイ後にGoogle Cloudコンソール画面からCLoud SQL接続設定すればいいのではないかと考えました。が、この案も失敗しました。
Cloud Functionのソースコードを変更してTerraform経由で再デプロイすると、これまでの関数は破棄されて新しく作りなおされることがわかりました。当然Cloud Runサービスも作り直されるので、手動で設定した内容は全てリセットされます。関数のデプロイのたびにGoogle Cloudコンソール画面から手動設定するのであれば、もはやTerraformを利用する意味がなくなってしまいます。
Cloud SQLに接続している関数の移行は諦めた
今回は第１世代から第２世代への移行だったのですが、Cloud SQL接続設定に壁があるため移行を諦めました。Cloud SQL接続を行わない関数は予定どおり第２世代に移行させました。
今後の方針
TerraformでのCloud SQL接続設定でつまずきましたが、Cloud FunctionsにはCloud Runにはないメリットがあり、ケースに応じてCloud Functionsを利用したいところです。
私が思うCloud Functionsのメリットは
- Eventarcトリガーがサポートされていおり、設定が簡単
- 関数を書くだけでよい。コードの記述量が少なくて済む
- 同時リクエストを処理できる
特に1番目のEventarcトリガーのサポートは、Cloud Functionsを利用する大きなメリットだと思っています。同じことをCloud Run ジョブでやろうとするとWorkflowの設定などが必要になってきますが、Cloud Functionsだと簡単に設定できます。
もしくは第２世代は第１世代よりも料金が高いことから、第１世代のサポート終了が決定するまで第１世代を使うという選択肢もありかもしれません。
Discussion