möchte­gern­geek

Seit Anfang September ist dieses Blog eine Progressive Web App. Das bedeutet, dass dieses Blog nun auch offline funktioniert und man es auf dem Smartphone als App hinzufügen kann.

Warum?

Nun, Chrome bietet mit Lighthouse Ratschläge, wie man seine Website verbessern kann. Einer der vier Unterpunkte heißt Progressive Web App und war frustrierend schlecht bewertet. Die folgenden Schritte habe ich also nur für Lighthouse gemacht und es hat sich auf jeden Fall gelohnt:

Wie?

Lighthouse bietet eine Checkliste, auf der neben einigen Punkten, die generell eine gute Idee sind, drei Punkte aufgeführt sind, die erfüllt sein müssen:

• Site is served over HTTPS
  • Dank Let’s Encrypt ist das kein Problem mehr.
• The start URL (at least) loads while offline
  • Das ist der aufwendigste Teil. Um dies zu erreichen muss man einen service worker registrieren. Damit der service worker weiß, welche Dateien notwendig sind, benutze ich nach jedem erfolgreichen Build sw-precache mit einer sehr einfachen Konfiguration. Dadurch benötige ich jetzt Node, um das Blog zu erstellen ¯\_(ツ)_/¯
• Metadata provided for Add to Home screen
  • Damit ist eine manifest.json gemeint. Diese Datei enthält links zu Icons, die als Appsymbol benutzt werden, wenn man die Seite auf Android oder Windows installiert. Und es legt die Farbe der Adressleiste im mobilen Chrome fest. Ein nützlicher Dienst, um ein solches Manifest zu erstellen, ist app-manifest.firebaseapp.com

Was jetzt?

Service Worker ermöglichen Benachrichtigungen von einer Website. Ein natürlicher nächster Schritt wäre es also Benachrichtigungen zu versenden, wenn ein neuer Post online ist. Auf der anderen Seite bin ich selbst immer etwas genervt von Websites, die mich benachrichtigen wollen und der Lighthouse Punktestand ist schon optimal, also wird das wohl nicht passieren.

Nachdem ich vor Kurzem einen euphorischen Eintrag über mein automatisiertes Update dieses Blogs via Travis-CI und GitHub pages geschrieben habe, bin ich jetzt auf eine einfachere Lösung gestoßen.

Alles unter einem Dach bei Netlify

Es gibt einen einfachen Buildservice, der zwar nicht so flexibel ist wie Travis-CI, aber für dieses Blog ausreicht. Netlify baut die Seite also bei jedem Push in ein beobachtetes GitHub Repository. Nach Konfiguration des DNS und einem weiteren Knopfdruck ist die Seite mit einem SSL Zertifikat von Let’s Encrypt ausgestattet und erreichbar. Also Bonus kann man selbst HTTP-Header bestimmen über eine _headers Datei:

/*
    Strict-Transport-Security: max-age=31536000; includeSubDomains

Also kann man HTTP/2 Server Push ausprobieren, ohne einen Server betreiben zu müssen.

Seit Anfang August wird dieses Blog nicht mehr von einem Raspberry aus den eigenen vier Wänden ausgeliefert, sondern von GitHub pages. Da die Quellen dieses Blogs bereits auf GitHub sind, ist dies ein konsequenter Schritt.

Hosting auf GitHub Pages

GitHub bietet hosting von statischen Seiten an, was perfekt zu diesem Pelican Blog passt. Die Verwaltung ist denkbar einfach: Für jedes Repository ist der Branch gh-pages unter [username].github.io/[reponame], hier z.B. surt91.github.io/blog, erreichbar.

Will man unter einer eigenen Domain erreichbar sein, reicht es aus, im DNS für die Domain einen CNAME Eintrag auf [username].github.io anzulegen und im root des gh-pages Branches eine Datei CNAME mit der eigenen Domain anzulegen, hier z.B.

echo blog.schawe.me > CNAME

Primär dient GitHub pages dazu Jekyll Seiten zu erstellen und auszuliefern, was zu Konflikten führen kann, wenn man einfach nur statische Seiten im gh-pages Branch vorhält. Dies lässt sich einfach vermeiden, indem man eine Datei .nojekyll im root anlegt.

Automatische Erstellung durch Travis CI

Natürlich könnte man das statische HTML auf einem lokalen Computer erstellen und per Hand in den gh-pages Branch pushen. Aber man kann das auch einem Dienst wie Travis CI überlassen.

Die Idee ist, dass jedes Mal wenn man die Quellen seiner Seite ändert — im Fall von Pelican werden die Blogeinträge in Markdown geschrieben und dann in HTML konvertiert — ein Server die Seite erstellt und das Ergebnis in den gh-pages Branch pusht. Dadurch wird ein Update der Website auf ein einfaches git push reduziert.

Die Konfiguration von Travis CI wird durch eine denkbar einfache YAML Datei definiert. Eine (vereinfachte) Konfiguration für dieses Blog sieht beispielsweise so aus:

# pelican is a python program
language: python
python:
  - "3.5"

# install pelican and some more packages
install: "pip install -r requirements.txt"

# generate static html through pelican's makefile
script:
  - make publish

# deploy to github pages
deploy:
  provider: pages
  skip_cleanup: true
  github_token: $GITHUB_TOKEN
  local_dir: output
  on:
    branch: master

Falls Fehler beim Erstellen auftreten, schickt Travis eine Email und bricht die Veröffentlichung ab. Wenn keine Fehler auftreten, wird wenige Sekunden später die neue Version von GitHub ausgeliefert.

SSL verschlüsselt von Cloudflare®

Die github.io Domains werden zwar verschlüsselt ausgeliefert, aber natürlich kann GitHub keine SSL Zertifikate für die eigene Domain ausstellen lassen. [Update: Mittlerweile kann GitHub das.] Man kann auch kein eigenes Zertifikat hochladen. Aber die Situation ist nicht so aussichtslos wie sie scheint. Cloudflare ermöglicht es, allerdings müssen ein paar Bedingungen erfüllt sein.

Cloudflare muss

• als DNS Service für die gewünschte Domain genutzt werden und
• als Proxy vor der Seite benutzt werden.

Als Bonus können wir Cloudflares CDN nutzen.

Sobald sich Cloudflare um das DNS der Domain kümmert, kann über das Dashboard SSL aktiviert werden — und wenn man schon dabei ist, sollte man auch die Always use HTTPS und HSTS Optionen aktivieren.