infra:cloud
Table of Contents
Cloud & Containerization
This page collects notes about cloud usage, Docker/Kubernetes, and how they fit with self-hosting.
When to Use the Cloud
From discussions, the main reasons to use cloud providers instead of only home servers:
- High availability: you need uptime that survives home power or ISP failures.
- Global latency: you have users spread across regions.
- Bandwidth: your home upload bandwidth is too low.
Examples where cloud can make sense:
- Public-facing APIs and websites.
- Latency-sensitive services (e.g. game backends).
- Off-site backups.
For purely personal or family tools (RSS, blog, small git hosting), many participants preferred self-hosting at home for privacy and cost reasons.
Docker and Compose
Key patterns around Docker:
- Use docker-compose to describe services:
- One `docker-compose.yml` per application stack.
- Declare networks, volumes, environment variables explicitly.
- Persist data in named volumes or host directories:
- For databases: always mount `/var/lib/postgresql` (or equivalent) somewhere persistent.
- Keep config files versioned in Git.
- Common services containerized:
- Reverse proxies (nginx, Traefik).
- Databases (PostgreSQL, MariaDB).
- Queue systems (Redis, RabbitMQ).
- Web apps (Node.js, Python, Go, Rust).
Kubernetes: Use with Caution
Kubernetes was mentioned a few times, usually with a note of caution:
- Powerful but heavy for small personal setups.
- High cognitive overhead:
- Pods, deployments, services, ingress, secrets, persistent volumes, etc.
General consensus from the tone of the discussions:
- For small-scale self-hosting, Kubernetes is often overkill.
- Prefer:
- Simple Docker-Compose stacks.
- Orchestrators like Nomad if you truly need scheduling.
- Or even plain systemd services for a few long-lived daemons.
Good Practices for Cloud-Hosted Services
When you do host services in the cloud:
- Infrastructure as Code (IaC):
- Use Terraform, Ansible, or similar to capture VM and network configuration.
- Avoid hand-tuning servers with undocumented changes.
- Backups and secrets:
- Keep encrypted secrets (e.g. with Ansible Vault, sops).
- Store backups in multiple regions if running in a single cloud vendor.
- Cost awareness:
- Watch for creeping costs: log storage, managed DBs, data transfer.
- Use basic monitoring (Grafana/Prometheus, netdata, provider dashboards) to avoid surprises.
infra/cloud.txt · Last modified: by 127.0.0.1
