Redmineの設定

VPS-ROOT環境 障害原因分析と構成管理改善提案

🔍 障害発生の根本原因¶

1. 設定ファイル管理の分散化¶

• 問題: /root/nginx-proxy/conf.d/ vs /etc/nginx/conf.d/ の二重管理
• 結果: 設定ファイルが正しい場所にコピーされていない状態

2. Docker ボリュームマウントの複雑性¶

• 実際のマウント: /etc/nginx/conf.d ← 直接マウント
• 誤解: /root/nginx-proxy/conf.d/ が有効と思い込み
• 結果: 設定変更が反映されない

3. 古い設定ファイルの残存¶

• 具体例: facty.call2arm.com.sni.conf (古い127.0.0.1:8080設定)
• 影響: 意図しないデフォルトサーバーとして動作

🏗️ インフラ構成の実態¶

実際の構成¶

nginx-proxy (コンテナ)
├── 直接マウント: /etc/nginx/conf.d ← 実際に使用される設定
├── 設定ファイル: facty.call2arm.com.sni.conf (古い設定)
└── DNSリゾルバー: 未設定 → コンテナ名解決不可

/root/nginx-proxy/ (ホスト側)
├── conf.d/ ← 管理用だが実際は未使用
├── docker-compose.yml
└── nginx.conf

誤解していた構成¶

nginx-proxy ← /root/nginx-proxy/conf.d/ が直接反映される

🔄 なぜ今まで動いていたのか？¶

1. 初期セットアップ時: 正しい場所に設定ファイルが配置されていた
2. 段階的な変更: 一部設定が /root/nginx-proxy/conf.d/ に保存されるも反映されず
3. 古い設定の残存: 以前動作していた設定が継続使用されていた

💡 構成管理改善提案¶

1. 設定ファイル管理の統一¶

• 単一ソース: /root/nginx-proxy/conf.d/ を管理用とする
• 自動同期: スクリプトによる /etc/nginx/conf.d/ への自動コピー
• バージョン管理: Git による設定変更履歴管理

2. Docker Compose 改善¶

volumes:
  - /root/nginx-proxy/conf.d:/etc/nginx/conf.d:ro
  - /root/nginx-proxy/nginx.conf:/etc/nginx/nginx.conf:ro

3. 監視・検証機構¶

• 設定検証: nginx -t の定期実行
• サービス監視: ヘルスチェック強化
• ログ監視: 502エラーの早期検出