naoufal101/inception-docker

1. This repository defines a containerized WordPress stack with Docker Compose as the orchestration layer. The top-level architecture is split between declarative runtime wiring in srcs/docker-compose.yaml, environment configuration in srcs/.env, and sensitive credentials stored as files under secrets/.

2. The core request path is: client/browser → Nginx container → WordPress container → MariaDB container. Nginx is the public entrypoint on the host; WordPress runs the PHP application layer; MariaDB is the persistent backing database. This is the primary dependency chain to show in an architecture diagram.

3. The services are isolated by Docker networking rather than host networking. Container-to-container communication happens through service names on a private Compose network, while only the externally exposed edge service(s) need host port mapping. This network boundary is a key part of the design.

4. Persistence is handled with Docker volumes rather than bind mounts for runtime data. The repository’s stated stateful assets are the database volume and the WordPress files volume, which preserve application state across container rebuilds and restarts. Configuration, by contrast, is kept in the repository as mounted config files so it can be edited without rebuilding everything.

5. Security-sensitive values are not stored in environment variables. Passwords are read from files in secrets/, while non-sensitive deployment parameters live in srcs/.env. Nginx also handles TLS certificate generation/usage, with support for either a provided root CA flow or a fallback self-signed certificate.

6. Each major service has its own Dockerfile, config directory, and startup script under srcs/requirements/. That means the repository is organized as service-specific build contexts rather than one shared image. The per-service entrypoint scripts are the boundary where container bootstrapping happens.

7. MariaDB is a self-contained database subsystem with its own config (Md.cnf) and entrypoint logic. It is the authoritative data store for WordPress and is the most important persistent backend in the stack. In a diagram, this should be shown as stateful and isolated from direct client access.

8. WordPress is the application subsystem. It is configured through environment variables and a CGI-related config file, and it depends on MariaDB plus, in the bonus setup, Redis for caching. Its role is to initialize and run the CMS logic rather than serve public traffic directly.

9. Nginx is the reverse proxy and TLS termination layer. It fronts the WordPress app, serves HTTPS, and is the only standard web-facing component in the main stack. This is the layer where certificate handling and HTTP-to-application routing belong in the diagram.

10. The bonus subtree adds optional, mostly auxiliary services that are not on the critical path:

• Redis for caching support.

• Redis Commander as a web UI for Redis inspection.

• Adminer as a database administration UI.

• FTP as a file-transfer interface.

• A custom website service implemented in Go, serving static content from public/.

11. These bonus services are separate containers with their own Dockerfiles and configs, so they should be drawn as parallel service boxes rather than dependencies of the core WordPress flow. Adminer and Redis Commander are operational tools; FTP is a content-management side channel; the custom website is a separate application example.

12. The repository is infrastructure-first rather than application-first. The Makefile wraps Compose lifecycle commands, and the documentation emphasizes reproducible builds, service isolation, volume-backed state, and secrets management. For an architecture diagram, the central elements are the Compose orchestrator, the private network, the persistent volumes, the secrets boundary, and the main traffic path through Nginx to WordPress and MariaDB.