Cloud Functions for FirebaseとContainer RegistryとCloud Storage

ストレージの使用量がやたら多いので色々調べてみたときの備忘録。

Container Registryをきれいにしたらかなり下がった(*´ω｀*)

各バケットの用途

見てみると、色んなバケットが利用されている。

デフォルトのバケット(GAE)
- <project-id>.appspot.com
- staging.<project-id>.appspot.com
Cloud Functionsで利用
- gcf-sources-<project-number>-asia-northeast1
- gcf-sources-<project-number>-us-central1
Container Registryで利用
- asia.artifacts.<project-id>.appspot.com
- us.artifacts.<project-id>.appspot.com

ずば抜けて容量が多いのは、Container Registoryで使われている
asia.artifacts.<project-id>.appspot.com。。

デフォルトのバケット(GAE)

App Engineで作成されるバケットたち。

<project-id>.appspot.com
- デフォルトのバケット
staging.<project-id>.appspot.com
- デプロイ時に使用する一時ストレージ

このあたりに書かれている感じ。

Cloud Functionsで利用

gcf-sources-<project-number>-<region>

中を見てみるとデプロイしたソースが配置されているよう。

公式ドキュメントの以下に流れが書いてあった。
・Cloud Functions イメージのビルド

関数のソースコードをCloud Functionsにデプロイすると、Cloud Storageバケットに保存

次にCloud Buildによって、コードは自動的にコンテナイメージに構築され、イメージレジストリにpush

Cloud Functionsは、関数を実行するためにコンテナを実行する必要がある場合に、このイメージにアクセス

また、Cloud Functions for Firebaseの流れはこちら。
・Cloud Functions for Firebase | Firebase Documentation

関数のソースコードをデプロイするとFirebase CLIによって関数コードの.zipを作成

Firebaseプロジェクト内のCloud Storageバケット(gcf-sources-*)にアップロード

Cloud Buildが関数のソースコードを取得してビルド

ビルドされた関数コードのコンテナイメージ（gcf）は、
プロジェクト内の非公開のContainer Registryリポジトリにアップロード新しい関数が展開

更新されたコードをデプロイすると、Cloud StorageとContainer Registryのビルドアーティファクトが更新され、
新しいインスタンスに置き換えられる

更新された際、古いバージョンのインスタンスがクリーンアップされる