GCP Cloud Runの概括
概要
- フルマネージドのサーバーレスプラットフォーム。トラフィックに応じて自動でスケーリング。
- コンテナをデプロイするから言語が自由。
- Cloud BuildやCloud Loggingと統合されていてデプロイやログ収集が手軽。
- 従量課金。リクエストが処理されている間が請求対象。
シンプルな構成のマイクロサービスにはうってつけ。複雑な構成管理が必要ならGKE。
パフォーマンスに関して
注意とtips
- レスポンスを返すとインスタンスのCPUアクセスが無効か制限されるのでバッググラウンドで処理しない。
- メモリが使われるので一時ファイルは削除する。
- 動的型付け言語の場合はライブラリの数を最小限にする。そしてライブラリは遅延読み込みする。コールドスタートの時間を短くするため。
- インスタンスは再利用されるのでグローバル変数を使って初期化を一度にする。GSCからのファイル読み込み、DBの接続。リクエストのレイテンシを減らすため。
- 使用頻度の低いグローバル変数の初期化は遅らせる。golangなら
sync.Once
で。コールドスタートの時間を短くするため。 - gcloudignoreでビルドに不要なファイルを除外しアップロード時間を最適化。
イメージを小さくする
alpine、distrolessやscratchを利用する。
ビルドがツールに依存する場合はマルチステージビルドを使用する。
FROM golang:1.15-alpine as builder
WORKDIR /app
COPY go.mod ./
COPY go.sum ./
RUN go mod download
COPY . ./
RUN GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -ldflags "-s -w" -mod=readonly -v -o server
FROM alpine:3.12.2
COPY /app/server /app/server
CMD ["/app/server"]
キャッシュの利用
--cache-fromでキャッシュを利用する。
最初のビルド時はpullできないためエラーを処理する。
steps:
- name: 'gcr.io/cloud-builders/docker'
entrypoint: 'bash'
args: ['-c', 'docker pull $_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:latest || exit 0']
- name: 'gcr.io/cloud-builders/docker'
args: [
'build',
'-t', '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:latest',
'--cache-from', '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:latest',
'.'
]
...
images:
- '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:latest'
...
あるいはKanikoでキャッシュする。
Kanikoでビルドしたら直接レジストリにアップロードされるためpushをしなくても良い。images attributeも必要ない。
引数はこことかに
steps:
- name: 'gcr.io/kaniko-project/executor:latest'
args:
- --dockerfile=Dockerfile
- --destination=$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:latest
- --cache=true
- --cache-ttl=24h
セキュリティに関して
- 定期的にビルド・デプロイし直し最新に保つ。
- root以外のユーザーを使用する。
...
ARG USER=docker
# alpineなのでadduser。debianやcentosならuseradd
RUN adduser --uid 60001 --no-create-home --disabled-password ${USER} \
&& echo ${USER}:${USER} | chpasswd
USER ${USER}
...
Secret Managerの利用
Cloud BuildでSecret Managerから機密データを取り出してCloud RunのDockerイメージに流す。
ステップ実行時の作業ディレクトリは持続的に利用できるので一時ファイルを保存して次のステップで利用できる。デフォルトで/workspaceというディレクトリ。
テキストファイルにシークレットを保存してDockerをビルド時に引数として渡す。
entrypointはシェルにしないと$()が使えない。
steps:
- name: gcr.io/cloud-builders/gcloud
entrypoint: 'bash'
args: [ '-c', "echo a_api_key=$(gcloud secrets versions access latest --secret=a_api_key) > secrets.txt" ]
- name: gcr.io/cloud-builders/gcloud
entrypoint: 'bash'
args: [ '-c', "echo b_api_key=$(gcloud secrets versions access latest --secret=b_api_key) >> secrets.txt" ]
- name: gcr.io/cloud-builders/docker
args: [ '-c', "docker build --no-cache -t $_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:latest .
-f Dockerfile $(cat secrets.txt | sed 's/^/--build-arg /')" ]
id: Build
entrypoint: bash
...
...
ARG a_api_key
ARG b_api_key
...
実行時に利用する場合。環境変数に入れちゃだめ。
Cloud Runのサービスアカウントにシークレットマネージャーにアクセスするためのロールが必要。
package main
import (
"context"
"fmt"
"os"
secretmanager "cloud.google.com/go/secretmanager/apiv1"
secretmanagerpb "google.golang.org/genproto/googleapis/cloud/secretmanager/v1"
)
func fetchSecret(ctx context.Context, name string) (string, error) {
path := fmt.Sprintf(
"projects/%s/secrets/%s/versions/latest",
os.Getenv("PROJECT_ID"), name)
client, err := secretmanager.NewClient(ctx)
if err != nil {
return "", fmt.Errorf("failed to create secretmanager client: %v", err)
}
req := &secretmanagerpb.AccessSecretVersionRequest{
Name: path,
}
res, err := client.AccessSecretVersion(ctx, req)
if err != nil {
return "", fmt.Errorf("failed to access secret version: %v", err)
}
return string(res.GetPayload().GetData()), nil
}
開発・運用に関して
ロールバック
gcloud run services update-traffic サービス名 --to-revisions リビジョン名=100
テスト環境
gcloud beta run deploy myservice --image イメージURL --no-traffic --tag stg
タグ付きでトラフィックをなしでデプロイすると、https://stg---hoge.run.app
のようなurlでテストできる。
サービスを無効にする
直接停止はできないのでroles/run.invoker(Cloud Run起動元)を外して無効にする。未認証であればallUsersを消す。
蓄積されるリビジョン
使われてないリビジョンはリソースを消費しないので料金は発生しない。
最大1000個で上限を超えると古いものから自動的に削除される。
認証に関して
開発者
curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" ${SERVICE_URL}
サービス間
Cloud Pub/SubやCloud Schedulerからのアクセスを自分で検証する場合はoidcトークンをそのままGoogleのサーバーに投げれば検証できます。
func verifyGoogleIdToken(idToken string) (bool, error) {
const endpoint = "https://www.googleapis.com/oauth2/v1/tokeninfo"
u, err := url.Parse(endpoint)
if err != nil {
return false, err
}
q := u.Query()
q.Set("id_token", idToken)
u.RawQuery = q.Encode()
res, err := http.Get(u.String())
if err != nil {
return false, err
}
defer res.Body.Close()
if res.StatusCode == 200 {
return true, nil
}
return false, nil
}
func main(w http.ResponseWriter, r *http.Request) {
...
idToken := strings.Split(r.Header.Get("Authorization"), " ")[1]
if bool, err := verifyGoogleIdToken(idToken); err != nil {
log.Fatal(err)
} else if !bool {
w.WriteHeader(http.StatusForbidden)
log.Println("The verification is not correct.")
return
}
...
}
ログ
- リクエストログ
サービスから送信されたログ。 - コンテナログ
コンテナインスタンスから送信されたログ。
収集される出力先
- 標準出力、標準エラー出力
- /var/log
- syslog(/dev/log)
- https://godoc.org/cloud.google.com/go/logging
構造化ログ
所定の形式でログを出力すると幸せになれる。
type LogEntry struct {
Message string `json:"message"`
// 重要度
Severity string `json:"severity,omitempty"`
// ログをまとめるために
// r.Header.Get("X-Cloud-Trace-Context")とProject IDから作成する
Trace string `json:"logging.googleapis.com/trace,omitempty"`
}
// Stringerインターフェイスを実装
func (l LogEntry) String() string {
if e.Severity == "" {
e.Severity = "INFO"
}
out, err := json.Marshal(e)
if err != nil {
log.Printf("json.Marshal: %v", err)
}
return string(out)
}
重要度を指定できたり。
- DEFAULT
- DEBUG
- INFO
- NOTICE
- WARNING
- ERROR
- CRITICAL
- ALERT
- EMERGENCY
traceでログを纏めて見やすくできたりする。リクエストに関連したコンテナログがリクエストログとくっついて表示される。
エラー
Cloud RunではCloud Error Reportingが自動的に有効になる。
stdout、stderrなどのログに書き込まれた例外はError Reportingで表示される。
自分でCloud Error Reportingに送信するには下記のライブラリを使用する。
Cloud Runのサービスアカウントにレポートの書き込み権限を付与して数分後に試してみる。
最後に
複雑なことはあまり考えずにサービスを提供できるのはすごく便利ですね。コンテナをデプロイするのでアプリケーションはある程度は自由が効きますし。他のGCPのサービスとの連携も容易で使い勝手が良いです。
Discussion
以下の記事において、「Secret Managerにシークレットを登録しておき、Cloud Runのデプロイコマンドを呼び出すときに環境変数として設定するのが安全だと思います。」と書かれていたのですが、これについてどう思いますか?