GCP

CLI(Gcloud)
- インストールせずに docker run で使う
- Mac にインストール
- インストール(バージョニングされたアーカイブを利用)
- インストール(パッケージマネージャを利用)
- CLI を利用した自動化
- Tips
Cloud IAM
- ユーザ
- 役割
- サービスアカウント
- IAM ポリシー
- gcloud で IAM 管理
課金
StackDriver Monitoring
StackDriver Logging
Compute Engine (GCE)
Compute Services
- Cloud Function
  - 機能
- AppEngine
GKE: Kubernetes Engine
- gcloud のセットアップ
- Compute Engine (GCE)
Storage
- Cloud SQL
- Persistent Disks
- Cloud Filestore
- Cloud Bigtable
- Cloud Storage
- Cloud Spanner
- Cloud Datastore
- Cloud Firestore
Network
- Virtual Private Cloud (VPC)
- Cloud Load Balancing
- Content Delivery Network (CDN)
Cloud Build
- 使えるイメージ
Cloud Repository
- リポジトリ作成
- クローン
Deployment manager
Cloud Code for IDEs (ALPHA)
GitHub and GitLab integrations (BETA)
Apigee hybrid (BETA)
API security reporting
Cloud RUN (BETA)
CloudFunction
ステージ（GA, BETA...）について

CLI(Gcloud)

GCE のインスタンスはデフォルトで gcloud がインストールされた状態になっている。

インストールせずに docker run で使う

一番環境を汚さない方法。

VERSION='274.0.0'
docker pull google/cloud-sdk:$VERSION

# 認証して認証情報をgcloud-configコンテナに保存する
docker run -ti --name gcloud-config google/cloud-sdk:$VERSION gcloud auth login

そして.bashrcに以下を追記する。

GCLOUD_VERSION='274.0.0'
alias gcloud="docker run --rm -ti --volumes-from gcloud-config google/cloud-sdk:${GCLOUD_VERSION} gcloud"

イメージはここを参照: https://hub.docker.com/r/google/cloud-sdk/

Mac にインストール

~/tools/google-cloud-sdkにインストールする例:

GCLOUD_VERSION=274.0.0
GCLOUD_PATH="${HOME}/tools"

mkdir -p $GCLOUD_PATH
(cd ${GCLOUD_PATH} \
  && curl -O https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-sdk-${GCLOUD_VERSION}-darwin-x86_64.tar.gz?hl=ja \
  && tar -zxvf google-cloud-sdk-${GCLOUD_VERSION}-darwin-x86_64.tar.gz?hl=ja \
  && rm google-cloud-sdk-${GCLOUD_VERSION}-darwin-x86_64.tar.gz?hl=ja \
  && ./google-cloud-sdk/install.sh --quiet)

インストール後に~/tools/google-cloud-sdkを PATH に追加するとgcloudコマンドが使えるようになる。

インストール(バージョニングされたアーカイブを利用)

この方法でインストールするとgcloud components updateなどが使える。

GCLOUD_VERSION=196.0.0
GCLOUD_PATH="${HOME}/tools"

mkdir -p $GCLOUD_PATH
(cd ${GCLOUD_PATH} \
  && curl -O https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-sdk-${GCLOUD_VERSION}-linux-x86_64.tar.gz \
  && tar -zxvf google-cloud-sdk-${GCLOUD_VERSION}-linux-x86_64.tar.gz \
  && rm google-cloud-sdk-${GCLOUD_VERSION}-linux-x86_64.tar.gz \
  && ./google-cloud-sdk/install.sh --quiet \
    ./google-cloud-sdk/bin/gcloud components update --quiet)

Ref: https://cloud.google.com/sdk/downloads#versioned

インストール(パッケージマネージャを利用)

apt-getを使ってインストールするとgcloud components updateなどが利用できなくなるので注意。 Ref:

https://cloud.google.com/sdk/docs/?hl=ja#deb

# 正しく配布されるように、環境変数を作成します。
export CLOUD_SDK_REPO="cloud-sdk-$(lsb_release -c -s)"

# Cloud SDK の配布 URI をパッケージ ソースとして追加します。
echo "deb http://packages.cloud.google.com/apt $CLOUD_SDK_REPO main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list

# Google Cloud の公開鍵をインポートします。
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -

# Cloud SDK を更新してインストールします。
sudo apt-get update && sudo apt-get install google-cloud-sdk

確認系は-qオプションを付けると Yes でスキップできる。 CLI の出力結果をパイプする場合は--formatオプションで出力を固定しておかないと、アップデートで出力内容が変わった時に対応できないので注意。

CLI を利用した自動化

自動化するときには次の点に気をつける

CLI の出力は将来変更されるかもしれないので、--filterや--formatオプションで整形した結果を利用する。

Tips

リソースの URI を取得する

--uriオプションを使う。

gcloud compute instances list --uri
gcloud pubsub topics list --uri

現在有効になっている API を確認する

gcloud services list --enabled

サービスアカウントキーで認証する

gcloud auth activate-service-account --key-file [KEY_FILE]

Ref:
https://cloud.google.com/sdk/docs/authorizing?hl=ja#authorizing_with_a_service_account

現在のプロジェクト ID を取得する

gcloud config list --format 'value(core.project)' 2>/dev/null

Ref:
https://stackoverflow.com/questions/35599414/gcloud-command-line-get-default-project-id

gcloud のアカウントを切り替える

まずconfigurationを作る。

NAME='my-config'
gcloud config configurations create $NAME
gcloud config configurations activate $NAME

# 各種値の設定
gcloud config set compute/region asia-northeast1
gcloud config set compute/zone asia-northeast1-b
gcloud config set core/account <ACCOUNT>
gcloud config set core/project <PROJECT_ID>
gcloud config set core/disable_usage_reporting False

作ったら次のコマンドで切り替えができる。

gcloud config configurations activate <NAME>

Ref: https://qiita.com/sky0621/items/597d4de7ed9ba7e31f6d

現在のアカウントを取得する

gcloud config list account --format "value(core.account)" --verbosity error

Ref:
authentication - How to get the active authenticated gcloud account? - Stack Overflow

現在のプロジェクト ID を取得する

gcloud config list --format 'value(core.project)' 2>/dev/null

Ref: https://stackoverflow.com/a/35606433

Cloud IAM

GCP のリソースに対する権限を管理する。 Cloud IAM は追加料金なしで利用できる。

IAM では 3 つの設定をする。

誰が
どのリソースに対して
何ができるか

組織内の各ユーザが、業務に必要な最小限の権限だけを持つように設定することが大事。

ユーザ

誰がに設定できるものは次のものがある。

Google アカウントまたは Cloud Identity ユーザ
Google グループ
G Suite ドメインまたは Cloud Identity
サービスアカウント: アプリに属するアカウント

他に特殊な設定値として次のものがある。

allAuthenticatedUsers: Google アカウントまたはサービスアカウントで認証されたユーザ全員
allUsers: ネット上の全員

役割

Primitive（基本の役割）

基本の役割では、プロジェクト内の全リソースに対する権限を設定できる。

Viewer（閲覧者）リソースの表示ができるが、リソースの状態を変更することはできない。
Editor（編集者） Viewer の権限に加えて、リソースの状態を変更できる。
Owner（オーナー） Editor の権限に加えて、リソースに対する役割と権限を管理でき、課金の設定もできる。

課金管理アカウントを作る場合は、リソースの変更権限を持たず、課金設定可能なアカウントとして作成するとよい。

Pre defined roles（事前定義された役割）

特定のリソースに対してできる操作の権限を設定できる。例えば、次のような役割を設定できる

ある G Suites チームは、projectA のすべての Compute Engine の管理権限をもつ

Custom roles（カスタムの役割）

カスタムの役割は、組織レベル、プロジェクトレベルでのみ使用できる。フォルダレベルでは使用できない。

より細かい権限管理ができるが、権限を管理するコストが生まれるため、カスタムの役割は使うかどうかをよく考えること。

サービスアカウント

ユーザではなく、特定の Compute Engine に権限を与えたい場合などに利用する。例えば、アプリが Cloud Storage にデータを保存する場合に、インターネット上のユーザからはデータを読み取れないようにし、データにアクセスできるのはアプリからのみとしたい場合など。

サービスアカウントのアカウント名、パスワードは次のようになる。

アカウント名 = メールアドレス
パスワード = 暗号鍵

IAM ポリシー

Cloud IAM は「Cloud IAM ポリシー」を作成してユーザに役割を付与できる。ポリシーは、組織レベル、プロジェクトレベル、リソースレベルで設定できる。上の階層で設定したポリシーは、下の階層に引き継ぐ。

下位のポリシーが優先されるため、例えば次の場合、該当ユーザはバケットの書き込み権限を得るようになる。

組織ポリシーでバケットの読み取りのみを許可
プロジェクトポリシーでバケットの読み書きを許可

組織
  - プロジェクトA
    Compute Engine
    App Engine
    ...
  - プロジェクトB
    Cloud Pub/Sub
    Cloud Storage
    ...
  ...

権限付与には次の方法がある。

GCP の GUI
Google IAM API を使用したアプリ
gcloud(CLI)

また、フォルダを作り複数のプロジェクトをまとめることもできる。

組織
  - フォルダA
    - プロジェクトA
    - プロジェクトB
  - フォルダB
    - プロジェクトC
    - プロジェクトD

フォルダを作る場合は組織が必須で、組織を作るためには G Suite Domain が必要。 G Suite Domain がある場合は自動的に組織が作られる。 G Suite Domain がない場合は Google Cloud ID を使うと組織が作成できる。

::: info 組織を作ったあとは、まず次をやっておくのがおすすめ。

プロジェクトや課金アカウントを作成できる人を限定する :::

gcloud で IAM 管理

ロールの表示:

gcloud projects get-iam-policy <PROJECT_ID>

# ユーザに対するRoleのみ表示
gcloud projects get-iam-policy <PROJECT_ID> \
  --flatten="bindings[].members" \
  --filter="bindings.members:user:" \
  --format='table(bindings.members,bindings.role)'

ロールの付与:

gcloud projects add-iam-policy-binding <PROJECT_ID> \
  --member user:<USER_NAME> \
  --role <ROLE>

# ex
gcloud projects add-iam-policy-binding my-project \
  --member user:test-user@gmail.com \
  --role roles/viewer

USER_NAMEは gmail アドレスなどを、ROLEはロールの名前（roles/viewerなど）を指定する。

指定できるロールの一覧はココを参照: https://cloud.google.com/iam/docs/understanding-roles

ロールの削除:

gcloud projects remove-iam-policy-binding <PROJECT_ID> \
  --member user:<USER_NAME> \
  --role <ROLE>

# ex
gcloud projects remove-iam-policy-binding my-project \
  --member user:test-user@gmail.com \
  --role roles/viewer

add-iam-policy-bindingがremove-iam-policy-bindingに変わっただけ。

課金

料金計算ツール: https://cloud.google.com/products/calculator/?hl=ja

StackDriver Monitoring

エージェントのインストール:

curl -sSO https://dl.google.com/cloudagents/install-monitoring-agent.sh
sudo bash install-monitoring-agent.sh

StackDriver Logging

エージェントのインストール:

curl -sSO https://dl.google.com/cloudagents/install-logging-agent.sh
sudo bash install-logging-agent.sh --structured

gcloud でログ送信

# テキスト
gcloud logging write my-test-log "A simple entry."

# json
gcloud logging write --payload-type=json my-test-log '{ "message": "My second entry", "weather": "partly cloudy"}'

ログはここから確認できる。 https://console.cloud.google.com/logs?hl=ja

gcloud でログ取得

# リソースタイプがglobalなログを取得
gcloud logging read "resource.type=global"

# フォーマットして表示
gcloud logging read "resource.type=global" \
  --format='table(timestamp,textPayload,jsonPayload)'

Compute Engine (GCE)

gcloud init --console-only

東京リージョンにするときは以下のいずれかを選択する。

[32] asia-northeast1-b
[33] asia-northeast1-c
[34] asia-northeast1-a

Ref: リージョンとゾーン

コマンドのヘルプは以下のように取得できる。

gcloud compute --help
gcloud compute instances --help
gcloud compute instances create --help

--helpの代わりに-hを使うとクイックヘルプを取得できる。

Compute Services

Cloud Function

サーバーレスコンピューティングのサービス。制限が多いけど、それが問題なければ簡単にアプリをデプロイできる。

チャットボット、リアクティブ API、ストリーム処理、

機能

Cloud Source Repository を介したバージョン管理、デプロイ
Funcitons エミューレータを介したローカルテスト
StackDriver との連携
Functions のライフサイクル管理に役立つツールがある
HTTP、 Cloud Pub/Sub、Cloud Storage、Firebase（データベース分析のような）、Pub/Sub 経由で Stackdriver のロギング

pros:

ホスト PC についてまったく考える必要がない。ソースを書いてデプロイするだけですべての面倒をみてくれる。

cons:

対応言語が少ない(node, python)
通常とは異なる考え方でアプリ設計をする必要がある

AppEngine

Cloud Function と同様に PaaS であるが、より一般的なランタイムとして機能し、Web アプリケーションに特に適している。 Cloud Function のように言語の制約はあるが、Node、Java、Ruby、C#、Go、Python、PHP など、選択肢は多い。また、App Engine Flexible と呼ばれるオプションを利用することで、App Engine の標準環境で提供される機能をいくつかあきらめる代わりに好きな言語環境で開発ができる。

ライフサイクル管理機能
バージョン管理
スケーリング
異なるバージョンのアプリ間でのトラフィック分割

AppEngine には 2 つの環境がある

スタンダード環境
フレキシブル環境

スタンダート環境

Google が提供するランタイムを使ってアプリを実行する。利用できるランタイムは次のものがある。

Java
Python
PHP
Go

スタンダード環境を利用するメリット

少ない利用であれば無料で利用できる。

スタンダード環境ではサンドボックス環境でアプリを実行するため、コードにいくつかの制限がある。

ローカルファイルの書き込み禁止
60 秒でリクエストがタイムアウトする。
サードパーティーソフトウェアを入れられない

多くのアプリはスタンダード環境のランタイムとライブラリがあれば十分。

フレキシブル環境

スタンダード環境はサンドボックス環境でアプリが実行されるのに対し、フレキシブル環境では任意のコンテナを指定してアプリを実行できる。

スタンダード環境とフレキシブル環境の比較

	スタンダード環境	フレキシブル環境
起動時間	早い	遅い
SSH アクセス	×	〇
ローカルファイルの書き込み	×	〇
サードパーティ製バイナリ	×	〇
ネットワークアクセス	App Engine サービス経由	〇
課金方式	無料枠あり、アイドル状態になると自動シャットダウンする	時間単位の課金。自動シャットダウンなし

GKE: Kubernetes Engine

IaaS と PaaS の間のような存在。コンテナ用のホスト型オーケストレーションシステム。Docker と Rocket 両方のイメージをサポートしている。クラスタのテンプレートが用意されている。 Google が用意したコンテナイメージレジストリを利用できる。コンテナイメージの脆弱性スキャンもサポートされている。 Cloud Build を利用することでコンテナイメージの CI デプロイもできる。

Cloud Function や App Engine と違い、Kubernetes Engine ではコード以外にもある程度の知識が必要になる。ただし、それはコンテナの基礎やそれに関連する Kubernetes の範囲で十分。

Google は証明書管理、内部 DNS、クラスタ状態管理などの Kubernetes の詳細に関連するものを管理してくれる。

gcloud のセットアップ

gcloud components install kubectl

gcloud components install kubectl

export PROJECT_ID="$(gcloud config get-value project -q)"

# イメージのビルド
docker build -t gcr.io/${PROJECT_ID}/<image name>:v1 .
# イメージのプッシュ
gcloud docker -- push gcr.io/${PROJECT_ID}/<image name>:v1

# クラスタの作成
gcloud container clusters create <cluster name> --num-nodes=3

# python2.7を入れる
sudo apt install python

Ref: https://cloud.google.com/kubernetes-engine/docs/tutorials/hello-app?hl=ja

Compute Engine (GCE)

インフラの構築知識

事前定義済みまたは（CPU コア数やメモリ容量などの）カスタムのマシン構成を選択したり、イメージ移行サービスを使用して既存のイメージをインポートできる。

プリエンプティブ仮想マシン： 24 時間しか連続で起動できない。他のコンピューティングリソースが必要になると Google によってシャットダウンされる。

1 つ以上のストレージディスクを VM に接続することができる。ストレージオプションでは利用可能な構成がいくつかある。ネットワークやセキュリティも同様。

インスタンスのテンプレートを使用して好きな数のインスタンスを生成することもできる。インスタンスグループを使用すると CPU やメモリの使用率、Stackdriver メトリクスなどの尺度に基づいてインスタンスをプロビジョニングしたりプロビジョニング解除するように自動スケーリングルールを設定できる。

インスタンスグループを利用すると、VM インスタンスの数を一定に保つように指定できるようになるなど、可用性も上がる。

Storage

GCP にはさまざまなデータシナリオに対応するためのさまざまなオプションが用意されている。

保存するデータの形式
保存したデータで何をするか

Cloud SQL

マネージドな MySQL または Postgres のサービス。リレーショナルデータベースが使いたい場合は選択肢にあがる。

Computed Engine 上で動いているため、継続割引などのすべてのメリットが得られる。マシンの種類、ストレージの構成、スケーリング、レプリカのプロビジョニング、バックアップやサーバへのパッチ適用方法の指定まで、さまざまなコントロールを提供する。

Persistent Disks

USB ドライブのようなクラウド。仮想マシンに接続したり、切り離したりして使うことができる。これにより、VM がクラッシュしたとしても永続データは失われなくなる。単一のディスクを複数の仮想マシンに接続することもできるが、その場合はデータ破損を避けるためにすべての仮想マシンで読み取り専用としてディスクをマウントする必要がある。ディスクの種類、サイズ、ディスクを使用可能にする地域やゾーン、データの暗号化などの設定ができる。ディスクの種類は場合によってはパフォーマンスに桁違いの差がでるため重要。サイズはいつでも変更できる。

Cloud Filestore

ネットワーク接続ストレージ。複数の仮想マシンや、Kubernetes コンテナで共有ファイルが必要とされる場合に役立つ。低レイテンシで、さらに重要なことにメンテナンスが少ない。

Cloud Bigtable

ペタバイト規模の高性能アクセスとデータ保存を提供する。Gmail のような Google アプリがこれを利用している。

低レイテンシで読み取り書き込みで高いスループットのある非常に大きなデータセットを作成するのに向いている。

使用するノード数やディスクの種類などは制御できるけど、レプリケーションやサイズ変更など、Bigtable の基盤となるインフラと運用の詳細部分は抽象カされている。

データのやり取りには API を使用する。クライアントライブラリは C++、C#、Go、Java、Node、Python など、さまざまな言語に対応している。シェルスクリプト用のコマンドラインインタフェースもある。

Bigtable には以下の特徴がある

テーブルにはインデックス付き列が 1 つしかなく、これを行キーと呼ぶ。テーブルはこのキーでソートされている。
複数行に対する操作ではトランザクション上の保証はない。

これらの特徴が Bigtable 用にデータをモデル化する方法に大きな影響を与える。例えば、異なる種類のエンティティがすべて同じテーブルの 1 つの行に保持される。関連する列は列ファミリと呼ばれる概念によってグループ化されているため、行キーでソートしたときに関連するエンティティがお互いに近くに配置されるように行キーのスキーマを考える必要がある。

そのため、Bigtable では空の列がたくさんある行で構成されるテーブルが作成されることがある。

Cloud Storage

BLOB ストレージサービス。AWS の S3 に似ている。クラウドのストレージで最も一般的に考えられるサービス。

保存したデータは自動的にエッジキャッシュされる。

料金は、ストレージのコストとデータアクセスのコストの両方に基づく。

コールドラインはストレージのコストは安くなるが、ネットワークアクセスコストはリージョナルやマルチリージョナルストレージよりも高くなる可能性がある。

ライフライクル管理機能があり、間違って変更したり削除するのを防ぐためにオブジェクトをバージョン管理したり、有効期限などの基準に基づいてオブジェクトを削除するルールを設定したり、ストレージクラス間でデータを自動的に移行することができる。

Pub/Sub 通知や、Cloud Function トリガーを介して他のサービスに統合できる。

オブジェクトストレージクラス

ストレージクラスは 4 種類ある。

Multi-Regional: 複数リージョンで冗長化される。世界中から頻繁にアクセスするデータに使用する。
Regional: 単一リージョンに保存。複数のアベイラビリティゾーンで冗長化される。特定の地域で頻繁にアクセスするデータに使用する。
Nearline: 保存コストが安く、オペレーションコストが高め。月 1 程度のアクセスで、バックアップなどに最適。最小保存期間が 30 日。
Coldline: 保存コストが最も安く、オペレーションコストも高い。年 1 程度アクセスするデータのアーカイブとして使用する。最小保存期間は 90 日。

バケット作成後でもストレージクラスは変更できる。ただし、以下のことはできない

マルチリージョナルからリージョナルへ変更。またはその逆。

gsutil defstorageclass set <ストレージクラス> gs://<クラウドストレージ名>
# gsutil defstorageclass set nearline gs://my-storage

# ストレージ内にある既存のオブジェクトにもストレージクラスの変更を反映させる
gsutil rewrite -s nearline -s nearline gs://my-storage/hoge.txt

メタデータ

すべてのオブジェクトには Key-Value のメタデータが存在する。カスタムメタデータは好きに追加できる。

バージョン管理

バージョン管理化のオブジェクトは、オブジェクトを更新した場合と、オブジェクトのメタデータを更新した場合にインクリメントされる以下のメタデータが付与される。

generation number
meta generation number

バージョニングを有効にするには、以下のコマンドを実行する。

# バージョニングを有効にする
gsutil versioning set on gs://<パス>

# 確認
# 有効になっている場合はEnable、そうでない場合はSuspendedが返る
gsutil versioning get gs://<パス>

# バージョニングを無効にする
gsutil versioning set on gs://<パス>

# バージョニングされている履歴オブジェクトも含めて表示する
# バージョニングを無効にした場合でも、それまでに保存されたバージョンは表示できる
gsutil ls -a gs://<パス>

# 指定したバージョンのオブジェクトをローカルにコピー
gsutil cp "gs:<パス> gs://<パス>#<世代番号> <ローカルパス>"

# 指定したバージョンのオブジェクトを削除
# バージョニングを無効にした場合はこのように明示的に古いバージョンを削除しないとファイルは永久に残り続ける
gsutil rm "gs://<パス>#<世代番号>"

バージョニングが有効になっているバケットにファイルを追加した場合は以下のようにして世代番号を取得できる。

gsutil ls -L gs://<パス>
# 以下の値を確認
# - Generation
# - Metageneration

バージョニングが有効な場合、オブジェクトを更新した場合は Generation が、メタデータを更新した場合は Metageneration が+される。

ストレージクラス変更後は既存のオブジェクトは以前の状態を保持し、新規追加されたオブジェクトのみ変更後のストレージクラスが適用される。

ライフサイクル管理

バックアップのアーカイブや、オブジェクトの削除を自動化できる。バージョニングしたデータが不必要に蓄積されるのを防げる。ライフサイクル管理ではルールとアクションを定義する。

条件を指定してオブジェクトのストレージクラスを自動的に変更する。これにより、アクセス頻度が減った古いデータなどをアーカイブし、課金額を節約できる。
- ex: 7 日後に Regional から Multi-Regional に変更する
- ex: 特定の日付より前に作成されたデータを削除する

Cloud Storage ではさまざまなルールが用意されている。

オブジェクトが特定の日時より前に作成されたか
オブジェクトがライブバージョンかアーカイブバージョンか
オブジェクトのストレージクラスが特定のタイプに設定されているかなど

サポートされるアクションには以下のようなものがある。

Delete
SetStorageClass

ライフサイクル管理のルールは、1 つ以上の条件と 1 つのアクションによって構成される。複数の条件がある場合は、AND 条件でアクションが実行される。逆に、複数のルールで同じアクションが実行されるよう構成すれば OR 条件となる。

ライフサイクルの追加は有効になるまで最大 24 時間かかるため、すぐにはルールの効果が反映されない。

コマンドラインから設定する場合は、ライフサイクルを定義した json ファイルを使う。この例では、リージョナルまたは標準のストレージクラスである 365 日以上古いすべてのオブジェクトが Nearline に変更されるルールを定義している。 my-lifecycle.json

{
  "lifecycle": {
    "rule": [
      {
        "action": {
          "type: "SetStorageClass",
          "storageClass": "NEARLINE"
        },
        "condition": {
          "age": 365,
          "matchesStorageClass": ["REGIONAL", "STANDARD"]
        }
      }
    ]
  }
}

gsutil lifecycle setでライフサイクルを適用する。

# パスはたいていバケット名になるはず
# jsonファイルが空オブジェクト`{}`の場合はライフサイクルの削除になる
gsutil lifecycle set my-lifecycle.json gs:<パス>

アクセス制御

バケットのアクセス管理ポリシーは、プロジェクトレベルまたはバケットレベルで設定できる。

ACL ベースのアクセス制御も使えるが、通常はバケット内の特定のオブジェクトのアクセスを制限したい場合にのみ使用する。

gsutil aclで、オブジェクトのアクセス権限を設定できる。

# すべてのユーザに指定したパスの読み取り権限を付与
# -u <user>: アクセス権限を設定するユーザを指定する。AllUsersはすべてのユーザを表す特別な文字列
gsutil acl -r ch -u AllUsers:R gs://<パス>

# 世界中すべてのユーザにObjectViewer権限を付与
gsutil iam ch allUsers:objectViewer gs://<パス>

バケットごと公開設定にした場合は、追加されるオブジェクトは自動的に公開設定になる。

IAM ではユーザにはロールが割り当てられ、権限はロールに対して与えられる。 ACL ベースのアクセス制御では、ユーザに直接権限を与える。

複数のユーザとアプリがある場合はロールベースのアクセス制御の方がかなり簡単。

暗号化

署名付き URL

時間制限付きアクセスを設定できる。

ストレージバケット

Blob ストレージとして利用することで画像ファイル

ローカルファイル ⇔Cloud Storage ファイルのやり取り

# ローカルファイルをクラウドにコピー
gsutil cp <local file> gs:<cloud file>

Cloud Spanner

フルマネージドなリレーショナルデータベース。リレーショナルデータベースを利用したい場合に最適。グローバルに分散されるにもかかわらず強力なトランザクション保証を提供する。 Bigtable でできなかったトランザクション保証を実現するために作られた。 Google のサービスは Bigtable から Cloud Spanner に移行している。

Cloud Datastore

App Engine のために作られた。スキーマレスで、ドキュメント DB のようなもの。エンティティグループ内でトランザクション保証をサポートする。クエリのパフォーマンスはクエリ対象のデータ量ではなく、結果セットのサイズに比例して変化する。

Cloud Firestore

Cloud Datastore の後継。リアルタイム同期をサポートする。オフラインサポートがある。

エンティティはドキュメントに、エンティティグループはコレクションとして扱う。データベース全体にわたるトランザクション保証がある。

Network

Virtual Private Cloud (VPC)

プライベートネットワークスペースを定義したり、サブネット、ルートなどを構成できる。

Cloud Load Balancing

ロードバランシングされた単一の IP アドレスを取得できる。

Content Delivery Network (CDN)

Google のネットワークのアクセス範囲をピアリングエッジを超えて広げることができる。これは Cloud Storage などのストレージオプションを使用するときにデフォルトで得られる。

Cloud Build

使えるイメージ

https://cloud.google.com/cloud-build/docs/cloud-builders?hl=ja

Cloud Repository

リポジトリ作成

gcloud source repos create [repo-name]

クローン

remote にリポジトリの URL が設定されるのでそのまま commit&push できる。

gcloud source repos clone [repo-name]

Deployment manager

.yamlまたは.pyで構成ファイルを書ける。 Cloud Source Repository でバージョン管理できる。

Cloud Code for IDEs (ALPHA)

VSCode、InteliJ 用のビルド、デプロイ、デバッグのための拡張機能。

GitHub and GitLab integrations (BETA)

Apigee hybrid (BETA)

API の管理

API security reporting

API の脆弱性を検出する。

Cloud RUN (BETA)

コンテナデプロイなサーバーレスプラットフォーム。 Knative ベースで動くためベンダーロックインがない。

CloudFunction

Functions Framewark

ステージ（GA, BETA...）について

https://cloud.google.com/products/#product-launch-stages

← GCP: VPC Network

# GCP

# CLI(Gcloud)

# インストールせずに docker run で使う

# Mac にインストール

# インストール(バージョニングされたアーカイブを利用)

# インストール(パッケージマネージャを利用)

# CLI を利用した自動化

# Tips

# リソースの URI を取得する

# 現在有効になっている API を確認する

# サービスアカウントキーで認証する

# 現在のプロジェクト ID を取得する

# gcloud のアカウントを切り替える

# 現在のアカウントを取得する

# 現在のプロジェクト ID を取得する

# Cloud IAM

# ユーザ

# 役割

# Primitive（基本の役割）

# Pre defined roles（事前定義された役割）

# Custom roles（カスタムの役割）

# サービスアカウント

# IAM ポリシー

# gcloud で IAM 管理

# 課金

# StackDriver Monitoring

# StackDriver Logging

# Compute Engine (GCE)

# Compute Services

# Cloud Function

# 機能

# AppEngine

# スタンダート環境

# フレキシブル環境

# スタンダード環境とフレキシブル環境の比較

# GKE: Kubernetes Engine

# gcloud のセットアップ

# Compute Engine (GCE)

# Storage

# Cloud SQL

# Persistent Disks

# Cloud Filestore

# Cloud Bigtable

# Cloud Storage

# オブジェクトストレージクラス

# メタデータ

# バージョン管理

# ライフサイクル管理

# アクセス制御

# 暗号化

# 署名付き URL

# ストレージバケット

# ローカルファイル ⇔Cloud Storage ファイルのやり取り

# Cloud Spanner

# Cloud Datastore

# Cloud Firestore

# Network

# Virtual Private Cloud (VPC)

# Cloud Load Balancing

# Content Delivery Network (CDN)

# Cloud Build

# 使えるイメージ

# Cloud Repository

# リポジトリ作成

# クローン

# Deployment manager

# Cloud Code for IDEs (ALPHA)

# GitHub and GitLab integrations (BETA)

# Apigee hybrid (BETA)

# API security reporting

# Cloud RUN (BETA)

# CloudFunction

# ステージ（GA, BETA...）について

GCP

CLI(Gcloud)

インストールせずに docker run で使う

Mac にインストール

インストール(バージョニングされたアーカイブを利用)

インストール(パッケージマネージャを利用)

CLI を利用した自動化

Tips

リソースの URI を取得する

現在有効になっている API を確認する

サービスアカウントキーで認証する

現在のプロジェクト ID を取得する

gcloud のアカウントを切り替える

現在のアカウントを取得する

現在のプロジェクト ID を取得する

Cloud IAM

ユーザ

役割

Primitive（基本の役割）

Pre defined roles（事前定義された役割）

Custom roles（カスタムの役割）

サービスアカウント

IAM ポリシー

gcloud で IAM 管理

課金

StackDriver Monitoring

StackDriver Logging

Compute Engine (GCE)

Compute Services

Cloud Function

機能

AppEngine

スタンダート環境

フレキシブル環境

スタンダード環境とフレキシブル環境の比較

GKE: Kubernetes Engine

gcloud のセットアップ

Compute Engine (GCE)

Storage

Cloud SQL

Persistent Disks

Cloud Filestore

Cloud Bigtable

Cloud Storage

オブジェクトストレージクラス

メタデータ

バージョン管理

ライフサイクル管理

アクセス制御

暗号化

署名付き URL

ストレージバケット

ローカルファイル ⇔Cloud Storage ファイルのやり取り

Cloud Spanner

Cloud Datastore

Cloud Firestore

Network

Virtual Private Cloud (VPC)

Cloud Load Balancing

Content Delivery Network (CDN)

Cloud Build

使えるイメージ

Cloud Repository

リポジトリ作成

クローン

Deployment manager

Cloud Code for IDEs (ALPHA)

GitHub and GitLab integrations (BETA)

Apigee hybrid (BETA)

API security reporting

Cloud RUN (BETA)

CloudFunction

ステージ（GA, BETA...）について