Warum ich die operativen Anweisungen meines Labs von Makefiles auf go-task migriert habe — mit Namespaces, Preconditions, Prompts und einem Überblick, was sich damit alles steuern lässt
Ein Follow-up zum GitOps-Aufbau meines Labs: Wenn das Repository den Zustand beschreibt, brauche ich trotzdem eine Handvoll Anweisungen, um den Cluster zu bedienen — bootstrappen, Secrets rotieren, Backups zurückspielen, Zertifikate erneuern. Lange lebten diese Anweisungen in Makefiles. Heute steckt jede davon in einem
go-task
-Taskfile, und der Umstieg war eine der besseren kleinen Entscheidungen.
Für die deklarative Konfiguration und den Rollout verwende ich Home-Manager — wie WeeChat dabei als reproduzierbares Nix-Artefakt entsteht und sich am Bouncer einklinkt, habe ich separat beschrieben. Hier geht es um die Konfiguration selbst. Mein Flake zur Verwaltung aller Systeme findest du hier; einen ausführlicheren Blogpost dazu schreibe ich bei Gelegenheit.
Netzwerke und ZNC
Vier IRC-Server stehen in irc.conf — drei laufen über den Bouncer, einer (Quakenet, mehr Gewohnheit als Vernunft) direkt:
libera, hackint und local — den cluster-internen IRCd — erreiche ich über den ZNC-Bouncer, der unter bnc.this-is-fine.social/+6697 via TLS hängt. Für ZNC aktiviere ich zusätzliche IRC-Capabilities (znc.in/server-time-iso, znc.in/self-message, …).
Die Serverpasswörter liegen verschlüsselt in ${sec.data} und die Passphrase hierfür wird beim Startup von WeeChat über pass mit
passphrase_command = "pass show apps/weechat/passphrase" entschlüsselt.
Layout: Bars und Buffer
weechat.conf definiert ein eigenes Bar-Set — die Statuszeile unten ist absichtlich weg; Kontext steckt in der Title-Bar:
Warum OCI mehr ist als nur Docker-Images, weshalb mein Build daemonlos mit Skopeo und Crane statt docker push arbeitet — und wie Zot mein schwergewichtiges Harbor abgelöst hat
„Container-Image“ ist im Sprachgebrauch fast zum Synonym für „Docker“ geworden — dabei ist das Format längst von Docker entkoppelt und in der Open Container Initiative(OCI) standardisiert. Dieser Beitrag erklärt, was das konkret bringt, warum meine Build-Pipeline deshalb mit Skopeo und Crane statt docker push arbeitet, und wie ich meine bisherige Harbor-Registry gegen das deutlich schlankere
Zot
getauscht habe.
Cilium als kube-proxy-freie CNI und seine BGP-Control-Plane, die Service-IPs per eBGP an eine Ubiquiti UDM-SE annonciert
In der Cloud ist ein Service vom Typ LoadBalancer ein gelöstes Problem — der Provider zaubert eine IP herbei. Auf Bare-Metal ist genau das die Lücke: Wer vergibt die IP, und wer sorgt dafür, dass das Netzwerk sie auch findet? In meinem Lab erledigt das
Cilium
— als CNI und gleichzeitig als BGP-Sprecher, der die Service-IPs an meine
Ubiquiti UDM-SE
annonciert.
Cilium als CNI
Cilium ist auf jedem Cluster die einzige CNI, installiert direkt über die Talos-Maschinenkonfiguration. Es ersetzt kube-proxy vollständig (kubeProxyReplacement: true) und bewegt das gesamte Service- und NetworkPolicy-Handling per
eBPF
in den Kernel. Pod-IPAM läuft im kubernetes-Modus; die Verschlüsselung des Pod-Traffics ist bewusst aus, weil die clusterübergreifenden Pfade ohnehin über das WireGuard des Headscale-Tailnets laufen.
Spannend wird es beim Übergang vom Cluster ins LAN.
Ein persistenter IRC-Bouncer auf Kubernetes, der seine Upstream-Netze als Onion-Services über Tor erreicht — plus ein interner IRCd und ein nostalgischer Blick auf BitlBee
IRC ist tot, lang lebe IRC. Während der Rest der Welt durch Messenger-Silos zieht, hänge ich nach wie vor gern in ein paar IRC-Kanälen ab — und damit mir dabei keine Zeile entgeht, betreibe ich einen Bouncer. Bei mir ist das
ZNC
, läuft auf Kubernetes und erreicht seine Upstream-Netze nicht direkt, sondern als
Onion-Services
über Tor.
