Open95

GCPメモ

ktkt

Marketplaceについて

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

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

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

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

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

ktkt

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

アプリケーションから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

ktkt

Cloud Asset Inventoryについて

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

アセット

  • リソース

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

  • ポリシー

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

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

ktkt

Cloud SQL Auth Proxy

概要:

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

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

公式資料:
https://cloud.google.com/sql/docs/mysql/sql-proxy#what_the_provides

ktkt

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",
    ]
ktkt

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(仮想マシン,を管理するものです。

ktkt

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

ktkt

Pub/Subについて

publisher / subscriber

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

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

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

参考記事:
https://qiita.com/t-yotsu/items/b578d7e12692d046ef9c

ktkt

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

ktkt

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

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

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

ユースケース

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

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



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

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


    ユースケース

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

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

ktkt

Cloud CDNの活用

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

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

動作

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

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

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

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

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

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

ktkt

Cloud VPN

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

ユースケース

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

最小権限の原則

定義:

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

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

職掌分散

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

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

目的:

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

ktkt

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

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

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

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

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

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

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

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

ロール

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

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

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

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

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

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

Cloud Endpointsについて

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

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

ktkt

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内のデータがスキャンされる
  • 画像スキャンも可能
  • メール、クレカなどの情報が検出される
  • 独自の情報タイプを追加可能
  • 機密データを削除、マスキング、トークン化できる
ktkt

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

必見 わかりやすく解説
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

ktkt

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

ログエクスプローラーのクエリで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

ktkt

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

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

利用例:

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

転送とストレージの概要

ログルーター

ログエントリが、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

ktkt

Cloud Loab Balancingまとめ

特徴

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

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

ktkt

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

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

ktkt

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

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

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

ktkt

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

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

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

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

メリット:

  • 本番に影響を与えない

デメリット:

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

引用資料:
https://recruit.gmo.jp/engineer/jisedai/blog/serverless-export/

ktkt

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

ktkt

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

ktkt

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

ktkt

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を使う)

(追記)注意:

google_service_account_iam_bindingは既存のroleを上書きする仕様の為、基本的には使わない。
↓事例:
https://tech.classi.jp/entry/2021/12/10/120000

modules/service_accounts_iamを利用する。
https://registry.terraform.io/modules/terraform-google-modules/iam/google/latest/submodules/service_accounts_iam

https://scrapbox.io/pokutuna/新しい権限で_Cloud_Build_から_Cloud_Run_へデプロイする

ktkt

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

ktkt

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

ktkt

VPC Access Connector

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

流れ:

VPCを用意

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

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

資料:

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

ktkt

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/

ktkt

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

ktkt

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

ktkt

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

ktkt

Error Reportingの通知機能 × Cloud Runの対応方法まとめ

主な仕様

  • 通知を構成のボタンからslack、Emailに通知が飛ぶよう設定できる
  • 既存のエラーに分類できないエラーが初めてGoogle Cloud プロジェクトで発生した場合通知される
  • 解決済みとマークされたエラーが再発した場合通知される
  • Error Reportingの保存期間は30日まで (30日で消滅する)

通知の上限

Google Cloud プロジェクトで 1 時間以内にエラーが 5 回以上再発した場合、
Error Reporting から最終通知が送られ、
今後 6 時間は通知が送信されないことが伝えられます。これにより、通知の量を制御します。

解決ステータス
解決ステータスが [解決済み] のエラーが再発した場合、
そのエラーがすでに削除されていても、解決ステータスが [対応待ち] に戻され、
Error Reporting から通知が送信されます。

[ミュート中] のエラーが再発した場合は、Error Reporting から通知は送信されません。

https://cloud.google.com/error-reporting/docs/notifications#limit

サービスアカウントに必要な権限

CLoud Runのサービスアカウントに以下の権限が必要
(errorreporting.writerが本当に必須かは要検証)
(logWriter権限がないと403エラーが生じた)

roles/errorreporting.writer
roles/logging.logWriter

アプリケーション側の実装 (PHP)

公式 PHP用Error Reportingの設定
https://cloud.google.com/error-reporting/docs/setup/php?hl=ja

テスト通知用のログエントリ

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

参考記事:

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

API:
https://cloud.google.com/error-reporting/reference/rest/v1beta1/projects.events/report

エラーの管理
https://cloud.google.com/error-reporting/docs/managing-errors?hl=ja

ktkt

フィルタリングと集計

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://www.kwbtblog.com/entry/2020/07/20/035720

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

Aligner 英語ドキュメント:
https://cloud.google.com/monitoring/api/ref_v3/rest/v3/projects.alertPolicies#Aligner

ktkt

セルフマネージド証明書の作成手順 メモ

①秘密鍵と証明書を作成する

openssl genrsa -out ****.co.jp.key 2048

②CSR を作成する

OpenSSL構成ファイルの作成

cat <<'EOF' >openssl_file
[req]
default_bits              = 2048
req_extensions            = extension_requirements
distinguished_name        = dn_requirements

[extension_requirements]
basicConstraints          = CA:FALSE
keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName            = @sans_list

[dn_requirements]
countryName               = Country Name (2 letter code)
stateOrProvinceName       = State or Province Name (full name)
localityName              = Locality Name (eg, city)
0.organizationName        = Organization Name (eg, company)
organizationalUnitName    = Organizational Unit Name (eg, section)
commonName                = Common Name (e.g. server FQDN or YOUR name)
emailAddress              = Email Address

[sans_list]
DNS.1                     = ****.co.jp

EOF

③OpenSSL コマンドを実行して、証明書署名リクエスト(CSR)ファイルを作成

openssl req -new -key ****.co.jp.key \
    -out *** \
    -config ***


独自の CA を管理する場合、テスト用の自己署名証明書を作成する場合、
次の OpenSSL コマンドを使用

openssl x509 -req \
    -signkey ***.co.jp.key \
    -in ***-csr \
    -out ***-certificate \
    -extfile *** \
    -extensions extension_requirements \
    -days 365

⑤セルフマネージド SSL 証明書リソースを作成

gcloud compute ssl-certificates create ****-cert \
  --certificate=***-certificate \
  --private-key=***.co.jp.key \
  --project=*** \
  --global

⑥SSL 証明書をターゲット プロキシに関連付ける
※事前に対象プロジェクトをセットしておく

gcloud compute target-https-proxies update *** \
    --global \
    --ssl-certificates=*** \
    --global-ssl-certificates

公式:
https://cloud.google.com/load-balancing/docs/ssl-certificates/self-managed-certs?hl=ja#gcloud

OpenSSLによるCSRの作成について
https://www.slogical.co.jp/ssl/faq/csr_openssl/

オレオレ証明書について
https://www.webtech.co.jp/blog/optpix_labs/server/1159/

参考記事:
https://blog.jicoman.info/2020/12/how-to-update-gcp-self-managed-ssl-certificates/

ktkt

terraform moduleで作ったserverless LBにセルフマネージド証明書を追加する

argument : ssl_certificatesにリスト型で入れたらOK

例:

module "sample_serveless_lb" {
  source                          = "GoogleCloudPlatform/lb-http/google//modules/serverless_negs"
  name                            = "sample_serveless_lb"
  project                         = var.project
  ssl                             = true
  managed_ssl_certificate_domains =  ["sample.co.jp"]
  ssl_certificates                = ["https://www.googleapis.com/compute/v1/projects/****/global/sslCertificates/***-co-jp-20990101"]
  create_address                  = false
  address                         = google_compute_global_address.sample_address.address
  https_redirect                  = false
  url_map                         = google_compute_url_map.sample_url_map.self_link
  create_url_map                  = false
  security_policy                 = google_compute_security_policy.sample_sp.name

  backends = {
    default = {
      groups = [
        {
          group = google_compute_region_network_endpoint_group.sample_serverless_neg.id
        }
      ]

      connection_draining_timeout_sec = 300
      description                     = null
      enable_cdn                      = false
      security_policy                 = null
      custom_request_headers          = null
      custom_response_headers         = null

      iap_config = {
        enable               = false
        oauth2_client_id     = ""
        oauth2_client_secret = ""
      }
      log_config = {
        enable      = true
        sample_rate = 1.0
      }
    }
  }
}
ktkt

Cloud Runでphp artisan migrateを自動化する

以下の手順で実現

①Cloud RunサービスアカウントにDB用のroleをつける (roles/cloudsql.client)
②Cloud RunDB接続でenvにDB_PASSWORDを設定 (Secret Manager利用が良い)
③php artisan migrateコマンド用のshを作成
④DockerfileのENTRYPOINTでshを叩く
⑤CI/CDにgcloud run deployを組み込んでデプロイさせる

特徴

  • コンテナ起動時にphp artisanコマンドが毎回呼び出される(デメリットとなる可能性あり)
  • そのままではartisanコマンドの実行制御はできない

※こちらの実装・運用に懸念があればどなたか教えていただきたいです!

参考記事:

sh + Dockerfileで実現するやり方はこちら
https://stackoverflow.com/questions/68009385/which-is-the-right-way-to-run-laravel-migrations-using-google-cloud-run-and-goog

cloudbuild使う場合はこちら
https://stackoverflow.com/questions/68009385/which-is-the-right-way-to-run-laravel-migrations-using-google-cloud-run-and-goog

ECSの場合の事例:
https://techblog.roxx.co.jp/entry/2020/06/16/102406

ktkt

cloud_sql_proxyとgcloudコマンドを使ってパスワードを秘匿化しながらCloud SQLにログイン

概要

利用するもの

  • cloud_sql_proxyコマンド
  • MYSQL_PWD(MySQL用の環境変数)
  • gcloud auth print-access-tokenコマンド
  • --impersonate-service-accountオプション
  • DB接続用サービスアカウント
  • --enable-cleartext-pluginオプション

コマンド例:

MYSQL_PWD=$(gcloud auth print-access-token  --impersonate-service-account=**user@****.iam.gserviceaccount.com) mysql -u **user -h 127.0.0.1 -P 3316 --enable-cleartext-plugin

手順

①DB接続用サービスアカウント・DBユーザーを用意する

 - サービスアカウント作成時に、roles/cloudsql.instanceUserをつけておく
 - roles/iam.serviceAccountTokenCreatorを対象グループ(DB用ML等)に付与する

Terraformの設定例:

# サービスアカウント作成, cloudsql userロール付与
module "db_user" {
  source  = "terraform-google-modules/service-accounts/google"
  version = "~> **"

  display_name = "db-user"
  description  = "db-user"
  project_id   = var.project_id
  prefix       = "db"
  names        = ["db-user"]
  project_roles = [
    "${var.project_id}=>roles/cloudsql.instanceUser"
  ]
}
# iam.serviceAccountTokenCreatorのroleを対象メンバーグループに付与
resource "google_service_account_iam_binding" "db_token_creater" {
  service_account_id = module.db_user[0].id
  role               = "roles/iam.serviceAccountTokenCreator"
  members = [
    "group:**@co.jp"
 ]
}

②cloud_sql_proxyをセットアップ

以下の記事を参考にセットアップ
https://qiita.com/cognitom/items/c6b2ccb6e6b0f731850a

③gcloud auth loginを打鍵

gcloud auth login

④冒頭のコマンド例に、作成したサービスアカウント、MLを当てはめて入力

IAM周りの権限解説:
https://runebook.dev/ja/docs/terraform/providers/google/r/google_service_account_iam

ktkt

エラー発生日時を日本時間で取得する 注意:apply日時で固定される

Terraformで作成した事例:

①local変数を作成

locals {
  now = timestamp()
  asia_tokyo_tz = timeadd(local.now, "9h")
  convert_cursorTimestamp = formatdate("YYYY-MM-DD hh:mm", local.asia_tokyo_tz)
  error_alert = {
    slack_post_message_document = <<-EOF
      エラーを検知しました。
      詳細の確認をお願いします。
      エラー発生日時:${local.convert_cursorTimestamp}
      https://console.cloud.google.com/logs/query;query=resource.type****
    EOF
 }
}

output "time" {
  value = {
    "now" = local.now,
    "asia_tokyo_tz" = local.asia_tokyo_tz,
    "convert_cursorTimestamp" = local.convert_cursorTimestamp
  }
}

②検知用のmetricsを作成

resource "google_logging_metric" "test_error_log" {
  name     = "test-error-log"
  project  = var.project_id
  filter   = <<-EOF
    resource.type = "cloud_run_revision"
    resource.labels.location = "asia-northeast1"
    severity>=ERROR
  EOF

  metric_descriptor {
    metric_kind = "DELTA"
    value_type  = "INT64"
  }
}

③alertを作成

data "google_monitoring_notification_channel" "test_alert_channel" {
  display_name = "test-error-log"
}

# DEV TEST エラー検知用
resource "google_monitoring_alert_policy" "test_error_alert" {
  project      = var.project_id
  combiner     = "OR"
  display_name = "TEST error-log"
  conditions {
    display_name = google_logging_metric.test_error_log.name

    condition_threshold {
      filter = <<-EOF
          metric.type="logging.googleapis.com/user/${google_logging_metric.test_error_log.name}"
          resource.type="cloud_run_revision"
      EOF
      comparison      = "COMPARISON_GT"
      duration        = "0s"
      threshold_value = "0" // 1件でも検知したら作動させる

      aggregations {
        alignment_period     = "60s"
        per_series_aligner   = "ALIGN_COUNT"
        cross_series_reducer = "REDUCE_COUNT"
      }

      trigger {
        count = 1
      }
    }
  }
  alert_strategy {
      auto_close = "1800s"
  }

  documentation {
    mime_type = "text/markdown"
    content =  local.error_alert.slack_post_message_document
  }

  notification_channels = [
    data.google_monitoring_notification_channel.test_alert_channel.name
  ]
}

エラーを検知したら以下の形でslackに表示される

  • 日時はterraform applyした日時が固定される為、実用的でない

Google Cloud Monitoring
アプリ  17:34
Incident #*** is ongoing
test-error-log
TEST error-log
logging/ Cloud Run Revision labels {project_id=***} is above the threshold of 0.000 with a value of 1.000.
Documentation
アプリケーションでエラーを検知しました。
詳細の確認をお願いします。
エラー発生日時:2022-**-** **:**
ktkt

Cloud SQL IAM データベース認証について

Cloud SQLはIAMと統合されており、データベースに対するユーザーとサービス アカウントのログインアクセスを適切に管理できる。この機能を IAM データベース認証と呼ぶ。

認証は2種類

  • データベースの組み込み認証:ユーザー名とパスワードを使用してデータベース ユーザーを認証
  • IAM データベース認証:アクセス トークンと IAM を使用してユーザーを認証

IAM 認証を使用する場合、リソース(Cloud SQL インスタンス)へのアクセス権はエンドユーザーに直接付与されない。代わりに複数の権限をロールにまとめて、プリンシパルに付与する。

プリンシパル

Cloud SQL では、ユーザー アカウントとサービス アカウント(アプリケーション用
という 2 種類のプリンシパルを使用できます

ロール

ユーザーがインスタンスにログインするために cloudsql.instances.login 権限が必要

リソース

プリンシパルがアクセスするリソースは Cloud SQL インスタンス

cloudsql_iam_authenticationフラグ

IAM データベース認証を有効にするには、cloudsql_iam_authenticationフラグを使用する。
このフラグを有効にすると、インスタンスで IAM データベース認証用に構成された
アカウントのログインが有効になる。

公式:
https://cloud.google.com/sql/docs/postgres/authentication?hl=ja
データベースフラグ:
https://cloud.google.com/sql/docs/postgres/flags?hl=ja#terraform
cloudsql_iam_authentication
https://cloud.google.com/sql/docs/mysql/create-edit-iam-instances?hl=ja#console

ktkt

Cloud Run Jobsについての調査

特徴:

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

既存のCloud Runとの比較

Cloud Run:リクエストをリッスンして対応する
Jobs:タスクを実行するだけで完了すると終了する

ジョブはリクエストをリッスンすることも対応することもしない
実行時に任意のパラメータを受け入れることはできない

ジョブを作成または更新した後ジョブを実行
1 回限りで実行することも、スケジュールに沿って実行することもできる
ワークフローの一部として実行することもできる

個々のジョブ実行を管理して、実行ログを表示できる

単一のタスクとしても、複数の独立したタスク(最大 10,000 個)としても構成できる
並列で処理できる

各タスクは 1 つのコンテナ インスタンスを実行し、障害発生時に再試行するように構成

各タスクはインデックスを認識する
インデックスは CLOUD_RUN_TASK_INDEX 環境変数に格納される

データを並行して処理する場合、どのタスクがデータのどのサブセットを処理するのかは
コードによって判断される

タスクのタイムアウトを設定し、タスクが失敗した場合の再試行回数を指定できる
いずれかのタスクで再試行の最大数を超えると、そのタスクは「失敗」とマークされる
ジョブの実行は、すべてのタスクの実行後に失敗とマークされる

Job

Cloud Run jobs のルートリソースでリージョンに紐づく
処理を行うコンテナイメージの指定や、Task 数、並列数の設定を行う
その他、各 Task の CPU / Memory サイズ、環境変数、VPC 接続、
Cloud SQL接続の設定など

Task

Job で指定された数だけ実行される
実際に処理を行うContainer Instanceと同義

Execution

Job の実行を表す。全Task が完了するまで継続されて、
1度作成したJobは何度も実行可能。

使い方

大きく分けて以下の3つ

①1 つの Task を実行
②複数の Task を直列に実行
③複数の Task を並列に実行

デフォルトの仕様

マシンスペック:

1CPU、512MiB (Cloud Runと同等)

リトライ数:

3 (0~10で調整可能)

タイムアウト:

デフォルト10分 (最大1時間)

実行のタイミング:

Jobを作成しただけでは実行されない

  • gcloud beta run jobs execute JOB_NAME --region REGION_NAME を実行
  • Job 作成時に“ --execute-now” オプションを指定、Job作成と同時に実行

制限

Job:

1Jobにつき、10000タスクまで実行可能
1Jobのタイムアウトはない
全タスクが完了するまでExecutionが継続する

Task:

1タスクのタイムアウトは最大1時間、デフォルト10分
CPUによって並列数の上限が変わる

CPU1:並列タスク数 100
CPU2:並列タスク数 50
CPU4:並列タスク数 25
CPU6以上:並列タスク数 10

各 Task には整数値のインデックスが割り当てられている
各インデックスの値は、各Task (Container) 内にセットされた環境変数
“CLOUD_RUN_TASK_INDEX” を参照することで確認可能

環境変数 “CLOUD_RUN_TASK_ATTEMPT”

試行回数の値が入っている
この値を Task のプログラムから参照して、
試行回数に応じて挙動を変える実装を行うことも可能

Cloud Schedulerとの連携

バッチ処理などを定期的に実行したいユースケースで利用できる

CLoud Run Jobs自体にはエンドポイントはない

Google CloudのAPI を通じて、Jobの実行を外部から呼び出すことが可能

参考引用記事:

公式
https://cloud.google.com/run/docs/create-jobs?hl=ja

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

ktkt

Cloud Natのルール (エンドポイントに依存しないマッピング)

エンドポイントに依存しないマッピングが有効になっている NAT ゲートウェイに NAT ルールを追加することはできません。NAT ルールが含まれる NAT ゲートウェイで、エンドポイントに依存しないマッピングを有効にすることはできません

https://cloud.google.com/nat/docs/nat-rules-overview?hl=ja

ktkt

Cloud Run Jobsのgcloudコマンドによる作成

事例: (php artisan migrateコマンドを実行)

gcloud beta run jobs create test-job \
--image=asia.gcr.io/プロジェクト/test-container:latest \
--command=php \
--command=artisan \
--command=migrate \
--max-retries=0 \
--service-account=****@****.iam.gserviceaccount.com \
--set-secrets=DB_PASS=****:latest \
--vpc-connector=vpc-*** \
--vpc-egress=all-traffic \
--project=**** \
--region=asia-northeast1

参考資料:

https://cloud.google.com/run/docs/create-jobs?hl=ja
https://cloud.google.com/sdk/gcloud/reference/beta/run/jobs/create?hl=ja

ktkt

Cloud NAT の Endpoint-independent Mappingについて

Cloud Natについて

Google CloudのVMに外部IPアドレスをつけなくても外部通信できるように、
Natの機能をマネージドで提供するサービス

Endpoint-Independent Mapping NAT

NATのマッピング動作

クライアントがNATにマッピングされるIPアドレス:Portが、
宛先のIPアドレス:Portによって変化するかを見て判定する

  • 宛先エンドポイントに依存しないIPアドレス:Portのマッピングを行うNAT
  • 異なる宛先IPアドレス:Portに対しても、クライアントにマッピングされるIP:Portが同じになる

Natのマッピング動作の判定方法
https://zenn.dev/yoshd/articles/2859fc5ffd5a6e

ENDPOINT_INDEPENDENCE_CONFLICTについて

マッピング方式が Endpoint Independent Mapping になっている時にのみ発生する

↓対策

  • Endpoint Independent Mapping をやめる
  • VM 当たりの送信元ポート番号の割り当てを増やす

なぜEndpoint Independent Mappingを採用するのか?

Natトラバーサルの技術互換性のために、Endpoint Independent Mappingを採用している
↓ユースケース
ゲームなどのために NAT の裏側にいるホスト同士で P2P 通信をおこないたい

Endpoint Dependent Mapping を利用することによるデメリットはほぼ無い

GCE/GKE のホスト同士が NAT トラバーサルを使った直接の通信を
しなければならない場面は非常に限定的

Cloud NATにおいては、Endpoint Dependent Mappingを
利用することによるデメリットはほぼ無い

引用資料:
https://medium.com/google-cloud-jp/cloud-nat-endpoint-independent-mapping-39d7eab3e83c

ktkt

cloud functionsの構築方法メモ

概要

サーバレスコンピューティングサービス

サーバーのプロビジョニング、スケールアップ、メンテナンス等の管理を全てGoogleに任せ、
ユーザーはその上で動かすコードの開発のみに集中できる

仕様

支払いは従量制

呼び出し料金は 1 回あたり $0.0000004(100 万件あたり $0.40)の単価制

呼び出し回数(1 か月あたり) 料金(100 万回あたり)
最初の 200 万回 無料
200 万回を超えた分 $0.40

コンピューティング時間

関数がリクエストを受け取ってから、

  • 完了シグナルの送信
  • タイムアウトなどのエラー
  • その他の終了処理

によって関数が完了するまでの時間

コンピューティング時間は 100 ミリ秒単位で測定され、この単位で切り上げ
たとえば、実行時間が 260 ミリ秒の関数には 300 ミリ秒の料金が請求

ユースケース:

サードパーティのサービスや API との統合

コンピューティング時間に対応する料金は、
関数に対してプロビジョニングされたメモリや CPU の量に基づいて変動

1 GB 秒は、1 GB のメモリがプロビジョニングされている場合の 1 秒間の実測時間
1 GHz 秒は、1 GHz の CPU がプロビジョニングされている場合の 1 秒間の実測時間

無料枠には 200 万回の呼び出しのほかに、
400,000 GB 秒、200,000 GHz 秒のコンピューティング時間と、
1 か月あたり 5 GB のインターネット下りトラフィック

ネットワーキング

送信データ転送(関数から外部の他の場所に転送されるデータ)

種類 料金/GB
送信データ(下り、外向き) $0.12
1 か月あたりの送信データ 5 GB 無料
受信データ(上り、内向き) 無料
同じリージョン内の Google API への送信データ 無料

デプロイ

CI/CDなどに組み込み、コードを変更する際に
反映させることができる

見本:

gcloud functions deploy deploy-functions \
--trigger-http \
--runtime=php81 \
--entry-point=function \
--source=**** \
--allow-unauthenticated \
--region=asia-northeast1 \
--memory=256MB \
--timeout=540s \
--security-level=secure-always \
--vpc-connector=projects/****/locations/asia-northeast1/connectors/****

公式:
https://cloud.google.com/functions/docs/deploy?hl=ja

日本語参考情報
https://shinyorke.hatenablog.com/entry/cloud-functions-gen2

terraformからcloud functionsを作成

## cloud functionsで使う関数が設置されたパスを指定する
data "archive_file" "file" {
  type        = "zip"
  source_dir  = "${path.module}/scripts/functions"
  output_path = "${path.module}/functions.zip"
}

## terraformデプロイ時に必須の為構築 ソースはアプリ側のコードから反映
resource "google_storage_bucket_object" "functions_object" {
  name    = "functions${data.archive_file.file.output_md5}.zip"
# bucket作成は必須
  bucket  = google_storage_bucket.functions.name
  source  = data.archive_file.file.output_path
}

resource "google_storage_bucket" "functions_bucket" {
  name     = "functions-bucket"
  location = ****
  project  = ****
}

resource "google_cloudfunctions_function" "functions" {
  name                          = "functions"
  runtime                       = "php81"
  region                        = var.region
  timeout                       = 540
  available_memory_mb           = 256
  entry_point                   = "function"
  trigger_http                  = true
  source_archive_bucket         = google_storage_bucket.functions_bucket.name
  source_archive_object         = google_storage_bucket_object.functions_object.name
  vpc_connector                 = "projects/${var.project_id}/locations/${var.region}/connectors/${local.vpc_access_connector}"
  vpc_connector_egress_settings = "ALL_TRAFFIC"
  ingress_settings              = "ALLOW_INTERNAL_AND_GCLB"

  # MEMO:gcloudでのCI/CDデプロイ時にlabelsが更新される為無視する項目 
  lifecycle {
    ignore_changes = [
      source_archive_object,
      labels,
      ingress_settings,
      environment_variables
    ]
  }
}

参考:
https://cloud.google.com/functions/docs/tutorials/terraform (第二世代)
https://towardsdatascience.com/deploy-cloud-functions-on-gcp-with-terraform-111a1c4a9a88

terraformからLBを作成

Cloud Run同様、サーバレスNEGが利用できる

参考コード

## グローバルアドレス作成
resource "google_compute_global_address" "address" {
  name          = "****"
  address_type  = "EXTERNAL"
}

## cloud functionsと紐付け
resource "google_compute_region_network_endpoint_group" "serverless_neg" {
  name                  = "lb-functions-neg"
  network_endpoint_type = "SERVERLESS"
  project               = ****
  region                = ****
  cloud_function {
    function = google_cloudfunctions_function.****.name
  }
}

## url map作成
resource "google_compute_url_map" "url_map" {
  name            = "lb-url-map"
  default_service = module.***.backend_services["default"].self_link
  project         = ****
}

## moduleでLB作成
module "lb_serveless_lb" {
  source                          = "GoogleCloudPlatform/lb-http/google//modules/serverless_negs"
  name                            = "lb-functions"
  project                         = ****
  ssl                              = true
  managed_ssl_certificate_domains = var.env == ["***"]
  create_address                  = false
  address                         = google_compute_global_address.****.address
  https_redirect                  = true
  url_map                         = google_compute_url_map.****.self_link
  create_url_map                  = false
  security_policy                 = ""

  backends = {
    default = {
      groups = [
        {
          group = google_compute_region_network_endpoint_group.serverless_neg.id
        }
      ]

      connection_draining_timeout_sec = 300
      description                     = null
      enable_cdn                      = false
      security_policy                 = null
      custom_request_headers          = null
      custom_response_headers         = null

      iap_config = {
        enable               = false
        oauth2_client_id     = ""
        oauth2_client_secret = ""
      }
      log_config = {
        enable      = true
        sample_rate = 1.0
      }
    }
  }
}

公式:
https://cloud.google.com/load-balancing/docs/https/setting-up-https-serverless#cloud-functions

日本語参考情報:
https://blog.g-gen.co.jp/entry/cloud-functions-explained

ktkt

GCEにapache2をインストールしてアクセスログをcloud loggingで取得できるようにする

Route53の加重ルーティング検証用に立てたのでメモ

  • 同じ内容のGCEを2つ作成
  • 加重設定を10:90、50:50、90:10にする
  • 数十〜数百、数千程度の攻撃をかけてアクセス比率をcloud loggingから確認する

GCEの作成

以下をインストールする

  • apache2
  • php
  • google-cloud-ops-agent

index.htmlをindex.phpに変更して、
出力を1 inspect、2 inspectと変更する

terraformで作成

以下のような形で作成

# /etc/google-cloud-ops-agent/config.yaml
data "template_file" "ops_agent" {
  template = file("config.yaml")
}

# index.htmlをindex.phpに上書き
data "template_file" "index1_php" {
  template = file("index1.php")
}

data "template_file" "index2_php" {
  template = file("index2.php")
}

resource "google_compute_instance" "inspection" {
  name         = "inspection-1"
  machine_type = "f1-micro"
  zone         = "asia-northeast1-a"
  project      = var.project

  boot_disk {
    initialize_params {
      image = "ubuntu-os-pro-cloud/ubuntu-pro-2204-jammy-v20221014"
    }
  }

  network_interface {
    network = "https://www.googleapis.com/compute/v1/projects/****/global/networks/default"
    access_config {
        nat_ip       = "**Route53で指定するIPアドレス**"
    }
  }

  metadata_startup_script = <<EOF
#!/bin/bash
sudo su
apt-get update
apt-get -y install apache2
systemctl start apache2
apt-get -y install php
curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
bash add-google-cloud-ops-agent-repo.sh --also-install
cp /etc/google-cloud-ops-agent/config.yaml /etc/google-cloud-ops-agent/config.yaml.bak
# config.yamlを上書き
echo "${data.template_file.ops_agent.rendered}" | tee /etc/google-cloud-ops-agent/config.yaml
cp /var/www/html/index.html /var/www/html/index.html.bak
mv /var/www/html/index.html /var/www/html/index.php
# index.htmlをindex.phpに変えて出力を変更
echo "${data.template_file.index_php.rendered}" | tee /var/www/html/index.php
service google-cloud-ops-agent restart
EOF

↑のindex.phpを別物に変えてもう1つGCEを作成

引用資料:

GCE
https://teech-lab.com/gcp-gce-apache-intro/1321/

公開イメージの取得
https://blog.e2info.co.jp/2021/12/30/gce_image_list/

apache
https://cloud.google.com/logging/docs/agent/ops-agent/third-party/apache?hl=ja

terraform :
https://registry.terraform.io/providers/hashicorp/template/latest/docs/data-sources/file

ログ関連
https://symphonict.nesic.co.jp/tech-blog/150/

ktkt

MQLについて

Google 社内の指標クエリ言語 (Monitoring指標に利用する)

LB Cloud CDNのキャッシュヒット率

fetch https_lb_rule
| metric 'loadbalancing.googleapis.com/https/response_bytes_count'
| filter (metric.cache_result == 'HIT')
| group_by 1m,
    [value_response_bytes_count_aggregate:
       aggregate(value.response_bytes_count)]
| every 1m
| group_by [resource.backend_target_name, resource.backend_target_type],
    [value_response_bytes_count_aggregate_aggregate:
       aggregate(value_response_bytes_count_aggregate)]
| filter resource.backend_target_name == "****"
| filter resource.backend_target_type == "BACKEND_SERVICE"

公式:
https://cloud.google.com/blog/ja/products/management-tools/introducing-monitoring-query-language-or-mql

ktkt

Cloud CDN概要整理

Google CloudのCDN
料金高め

GCBと連携してコンテンツ配信を行う

送信元サーバ:

  • GCE
  • NEG(ネットワークエンドポイントグループ)
  • サーバレスNEG (Cloud Run, Cloud funtcion)
  • GCS

仕組み

LBに対してコンテンツをリクエストすると、エッジサーバ(Google Front End GFE)に到達
LBのurl mapがCLoud CDNの構成されたバックエンド、あるいはバケットに
トラフィックをルーティングする際にCDNを利用する

キャッシュヒット・ミス

コンテンツを保存・管理するサーバのグループ
対象コンテンツに対する将来のリクエストを高速で処理できるようにする

キャッシュ保存されたコンテンツ = 送信元サーバ

キャッシュヒット:

キャッシュに保存されているそのレスポンスをユーザーに送信

ラウンドトリップ時間が短くなる

部分ヒット:

リクエストの一部分がキャッシュから、一部分がバックエンドから配信された場合に発生

キャッシュミス:

コンテンツが初めてリクエストされたとき
キャッシュからリクエストを処理できないとみなす

特定のキャッシュに保存されるのは、

  • リクエストがそのキャッシュを通過
  • そのリクエストに対するレスポンスがキャッシュ可能な場合だけ

公式:
https://cloud.google.com/cdn/docs/overview?hl=ja

ktkt

Artifact Registry概要

パッケージと Docker コンテナ イメージを 1 か所で保管し管理するリポジトリ
従来のContainer Registry の機能を拡張したもの

公式:
https://cloud.google.com/artifact-registry/docs/overview?hl=ja

リポジトリの作成方法

  • terraformで作成
  • gcloudコマンドで作成
  • コンソールから作成

などなど

コマンド例:

gcloud artifacts repositories create $REGISTRY_NAME --repository-format=docker --location $REGION --description="Docker repository" --project $PROJECT

引用資料:
https://blog.usize-tech.com/cloud-run-auto-deploy/

参考記事:
https://zenn.dev/htr_art/articles/b00cfa9af06d12

ktkt

Container RegistryからArtifact Registryへの移行

事前準備

  • Container Registry
gcloud auth configure-docker 
  • Artifact Registry
gcloud auth configure-docker ** 対象region **-docker.pkg.dev

Container Registryのイメージをローカルにpull

docker pull asia.gcr.io/project-id/image-name:latest
# 確認
docker image

イメージのビルドとタグ付け

# docker tag Container Registryのパス Artifact Registry:タグを入れる
docker tag asia.gcr.io/project-id/image-name region名-docker.pkg.dev/project-id/リポジトリ名/image-name:1.0

# 確認
docker image

コンテナレジストリのイメージをArtifact Registryへpushする

# ↑でタグづけしたイメージをpush
docker push region名-docker.pkg.dev/project-id/リポジトリ名/image-name:1.0

公式:
https://cloud.google.com/artifact-registry/docs/transition/transition-from-gcr?hl=ja
https://cloud.google.com/artifact-registry/docs/transition/changes-docker?hl=ja

ktkt

IPアドレスを使ってssh接続のメモ

ssh itd@IPアドレス番号

The authenticity of host '***' can't be established.
RSA key fingerprint is SHA256:***.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '****' (RSA) to the list of known hosts.
itd@****'s password: 

ktkt

Workload Identityについて

概要

キーなしの新しいアプリケーション認証メカニズム
AWS、Azure で実行するワークロードは、外部 ID プロバイダ(IdP)と連携し、
サービス アカウント キーを使用せずに Google Cloud リソースを呼び出すことができる

Google Cloud の外部で実行されているアプリケーションが、
外部 ID プロバイダの認証情報を使用してサービス アカウントの権限を借用する

外部環境の認証メカニズムをアプリケーションで使用できるようになり、
セキュリティを強化できます。また、サービス アカウント キーを置き換えることも可能

GitHub Actions ではワークフローでデプロイジョブの ID が反映された ID トークンを取得できる

ワークロードはセキュリティ トークン サービス(STS)エンドポイントを呼び出して、
IdP から取得した認証トークンを有効期間が短い GCP アクセス トークンと交換
アクセス トークンを使用してサービス アカウントになりすまして、
GCP リソースにアクセスするサービス アカウントの権限を継承

設定手順

①GCP プロジェクトで、Workload Identity プールのリソース オブジェクトを作成

②IdP を Workload Identity プールに接続
IdP はOIDC プロトコルをサポートする AWS や Azure のアカウントまたはプロバイダのいずれか

③IAM ポリシーを定義して、プールにリソースへのアクセス権を付与

  • サービス アカウントに、目的のリソースへのアクセスを許可するポリシー
  • プールの ID がサービス アカウントになりすますことを許可するポリシー

GKE事例の記事:
https://blog.recruit.co.jp/rls/2019-12-23-workload-identity/

引用公式記事:
https://cloud.google.com/blog/ja/products/identity-security/enable-keyless-access-to-gcp-with-workload-identity-federation

ktkt

Artifact Registryにnpmプライベートリポジトリの内容をpublishする

事前準備

npmのローカルセットアップ

# brewでインストール
brew install nodebrew

# zsh用のセット
vim ~/.zshrc
export PATH=$HOME/.nodebrew/current/bin:$PATH
source ~/.zshrc

# 確認
nodebrew setup
nodebrew -v

# リモートのバージョン確認
nodebrew ls-remote

nodebrew install ***
nodebrew use ***
nodebrew -ls

Artifact Registryのリポジトリ作成

gcloud artifacts repositories create REPOSITORY \
    --repository-format=npm \
    [--location=LOCATION] \
    [--description="DESCRIPTION"] \
    [--kms-key=KMS-KEY] \
    [--async] \

https://cloud.google.com/artifact-registry/docs/repositories/create-repos#create

あるいは手動で作成

リポジトリを設定

 gcloud artifacts print-settings npm \
    --project=**** \
    --repository=test-npm--repository \
    --location=asia-**** \
    --scope=@****

scope

作成したリポジトリパッケージ名
package.jsonのnameを入力する

  "name": "@npm-test/private-repositry",
  "version": "***",

↑の場合@***まで /以降は不要

※gcloud artifacts print-settings npm実行時に出力された
Insert the following snippet into your project .npmrc の部分2行を.npmrcに貼るので保存しておく

.npmrcの作成・編集

touch .npmrc
vim .npmrc
# 前の項目にあった2行を貼り付け
@SCOPE:registry=https://asia-northeast1-npm.pkg.dev/プロジェクトID/REPOSITRY/
//asia-northeast1-npm.pkg.dev/プロジェクトID/REPOSITRY/:always-auth=true

以下コマンドを実施する

npm run artifactregistry-login

> @*****@*.**.0 artifactregistry-login
> npx google-artifactregistry-auth

Need to install the following packages:
  google-artifactregistry-auth@3.0.2
Ok to proceed? (y) y
Retrieving application default credentials...
Success!

npx google-artifactregistry-auth
npx: 47個のパッケージを4.278秒でインストールしました。
Retrieving application default credentials...
Success!

最後にnpm publish実行

公式:
https://www.npmjs.com/package/google-artifactregistry-auth
https://cloud.google.com/artifact-registry/docs/nodejs/store-nodejs?hl=ja
https://www.npmjs.com/package/google-artifactregistry-auth?activeTab=readme

npm publish
https://docs.npmjs.com/cli/v9/commands/npm-publish

npm scope
https://docs.npmjs.com/cli/v9/using-npm/scope

流れがわかりやすい記事・引用資料:
https://qiita.com/takaHAL/items/53c6264c9101cd3142d6

ktkt

Cloud SQLのログイン履歴 監視対応の調査メモ

Cloud SQL 用 IAM
https://cloud.google.com/sql/docs/mysql/iam-overview?hl=ja

Cloud SQL IAM の役割と権限について

Cloud SQL リソースへのアクセス権を制御できるように、Cloud SQLには事前定義ロールが用意されている
事前定義ロールの中に必要な権限を付与するものがない場合、カスタムロールを独自に作成する

Cloud SQL では IAM Conditions もサポートしているため、個々の Cloud SQL リソースレベル
(プロジェクト内のインスタンスやバックアップなど)でロールと権限を調整できます

IAM ポリシー バインディングのプロパティとして条件を追加して、
メンバーがアクセスできるインスタンスのサブセットを指定できます

IAM の条件を使用すると、さまざまな属性に基づいてロールを付与できます
たとえば、特定の日時にのみアクセスを許可することや、
特定の名前の Cloud SQL リソースにのみアクセス権を付与することが可能

Cloud Audit Logs を使った操作

監査ログを使用すると、ログインなどのデータアクセスの記録を保持できます。
デフォルトでは、Cloud Audit Logs は無効になっています。
ログインをトラッキングするには、データアクセスの監査ログを有効にする必要があります。
この目的で監査ロギングを使用すると、データロギングの費用が発生します。
詳細については監査ログ、データアクセス監査ログの構成、データロギングの料金をご覧ください。

https://cloud.google.com/sql/docs/mysql/authentication?hl=ja#work_with

  1. セキュリティ上、IAM データベース認証を使用したログインは SSL 接続でのみ使用できます。暗号化されていない接続は拒否されます。2. 各インスタンスには分単位のログイン割り当てがあります。これには、成功したログインと失敗したログインの両方が含まれます。割り当てを超過すると、一時的にログインできなくなります。頻繁にログインするのではなく、承認済みネットワークを使用してログインを制限することをおすすめします。ログインの承認の割り当ては、インスタンスごとに 1 分あたり 3, 000 です。3. MySQL 5.6 を使用するインスタンスでは、IAM データベース認証はサポートされていません。

監査ログ
https://cloud.google.com/sql/docs/mysql/audit-logging?hl=ja

Cloud SQL for MySQL によって作成される監査ログについて

監査ログが書き込まれ、Google Cloud リソース内で「誰が、いつ、どこで、何をしたか」の確認に役立つ

Cloud SQL for MySQL では、次の種類の監査ログを使用できる

  • 管理アクティビティ監査ログ
メタデータまたは構成情報を書き込む「管理書き込み」オペレーションが含まれます。
管理アクティビティ監査ログは無効にできません。

  • データアクセス監査ログ ←本題
メタデータまたは構成情報を読み取る「管理読み取り」オペレーションが含まれます。ユーザー提供データの読み取りまたは書き込みを行う「データ読み取り」オペレーションと「データ書き込み」オペレーションも含まれます。
データアクセス監査ログを受信するには、監査ログを明示的に有効にする必要があります。

  • システム イベント監査ログ
リソースの構成を変更する自動化された Google Cloud アクションを特定します。
システム イベント監査ログは無効にできません。

監査ログのログイン情報を表示する

監査ログを有効にして、データベースへの IAM ログインをキャプチャできます。
ログインで問題が発生した場合は、監査ログを使用して問題を診断できます。

注: 監査ロギングには追加費用が発生します。詳細については、データロギングの料金をご覧ください。

構成が完了すると、ログ エクスプローラを使用して、成功したログインのデータアクセス監査ログを表示できます。

https://cloud.google.com/sql/docs/mysql/add-manage-iam-users?hl=ja#viewing-login-audit-logs