Firebaseストレージアーティファクト
私eu.artifacts.%PROJECT NAME%.appspot.comは何であるかを理解しようとしています。現在、1日の5GBの制限から800MBのストレージを使用しています。これには、アプリケーション/オクテットストリームタイプのファイルのみが含まれます。このバケットは自動的に作成され、ファイルパスはeu.artifacts .... appspot.com/containers/imagesです。そこにある2つの最も重いファイルの重量は200mbと130mbにもなります。削除してみましたが、自動的に再作成されました。ユーザーは私のウェブサイトに写真をアップロードできますが、そのバケットは現在、すべてのユーザー画像を含む約10MBしかかかりません。
だから私の質問は:このバケツは何のためにあり、なぜそれがそれほど重くなるのですか?
回答
Cloud Functionsを使用している場合、表示されているファイルは、ランタイム(ノード10以降)の構築方法の最近の変更に関連しています。
Cloud Functionsは、Cloud Buildを使用して、Cloud Functionsのランタイム(ノード10以降用)を作成するようになりました。そして、Cloud Buildは、Container Registryを使用してこれらのランタイムを保存し、プロジェクトの下の新しいCloudStorageバケットにそれらを保存します。
詳細については、FirebaseのCloud Functions forFirebaseでNode.js10以降を使用するために課金アカウントが必要な理由に関するFirebaseの価格に関するよくある質問のこのエントリもご覧ください。
これらのアーティファクトについては、firebase-talkメーリングリストのこのスレッドも参照してください。
GCPサポートに相談しましたが、次のことがいくつかあります
- クラウド機能により、ストレージ使用量が急増しました
- これらのアーティファクトはデフォルトのバケットに保存されないため、保存されている合計バイト数が空き枠の制限に達していない場合でも課金されます
- https://console.cloud.google.com/storage/browserでアーティファクトバケットを削除します。サポートスタッフによると
アーティファクトバケットに関しては、以前のバージョンの関数が格納されているため、実際にそれらを取り除くことができます。ただし、「gcf-sources ...」バケットには現在の画像が含まれているため、削除することはお勧めしません。このバケットを削除すると、関数が台無しになります。
全体を取り除いてみましたが、今のところ問題ありません。後で壊れたら更新します。
編集201118:以下のコメントを参照してください。バケット内のすべてのコンテンツを削除する間、バケットを保持する必要がある場合があります。
@ yo1995の応答に加えて、GCPにアクセスしなくてもバケットを削除できます。Firebaseにとどまり、ストレージに移動してから[バケットを追加]に移動します。そこから、gcpバケットとアーティファクトバケットをインポートするオプションが表示されます。次に、それに応じてバケットを削除できます。
@ yo1995
に加えて、Firebaseサポートに相談したところ、アーティファクトバケットを削除してはならないことが確認されました。基本的に、アーティファクトは、「gcf-sources」バケットに格納される最終的なイメージを構築するために使用されます。
それらを直接引用すると
、「「XX.artifacts」の内容は自由に削除できますが、バケットはそのままにしておいてください。次の展開サイクルで使用されます。」
アーティファクトバケットを完全に削除すると、意図しない動作が発生する可能性があります。
また、「チームはこのバケットを自動的にクリーンアップするように取り組んでいますが、ソリューションを公開する前に解決する必要のあるいくつかの制限があります。」
とりあえず、1日以上前のファイルを自動削除するようにバケットを設定しました。
ストレージを削減する方法
したがって、この問題には素晴らしい答えがありますが、それを修正する方法に関する解決策には、さらに深く掘り下げる必要があります。
将来の開発者が追いかけるのを助けるために、GCPのプロジェクトに次のルールを追加した後に表示される結果を次に示します。
オレンジ色の線がus-artifacts.<your-project>.appspot.comバケツです。
問題を修正する手順
- https://console.cloud.google.com/に移動します
- Firebaseプロジェクトに対応するGCPプロジェクトを開きます
- メニューで、[ストレージ]-> [ブラウザ]を選択します
- 問題のある
us-artifacts.<your-project>.appspot.comバケットをクリックします - [ライフサイクル]タブに移動し、3日間の寿命を追加します
- ルールを追加する
- オブジェクトの削除
- 年齢、3日
注:結果は約24時間後まで使用状況グラフに表示されません
警告
Firebaseは以前のコンテナを逆参照するコンテナを使用するため、3日間の期間を設定してFirebaseデプロイ関数が失敗し始めた場合は、関数のローカル名を更新してバージョン管理を含めるか、ビルドフラグを指定して古いものを削除する必要がありますバージョンを削除するか、firebase.jsonから削除するか、廃止された関数を手動で削除してください。
バージョン管理されたAPIタイプの関数の使用
エントリポイントで、を想定しindex.ts、Firebaseを初期化したと想定します。
admin.initializeApp(functions.config().firebase)
import * as functions from 'firebase-functions'
// define the app as a cloud function called APIv1 build xxxxxx
export const APIv1b20201202 = functions.https.onRequest(main)
mainアプリの名前はどこですか
そしてあなたの中で firebase.json
...
"hosting": {
"public": "dist",
"ignore": ["firebase.json", "**/.*", "**/node_modules/**", "**/tests/**"],
"rewrites": [
{
"source": "/api/v1/**",
"function": "APIv1b2021202"
}
]
},
...
または、手動で更新するには
# Deploy new function called APIv11
$ firebase deploy --only functions:APIv11 # Wait until deployment is done; now both APIv11 and APIv10 are running # Delete APIv10 $ firebase functions:delete APIv10
別の方法として、ライフサイクルルールを作成して、フォルダー内のオブジェクトを削除することもできます。年齢を1日に設定します。そのため、1日以上経過したフォルダ内のすべてのオブジェクトが削除されます。ライフサイクルルール
SetCondition