ファイルの保存先
デフォルトはディスク上のフォルダ。バケットはいくつでも追加できる
アップロードしたファイルはディスク上のフォルダに入ります。初回起動時に、インスタンスは default という名前のストレージバックエンドを一つ作り、server.data_dir の中の blobs を指して、すべてのアップロードをそこへ送ります。ひとりで自分のマシンに置くなら、これで完結します。
Docker イメージでは server.data_dir は /data です。このボリュームをマウントしておけば、作り直してもファイルは残ります。
保存先を追加する
バックエンドは管理画面で管理します。それぞれに名前、アドレス、任意の容量上限、読み取り専用の切り替え、ブラウザを直接向かわせる切り替えがあります。バケットを追加してデフォルトにすると、フォルダは新しいアップロードを受けなくなり、次の起動でも作り直されません。
アドレスは封印して保存され、二度と出てこない
アドレスには認証情報が含まれるので、保存前に security.secret_key で暗号化され、どのリクエストからも読み出せません。この鍵をなくすと、すべてのバックエンドを入れ直すことになります。設定を見てください。
既にある名前で追加すると、置き換えになります。
ファイルがどこに入るか
デフォルトのバックエンドは、入る限りファイルを受けます。運営者がわざわざ選んだからです。入らないときだけほかのバックエンドが候補になり、いちばんぴったり入るものが選ばれます。
バックエンドを読み取り専用にすると、新しい中身は受けなくなり、すでにあるものはそのまま残ります。バックエンドを引退させる前にはこうします。
どれよりも大きなファイル
デフォルトはオフです。有効にすると、どのバックエンドにも丸ごと入らないファイルが複数に分割されます。無料の 10 GB バケットが 5 つあれば、有効なら 40 GB のファイルが入り、無効なら断られます。
普通のアップロードは散らばりません。分割するのは、どこにも丸ごと入らないときだけです。
分割したファイルはこのサーバー経由で返ります。ただし、断片を持つバックエンドがすべて直接アクセス可なら、ブラウザが自分で断片を取ってきてつなぎます。無料枠では、サーバー経由にするとアップロードとダウンロードの帯域が別々にかかります。
複数使いたくなるとき
- マシンのディスクは小さいか高いけれど、バケットはそうでもない。
- 複数のインスタンスで同じファイルを見る必要がある。
- Garage や MinIO などをすでに動かしていて、バックアップ先を一つにまとめたい。
それ以外なら、フォルダのほうがシンプルで速く、設定ミスの原因も一つ減ります。
引退させる
バックエンドを読み取り専用にすると、新しい中身はほかへ行き、すでにあるものは引き続き配信されます。何も保存されていない状態になれば削除できます。共有が終わり、掃除で中身が消えていけば、いずれそうなります。
ファイルが残っているバックエンドは削除できない
管理画面でもコマンドラインでも断られ、残っているファイルの数が表示されます。先に引退させて、空になるのを待ってください。
コマンドラインから
tessera-server backends で管理画面と同じことができます。サービスを止めていても動きます。
tessera-server backends list
tessera-server backends add archive s3://my-bucket
tessera-server backends default archive
tessera-server backends capacity archive 10000000000
tessera-server backends retire default
tessera-server backends remove defaultlist は認証情報を表示しません。capacity はバイト単位で、0 なら上限なしです。retire は読み取り専用の切り替えです。動いているサーバーに反映されるのは、次に起動したときです。
アドレスの書き方
| 保存先 | アドレス | 備考 |
|---|---|---|
| ディスク上のフォルダ | data/blobs | デフォルト |
| Garage、RustFS、MinIO、VersityGW | s3://bucket | |
| SeaweedFS | s3://bucket | -s3.config の ID ファイルがないと書き込みをすべて拒否する |
| s3proxy | s3://bucket | 2.6.0 より新しいビルドが必要 |
| Azure Blob | azure://container | |
| WebDAV | https://host/path | 小さなファイル専用。下を参照 |
| Google Cloud Storage | gs://bucket | 未検証。下を参照 |
エンドポイント、リージョン、平文 HTTP の保存先向けの allow_http など、アドレス以外に必要なものは、そのバックエンドのオプションに入れます。
表の最後以外の保存先には、変更のたびにテストスイートを実行しています。AWS S3、Cloudflare R2、Backblaze B2 は同じ S3 API を話し、認証情報があるときに動く別のジョブで確認しています。
WebDAV は 64 KiB 未満のファイルしか受けない
WebDAV でアップロードする方法は、本体を丸ごと送るリクエスト一つしかありません。一方、share.inline_threshold_bytes を超えるものは少しずつ書き込みます。そのため大きなファイルは、途中で失敗する前に最初から断られます。メモや小さなファイル用に使うか、使わないでください。
Google Cloud Storage は組み込み済みだが未検証
ライブラリが書き込みに使う機能を実装したエミュレーターがないので、動くことをここでは証明できていません。最初に使うなら、大きなファイルをアップロードし、ダウンロードし、削除して、バケットを確かめてから本番で使ってください。
ブラウザからバケットへ直接
S3 か Google Cloud Storage のバックエンドでは、直接アクセスを有効にできます。すると大きなアップロードはこのサーバーを通らず、ブラウザからバケットへ直接送られます。ダウンロードの一部も、ストリーミングする代わりに 15 秒だけ有効なリンクを渡します。
ダウンロードが直接になるのは、次をすべて満たすときだけです。共有にパスワードも回数制限もない、ファイルが一つだけ、訪問者のブラウザからバケットに届く。それ以外はこれまでどおりインスタンスが配信し、どのダウンロードも先に同じ確認を通ります。
バケットには、ブラウザからのアップロードを許可する CORS ルールが必要です。ないとブラウザはサーバー経由の送信に戻ります。それでも動きますが、何も節約できません。
S3 で設定しておくルール
始めて放置したアップロードは、バケットに断片を残します。tessera は見つけられたものを片付けますが、それに失敗すると S3 はずっと残して課金し続け、しかもファイルの一覧には出てきません。
AbortIncompleteMultipartUpload のライフサイクルルールを設定する
期間は share.upload_session_ttl_hours より数日長くします。どの S3 事業者も対応しています。設定しないと、バケットが気づかないうちに膨らむことがあります。
バケットに入るもの
ファイルごとにオブジェクトが一つ、年、月、ランダムな ID の下に入ります。パスに名前やアドレスは出ません。テキスト共有はここには入らず、データベースにあります。
定期的な確認で、すべてのバックエンドについて保存先の中身と記録を突き合わせ、どこからも参照されなくなったオブジェクトを消します。
保存先の種類はそれぞれコンパイル時のオプションで、公開イメージではすべて有効です。フォルダしか使わないインスタンス向けにソースからビルドするなら、次のようにします。
cargo build --no-default-features --features sqlite,storage-fs,email