Wochenrückblick: Cluster, Kriege und Konzeption

Mit dem Aufbau unseres ersten Kubernetes-Clusters machen wir in dieser Woche klar, dass Größenwahn für uns kein Fremdwort ist! :D Doch bevor wir in die Untiefen der IT-Abteilung hinabsteigen, in der mysteriöse Infra-Entwickler ihr Unwesen treiben, kommen wir erst einmal zu etwas völlig Anderem:

Schematics und Klankriege

Wenn es darum geht, Gebäude und andere Strukturen im Spiel abzuspeichern und nach Belieben wieder zu platzieren, sind Schematics ideal. Im letzten Wochenrückblick haben wir von unseren ersten Schritten dazu berichtet. Inzwischen ist es uns nicht nur gelungen, normale Blöcke in Schematics zu speichern, sondern auch kompliziertere Objekte wie Bilderrahmen und sogar Armorstands.

Im letzten Test konnten wir so beispielsweise den kompletten PvP-Spawn in einer 1 Megabyte großen Datei unterbringen und könnten ihn nach Belieben im Spiel erneut platzieren.

Natürlich haben wir dieses Tool nicht zu diesem Zweck entwickelt. Wofür es wirklich gedacht ist? Für den Klankrieg natürlich! Was wir hier entwickeln, bildet die Grundlage dafür, dass wir als Spieler jederzeit größere Belagerungswaffen aufstellen und überall Feldlager errichten können. Es bildet die Grundlage dafür, dass wir uns in fremden Welten mit unser eigenen Burg wiederfinden können, um uns dort mit anderen Klans mitreißende Schlachten zu liefern!

Zugegeben: Wie diese Kriege genau aussehen werden, steht noch in den Sternen. Hier hat sich das Team in dieser Woche durch verschiedene Vorschläge gearbeitet und deren Vor- und Nachteile durchdacht. Da hier einiges an Entwicklungsaufwand hinter steckt, haben wir für die Konzeptionsdetails entsprechend viel Zeit eingeplant.

Welt-Korrekturen

Infrastruktur-Entwicklung

Bereits seit Ende September planen wir schrittweise unsere Infrastruktur noch weiter auszubauen und zu modernisieren. Bislang lief insbesondere das Ausrollen der Änderungen (trotz der Verwendung von Fedora CoreOS, Containern und Ansible) noch recht manuell ab. Wir nutzen übergreifend Docker-Compose und betreiben eine eigene Registry für Container-Images. Führen wir nun im Code also eine Änderung durch, so wird automatisch eine Pipeline angestoßen und ein neues Container-Image wird kompiliert und in unserer Registry verfügbar gemacht.

Anschließend müssen wir jedoch manuell auf den entsprechenden Server gehen, auf dem die Aktualisierung aufgespielt werden soll, und stoßen mit Docker-Compose das Update an. Dadurch werden automatisch alle betroffenen Container-Images heruntergeladen, die entsprechenden Container gestoppt und neue Container mit der aktualisierten Version werden hochgefahren. Diese Art der Wartung verwenden wir so schon lange und das Verfahren ist grundsätzlich auch sicher und (recht) komfortabel. Dennoch hat dieser Ansatz für uns einige Probleme, weshalb wir schon seit einiger Zeit den Schritt zu einem Kubernetes-Cluster planen.

Was Kubernetes ist und was hier alles technisch anders läuft, sprengt den Rahmen eines Wochenrückblicks um ein Vielfaches. In diesem Absatz geht es daher insbesondere um die Vorteile, die dieser Schritt für uns mit sich bringt, die technischen Hürden, denen wir dabei schon begegnet sind oder noch begegnen werden, und was die nächsten Schritte sind.

Kubernetes eröffnet uns die Möglichkeit unsere verteilten Systeme (also Minecraft-Server, Websites, APIs, Entwicklungsplattformen, Test-Instanzen, etc.) komfortabel und losgelöst von physischen Servern auszuführen und sehr übersichtlich zu warten. Wir können Anwendungen also (unabhängig von dem jeweiligen Server, auf dem sie am Ende ausgeführt wird) starten und anpassen und können so den Fokus eher auf die Infrastruktur an sich, als auf die tatsächlichen Prozesse der Wartung lenken.

Wirklich zu einem (schrittweisen) Umstieg bewogen, haben uns in erster Linie aber drei große Vorteile:

• Wir können unseren Entwicklern einfach die Möglichkeit geben beliebig viele Test-Instanzen in unserem Cluster zu deployen (auszuliefern) um so direkt, zusammen mit anderen, neue Funktionen auszuprobieren oder Bugs zu suchen.

• Es ist nun möglich automatisiert direkt aus unserer Entwicklungsumgebung heraus, am Ende einer Pipeline, die Aktualisierung in eine unserer Umgebungen auszuliefern. Dabei können wir zwischen den Versionen für die Entwicklung und für den Produktivbetrieb unterscheiden.

• Konfigurationen und Geheimnisse (Tokens, Passwörter, Kennungen, etc.) können gemeinsam und einheitlich überblickt werden und direkt den Diensten, die sie (beispielsweise als Teil ihrer Konfiguration) benötigen, zur Verfügung gestellt werden.

In dieser Woche haben wir nun also den Grundstein für unseren Umzug zu einem Kubernetes-Cluster gelegt: Das Cluster wurde initialisiert. Das Rahmenwerk für den Umzug steht bereits und die wichtigen, globalen Dienste sind bereits installiert. Nun werden wir in den kommenden Wochen alle unserer Anwendungen nach und nach auf unser Cluster umziehen und Stück für Stück weitere unserer physischen Server in das Cluster einbinden. Obwohl wir bereits seit September keine Anwendung mehr haben, die nicht in einem Container betrieben wird, werden dennoch einige Anpassungen nötig sein um die Vorteile von Kubernetes auch wirklich auszuschöpfen.

Ausblick

Es bewegt sich also vieles hinter den Kulissen. Letztlich dient alles der großen Show, die uns als Spieler bevorstehen soll. Diese Features bilden die Grundlage für spektakuläre Klankriege, grenzenlose Welten und vieles mehr. Einiges erleichtert es uns als Team, diese Träume effektiv umzusetzen.

Wir befinden uns also noch am Anfang dieses Prozesses, aber wir freuen uns schon jetzt über die vielen Vorteile die sich uns dadurch bieten und werden euch in den kommenden Wochen immer mal wieder weitere Fortschritte unseres Umzugs innerhalb der Wochenrückblicke mitteilen! Abonniert uns gerne via Discord, Instagram und per Twitter, um nichts zu verpassen!