たびたび、サーチコンソールなどの権限を設定する際に、
大元のドメインのオーナーを付与する方法を忘れるので備忘メモ。
ウェブマスターセントラルから行う。
https://www.google.com/webmasters/verification/home
単なるメモでした。
ではでは。
たびたび、サーチコンソールなどの権限を設定する際に、
大元のドメインのオーナーを付与する方法を忘れるので備忘メモ。
ウェブマスターセントラルから行う。
https://www.google.com/webmasters/verification/home
単なるメモでした。
ではでは。
Cloud Run に新しいコンテナをデプロイした際、
新しいリビジョンにはトラフィックを流さずに一旦privateな状態でリビジョンで動作確認を行い、
トラフィックを流したい、という要望がありそうですが、そのやり方
(デプロイの際に最新リビジョンにトラフィックを流さない方法)
必要なオプションは --no-traffic
オプションです
具体的には以下のようなイメージになります
gcloud run deploy $SERVICE_NAME \ --image $IMAGE \ --port $PORT \ --project $GCP_PROJECT_ID \ --region $GCP_REGION \ --platform=managed \ --allow-unauthenticated \ --no-traffic \ --quiet
gcloud run deploy | Cloud SDK Documentation | Google Cloud
ではでは!
Cloud Run 使ってますかー?
例えば、本番環境とテスト環境など、 Project を分離した場合、どちらかの GCR などから両方の環境の Cloud Run にコンテナをデプロイしたくなることはあると思います。
一般的には単一のコンテナで(環境に合わせて build などせずとも)複数環境対応できるのが良いとされていると思います。
Run で他の Project の GCR からイメージを取得しようとすると、
Google Cloud Run Service Agent must have permission to read the image
という感じのエラーメッセージが表示されます。
これは、Run のデプロイの際に他のプロジェクトからコンテナを Pull しようとしたが、コンテナレジストリに対して Run の Service Agent が権限を持っていないというメッセージになります。
さて、どうやって対応すればよいのか。
Run の Service Agent がつまりは他のプロジェクトのレジストリの権限を持てばよいということになります。
手順を示します。
Run の Service Agent は以下のような命名ルールになっています。
service-<projectNumber>@serverless-robot-prod.iam.gserviceaccount.com
注意点は project_id ではなく、 project_number である点です。
一番確認しやすいのは、GCP コンソールの自分のアイコンの左横の 点が3つ のボタンから、
Project Setting を押し、 Project number: を参照します。
(これは参照元 projct の ID です。Run が動く側。)
上記のルールの Service Agent をメンバーとして追加します。
また、ロールは Storage Object Viewer
を 参照先のプロジェクト
に追加する。
(これは GCR:レジストリがある側のプロジェクトです)
Cloud Run のデプロイを試し、動作確認をしましょう。
問題なくデプロイできれば完了です。
ではでは。
開発していると、特定のディレクトリだけ git にコミットしたいけど(.gitkeep)、
その中に入るファイルは除外したいんだよなぁって場合があると思います。
そういう場合の .gitignore の書き方は..
特定のディレクトリが hoge の場合、 .gitignore には以下のように記述します。
/hoge/* !/hoge/.gitkeep
ディレクトリ内にあるファイルはすべて git 追加対象外にする、
/hoge/.gitkeep だけは有効にする。
という感じの記述です。
これで、なにかbuild時にファイルを生成するだけのディレクトリなどで、
基本的に git にコミットしたくないディレクトリがある場合に対応できます。
docker などでディレクトリごと持っていく場合には、 .dockerignore などで除外すると良さそうですが、
.dockerignore は記述が .gitignore とにてるけど振る舞いが全然ちがうので注意が必要そうです(余談)
ではでは.
GCP のコンテナスキャン、便利な機能ですが、ひたすらコンテナを GCR/Articact Registry に push したり、
GAE のデプロイを大量に行っていると課金でびっくりすることもあるかと思います。
停止するためには、GCR か Artifact Redistry の settings から Scannning を無効化します。
どちらも機能は共有なので GCR を利用していても Artifact Registry 側が有効化されているように見えるかもしれません。
どちらかを停止すれば共通で停止されます。
https://console.cloud.google.com/gcr/settings
https://console.cloud.google.com/artifacts/settings
図の Turn Off を実行します。
Scanning : Off
になれば無効化されています。
こんな感じでかんたんに無効化することができます。
Organization のポリシーなどで標準で有効化とかしていると Project 作ったときに勝手に有効化されたりするかもしれません。(要出典)
ではでは。
タイトルの通り。
マイクロサービスの Fault Tolerant に関して説明する際に、
いつも探してしまうがなかなか見つからないのでメモ。
下記の スライド と 解説 を合わせて見ると良い感じです。
スライド(PDF)
https://www.jfokus.se/jfokus16/preso/Building-Fault-Tolerant-Microservices.pdf
解説.
たびたび話題にしようとして忘れてしまうのでメモ。 秒間100万リクエストはすごい。