GCP ACE 試験対策メモ①

GCP
  1. はじめに
  2. 出題範囲
  3. クラウド ソリューション環境の設定
    1. クラウド プロジェクトとアカウントを設定する。
      1. プロジェクトを作成する
      2. プロジェクト内で事前定義された IAM ロールにユーザーを割り当てる
      3. Cloud Identity でユーザーを管理する(手動および自動)
      4. プロジェクトで API を有効にする
      5. Stackdriver ワークスペースをプロビジョニングする
    2. 課金構成を管理する。
      1. 請求先アカウントを作成する
      2. プロジェクトを請求先アカウントにリンクする
      3. 課金の予算とアラートを設定する
      4. 日 / 月単位の料金見積もりを目的として請求関連のエクスポートを設定する
    3.  コマンドライン インターフェース(CLI)
  4. クラウド ソリューションの計画と構成
    1. 料金計算ツールを使用して GCP プロダクトの使用量を計画して見積もる
    2. コンピューティング リソースを計画、構成する
      1. ワークロードに適したコンピューティング サービスの選択
      2. プリエンプティブル VM とカスタム マシンタイプの適宜使用
    3. データ ストレージ オプションを計画、構成する
      1. プロダクトの選択
      2. ストレージ オプション
    4. ネットワーク リソースを計画、構成する
      1. 負荷分散オプションの違いを見分ける
      2. 可用性を考慮してネットワーク内のリソースのロケーションを決定する
      3. Cloud DNS を構成する
  5. クラウド ソリューションのデプロイと実装
    1.  Compute Engine リソースをデプロイ、実装する
      1. インスタンスの起動(Cloud Console , Cloud SDK (gcloud))
      2. 自動スケーリングされるマネージド インスタンス グループの作成
      3. インスタンス用のカスタム SSH 認証鍵を生成、アップロードする
      4. VM で Stackdriver Monitoring と Stackdriver Logging の構成を行う
      5. コンピューティングの割り当てを評価し、割り当ての引き上げをリクエストする
      6. モニタリングとロギング用に Stackdriver Agent をインストールする
    2. Google Kubernetes Engine リソースをデプロイ、実装する
      1. Google Kubernetes Engine クラスタをデプロイする
      2. Pod を使用して Google Kubernetes Engine にコンテナ アプリケーションをデプロイする
      3. Google Kubernetes Engine アプリケーションのモニタリングとロギングを構成する
    3. App Engine、Cloud Run、Cloud Functions をデプロイ、実装する。
      1. アプリケーションをデプロイし、スケーリング構成、バージョン、トラフィック分割を更新する
        1. スケーリング
        2. バージョニング、トラフィック分割
      2. Google Cloud イベントを受け取るアプリケーションをデプロイする
    4. データ ソリューションをデプロイ、実装する
      1. プロダクトを使用してデータシステムを初期化する
      2. データを読み込む
    5. ネットワーキング リソースをデプロイ、実装する
      1. サブネットを持つ VPC(例: カスタムモード VPC、共有 VPC)を作成する
      2. カスタム ネットワーク構成を持つ Compute Engine インスタンスを起動する
      3. VPC 用の上り(内向き)および下り(外向き)ファイアウォール ルール
      4. Cloud VPN を使用して Google VPC と外部ネットワークとの間の VPN を作成する
      5. アプリケーションへのネットワーク トラフィックを分散するロードバランサを作成する
    6. Cloud Marketplace を使用してソリューションをデプロイする。
    7. Cloud Deployment Manager を使用してアプリケーション インフラストラクチャをデプロイする

はじめに

ある程度、GCPの試験対策が進んだので、情報を整理するためのページ

出題範囲のうち、以下を記載。

  1. クラウド ソリューション環境の設定
  2. クラウド ソリューションの計画と構成
  3. クラウド ソリューションのデプロイと実装

残りについては以下のページ

出題範囲

Associate Cloud Engineer 認定資格  |  Google Cloud
Google Cloud Certified Associate Cloud Engineer は、目標となるパフォーマンス指標を確実に達成するため、アプリケーションのデプロイ、複数プロジェクトのオペレーションのモニタリング、エンタープライズ ソリューションの管理を行います。

クラウド ソリューション環境の設定

クラウド プロジェクトとアカウントを設定する。

プロジェクトを作成する

実際に作成して、試してみた。
特筆する事項は特になし。

プロジェクト内で事前定義された IAM ロールにユーザーを割り当てる

実際に割り当てして、試してみた。

ロールには以下の3種類が存在する。

項目内容
基本ロールIAM の導入前に存在していたオーナー、編集者、閲覧者のロールが含まれます。
事前定義ロール特定のサービスへのアクセスを細かく制御します。
また、Google Cloud により管理されます。
カスタムロールユーザー指定の権限のリストに応じたきめ細かなアクセス権が提供されます。

基本ロール、事前ロールでは権限の割り当てが過剰すぎる際にカスタムロールを使う

コマンドラインでのロール割り当て方法も確認しておくこと。

### メンバーへのロールの割り当て
gcloud projects add-iam-policy-binding プロジェクトID \
  --member=MEMBER \
  --role=ROLE \
  [--condition=[KEY=VALUE,…] | --condition-from-file=CONDITION_FROM_FILE] [GCLOUD_WIDE_FLAG …]

### カスタムロールの作成
gcloud iam roles create ROLE_ID \
  --project=PROJECT_ID \
  [--file=FILE | --description=DESCRIPTION --permissions=PERMISSIONS --stage=STAGE --title=TITLE]\
  [GCLOUD_WIDE_FLAG …]

### カスタムロール作成時にはロールresourceの定義ファイルが必要
例.
{
  "name": string,
  "title": string,
  "description": string,
  "includedPermissions": [
    string
  ],
  "stage": enum (RoleLaunchStage),
  "etag": string,
  "deleted": boolean
}

IAMのコマンドは頻出なので、正しく理解しておく。
基本的には以下をおさえておけば良いと思われる。

項目内容
gcloud projects add-iam-policy-binding プロジェクトID \
–member=MEMBER \
–role=ROLE \
メンバーへのロールの割り当て。
gcloud projectsから始まるので注意
gcloud iam rolesロールを作成および操作する
gcloud iam service-accountsサービスアカウントを作成および操作します
gcloud iam list-grantable-roles RESOURCE \
[–filter=EXPRESSION] \
[–page-size=PAGE_SIZE; default=100] \
[GCLOUD_WIDE_FLAG …]
あまり出てこないかも?
公式模擬試験で出てきた。
リソースに付与可能なロールのリストを表示。
(権限の確認とかには使わない)
gcloud iam list-testable-permissions見たことないけど、一応。
リソースのIAMテスト可能な権限を一覧表示します
テスト可能なアクセス許可とは・・・
「ユーザーが特定のリソースのロールで
追加または削除できるアクセス許可を意味」

現在、どのメンバーに何のロールが割り当てられているかを確認するにはCloud Consoleを使う。

役割にどんな権限が含まれているかを確認するにはCloud Consoleを使う。

Cloud Identity でユーザーを管理する(手動および自動)

ドメインの取得、組織の設定が必要となる。
コストが重たいので、未実施。

プロジェクトで API を有効にする

実際に試してみた。
特筆する事項は特になし。

Stackdriver ワークスペースをプロビジョニングする

実際に試してみた。
代表的なMonitoring、Error Reporting、Loggingは実施済み。


課金構成を管理する。

請求先アカウントを作成する

実際に試してみた。
特筆事項は無し。
以下のような内容を入力すればよい。

プロジェクトを請求先アカウントにリンクする

実際に試してみた。
特筆事項は無し。

抑えておくポイント

  • 各プロジェクトとそのサービスレベルのリソースに対する請求先アカウントは常に 1 つ
  • Cloud 請求先アカウントは、1 つ以上のプロジェクトにリンクできます。

課金の予算とアラートを設定する

実際に試してみた。

通知方法については抑えておく。
通知方法はメールアラート以外にもCloud Pub/Subに飛ばすことができる。
Pub/Subに飛ばした通知をCloud Functionで拾ってSlackに飛ばすとかの用途に使う。

日 / 月単位の料金見積もりを目的として請求関連のエクスポートを設定する

実際に試してみた。

Bigqueryに請求データをエクスポートすることができる点をおさえておく。

Cloud Billing データを BigQuery にエクスポートする  |  Google Cloud

 コマンドライン インターフェース(CLI)

gcloud環境の設定変更(超重要

### アカウントの変更
$ gcloud config set core/account アカウント名

### プロジェクトの変更
$ gcloud config set project プロジェクト名

### デフォルトリージョンの設定
$ gcloud config set compute/region asia-northeast1

### デフォルトゾーンの設定
$ gcloud config set compute/zone asia-northeast1-a

### 変更後の確認
$ gcloud config list
(省略)
[compute]
gce_metadata_read_timeout_sec = 30
region = asia-northeast1
zone = asia-northeast1-a

gcloudコンフィグセットの作成、適用

### コンフィグセットの一覧を表示
gcloud config configurations list

### コンフィグセット(testconfig)を作成
gcloud config configurations create testconfig

### 任意の設定の有効化
gcloud config configurations activate CONFIGURATION_NAME [GCLOUD_WIDE_FLAG …]

gcloud SDKのインストール方法

Google Cloud SDK のインストール  |  Cloud SDK のドキュメント

インストール後の初期設定

Cloud SDK の初期化  |  Cloud SDK のドキュメント  |  Google Cloud
gcloud init

クラウド ソリューションの計画と構成

料金計算ツールを使用して GCP プロダクトの使用量を計画して見積もる

実際に試してみた。
特筆事項は特になし。

とても幅広い範囲で予算を見積もれる。

Google Cloud Platform 料金計算ツール
サーバーの台数、利用状況、処理能力に基づいて、Google Cloud Platform から提供されるプロダクトに関して、お客様に合わせてカスタマイズした見積もりを作成します。

別項で取り上げるが、Bigqueryのコスト(dryrun)と合わせておさえておく。


コンピューティング リソースを計画、構成する

ワークロードに適したコンピューティング サービスの選択

以下のサービスの特徴をおさえておく

サービス名概要
Compute EngineVMインスタンス
Google Kubernetes EngineマネージドKubernetesサービス
App Engineアプリケーションの実行基盤サービス。PaaS
gcloud app コマンドでCLIから操作デプロイするのが特徴
スタンダード、フレキシブルと、構成に違いがある。

https://www.homatin.com/2021/01/20/gcp-app-engine%e4%bd%bf%e3%81%a3%e3%81%a6%e3%81%bf%e3%81%9f/
Cloud Rungcloud run deploy コマンドでContainer Repositoryからコンテナをデプロイできる。
HTTPサービスのコンテナデプロイに適している?
Cloud Buildと合わせて確認をしておくこと。

https://www.homatin.com/2021/02/17/gcp-cloud-run-%e3%83%a1%e3%83%a2/
Cloud Functions関数を実行する基盤。
HTTPリクエストをトリガーにした関数(REST APIチックなものを作成する用途)
Cloud Pub/Subをトリガーにした関数(パイプライン処理をする用途)
と、柔軟にちょっとしたものを動かすときに使う。

プリエンプティブル VM とカスタム マシンタイプの適宜使用

実際に試してみた。
特筆事項は特になし。
VM作成時のオプションで設定する。

プリエンプティブルVM
格安だけど、勝手に落ちる、Google都合でどうとでもされるVM

カスタムマシンタイプ
CPU、メモリーを自分で定義。(デフォルトはe2-microとか事前定義のを使う)


データ ストレージ オプションを計画、構成する

ようするに、データベース。

プロダクトの選択

以下のサービスの特徴をおさえておく

項目内容
Cloud SQLデータベースサービス。以下のストレージエンジンから選択可能。
・MySQL
・PostgreSQL
・SQL Server

アクセス方法(sqlコマンド、sql proxy、gcloud sql)、ACL制御等も確認しておく。
https://www.homatin.com/2021/02/24/cloud-sql-%e8%a9%a6%e3%81%97%e3%81%a6%e3%81%bf%e3%81%9f/
Big Queryビッグデータに対して、クエリを使って解析ができるデータ分析基盤。
保管データだけでなく、クエリに対してもお金がとられる。

以下の内容は重要
・予期せぬクエリで高額請求されないようにするためのdryrunコマンドの活用
・Bigtableとの比較
・Bigquery Data Transfer Serviceでのデータ読み込み
・bqコマンドの使い方
 - bq mk
 - bq query
 - bq ls

https://www.homatin.com/2021/02/15/bigquery-%e3%83%a1%e3%83%a2/
Cloud Spanner高い整合性、大規模な水平スケーリングを備えたRDBサービス。
Cloud SQLと違い、運用方法が少し特殊なため、ツボを押さええておく必要がある。
・リージョン構成とレプリカの構成
・設計上の制約
 - ホットスポット回避のためのスキーマ設計(超重要)
 - データを操作する際のSQLクエリとAPIのすみわけ
 - 自動採番機能が存在しないという点 (ホットスポットが生成されてしまうため)
・インターリープを用いたデータ配置の最適化
・アクセス制御
・暗号化
・バックアップ

https://www.homatin.com/2021/01/25/gcp-cloud-spanner-%e3%83%a1%e3%83%a2/
Cloud BigtableIoTといったビッグデータ用のNoSQLデータベース。
オープンソースのHBaseはBigtableの技術がベースとなるので共通点が多い。
テーブルの特徴をおさえておく必要がある。
・ファミリー、列修飾子とは
・ホットスポット回避のテクニック
 - フィールドプロモーション (無理くり列データを行キー列に合体させる)
 - ソルティング (塩をふりまくみたいな?ハッシュをキーに埋め込む)
 - データのインポート、エクスポート
 - レプリケーション

https://www.homatin.com/2021/01/28/gcp-bigtable-%e3%83%a1%e3%83%a2/

Spannerの構成メモ

Spannerのインスタンスは複数のデータベース(レプリカ)から構成されている。
レプリカが1個のデータベースであり、1、もしくは複数のノードから構成される。
レプリカが配置されるゾーンはGoogleにより決定されており、変更することはできない。
ユーザが変更できるのは1レプリカあたりのノード数のみとなる。

マルチリージョン構成では複数のリージョンにレプリカが設置される。
この時、台湾には投票レプリカが設置される。
投票レプリカはレプリカにデータを書き込む際に、分散DBとしての整合性を確認するための処理に使われる。通常の読み込みとかには使われない。

単一リージョン構成(例.asia-northeast1 東京)

マルチリージョン構成(例.asia1)

ストレージ オプション

Cloud Storageのストレージオプションの選択

ストレージ クラス  |  Cloud Storage  |  Google Cloud
項目内容
Standard Storage頻繁にアクセスされるデータ、短時間だけ保存されるデータ向け
Nearline Storage最小保存期間30日。可用性が若干低い。
データ取得に追加料金がかかる。
ただし、保管に関しては若干コストが低い。
Coldline Storage最小保存期間90日。可用性が低い。
データ取得に追加料金がかかる。
ただし、保管に関してはかなりコストが低い。
Archive Storage最小保存期間365日。可用性SLAは無し。
データ取得にかなり割高な追加料金がかかる。
ただし、保管に関してはかなりコストが低い。
完全に塩漬け用のバックアップデータとかBCP用。

ファイルの更新頻度も考える必要がある。
ファイルの更新が入ると、最小保存期間が更新される。

バケットのロケーションについても出題されるのでおさえておく。

Cloud Storageの暗号化
デフォルトでディスクに書き込まれる前にグーグル管理の鍵で暗号化されている。
それを任意の鍵に変更することが可能。ただし、鍵管理の負担が増えるので注意。
それ以外にも制約事項が増えたりする。

暗号鍵内容
Google管理の暗号鍵デフォルトの動作
顧客管理の暗号鍵
CMEK
Cloud Key Management Service によって生成される暗号鍵を利用
顧客指定の暗号鍵
CSEK
完全に任意の鍵を利用できる

Cloud Consoleのバケットの詳細から変更が可能。
ただし、CMEKのみであり、CSEKの設定ができない。

CSEKを設定するためには以下のどれかのパターンで行う。

暗号鍵の使用  |  Cloud Storage  |  Google Cloud
顧客指定の暗号鍵の使用  |  Cloud Storage  |  Google Cloud

ネットワーク リソースを計画、構成する

負荷分散オプションの違いを見分ける

実際にまとめてはみたが、現時点で押さえておくべきポイントは不明。

項目内容
内部HTTP(S)負荷分散Google Cloud 内部 HTTP(S) 負荷分散は、プロキシベースのリージョンのレイヤ 7 ロードバランサです。内部 IP アドレスの背後でサービスを実行し、スケーリングできます。
内部 HTTP(S) 負荷分散は、Compute Engine と Google Kubernetes Engine(GKE)でホストされているバックエンドに HTTP/HTTPS トラフィックを分散します。ロードバランサには、内部 IP アドレスを使用して Virtual Private Cloud(VPC)ネットワークの特定のリージョンでのみアクセスできます。
外部HTTP(S)負荷分散Google Cloud HTTP(S) 負荷分散は、プロキシベースのグローバルなレイヤ 7 ロードバランサであり、単一の外部 IP アドレスの背後でサービスをグローバルに実行、拡張できます。外部 HTTP(S) 負荷分散は、Compute Engine と Google Kubernetes Engine(GKE)でホストされているバックエンドに HTTP および HTTPS トラフィックを分散します。
内部TCP/UDP負荷分散Google Cloud 内部 TCP / UDP 負荷分散はリージョン単位のロードバランサであり、内部仮想マシン(VM)のインスタンスのみにアクセス可能な内部負荷分散 IP アドレスの背後でサービスの実行とスケーリングを行うことができます。
内部 TCP / UDP 負荷分散は、プライベートの内部 IP アドレスを使用して、Virtual Private Cloud(VPC)ネットワークの同じリージョン内の VM インスタンス間でトラフィックを分散します。
外部TCP/UDP ネットワーク負荷分散Google Cloud の外部 TCP / UDP ネットワーク負荷分散(以降はネットワーク負荷分散と呼びます)は、リージョンのパススルー ロードバランサです。ネットワーク ロードバランサは、同じリージョン内の仮想マシン(VM)インスタンス全体に TCP または UDP トラフィックを分散します。
外部SSL プロキシ負荷分散SSL プロキシ負荷分散は、インターネットから送信された SSL トラフィックを Google Cloud VPC ネットワークの仮想マシン(VM)インスタンスに分散するリバース プロキシ ロードバランサです。
(オフロードしてくれるイメージ)

可用性を考慮してネットワーク内のリソースのロケーションを決定する

特筆事項は無し。

Cloud DNS を構成する

特筆事項は無し。

Cloud DNS の概要  |  Google Cloud

クラウド ソリューションのデプロイと実装

 Compute Engine リソースをデプロイ、実装する

インスタンスの起動(Cloud Console , Cloud SDK (gcloud))

インスタンスの基本操作を覚えておく。
gcloudコマンドの問題が出た時にも対処できるようにしておく。

ディスクの割り当て

gcloud compute instances attach-disk

gcloud compute instances attach-disk  |  Cloud SDK Documentation
gcloud compute instances attach-disk INSTANCE_NAME --disk=DISK \
  [--boot] \
  [--csek-key-file=FILE] \
  [--device-name=DEVICE_NAME] \
  [--disk-scope=DISK_SCOPE; default="zonal"] \
  [--force-attach] \
  [--mode=MODE; default="rw"] \
  [--zone=ZONE] [GCLOUD_WIDE_FLAG …]

可用性ポリシーの割り当て

gcloud compute instances set-scheduling

Googleメンテナンス時のVMの対処方針をどうするかの設定
・ライブマイグレーションを受け入れる
・シャットダウンコマンドを送る

### インスタンス作成時のオプション
gcloud compute instances create INSTANCE_NAME \
    --maintenance-policy MAINTENANCE_POLICY \
    [--no-restart-on-failure]

### 既存インスタンスのオプション変更
gcloud compute instances set-scheduling INSTANCE_NAME \
    --maintenance-policy MAINTENANCE_POLICY \
    [--no-restart-on-failure | --restart-on-failure]

### Maintenance Policy

MIGRATE
The instances should be migrated to a new host.
This will temporarily impact the performance of instances during a migration event.

TERMINATE
The instances should be terminated.

SSH認証鍵の割り当て

GCEのインスタンス(CentOS)を例にとった、SSHまわりのポイント
・sshd_configでパスワード認証がNGになっている。(デフォルトは鍵認証のみ)
・パスワード認証をしたかったら、sshd_configをいじるだけで良い
・デフォルトのSSH鍵はGCPが管理してくれている
・自分で作成したSSH鍵を使いたい場合、公開鍵をメタデータに埋め込む

コマンドは以下でメタデータを変更する。

gcloud compute project-info add-metadata --metadata-from-file ssh-keys=[LIST_PATH]
メタデータ内の SSH 認証鍵の管理  |  Compute Engine ドキュメント  |  Google Cloud

自動スケーリングされるマネージド インスタンス グループの作成

インスタンステンプレートを用いて、マネージドインスタンスグループを作成すると、オートスケーリング機能が利用できる。

自動スケーリングの指標としてStackdriver Monitoringの指標が利用できる点はおさえておく

インスタンス用のカスタム SSH 認証鍵を生成、アップロードする

先述で触れているので割愛

VM で Stackdriver Monitoring と Stackdriver Logging の構成を行う

実際に試してみた。
特筆事項は特に無いかな。

コンピューティングの割り当てを評価し、割り当ての引き上げをリクエストする

GCPのサービスはリソースの割り当て上限が設けられている。
〇〇サービスの秒間リクエストは最大〇〇まで、みたいな。

上限に到達した場合、割り当ての引き上げをリクエストできる。

モニタリングとロギング用に Stackdriver Agent をインストールする

特筆事項はあまりないように思われる。

単一の VM に Cloud Monitoring エージェントをインストールする  |  Google Cloud
単一の VM に Cloud Logging エージェントをインストールする  |  Google Cloud

Monitoring (stackdriver-agent)

$ curl -sSO https://dl.google.com/cloudagents/add-monitoring-agent-repo.sh
$ sudo bash add-monitoring-agent-repo.sh
$ sudo yum list --showduplicates stackdriver-agent
$ sudo yum install -y stackdriver-agent-major-version.*
$ sudo service stackdriver-agent start

Logging (google-fluentd)

$ curl -sSO https://dl.google.com/cloudagents/add-logging-agent-repo.sh
$ sudo bash add-logging-agent-repo.sh
$ sudo yum list --showduplicates google-fluentd
$ sudo yum install -y google-fluentd-major-version.*
$ sudo yum install -y google-fluentd-catch-all-config
$ sudo service google-fluentd restart


Google Kubernetes Engine リソースをデプロイ、実装する

Google Kubernetes Engine クラスタをデプロイする

実際に試してみた。

リージョンの構成は把握しておくこと。

単一ゾーン

マルチゾーン

リージョン

Pod を使用して Google Kubernetes Engine にコンテナ アプリケーションをデプロイする

コンテナのデプロイはワークロードから実施する。
コンテナイメージはあらかじめContainer RegistryかArtifact Registryに登録しておく必要がある。

コマンドでPodをデプロイするときはkubectlを使う。
※ gcloudはGCPリソースとしてのクラスタ操作、kubectlはKubernetes操作

$ kubectl create deployment hello-app --image=gcr.io/${PROJECT_ID}/hello-app:v1

Google Kubernetes Engine アプリケーションのモニタリングとロギングを構成する

ちょい難しいかも。確認しておく。

Logging Using Stackdriver
Before reading this page, it's highly recommended to familiarize yourself with the overview of logging in Kubernetes. Note: By default, Stackdriver logging coll...
GKE ログの表示  |  オペレーション スイート  |  Google Cloud

App Engine、Cloud Run、Cloud Functions をデプロイ、実装する。

特筆する事項としては、App Engineの構成については確認しておく。

機能Standard EditionFlexible Edition
特徴PaaSバックエンドにGCEをかついでおり、
若干IaaSよりで柔軟な対応が可能
起動時間
ローカルディスクへの書き込み×
サードパーティ製品の使用×
料金App Engine時間課金GCEインスタンスの使用量に基づく

アプリケーションをデプロイし、スケーリング構成、バージョン、トラフィック分割を更新する

スケーリング

・AppEngine

インスタンスの管理方法  |  Python 2 の App Engine スタンダード環境  |  Google Cloud

App Engine は自動、基本、手動のオートスケーリングタイプをサポートしている。
指定する際にはアプリをデプロイするさいのyamlファイルで指定する。

・Cloud Run

コンテナ インスタンスの最大数の設定  |  Cloud Run のドキュメント  |  Google Cloud

Cloud Runの場合はサービス作成時に指定することができる。

コマンドでも指定することが可能。

### 既存サービスの更新
gcloud run services update SERVICE --max-instances MAX-VALUE

### 新規デプロイ時の指定
gcloud run deploy --image IMAGE_URL --max-instances MAX-VALUE

########################
# yamlを編集する場合
# 現在の設定を出力
gcloud run services describe SERVICE --format export > service.yaml

# service.yamlの属性を変更
spec:
 template:
   metadata:
     annotations:
       autoscaling.knative.dev/maxScale: 'MAX-INSTANCE' 

# サービスン構成を変更
gcloud beta run services replace service.yaml
バージョニング、トラフィック分割

・App Engine


### アプリケーションのデプロイ
$ gcloud app deploy app.yaml --project sylvan-airship-306401

### バージョンをつけてデプロイ
$ gcloud app deploy app.yaml --project sylvan-airship-306401 \
  --version=version1

初期リリースのバージョンではなく、version1にトラフィック100%で割り振られている。

トラフィックを分割を選択し、割り当て割合を指定するとトラフィックを分散できる。

・Cloud Run

同様に、リビジョンの操作からトラフィックを分割することができる。

バージョンニング、トラフィック分割の用途やメリット

・新規バージョンをリリースする際に、一部テストユーザにのみ新バージョンをリリース
・段階的にユーザ移行を進める
・切り替え、切り戻しが容易

Google Cloud イベントを受け取るアプリケーションをデプロイする

Cloud Pub/Subは実際に試してみた。

データ ソリューションをデプロイ、実装する

プロダクトを使用してデータシステムを初期化する

Cloud SQL

Cloud Datastore

BigQuery

Cloud Spanner

Cloud Pub/Sub

Cloud Bigtable

Cloud Dataproc

Cloud Dataflow

Cloud Storage

データを読み込む

主にCloud Storageのgsutilコマンドをおさえておく必要がある。

バケットの作成

### Bucketの作成 mb - Make buckets
gsutil mb -c standard -l us-east1 -b on gs://my-awesome-bucket/
オプション内容
-cストレージクラスを指定. Default is “Standard”.
-lロケーション
-b均一なバケットレベルのアクセス設定を指定. Default is “off”
従来、「IAM」と「GCSのACL設定」の2つで管理しているところ、
「IAM」の管理のみに一本化するオプション

ファイルのアップロード、ダウンロード

### ローカルファイルのアップロード
gsutil cp *.txt gs://my-bucket

### ローカルへのダウンロード
gsutil cp gs://my-bucket/*.txt .

### フォルダを再帰的にアップロード
gsutil cp -r dir gs://my-bucket

ファイル一覧の表示

### デフォルトプロジェクトのバケットを表示
gsutil ls

### バケットの中のファイルを表示
gsutil ls gs://bucket

バージョニングはバケットに対して設定する必要がある。
また、設定はgsutilコマンドを使ってAPIから実施する。

### バージョニング有効化
gsutil versioning set on gs://BUCKET_NAME

### バージョニング無効化
gsutil versioning set off gs://BUCKET_NAME

### バージョニング設定状況確認
gsutil versioning get gs://BUCKET_NAME

### ファイルの世代情報を確認するにはgsutil ls に -a オプションをつける
gsutil ls -a gs://BUCKET_NAME


ネットワーキング リソースをデプロイ、実装する

サブネットを持つ VPC(例: カスタムモード VPC、共有 VPC)を作成する

基本的な項目なので、特筆事項は無し。
サブネットとVPCがグローバルリソースなのか、リージョンリソースなのかをおさえる。
ネットワークの共有という点で、共有VPCとVPCピアリングの違いをおさえる。

カスタム ネットワーク構成を持つ Compute Engine インスタンスを起動する

特筆事項は特になし。
gcloud compute instances createの際のオプションは確認しておくこと。

内部専用 IP アドレス
静的外部 IP アドレスとプライベート IP アドレス
ネットワーク タグ

gcloud compute instances create  |  Cloud SDK Documentation
cloud compute instances create INSTANCE_NAMES [INSTANCE_NAMES …] \
  --private-network-ip=PRIVATE_NETWORK_IP] \ 
  --address=ADDRESS  | --no-address] 
[--tags=TAG,[TAG,…]]

# Assigns the given RFC1918 IP address to the interface.
--private-network-ip 

# Assigns the given external address to the instance that is created. 
--address=ADDRESS 

# If provided, the instances are not assigned external IP addresses.
--no-address 

限定公開の Google アクセス

限定公開の Google アクセスの構成  |  VPC  |  Google Cloud
gcloud compute networks subnets update SUBNET_NAME \
--region=REGION \
--enable-private-ip-google-access

VPC 用の上り(内向き)および下り(外向き)ファイアウォール ルール

特筆事項は無いので省略。
上りと下り、どちらがどちらなのかをちゃんと覚えておくこと。

Cloud VPN を使用して Google VPC と外部ネットワークとの間の VPN を作成する

Cloud VPN の概要  |  Google Cloud

Cloud InterconnectとCloud VPNの違いを理解し、使い分けを確認しておく。

アプリケーションへのネットワーク トラフィックを分散するロードバランサを作成する

負荷分散の項目で触れたので割愛


Cloud Marketplace を使用してソリューションをデプロイする。

特筆事項は無し。

ミドルウェアやアプリケーションがカスタマイズ済みのOSやサービスを購入できる。

Cloud Deployment Manager を使用してアプリケーション インフラストラクチャをデプロイする

gcloud または API を使用してデプロイを作成する  |  Cloud Deployment Manager のドキュメント
gcloud deployment-manager deployments create my-first-deployment \
    --config vm.yaml

コメント

タイトルとURLをコピーしました