Containerized Environment
A development environment that can be rebuilt, not remembered.
- Dockerfiles
- 12 (6 × 2 platforms)
- Compose services
- 6
- K8s replicas
- 3
- HPA range
- 2–10 @ 85% CPU
- Commits
- 78
- Updated
- Oct 2025
System
How it fits together.
A simplified view of the moving parts, not a full architecture diagram.
- 01Dockerfiles6 toolchains × 2 platforms
- 02Composemounts + networking
- 03K8s manifestssite deployment
- 04HPA / KEDAscale on load and lag
Context
Why it exists.
Local toolchains were spread across machines and operating systems. The goal was to make the environment a file in the repository, and then carry the same declarative habit from a laptop to a cluster.
Approach
- 01Define one image per toolchain and drive them with Compose, keeping the macOS and Windows variants explicit rather than pretending one file fits both.
- 02Mount the working tree and persistent data instead of baking projects into images.
- 03Carry the model into Kubernetes: Deployment, Service, Ingress, and an HPA for the personal site.
- 04Add a Kafka → Logstash → KEDA example to show lag-based autoscaling instead of CPU-only scaling.
Inside the repository
What is actually in there.
Twelve Dockerfiles
Node.js, Python, C/C++, Java, Kali, and MongoDB images, each with zsh, oh-my-zsh, neovim, fzf, bat, and a small set of terminal tools.
Dev containers
Both platforms include devcontainer.json targeting the Node service, with a shared workspace folder and 51 VS Code extensions.
Site deployment
Three replicas, health probes, explicit requests and limits, ClusterIP service, and an ingress with a TLS secret.
Autoscaling demo
An autoscaling/v2 HPA (2–10 replicas at 85% CPU) plus a KEDA ScaledObject driven by Kafka consumer lag.
Constraints & notes
A working reference, not a hardened platform. `network_mode: host` is limited on Docker Desktop, the committed WebPageDeployment.yaml has a mis-indented readinessProbe that must be fixed before applying, and the TLS secret is intentionally not in the repository.