User Tools

Site Tools


infra:cloud

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