Docker Environment¶
The Docker-based setup is tailored per project to allow full flexibility and control during both local development and production deployment. Each core service (PHP, Nginx, MySQL) is containerized with its own Dockerfile and configuration to ensure version control, customization, and stability.
Folder structure¶
project/
├── devops/
│ ├── dev/
│ │ ├── mysql/
│ │ │ ├── Dockerfile
│ │ │ └── my.cnf
│ │ ├── nginx/
│ │ │ ├── certs/
│ │ │ │ ├── site-local.pem
│ │ │ │ └── site-local-key.pem
│ │ │ ├── Dockerfile
│ │ │ └── default.conf
│ │ ├── php/
│ │ │ ├── Dockerfile
│ │ │ └── php.ini
│ │ └── node/
│ │ └── Dockerfile
│ │
│ └── prod/
│ ├── bash/
│ │ └── deployment-script.sh
│ ├── mysql/
│ │ ├── Dockerfile
│ │ └── my.cnf
│ ├── nginx/
│ │ ├── Dockerfile
│ │ └── default.conf
│ ├── php/
│ │ ├── Dockerfile
│ │ └── php.ini
│ └── node/
│ └── Dockerfile
│
├── docker-compose.yml
├── docker-compose.override.yml
└── .env
Environment separation: dev vs prod¶
The environment is structured with two clearly separated layers:
| Environment | Purpose | Path |
|---|---|---|
dev | Local development | devops/dev/ |
prod | Production deployment | devops/prod/ |
This separation provides:
- Safe customization during development without affecting production containers.
- Each service (
php,nginx,mysql,node, etc.) has its own Dockerfile for bothdevandprod. - Developers can tweak local files (e.g., add tools, debugging utilities).
- Production images remain stable, minimal, and optimized for live deployment.
Services¶
| Service | Description | Doc |
|---|---|---|
| PHP | Backend application server | PHP Container |
| Nginx | Web server and reverse proxy | Nginx Container |
| MariaDB | Relational database | MariaDB |
| Node.js | Asset compilation (watch mode) | Node.js Container |
See Configuration for environment variables, build arguments, and local overrides.
Deployment model¶
Each deployment creates a new timestamped release folder. Docker containers always mount a symlinked current/ directory rather than the release folder directly. The deployment script updates the symlink atomically after a successful build, so the running containers never need to be restarted to pick up a new release.
This separation means:
- Container restarts do not affect the active deployment.
- Rolling back is a symlink swap — no container rebuild required.
- Deployment logic is fully isolated from runtime.