💭

GCP Cloud Runの概括

2021/01/06に公開

1件

GCP

Cloud Run

tech

概要

フルマネージドのサーバーレスプラットフォーム。トラフィックに応じて自動でスケーリング。
コンテナをデプロイするから言語が自由。
Cloud BuildやCloud Loggingと統合されていてデプロイやログ収集が手軽。
従量課金。リクエストが処理されている間が請求対象。

シンプルな構成のマイクロサービスにはうってつけ。複雑な構成管理が必要ならGKE。

パフォーマンスに関して

注意とtips

レスポンスを返すとインスタンスのCPUアクセスが無効か制限されるのでバッググラウンドで処理しない。
メモリが使われるので一時ファイルは削除する。
動的型付け言語の場合はライブラリの数を最小限にする。そしてライブラリは遅延読み込みする。コールドスタートの時間を短くするため。
インスタンスは再利用されるのでグローバル変数を使って初期化を一度にする。GSCからのファイル読み込み、DBの接続。リクエストのレイテンシを減らすため。
使用頻度の低いグローバル変数の初期化は遅らせる。golangならsync.Onceで。コールドスタートの時間を短くするため。
gcloudignoreでビルドに不要なファイルを除外しアップロード時間を最適化。

イメージを小さくする

alpine、distrolessやscratchを利用する。
ビルドがツールに依存する場合はマルチステージビルドを使用する。

Dockerfile

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 --from=builder /app/server /app/server

CMD ["/app/server"]

キャッシュの利用

--cache-fromでキャッシュを利用する。
最初のビルド時はpullできないためエラーを処理する。

cloudbuild.yaml

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も必要ない。
引数はこことかに

cloudbuild.yaml

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以外のユーザーを使用する。

Dockerfile

...
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の利用

https://cloud.google.com/secret-manager

Cloud BuildでSecret Managerから機密データを取り出してCloud RunのDockerイメージに流す。
ステップ実行時の作業ディレクトリは持続的に利用できるので一時ファイルを保存して次のステップで利用できる。デフォルトで/workspaceというディレクトリ。
テキストファイルにシークレットを保存してDockerをビルド時に引数として渡す。
entrypointはシェルにしないと$()が使えない。

cloudbuild.yaml

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
...

Dockerfile

...
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

melodyclue 5ヶ月前

以下の記事において、「Secret Managerにシークレットを登録しておき、Cloud Runのデプロイコマンドを呼び出すときに環境変数として設定するのが安全だと思います。」と書かれていたのですが、これについてどう思いますか？