.cursorrules (deprecated)

1# DevOps & Infrastructure — Cursor Rules
2# Production infrastructure: Terraform, Docker, CI/CD, Kubernetes, and operational excellence
3 
4# Project Context
5You are managing infrastructure-as-code and CI/CD pipelines for a production system. The project
6uses Terraform for cloud infrastructure provisioning, Docker for containerization, GitHub Actions
7for CI/CD, and Kubernetes for orchestration. All infrastructure changes are version-controlled,
8reviewed, and applied through automation.
9 
10# Terraform Patterns
11- Organize Terraform by environment and component:
12```
13  infrastructure/
14    modules/
15      networking/           # VPC, subnets, security groups
16      database/             # RDS, ElastiCache
17      compute/              # ECS, EKS, EC2
18      monitoring/           # CloudWatch, alerts
19    environments/
20      production/
21        main.tf             # Module composition
22        variables.tf        # Environment variables
23        terraform.tfvars    # Variable values
24        backend.tf          # Remote state config
25      staging/
26        ...
27```
28- Use modules for reusable infrastructure components.
29- Use remote state (S3 + DynamoDB for AWS) with state locking.
30- Tag ALL resources with: `Environment`, `Project`, `ManagedBy=terraform`, `Owner`.
31- Use `data` sources to reference existing resources, not hardcoded IDs.
32- Use `terraform plan` output in PR reviews before applying.
33 
34# Terraform Best Practices
35- Use variables for all configurable values:
36```hcl
37  variable "instance_type" {
38    description = "EC2 instance type for application servers"
39    type        = string
40    default     = "t3.medium"
41    validation {
42      condition     = can(regex("^t3\\.", var.instance_type))
43      error_message = "Only t3 instances are allowed."
44    }
45  }
46```
47- Use `locals` for computed values used multiple times.
48- Use `output` to expose values needed by other configurations.
49- Use `lifecycle` blocks for zero-downtime updates:
50```hcl
51  resource "aws_instance" "web" {
52    lifecycle {
53      create_before_destroy = true
54    }
55  }
56```
57- Use `prevent_destroy` on critical resources (databases, S3 buckets with data).
58- DON'T: Store secrets in Terraform state — use a secrets manager.
59- DON'T: Use `terraform apply -auto-approve` in production.
60- DON'T: Hardcode AWS account IDs, regions, or ARNs — use data sources and variables.
61 
62# Docker Best Practices
63- Multi-stage builds for minimal production images:
64```dockerfile
65  # Build stage
66  FROM node:20-alpine AS builder
67  WORKDIR /app
68  COPY package*.json ./
69  RUN npm ci --only=production && npm cache clean --force
70  COPY . .
71  RUN npm run build
72 
73  # Production stage
74  FROM node:20-alpine
75  RUN addgroup -S appgroup && adduser -S appuser -G appgroup
76  WORKDIR /app
77  COPY --from=builder --chown=appuser:appgroup /app/dist ./dist
78  COPY --from=builder --chown=appuser:appgroup /app/node_modules ./node_modules
79  USER appuser
80  EXPOSE 3000
81  HEALTHCHECK --interval=30s --timeout=3s CMD wget -qO- http://localhost:3000/health || exit 1
82  CMD ["node", "dist/main.js"]
83```
84- Always use specific image tags, never `latest`: `node:20.11-alpine`, not `node:latest`.
85- Scan images for vulnerabilities: `docker scout`, `trivy`, or `snyk container`.
86- Keep images small: use Alpine base, multi-stage builds, minimal dependencies.
87- One process per container — don't run multiple services in one container.
88- Use `.dockerignore` to exclude: `.git`, `node_modules`, `tests`, `docs`, `.env`.
89 
90# CI/CD Pipeline (GitHub Actions)
91- Standard pipeline stages: lint -> test -> build -> deploy:
92```yaml
93  name: CI/CD
94  on:
95    push:
96      branches: [main]
97    pull_request:
98      branches: [main]
99
100  jobs:
101    lint:
102      runs-on: ubuntu-latest
103      steps:
104        - uses: actions/checkout@v4
105        - uses: actions/setup-node@v4
106          with: { node-version: 20, cache: npm }
107        - run: npm ci
108        - run: npm run lint
109
110    test:
111      needs: lint
112      runs-on: ubuntu-latest
113      services:
114        postgres:
115          image: postgres:16
116          env: { POSTGRES_PASSWORD: test }
117          ports: ['5432:5432']
118      steps:
119        - uses: actions/checkout@v4
120        - run: npm ci
121        - run: npm test -- --coverage
122        - uses: actions/upload-artifact@v4
123          with: { name: coverage, path: coverage/ }
124
125    deploy:
126      needs: test
127      if: github.ref == 'refs/heads/main'
128      runs-on: ubuntu-latest
129      environment: production
130      steps:
131        - uses: actions/checkout@v4
132        - run: docker build -t app:${{ github.sha }} .
133        - run: docker push registry/app:${{ github.sha }}
134        - run: kubectl set image deployment/app app=registry/app:${{ github.sha }}
135```
136- Cache dependencies between runs (npm cache, Docker layer cache).
137- Run security scans (SAST, dependency audit) in CI.
138- Use GitHub Environments with approval gates for production deploys.
139- Store secrets in GitHub Secrets, not in code or CI config.
140 
141# Kubernetes Patterns
142- Use Deployments for stateless services, StatefulSets for stateful.
143- Define resource requests AND limits on every container:
144```yaml
145  resources:
146    requests:
147      cpu: 100m
148      memory: 128Mi
149    limits:
150      cpu: 500m
151      memory: 512Mi
152```
153- Use ConfigMaps for configuration, Secrets for sensitive data.
154- Define liveness, readiness, and startup probes:
155```yaml
156  livenessProbe:
157    httpGet: { path: /health, port: 3000 }
158    initialDelaySeconds: 15
159    periodSeconds: 10
160  readinessProbe:
161    httpGet: { path: /ready, port: 3000 }
162    initialDelaySeconds: 5
163    periodSeconds: 5
164```
165- Use Horizontal Pod Autoscaler (HPA) based on CPU/memory or custom metrics.
166- Use PodDisruptionBudget to ensure availability during node maintenance.
167- Use Ingress with TLS termination for external traffic.
168- Use NetworkPolicies to restrict pod-to-pod communication.
169 
170# Monitoring and Alerting
171- Monitor the Four Golden Signals: latency, traffic, errors, saturation.
172- Set up alerts for:
173  - Error rate > 1% for 5 minutes
174  - P99 latency > 2 seconds for 5 minutes
175  - CPU/memory utilization > 80% for 10 minutes
176  - Disk space > 85%
177  - Certificate expiry within 30 days
178  - Health check failures
179- Use Prometheus + Grafana or cloud-native monitoring (CloudWatch, Datadog).
180- Create dashboards for: service health, infrastructure metrics, business metrics.
181- Set up PagerDuty or Opsgenie for on-call alerting.
182 
183# Secret Management
184- Never store secrets in code, environment files committed to git, or CI config files.
185- Use a secrets manager: AWS Secrets Manager, HashiCorp Vault, or cloud-native equivalent.
186- Rotate secrets regularly (automated rotation preferred).
187- Use separate secrets per environment (dev/staging/prod).
188- Audit secret access with logging.
189 
190# Disaster Recovery
191- Define RTO (Recovery Time Objective) and RPO (Recovery Point Objective) for each service.
192- Automated database backups with tested restoration procedures.
193- Multi-AZ deployment for high availability.
194- Document runbooks for common failure scenarios.
195- Conduct regular disaster recovery drills.
196- Use infrastructure-as-code for fast environment recreation.
197 
198# Security
199- Enable MFA on all cloud accounts and CI/CD systems.
200- Use IAM roles with least-privilege permissions.
201- Enable VPC flow logs and CloudTrail for audit trails.
202- Scan Docker images and dependencies for vulnerabilities in CI.
203- Use HTTPS everywhere — no exceptions.
204- Implement WAF rules for public-facing services.
205 
206# Common Mistakes to Avoid
207- DON'T: Store secrets in Terraform state or version control.
208- DON'T: Use `latest` Docker tags — pin specific versions for reproducibility.
209- DON'T: Skip health checks in Kubernetes deployments.
210- DON'T: Deploy directly to production without a staging environment.
211- DON'T: Set CPU limits without load testing — too low causes throttling.
212- DON'T: Ignore Terraform plan output — review every change before applying.
213- DON'T: Use root user/account for daily operations — use service accounts with limited permissions.
214