インスタンスをアップグレードする
KolleKのアップグレードは、あえて退屈な作業になるように設計されています。新しいバージョンを取得し、再ビルドすれば完了です。このページでは、それが安全である理由と、アップグレード後に知っておくべき唯一の手順を説明します。
アップグレードでデータが失われない理由
アップグレードの流れが安全なのは、2つの性質によるものです。
- データは名前付きボリュームに保存されている。 データベース用の
db-data、ファイル用のstorage-dataは、コンテナやイメージから独立しています。コンテナを再ビルドしても、これらには影響しません。 - マイグレーションは前方向にのみ進む。 webコンテナは起動時に
migrate --forceで未適用のデータベースマイグレーションを適用しますが、KolleKがデータをリセットしたり破壊的に書き換えたりするマイグレーションを配布することはありません。アップグレードはスキーマに追加を行うだけです。
アップグレードの手順
インスタンスをバックアップ・復元するで説明されている通り、データベースのダンプとストレージのアーカイブを取得します。アップグレード自体は設計上安全ですが、バックアップがあることで「設計上安全」が「文句なしに安全」になります。
リポジトリのディレクトリから、アップグレード先のリリースを取得します。
git pull
docker compose up -d --build
Composeがイメージを再ビルドし、コンテナを再作成します。起動時にwebコンテナが新しいマイグレーションを自動的に適用し、その後インスタンスは元のAPP_URLで再び動作します。
マイグレーションを手動で制御したい場合は、Dockerでインストールで説明されている通り、RUN_MIGRATIONS=falseを設定し、手順の一部として自分でdocker compose exec app php artisan migrate --forceを実行してください。
写真検索インデックスの手順
あるアップグレードには、一度きりのメンテナンス作業が含まれます。写真ライブラリ画面が登場する前から存在するインスタンスは、写真検索インデックスを一度構築する必要があります。行わないと、既存の写真については検索結果が空のままになります。
docker compose exec app php artisan photos:rebuild-search-index
このコマンドは冪等であり、どのインスタンスで実行しても安全なので、迷ったら実行してください。また、寸法が記録される前にアップロードされた写真についても、画像の寸法をさかのぼって補完します。
アカウント検索インデックスの手順
アカウント全体の検索は独自のインデックスを読みます。マイグレーションが作るのはテーブルだけで、中身を埋めるのは再構築コマンドだけです。そのため既存のインスタンスでは、一度実行するまで検索は何も見つけません。
docker compose exec app php artisan search:rebuild-index
すべてのアカウントのすべてのレコードをたどるため、規模の大きなインスタンスでは少し時間がかかります。それ以降、インデックスはレコードの変更に合わせて自動的に最新に保たれます。アカウント全体を検索するを参照してください。
アップグレードの一環としてAPP_KEYを変更しないでください。このキーはどのバージョンよりも長く使い続けるものです。もしアップグレード手順が新しいキーを求めているように見えたら、それは読み間違いです。アプリケーションキーと暗号化を参照してください。
次に読むべきもの
- すべてのアップグレードがそこから始められるよう、バックアップを最新に保ちましょう。
- schedulerコンテナが復旧すると自動的に再開する夜間メンテナンスジョブを確認しましょう。