CloudRun
merutinちょっと違う
merutin
merutinわかりやすい
Cloud Run の主要なリソースはサービスです。Cloud Run サービスは、Pod オートスケーラーと一意のエンドポイントが組み込まれた Kubernetes Deployment のような高度な抽象化とみなすことができます。Kubernetes の Pod は、Cloud Run のインスタンスに対応します。Kubernetes Deployment は Cloud Run サービスに変換することをおすすめします（一度に 1 つのサービスに変換してください）。Kubernetes HorizontalPodAutoscaler と Kubernetes Service の一部の構成を Cloud Run サービスに統合することもできます。
merutinCloud SQL 接続がデフォルトであるのね。ふむふむ
merutinCPUの数が1以下の場合、同時リクエストが1になるらしい。すごい仕様だ
merutin認証
IAMを使った認証ができるらしい。外部からのアクセスを許可しない場合に利用しそう。
LBを使う場合はどうなるんだろう
merutinCloud Run が TLS を管理し、WebSocket、HTTP/2（エンドツーエンド）、gRPC（エンドツーエンド）をサポートします。
WebSocketもいけるの便利だな
merutinCloud IAM を使用してアクセス ポリシーを指定する。
上り（内向き）設定を使用してネットワーク アクセスを制限する。これは、VPC と内部サービスからの内部トラフィックのみを許可する場合に便利です。
Cloud Identity-Aware Proxy（IAP）で認証されたユーザーのみを許可する。
作成の画面からだとIAMのみに見えたけど、結構色々あるのね
merutinTransport Layer Encryption（TLS）
コンテナ内部はHTTP/1前提になっているのね。grpcは別だけど、まああんまり使ったことないからいいや
merutinIngressのコンテナがあるのね。
merutinNingxがメインのコンテナなのね
ingressコンテナっていうのは、外部の公開しているポートのコンテナってニュアンスっぽい
merutinterraformのサンプルがあるのうれしいですね
merutinトラフィックの急増やシステム メンテナンスなどの一部のケースでは、Cloud Run が短期間に最大インスタンス数を超えるインスタンスを作成することがあります。
merutinサンプルのコンテナで起動してみる
merutinIAM認証が必要な場合に直接リンクを踏むとForbiddenが発生する
merutin手前にロードバランシングを追加する
merutin設定するものは多いものの、バックエンドとしてCloudRunを指定する
merutinなんかエラーでた
An active proxy-only subnetwork is required in the same region and VPC as the forwarding rule.
merutin- サーバーレス ネットワーク エンドポイント グループ
- バックエンド サービス
- プロキシ専用サブネット
を作成する必要がある
merutin作成完了画面は割とあっさり
merutinLB通してもForbiddenは変わらず。インターネット通しているからかな
merutin内部のネットワークに絞ったものを作成してみる。
当然、作成したもののページは表示されず
Error: Page not found
merutinLB側にCloudRunの説明があった
merutinまとまっていてわかりやすい
merutinLBのターゲットごとに指定するバックエンドセキュリティポリシーでは、rate limitなどを設定できる
merutinこれ忘れてた
merutindeployのパターン。
gcloud run deploy は知らなかった。便利だわ
merutintutorialをやってみる
merutinデプロイ周りの話
merutin上記記事内で言及されていた内容
merutinCloudRunじゃないけど、LBからCloudRunを向けるときの複数サービスのやり方
defaultService: service
name: path-matcher-1
routeRules:
- matchRules:
- prefixMatch: /terraform
priority: 1
routeAction:
weightedBackendServices:
- backendService: service
weight: 100
urlRewrite:
pathPrefixRewrite: /
Cloud Run は、コンテナ イメージのローカルコピーを保存して、コンテナの起動時に非常に高速に読み込みを行う。
知らなかった。勉強になる
merutinそういや、Boostがあるのか
merutinパフォーマンスチューニングDeepDive
merutinスケールアウト中など、新しいインスタンスが起動されると、少なくともこのサービスのコンテナ インスタンスの平均起動時間の間はリクエストが保留されます。これには、ゼロからのスケーリングなど、リクエストでスケールアウトが開始されるタイミングも含まれます。
起動時間が 10 秒未満の場合、リクエストは最大で 10 秒間保留されます。
起動プロセスにインスタンスがなく、リクエストがスケールアウトを開始しない場合、リクエストは最大で 10 秒間保留されます。
merutinリクエストの処理中にのみ CPU を割り当てるように設定されたサービスの場合、Cloud Run はリクエストの処理中にのみ CPU 使用率に基づいてインスタンス数を自動スケーリングします。
CPU を常に割り当てるように設定されたサービスの場合、Cloud Run は、コンテナ インスタンスのライフサイクル全体で CPU 使用率に基づいてインスタンス数を自動スケーリングします。ただし、ゼロへのスケーリングとゼロからのスケーリングの場合は、リクエストのみを使用します。
そういえばこんな設定も。ただ、それなりに動作している場合は常に割り当てをしていた方が安いらしい
merutin現在、[リクエストの処理中にのみ CPU を割り当てる] を使用していて、次のような場合は、[CPU を常に割り当てる] のほうが経済的です。
Cloud Run サービスが、現在の多くのリクエストを一定の速度で処理している。
インスタンス数の指標で、アイドル状態のインスタンスが多くない。
merutinCPUを常に割り当てって後からできた機能なのね
merutinイメージ ストリーミング
merutinv1とv2の違い
merutin実行環境について
merutingcloud deployのコマンドで複数起動しているコンテナのデプロイをしてみた。
gcloud run deploy backend-for-test --image=asia-northeast1-docker.pkg.dev/xxxx
メインのコンテナのimageのみが更新されて、ほかは変更がないことを確認した。
コマンドのリファレンスにもそれっぽいことは書いてあり、指定してない場合はprimary ingress containerになるとのこと。primaryとは？という感じだが、おそらく最初に指定されている要素っぽい。
The following flags apply to a single container. If the --container flag is specified these flags may only be specified after a --container flag. Otherwise they will apply to the primary ingress container.