Von Kamelen und Webseiten
uberspace.de erstrahlt nun schon seit Längerem in neuem Glanz. Details dazu habt ihr schon im passenden Blogpost erfahren. Um unsere Entwicklung zu beschleunigen, war die neue Seite zunächst bei netlify gehostet - ein cooles CDN mit eingebauter Build-Pipeline. Diese Woche haben wir die Seite jedoch wieder zu uns gezogen. Wieso, weshalb, warum? Lies weiter!
Perl & Catalyst
Unsere alte Website wurde 2011 gemeinsam mit dem Produkt geboren. Am Design aber auch an der Technik haben wir über die Jahre außer Updates nichts Wesentliches geändert: Perl, Perl, Perl und Hosting auf einem aufgebohrten Uberspace. So waren Website und das Dashboard aus einem Stück und in einer Hand: Jonas. Über die Jahre ist unser guter Chef allerdings aus Entwicklung und Support rausgewachsen, so dass die Seite ohne proaktive Weiterentwicklung da stand. Anderen Kolleginnen fiel es aufgrund der Sprachbarriere schwer, sich in die bestehende Codebase einzuarbeiten.
Die neue Seite
Das alte Perl-Monster musste also weg. Schritt eins: Eine neue Website auf neuer technischer Basis. Mit einem UX Mo bewaffnet hat sich Janto auch gleich ans Werk gemacht. Ein Entwurf stand schnell, HTML war kein Problem, und auch die notwendige Umstellung des Dashboards auf dashboard.uberspace.de war kein großes Problem. Nur, wohin mit der neuen Seite?
Rapid Prototyping? netlify!
Ihr sollt unsere Website und besonders unsere Statusseite is.uberspace.online auch erreichen können, wenn wir Uplink-Probleme haben oder mal ein Server down ist. Deswegen kam ein Hosting auf einem Uberspace wie früher nicht in Frage. Personelle Resourcen, um eine entsprechende Lösung selbst zu bauen, hatten wir nicht. Da wir für’s Manual und Lab aus anderen Gründen bereits auf netlify setzen, war die Entscheidung schnell getroffen.
Unsere Erfahrungen mit netlify für’s Manual und Lab waren durchweg positiv: flotter Support, Bearbeitung von EU-Requests aus der EU, geiles Tooling. Mit unserer Hauptseite uberspace.de sind wir dann jedoch in ein paar Spezialfälle geraten. Zentrales Problem ist, dass netlify mit CNAMEs arbeitet. Für lab. und manual. ist das kein Problem - Records sind schnell erstellt. Für unsere Hauptdomain jedoch schon: Wenn wir dort einen CNAME setzen wird de facto die gesamte Zone zu netlify umgeleitet - inklusive aller Subdomains und deren Records. Bei unseren 30.000 Records stellt das uns und vermutlich auch das netlify-DNS vor ein Problem. Details dazu könnt ihr euch beim ISC abholen.
Am Ende bleibt aber nur: CNAME ist nicht.
Kann man nicht mit CNAMEs arbeiten, bietet netlify eine eigene IPv4-Adresse an, die man als A-Record hinterlegen kann. Der Lösungsansatz hat allerdings zwei Haken:
- Es gibt nur eine IPv4-Adresse. IPv6 ist damit raus.
- Die IP liegt in den USA bei Google. Das ist nicht gerade, wie wir uns Datenschutz vorgestellt haben.
Damit hat netlify leider unsere Erwartungen in puncto Datentransfer Richtung USA, aber auch bei anderen Themen wie z.B. DDoS-Schutz nicht erfüllen können, so dass wir uns schon kurz nach dem Launch nach Alternativen umschauen mussten.
cheapy-cdn
Nun, da die neue Seite raus war, hatten wir wieder ein, zwei Personenstunden frei, um das Hosting wieder in die eigene Hand zu nehmen. Nach ein bisschen Hin und Her sind wir nach ein paar Monaten bei einer Konstruktion aus zwei Servern in zwei Rechenzentren angekommen, sowie einer Pipeline, um die beiden zu befüttern.
Build & Deployment
Am Anfang - im hpnexxter-Repo - unserer länglichen Build-Pipeline steht ein Hugo. Wir haben bei der Entwicklung darauf geachtet, so viel wie möglich über Markdown abzubilden, so dass die Seite für alle Kolleginnen einfach editierbar bleibt. Was nicht ins Markdown gepasst hat, lebt in shortcodes beziehungsweise am Ende natürlich in HTML-Templates und CSS.
Im ersten Schritt wird aus Markdown ein Bündel fertige HTML/CSS/JavaScript-Files. Das Paket hat keine externen Abhängigkeiten und könnte, mit der passenden Serverconfig, genau so gehostet werden. Um uns das Leben in den weiteren Schritten zu erleichtern und die Nachvollziehbarkeit zu verbessern, packen wir das fertige HTML automatisch in’s hpnexxter-dist-Repo. In den nächsten Schritten wird der Code nur noch im Kreis kopiert, jedoch nicht geändert.
Bei jedem Push ins Repo wird die CI-Pipeline von cheapy-cdn angeworfen. Bis zu diesem Punkt war die Pipeline agnostisch gegenüber der letztendlichen Hostinglösung. Nun geht’s aber ans Eingemachte:
- Basissetup der VMs: CentOS, Updates, nginx, Config, …
- Deployment des HTML-Paketes aus
hpnexxter-dist
Sobald die passenden Ansible-Playbooks dazu durchgelaufen sind, ist die Seite auf dem neuesten Stand und kann von euch begutachtet werden.
Verfügbarkeit
Redundanz ist gut, Redundanz ist besser. Deswegen landen unsere Inhalte auf nicht nur einem Server, sondern zwei. Zusätzlich verstecken sich die beiden Server hinter dem DDoS-Schutz der jeweiligen RZs, so dass sie auch bei Angriffen zumindest eingeschränkt erreichbar sind. So ist sichergestellt, dass ein Server oder gar RZ-Ausfall nicht das Ende unserer Kommunikationskette zu euch bedeutet.
Datenhoheit
Von der Build-Pipeline über die unmittelbare Netzwerkhardware bis hin zum Produktionssystem: alle involvierten Komponenten liegen in VMs und letzten Endes auf Blechen, die uns gehören. Tracking kommt, bis auf ein von uns betriebenes Matomo keines zum Einsatz. Jenes arbeitet selbstverständlich ohne Cookies und mit gekürzten IP-Adressen. So können wir garantieren, dass eure Daten nur bei uns liegen und auch dort bleiben.