Skip to content

This project has been created as part of the 42 curriculum by kamitsui.

Docker Infrastructure

Description

This project aims to broaden your knowledge of system administration by using Docker to virtualize several services. You will build a small infrastructure composed of different services using specific rules. The goal is to set up a complete infrastructure using Docker Compose, creating a personal Docker network where each service runs in a dedicated container.

The stack includes:

  • NGINX: Web server with TLS v1.2/v1.3.
  • WordPress: Setup with PHP-FPM, connected to MariaDB and Redis.
  • MariaDB: Database for WordPress.
  • Redis: Object cache for WordPress.
  • FTP Server (vsftpd): For file transfer to the WordPress volume.
  • Adminer: Database management tool.
  • Static Website: A bonus Node.js/VitePress website.
  • WAF (ModSecurity): Web Application Firewall on NGINX.

Instructions

Prerequisites

  • Docker Engine & Docker Compose
  • Make
  • Operating System: Linux (Debian/Ubuntu recommended)

Installation & Execution

  1. Clone the repository:

    bash
    git clone <repository_url> inception
    cd inception
  2. Setup Environment: Create a .env file in srcs/ or use the provided tools (if applicable) to populate secrets. (Note: Credentials are managed via secrets/ directory in dev environment)

  3. Build and Run: Use the Makefile to build and start the services.

    bash
    make

    This command will build the Docker images (Debian 12 / Alpine 3.22 base) and start the containers.

  4. Access Services:

    • WordPress: https://local.dev (Ensure local.dev map to localhost in /etc/hosts)
    • Adminer: https://local.dev/adminer
    • Static Website: https://local.dev/website
  5. Stop:

    bash
    make down
  6. Clean:

    bash
    make clean    # Remove containers and networks
    make fclean   # Remove images and volumes as well

Project Description & Architectural Choices

Docker and Containers

This project uses Docker to containerize services. Each service (Nginx, MariaDB, WordPress, etc.) runs in its own isolated container, defined by a custom Dockerfile. We use Debian 12 (Bookworm) and Alpine 3.22 as base images, strictly following the "penultimate stable version" requirement.

Design Choices

  • Docker Compose: Used to orchestrate the multi-container application.
  • ModSecurity: Implemented as a WAF module in Nginx for enhanced security.
  • Redis: Configured as an object cache to improve WordPress performance.
  • TLS: Self-signed certificates are used for HTTPS access.

Comparisons

Virtual Machines vs Docker

FeatureVirtual MachinesDocker (Containers)
IsolationHardware-level virtualization (Complete OS)OS-level virtualization (Shared Kernel)
Resource UsageHeavy (requires ensuring resources for full OS)Lightweight (uses host OS resources)
Boot TimeSlow (minutes)Fast (seconds)
PortabilityLess portable (large images)Highly portable (build once, run anywhere)

Secrets vs Environment Variables

  • Environment Variables: Easiest to use but can be insecure if leaked (e.g., via docker inspect). Suitable for non-sensitive config.
  • Secrets: Docker Secrets (or similar mechanisms) mount sensitive data (passwords, keys) as files into the container. This is more secure as the data is not exposed in the environment or command line history.

Docker Network vs Host Network

  • Docker Network (Bridge): Provides isolation. Containers communicate via a private internal network. Ports must be explicitly exposed/mapped. This is the default and used in Docker Infrastructure for security and isolation.
  • Host Network: The container shares the host's networking namespace. No isolation; the container uses the host's IP and ports directly. Faster performance but less secure and can cause port conflicts.

Docker Volumes vs Bind Mounts

  • Docker Volumes: Managed by Docker (/var/lib/docker/volumes/). Easier to back up, migrate, and manage via Docker CLI. Best for persisting data generated by containers (e.g., Database data).
  • Bind Mounts: Maps a specific file or directory on the host machine to the container. Dependent on the host's file system structure. We use this for development convenience (updating code without rebuilds) and persisting configuration/data as required by the subject (e.g., storing WP/DB data in /home/kamitsui/data/).

Resources

Documentation & References

AI Usage

AI tools (Google Gemini / Antigravity) were used in this project for:

  1. Code Assistance: Generating boilerplate for Dockerfiles and debugging configuration issues (e.g., Nginx config syntax).
  2. Documentation: Drafting and translating documentation files (README, Decision Logs).
  3. Troubleshooting: Analyzing error logs (e.g., MariaDB initialization errors, PHP version mismatches) and suggesting fixes.
  4. Optimization: Suggesting security improvements like WAF integration and best practices for Docker image size reduction.

Released under the MIT License.