A multi-container hit counter application built to learn containers, Kubernetes, and cloud-native development.
A simple web app that counts page visits. Each refresh increments the counter and spawns a bouncing "Jupiter" ball on screen.
But the real purpose? Learning how containers and orchestration work by building something hands-on.
I wanted to understand:
- How containers actually work (not just
docker run) - Why we need orchestration tools like Kubernetes
- The difference between local memory and external state (Redis)
- How multi-container applications communicate
Instead of just reading docs, I built something.
| Component | Technology |
|---|---|
| Backend | Python 3.11 + Flask |
| Database | Redis |
| Container Runtime | Podman |
| Orchestration | Kubernetes (Minikube / Kind) |
- Writing Dockerfiles with multi-stage builds
- Why
entrypoint.shexists (runtime configuration) - Container networking — why
localhostdoesn't work across containers
- Pods, Deployments, Services, Namespaces
- How Services provide stable DNS names for ephemeral pods
- The difference between Minikube and Kind
- Using
kubectlto debug running applications
- Why external state (Redis) matters — containers are ephemeral
- How pods share network namespaces (pause containers)
- The declarative model: describe desired state, let K8s handle the rest
# With Podman
podman build -t jupiter-frontend .
podman pod create --name jupiter -p 5000:5000
podman run -d --pod jupiter --name redis redis:7-alpine
podman run -d --pod jupiter --name flask-app jupiter-frontend
# Visit http://localhost:5000Jupiter/
├── app/
│ ├── app.py # Flask application
│ ├── requirements.txt # Dependencies
│ └── templates/
│ └── index.html # Frontend with bouncing Jupiters
├── k8s/
│ ├── deployment.yaml # Kubernetes Deployments
│ └── service.yaml # Kubernetes Services
├── Dockerfile
├── entrypoint.sh
└── README.md
Refresh the page to add more bouncing planets!