
Google Cloud FunctionsをServerless Frameworkで環境構築してみる
この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
本記事では、Google Cloud Functionsの構成要素などをServerless Frameworkで構築していきます。基本的に以下の公式ガイドを参照しています。
AWSのサーバーレス環境構築では、対応しているプラグインの数も多いことから、真っ先にServerless Frameworkを選択していますが、Google Cloudにおいても同様なのでしょうか?その辺りの手触り感を確認していきます。
環境構築
検証時の実施環境は以下の通りです。
- macOS Big Sur 11.6
- Node.js: v16.11.1 (nodebrewで構築)
- npm: 8.1.0
- Serverless Framework
- Framework Core: 2.62.0
- Plugin: 5.4.7
- SDK: 4.3.0
- Components: 3.17.1
- 開発言語
- Go 1.16.5 (homebrewで構築)
まずInstallationに沿って、Serverless Framework本体をインストールします。
$ npm install -g serverless
続いてQuick Startに沿って、リポジトリの作成します。公式のテンプレートからリポジトリを新規作成します。
$ serverless create --template google-go --path sls-gcp Serverless: Generating boilerplate... Serverless: Generating boilerplate in "/Users/haruta.takumi/go/sls-gcp" Serverless: Successfully generated boilerplate for template: "google-go" $ cd sls-gcp $ ls Makefile fn.go fn_test.go serverless.yml
serverless-google-cloudfunctionsをローカルにインストールします。
$ npm install --save serverless-google-cloudfunctions
$ cat package.json
{
"dependencies": {
"serverless-google-cloudfunctions": "^4.4.0"
}
}
$ ls
Makefile fn.go fn_test.go node_modules package-lock.json package.json serverless.yml
デプロイにはGoogle Cloud側のCredentials情報が必要です。Google Cloudの任意のプロジェクトにて、API Dashboardから以下のAPIを有効化します。
- Cloud Functions API
- Cloud Deployment Manager V2 API
- Cloud Build API
- Cloud Storage
- Cloud Logging API

続いてService Accountを発行します。IAM & Adminの画面から左メニューのService Accountsをクリックします。

Create service accountをクリックします。

サービスアカウント名を記入します。今回はServerless Framework側のリポジトリ名と合わせて sls-gcp としました。

以下のロールをアタッチします。
- Deployment Manager Editor
- Storage Admin
- Logging Admin
- Cloud Functions Developer

サービスアカウントに対する他のユーザー・グループのアクセス権限は、今回は付与しなくて大丈夫です。空欄のままDoneをクリックして作成完了です。

続いて認証に使うKeyを作成します。先ほど作成したサービスアカウントをクリックします。

KeysのタブからADD KEYをクリックし、認証情報の入ったJSONファイルをダウンロードします。JSONファイルは~/.gcloud/に配置しておきましょう。

デプロイ前にserverless.ymlの記述を以下のように修正します。
service: sls-gcp
provider:
name: google
runtime: go116 # 2021年10月17日時点ではプレビュー
region: asia-northeast1
project: haruta-takumi
credentials: ~/.gcloud/haruta-takumi-sls-gcp.json
frameworkVersion: '2'
plugins:
- serverless-google-cloudfunctions
package:
exclude:
- .npmignore
- node_modules/**
- package-lock.json
- package.json
functions:
hello:
handler: Hello # fn.go内の関数名
events:
- http: path
sls deployを実行します。出力ログ的にコンパイルもServerless Framework側でやってくれていますね。
$ sls deploy Serverless: Configuration warning at 'provider.runtime': should be equal to one of the allowed values [nodejs6, nodejs8, nodejs10, nodejs12, nodejs14, python37, python38, go111, go113, java11, dotnet3, ruby26, ruby27] Serverless: Serverless: Learn more about configuration validation here: http://slss.io/configuration-validation Serverless: Serverless: Packaging service... Serverless: Excluding development dependencies... Serverless: Compiling function "hello"... Serverless: Creating deployment... Serverless: Checking deployment create progress... .... Serverless: Done... Serverless: Uploading artifacts... Serverless: Artifacts successfully uploaded... Serverless: Updating deployment... Serverless: Checking deployment update progress... ....................................................... Serverless: Done... Service Information service: sls-gcp project: haruta-takumi stage: dev region: asia-northeast1 Deployed functions hello https://asia-northeast1-haruta-takumi.cloudfunctions.net/sls-gcp-dev-hello
Cloud Functions側では下記のような設定の下デプロイされてました。

関数の中身も確認できます。

先にDeployment ManagerのRoleを付与した通り、Serverless Frameworkの裏ではDeployment Managerによってリソースが生成されています。生成されたリソースはCloud StorageのバケットとCloud Functionです。

気になった点
今のServerless FrameworkでGoogle Cloudにデプロイすると、2回目以降も約7分くらい時間がかかってしまいます。Goランタイムだと遅いのか原因が掴みきれてないですが。デプロイする度にVersionが2つずつ上っていたり、リソースの差分だけ更新していなかったりと、挙動に無駄が多いのかなと予想しています。(差分更新せずに、都度新しいリソースを生成する仕様に関しては、Deployment Managerそのものの仕様だった気も)
Serverless Frameworkの開発自体もAWS向けがメインになっているみたいなので、AWSと同じ様な便利さを想像して使うには現段階では少し厳しいかなと感じました。表面的に使ってみての感想なので、あまり間には受けないでください。実際にServerless FrameworkでGoogle Cloudを使っている方がおりましたら、所感を聞いてみたいところです。
ひとまず個人としては、TerraformやDeployment Manager直で使うなどして代替案を探っていきます。







