Skip to content

このプロジェクトは、「人生、宇宙、すべての答えを探すコードの旅」の一部として kamitsui によって作成されました。

Docker Infrastructure

概要 (Description)

このプロジェクトは、Dockerを使用して複数のサービスを仮想化することで、システム管理の知識を広げることを目的としています。特定のルールに従って、異なるサービスで構成される小さなインフラストラクチャを構築します。目標は、Docker Composeを使用して完全なインフラストラクチャをセットアップし、各サービスが専用のコンテナで実行される個人のDockerネットワークを作成することです。

スタックには以下が含まれます:

  • NGINX: TLS v1.2/v1.3対応のWebサーバー。
  • WordPress: PHP-FPMでセットアップされ、MariaDBとRedisに接続されています。
  • MariaDB: WordPress用のデータベース。
  • Redis: WordPress用のオブジェクトキャッシュ。
  • FTP Server (vsftpd): WordPressボリュームへのファイル転送用。
  • Adminer: データベース管理ツール。
  • Static Website: ボーナスのNode.js/VitePressウェブサイト。
  • WAF (ModSecurity): NGINX上のWebアプリケーションファイアウォール。

手順 (Instructions)

前提条件

  • Docker Engine & Docker Compose
  • Make
  • オペレーティングシステム: Linux (Debian/Ubuntu 推奨)

インストールと実行

  1. リポジトリのクローン:

    bash
    git clone <repository_url> inception
    cd inception
  2. 環境セットアップ: srcs/.env ファイルを作成するか、提供されたツール(該当する場合)を使用してシークレットを設定します。 (注:開発環境では、認証情報は secrets/ ディレクトリで管理されます)

  3. ビルドと実行: Makefileを使用してサービスをビルドおよび起動します。

    bash
    make

    このコマンドは、Dockerイメージ(Debian 12 / Alpine 3.22 ベース)をビルドし、コンテナを起動します。

  4. サービスへのアクセス:

    • WordPress: https://local.dev (/etc/hostslocal.dev を localhost にマッピングしてください)
    • Adminer: https://local.dev/adminer
    • Static Website: https://local.dev/website
  5. 停止:

    bash
    make down
  6. クリーンアップ:

    bash
    make clean    # コンテナとネットワークを削除
    make fclean   # イメージとボリュームも削除

プロジェクトの説明とアーキテクチャの選択

Dockerとコンテナ

このプロジェクトでは、サービスをコンテナ化するためにDockerを使用しています。各サービス(Nginx, MariaDB, WordPressなど)は、カスタム Dockerfile で定義された独自の分離されたコンテナで実行されます。 ベースイメージとして Debian 12 (Bookworm)Alpine 3.22 を使用し、「最後から2番目の安定版 (penultimate stable version)」という要件を厳守しています。

設計上の選択

  • Docker Compose: マルチコンテナアプリケーションのオーケストレーションに使用。
  • ModSecurity: セキュリティ強化のためにNginxのWAFモジュールとして実装。
  • Redis: WordPressのパフォーマンスを向上させるためのオブジェクトキャッシュとして構成。
  • TLS: HTTPSアクセスには自己署名証明書を使用。

比較

Virtual Machines vs Docker

機能Virtual Machines (仮想マシン)Docker (コンテナ)
分離ハードウェアレベルの仮想化(完全なOS)OSレベルの仮想化(カーネル共有)
リソース使用量重い(完全なOS分のリソースが必要)軽量(ホストOSのリソースを使用)
起動時間遅い(数分)速い(数秒)
移植性低い(イメージサイズが大きい)非常に高い(一度ビルドすればどこでも実行可能)

Secrets vs Environment Variables

  • 環境変数: 最も使いやすいですが、漏洩した場合(例:docker inspect経由)に安全ではありません。機密でない設定に適しています。
  • Secrets: Docker Secrets(または同様のメカニズム)は、機密データ(パスワード、キー)をファイルとしてコンテナにマウントします。データが環境やコマンドライン履歴に露出しないため、より安全です。

Docker Network vs Host Network

  • Docker Network (Bridge): 分離を提供します。コンテナはプライベートな内部ネットワークを介して通信します。ポートは明示的に公開/マッピングする必要があります。これはデフォルトであり、Docker Infrastructureではセキュリティと分離のためにこれを使用しています。
  • Host Network: コンテナはホストのネットワーク名前空間を共有します。分離はなく、コンテナはホストのIPとポートを直接使用します。パフォーマンスは高速ですが、セキュリティが低く、ポート競合が発生する可能性があります。

Docker Volumes vs Bind Mounts

  • Docker Volumes: Dockerによって管理されます(/var/lib/docker/volumes/)。バックアップ、移行、Docker CLIによる管理が容易です。コンテナによって生成されたデータ(例:データベースデータ)の永続化に最適です。
  • Bind Mounts: ホストマシンの特定のファイルまたはディレクトリをコンテナにマップします。ホストのファイルシステム構造に依存します。開発の利便性(リビルドなしでのコード更新)や、課題で要求される設定/データの永続化(例:/home/kamitsui/data/ へのWP/DBデータの保存)に使用しています。

リソース

ドキュメントと参照

AIの使用について

このプロジェクトでは、以下の用途でAIツール(Google Gemini / Antigravity)を使用しました:

  1. コード支援: Dockerfileのボイラープレート生成や設定上の問題(例:Nginx設定構文)のデバッグ。
  2. ドキュメント: ドキュメントファイル(README, 決定ログ)のドラフト作成と翻訳。
  3. トラブルシューティング: エラーログ(例:MariaDB初期化エラー、PHPバージョン不整合)の分析と修正案の提示。
  4. 最適化: WAF統合などのセキュリティ改善やDockerイメージサイズ削減のベストプラクティスの提案。

Released under the MIT License.