CASE STUDY · 1337 / 42 validated project
Inception
A Docker Compose infrastructure project connecting NGINX with TLS, WordPress with PHP-FPM, and MariaDB.
- Role
- 1337 / 42 Developer
- Access
- 1337 / 42 validated project
Context
A Docker Compose infrastructure project connecting NGINX with TLS, WordPress with PHP-FPM, and MariaDB. Each service is built from its own Dockerfile and coordinated through an isolated network and persistent volumes.
My responsibility
Built and validated through the 1337 / 42 project curriculum, with direct responsibility for implementation, debugging, testing, and evaluation requirements.
System scheme
Engineering scheme
Containerized web service topology
A TLS entry point, application runtime, and database run as separately built services with isolated networking and persistent storage.
- 01
Docker build
Build each service from an approved base image and explicit configuration.
- 02
NGINX gateway
Terminate TLS and forward FastCGI traffic to the application.
- 03
WordPress runtime
Run PHP-FPM and initialize application configuration.
- 04
MariaDB
Initialize credentials, schema, users, and persistent database state.
- 05
Private network
Resolve service names without exposing internal ports.
- 06
Persistent volumes
Retain database and application files across replacement.
Implementation breakdown
- 01
System design
Three containerized services communicate over a private Docker network. NGINX is the public entry point, while named volumes preserve application and database data.
Technical scope
Implementation details
- ✓TLS-enabled NGINX routing to the WordPress FastCGI service.
- ✓Persistent volumes that retain application and database data across container replacement.
Engineering constraints
- →Building service images from approved base distributions instead of application-ready images.
- →Coordinating initialization order and readiness across dependent containers.
Project gallery
Need a system like this?
Tell me about the workflow, integration, or backend problem.