Server-Basis

Einmalig / pro Projekt / pro Server

Diese Anleitung deckt Zeile 1 und 2 ab und zeigt das Muster für Zeile 3. Die konkrete cloud-init-Zeile und den Stack liefert die jeweilige Dienst-Anleitung.

1 Konto, 2FA, Projekt

1. Konto auf console.hetzner.com, Zahlungsart hinterlegen (sonst schlägt server create mit „not verified“ fehl).
2. 2FA anschalten: Security › Two Factor Auth – das Hetzner-Konto steuert echtes Geld.
3. Projekt anlegen (oben links). Ein Projekt ist ein abgeschotteter Ressourcen-Topf mit eigenem Token. Empfehlung: eigenes Projekt heimlabor für Wegwerf-Server, getrennt von allem Dauerhaften.

2 API-Token

Das Passwort, mit dem hcloud Server erstellt und löscht. Pro Projekt einer.

1. Im Projekt: Security › API (Application Programming Interface) Tokens › Generate API token → Berechtigung Read & Write.
2. Sofort kopieren – wird nur einmal gezeigt. In den Passwortmanager, nicht ins Repo.
3. Verloren? Neuen erzeugen, alten löschen.

3 hcloud CLI & Kontext

winget install HetznerCloud.CLI
# Terminal neu oeffnen, damit hcloud im PATH ist

hcloud context create heimlabor     # fragt nach dem Token aus Schritt 2
hcloud context list                     # der aktive hat einen *

4 Werkzeuge je nach Ziel

ssh.exe, scp.exe, tar.exe sind unter Windows 10/11 eingebaut – nichts zu installieren.

5 SSH-Key hinterlegen

Der private Teil bleibt auf dem Laptop, der öffentliche wird von Hetzner in den root-Account jedes neuen Servers gelegt.

# nur falls noch keiner existiert:
ssh-keygen -t ed25519 -f $env:USERPROFILE\.ssh\id_ed25519

# bei Hetzner hinterlegen (Name "laptop" -- taucht in jedem "server create" wieder auf)
hcloud ssh-key create --name laptop --public-key-from-file $env:USERPROFILE\.ssh\id_ed25519.pub

6 Firewall-Prinzip

Eine Hetzner Cloud Firewall filtert schon im Netz, vor dem Server. Regel: nur die nötigen Ports, nur von deiner IP (Internet Protocol).

$ip = (Invoke-RestMethod 'https://ipv4.icanhazip.com').Trim()

hcloud firewall create --name podman-host-fw
hcloud firewall add-rule podman-host-fw --direction in --protocol tcp --port 22 --source-ips "$ip/32"
# je nach Dienst zusaetzlich: 6443 (kube-API), 80/443 (Web) -- steht in der Dienst-Anleitung

7 cloud-init: Grundmuster

cloud-init.yaml läuft einmalig beim ersten Boot. Jede Dienst-Anleitung ergänzt hier ihre eine Zeile (k3s-Install, Podman, Docker …) – der Rahmen ist immer gleich.

#cloud-config
package_update: true
package_upgrade: true
packages: [ ca-certificates, curl, fail2ban, unattended-upgrades ]
runcmd:
  # --- HIER die Zeile aus der jeweiligen Dienst-Anleitung ---
  # Container:  - curl -fsSL https://get.docker.com | sh
  # k3s:        - curl -sfL https://get.k3s.io | sh -s - server --write-kubeconfig-mode 644 --tls-san "$(curl -s http://169.254.169.254/hetzner/v1/metadata/public-ipv4)"
  - printf '%s\n' '{ "log-driver":"json-file","log-opts":{"max-size":"10m","max-file":"3"} }' > /etc/docker/daemon.json
  - systemctl restart docker 2>/dev/null || true
write_files:
  - path: /etc/apt/apt.conf.d/20auto-upgrades
    content: |
      APT::Periodic::Update-Package-Lists "1";
      APT::Periodic::Unattended-Upgrade "1";

Wichtig: cloud-init läuft nur beim allerersten up (aus dem Basis-Image). Danach bootet der Server aus dem Snapshot und alles ist schon eingerichtet – siehe Server-Snapshot & Restore.

8 Die Skripte konfigurieren

Repo klonen (Link in der Übersicht), dann oben in der passenden .ps1 die Konfiguration anpassen.

9 Erster Server

.\scripts\cloud.ps1 up          # erstellt aus Basis-Image + cloud-init, setzt Firewall + Verbindung
.\scripts\cloud.ps1 status      # laeuft er? seit wann? ~Kosten
.\scripts\cloud.ps1 ssh         # SSH drauf (Host-Key wird vorher bereinigt)

Der erste SSH-Kontakt bestätigt automatisch den neuen Host-Key. Bei „resource_unavailable“ hat Hetzner keine Kapazität für den Typ – .\scripts\cloud.ps1 up -Type cpx42 (eine Nummer größer), einen anderen Standort (-Location hel1) oder – falls gerade frei – -Type cx33 / cax21 probieren.

10 Danach: was noch

+ Ohne Skripte (reine hcloud-Befehle)

$ip = (Invoke-RestMethod 'https://ipv4.icanhazip.com').Trim()
hcloud firewall replace-rules podman-host-fw --rules-file rules.json   # [{"direction":"in","protocol":"tcp","port":"22","source_ips":["'+$ip+'/32"]}]

hcloud server create --name podman-host --type cpx32 --image ubuntu-24.04 `
  --ssh-key laptop --firewall podman-host-fw --user-data-from-file cloud-init.yaml

hcloud server ip podman-host
# ... arbeiten ...
hcloud server create-image --type snapshot --description podman-host podman-host
hcloud server delete podman-host

Die Firewall-Regeldatei ohne BOM schreiben ([IO.File]::WriteAllText, nicht Set-Content -Encoding utf8) – sonst scheitert der JSON-Parser von hcloud.

+ Mehrere Server & Projekte

• Getrennte Projekte für prod / staging / Wegwerf – eigene Tokens, eigene Rechnung, kein versehentliches Löschen über Grenzen. Der Self-Destruct-Timer (cloud-init.selfdestruct.yaml) nur in einem reinen Wegwerf-Projekt.
• Ein Server für viele Dienste statt vieler kleiner – Mehrere Dienste auf einem Server.
• Cluster (mehrere Nodes): snapshot.ps1 mit mehreren $SERVERS-Einträgen, feste Primary-IPs optional.
• Namenskonvention: <zweck>-host (podman-host, k3s-host), Firewall <zweck>-fw – die Skripte leiten das ab.