Open65

GCPメモ

Marketplaceについて

インターネット上に存在するモノやサービスの売り手と買い手が自由に参加できる
取引市場のこと

GCPのマーケットプレイスではイメージが取引されている

設定済みのOSのインストールディスクのようなもの

簡単に設定済みのOSをセットアップできる

例:
wordpress with nginx and ssl certified by bitnami and automattic

サービスアカウントについて

アプリケーションからGoogle Cloudにアクセスする際に用いられるアカウント
※ユーザーではない

Compute Engine 仮想マシン(VM)インスタンスなどのアプリケーションや
コンピューティング ワークロードで使用される特別なアカウント

その認証情報(メール[1]と鍵)を利用して各種Google CloudサービスのAPIが実行される

サービスアカウントを一意に特定するために「メール」と呼ばれるアットマークを含んだ文字列が使われる

  • あるサービス アカウントの代わりとして、他のユーザーまたは他のサービス アカウントを使用
  • Google への認証とデータの署名に使用される公開 / 秘密 RSA 鍵ペアに関連付けられている

サービスアカウントの種類

1.GCP管理のサービスアカウントキー

2.ユーザー管理キー

付与できる操作の権限

権限は全て API で管理されており、サービス名、リソース、動詞という命名規則をもって定義されている

Google グループに役割を付与する方法が望ましい

権限の対象

「何に対して」権限の対象は、組織、フォルダ、プロジェクトに設定でき、一部のサービスリソース、請求先アカウントは個別に、さらに権限を設定していくことができる

Google Cloud のリソースを企業で利用する場合は、階層構造を作ることができる上位階層で付与した権限は下位の階層に継承される

上位で設定された権限は、下位のリソースで剥奪することが不可

マネージャーがフォルダ全体の閲覧権限をもっていて、見られたくないプロジェクトからその閲覧権限を剥奪することは出来ない

サンドボックスフォルダに対して、全デベロッパーがプロジェクト作成権限を持つことで自由に検証をする環境を整えておくも可能

フォルダ戦略

企業/部署の中で、権限を移譲できる単位で分けるのが理想

環境別

---組織---
本番フォルダ             開発フォルダ
Aプロジェクト, Bプロジェクト     Aプロジェクト, Bプロジェクト

機能別

---組織---
機能Aフォルダ            機能Bフォルダ
本番, 開発              本番、開発

チーム別

---組織---
事業部1フォルダ           事業部2フォルダ
本番, 開発              本番、開発

フォルダのルール

  • フォルダのネストレベルは 10 個まで
  • 親フォルダ内に作成できるフォルダは 300 個まで
  • フォルダの表示名は、階層内の同じレベルでユニーク

アクセス制御

Identity-Aware Proxy (IAP)
App Engine, Compute Engine, LBへのアクセスをユーザー単位で許可できる

IAM Conditions
どのような条件下で実行できるか設定できる

Access Context Manager
Google Cloud のプロジェクトとリソースに対する属性ベースのアクセス制御を定義

例:
アクセス元のデバイス、OS、IPアドレス、ユーザーID

VPC Service Controls
境界と呼ばれる仮想環境を作り、アクセスとデータの流れを制御する

VPC におけるFirewallみたいなもの
BigQuery や Cloud Storage などに保管されているデータの
プロジェクトからの持ち出し防止

公式:

https://cloud.google.com/iam/docs/service-accounts?hl=ja

引用資料:

https://medium.com/google-cloud-jp/google-cloud-access-management-40963bea0dfc
https://zenn.dev/prayd/articles/10366280752b01

https://qiita.com/t-yotsu/items/5d3d36847fbc71b72b76

Cloud Asset Inventoryについて

Google Cloud上のアセットを管理できるサービス

アセット

  • リソース

Compute Engine 仮想マシン(VM)やCloud Storage バケットなどの
  Google Cloud上で作成されたリソースのメタデータ

  • ポリシー

IAMポリシー、Organizationsポリシーなど、誰が何にアクセスできるかという情報(ポリシーのメタデータ)

引用資料:https://tech.nri-net.com/entry/gcp-cai

Cloud SQL Auth Proxy

概要:

TLS 1.3 と 256 ビット AES 暗号を使用して、データベースとの間で送受信されるトラフィックを自動的に暗号化

SSL 証明書はクライアントとサーバーの ID を確認するために使用され、データベース プロトコルから独立する為、管理不要

公式資料:

https://cloud.google.com/sql/docs/mysql/sql-proxy#what_the_provides

Stackdriver Error Repotingとは Terraformにおける有効化

アプリケーションのエラーをレポートし、デプロイした Web アプリケーションのバグ修正や障害の対応に役立てる情報を提供するためのサービス

NewRelic、Datadog等

https://www.topgate.co.jp/gcp23-stackdriver-error-reporting

Terraformにおける有効化

書き込み権限の場合、ロールから探して追加

ロール→error reporting 書き込みでフィルタリング

"roles/errorreporting.writer" = [
      "serviceAccount:〜〜〜.iam.gserviceaccount.com",
    ]

GKEのNode Poolについて

node(仮想マシン)のグループを作成する機能
1つのクラスタの中で複数の実行環境を管理するもの

Google Cloudの多彩なサイズのマシンタイプ(n1-standard, n1-hignmem, …)から
処理能力の異なるプールを作成できる

例:
DBMSはCPU/メモリ性能の高いプール、Webフロントは比較的低スペックでマシン数の多いプール、
というように特性に合わせたハードにコンテナをアサインすることが可能

https://unicorn.limited/jp/rd/kubernetes/20160627-k8s-node-op.html#:~:text=Google Kubernetes EngineのNode Pool,-Googleのkubernetes&text=これはnode(仮想マシン,を管理するものです。

FirebaseとCloud Firestoreとの違い

Firestore:

mBaaSと呼ばれるサービス mobile backend as a Service
iOS/AndroidアプリやWebアプリケーションの開発に活用できるプラットフォーム
モバイルアプリ開発のバックエンド側のインフラを提供

Cloud Firestore:

非常にスケーラブルなクラウドホスト型のNoSQLリアルタイムデータベース

記事:

https://ichi.pro/firebase-to-googlecloud-cloud-firestore-to-no-chigai-wa-nani-desu-ka-71408063245598

https://udemy.benesse.co.jp/development/system/what-is-firabase.html

Pub/Subについて

publisher / subscriber

パブリッシュ/サブスクライブ・メッセージング方式を使用してメッセージ (パブリケーション) をそれぞれ送信および受信するアプリケーション

パブリッシャー:情報の提供者

サブスクライバー:有料テレビの契約者や雑誌の予約購読者

参考記事:

https://qiita.com/t-yotsu/items/b578d7e12692d046ef9c

IAP詳細

Identity-Aware Proxy

Google のアカウントを使ってセキュアにリソースに接続できるプロキシサービス
ユーザーとアプリケーションの間に入って通信を仲介する

アプリへのアクセスを許可するユーザーを管理者が制御でき、従業員はVPNを利用しなくても安全にウェブベースのアプリケーションにアクセスできる

公式:

https://cloud.google.com/iap/docs/concepts-overview?hl=ja

解説記事:

https://qiita.com/dirtymosschan/items/fd11001daa68d7c8d943
https://www.nec-solutioninnovators.co.jp/ss/insider/security-words/50.html

グローバルロードバランサー

マルチリージョンにデプロイされたサービスにアクセスする場合に使用する

  • HTTPロードバランサー、TCPプロキシ、SSLプロキシでグローバルな負荷分散をサポート
  • HTTPロードバランサはユーザーに最も近いリージョンにリクエストをルーティング(グローバルな絵にキャストIPアドレスを使用)

ユースケース

  • バックエンドが複数のリージョンに分散されている
  • 1つのエニーキャストIPアドレスを使用してコンテンツやアプリケーションにアクセスできるようにする

リージョンロードバランサー



シングルリージョンにデプロイされたサービスへアクセスする場合に使用する

  • HTTP、TCP、UDPロードバランサでサポート
  • パブリックIPアドレス、またはプライベートIPアドレスを持つことができる
  • 任意のTCPポート、またはUDPポートを使用できる


    ユースケース

  • 1つのリージョンに複数のバックエンドがあり、IPv4終端が必要な場合
  • HTTPリージョン負荷分散は内部トラフィックのみ対象
  • TCP/UDPの内部負荷分散では、プライベートIPアドレスの内部で分散が可能

※パブリックIPを持つロードバランサの場合、SSLを使用して保護する

Cloud CDNの活用

グローバルに分散しているエッジ拠点を使用して、コンテンツの配信にかかる時間を短縮する
ネットワークレイテンシの低減やサービス料金の低減などのメリットがある

Cloud CDNはグローバル HTTP(S)ロードバランサで使用される

動作

HTTP(S)ロードバランサに対してコンテンツのリクエストが作成される

ユーザーに近い拠点にあるGFE (Google Front End)にリクエストが送信される

バックエンドにCloud CDNが構成されている場合、GFEはCloud CDNキャッシュ内でリクエストに対するレスポンスを探す

見つかった場合、GFEはキャッシュに保存されたレスポンスをリクエスト元に送信

キャッシュ内でレスポンスが見つからなかった場合、GFEは適切なバックエンドに対してリクエストを作成

CDNを使用するには、ロードバランサでプレミアムティアネットワークを使用する必要がある

Cloud VPN

IPSec VPNトンネルを使用して接続する
サポートされてるプロトコルはIPSecのみ

ユースケース

  • データ量が少ない接続
  • 低レイテンシと高可用性を必要としない場合

最小権限の原則

定義:

職務を行うために最小限必要な権限一式だけをユーザーに付与する手法のこと

  • IAMを使用して最小権限の原則を適用する
  • ログインを使用してユーザーを識別する
  • サービスアカウントを使用してマシンとコードを識別する
  • IAMロールをユーザーとサービスアカウントに割り当て、実行できるアクションを制限する

職掌分散

1 人の個人が悪意のある操作を行うのに必要なすべての権限を持たないようにするという概念

  • ユーザーによるデータの変更や削除は必ず検出される
  • どのユーザーも機密データを盗み出すことはできない
  • どのユーザーにも機密性の高いシステムの設計、実装、レポートを担当させない

目的:

利害の対立の防止
管理不全の検出

ユーザー・プロジェクト・ロール・ポリシーなどの整理

  • メンバーはログインで識別される
  • ロールは単なる権限のリスト

ポリシーはロールをユーザーに割り当てるための手段
ポリシーには一連のユーザーを設定し、ロールを割り当てる

ロールとユーザーのそれぞれの組み合わせはバインディングと呼ばれる

ポリシーはリソース階層の任意の場所に設定可能

組織、プロジェクト、個々のリソースに設定できる

ロールは個人ではなく、Googleグループにロールを付与する

  • 職務よりも細分化したグループが作成可能
  • 複数のグループ(閲覧のみのグループなど)を使用すると管理が容易

ロール

  • カスタムのロールよりも事前定義されたロールを優先する
  • オーナーと編集者のロールの使用を制限する
  • ロールを割り当てる際は階層による継承を考慮する

サービスアカウントについて

マシン、アプリケーションのIDとして使用可能

  • ロールを割り当てて付与された権限のみで実行可能
  • 作成時にキー(json)が生成されて認証に使用可能
  • サービスアカウントごとに10個のキーが作成可能

サービスアカウントを使用してCLIを構成可能

gcloud auth activate-service-account --key-file=[キーファイルパス]

Cloud Endpointsについて

  • 公開APIを保護してモニタリングする
  • APIにアクセスできるユーザーを制御する
  • JSONウェブトークンとGoogle APIキーを使って全ての呼び出しを検証する
  • 他のリッチな機能としてApigeeも提供されている

Cloud Armorについて

Google 製のクラウド型 WAF
Web アプリケーションに対する "SQL インジェクション", "クロスサイトスクリプティング" といったアプリケーションレイヤの攻撃を検知し、防御するための仕組み

事前定義したルールによりブロック

  • IPアドレス又はIPアドレスの範囲を使用して、Google Cloudリソースへのアクセスを許可、または拒否可能
  • 既知のアドレスを許可するホワイトリストを作成する
  • 既知のアドレスをブロックするブラックリストを作成する

ルール言語を用いて、リクエストヘッダー、地理的な位置、IPアドレス、Cookieなどを基準にトラフィックを許可または拒否できる

Cloud Armor は全ての Web アプリケーションに使えるわけではない

Google Cloud のロードバランサーである Cloud Load Balancing の背後にある Web アプリケーションのみ を保護できる

https://blog.g-gen.co.jp/entry/cloud-armor-explained

GCPの暗号化について

デフォルトで保存データをサーバ側で暗号化する

  • データ暗号鍵(DEK)にはAES-256対称鍵が使用される
  • 鍵は鍵暗号鍵(KEK)で暗号化される
  • マスター鍵はGoogleがCloud KMSで管理
  • 鍵は自動的かつ定期的にローテーションされる
  • 承認済みユーザー アクセスによる復号は臨機応変に行なわれる

顧客管理用の暗号鍵取扱について

  • Cloud Key Management Service(KMS)を使用してクラウドで作成する
  • 顧客環境内で作成してGCPに提供
  • API呼び出しごとに呼び出し側アプリケーションでCSEKを指定する
  • Googleは鍵をRAMのキャッシュにのみ保存
  • 単一のペイロード、あるいは戻りデータのブロックが復号される

機密データの保護

Data Loss Prevention APIで機密データを検出して秘匿化する

  • Cloud Storage、BigQuery、Datastore内のデータがスキャンされる
  • 画像スキャンも可能
  • メール、クレカなどの情報が検出される
  • 独自の情報タイプを追加可能
  • 機密データを削除、マスキング、トークン化できる

電車で読む用
ログ周りのドキュメント

必見 わかりやすく解説

https://please-sleep.cou929.nu/cloud-monitoring-metrics-fundamental-concepts.html

Terraform で Stackdriver の通知設定をする

https://qiita.com/sonots/items/64b9ee1e2d39eaf57ac9

Kubernetes Engine で動作するアプリでのロギングの使用

https://cloud.google.com/blog/ja/products/management-tools/using-logging-your-apps-running-kubernetes-engine

ログ エクスプローラを使用したサンプルクエリ

https://cloud.google.com/logging/docs/view/query-library-preview#kubernetes-filters

公式 ログ エクスプローラでクエリを作成

https://cloud.google.com/logging/docs/view/building-queries

ログエクスプローラーのクエリで問題を検知する

ログエクスプローラーのクエリでk8sのCronjobに絞って問題を検知する

こんな感じでいける

resource.type="k8s_cluster" severity>=WARNING
resource.type="k8s_cluster" resource.labels.location="asia-northeast1"
resource.labels.cluster_name="対象クラスター名"
jsonPayload.involvedObject.kind="CronJob"

参考:

https://www.m3tech.blog/entry/gke-events-log-monitoring
公式:
https://cloud.google.com/logging/docs/view/query-library-preview?hl=ja#using-queries

フィルタリングと集計

google_monitoring_alert_policyのaggregationsなどに使うパラメータの理解用

フィルタリング: 一部のデータを対象から除外
集計: 指定した分割項目に基づいて、複数のデータを小さなセットに結合

フィルタリング

関心のないデータを非表示にする。
時系列データは、時間、1 つ以上のラベルの値に基づいてフィルタリングする

  • 時間
  • 1 つ以上のラベルの値

集計

データの量を減らすために集計または集約する

  • 単一の時系列内のデータ内で、アライメントまたは正則化
  • 複数の時系列の縮小または結合

alignment 整列

生データが時間で正規化された新しい時系列を作成し、他のアライメントされた時系列と結合できるようにする

  • 時系列を定期的な時間間隔に分割する
  • アライメント期間のポイントに対して単一の値を計算

アライメントによって作成された新しい時系列は、アライメント期間内の生の時系列のすべての値を単一の値で表すため、系列内縮小または系列内集計と呼ばれる

時間間隔の正則化

時系列データを分析するには、データポイントを一定間隔の期間内で利用できるようにする必要あり。アライメントはこの処理を行うためのプロセスになる。

データポイント間に一定の間隔を持つ新しい時系列(アライメント期間)を作成

アライメント期間

次の 2 つの要因によって決まる

  • データ内で検索しようとしている粒度
  • データのサンプリング期間、レポートの頻度

粒度:

2、3 時間のスパン以内に何かが発生したことがわかっていて、さらに深掘りしたい場合はアライメントに 1 時間または何分かを使用する

サンプリングレート:

アライメント期間がサンプリング期間と同じ場合、各アライメント期間には 1 つのデータポイントが存在する。たとえば、max、mean、min のいずれかのアライメントを適用すると同じアライメント時系列になる

アライメント期間を選択する際はサンプリング期間よりも長くするが、関連するトレンドを表示できるくらいに短くする

Aligner

データをアライメント期間に分割した後、その期間のデータポイントに適用する関数(Aligner)を選択する

オプションには、値の合計、値の最大値、最小値、平均値の検索、選択したパーセンタイル値の検索、値のカウントなどがある

例:

期間 値 Aligner: MAX Aligner: MEAN Aligner: MIN
1:01–2:00 400, 350, 300, 200 400 312.5 200
2:01–3:00 200, 100 200 150 100
3:01–4:00 300, 250, 200 300 250 200

COUNT は、アライメント期間内の値の数をカウントします。
SUM は、アライメント期間のすべての値を合計します。
NEXT OLDER は、期間内の最新の値をアライメント値として使用します。

Reducer

一連の時系列の値に適用され、単一の値を生成する関数

Reducer のオプションは、アライメントされた値の合計や、最大値、最小値、平均値の検索など

上記の表のアライメントされたデータを使用して、Reducer を選択し、値に適用する

例:

アライメントの境界 Reducer: MAX Reducer: MEAN Reducer: MIN Reducer: SUM
2:00 400 281.9 133.3 845.8
3:00 433.3 288.9 150 866.7
4:00 350 300 250 900

公式:

https://cloud.google.com/monitoring/api/v3/aggregation?hl=jak

Aligner 英語ドキュメント:

https://cloud.google.com/monitoring/api/ref_v3/rest/v3/projects.alertPolicies#Aligner

メトリクス・アラートリソースのフィルターをヒアドキュメントで可読性高くする

改行やAND, ORが簡単に使えて可読性も良くなるので切り替え中

利用例:

      "filter" = <<-EOF
        severity>=WARNING
        httpRequest.status>=500
        resource.labels.backend_service_name=~""
      EOF

転送とストレージの概要

ログルーター

ログエントリが、entries.write の呼び出し中にlogNameフィールドで指定された
Google Cloud リソース に送信される

Cloud Logging API を介してログエントリを受信し、その過程でログエントリはログルーターを通過

ログルーターのシンクは
Cloud Logging バケットなどログエントリの送信先として設定する必要がある宛先を判別

既存の包含フィルタと除外フィルタと照合各ログエントリを確認

ログルーターはログを一時的に保存する処理も行う

シンク

Cloud Logging がログをルーティングする方法を制御する

ログの一部またはすべてをサポートされている宛先に転送できる

シンクは特定の Google Cloud リソース(Cloud プロジェクト、請求先アカウント、フォルダ、組織)
に属する

リソースがログエントリを受信

↓リソースに含まれるシンクと有効になっている場合

リソース階層に属する祖先シンクに従ってログエントリを転送

Cloud プロジェクト、請求先アカウント、フォルダ、組織ごとに
2 つのシンク(_Required と _Default)が事前定義されている

シンクは別々に動作する
事前定義されたシンクが独自のシンクを作成

ログの一部またはすべてを選択できる宛先に転送
Cloud Logging で保存されないようにログを除外

各シンクを転送する際の動作は、
シンクの包含フィルタと除外フィルタを構成することによって制御

包含フィルタ

包含フィルタを設定すると、特定のログを選択するようにシンクを構成できる
1 つ以上の除外フィルタを設定して、シンクのエクスポート先からログを除外

除外フィルタ

複数の除外フィルタを設定して、
一致するログエントリをシンクの宛先へのルーティングや Cloud Logging による取り込みから除外

ログの保存、表示、管理

Google Cloud プロジェクト、請求先アカウント、フォルダ、組織で
ログデータを保存して整理するためのコンテナとしてログバケットを使用
ログデータを保存、整理する

Cloud Logging に保存したログはインデックスに登録されて最適化され、
ログをリアルタイムで分析できるように配信される

公式:

https://cloud.google.com/logging/docs/routing/overview?hl=ja

Cloud Loab Balancingまとめ

特徴

  • 単一のエニーキャスト IP アドレス
  • レイヤ 4 /レイヤ 7 のロード バランシング
  • 外部ロードバランシング/内部ロードバランシング
     →インターネットからアプリケーションにアクセス:外部
     →Google Cloud内のアプリ間通信:内部
  • グローバル ロードバランシング/リージョンロードバランシング
     →ロード バランシングされたリソースを単一または複数のリージョンに分散

公式:

https://cloud.google.com/blog/ja/products/serverless/serverless-load-balancing-terraform-hard-way

gcloud sshコマンド

gcloud compute ssh --project=プロジェクト名 --zone=ゾーン名 インスタンス名

資料:

https://jpdebug.com/p/2304549

スナップショットを権限つきで作成する

gcloud compute snapshots create  スナップショット名 \
    --source-disk ディスク名 \
    --source-disk-zone ゾーン名 \
    --project プロジェクト名 \
    --impersonate-service-account=〜〜@〜〜.com

※--impersonate で利用できる権限を付与することでワンライナーにて実施可能

スナップショットが作成された事を確認

gcloud compute snapshots list --project プロジェクト名 | grep 作成したスナップショット名

公式:

https://cloud.google.com/compute/docs/disks/create-snapshots?hl=ja#create_zonal_snapshot

VMへのSSHログインをimpersonateでサービスアカウントになりすましてワンライナーで対応する

gcloud compute ssh 対象インスタンス名 \
 --zone 対象ゾーン名 \
 --project 対象プロジェクト名 \
 --impersonate-service-account=〜〜@〜〜.com

Recommenderについて

組織内のプロジェクトの使用状況が分析され、
放置プロジェクトの検出、再利用、削除に役立つ推奨事項が表示される

ユースケースの紹介

https://zenn.dev/e_koma/articles/20211205-gcp-instances-recommender

公式:

放置されたプロジェクトの Recommender

https://cloud.google.com/recommender/docs/unattended-project-recommender?hl=ja

https://cloud.google.com/blog/ja/products/identity-security/the-security-analytics-that-deliver-iam-recommendations

料金:

https://cloud.google.com/recommender/pricing?hl=ja

サーバレスエクスポートについて

内部的に稼働しているDBインスタンスとは別の一時的なDBインスタンスを新たに作成

その一時的なDBインスタンスを利用してデータのエクスポートを行う

稼働しているDBインスタンスへの影響を回避する

メリット:

  • 本番に影響を与えない

デメリット:

  • 一時的なDBインスタンスの作成に時間がかかるため、標準エクスポートよりも時間がかかる
  • DBインスタンスの追加料金が発生する

引用資料:

https://recruit.gmo.jp/engineer/jisedai/blog/serverless-export/

gcloudコマンドでプロジェクトリソースをterraformファイルとしてエクスポート

bulk-exportコマンドを打鍵

gcloud beta resource-config bulk-export --resource-format=terraform 
You do not currently have this command group installed.  Using it 
requires the installation of components: [beta]


Your current Google Cloud CLI version is: 379.0.0
Installing components from version: 379.0.0

┌─────────────────────────────────────────────┐
│     These components will be installed.     │
├──────────────────────┬────────────┬─────────┤
│         Name         │  Version   │   Size  │
├──────────────────────┼────────────┼─────────┤
│ gcloud Beta Commands │ 2022.03.25 │ < 1 MiB │
└──────────────────────┴────────────┴─────────┘

For the latest full release notes, please visit:
  https://cloud.google.com/sdk/release_notes

Do you want to continue (Y/n)?  Y

╔════════════════════════════════════════════════════════════╗
╠═ Creating update staging area                             ═╣
╠════════════════════════════════════════════════════════════╣
╠═ Installing: gcloud Beta Commands                         ═╣
╠════════════════════════════════════════════════════════════╣
╠═ Creating backup and activating new installation          ═╣
╚════════════════════════════════════════════════════════════╝

Performing post processing steps...done.                                                                                                                                                                   

Update done!

Restarting command:
  $ gcloud beta resource-config bulk-export --resource-format=terraform --path=./bulk_export/

Pausing command execution:

This command requires the `config-connector` binary to be installed to export GCP resource configurations. Would you like to install the`config-connector` binary to continue command execution? (Y/n)?  Y



Your current Google Cloud CLI version is: 379.0.0
Installing components from version: 379.0.0

┌───────────────────────────────────────────────────────────────────────────┐
│                    These components will be installed.                    │
├──────────────────────────────┬─────────────────────┬──────────────────────┤
│             Name             │       Version       │         Size         │
├──────────────────────────────┼─────────────────────┼──────────────────────┤
│ config-connector             │              1.78.0 │             51.0 MiB │
└──────────────────────────────┴─────────────────────┴──────────────────────┘

For the latest full release notes, please visit:
  https://cloud.google.com/sdk/release_notes

Do you want to continue (Y/n)?  Y

╔════════════════════════════════════════════════════════════╗
╠═ Creating update staging area                             ═╣
╠════════════════════════════════════════════════════════════╣
╠═ Installing: config-connector                             ═╣
╠════════════════════════════════════════════════════════════╣
╠═ Installing: config-connector                             ═╣
╠════════════════════════════════════════════════════════════╣
╠═ Creating backup and activating new installation          ═╣
╚════════════════════════════════════════════════════════════╝

Performing post processing steps...done.                                                                                                                                                                   

Update done!

ERROR: (gcloud.beta.resource-config.bulk-export) config-connector binary not installed

take2

gcloud beta resource-config bulk-export \
>   --project #### \
>   --resource-format=terraform \
>   --path=./対象ディレクトリ
API [cloudasset.googleapis.com] is required to continue, but is not enabled on project [learngcp-335008]. Would you like to enable and retry (this will take a few minutes)? (y/N)?  y

Enabling service [cloudasset.googleapis.com] on project [learngcp-335008]...
Operation "operations/acat.p2-95270527167-ad5622f1-3a70-457b-940c-2a595fd4969e" finished successfully.
Path ./対象ディレクトリ does not exists. Do you want to create it?

Do you want to continue (Y/n)?  n

ERROR: (gcloud.beta.resource-config.bulk-export) Export aborted. No files written.

対象プロジェクトをセット

gcloud config set core/project プロジェクトID

成功

gcloud beta resource-config bulk-export --project=プロジェクトID --resource-format=terraform --path=./対象ディレクトリ
Exporting resource configurations to [./対象ディレクトリ]...done.                                                                                                                                
Exported resource configuration(s) to [./対象ディレクトリ].

参考資料:

https://dev.classmethod.jp/articles/export-google-cloud-resources-as-terraform-code/
https://zenn.dev/korosuke613/scraps/f91dedf3890a65

Cloud Run概要

サービス、リビジョン、コンテナインスタンスの3つで構成される

サービス

Cloud Runのメインリソース
実行環境にデプロイされたアプリケーションを表す
各サービスは特定のリージョンに属するが、冗長性とフェイルオーバーのため、
リージョン内の複数ゾーンに自動的に複製される

リビジョン

サービスがデプロイされるたびに作成される
環境変数、メモリ制限、同時実行などの環境設定
+
特定のコンテナイメージから構成される

コンテナインスタンス

リビジョンの実体がコンテナインスタンス
リビジョンは受信した全てのリクエストを処理できるように、コンテナインスタンスの数を自動的にスケーリングする

リクエストが届いたサービスに対して、コンテナインスタンスが起動される
リクエストが届かないとコンテナは起動されない

機能

  • HTTPS以外で返せない
  • 同時に最大250リクエストを処理できる
  • 1つのリクエストに対して処理時間 15分以内
  • リクエストレートの制限は設定されていない
  • 1度リビジョンのキューに保存される
  • コンテナへリクエストを渡せない場合、429 too many requestエラー
  • コンテナにSSHログインできず、何か変更をするには全てコンテナイメージを作成してデプロイする必要がある

引用資料:

https://www.topgate.co.jp/ggg-study-cloud-run
参考資料:
https://www.apps-gcp.com/cloud-run-full-managed-basic-1/
パフォーマンス資料:
https://lp.cloudplatformonline.com/rs/808-GJW-314/images/App_Modernization_OnAir_q1_0217_Session.pdf

Google VPC Access Connectorについて

サーバーレス環境をVPC ネットワークに直接接続し、VM インスタンス、Memorystore、内部 IP アドレスを持つその他のリソースへのアクセスを可能にする

コネクタを作成

  • プロジェクトで Serverless VPC Access APIを有効にする

Terraform 例:

resource "google_project_service" "vpcaccess-api" {
  project = var.project_id # Replace this with your project ID in quotes
  service = "vpcaccess.googleapis.com"
}
  • コネクタを使用するように Cloud Run を構成

Terraform 例:

# Cloud Run service
resource "google_cloud_run_service" "gcr_service" {
  name     = "mygcrservice"
  provider = google-beta
  location = "us-west1"

  template {
    spec {
      containers {
        image = "us-docker.pkg.dev/cloudrun/container/hello"
        resources {
          limits = {
            cpu = "1000m"
            memory = "512M"
          }
        }
      }
      # the service uses this SA to call other Google Cloud APIs
      # service_account_name = myservice_runtime_sa
    }

    metadata {
      annotations = {
        # Limit scale up to prevent any cost blow outs!
        "autoscaling.knative.dev/maxScale" = "5"
        # Use the VPC Connector
        "run.googleapis.com/vpc-access-connector" = google_vpc_access_connector.connector.name
        # all egress from the service should go through the VPC Connector
        "run.googleapis.com/vpc-access-egress" = "all"
      }
    }
  }
  autogenerate_revision_name = true
}

コネクタを使用するようにサーバレス環境を構成

引用資料:

https://cloud.google.com/vpc/docs/configure-serverless-vpc-access

Cloud Run Jobsの記事

特徴:

  • HTTP リクエストに依らない実行←現行のバッチ処理をそのまま移行できるかも
  • より長時間の実行 ( 複数の Task を組み合わせることにより 60 分以上の実行を実現 )
  • 明示的な並列処理

参考記事:

https://medium.com/google-cloud-jp/cloud-run-jobs-c963a7143367
https://zenn.dev/nekoshita/articles/cf39a31f3052bf

6/11 追加

https://codelabs.developers.google.com/codelabs/cloud-starting-cloudrun-jobs-io?hl=ja#0

gcloudコマンドでcloud runのコンテナイメージを入れようとしたがエラー

現象:

以下のコマンドを打鍵

gcloud run deploy cloud run名 \
	--project 対象プロジェクトID \
	--region 対象リージョン \
  	--image 対象イメージID \
	--update-secrets=DB_PASSWORD=secret_manager名:バージョン

エラー内容

Deploying container to Cloud Run service [***] in project [***] region [***]
X Deploying... Google Cloud Run Service Agent must have permission to read the image, . Ensure tha
t the provided container image URL is correct and that the above account has permission to access the image. If you just enabled the Cl
oud Run API, the permissions might take a few minutes to propagate. Note that the image is from project [***], which is not the 
same as this project [***]. Permission must be granted to the Google Cloud Run Service Agent from this project.              
  X Creating Revision... Google Cloud Run Service Agent must have permission to read the image, ***. 
  Ensure that the provided container image URL is correct and that the above account has permission to access the image. If you just en
  abled the Cloud Run API, the permissions might take a few minutes to propagate. Note that the image is from project [***], which is not the same as this project [***]. Permission must be granted to the Google Cloud Run Service Agent from this projec
  t.                                                                                                                                   
  . Routing traffic...                                                                                                                 
Deployment failed                            

ERROR: (gcloud.run.deploy) Google Cloud Run Service Agent must have permission to read the image, ***. Ensure that the provided container image URL is correct and that the above account has permission to access the image. If you just enabled the Cloud Run API, the permissions might take a few minutes to propagate. Note that the image is from project [***], which is not the same as this project [***]. Permission must be granted to the Google Cloud Run Service Agent from this project.

原因:

Run のデプロイの際に他のプロジェクトからコンテナを Pull しようとしたが、
コンテナレジストリに対して Run の Service Agent が権限を持っていない為

対応:

対象コンテナレジストリのあるプロジェクト IAMに、
該当Cloud RunのService Agentを追加する

参考資料:

https://chidakiyo.hatenablog.com/entry/deploy-run-different-project
他の Google Cloud プロジェクトからイメージをデプロイする:
https://cloud.google.com/run/docs/deploying#other-projects
Terraformで追加する時の参考:(google_service_account_iam_bindingを使う)
https://scrapbox.io/pokutuna/新しい権限で_Cloud_Build_から_Cloud_Run_へデプロイする

Serverless NEGについて

サーバーレスサービスを Serverless NEG (Serverless Network Endpoint Group)
という形で抽象化することで、Google Cloud のグローバルなロードバランサーである
HTTP(S) Load Balancingと組み合わせて使うことを目的としている

HTTP(S) Load Balancing と組み合わせることで、

  • グローバルな Anycast IP アドレス
  • コンテンツベースのルーティング
  • マネージドな SSL 証明書
  • Cloud Armor によるウェブアプリケーションの保護
  • ユーザー定義ヘッダ
  • リダイレクトやURL書き換え

などの豊富な機能を使えるようになる

構成

Forwarding Rule

Target HTTP(S) Proxy

URL map

Backend Service

Serveless NEG (cloud run)

という構成となる

引用資料:

https://medium.com/google-cloud-jp/serverless-neg-でシステム開発をより柔軟に-4f9cebd2780f

グローバルなロードバランサーとサーバーレスサービスの色々な組み合わせ

https://medium.com/google-cloud-jp/serverless-neg-and-google-cloud-load-balancing-cbb341d3b636

Cloud Runのバックエンドサービス タイムアウトを変更したいができなかった

バックエンド サービスのタイムアウト設定は、サーバーレス NEG バックエンドを使用するバックエンド サービスには適用されません。バックエンド サービスの resource.timeoutSec プロパティを変更しようとすると、次のエラーが発生します。Timeout sec is not supported for a backend service with Serverless network endpoint groups
サーバーレス NEG バックエンドを使用するバックエンド サービスの場合、デフォルトのタイムアウトは 60 分です。このタイムアウトは構成できません。アプリケーションで長時間の接続が必要な場合は、失敗時にリクエストを再試行するようにクライアントを構成します

引用公式資料:

https://cloud.google.com/load-balancing/docs/negs/serverless-neg-concepts?hl=ja#backend-service-limitations

VPC Access Connector

VPC内にあるリソースを外部に公開する事なく、対象リソース(Cloud Run、Cloud Function)からアクセスができる。

流れ:

VPCを用意

サーバレスVPCアクセスコネクタを作成

Cloud Natを作成
CLoud Run等の対象リソースからのインターネットアクセスが
静的IPアドレスから行われるように設定

資料:

https://www.isoroot.jp/blog/3238/#:~:text=サーバーレスVPCアクセスコネクタは、名前の通りサーバー,するためのコネクタです。

cloud_sql_proxyコマンドをホームで叩けるようにmoveしたメモ

homeにある状態

-rwxr-xr-x    1   staff   3 15 10:52 cloud_sql_proxy*

moveで/usr/local/bin配下に移動

mv cloud_sql_proxy /usr/local/bin/cloud_sql_proxy

homeディレクトリで実行可能

cloud_sql_proxy -instances=***

参考:

https://linuc.org/study/knowledge/544/

Cloud RunにAlways on cpuを設定する

gcloudコマンドでの設定例:

gcloud beta run deploy **** \
--no-cpu-throttling \
--min-instances

Terraformでの設定例:

  template {
    metadata {
      annotations = {"run.googleapis.com/cpu-throttling"= false}
    }
}

言及資料:

https://github.com/hashicorp/terraform-provider-google/issues/10589

--min-instances オプションを指定しておかないと、Idle 状態(リクエストが無い状態)の
コンテナインスタンスは CPU はallocate された状態であっても、
スケールインして最終的にコンテナインスタンスが 0 になってしまう。

期待値としては非同期のワーカーとしてずっと動いていてほしいので、
--min-instances オプションで常に稼働するコンテナインスタンスの数を指定

参考記事:

https://medium.com/google-cloud-jp/cloudrun-always-on-cpu-pubsub-pull-2664b9730781

https://medium.com/google-cloud-jp/サーバーレス-コンテナ-cloud-run-に新機能-always-on-cpu-が登場しました-c88cd1114c60

https://cloud.google.com/blog/ja/products/serverless/cloud-run-gets-always-on-cpu-allocation

SSL 証明書の概要 (Google マネージド証明書)

SSL証明書を使用して、LBに転送されるデータのプライバシーとセキュリティを保護する
1 つの証明書で複数のホスト名をサポートしており、Google は証明書を自動的に更新する

Google マネージド証明書は、次のロードバランサでサポートされている。

  • グローバル外部 HTTP(S) ロードバランサ(プレビュー)。
  • グローバル外部 HTTP(S) ロードバランサ(従来)
  • SSL プロキシ ロードバランサ

Google マネージド SSL 証明書は、ドメイン用に Google Cloud が取得して管理する証明書
自動的に更新される。Google マネージド証明書はドメイン認証(DV)証明書。
証明書に関連付けられた組織や個人の ID を証明せず、ワイルドカードの共通名をサポートしない。

公式:

https://cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs?hl=ja
https://cloud.google.com/load-balancing/docs/ssl-certificates?hl=ja

Cloud RunのRevision Template

Terraformで制御する場合、
コンテナインスタンス数は以下をannotationsに設定する事ができる

autoscaling.knative.dev/minScale // sets the minimum number of instances.
autoscaling.knative.dev/maxScale // sets the maximum number of instances.

公式:

https://cloud.google.com/run/docs/reference/rest/v1/RevisionTemplate

Cloud Runで403エラー

Cloud Runを立ち上げ、Serveless LBのIPに向き先を変更して疎通するようにしたが、
サービスのURL以下のエラーが出るようになった。

Error: Forbidden
Your client does not have permission to get URL / from this server.

原因:

Cloud Runのトリガー設定で認証が必要としていた為

Ingress:内部トラフィックとCloud Load Balancingからのトラフィックを許可する
認証:未認証の呼び出しを許可

↑の設定にして解決
gcloudからも設定が可能

--allow-unauthenticated 
--ingress internal-and-cloud-load-balancing

認証設定について:

https://cloud.google.com/run/docs/authenticating/public?hl=ja#command-line

Terraformによる設定 (Ingress)

  template {
    metadata {
      annotations = {
        "run.googleapis.com/ingress" = "internal-and-cloud-load-balancing"  // Ingressの設定
      }
    }

必要設定 公式:

https://cloud.google.com/run/docs/securing/ingress?hl=ja#yaml

エラー時の対応 公式:

https://cloud.google.com/run/docs/troubleshooting?hl=ja#unauthorized-client

監視設定のやりたい事メモ

実現したいこと

Cloud Runアプリのstderr(ERROR以上とか)を検知したら、slackチャンネルにエラー内容が
一目でわかるように流す

現状、社内のエンジニアが挑戦したが自作でゴリゴリ手を加えないとできない模様

エラー内容詳細ではなく、設定した条件のエラーを検知したら通知はできる

slackからではどんな内容か詳細がわからない(リンクを踏まないとわからない)

無視して流せる内容なのか、認知して対処が必要なエラーなのか、一見判断がつかない

ログエクスプローラの概要に書いてあること引っ張ってくるだけなのなんとかできそうだが。。

6/25追記

Error Reportingのログをslackに通知させる方向で話がまとまった

タスク

・Terraformでの構築、設定方法の調査
 ・slack通知方法の調査

参考記事:

Cloud RunでのError Reporting設定(公式)

https://cloud.google.com/error-reporting/docs/setup/cloud-run?hl=ja

(公式)

https://cloud.google.com/logging/docs/view/logs-explorer-interface?hl=ja#query-results
(エラーレポーティング)
https://cloud.google.com/blog/ja/products/devops-sre/use-slack-and-webhooks-for-notifications
https://www.kwbtblog.com/entry/2020/07/20/035720
ログインするとコメントできます