Neuer Server
Seit einiger langer Zeit denke ich ja darüber nach, dass man mal die Hetzner-Konsole aufräumen sollte. Klar, eine neue VM kostet nur 3 Euro im Monat oder so, da fällt es leicht für jedes Quatschprojekt eine Neue zu klicken, aber natürlich besteht hier das klassische Problem: Es läppert sich.
Dazu kommt, dass die billige VM natürlich eigentlich für alles mögliche ausreicht, aber wenn man mal ein paar Thumbnails generieren will, oder irgendwas machen will, was mehr Resourcen braucht, ist der eine popelige Core auch ganz schön am Strampeln.
Abgesehen davon will ein Mensch, der nebenbei ein paar Quatschprojekte hosted, sich nicht um 10 oder 15 Debian-Distributionen kümmern. Ich habe irgendwann angefangen mir eine Ansible-Konfiguration zusammenzubauen, so wie ich es damals auch bei Nerdlichter machte, aber letztendlich muss ich doch zugeben, dass Systemadministration für mich doch eher ein notwendiges Übel ist und nicht gerade etwas, das großen Joy sparked. Also nichts, was ich gerne in meiner Freizeit mache.
Gerade bin ich auf jeden Fall mal wieder in einer solchen Phase, in der ich zumindest mal ausprobieren will, wie es wohl ist, wenn man mehrere Sachen auf einen Server packt. Völlig unnormal klickte ich dafür jetzt erstmal eine kleine, günstige VM, die aber diesmal zumindest 3 Kerne hat, um damit rumzuspielen, statt direkt den 50€-Ryzen-Server anzuschmeißen.
Also. Was sind meine Wünsche? Ich will eine Linux-Distribution haben, um die ich mich kümmern muss und der Rest soll aber trotzdem irgendwie untereinander abgekapselt laufen, damit da nichts kaputt gehen kann.
Alle werden direkt schreien, ja Docker, was sonst!
Ja, leider habe ich die Angewohnheit, dass ich meine Sachen am Liebsten in PHP schreibe und gerne direkt auf Live arbeite, im Hobby-Umfeld. Zwei Sachen, die Docker eher mittelmäßig kann.
Wenn man jetzt eine tolle Go-Anwendung hat, packt man die Binary einfach in einen Docker-Container und gut ist, alles funzt, alle freuen sich. Für PHP braucht man immer erstmal php-fpm
und noch einen Webserver für den Rest, was am Ende schonmal zwei Container sind, und natürlich gibt es auch so Fertigkram, wo alles in einem ist, aber das finde ich einfach schmutzig, ich gehe davon aus, dass ich genau diesen Satz schonmal in diesem Blog geschrieben habe.
Dazu kommt das “an Live arbeiten”: Ich brauche dringend die direkte Möglichkeit, zum Beispiel hier am Blog, an einem Template eine Zeile zu ändern und das Ergebnis unmittelbar zu sehen. Kein “oh, ich führe mal das Build-Script aus, baue den neuen Docker-Container, pushe ihn in die Registry und starte auf dem Server alles neu”.
Ich hab es jetzt erstmal folgendermaßen gelöst: Bei den Laravel-Apps baue ich einen Container mit php:8.1-cli-alpine
und benutze CMD [ “php”, “artisan”, “serve”, “—host=0.0.0.0”, “—port=9000” ]
in der Dockerfile um einfach den in PHP eingebauten Webserver zu verwenden. Sind ja eh nur Dinge, deren einziger Konsument ich selber bin, da sollte das wohl ausreichen. Um die Möglichkeit des Live-Arbeitens zu haben mounte ich meinen /app
-Ordner halt aus dem Dateisystem des Docker-Hosts.
Nun stellt sich die Frage, was mir das eigentlich bringt. Wenn ich eh keine Container habe, die für sich arbeiten, ich also ständig an Dateien herumfummeln will, warum sperre ich es überhaupt ein. Warum nicht einfach alles ganz normal mit php-fpm
machen. Wie groß ist schon die Gefahr, dass jemand in eine meiner PHP-Apps einbricht, die eh alle per Basic Auth geschützt sind, und dann auch noch einen Bug in php-fpm
hat, der es ermöglicht, da Code zu executen?
Um ehrlich zu sein, ich habe keine Ahnung. Für ein paar der Services, die ich so für mich betrieben habe — bisher auf einzelnen Servern, z. B. eine Gitea-Instanz, ist das glaube ich ganz cool mit Docker, aber mir fällt es schwer den Vorteil für meine Herumspielereien zu sehen, so gerne ich ihn auch sehen würde.
Vor allem, hätte ich gerne, dass mir jemand die letzte Stunde des Rumprobierens wieder gibt, da hat nur so mittelmäßig viel Spaß gemacht.