ラベル Google Cloud Platform の投稿を表示しています。すべての投稿を表示

2026年2月11日水曜日

GAE 用のバケットやサービスアカウントを削除して deploy できなくなった場合の対処方法

概要
環境
コマンド
最後に
参考サイト

概要

間違って GAE 用のバケットやサービスアカウントを削除してしまった素直に repair しましょう

環境

gcloud 545.0.0

コマンド

gcloud beta app repair

最後に

ドメイン入りのバケットは手動では作成できません

参考サイト

https://docs.cloud.google.com/appengine/docs/admin-api/reference/rest/v1/apps/repair

2026年2月6日金曜日

GCP のクラウドストレージに上書きアップロードしてもオブジェクトが変更されない場合の対応方法

概要
環境
ブラウザのキャッシュを削除する
クエリ付きでアクセスする
Cache-Control を確認し短くする
別のファイル名にする
ダメだったケース
最後に

概要

おそらくキャッシュされているのが問題です
特に発生しやすいのが「同じような画像を上書きアップロードした場合」で例えば元の画像を90度回転させた画像などは上書きアップロードしても反映されないことが多いです

そんな場合の反映方法を紹介します

環境

GCP 2026/02/04 時点

ブラウザのキャッシュを削除する

とりあえず削除して再度アクセスしてみましょう

クエリ付きでアクセスする

クラウドストレージ側でキャッシュしている可能性があるのでクエリ付きでアクセスしましょう

https://storage.googleapis.com/your_bucket_name/file.jpg?nocache=1

Cache-Control を確認し短くする

curl -I https://storage.googleapis.com/your_bucket_name/file.jpg

これで「Cache-Control:」「Age:」「X-Cache:」があればクラウドストレージ側のキャッシュが有効になっています

gsutil setmeta -h "Cache-Control:public,max-age=60" gs://your_bucket_name/file.jpg

60秒など短い時間にしましょう
0 だと毎回クラウドストレージにアクセスしネットワーク量が多くなり金額上がるので注意しましょう

別のファイル名にする

これが一番カンタンです
がアプリ側の改修などが必要になるケースがあるので注意しましょう

よくあるパターンはファイル名にハッシュなどを含めるケースです

ダメだったケース

削除 -> 再度アップロード
- なぜか元の画像がクラウドストレージ側でも利用されてしまう
実はファイルが回転できていない
- exif の Orientation にまだデータが残っている
- ビューアの見た目だけが回転している

最後に

まずはキャッシュを疑いましょう

2025年11月21日金曜日

概要

コンソールでの手順を紹介します

環境

GCP (2025/11/21 時点)

手順

Compute Engine のページを開く
「VM インスタンス」を選択
監視したい VM を選択
「オブザーバビリティ」を選択
右上にある「推奨アラート」を選択
VM Instance - High CPU Utilization (web) を選択 -> 作成
「通知チャンネルを使用」で通知したいチャネルを選択 -> 作成

確認

モニタリングにアラートポリシーがあることを確認しましょう

最後に

GCP の VM で CPU 監視する方法を紹介しました
コンソール作業なので UI が変わった場合は手順が変わるので注意してください

しきい値を変えたい場合はポリシーを直接変更すれば OK です

Slack の通知チャネルを作成する方法は以下の参考リンクを参照してください

参考サイト

https://docs.cloud.google.com/monitoring/support/notification-options?hl=ja

2025年11月3日月曜日

GCP の Ops エージェントを完全にアンインストールする方法

概要
環境
まずは purge
設定ファイルの削除
VM のカスタムメタデータの削除
VM のラベルの削除
デフォルト
動作確認
最後に

概要

コンソールから Ops エージェントをインストールするとなぜかアンインストールしても勝手に再インストールしてしまうので完全にアンインストールする方法を紹介します

環境

Ops エージェント 2.60.0
Ubuntu 22.04

まずは purge

sudo apt purge google-cloud-ops-agent

設定ファイルの削除

purge した場合は基本ないはずですが一応確認します

sudo ./add-google-cloud-ops-agent-repo.sh --remove-repo
sudo rm /etc/apt/sources.list.d/google-cloud-monitoring.list

/opt 配下にも何も無いことを確認します

VM のカスタムメタデータの削除

これがあるとエージェントが勝手に再インストールしている可能性があるので削除します
コンソールでも OK です

gcloud compute instances remove-metadata YOUR_INSTANCE_NAME --zone=YOUR_ZONE --keys=enable-osconfig

VM のラベルの削除

VM インスタンス -> 選択 -> 編集 -> ラベルを管理 -> goog-ops-agent-policy のラベルを削除

デフォルト

以下のエージェントだけになっていればデフォルトの状態です

dpkg -l | grep google
ii  google-compute-engine            20230808.00-0ubuntu1~22.04.1            all          Google Compute Engine guest environment.
ii  google-compute-engine-oslogin    20231004.00-0ubuntu1~22.04.3            amd64        Google Compute Engine OS Login
ii  google-guest-agent               20231004.02-0ubuntu1~22.04.5            amd64        Google Compute Engine Guest Agent
ii  google-osconfig-agent            20240524.03-0ubuntu2~22.04.1            amd64        Google OS Config Agent

動作確認

最終的にはコンソールでオブザーバビリティを確認したい際に「Opsエージェントをインストール」が表示されていれば完全に削除できています
インストール中の保留中やメトリクスが送信できないような文言の場合はまだタグやラベルが残っている可能性があります

最後に

GCP の小さめのインスタンスに Ops エージェントをインストールすると CPU とメモリを食い尽くして他のプロセスが全く動かなくなるので安易にインストールするのはやめておきましょう

2025年7月7日月曜日

google.auth.exceptions.RefreshError の対処方法

概要
環境
アプリがテストの場合はリフレッシュトークンが7日になる
解決方法の一番はアプリを公開すること
もしアプリを公開できない場合は OAuth クライアントのシークレットを更新しなければならない
認証後のトークンの期限は変更できない？
最後に

概要

エラー全文は以下です

google.auth.exceptions.RefreshError: ('invalid_grant: Token has been expired or revoked.', {'error': 'invalid_grant', 'error_description': 'Token has been expired or revoked.'})

環境

GCP (2025/07/05 時点)

アプリがテストの場合はリフレッシュトークンが7日になる

らしいです

解決方法の一番はアプリを公開すること

基本は自分で使うだけなら公開しても問題ないです
スコープやアプリの細かい設定が必要な場合は公開するアプリの審査が必要になるかもです
なので可能な限りアプリの設定はシンプルにしましょう (許可ドメインとコールバックURLくらい)

もしアプリを公開できない場合は OAuth クライアントのシークレットを更新しなければならない

しかもシークレットは無効 -> 削除 -> 新規作成が推奨されているので面倒です
しかもアプリがテストの場合はリフレッシュトークンが7日なので再度シークレットを作成し直す必要があります

認証後のトークンの期限は変更できない？

API ならできるのかもしれません
少なくともコンソールからトークンの期限を変更することはできませんでした

最後に

できればアプリは公開状態にしましょう

2025年6月5日木曜日

Gitlab で reCAPTCHA を使ってみる

概要
環境
reCAPTCHA の登録
Gitlab 側の設定
動作確認
gitlab.rb の編集
ロックアウトされた場合は
最後に
参考サイト

概要

Gitlab と reCAPTCHA v2 を連携しログイン時にロボット化どうかを判定するチェックを導入してみました
v3 にはまだ対応していないので v2 を使いましょう

環境

reCAPTCHA v2
Gitlab 17.9.3

reCAPTCHA の登録

Gitlab は reCAPTCHA v3 をまだサポートしていないんどえ v2 のキーを取得しましょう

ここから申し込みます
GCP のプロダクトと紐づける必要があります
ドメインには Gitlab の URL を指定しましょう

サイトキーとシークレットキーが発行されるのでメモしておきます
また GCP 側のプロジェクトにも紐づいているのでそちらでも reCAPTCHA の情報を確認できます

Gitlab 側の設定

Admin ユーザでログイン
左下の Admin ボタンをクリック
左メニュー Settings -> Reporting
Spam and Anti-bot Protection
- Enable reCAPTCHA -> ON
- Enable reCAPTCHA for login. -> ON
- reCAPTCHA site key -> 先ほど取得したサイトキーを入力
- reCAPTCHA private key -> 先ほど取得したシークレットキーを入力
Save Change

動作確認

Gitlab にアクセスしてログインページで reCAPTCHA が表示されることを確認します
表示されない場合は以下を試してください

ブラウザのシークレットモードでアクセスする
パスワードを何回か間違えて表示されることを確認
ブラウザのキャッシュをクリアする
異なる IP の環境からアクセスする

一度信頼されている環境だと reCAPTCHA は表示されないので注意してください GCP 上の reCAPTCHA でも保護がカウントされていることが確認できます

gitlab.rb の編集

これはいらないかもです
一応入れておくと安心です
Omnibus Gitlab であれば docker-compose.yml などに記載しましょう

vim /etc/gitlab/gitlab.rb

nginx['proxy_set_headers'] = { 'X-GitLab-Show-Login-Captcha' => '1' }

ロックアウトされた場合は

DB に直接触れたり Admin 権限のあるアクトークンがあるのであれば API から reCAPTCHA を一時的に無効にすることも可能です

curl --request PUT --header \
"PRIVATE-TOKEN: <PersonalAccessToken>" \
"https://gitlab.example.com/api/v4/application/settings?recaptcha_private_key=<SecretKey>&recaptcha_site_key=<SiteKey>"

最後に

Gitlab と reCAPTCHA を連携してみました
テストする場合はロックアウトされる可能性もあるのでログイン状態を保持したブラウザを用意しておくことをおすすめします

参考サイト

2025年3月7日金曜日

Google Cloud Associate Cloud Engineer 合格メモ

概要
環境
料金
対策
- 教科書
- 模擬試験
試験範囲
解き方のポイント
実際に出題された問題の記憶
スコアレポートはでない
暫定合格を確認する方法もない
合否通知はいつくるか
最後に

概要

勉強方法などを紹介しておきます
基本は過去ゲーです

環境

GCP ACE (2025/01/27時点)
テストセンターにて受験

料金

137ドル (19702円)

対策

基本的には教科書と過去問です
ただ教科書だけでは合格するのはほぼ不可能だと思います (実務経験がかなりあれば別かも)

過去問を完璧にこなせば基本的には大丈夫かなと思います
教科書にも模擬試験的なのがあるのでお守り程度に持っておくといいかなと思います
過去問の問題も実際の試験で30-50%ほど出題された気がします (もう少しあったかも)
なお問題はすべて選択式で4択から1つ選択するだけでした
複数回答を求める問題は出題されませんでした

教科書

(模擬問題付き)徹底攻略 Google Cloud認定資格 Associate Cloud Engineer教科書

模擬試験

Udemy で 400 問ほど解きました
すべて有料なのでご注意ください
むしろ有料以外の模擬試験はほぼなくあっても微妙な問題集しかなかったです

試験範囲

一応確認しておくといいかもです

https://services.google.com/fh/files/misc/associate_cloud_engineer_exam_guide_japanese.pdf

解き方のポイント

回答から問題が何関するものなのか先に推測する
- 問題はダラダラ長いが最終的に聞きたいことはただの権限の問題だったりする
消去法
- 知らない問題でもあり得ない回答がわかればそこから2択などに絞り込む
「実務ではこうする」の考えは完全に消したほうがいい
- その方法じゃなくてもできるんだけどなー
- そっちのほうが実際は面倒なんだよなー
- と言った実務経験は完全にすてたほうがいいです
- Google Cloud 推奨およびベストプラクティスを探す問題がほとんどなので注意しましょう
- 実務経験が長い人ほど陥りやすいかもです
定番の問題はおさえる
- クラウドストレージのライフサイクル
- ロールの最小原則とグループ割り当て
- VPC のサブネット内の CIDR の扱い

実際に出題された問題の記憶

過去問(および過去問に似た問題)が30-50%ほど出題された
全く勉強していなかった部分はほぼなかった
- UDP + ネットワークロードバランサは知らなかったが消去法で対処した
クラウドストレージに Cloud Interconnect 経由で接続する方法
- 内部の DNS に CNAME 貼るやつ
サブネットの CIDR の IP レンジ拡張
- ネットワーク部分の数字を減らして拡張するので間違えそう
日本語がおかしい
- Coldline -> コールドストレージ
- それ以外にも問題文章自体の翻訳がおかしい部分が多々ある
時間はかなりあまる
- 自分は60分で終了

スコアレポートはでない

受験直後でも受験後の certmetrics の履歴でも確認することはできませんでした

暫定合格を確認する方法もない

ネットで調べると受験直後の画面に「暫定合格」なる文言が表示されるらしいのですが自分のときはありませんでした
最新の受験だとなくなったんだと思います
また受験直後に webassessor を確認しても完了した試験の項目がなくそこでも確認できませでした

なので現状だと受験直後に合否を確認する手段はありません

合否通知はいつくるか

自分は翌日の朝6:00にメールで合格通知が来ていました
なのでそんなに焦って合否を確認しなくても大丈夫かなと思います

最後に

スコアレポートが出ないのがかなり不満でした
また模擬試験が有料しかほぼないので個人でかつ実費で受験しなければいけない人には正直向かない試験です

2024年11月20日水曜日

GCP のインスタンスで swap 領域を作成する方法

概要
環境
コマンド
fstab
最後に

概要

メモ

環境

e2-micro

コマンド

sudo dd if=/dev/sda1 of=/swapfile bs=1M count=8192
sudo chmod 600 /swapfile
sudo mkswap -f /swapfile
sudo swapon /swapfile
swapon -s

fstab

sudo vim /etc/fstab

/swapfile1  swap   swap    defaults   0 0

最後に

昔の f1 シリーズだとスワップがないと動作しないケースがあったが最近の e2 ではスワップなしでも問題ないケースが多いです

それでもメモリ領域が足りない場合にはスワップを作成して対応してください

2024年11月7日木曜日

Google Cloud Storage でバケット内にオブジェクトがある場合でもバケットごと削除する方法

概要
環境
コマンド
参考サイト

概要

gsutil を使う方法を紹介します

環境

macOS 15.0.1
gsutil 5.30

コマンド

gsutil rm -r gs://sound-bucket-log

参考サイト

https://cloud.google.com/storage/docs/gsutil?hl=ja

2024年11月5日火曜日

App Engine APIs are not enabled 対策

概要
エラー詳細
環境
app.yaml を修正
最後に

概要

対応方法を紹介します

エラー詳細

gcloud app logs tail -s default

2024-10-29 04:54:19 default[20241029t134559]  2024/10/29 04:54:19 internal.flushLog: Flush RPC: Call error 7: App Engine APIs are not enabled, please add app_engine_apis: true to your app.yaml to enable.

環境

google-cloud-sdk 491.0.0
golang runtime 122

app.yaml を修正

以下を追加します

app_engine_apis: true

最後に

最新のラインタイムv2を使う場合は必要です

2024年10月31日木曜日

概要

過去の手順だと動作しないランタイムがあるので最新の手順を紹介します

環境

macOS 15.0.1
Python 3.11.10
google-cloud-sdk 491.0.0
golang runtime 122

google-cloud-sdk のインストール

brew install google-cloud-sdk

dev_appserver.py があるか確認

ls /opt/homebrew/share/google-cloud-sdk/bin/dev_appserver.py

python の設定

グローバルにインストールした python3 でも OK です

pyenv local 3.11.10

実行

python /opt/homebrew/share/google-cloud-sdk/bin/dev_appserver.py .

最後に

すでにサポートされていないランタイムだとこの方法では動作しないので注意してください

参考サイト

https://cloud.google.com/appengine/docs/standard/go/runtime?hl=ja

2024年10月11日金曜日

指定の期間における GCP インスタンスのネットワーク転送量を計算するスクリプト

概要
環境
インストール
認証
集計スクリプト
当日までの今月分の転送量
最後に
参考サイト

概要

例えば前月や当月の本日までの特定の VM におけるネットワーク転送量が知りたいケースがあるかなと思います
コンソールだと合計値が見れないのでスクリプトを作成してみました

環境

macOS 15.0.1
Python python 3.11.10
gcloud 491.0.0
- google-cloud-monitoring 2.22.2
GCP (2024/10/08 時点)

インストール

pipenv install google-cloud-monitoring

認証

gcloud auth application-default login

集計スクリプト

前月分集計する場合は以下のようになります
プロジェクトIDとVM名の部分は適宜変更してください

from datetime import datetime, timedelta

from google.cloud import monitoring_v3


def get_network_usage(project_id, instance_name):
    now = datetime.now()
    current_month_start = datetime(now.year, now.month, 1)
    # 前月の開始日時を計算
    last_month_end = current_month_start - timedelta(
        seconds=1
    )  # 前月の終了日時（現在の月開始日の前日23:59:59）
    last_month_start = datetime(
        last_month_end.year, last_month_end.month, 1
    )  # 前月の開始日時
    print(last_month_end)
    print(last_month_start)
    # UNIX タイムスタンプに変換
    start_time = int(last_month_start.timestamp())
    end_time = int(last_month_end.timestamp())

    # クライアントの作成
    client = monitoring_v3.MetricServiceClient()

    # プロジェクト名の設定
    project_name = f"projects/{project_id}"
    # メトリックス取得期間の設定
    interval = monitoring_v3.TimeInterval(
        {
            "end_time": {"seconds": end_time},
            "start_time": {"seconds": start_time},
        }
    )
    # 取得するメトリクス情報の設定
    filter_str = (
        f'metric.type="compute.googleapis.com/instance/network/received_bytes_count" '
        # f'metric.type="compute.googleapis.com/instance/network/sent_bytes_count" '  # 送信量に関してはこちら
        f'AND metric.label.instance_name="{instance_name}"'
    )

    # メトリクスデータを取得
    results = client.list_time_series(
        name=project_name,
        filter=filter_str,
        interval=interval,
        view=monitoring_v3.ListTimeSeriesRequest.TimeSeriesView.FULL,
    )
    # 合計値を計算
    total_received_bytes = sum(
        [point.value.int64_value for ts in results for point in ts.points]
    )
    print(f"Total received bytes: {total_received_bytes / 1024 / 1024} MB")


# 例: プロジェクト ID とインスタンス ID を使って前月分のネットワーク受信量を計算
get_network_usage("project-123456", "web")

当日までの今月分の転送量

当日分までの転送量の場合は以下です
日付の計算部分だけ変更しています

from datetime import datetime

from google.cloud import monitoring_v3


def get_network_usage(project_id, instance_name):
    # 現在の UTC 日付と時刻を取得
    now = datetime.now()
    # 今月の開始日時を設定
    current_month_start = datetime(now.year, now.month, 1)
    # UNIX タイムスタンプに変換
    start_time = int(current_month_start.timestamp())
    end_time = int(now.timestamp())

    # クライアントの作成
    client = monitoring_v3.MetricServiceClient()

    # プロジェクト名の設定
    project_name = f"projects/{project_id}"
    # メトリックス取得期間の設定
    interval = monitoring_v3.TimeInterval(
        {
            "end_time": {"seconds": end_time},
            "start_time": {"seconds": start_time},
        }
    )
    # 取得するメトリクス情報の設定
    filter_str = (
        f'metric.type="compute.googleapis.com/instance/network/received_bytes_count" '
        # f'metric.type="compute.googleapis.com/instance/network/sent_bytes_count" '  # 送信量に関してはこちら
        f'AND metric.label.instance_name="{instance_name}"'
    )

    # メトリクスデータを取得
    results = client.list_time_series(
        name=project_name,
        filter=filter_str,
        interval=interval,
        view=monitoring_v3.ListTimeSeriesRequest.TimeSeriesView.FULL,
    )
    # 合計値を計算
    total_received_bytes = sum(
        [point.value.int64_value for ts in results for point in ts.points]
    )
    print(f"Total received bytes: {total_received_bytes / 1024 / 1024} MB")


# 例: プロジェクト ID とインスタンス ID を使って前月分のネットワーク受信量を計算
get_network_usage("project-123456", "web")

最後に

GCP のインスタンスが一ヶ月でどれくらいネットワーク通信をしているのか確認するのに使えると思います
具体的な取得方法は GCP 側でブラックボックスになっているのでどこにどれくらい通信したのかはわかりませんがおおよその目安として使用量がわかるかなと思います

何もしていなくても数GBの通信はしていることが確認できました

参考サイト

2024年5月2日木曜日

Mac で gcloud コマンドのタブ補完を有効にする方法

概要
環境
補完を有効にする方法
参考
最後に

概要

zsh の場合はを紹介します

環境

macOS 11.7.10
google-cloud-sdk 468.0.0
Python 3.12.2

補完を有効にする方法

vim ~/.zshrc

source "$(brew --prefix)/share/google-cloud-sdk/path.zsh.inc"
source "$(brew --prefix)/share/google-cloud-sdk/completion.zsh.inc"

参考

brew info google-cloud-sdk を実行するとちゃんと表示されていました
bash などの方法も記載されています

brew info google-cloud-sdk
==> google-cloud-sdk: 470.0.0 (auto_updates)
https://cloud.google.com/sdk/
/usr/local/Caskroom/google-cloud-sdk/468.0.0 (129B)
From: https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/g/google-cloud-sdk.rb
==> Name
Google Cloud SDK
==> Description
Set of tools to manage resources and applications hosted on Google Cloud
==> Artifacts
google-cloud-sdk/install.sh (Installer)
google-cloud-sdk/bin/git-credential-gcloud.sh -> git-credential-gcloud (Binary)
google-cloud-sdk/completion.zsh.inc -> /usr/local/share/zsh/site-functions/_google_cloud_sdk (Binary)
google-cloud-sdk/bin/gsutil (Binary)
google-cloud-sdk/bin/anthoscli (Binary)
google-cloud-sdk/bin/bq (Binary)
google-cloud-sdk/completion.bash.inc -> /usr/local/etc/bash_completion.d/google-cloud-sdk (Binary)
google-cloud-sdk/bin/docker-credential-gcloud (Binary)
google-cloud-sdk/bin/gcloud (Binary)
==> Caveats
To add gcloud components to your PATH, add this to your profile:

  for bash users
    source "$(brew --prefix)/share/google-cloud-sdk/path.bash.inc"

  for zsh users
    source "$(brew --prefix)/share/google-cloud-sdk/path.zsh.inc"
    source "$(brew --prefix)/share/google-cloud-sdk/completion.zsh.inc"

  for fish users
    source "$(brew --prefix)/share/google-cloud-sdk/path.fish.inc"

==> Analytics
install: 11,433 (30 days), 32,208 (90 days), 107,295 (365 days)

最後に

これでサブコマンドなどの補完が行えます

2023年2月24日金曜日

gcloud scp コマンドで実際に実行している素の scp コマンドを表示する方法

概要
環境
サンプルコマンド

概要

--dry-run オプションを使用します

環境

macOS 11.7.3
gcloud 371.0.0

サンプルコマンド

gcloud scp

gcloud compute scp --ssh-key-file="~/.ssh/id_rsa" --dry-run test.text user1@web:~/test.txt

実際に実行される scp コマンド

/usr/bin/scp -i /Users/user1/.ssh/id_rsa -o CheckHostIP=no -o HashKnownHosts=no -o HostKeyAlias=compute.1234567890 -o IdentitiesOnly=yes -o StrictHostKeyChecking=yes -o UserKnownHostsFile=/Users/user1/.ssh/google_compute_known_hosts test.text user1@xxx.xxx.xxx.xxx:~/test.txt

ちなみに --ssh-key-file のデフォルトパスは ~/.ssh/google_compute_engine なのですでにその名前で鍵がある場合は指定不要です

2022年3月1日火曜日

GCP のクラウドストレージでバケットの使用量を確認する方法

概要
環境
gsutil を使う
メトリックエクスプローラを使う
最後に

概要

なぜかクラウドストレージのメニューでは確認できないようです

以下2つの方法を紹介します

環境

macOS 11.6.4
gsutil 5.6

gsutil を使う

gsutil ls -l gs://your.backet.name/

メトリックエクスプローラを使う

Resource & Metric で GCS BUCKET から TOTAL BYTES を選択することで見れます

最後に

普通にバケットのエクスプローラ画面で確認できるようにしてほしい気もします

API の設計上数値的な情報は全部メトリックに集めようという思想なんだと思います

2021年7月7日水曜日

GCP の Cloud Run を試してみた

概要
環境
サンプルアプリの作成
サンプルアプリのビルドとプッシュ
サンプルアプリのデプロイ
- サービスの作成
動作確認
クリーンアップ
おまけ: コマンドでデプロイする
最後に
トラブルシューティング
参考サイト

概要

Cloud Run はコンテナ化したアプリをデプロイすることができるプラットフォームですコンテナ化さえしていれば何でもデプロイできるので便利です (ローカルパスなどをマウントしていない場合) 今回は簡単な Web アプリを作成してデプロイしてみました

環境

macOS 11.4
docker
Ruby 3.0.1p64
Cloud Run
Container Registry

サンプルアプリの作成

今回は Ruby アプリをデプロイしてみますまずはアプリを作成します

mkdir test
cd test
bundle init
vim Gemfile

gem "sinatra"
gem "thin"

bundle config path vendor
bundle install
bundle lock --add-platform x86_64-linux
vim app.rb

require 'sinatra/base'

class WebApp < Sinatra::Application
  get '/' do
    'ok'
  end
end

vim config.ru

require './app'

run WebApp

サンプルアプリのビルドとプッシュ

次に docker を使ってアプリをビルドします gcloud コマンドに専用のビルドコマンドがあるのでそれを使うとレジストリの認証をしてプッシュまでしてくれます

vim Dockerfile

FROM ruby:3.0.0

WORKDIR /usr/src/app
COPY Gemfile Gemfile.lock ./
ENV BUNDLE_FROZEN=true
RUN gem install bundler && bundle install

COPY . ./

CMD ["bundle", "exec", "rackup", "config.ru", "-o", "0.0.0.0", "-p", "8080"]

デフォルトだと Cloud Run は 8080 でアプリがリッスンすることを想定しているので 8080 を指定します

vim .dockerignore

Dockerfile
.bundle/
vendor/

dockerignore も作成しますビルドは Cloud Build を使うため不要なファイルはビルドに含めないようにします

gcloud builds submit --tag us.gcr.io/PROJECT_ID/test

PROJECT_ID の部分は gcloud projects list で確認できますまたプッシュ可能なレジストリのリージョンは「gcr.io」「us.gcr.io」「eu.gcr.io」「asia.gcr.io」があり今回は us.gcr.io を選択しています

これは Cloud Run と Registry のリージョンを同じにするためでありそうすることでデプロイ時のネットワーク転送料が無料になります

gcloud build コマンドを使うとクラウドビルドしてくれるのでローカルで docker が動作している必要はありません

GCP の管理画面からコンテナレジストリの一覧を確認するとちゃんとイメージがプッシュされているのが確認できると思います

サンプルアプリのデプロイ

イメージがプッシュできたら Cloud Run にデプロイしてみます今回は UI からデプロイしてみます

サービスの作成

まずはサービスを作成します Cloud Run の画面から「サービス作成」をクリックします

そしてサービス名とリージョンを指定します今回は us-central-1 を指定します

次に先程プッシュしたイメージを選択します

最後のアプリを起動させるトリガーを選択します今回は Web アプリなので Ingress で「すべてのトラフィックを許可する」を選択しますまた認証は「未認証の呼び出しを許可」にチェックを入れます

これで「作成」をクリックするとアプリのデプロイが完了します

動作確認

デプロイが完了すると以下のようにアクセス可能な URL が表示されます (何度かデプロイミスしたのでエラーの履歴があります)

あとは表示されている URL にアクセスするとアプリが動作しているのが確認できると思います

クリーンアップ

プロジェクトを作成できるのであればプロジェクトごと削除しましょう

プロジェクトを削除できないのであれば Cloud Run 上のサービスと Registry 上にプッシュしたイメージを削除しましょう

おまけ: コマンドでデプロイする

UI でやった作業をコマンドで行うこともできますいくつか質問されるので答える必要がありますが認証の部分の設定になるので UI でデプロイしていればわかると思います

gcloud run deploy --image us.gcr.io/PROJECT_ID/test --platform managed

最後に

Cloud Run に Web アプリをデプロイしてみました CPU やメモリの量を調整したり起動トリガーなどもいろいろ変更できるのでかなり使えるサービスだと思います

アプリをコンテナ化しているのであればプッシュするだけで起動できるのでわざわざインスタンスを構築する必要もなくなります

またクラウドストレージにクラウドビルドのリソースも残っているのでそれらも削除しておきましょう

トラブルシューティング

Your bundle only supports platforms ["x86_64-darwin-20"] but your local platform is x86_64-linux. Add the current platform to the lockfile with `bundle lock --add-platform x86_64-linux` and try again.

が表示される場合は bundle lock --add-platform x86_64-linux してからビルド＆プッシュしましょうクラウドビルドを使っているためプラットフォームが異なるのが原因です

Dockerfile の書き方にも少しくせがあります自分が遭遇したエラーは

bundler: command not found: rackup
Install missing gem executables with `bundle install`

bundle config path vendor を Dockerfile から削除するとうまくパスが見えました

参考サイト

https://cloud.google.com/run/docs/quickstarts/build-and-deploy?hl=ja&_ga=2.113478727.-110751585.1560811870

2019年12月12日木曜日

Google Speech to Text を使う場合はデータのロギングを有効にしたほうがいい

概要
環境
料金比較
データロギングを有効にする
有効にするデメリット
最後に
参考サイト

概要

Google Speech to Text は音声データを文字起こししてくれるサービスです
月間で 60 分以内であれば無料で使えます
60 分以上の音声データを解析する場合にはデータのロギング機能を ON にすることをオススメします
理由は単純に安くなるからです

環境

Google Speech to Text API (2019/12/11 時点)

料金比較

基本は 15 秒単位で課金されます
データロギングを有効にした場合は 0.004/15秒になります
無効の場合は 0.006/15秒と少し高くなります

データロギングを有効にする

コンソールから API の一覧に移動し Speech to Text を検索しましょう
そしてデータのロギングから「有効にする」ボタンを押せば OK です

有効にするデメリット

解析させたデータが Google 側に残り学習の精度向上のために使われるようです
プライベートなデータを含む音声データの場合それらを学習データの対象などのしたくない場合は有効にしないほうが良いのかもしれません
(詳しくはこちらを御覧ください)

逆にすでにパブリックで公開している音声データは無効にするメリットは特にないので有効にして料金の抑えるのと音声の解析精度を上げたほうが良いかなと思います

最後に

Google Speech to Text のデータロギングについて紹介しました
特に気にしないのであれば有効にすると料金も抑えられます
月間で 60 分を超えないのであればデータロギングの有効無効に関わらず無料で使えるのでどちらでも OK だと思います

参考サイト

2019年11月2日土曜日

The resource 'projects/product-123456/global/firewalls/default-allow-ssh' is not ready

概要
対処方法

概要

GCP のファイアウォールを操作するときにタイトルのエラーが発生し続けファイアウォールの操作ができなくなりました
対処方法を紹介します

対処方法

対処方法ではないのかもしれませんがいろいろ試した結果解消しなかったので同じルールを再作成しました

gcloud compute firewall-rules delete default-allow-ssh
gcloud compute firewall-rules create default-allow-ssh --network default --allow tcp:22 --priority 65534

たぶんこれが一番てっとり早いはず

2019年5月28日火曜日

【GCP】Cloud Scheduler を使ってみた

概要
環境
HTTP + Get
HTTP + POST + JSON
Pub/Sub
App Engine HTTP
最後に
参考サイト

概要

GCP の Cloud Scheduler は cron サービスです
3 ジョブまでは無料で使えるので試してみました

環境

macOS 10.14.5
gcloud 247.0.0

HTTP + Get

コンソールから作成しました

Cloud Scheduler のページアクセスし「ジョブを作成」を選択します

入力した情報は以下の通りです

名前･･･job1 (好きな名前で OK)
頻度･･･*/1 * * * * (テストのため 1 分に 1 回実行)
タイムゾーン･･･日本
ターゲット･･･HTTP
URL･･･リクエストしたい好きな URL
HTTP メソッド･･･GET

これで「作成」を選択します

ジョブが作成されるとスケジュール通りに実行されます
結果が「成功」になっていれば OK です
手動で実行することもできます

ログは Stackdriver に自動的に格納されます
スケジュール時のリクエストのログが残るようです
レスポンスに関してはレスポンスコードしか残らずレスポンスボディやヘッダは残らないようです

HTTP + POST + JSON

コンソールからではヘッダが設定できないので gcloud コマンドから作成します

gcloud beta scheduler jobs create http job2 \
--time-zone "Asia/Tokyo" \
--schedule="*/1 * * * *" \
--uri="https://kaka-request-dumper.herokuapp.com/" \
--headers="Content-Type=application/json" \
--http-method="POST" \
--message-body="{\"key1\":\"value1\"}"

--headers オプションで Content-Type=application/json を指定しましょう
--message-body は文字列しか指定できないのでエスケープして JSON を指定しましょう
これで実行するとちゃんと JSON ボディが設定されてサーバ側にリクエストされます

Pub/Sub

特定のトピックにペイロードを送信することもできます
事前に Pub/Sub のコンソールからトピックとサブスクリプションを作成しておきましょう

あとはジョブを作成します
ターゲットを「Pub/Sub」にトピックに事前に作成トピックを指定しましょう
サブスクリプションを指定する項目はコンソールにはないようです

ペイロードを受け取るサブスクライバーは何でも OK です
今回は Ruby で実装しました (参考)

bundle init
vim Gemfile

gem "google-cloud-pubsub"

bundle install --path vendor
touch app.rb

require 'google/cloud/pubsub'

pubsub = Google::Cloud::PubSub.new(
  project_id: 'pjct-123456',
  credentials: './pjct-123456-abcd12345.json'
)
topic = pubsub.topic 'cloud_scheduler_topic'
sub = pubsub.subscription ''
subscriber = sub.listen do |msg|
  msg.acknowledge!
  puts msg.data
  puts msg.message_id
  puts msg.attributes
end
subscriber.start
sleep

bundle exec ruby app.rb

しばらく待っていれば以下のようにメッセージが表示されるのが確認できると思います

bundle exec ruby app.rb 
hoge
560942199166650
{}
hoge
560943876532507
{}

App Engine HTTP

事前にプロジェクト内に App Engine を使って適当にアプリを起動しておきましょう

あとはそのアプリに使ってリクエストするようなジョブを作成するだけです
今回は App Engine を default というサービス配下に作成しました
違うサービス配下に作成した場合は適宜変更してください

最後に

Cloud Scheduler を試してみました
現状は 3 つのターゲットをが指定可能なようです
MemoryStore に値を入れることができたり GCE の定期的な起動や停止、何かしらのメッセージやコマンドが渡せたできるようになると面白いかなと思いました
今後に期待かなと思います

参考サイト

2019年5月26日日曜日

【GCP】Cloud Memory を使ってみた

概要
環境
インスタンス作成
インスタンス確認
redis-cli 接続確認
料金
後始末
最後に
参考サイト

概要

GCP の Redis サービス MemoryStore を使ってみました
インスタンスの作成から redis-cli を使った接続確認まで行いました

環境

macOS 10.14.5
gcloud 247.0.0

インスタンス作成

まずはインスタンスを作成します
コンソール画面から作成しても OK ですが今回は gcloud を使いました

gcloud beta redis instances create myredis --size=1 --region=us-central1 --redis-version=redis_4_0

タイプは「基本」で作成されます
基本はシンプルなシングル構成になります
メモリ容量は最小の 1GB にしています
Redis のバージョンは MemoryStore で使える最新の 4.0 にしています

またインスタンスの作成には beta コマンドを使います

インスタンス確認

create が完了したらインスタンスの状態を確認しましょう

gcloud redis instances describe myredis --region=us-central1

authorizedNetwork: projects/pjct-123456/global/networks/default
createTime: '2019-05-22T07:20:21.365383747Z'
currentLocationId: us-central1-b
host: 10.0.0.3
locationId: us-central1-b
memorySizeGb: 1
name: projects/pjct-123456/locations/us-central1/instances/myredis
port: 6379
redisVersion: REDIS_4_0
reservedIpRange: 10.0.0.0/29
state: READY
tier: BASIC

エンドポイントの IP やポートなどが表示されると思います
MemoryStore では FQDN ではなく IP アドレス (10.0.0.3) を使ってアクセスすることになります

MemoryStore は基本的に GCP 内のリソース (Compute Engine VM インスタンス、Google Kubernetes Engine クラスタ、Cloud Functions、App Engine フレキシブル環境、App Engine スタンダード環境) からしかアクセスできません

redis-cli 接続確認

今回は GCE インスタンスを 1 台作成して動作確認しました
また動作確認用の GCE と MemoryStore のインスタンスは同一ネットワーク (default) に所属するようにしてください

gcloud redis instances describe myredis --region us-central1 | grep default

authorizedNetwork: projects/pjct-123456/global/networks/default

gcloud compute instances describe vm01 | grep ' network:'

network: https://www.googleapis.com/compute/v1/projects/pjct-123456/global/networks/default

GCE に SSH ログインしたら先程確認したエンドポイントに対して動作確認してみます
ちなみに GCE は Ubuntu18.04 LTS のイメージを元に作成しました

apt -y install redis-tools
redis-cli -h 10.0.0.3

# Server
redis_version:4.0.14
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:c361ea82ce4c0f02
redis_mode:standalone
os:Linux 4.14.94+ x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:6.3.0
process_id:1
run_id:288517b3521abb484270dcf09846499bcc79489f
tcp_port:6379
uptime_in_seconds:985
uptime_in_days:0
hz:10
lru_clock:15006935
executable:/data/redis-server
config_file:/usr/local/etc/redis/redis.conf

こんな感じでホストを指定するだけでアクセスできます

料金

Cloud MemoryStore (アイオワ、1GB)･･･$0.049 (参考)
GCE (アイオワ、f1.micro)･･･$0.000 (参考)

後始末

Cloud MemoryStore インスタンスの削除

gcloud beta redis instances delete myredis --region=us-central1

GCE インスタンスの削除

gcloud compute instances delete vm01

最後に

Cloud MemoryStore を試してみました
インスタンスを作成するだけで Redis を使えるようになるので簡単です
注意点としては GCP の特定のリソースのみからしかアクセスできない点です
GCE を使ってグローバルな IP アドレスからポートフォーワードなどすれば外部からでもアクセスできるようになるとは思います

参考サイト

https://cloud.google.com/memorystore/docs/redis/quickstart-gcloud?hl=ja

登録: 投稿 (Atom)