How to start a blog.

Es beginnt anscheinend.

Normalerweise starte ich ja indem ich einen timestamp notiere.
Es ist also Mo 2024-10-21 18:01.

Naja also gerade bin ich in Borgloh am Anfang einer Woche, die ich in Vatters tiny Haus verbringen werde. Ich hatte schon öfter die Idee mal testweise einen Blogtext zu schreiben und fand die Vorstellung witzig, dass dieser den Titel "How to start a blog" würde tragen werden. Wie habe ich also es geschafft den langen Weg bis hierhin zu beschreiten?

...

Hm? Achso. Ja gute Frage. Die größt wahrgenommene Herausforderung, die es zu bewältigen galt, war einen Namen zu finden. Ohne diesen Einstiegspunkt schien alles aussichtslos. ("aussichtslos" mag hier eine klassische Übertreibung in meiner Gedankenwelt sein, aber) Die Möglichkeit per DNS subdomain sauber getrennte Umgebungen mit cleanem Pfad zu verwalten schien unglaublich wichtig.
Einerseits bietet nicht jede Software eine gute Konfigurationsmöglichkeit für ein Pfad-Prefix - und wenn, dann sind diese sicherlich nicht einheitlich. Naja und wenn die dann anfangen sich da auch noch gegenseitig in die Quere zu kommen, dann hat ja bald auch niemand mehr wirklich was davon :) .
Andererseits ist es super praktisch testweise einfach 'ne Anleitung durchzuballern, die irgendwie zu nennen und das Ergebnis zu sehen, ohne eine live Anwendung (potentiell negativ) beeinflussen zu können*. Sobald ein Setup stabil genug scheint kann es entweder umbenannt in einen produktiven Namen, oder alternativ unter diesem clean aufgebaut werden. Dann noch fix ein Zertifikat dafür issue'n und glücklich sein.
Und wie ich dazu gekommen bin diese Dinge zu identifizieren und umzusetzen möchte ich kurz beschreiben.

Im Kern basiert das Setup auf Docker. Alle environments liegen parallel in eigenen Verzeichnissen. Jedes wird von einem compose file definiert bzw. gesteuert. Neben der docker-compose.yml können weitere Resourcen im Verzeichnis der Anwendung liegen, die von dieser gelesen und/oder geschrieben werden können. Die Verzeichnisstrukutur meiner derzeitig produktiv laufenden Apps sieht so aus:

docker/
├── README.txt
├── tmuxp.yml
├── proxy/
│   ├── docker-compose.yml
│   ├── haproxy.cfg -> config/haproxy.cfg
│   ├── acme-out/ -> ../acme/haproxy-out/
│   └── config/
├── acme/
│   ├── docker-compose.yml
│   ├── var/
│   └── haproxy-out/
├── ghost/
│   └── docker-compose.yml
└── nextcloud/
    ├── docker-compose.yml
    ├── nginx.conf
    ├── postgres.env
    └── README.md

Die ersten beiden Apps proxy und acme arbeiten eng zusammen und bilden den Rahmen um weitere Anwendungen ordentlich zugänglich zu machen. Erstere nutzt das haproxy:2.6 image und richtet port fowards für 80 und 443 ein. Über ein umgebungsübergreifendes Netzwerk stellt jede Anwendung einen HTTP-Endpunkt zur Verfügung an den proxy weiterleiten kann. acme nutzt das neilpang/acme.sh image und stellt den Endpunkt http://acme:80 bereit, an dem sie lauscht um ACME HTTP-01 challenges zu beantworten. Erfolgreich bestellte TLS-Zertifikate werden im haproxy-out Verzeichnis abgelegt, aus dem proxy diese wiederum liest und somit dazu ermächtigt wird für eine beliebige von acme bestellte Domain Anfragen verschlüsselt anzunehmen und zu beantworten und somit sichere Kommunikation per HTTPS zu ermöglichen.
Für die tiefere Verarbeitung des Requests innerhalb der Anwendung spielt TLS dann keine Rolle mehr, was sowohl das Setup für jede Umgebung vereinfacht, als auch es im gesamten einheitlicher und folglich robuster macht.

In der Zeit als ich noch auf der Suche nach einem guten domain Namen war, entstand die Grundstruktur des docker Verzeichnis. Nicht-HTTP-basierte Anwendungen konnte ich auch ohne subdomains parallel betreiben, da sie eh auf eigenen Ports lauschen und dort jeweils ihre ganz eigene Sprache sprechen. So hatte ich zeitweise Minecraft, Palworld und Nextcloud parallel laufen und die zugrunde liegende Struktur begann sich zu festigen.
Dem Aufmerksamen Leser mag im obigen tree listing die Datei docker/tmuxp.yml aufgefallen sein. Diese definiert eine tmux session, die für alle produktiv laufenden Anwendungen ein Fenster reserviert und dort passende Aufrufe zum Starten dieser ausführt – ülicherweise docker compose up -d. So kann nach Reboots, mit tmuxp load docker leicht dafür gesorgt werden, dass alle produktiven Apps laufen. Anschließend bleibt einem eine gut organisierten tmux session, an die man sich gerne regelmäßig attached um den Status der Anwendungen zu prüfen, logs zu checken und an der nächsten Kleinigkeit zu hacken.
Auf diese Weise konnten - sobald der Domainname vorhanden war - recht zügig und schmerzfrei proxy, acme und schließlich ghost entstehen.

\* Das ist natürlich nicht vollkommen ausgeschlossen.