GCPメモ
Marketplaceについて
インターネット上に存在するモノやサービスの売り手と買い手が自由に参加できる
取引市場のこと
GCPのマーケットプレイスではイメージが取引されている
↓
設定済みのOSのインストールディスクのようなもの
簡単に設定済みのOSをセットアップできる
例:
wordpress with nginx and ssl certified by bitnami and automattic
Anthosについて
GCP IAM impersonateについて
AWSでいう所のassume role
持っていない権限に関して、サービスアカウントの権限を成りすまして利用できるようにする
サービスアカウント:
アプリケーションからGoogle Cloudにアクセスする際に用いられるアカウント
参考:
公式:
provider googleのaliasについて
公式:
サービスアカウントについて
アプリケーションから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 などに保管されているデータの
プロジェクトからの持ち出し防止
公式:
引用資料:
Cloud Asset Inventoryについて
Google Cloud上のアセットを管理できるサービス
アセット
↓
- リソース
Compute Engine 仮想マシン(VM)やCloud Storage バケットなどの
Google Cloud上で作成されたリソースのメタデータ
- ポリシー
IAMポリシー、Organizationsポリシーなど、誰が何にアクセスできるかという情報(ポリシーのメタデータ)
Cloud SQL Auth Proxy
概要:
TLS 1.3 と 256 ビット AES 暗号を使用して、データベースとの間で送受信されるトラフィックを自動的に暗号化
SSL 証明書はクライアントとサーバーの ID を確認するために使用され、データベース プロトコルから独立する為、管理不要
公式資料:
Stackdriver Error Repotingとは Terraformにおける有効化
アプリケーションのエラーをレポートし、デプロイした Web アプリケーションのバグ修正や障害の対応に役立てる情報を提供するためのサービス
NewRelic、Datadog等
Terraformにおける有効化
書き込み権限の場合、ロールから探して追加
ロール→error reporting 書き込みでフィルタリング
"roles/errorreporting.writer" = [
"serviceAccount:〜〜〜.iam.gserviceaccount.com",
]
GKEのNode Poolについて
node(仮想マシン)のグループを作成する機能
1つのクラスタの中で複数の実行環境を管理するもの
Google Cloudの多彩なサイズのマシンタイプ(n1-standard, n1-hignmem, …)から
処理能力の異なるプールを作成できる
例:
DBMSはCPU/メモリ性能の高いプール、Webフロントは比較的低スペックでマシン数の多いプール、
というように特性に合わせたハードにコンテナをアサインすることが可能
GKE アクセススコープについて
node_config/oauth_scopes
公式:
GCP compute engine IAMロールと権限 メモ
Compute Engine IAMのロールと権限
Compute OS 管理者ログインのロール
gcloudコマンド 設定変更系
分かりやすい
Apigeeについて
資料
Google Cloud における Twelve-Factors App 開発
日本語解説記事
公式:
FirebaseとCloud Firestoreとの違い
Firestore:
mBaaSと呼ばれるサービス mobile backend as a Service
iOS/AndroidアプリやWebアプリケーションの開発に活用できるプラットフォーム
モバイルアプリ開発のバックエンド側のインフラを提供
Cloud Firestore:
非常にスケーラブルなクラウドホスト型のNoSQLリアルタイムデータベース
記事:
Pub/Subについて
publisher / subscriber
パブリッシュ/サブスクライブ・メッセージング方式を使用してメッセージ (パブリケーション) をそれぞれ送信および受信するアプリケーション
パブリッシャー:情報の提供者
サブスクライバー:有料テレビの契約者や雑誌の予約購読者
参考記事:
ログ エクスプローラについて
解説記事:
IAP詳細
Identity-Aware Proxy
Google のアカウントを使ってセキュアにリソースに接続できるプロキシサービス
ユーザーとアプリケーションの間に入って通信を仲介する
アプリへのアクセスを許可するユーザーを管理者が制御でき、従業員はVPNを利用しなくても安全にウェブベースのアプリケーションにアクセスできる
公式:
解説記事:
グローバルロードバランサー
マルチリージョンにデプロイされたサービスにアクセスする場合に使用する
- 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 人の個人が悪意のある操作を行うのに必要なすべての権限を持たないようにするという概念
- ユーザーによるデータの変更や削除は必ず検出される
- どのユーザーも機密データを盗み出すことはできない
- どのユーザーにも機密性の高いシステムの設計、実装、レポートを担当させない
目的:
利害の対立の防止
管理不全の検出
GKE IAM確認用
ライブマイグレーション
実行しているVMインスタンスの実行を継続したまま、別のホストへ移行するための仕組み
公式:
解説記事:
ユーザー・プロジェクト・ロール・ポリシーなどの整理
- メンバーはログインで識別される
- ロールは単なる権限のリスト
ポリシーはロールをユーザーに割り当てるための手段
ポリシーには一連のユーザーを設定し、ロールを割り当てる
ロールとユーザーのそれぞれの組み合わせはバインディング
と呼ばれる
ポリシーはリソース階層の任意の場所に設定可能
↓
組織、プロジェクト、個々のリソースに設定できる
ロールは個人ではなく、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 アプリケーションのみ を保護できる
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内のデータがスキャンされる
- 画像スキャンも可能
- メール、クレカなどの情報が検出される
- 独自の情報タイプを追加可能
- 機密データを削除、マスキング、トークン化できる
GCPのプライマリおよびセカンダリ CIDR 範囲について
公式:
GCPのログについて
参考:
電車で読む用
ログ周りのドキュメント
必見 わかりやすく解説
Terraform で Stackdriver の通知設定をする
Kubernetes Engine で動作するアプリでのロギングの使用
ログ エクスプローラを使用したサンプルクエリ
公式 ログ エクスプローラでクエリを作成
ログエクスプローラーのクエリで問題を検知する
ログエクスプローラーのクエリで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"
参考:
公式:メトリクス・アラートリソースのフィルターをヒアドキュメントで可読性高くする
改行や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 に保存したログはインデックスに登録されて最適化され、
ログをリアルタイムで分析できるように配信される
公式:
CloudSQLのSlow Query確認
cloud loggingでの確認
クエリ例:
resource.type="cloudsql_database"
logname="{var.project_id}.cloudsql.googleapis.com%2Fmysql-slow.log
mysql-slow.log、mysql.errorなど指定する
公式: (古いのでstack driverが使われている点に注意)
Cloud Loab Balancingまとめ
特徴
- 単一のエニーキャスト IP アドレス
- レイヤ 4 /レイヤ 7 のロード バランシング
- 外部ロードバランシング/内部ロードバランシング
→インターネットからアプリケーションにアクセス:外部
→Google Cloud内のアプリ間通信:内部 - グローバル ロードバランシング/リージョンロードバランシング
→ロード バランシングされたリソースを単一または複数のリージョンに分散
公式:
gcloud sshコマンド
gcloud compute ssh --project=プロジェクト名 --zone=ゾーン名 インスタンス名
資料:
スナップショットを権限つきで作成する
gcloud compute snapshots create スナップショット名 \
--source-disk ディスク名 \
--source-disk-zone ゾーン名 \
--project プロジェクト名 \
--impersonate-service-account=〜〜@〜〜.com
※--impersonate で利用できる権限を付与することでワンライナーにて実施可能
スナップショットが作成された事を確認
gcloud compute snapshots list --project プロジェクト名 | grep 作成したスナップショット名
公式:
VMへのSSHログインをimpersonateでサービスアカウントになりすましてワンライナーで対応する
gcloud compute ssh 対象インスタンス名 \
--zone 対象ゾーン名 \
--project 対象プロジェクト名 \
--impersonate-service-account=〜〜@〜〜.com
Asset Inventoryでリソースの確認
参考資料:
Recommenderについて
組織内のプロジェクトの使用状況が分析され、
放置プロジェクトの検出、再利用、削除に役立つ推奨事項が表示される
ユースケースの紹介
公式:
放置されたプロジェクトの Recommender
料金:
サーバレスエクスポートについて
内部的に稼働しているDBインスタンスとは別の一時的なDBインスタンスを新たに作成
↓
その一時的なDBインスタンスを利用してデータのエクスポートを行う
↓
稼働しているDBインスタンスへの影響を回避する
メリット:
- 本番に影響を与えない
デメリット:
- 一時的なDBインスタンスの作成に時間がかかるため、標準エクスポートよりも時間がかかる
- DBインスタンスの追加料金が発生する
引用資料:
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 [./対象ディレクトリ].
参考資料:
Cloud Run概要
サービス、リビジョン、コンテナインスタンスの3つで構成される
サービス
Cloud Runのメインリソース
実行環境にデプロイされたアプリケーションを表す
各サービスは特定のリージョンに属するが、冗長性とフェイルオーバーのため、
リージョン内の複数ゾーンに自動的に複製される
リビジョン
サービスがデプロイされるたびに作成される
環境変数、メモリ制限、同時実行などの環境設定
+
特定のコンテナイメージから構成される
コンテナインスタンス
リビジョンの実体がコンテナインスタンス
リビジョンは受信した全てのリクエストを処理できるように、コンテナインスタンスの数を自動的にスケーリングする
リクエストが届いたサービスに対して、コンテナインスタンスが起動される
リクエストが届かないとコンテナは起動されない
機能
- HTTPS以外で返せない
- 同時に最大250リクエストを処理できる
- 1つのリクエストに対して処理時間 15分以内
- リクエストレートの制限は設定されていない
- 1度リビジョンのキューに保存される
- コンテナへリクエストを渡せない場合、429 too many requestエラー
- コンテナにSSHログインできず、何か変更をするには全てコンテナイメージを作成してデプロイする必要がある
引用資料:
参考資料: パフォーマンス資料:Cloud Runのterraform情報
zozoの記事:
terraformドキュメント
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
}
コネクタを使用するようにサーバレス環境を構成
引用資料:
GKE Sandboxについて
Pod 内のコンテナが不明なコードや信頼できないコードを実行したとき、
またはそのノードから特別に切り離す必要があるときに、
GKE Sandbox を使用してノードのホストカーネルを保護する
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を追加する
参考資料:
他の Google Cloud プロジェクトからイメージをデプロイする: Terraformで追加する時の参考:(google_service_account_iam_bindingを使う)(追記)注意:
google_service_account_iam_bindingは既存のroleを上書きする仕様の為、基本的には使わない。
↓事例:
modules/service_accounts_iamを利用する。
roles/run.invoker権限について
資料:
Secret Managerの作成
下記のコマンドでパスワード付きで生成できる
echo -n "パスワード" | gcloud secrets create Sercret manger名 --data-file=- --impersonate-service-account=
公式:
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)
という構成となる
引用資料:
グローバルなロードバランサーとサーバーレスサービスの色々な組み合わせ
Cloud Run用のLB構築メモ
参考公式モジュール資料:
github:
Cloud Runのバックエンドサービス タイムアウトを変更したいができなかった
バックエンド サービスのタイムアウト設定は、サーバーレス NEG バックエンドを使用するバックエンド サービスには適用されません。バックエンド サービスの resource.timeoutSec プロパティを変更しようとすると、次のエラーが発生します。Timeout sec is not supported for a backend service with Serverless network endpoint groups
サーバーレス NEG バックエンドを使用するバックエンド サービスの場合、デフォルトのタイムアウトは 60 分です。このタイムアウトは構成できません。アプリケーションで長時間の接続が必要な場合は、失敗時にリクエストを再試行するようにクライアントを構成します
引用公式資料:
VPC Access Connector
VPC内にあるリソースを外部に公開する事なく、対象リソース(Cloud Run、Cloud Function)からアクセスができる。
流れ:
VPCを用意
↓
サーバレスVPCアクセスコネクタを作成
↓
Cloud Natを作成
CLoud Run等の対象リソースからのインターネットアクセスが
静的IPアドレスから行われるように設定
資料:
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=***
参考:
cloud runの準備
参考資料:
解説資料:
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}
}
}
言及資料:
--min-instances オプションを指定しておかないと、Idle 状態(リクエストが無い状態)の
コンテナインスタンスは CPU はallocate された状態であっても、
スケールインして最終的にコンテナインスタンスが 0 になってしまう。
期待値としては非同期のワーカーとしてずっと動いていてほしいので、
--min-instances オプションで常に稼働するコンテナインスタンスの数を指定
参考記事:
SSL 証明書の概要 (Google マネージド証明書)
SSL証明書を使用して、LBに転送されるデータのプライバシーとセキュリティを保護する
1 つの証明書で複数のホスト名をサポートしており、Google は証明書を自動的に更新する
Google マネージド証明書は、次のロードバランサでサポートされている。
- グローバル外部 HTTP(S) ロードバランサ(プレビュー)。
- グローバル外部 HTTP(S) ロードバランサ(従来)
- SSL プロキシ ロードバランサ
Google マネージド SSL 証明書は、ドメイン用に Google Cloud が取得して管理する証明書
自動的に更新される。Google マネージド証明書はドメイン認証(DV)証明書。
証明書に関連付けられた組織や個人の ID を証明せず、ワイルドカードの共通名をサポートしない。
公式:
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.
公式:
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
認証設定について:
Terraformによる設定 (Ingress)
template {
metadata {
annotations = {
"run.googleapis.com/ingress" = "internal-and-cloud-load-balancing" // Ingressの設定
}
}
必要設定 公式:
エラー時の対応 公式:
Error Reportingの通知機能 × Cloud Runの対応方法まとめ
主な仕様
- 通知を構成のボタンからslack、Emailに通知が飛ぶよう設定できる
- 既存のエラーに分類できないエラーが初めてGoogle Cloud プロジェクトで発生した場合通知される
- 解決済みとマークされたエラーが再発した場合通知される
- Error Reportingの保存期間は30日まで (30日で消滅する)
通知の上限
Google Cloud プロジェクトで 1 時間以内にエラーが 5 回以上再発した場合、
Error Reporting から最終通知が送られ、
今後 6 時間は通知が送信されないことが伝えられます。これにより、通知の量を制御します。
解決ステータス
解決ステータスが [解決済み] のエラーが再発した場合、
そのエラーがすでに削除されていても、解決ステータスが [対応待ち] に戻され、
Error Reporting から通知が送信されます。
[ミュート中] のエラーが再発した場合は、Error Reporting から通知は送信されません。
サービスアカウントに必要な権限
CLoud Runのサービスアカウントに以下の権限が必要
(errorreporting.writerが本当に必須かは要検証)
(logWriter権限がないと403エラーが生じた)
roles/errorreporting.writer
roles/logging.logWriter
アプリケーション側の実装 (PHP)
公式 PHP用Error Reportingの設定
テスト通知用のログエントリ
参考記事:
Cloud RunでのError Reporting設定(公式)
(公式)
(エラーレポーティング)API:
エラーの管理
フィルタリングと集計
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
分かりやすい記事:
公式:
Aligner 英語ドキュメント:
gcloudコマンドのデバッグ方法
下記のオプションをつける
--verbosity=debug
使用例:
gcloud --verbosity=debug run deploy *** \
--project *** \
--region *** \
--allow-unauthenticated \
--image asia.gcr.io/****:latest
引用記事:
セルフマネージド証明書の作成手順 メモ
①秘密鍵と証明書を作成する
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
公式:
OpenSSLによるCSRの作成について
オレオレ証明書について
参考記事:
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
}
}
}
}
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で実現するやり方はこちら
cloudbuild使う場合はこちら
ECSの場合の事例:
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をセットアップ
以下の記事を参考にセットアップ
③gcloud auth loginを打鍵
gcloud auth login
④冒頭のコマンド例に、作成したサービスアカウント、MLを当てはめて入力
IAM周りの権限解説:
エラー発生日時を日本時間で取得する 注意: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-**-** **:**
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 データベース認証用に構成された
アカウントのログインが有効になる。
公式:
データベースフラグ: cloudsql_iam_authenticationCloud 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の実行を外部から呼び出すことが可能
参考引用記事:
公式
6/11 追加
Cloud Natのルール (エンドポイントに依存しないマッピング)
エンドポイントに依存しないマッピングが有効になっている NAT ゲートウェイに NAT ルールを追加することはできません。NAT ルールが含まれる NAT ゲートウェイで、エンドポイントに依存しないマッピングを有効にすることはできません
IAMの階層構造についての解説
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
参考資料:
Cloud Run Jobsのジョブ対象でgcloudコマンドによるロール付与設定
IAM Policy付与 事例:
gcloud beta run jobs add-iam-policy-binding ジョブ名 \
--member="group:***@****.co.jp" \
--role="roles/run.invoker" \
--project ****
確認:
gcloud beta run jobs get-iam-policy ジョブ名 --project ****
参考資料:
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のマッピング動作の判定方法
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を
利用することによるデメリットはほぼ無い
引用資料:
Cloud Loggingのよく使うクエリ
リンク:
startup CPU boost
Cloud FunctionsやCloud Runにおけるコールドスタートで時間がかかる起動時間を短縮する
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/****
公式:
日本語参考情報
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 (第二世代)
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
}
}
}
}
公式:
日本語参考情報:
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
公開イメージの取得
apache
terraform :
ログ関連
Cloud CDNのキャッシュヒット率
リクエストされたオブジェクトがキャッシュから提供される回数の割合
キャッシュ ヒット率が 60% の場合、
リクエストされたオブジェクトがキャッシュから 60% の割合で提供
送信元から 40% の割合で取得
Cloud Monitoring ダッシュボードの作成
参考記事:
指標選択:
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"
公式:
Cloud Loggingのクエリ 正規表現
公式:
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を利用する
キャッシュヒット・ミス
コンテンツを保存・管理するサーバのグループ
対象コンテンツに対する将来のリクエストを高速で処理できるようにする
↓
キャッシュ保存されたコンテンツ = 送信元サーバ
キャッシュヒット:
キャッシュに保存されているそのレスポンスをユーザーに送信
↓
ラウンドトリップ時間が短くなる
部分ヒット:
リクエストの一部分がキャッシュから、一部分がバックエンドから配信された場合に発生
キャッシュミス:
コンテンツが初めてリクエストされたとき
キャッシュからリクエストを処理できないとみなす
特定のキャッシュに保存されるのは、
- リクエストがそのキャッシュを通過
- そのリクエストに対するレスポンスがキャッシュ可能な場合だけ
公式:
Artifact Registry概要
パッケージと Docker コンテナ イメージを 1 か所で保管し管理するリポジトリ
従来のContainer Registry の機能を拡張したもの
公式:
リポジトリの作成方法
- terraformで作成
- gcloudコマンドで作成
- コンソールから作成
などなど
コマンド例:
gcloud artifacts repositories create $REGISTRY_NAME --repository-format=docker --location $REGION --description="Docker repository" --project $PROJECT
引用資料:
参考記事:
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
公式:
Cloud Monitoring Aggregationの分かりやすい解説記事
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:
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事例の記事:
引用公式記事:
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] \
あるいは手動で作成
リポジトリを設定
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実行
公式:
npm publish
npm scope
流れがわかりやすい記事・引用資料:
gcloud configのrun region設定リセット方法
以下で変更可能
gcloud config unset run/region REGION
設定したい場合はsetにする
公式:
config list
Cloud SQLのログイン履歴 監視対応の調査メモ
Cloud SQL 用 IAM
Cloud SQL IAM の役割と権限について
Cloud SQL リソースへのアクセス権を制御できるように、Cloud SQLには事前定義ロールが用意されている
事前定義ロールの中に必要な権限を付与するものがない場合、カスタムロールを独自に作成する
Cloud SQL では IAM Conditions もサポートしているため、個々の Cloud SQL リソースレベル
(プロジェクト内のインスタンスやバックアップなど)でロールと権限を調整できます
IAM ポリシー バインディングのプロパティとして条件を追加して、
メンバーがアクセスできるインスタンスのサブセットを指定できます
IAM の条件を使用すると、さまざまな属性に基づいてロールを付与できます
たとえば、特定の日時にのみアクセスを許可することや、
特定の名前の Cloud SQL リソースにのみアクセス権を付与することが可能
Cloud Audit Logs を使った操作
監査ログを使用すると、ログインなどのデータアクセスの記録を保持できます。
デフォルトでは、Cloud Audit Logs は無効になっています。
ログインをトラッキングするには、データアクセスの監査ログを有効にする必要があります。
この目的で監査ロギングを使用すると、データロギングの費用が発生します。
詳細については監査ログ、データアクセス監査ログの構成、データロギングの料金をご覧ください。
- セキュリティ上、IAM データベース認証を使用したログインは SSL 接続でのみ使用できます。暗号化されていない接続は拒否されます。2. 各インスタンスには分単位のログイン割り当てがあります。これには、成功したログインと失敗したログインの両方が含まれます。割り当てを超過すると、一時的にログインできなくなります。頻繁にログインするのではなく、承認済みネットワークを使用してログインを制限することをおすすめします。ログインの承認の割り当ては、インスタンスごとに 1 分あたり 3, 000 です。3. MySQL 5.6 を使用するインスタンスでは、IAM データベース認証はサポートされていません。
監査ログ
Cloud SQL for MySQL によって作成される監査ログについて
監査ログが書き込まれ、Google Cloud リソース内で「誰が、いつ、どこで、何をしたか」の確認に役立つ
Cloud SQL for MySQL では、次の種類の監査ログを使用できる
-
管理アクティビティ監査ログ メタデータまたは構成情報を書き込む「管理書き込み」オペレーションが含まれます。 管理アクティビティ監査ログは無効にできません。
-
データアクセス監査ログ ←本題 メタデータまたは構成情報を読み取る「管理読み取り」オペレーションが含まれます。ユーザー提供データの読み取りまたは書き込みを行う「データ読み取り」オペレーションと「データ書き込み」オペレーションも含まれます。 データアクセス監査ログを受信するには、監査ログを明示的に有効にする必要があります。
-
システム イベント監査ログ リソースの構成を変更する自動化された Google Cloud アクションを特定します。 システム イベント監査ログは無効にできません。
監査ログのログイン情報を表示する
監査ログを有効にして、データベースへの IAM ログインをキャプチャできます。
ログインで問題が発生した場合は、監査ログを使用して問題を診断できます。
注: 監査ロギングには追加費用が発生します。詳細については、データロギングの料金をご覧ください。
構成が完了すると、ログ エクスプローラを使用して、成功したログインのデータアクセス監査ログを表示できます。
IAM関連メモ
AWSとの違い
Organization