アプリデータを失わずにコンテナイメージをロールバックできますか？

はい、永続状態がコンテナの外部に保存され、古いバージョンとの互換性が保たれている場合は、アプリデータを失わずにコンテナイメージをロールバックできます。

ホームNASでは、通常、イメージを置き換えて再作成されるのはアプリケーションの実行環境だけです。一方、名前付きボリュームやバインドマウントには、データベース、設定、ユーザーファイルが保持されます。危険な境界となるのはスキーマの変更です。新しいイメージがデータベースを移行したり、古いイメージでは読み取れない形式に設定を書き換えたりする可能性があります。ロールバック前に、現在のマウント、イメージの識別情報、設定、シークレット、整合性のあるデータバックアップを取得してください。

イメージを変更する前に現在の状態を凍結する

イメージの自動更新を停止し、現在のイメージタグ、イミュータブルダイジェスト、コンテナ設定、環境変数、ネットワーク、ポート、マウント、再起動ポリシー、ヘルスチェックを記録します。Composeファイルまたはエクスポートした設定は、コンテナとは別に保存してください。

NASコンテナのロールバック手順では、変動する latest タグに頼るのではなく、既知の以前のイメージを利用できる状態にしておくことが推奨されます。使用可能な復旧ポイントは、実行に使用した設定と特定の以前のイメージバージョンの組み合わせです。

新しいバージョンを停止する前に、アプリケーションと整合性のあるデータベースバックアップまたはスナップショットを取得してください。既存のボリュームがロールバック用のコピーになるとは限りません。更新によってスキーマやデータがすでに変更されている可能性があるためです。

アプリデータが書き込み可能レイヤーの外部にあることを確認する

すべての名前付きボリュームとバインドマウントを対応付け、データベース、アップロードファイル、プラグイン、証明書、キャッシュ、設定がコンテナの書き込み可能レイヤーだけに保存されていないか確認します。

永続ストレージがコンテナの置き換え後も保持されるのは、新しいコンテナが同じ外部データ保存先に再接続された場合だけです。SynoForumのイメージバージョン手順でも、別のイメージからコンテナを再作成する前に、ボリュームデータがNASストレージ上に保持されていることを明示的に確認しています。

重要なデータが書き込み可能レイヤーにしか存在しない場合は、現在のコンテナを削除する前にコピーまたはエクスポートしてください。この抽出は復旧手順として扱い、バージョン管理されていないコンテナを無期限に使い続ける理由にはしないでください。

latestを再利用せず、正確な古いイメージを固定する

最後に正常動作していたタグまたはダイジェストを取得または確認し、変更するのはイメージ参照だけにします。サービスを再作成する前に、アーキテクチャ、アプリケーションのエディション、必要な環境変数を確認してください。

Composeで管理されるサービスをロールバックする場合、Dockerに実行中のコンテナをその場で逆戻りさせるよう求めるのではなく、通常は以前の明示的なイメージバージョンに戻します。実用的なロールバック手順では、固定したComposeイメージタグを変更してサービスを再作成します。

正体の分からない古いキャッシュ済みイメージは使用しないでください。取得後にダイジェストを記録し、同じ変更可能なタグの下で別のバイナリが暗黙的に選択されないようにします。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

新しいバージョンでデータベースが変更されたか確認する

ロールバック先のバージョンから現在のイメージまでの各バージョンについて、アプリケーションのリリースノートと移行ログを確認します。不可逆的なスキーマ変更、書き換えられた設定、暗号化キーの変更、プラグインのアップグレードがないか調べてください。

アプリケーションのコードとスキーマには互換性が必要なため、データベースのロールバックはイメージのロールバックより困難です。Octopusは、古いバージョンと新しいバージョンのアプリケーションが共存または逆戻りする可能性がある場合、後方互換性のある移行が必要だと説明しており、バージョン間のスキーマ互換性がロールバックの可否を決める境界になります。

古いイメージで移行済みのデータベースを読み取れない場合は、新しい状態を古いコードに接続するのではなく、アップグレード前のデータベースバックアップを復元してください。ロールバック自体を取り消す必要が生じた場合に備え、現在のデータベースは別途保持します。

同じ永続パスを使用してサービスを再作成する

確認済みの同じ名前付きボリュームまたはバインドマウントを保持したまま、アプリケーションコンテナを停止して古いイメージで再作成します。ボリュームを削除するコマンドやUIオプションは使用しないでください。

古いバージョンで文書化された変更が必要な場合を除き、ネットワーク名、サービスエイリアス、公開ポート、UID/GIDマッピング、シークレット、リバースプロキシの接続先は一貫性を保ってください。マウント先を間違えたままコンテナが正常に起動すると、新しく空のアプリが作成され、データが失われたように見えることがあります。

ログインしたりバックグラウンドジョブを実行させたりする前に、マウント一覧とアプリケーションログを確認します。アプリが新しいデータベースを初期化した場合は、すぐに停止し、誤った場所にインポートするのではなくデータパスを修正してください。

ロールバックを検証し、前方復旧の手段を維持する

ログイン、データベースの読み書き、アップロード、スケジュール済みジョブ、連携機能、制御された再起動を1回テストします。レコードとファイルの一部を、ロールバック前の一覧と比較してください。

ZimaSpaceの更新前のアプリデータスナップショットに関する手順は、今後のアップグレードに向けたより安全な準備方法を示しています。

古いイメージが意図した永続データを使用し、スキーマに互換性があるか復元済みで、サービスが再度の再作成後も動作して初めて、ロールバックは完了です。古いバージョンが通常の運用期間を通じて安定するまで、新しいイメージ、そのデータバックアップ、ロールバックの記録を保持してください。