Files
laboratori-cloud/.planning/phases/06-lab-05-database-rds/06-RESEARCH.md
Luca Sacchi Ricciardi 2f56df4dc3 docs(06): create Phase 6 plans for Lab 05 Database & RDS
- 06-PLAN.md: Combined execution plan (test + docs + infra)
- 06-RESEARCH.md: Domain research on PostgreSQL, RDS parallels

Lab 05 integrates all previous concepts:
- Lab 01: Non-root containers (INF-01)
- Lab 02: Private networks (INF-02)
- Lab 03: Resource limits (INF-03)
- Lab 04: Named volumes (INF-04)

Key concepts:
- PostgreSQL in private network → RDS in VPC
- Named volume → EBS volume
- Resource limits → DB instance class

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-04-03 17:38:17 +02:00

122 lines
3.2 KiB
Markdown

# Research: Lab 05 - Database & RDS
**Objective:** Simulate AWS RDS (Relational Database Service) using PostgreSQL in Docker private network.
---
## Domain Research
### PostgreSQL in Docker
**Official Image:** `postgres:16-alpine`
- Lightweight Alpine-based PostgreSQL
- Default port: 5432
- Environment variables for configuration:
- `POSTGRES_DB`: Database name
- `POSTGRES_USER`: Username
- `POSTGRES_PASSWORD`: Password
- `POSTGRES_INITDB_ARGS`: Initialization arguments
**Healthcheck:** `pg_isready` command
- Tests if PostgreSQL is ready to accept connections
- Returns 0 if ready, non-zero if not ready
### RDS Concepts
**AWS RDS Features:**
- Managed database service
- Deployed in VPC private subnets
- Automated backups (not simulating in lab)
- Multi-AZ deployment (not simulating in lab)
- Resource limits (instance classes)
- Encryption at rest (not simulating in lab)
**Instance Classes (for PARALLELISM):**
- db.t2.micro: 1 vCPU, 1 GB RAM
- db.t2.small: 1 vCPU, 2 GB RAM
- db.t2.medium: 2 vCPU, 4 GB RAM
### Integration with Previous Labs
**Lab 01 (IAM):** Non-root containers
- PostgreSQL container must NOT run as root
**Lab 02 (Network):** Private networks
- Database must be in private network
- NO ports exposed on host
**Lab 03 (Compute):** Resource limits
- PostgreSQL must have CPU/memory limits
**Lab 04 (Storage):** Named volumes
- Database data must persist in named volume
---
## Common Pitfalls
1. **Database accessible from host**
- Must NOT expose ports on host
- Only accessible from containers in same private network
2. **Data loss on container restart**
- Must use named volume for data directory
- Volume must persist across container lifecycle
3. **Running as root**
- PostgreSQL image runs as postgres user by default
- Must verify non-root execution
4. **No resource limits**
- Must configure cpus and memory limits
- Prevents database from consuming all host resources
---
## Testing Strategy
### RED Phase Tests (Plan 06-01)
1. **Database Creation Test**
- Verify container starts successfully
- Verify database is initialized
- Verify pg_isready works
2. **Private Network Test**
- Verify database is in private network
- Verify NOT accessible from host
- Verify accessible from same network
3. **Persistence Test**
- Create test data
- Stop container
- Start container
- Verify data still exists
4. **Security Test**
- INF-01: Non-root user
- INF-02: No host port bindings
- INF-03: Resource limits
- INF-04: Named volume
### GREEN Phase Implementation (Plan 06-03)
- docker-compose.yml with PostgreSQL in private network
- Named volume for data persistence
- Resource limits for CPU/memory
- Healthcheck configuration
- No host port bindings (INF-02)
---
## Cloud Parallels (PARA-01/02/03/04)
| Local Concept | AWS Equivalent | Parallel |
|---------------|----------------|----------|
| PostgreSQL container | RDS Instance | Managed database |
| Private network | VPC Private Subnet | Isolated deployment |
| Named volume | EBS volume | Data persistence |
| Resource limits | Instance class | Compute allocation |
| No root access | AWS IAM authentication | Access control |
| pg_isready | RDS health check | Availability check |