ボリューム、ネットワーク、シークレットに関するDocker Compose変更レビュー用チェックリスト

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Docker Compose Change Review Checklist for Volumes, Networks, and Secrets - Zima Store Online

安全なアプローチでは、レンダリング済み設定のレビューと、データパス、ネットワーク到達性、シークレットを保護する可逆的なデプロイ確認を、単一のコマンドではなく、観測可能なゲートの連続として扱います。

ホームサーバー上の Docker Compose アプリケーションスタックでは、Compose の編集によって、永続ストレージ、接続性、シークレットの受け渡しが異なるコンテナが再作成される可能性があります。現在の識別情報と復旧ポイントを記録し、最も影響の少ない判別から始め、別の変数を変更する前に成功・失敗の結果を解釈し、ストレージが不安定になった場合や、復旧可能なコピーが公開されるしかない場合は中止します。以下のワークフローは、元のワークロードが正常に動作するか、証拠がエスカレーション境界に達した時点でのみ完了します。

レビュー前に有効な設定をレンダリングする

稼働中のデプロイで使用されている Compose ファイルセット、プロジェクト名、作業ディレクトリ、環境ファイル、プロファイル、イメージタグを固定します。シークレット値が公開されない経路で docker compose config を実行し、レンダリングされたモデルを安全に保存して、最後に正常だったデプロイと比較します。

Compose の動作は補間とマージされたファイルに依存するため、編集した YAML だけを確認すると、実際の変更を見落とす可能性があります。レンダリング済み Compose 設定のレビューでは、解決済みの設定を検証し、デプロイ計画を確認することを推奨しています。これにより、レビューは書式の確認からランタイム比較へと変わります。

変数が未設定の場合、プロジェクト名が予期せず変更された場合、イメージタグが記録済みのダイジェストなしで可変の場合、またはレンダリング済みファイルに認証情報が含まれている場合は中止します。pull、build、up コマンドを実行する前に、これらの条件を解決してください。

すべての永続ボリュームとバインドマウントを追跡する

各サービスについて、コンテナ側の保存先を名前付きボリュームまたはホストパスに対応付け、それが設定、データベースファイル、アップロード、キャッシュのいずれを保持しているかを特定し、想定される所有者でソースが存在することを確認します。相対パスには特に注意してください。作業ディレクトリが変わると、気付かないうちに新しい空のフォルダーを指す可能性があります。

明示的なボリューム名と external フラグを、現在の Docker ボリューム一覧と比較します。プロジェクト名が変わると、新しいプレフィックス付きボリュームが作成され、古いデータがそのまま残ることがあります。その結果、アプリケーションがリセットされたように見えます。再作成を許可する前に、状態を持つデータをバックアップし、現在のボリューム検査結果を記録してください。

アップグレード中に永続的なアプリ設定を保護する方法に関する ZimaSpace の関連記事では、アプリのアップグレードに伴う設定消失を扱っています。レビューによって永続的なアプリ状態が適切に分離されていなかったことが判明した場合に使用し、新しく作成されたボリュームへ不明なファイルをコピーして問題を隠さないでください。

ネットワーク、ポート、シークレットの受け渡しをレビューする

ネットワーク名、エイリアス、IP ファミリー、公開ポート、ホストバインディング、リバースプロキシの転送先を比較します。データベースが引き続き非公開であること、プロキシがアプリケーションのサービス名を解決できること、変更後に管理用ポートがすべてのインターフェースで公開されていないことを確認します。

各シークレットについて、値を記録せずに、そのソース、利用者、マウントパスまたは環境変数キー、ファイルモード、ローテーション担当者を記録します。新しい設定が既存の保護されたファイルまたは外部シークレットを参照していること、ログ、ビルド引数、ラベル、レンダリング済みの差分にシークレットが漏れていないことを確認します。

ネットワークまたはシークレットの変更は、意図した利用者がそれに到達または読み取りでき、意図しないピアがアクセスできない場合にのみレビューを通過します。変更に認証情報の同時ローテーションが必要な場合は、両方を1回の不可逆的な再起動にまとめず、併存フェーズと失効フェーズに分けてデプロイしてください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

再作成を段階的に行い、ロールバックを実証する

スタックを起動する前にイメージをプルし、提案されたサービス変更を確認します。復旧可能な時間帯にデプロイし、アーキテクチャ上可能であれば、まずリスクの低い依存サービスを1つ再作成して、先に進む前にヘルスチェック、ログ、マウント、DNS 解決、公開ソケットを監視します。

ログイン、1件のデータ読み取り、1件の使い捨て書き込み、バックグラウンドジョブ、リバースプロキシ経由のアクセスをテストします。スタックを1回再起動し、プロセスの再作成後もボリュームとシークレットの参照が維持されることを確認します。コンテナが単に running 状態を示しているだけで、変更を成功と判断しないでください。

受け入れ確認に合格するまで、以前の Compose ファイル、環境参照、イメージダイジェスト、データバックアップを保持します。アプリが空の状態で起動した場合、データベースが予期せずマイグレーションされた場合、シークレットが見つからない場合、または管理用ポートが公開された場合は、直ちにロールバックし、保存したレンダリング済み差分から調査してください。