Cloud Functions（第二世代）のドキュメントを読んでいくと、ソースのディレクトリ構造のサンプルとして以下のような構造が出てきます。

.
├── myfunction.go
├── go.mod
└── cmd/
    └── main.go

Source directory structure より

ドキュメントに出てくるようなシンプルな例ならこれでも十分かもしれませんが、Cloud Functions の関数も含めてモノレポにまとめて、共通部分を切り出して…などやっていく場合、どういう構成にすれば良いか悩む人も多そうだな、と。

そこで今回、一つの例として実際に実装してみたのでシェアします。

なお、Cloud Functions の前提知識として、前回の記事もあわせて読んでいただけると、分かりやすいかもしれません。

前提整理

Go言語で実装
複数のCloud Functions関数を同一リポジトリで扱う
- 実装例では Cloud Event 関数としているが、HTTP関数でも同様にできると思われる
Layered Architecture チックなソフトウェアアーキテクチャを想定
- usecase層や infrastructure 層などを関数間で共用するイメージ
- 今回は usecase層でログ出力するまでに留めています
internal/ ディレクトリを利用する（これには議論があるのは承知していますが、より縛りが強い状態での解決策を模索してみるために採用しています。）

実装してみたサンプルリポジトリ

ディレクトリ構造

.
├── event.go
├── go.mod
├── go.sum
├── cmd
│     └── function
│         └── event
│             └── main.go
├── env
│     ├── local
│     │     └── function
│     │         ├── a
│     │         └── b
│     └── prd
│           └── function
│               ├── a
│               │   ├── env.yaml
│               │   └── secret.yaml
│               └── b
│                   └── env.yaml
└── internal
      ├── domain
      │     └── model
      │         └── message
      │             └── message.go
      ├── ui
      │     └── function
      │         └── event
      │             ├── a
      │             │     └── function.go
      │             └── b
      │                 └── function.go
      └── usecase
          ├── a.go
          ├── b.go
          └── usecase.go

工夫ポイント1) init関数をまとめつつ、環境変数で serve する関数を切り替える

前回の記事で整理した通り、Cloud Functions のデプロイでは、go.mod/go.sum と init 関数を持つ go ファイルが配置されたディレクトリの配下が Cloud Storage にアップロードされ、Cloud Build でビルドされることになる。

init関数を提供する .go ファイルを関数ごとに用意することも考えたが、その場合共通実装部（例えば usecase層や infrastructure層）を各関数ディレクトリの配下にどうにか持ってくる必要が出てくる。

ドキュメントでは vendor/ の利用などが紹介されているが、ここで前提に置いた internal/ 縛りが効いてきて、利用できない状態になる。
（逆を言うと、internal/ を使っていなければ、各関数のディレクトリ配下に vendoring することで解決できると思われる。ただ、それに伴って生まれる複雑さ・課題がある点に注意が必要。）

そこで今回のサンプルでは、init関数は共通化し、環境変数でEntryPoint名をもらって、それごとに serve する関数を切り替える仕組みとしている。

func init() {
	name := config.MustGetFunctionEntryPointName()

	switch name {
	case "function_a":
		functions.CloudEvent(
			"function_a",
			eventA.CloudEventFunc,
		)
	case "function_b":
		functions.CloudEvent(
			"function_b",
			eventB.CloudEventFunc,
		)
	}
}

init関数を共通化したことで、テスト時や Cloud Functions 以外へホスティングする際に利用する cmd/function/event/main.go を同一の実装にまとめることができた。

なお、funcframework では、複数を serve した場合、curl するURLのパスで呼び分けもできる（※）。そのため、今回のサンプルでは EntryPoint 名は単一の想定にしているが、カンマ区切りなどで複数を受け取り全てを serve することにしても良いかもしれない。

※ 以下参照

...
func initServer() (*http.ServeMux, error) {
	server := http.NewServeMux()

	// If FUNCTION_TARGET is set, only serve this target function at path "/".
	// If not set, serve all functions at the registered paths.
	if target := os.Getenv("FUNCTION_TARGET"); len(target) > 0 {
...

工夫ポイント2) デプロイ時の Secret Manager 指定を yaml ファイルにする

今回のサンプルリポジトリでは、Github Actions でデプロイする Workflow サンプルも含めてみた。

Composite Actions で gcloud functions deploy コマンドを使用したデプロイ部分を作り、各関数ごとに Workflow 側でパラメータを渡してデプロイする形としている。

その中で、Secret Manager を使ったシークレット情報の注入について、少し工夫を入れてある。

gcloud functions deploy コマンドでは、シークレット関連のオプションとして以下が用意されている。

--set-secrets=[SECRET_ENV_VAR=SECRET_VALUE_REF,/secret_path=SECRET_VALUE_REF,/mount_path:/secret_file_path=SECRET_VALUE_REF,…]
--update-secrets=[SECRET_ENV_VAR=SECRET_VALUE_REF,/secret_path=SECRET_VALUE_REF,/mount_path:/secret_file_path=SECRET_VALUE_REF,…]

今回のサンプルでは、SECRET_ENV_VAR=SECRET_VALUE_REF の組み合わせのセットを yaml ファイルで定義し、shell でオプションを追加する方式としている。

以下、該当部の shell を参考までに記載しておく。

        if [ "${{ inputs.secret-env-vars-file }}" != "" ]; then
          secrets=$(awk -F ': ' '{print $1 "=" $2}' ${{ inputs.secret-env-vars-file }} | tr '\n' ',' | sed 's/,$//')
          CMD="$CMD --set-secrets=$secrets"
        fi

まとめ

以上、一つのリポジトリで管理するにあたって気になるであろう所を対応してみました。

もちろん、解き方は他にも色々あると思いますが、それを考えるきっかけにでもなれば幸いです。