Aufbau unserer Teleport-Demoumgebung
Priorität 1: einfach zugänglich
Das Wichtigste an einer Demoumgebung ist, dass sie tatsächlich als solche genutzt werden kann. Der erste Schritt dorthin ist die Zugänglichkeit: Deshalb haben wir sie auf GitHub öffentlich verfügbar gemacht. Darüber hinaus sind weitere Aspekte zu berücksichtigen. Vor allem: Der Code sollte alles Notwendige enthalten, einfach ausführbar und intuitiv kompartimentiert sein, damit man ihn leicht Schritt für Schritt erklären kann.
Der grundlegende Weg dorthin ist, alles als Code zu implementieren – von den unterschiedlichen Cloud-Ressourcen in Terraform über die kleinen Bash-Skripte für deren Einrichtung bis hin zu den Deployment-Pipelines, die sich per Knopfdruck anstoßen lassen. Damit erhält jeder objektive Antworten auf praktische Fragen: der Einsteiger, der sich den Code erstmals ansieht, jemand, der bereits die halbe eigene Stack-Implementierung fertig hat und einen Abgleich sucht, oder auch wir selbst, wenn wir nach längerer Pause zur Demo zurückkehren. In welcher Reihenfolge müssen die Schritte deployed werden? Ein Blick in die passende GitHub-Actions-Konfiguration genügt. Wo wird eine bestimmte Ressource referenziert? Im Terraform-Code nachsehen. Wie richtet man eine neue Teleport-Ressourcenmaschine ein? Das entsprechende Userdata-Skript verrät es.
Damit eng verbunden ist ein weiteres wichtiges Ziel: Die Demo soll sich schnell und einfach starten lassen. Wir führen nicht ständig Demonstrationen durch und vergessen deshalb schon einmal kleinere technische Details – und selbst wenn diese klar dokumentiert sind, fehlt bisweilen die Zeit oder eine stabile Internetverbindung für ausgedehnte manuelle Prozesse. Umso hilfreicher ist es, dass sich unsere Umgebungen mit einem einzigen Klick sowohl deployen als auch wieder abbauen lassen. Wir haben uns dafür für ein weit verbreitetes Continuous-Integration-Tool entschieden, das direkt aus unserem Repository heraus sichtbar ist – also ohne zusätzliche Logins oder externe Links – und sich bequem als Code konfigurieren lässt: GitHub Actions.
Selbstverständlich ist es auch bei vollständiger Automatisierung wichtig zu wissen, was zu tun ist und worauf man achten muss. Genau hier kommt unsere README ins Spiel.
Als nächstes trägt eine klare Strukturierung des Codes maßgeblich zur Zugänglichkeit bei. Das ist naturgemäß ein subjektiverer Aspekt; wir haben ihn angegangen, indem wir die Umgebung nach Stacks gegliedert haben. Ein Stack ist eine Sammlung von Infrastrukturdateien und -ressourcen, die gemeinsam deployed werden. Wir gruppieren sie auf zwei Ebenen: zunächst nach der übergeordneten Art des Deployments, dann nach dessen Stufe. Jeder Ordner im Repository lässt sich entweder als Terraform-Projekt oder als Flux-Konfigurationssatz deployen, wobei bewusst nur wenige Variablen zwischen den Stufen geteilt werden.
Diese Aufteilung zielt darauf ab, jede Deployment-Einheit sowohl logisch als auch codeseitig möglichst in sich abgeschlossen zu halten. Der Blick in einen Ordner sollte reichen, um zu verstehen, warum es ihn gibt, wann er deployed werden sollte und was er benötigt – für eine Demoumgebung essentiell. Und es sollte möglich sein, denselben Code mit minimalen Anpassungen in einen neuen Kontext zu übernehmen. Dieser Aspekt verdient eine genauere Betrachtung.
Priorität 2: einfach anpassbar
Eine Demoumgebung erfüllt zwei Zwecke. Erstens muss sie die relevante Software – in diesem Fall Teleport – so deployen, dass sich das Ergebnis anschaulich vermitteln und leicht reproduzieren lässt. Zweitens soll sie als Vorlage dienen: als Codebasis, die im Demokontext funktioniert, aber mit überschaubarem Aufwand für einen realen Endkunden angepasst werden kann.
Im Fall von Teleport haben wir angenommen, dass es zwei wesentliche Achsen eines Deployments gibt: welche (Public) Cloud verwendet wird und ob der Code auf Kubernetes oder direkt auf Instanzen ausgerollt wird.
Die Wahl der Public Cloud ist stark kundenabhängig – die meisten Unternehmen haben einen oder mehrere bevorzugte Anbieter, die sie bereits nutzen. Wir planen, die Codebasis um weitere Clouds zu erweitern; zum Start unterstützen wir zwei. Angesichts des Teleport-Fokus auf Sicherheit und Kontrolle über die eigene Infrastruktur haben wir den europäischen Anbieter Scaleway für den Großteil der Ressourcen gewählt. Da jedoch einige Datenbank-Features von Scaleway nicht ohne Weiteres mit Teleport kompatibel sind und unsere eigene Think-Ahead-Organisation in Microsoft Azure betrieben wird, haben wir die Datenbank- und Zugriffskomponenten dort integriert.
Zur Wahl des Deployment-Typs: Sowohl Kubernetes als auch Instanzen werden von nahezu jedem Cloud-Anbieter unterstützt, und die zugehörigen Terraform-Ressourcen sind über Anbieter hinweg recht ähnlich – die Deployment-Prozesse selbst unterscheiden sich zwischen beiden Paradigmen jedoch deutlich. Wir haben deshalb beide Varianten vollständig und parallel umgesetzt. Auf Instanzen lässt sich die genaue Konfiguration, die Teleport zum Laufen benötigt, besonders gut nachvollziehen. Wir gehen davon aus, dass unsere Kunden häufiger auf Kubernetes setzen werden – wegen der einfachen Skalierbarkeit und der weitgehend automatisierten Deployments –, doch der dafür erforderliche Code ist unstrittig komplexer.
Herausforderungen
Kein Coding-Projekt läuft völlig reibungslos, und auch unsere Demo hatte ihre Stolpersteine. Da wir Ziele und Deployment-Prozesse weitgehend selbst in der Hand hatten, fielen sie im Vergleich zu vielen anderen Projekten überschaubar aus – ein Rückblick lohnt sich dennoch.
Die größten Reibungspunkte ergaben sich aus dem Unterschied zwischen unserer Demo und den geschäftlichen Kontexten, in denen Teleport normalerweise deployed wird. Konkret: Teleport ist auf langlebige Systeme ausgelegt, mit persistenten Datenbanken und Kubernetes-Clustern, während unsere Demo nur zeitweise genutzt wird und ihre Ressourcen zwischen den Terminen nicht benötigt werden – wir bauen sie daher zwischendurch vollständig ab. Entsprechend sind einige zusätzliche Schritte nötig, um Datenbankstrukturen bei jedem Aufbau neu zu erzeugen.
Unabhängig vom Teleport-Produkt erwies sich die Umsetzung von Kubernetes-Ressourcen über Terraform als schwieriger als erwartet. Über den Cluster selbst hinaus mussten einige Kubernetes-Ressourcen direkt aus Terraform heraus deployed werden, insbesondere solche rund um Secrets und Credentials. Der Terraform-Kubernetes-Provider hat aktuell jedoch die Einschränkung, dass die CustomResourceDefinition einer Ressource bereits zum Zeitpunkt des terraform plan vorhanden sein muss.
Unsere Lösung war, die Kubernetes-Ressourcen in mehrere Stacks aufzuteilen: Secrets lassen sich erst nach ihrem Secret-Provider deployen, der wiederum erst nach dem Cluster selbst hochgefahren werden kann. Sobald Secrets verfügbar waren, haben wir das Problem für die übrigen Ressourcen konsequent mit Flux gelöst – einem GitOps-Tool zur Verwaltung der Kubernetes-Ressourcenkonfiguration. (Wir hätten GitOps auch für das Secret-Deployment einsetzen können, mit Terraform ließ sich jedoch die zusätzliche Komplexität einer Secret-Verschlüsselung, etwa mit SOPS, vermeiden.)
Insgesamt boten diese Herausforderungen jedoch gute Gelegenheiten, das Teleport-Produkt noch besser kennenzulernen, und wir sind mit der entstandenen Demo-Codebasis zufrieden. Schauen Sie sich gerne um!
Was meinen Sie? Fehlen aus Ihrer Sicht Prioritäten, oder möchten Sie Teleport selbst einmal ausprobieren? Buchen Sie ein kostenloses Beratungsgespräch, um zu klären, ob Teleport das richtige Werkzeug für Sie ist – oder um andere Fragen rund um Ihre Infrastruktur zu besprechen.
Offenlegung: Think Ahead Technologies ist offizieller Teleport Reseller und Support Partner. Dieser Artikel spiegelt unsere praktischen Erfahrungen aus dem Einsatz von Teleport bei Kundenprojekten und in internen Umgebungen wider.