Composeファイル、シークレット、永続データを分離して再現可能なアプリスタックを構築する方法

バージョン管理されたCompose定義、保護されたシークレット、独自のバックアップおよび復元経路を持つ永続データという、3つの資産を軸にスタックを構築します。

家庭や小規模チームのサーバーでは、オペレーティングシステムとコンテナーは置き換え可能であるべきです。Composeプロジェクトで必要なサービスを定義し、デプロイ時にシークレット管理システムから認証情報を渡し、名前付きのデータパスで状態を保持します。障害が発生したマシンの外部に保存された記録から、この3つの役割をクリーンなホスト上で再構成できて初めて、復旧に成功したと言えます。

Composeファイルを書く前に再構築の境界を定義する

ホストOS、コンテナーランタイム、ダウンロード済みイメージは置き換え可能なものとして扱います。Composeファイル、カスタム設定、認証情報、データベース、アップロードデータ、証明書、暗号化キーは、それぞれの実際の復旧上の役割に応じて扱います。

サービスごとに、イメージとバージョン、ポート、依存関係、シークレット名、永続データのパス、バックアップ方法、復元の検証を1行にまとめた一覧を作成します。この一覧により、コンテナーファイルシステム内に隠れてしまう状態を把握できます。

アプリケーションが書き込み可能なコンテナーレイヤーに置き換え不能なデータを保存している場合は、作業を中断します。スタックを再現可能とみなす前に、そのパスを明示的なボリュームまたはバインドマウントに移してください。

シークレットをコミットせずに定義をバージョン管理する

Composeファイル、機密情報を含まない設定、ヘルスチェック、デプロイに関するメモをバージョン管理します。更新ポリシーに従ってイメージのバージョンまたはダイジェストを固定し、再ビルド時に別のアプリケーションリリースが予期せず選択されないようにします。

実際のパスワード、APIキー、秘密証明書をComposeファイルやリポジトリに記載しないでください。Dockerシークレットをソースの外で管理する方法についての実践的な解説では、認証情報に別の受け渡し経路が必要な理由を説明しています。

プレースホルダーを使ったシークレット名の一覧をコミットし、値は暗号化されたパスワードマネージャー、ファイル、または独立して復元できるシークレット管理サービスに保管します。

永続データの所有者とパスを明確にする

各アプリケーションのデータベース、ユーザーのアップロードデータ、生成キャッシュ、差し替え可能なサムネイルをそれぞれ分離します。永続化が必要なデータをバックアップし、不要なデータまで大量に復元しないよう、再生成可能なキャッシュを文書に記録します。

安定した読みやすいホストパス、または慎重に文書化された名前付きボリュームを使用します。クリーンなホストが古いローカルユーザーのデータベースに依存しないよう、権限は数値IDまたは初期化手順で指定してください。

データベースでは、稼働中のファイルをむやみにコピーせず、論理ダンプまたはアプリケーション整合性のあるスナップショットを作成します。スタックが壊れても唯一のバックアップが消えないよう、ダンプの保存先はアプリケーションボリュームの外にします。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

可逆的なデプロイとして更新を設計する

更新前に、現在のComposeリビジョン、イメージ識別子、設定、および変更された状態の最新の復元可能なコピーを取得します。アプリケーションがデータベースも移行する場合、新しいイメージをプルするだけではロールバック計画になりません。

セルフホスティングの手順では、Composeによって複数コンテナの定義と運用コマンドを一元管理する方法を紹介しています。状態と認証情報を破棄可能なレイヤーの外に保ちながら、Composeベースのデプロイパターンを活用してください。

依存関係グループを1つずつ更新し、ヘルスチェックとログイン確認を実行してから、正常動作が確認されたリビジョンを記録します。ロールバックに古いデータベース形式が必要な場合は、別のパスに復元して切り替え前に検証します。

クリーンな復旧ホストでスタックを検証する

使い捨てVMまたは予備のマシンを使用します。文書化された前提条件のみをインストールし、定義をクローンして、承認済みのチャネルからシークレットを復元し、1つのアプリケーションのデータを復元してから、依存関係の順に起動します。

コンテナのステータスだけでなく、サインイン、既知のレコードの読み取り、テスト項目の作成と削除、ホストの再起動を行い、バックアップ監視で新しい保存先が報告されることを確認します。文書化されていない手動修正はすべて、ビルドプロセスの不具合として記録してください。

認証情報の受け渡し方法を選ぶ際は、ZimaSpaceガイドに従ってDockerシークレットをComposeファイルから分離してください。

最終セットアップルール

セットアップが合格となるのは、まっさらなホストでサービス定義を再現し、リポジトリに公開せずにシークレットを受け取り、永続データを復元し、アプリケーションレベルの検証を完了できる場合です。複数のホストで同じ管理されたワークフローが必要になった場合にのみ、オーケストレーションへ移行しましょう。