heise online: Die Technik hinter den Kulissen
Das Developer-Team berichtet, wie die Architektur von heise online entstanden ist, und zeigt, wie heute eine Applikation bei uns entwickelt wird.
Das Developer-Team berichtet, wie die Architektur von heise online entstanden ist, und zeigt, wie heute eine Applikation bei uns entwickelt wird.
Vor einiger Zeit erreichte uns die Frage eines Lesers, wie die Technik hinter heise online eigentlich aussieht. Der Frage nehmen wir uns an und begleiten eine Applikation bei ihrer Entwicklung. Doch zunächst gibt es einen kleinen Rückblick über die Entstehung der Technik hinter dem Web-Angebot von heise online.
"We had joy, we had fun, we had Linux on a SUN..."
Die Legende besagt, dass der erste Webserver des Hauses auf dem Redaktionsserver der iX lief, doch seitdem ist viel passiert. Dieser Webserver wurde auf der CeBIT 1994 gezeigt. Erste Vorboten des späteren IT-Nachrichten-Portals waren vereinzelte IT-Meldungen im Dezember 1995, und zur CeBIT 1996 startete dann der "Newsticker". Schon im Jahr 2000 verkündeten wir, dass unsere Webserver von einer Sun E450 in Hannover in ein Server-Cluster von Plus.line in Frankfurt umziehen. Bereits damals standen vor den Servern zwei Load-Balancer (BIG-IP) von F5.
Die Weiterentwicklung unserer Systeme aus Admin-Sicht fasste mein Kollege Eckebrecht von Pappenheim 2016 anlässlich des 20. Geburtstags von heise online zusammen. Geändert hat sich seitdem beispielsweise, dass wir das Bild-Hosting zum Dienstleister Cloudimage ausgelagert haben, die Bildskalierung nicht mehr selbst vornehmen, und auch von unserem Kubernetes-Cluster war damals noch nichts zu lesen.
Das große Schiff oder der kleine Container?
Um die heutige Entwicklung von heise online zu betrachten, verfolgen wir einfach mal die Entwicklung einer Applikation. Grundsätzlich gibt es zwei Möglichkeiten, wo eine Applikation bei uns ihren Anfang nehmen kann. Das sind zum einen die sogenannten Daves – das sind virtuelle Server, die quasi ein kleines heise online sind. Jede Entwicklerin und jeder Entwickler von uns hat so einen Dave zur Verfügung, manche auch mehrere. In der Regel wählt man sich dort per SSH ein, Ansible und Git-Pulls halten Codebase und Konfigurationen aktuell. Debian sind wir als Server-Betriebssystem treu geblieben und erfreuen uns aktuell an Buster. Sogar einen eigenen Varnish-Cache bringt ein Dave mit, jedoch ist dieser für die Entwicklung einfach ein-/ausschaltbar, schließlich ist es bei der Entwicklung nicht immer hilfreich, "alten" Content zu sehen.
Woher der Name "Dave" kommt? Ein Wortspiel, das vermutlich an "Dev" angelehnt ist, aber so ganz genau kann das kaum noch jemand bei uns rekonstruieren.
Nostalgie gefällig?
Wer ein wenig in der Vergangenheit schwelgen möchte, findet hier eine kleine Link-Sammlung zu Beiträgen, in denen wir in der Vergangenheit von der Technik hinter heise online berichtet haben.
- c't 6/99 S. 272 "Stets zu Diensten"
- heise online mit neuer Technik - Webserver im Umzugskarton
- 10 Jahre heise online
- c't 7/04 S.90 "Online-Geburtstag"
- "Ungluablich": 10 Jahre Newsticker bei heise online
- 20 Jahre heise online: Nichts ist nur Geschichte, nichts ist nur Zukunft
- Die Technik hinter heise online
Im Gegensatz zur Applikationsentwicklung auf den Daves haben wir auch zunehmend mehr Applikationen auf Node.js-Basis, die wir in Docker-Images verpacken. Diese können daher problemlos auf dem lokalen Gerät entwickelt werden. Für Docker-Container und Node-Packages haben wir jeweils eigene Registries – die einen für private Container und Pakete, die anderen einfach als Cache.
Wer bei uns anfängt, kann sich das Arbeitsgerät aussuchen, und so haben wir in der Abteilung Macs, Computer mit Windows und natürlich auch einige mit Linux-Kernel. In der Regel werden wir alle mit Laptops ausgestattet, um mobil arbeiten zu können (unabhängig von Corona) und um schnell mal mit dem Gerät zu jemandem gehen und etwas zeigen oder besprechen zu können, ohne sich einen Tower unter den Arm klemmen zu müssen.
Versionierung, Austausch, Tests
Egal wo der Code entsteht, versioniert wird auf einem gemeinsamen Git-Server. Als Git-Frontend und für Continuous Integration benutzen wir GitLab. Nach jedem Commit werden automatisiert Tests durchgeführt. Hier kommt es ein bisschen auf die Art des Projekts an – die Tests können auf einer Dave-ähnlichen Maschine stattfinden (virtualisiert) oder im hannoverschen Kubernetes-Cluster, falls es sich um eine Anwendung in einem Container handelt.
Auf einem Test- und einem Beta-System können wir eine Applikation oder eine Code-Änderung in einer möglichst live-nahen Umgebung testen. Dabei handelt es sich technisch um zwei Server aus dem Live-Cluster, die vom Load-Balancer ausgenommen sind.
Fertig? Raus damit
Sind alle Tests erfolgreich, wird der Code in den Master-Branch gemergt und mittels GitLab CI deployt. Handelt es sich um Container, werden diese fortan von unserem Kubernetes-Cluster in Frankfurt ausgeliefert, ansonsten übernimmt unser Server-Cluster mit echten Maschinen die Auslieferung – wir sprechen hier von den Octos, es sind genau genommen 14 Maschinen. Diese kommunizieren nicht direkt mit den Clients, sondern dazwischen stehen noch ein Load-Balancer (BIG-IP von F5) und ein Varnish, der für ausreichend Caching der redaktionellen Seiten sorgt.
CMS
Neben unseren Applikationen gibt es das Content Management System (CMS). Es umfasst zwei Server, ein Live- und ein Backup-System. Im CMS geben die Redakteurinnen und Redakteure all die Inhalte ein, die bei heise online gelesen werden können. Die Auslieferung findet allerdings gar nicht mehr direkt über das CMS statt, sondern fast ausschließlich über eine JSON-Schnittstelle, deren Ausgabe dann weiterverarbeitet wird, was uns mehr Freiheiten für die Entwicklung gibt.
Damit sind wir am Ende unserer kleinen Technik-Reise. Dank der rasanten Veränderung in der Web-Entwicklung wird sich sicherlich in den nächsten Jahren auch bei uns wieder einiges verändern, über das es sich dann zu berichten lohnt. (hih)
