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
Clone the repository:
bashgit clone <repository_url> inception cd inceptionSetup Environment: Create a
.envfile insrcs/or use the provided tools (if applicable) to populate secrets. (Note: Credentials are managed via secrets/ directory in dev environment)Build and Run: Use the Makefile to build and start the services.
bashmakeThis command will build the Docker images (Debian 12 / Alpine 3.22 base) and start the containers.
Access Services:
- WordPress:
https://local.dev(Ensurelocal.devmap to localhost in/etc/hosts) - Adminer:
https://local.dev/adminer - Static Website:
https://local.dev/website
- WordPress:
Stop:
bashmake downClean:
bashmake 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
| Feature | Virtual Machines | Docker (Containers) |
|---|---|---|
| Isolation | Hardware-level virtualization (Complete OS) | OS-level virtualization (Shared Kernel) |
| Resource Usage | Heavy (requires ensuring resources for full OS) | Lightweight (uses host OS resources) |
| Boot Time | Slow (minutes) | Fast (seconds) |
| Portability | Less 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
- Docker Documentation
- Docker Compose Specification
- NGINX Documentation
- Debian Packages
- Alpine Linux Packages
- Docker Infrastructure Documents : Project documentation built with VitePress, available when running the project.
AI Usage
AI tools (Google Gemini / Antigravity) were used in this project for:
- Code Assistance: Generating boilerplate for Dockerfiles and debugging configuration issues (e.g., Nginx config syntax).
- Documentation: Drafting and translating documentation files (README, Decision Logs).
- Troubleshooting: Analyzing error logs (e.g., MariaDB initialization errors, PHP version mismatches) and suggesting fixes.
- Optimization: Suggesting security improvements like WAF integration and best practices for Docker image size reduction.