Gestern Abend wollte ich schnell einen Rezepte-Import in meine Re-Implementierung vom Speiseplaner packen. Ich hatte in den letzten Monaten öfter Github-Repositories gesehen, die sowas anbieten. recipe-scrapers sah ziemlich umfassend aus, ist aber leider in Python geschrieben.

Nun hätte ich sicher Python in mein Docker-Image ziehen können, das alles installieren und per exec drauf zugreifen können, doch ich dachte mir, warum machst du das nicht kurz in sauber und baute eine Flask-App darum. Wobei, bauen kann man das nun wirklich nicht nennen, ich änderte ungefähr eine Zeile aus der Hello World-Beispielapp:

from flask import Flask
from flask import request
from recipe_scrapers import scrape_me

app = Flask(__name__)

@app.route("/")
def hello_world():
    url = request.args.get('url', '')
    scraper = scrape_me(url, wild_mode=True)
    return scraper.to_json()

Dazu diese kurze Dockerfile und fertig ist die Rezepte-Scraping-API.

FROM python:3-alpine

WORKDIR /usr/src/app

COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt

COPY app.py ./

CMD [ "flask", "--app", "app", "run", "--host=0.0.0.0"]

Jetzt war es ein leichtes, das Import-Feature in den Speiseplaner zu implementieren, quasi nur noch ein API-Aufruf und fertig. Da freut man sich doch, wie leicht mittlerweile vieles geworden ist.

Im Zuge meiner Server-Konsolidierung musste ich mal wieder auch meinen Last.fm-Ersatz mey anfassen, da er sich leider nicht leicht zu SQLite konvertieren ließ. Immerhin sieht es nun auch ein bisschen hübscher aus!

Leider muss ich nochmal ran, denn die damals importierten Daten sind echt etwas… Lückenhaft. Vielleicht aber auch egal, hauptsache es läuft im Docker Container und ist still.

Nur eine kurze Notiz, für alle, die noch ein oder zwei Wordpresse rumfliegen haben, aber keine Lust dazu haben einen MySQL-Server dafür zu betreiben, weil eh fast kein Traffic drauf ist:

Es existiert diese One-File-Lösung auf Github, die man einfach in wp-content ablegt und schon supported Wordpress SQLite. Verrückt. Um einen bestehenden MySQL-Dump so umzubiegen, dass er in SQLite zu importieren geht, kann man dieses Script benutzen.

Das ganze packt man ins Docker-Image und muss sich nie wieder damit auseinandersetzen, hoffentlich.

Gestern warf Markus einen Link zu airgpu in den Raum. Glücklicherweise war auch gerade das Open Beta-Wochenende für Diablo 4, was für eine gute Kombination, um mal wieder Cloud-Gaming auszuprobieren.

Bei airgpu zahlt man, anders als bei Shadow, auf Stundenbasis. Außerdem benutzt man mit Moonlight einen Open Source-Client und nicht dieses proprietäre Zeug von Shadow. Letztendlich scheint es nur ein Wrapper um g4dn.xlarge-Instanzen von AWS zu sein, mit einem Windows Server-Image, auf dem halt ein paar Sachen vorinstalliert sind.

Ich muss sagen, es lief ziemlich gut. Ich hatte eigentlich keinen einzigen Ruckler während der Stunde Spielzeit. Vielleicht lag es daran, dass ich heute mal direkt neben dem Wifi-Accesspoint saß, keine Ahnung.

Diablo 4 war soweit auch okay. Man läuft halt rum und klickt auf Gegner, bis sie tot umfallen. Ich war jetzt nicht so tief involved, denn auf der einen Seite habe ich keine Lust mich in eine Open Beta reinzunerden, wenn ich danach noch Monate auf den Release warten muss und zum Anderen weiß ich noch gar nicht, wie ich die finale Version spielen soll, weil Blizzard es wohl aufgegeben hat, MacOS-Builds herzustellen.

Jedenfalls sehe ich für mich und airgpu auch keine wirkliche Zukunft. Zwar kostet es keine 30€ im Monat wie Shadow, aber Preise zwischen 1€ und 1,50€ pro Stunde und zusätzlich 7€ für 100GB SSD-Speicher im Monat läppern sich auch schnell zusammen. Letztendlich wären das 15 Stunden spielen und man ist wieder beim Shadow-Preis. Nicht, dass ich das jemals schaffen würde, im Monat 15 Stunden zu spielen, aber es spielt sich auf jeden Fall anders, wenn man im Hinterkopf hat, dass jede Stunde bares Geld kostet. Psychologisch anstrengend!

Da airgpu auch nur AWS-Instanzen reselled könnte man ja mal gucken, ob man sich das selber bauen kann und sich damit die Marge spart, aber ich glaube, das bringt nicht so viel. So wie ich das sehe, kostet eine g4dn.xlarge auch um die 70 Cent und da ist ja noch gar kein Datentransfer dabei. 100GB EBS-Volume kosten auch schon fast 10€ bei AWS, ich weiß gar nicht, wie airgpu die für 7€ anbieten kann. Habe mich vielleicht irgendwo verrechnet.

Achso, eine Kleinigkeit noch: Weil ich seit Jahren fast keine Maus mehr benutzt habe und Diablo 3 auch einige Zeit auf der Switch spielte, ist mir die Konsolensteuerung bei dem Spiel eigentlich fast lieber. Leider wird es Diablo 4 wohl nicht für die Switch geben und eine PS5 will ich wirklich auch nicht haben, schade.

(album: himmelfahrt)

Ein neues Album von Subway to Sally! Schön, aber auch egal. Ein paar Lieder sind okay, zwei, drei sind so, dass ich sie mir fast in eine Playlist packen würde. Das Album enthält noch Akustik-Versionen von ein paar Songs, die sind besser als die normalen Mixe. Das Highlight ist allerdings So Rot, was eigentlich auf Herzblut ist. Die neue Version ist immerhin der beste Song auf Himmelfahrt, aber natürlich keine wirkliche Verbesserung zum Klassiker von 2001.

Ich bin ja schon ein großer Fan von Let’s Encrypt. Ich gab in meinem Leben bestimmt fast 100€ für SSL-Zertifikate aus, damals, als sie noch nicht kostenlos waren.

Seit einigen Jahren gehört certbot für mich nun zum Standard Werkzeugkasten. So ein Tool, das man ständig installiert, wenn man mal eben ein SSL-Zertifikat braucht. Doch etwas störte mich immer. Ich glaube mich zu erinnern, dass ich am Anfang ab und zu ein paar Python-Probleme hatte. Jahre später musste ich plötzlich unter Debian snapd und so Kram installieren, um am certbot zu kommen. Alles machbar, fühlte sich aber nach Overhead an. Mittlerweile scheint es wieder ein direktes Debian-Paket zu geben, immerhin.

Heute baute ich an einem kleinen Script, mit dem ich einfache HTML-Seiten leichter deployen kann. Fast so, als würde ich Vercel benutzen, oder sowas. Will ich natürlich nicht, mehr dazu in einem anderen Post. Jedenfalls stand ich vor dem Problem, certbot benutzen zu wollen, um ein SSL-Zertifikat zu generieren, allerdings ohne, dass der ausführende User root ist. Direkt schlug es fehl, weil er nginx nicht steuern konnte und keine Ahnung. Statt zu versuchen, es mit certbot zum Laufen zu kriegen, fiel mir acme.sh vor die Füße.

Dabei handelt es sich um einen ACME-Protokoll-Client, der einfach in Shellscript geschrieben ist. Keine Abhängigkeiten! Außerdem schafft er es, Zertifikate zu beantragen, ohne root-Rechte zu benötigen. Also, vielleicht wäre das mit certbot auch gegangen, aber acme.sh hat mich auch so sofort überzeugt und wird ein neuer Teil des Werkzeugkastens!

Ich muss ja sagen, dass ich mich langsam an Docker gewöhne. Letzten habe ich gelernt, dass Docker Volumes eigentlich ganz schlau sind. Bisher habe ich eigentlich nie welche verwendet und immer direkte Filesystem-Mounts benutzt, doch jetzt im Zuge meiner großen Server-Konsolidierung, wo ich versuche, das meiste auf Docker umzustellen, hab ich mich nochmal tiefer eingelesen und habe nun weniger gefährliches Halbwissen!

Tatsächlich kam meine Abneigung zu Volumes wahrscheinlich daher, dass sie am Anfang unter MacOS (vielleicht immer noch?) halt nicht so funktionierten, wie ich das gerne wollte — in einem Dev-System will man ja immer direkten Zugriff auf die Daten, also zumindest, wenn man PHP entwickelt. Da mussten es natürlich direkte Filesystem-Mounts sein und die waren langsam und allgemein war Docker auf dem Mac am Anfang ja eher schwierig und hat bei mir zu großer Abneigung geführt.

Nun, informierter, und in einer anderen Umgebung, ich will ja jetzt keine Dev-Umgebungen deployen, sondern… funktionierende Anwendungen, weiß ich es plötzlich zu schätzen. Alles ist etwas aufgeräumter, und sauberer. Vielleicht ist es auch noch ein wenig schneller! Das wichtigste Feature für mich ist allerdings, dass Volumes beim Start des Containers mit dem Inhalt aus dem Container vorgefüllt werden! Das finde ich ein grandioses Feature.

In meinem Post zu Kioski, meiner Homeassistant-Sonos-Steuer-App, gab ich, unwissend, noch folgenden Schnipsel zum Starten an:

touch db.sqlite
docker run -d \
 -p 127.0.0.1:9901:9901 \
 -v $(pwd)/db.sqlite:/app/database.sqlite \
 ghcr.io/pwaldhauer/kioski:latest

Mit Volumes könnte man das Touchen der Datenbank nun einfach weglassen. Er würde einfach die (leere) Datenbank aus dem Image nehmen und sie beim Initialisieren des Volumes dort hin kopieren. Nice!

Zusätzlich könnte man, wenn man wollte, die Volumes auch per NFS oder sonstwas einbinden, da gibt es tausend Möglichkeiten, die man mit den Filesystem-Mounts nicht hat. Gute Sache!