⚓ Inception — Docker Orchestration (42 Project)

Full stack service orchestration using Docker and Docker Compose following 42's Inception requirements.

Hands-on mastery of containerization, networking, persistent volumes, and basic monitoring

About · Services · Usage · What I Learned

---

💡 About the project

Inception is a systems/devops-focused project in the 42 curriculum where the goal is to design, build, and deploy a small production-like environment using Docker. The emphasis is on reproducible infrastructure: containers are defined with Dockerfiles, composed with docker-compose, connected via user networks, and persisted via volumes. Services must be reachable through a reverse proxy (with proper routing and optional HTTPS), and the whole stack must be able to start reliably on a fresh machine.

This repository contains a complete Inception setup, with reusable Dockerfiles, a docker-compose configuration, helper scripts for building and tearing down the stack, and notes for deploying and debugging.

---

🧩 Services

Below are the typical services included in the project and short descriptions of their roles and constraints.

---

🟩 Reverse Proxy (Nginx)

Acts as the single entrypoint for HTTP/HTTPS traffic. Reverse proxy configuration routes requests to the appropriate backend (WordPress, phpMyAdmin, etc.), handles static assets, and can be extended to terminate TLS (Certbot) or forward to a TLS terminator.

---

🟩 Database (MySQL / MariaDB)

Persistent relational database used by WordPress and other services. Configured with secure credentials, a persistent volume, and appropriate initialization scripts. Backups and restoration procedures are documented.

---

🟩 WordPress (PHP-FPM + PHP)

A simple PHP application representing the "app" layer. Runs in its own container, connects to the database, and is served through the reverse proxy. Built from a custom Dockerfile to control PHP extensions and file permissions.

---

🛠️ Usage

Each service and the whole stack can be built and controlled via the Makefile and docker compose.

1. Copy the example environment and set passwords / domain:

cp .env.example .env create secrets directory with secrets in srcs directories
# edit .env to set MYSQL_ROOT_PASSWORD, MYSQL_USER, MYSQL_PASSWORD, DOMAIN, etc.

2. Build and start the entire stack:

make build
make up
# or (docker compose)
docker compose up -d --build

3. Stop and remove containers (preserve volumes if desired):

make down
# or with docker compose
docker compose down

4. Full cleanup (remove volumes and images):

make clean

5. View logs:

docker compose logs -f nginx wordpress mysql

6. Access:

• Reverse proxy: http://localhost or https://
• WordPress: http(s)://
• phpMyAdmin: http(s):///phpmyadmin (if enabled)
• Grafana: http(s)://:3000 (or routed via proxy)

Notes:

• All persistent data lives in named Docker volumes (see docker-compose.yml).
• Healthchecks are included where relevant for reliable orchestration.
• The reverse proxy config demonstrates routing and header forwarding; TLS is optionally handled by Certbot or manually-provided certificates.

---

🧭 Project structure (high level)

• docker-compose.yml — service definitions, networks, volumes
• nginx/ — nginx configuration and Dockerfile (if building custom image)
• wordpress/ — Dockerfile, php configuration, entrypoint scripts
• mysql/ — initialization scripts and volume mappings
• ftps/ — FTPS server Dockerfile and configuration
• monitoring/ — Telegraf, InfluxDB, Grafana configs and dashboards
• .env.example — environment variables template
• Makefile — convenience targets: build, up, down, clean, logs, ps
• docs/ — deployment notes, backup & restore, troubleshooting

---

📚 What I Learned

• Containerization fundamentals: Dockerfiles, images, layers, and best practices
• Service composition with docker compose — networks, depend_on, and orchestration caveats
• Designing for persistence: volumes, init scripts, and safe data handling
• Reverse proxy configuration and HTTP routing strategies
• Debugging containerized apps: logs, exec'ing into containers, and common permission pitfalls

---

📝 Notes & Tips

• Always keep secrets out of version control. Use .env files, Docker secrets, or a vault for production.
• Use named volumes for persistent data; document backup/restore steps for each volume.
• Test service restarts and full stack reboots to ensure data and configuration survive.