ADMIN

2022

02

2022-01-30T12:00:00

Cloudmanagement

TESTS

028

IT-Infrastruktur

Hashicorp Terraform Enterprise

Weltenbauer

von Dr. Guido Söldner

Veröffentlicht in Ausgabe 02/2022 - TESTS

Hashicorp hat mit Terraform schon seit Jahren eine umfassende Deploymentsoftware für Infrastructure-as-Code am Start. Mittlerweile ist Terraform in Version 1.0 verfügbar und neben der Open-Source-Variante hat der Hersteller sein Werkzeug als Clouddienst und für die lokale Installation im Angebot. Diese kostenpflichtigen Versionen bieten zusätzliche Features für das zentrale Verwalten und Ausführen von Terraform-Code, die Sicherheit, die Erweiterbarkeit und die Integration in Drittprodukte.

Terraform Enterprise als Werkzeug für Infrastructure-as-Code (Iac) liegt aktuell in vier Versionen vor, wobei die "Free"-Variante sich vor allem an einzelne Entwickler richtet. Sie bietet ein grafisches Portal zur Verwaltung des eigenen "Terraform State" und für das Modulmanagement steht eine Module Registry bereit. Support seitens des Anbieter gibt es hier nicht – dieser muss von der Community bezogen werden. Die "Team & Governance"-Edition erweitert die Free-Version auf Teams und erlaubt den Einsatz von Sentinel. Dabei handelt es sich um ein Policy-Framework, das dem Nutzer einzuschränken erlaubt, was Terraform deployen kann. Die Variante wird pro User lizenziert und bringt auch Support durch den Hersteller mit.
An Großkunden richtet sich die Business-Variante, die Enterprise-Features wie Single Sign-on, Auditprotokollierung, Agenten und Premium-Support bietet. Als selbst installierbare Version steht Terraform Enterprise bereit. Diese selbstbetriebene Software bietet vergleichbare Features wie ihr Terraform-Pendant in der Cloud, das wir im Folgenden unter die Lupe nehmen.
Schnell zum ersten Workspace
Das initiale Einrichten der in der Cloud gehosteten Version gestaltet sich sehr einfach und gelingt in wenigen Minuten. Nachdem wir uns registriert hatten, konnten wir uns an das Anlegen eines Workspaces machen. Hashicorp bietet dafür einen Workflow an, der aus wenigen Schritten besteht: Im ersten galt es, einen Workflow-Typ auszuwählen. Dazu konnten wir Terraform entweder an ein Git-Repository binden, um Terraform-Läufe basierend auf Requests oder Merges auszuführen, Terraform per CLI anzutriggern oder mittels der Terraform-API anzusteuern. Kommt ein Git-Repository zum Einsatz, ist die dortige Anmeldung mit den entsprechenden Credentials erforderlich. Abschließend lässt sich festlegen, welche Repositories genutzt werden.
Terraform Enterprise als Werkzeug für Infrastructure-as-Code (Iac) liegt aktuell in vier Versionen vor, wobei die "Free"-Variante sich vor allem an einzelne Entwickler richtet. Sie bietet ein grafisches Portal zur Verwaltung des eigenen "Terraform State" und für das Modulmanagement steht eine Module Registry bereit. Support seitens des Anbieter gibt es hier nicht – dieser muss von der Community bezogen werden. Die "Team & Governance"-Edition erweitert die Free-Version auf Teams und erlaubt den Einsatz von Sentinel. Dabei handelt es sich um ein Policy-Framework, das dem Nutzer einzuschränken erlaubt, was Terraform deployen kann. Die Variante wird pro User lizenziert und bringt auch Support durch den Hersteller mit.
An Großkunden richtet sich die Business-Variante, die Enterprise-Features wie Single Sign-on, Auditprotokollierung, Agenten und Premium-Support bietet. Als selbst installierbare Version steht Terraform Enterprise bereit. Diese selbstbetriebene Software bietet vergleichbare Features wie ihr Terraform-Pendant in der Cloud, das wir im Folgenden unter die Lupe nehmen.
Schnell zum ersten Workspace
Das initiale Einrichten der in der Cloud gehosteten Version gestaltet sich sehr einfach und gelingt in wenigen Minuten. Nachdem wir uns registriert hatten, konnten wir uns an das Anlegen eines Workspaces machen. Hashicorp bietet dafür einen Workflow an, der aus wenigen Schritten besteht: Im ersten galt es, einen Workflow-Typ auszuwählen. Dazu konnten wir Terraform entweder an ein Git-Repository binden, um Terraform-Läufe basierend auf Requests oder Merges auszuführen, Terraform per CLI anzutriggern oder mittels der Terraform-API anzusteuern. Kommt ein Git-Repository zum Einsatz, ist die dortige Anmeldung mit den entsprechenden Credentials erforderlich. Abschließend lässt sich festlegen, welche Repositories genutzt werden.
Die Workspaces dienen dazu, verschiedene Deployments, die auf demselben Code basieren, zu trennen. Bei den kommerziellen Tools stehen diese Workspaces im Vordergrund und Hashicorp baut den kompletten Terraform-DevOps-Lifecycle darauf auf. Jeder Workspace umfasst eine Menge von Variablen, die sich entweder von einer Datei aus oder einzeln befüllen lassen. Bei vielen Einstellungen zwingt Terraform den Nutzer, sich genau an die Vorgaben zu halten. Dies beinhaltet beispielsweise die Nomenklatur von Variablendateien oder die genaue Unterordnerstruktur, aus der das Tool den Code bezieht. Wer mehr Flexiblität benötigt, kann die CLI nutzen und sich von dort bei Terraform in der Cloud anmelden. In diesem Fall erfolgt die Steuerung über die CLI und nicht mehr via GUI. Nichtsdestotrotz lassen sich Aktivitäten in der grafischen Benutzeroberfläche nachvollziehen.
Das Zusammenspiel mit Git (daneben existiert Unterstützung für GitLab, BitBucket und Azure DevOps) ist sehr eng. Der übliche Workflow gestaltet sich dermaßen, dass der IT-Verantwortliche seinen Code in GitLab verwaltet. Dabei ist eine Integration von Terraform in Merge-Requests möglich. So lässt sich beispielsweise das Ausführen eines "terraform-plan"-Befehles in eine Pipeline integrieren und Änderungen abhängig vom Ergebnis in einen Zielbranch übernehmen.
Gute Visualisierung der Abläufe
Gut gelungen ist die grafische Visualisierung der durchgeführten Terraform-Läufe. Wir konnten auf einem Blick erkennen, was der aktuelle Terraform-Zustand ist, welche Läufe es in der Vergangenheit gab, wer sie durchgeführt hat, ob sie erfolgreich waren oder auf welcher Code-Basis sie erfolgt sind. Für das Trouble-shooting stand zudem für jedem Lauf der Output zur Verfügung.
Hilfreich sind auch die Metriken, die Terraform zu den Workspaces erstellt. Hier waren wir in der Lage zu sehen, wie viele Läufe in den letzten Wochen stattfanden, wie lange diese im Durchschnitt gedauert haben und wie viele davon erfolgreich beziehungsweise nicht erfolgreich waren. Ein weiteres Feature ist die automatische Bereitstellung der Terraform Binaries. Diese mussten wir nicht selbst installieren, sondern sie waren in verschiedenen Versionen verfügbar. Pro Workspace konnten wir zudem definieren, welche Terraform-Version für die Deployment-Vorgänge genutzt werden soll.
Bild 1: Alle Terraform Workspaces finden sich zentral in der GUI. Dort lassen sich auch überwachte Metriken dazu aufrufen.
Flexibel arbeiten dank State-Files
Ein weiteres zentrales Feature stellt die Terraform Registry dar. Diese erlaubte es uns, eigene Module zentral zu veröffentlichen und auffindbar zu machen – dies ist insbesondere in abgeschotteten Umgebungen ohne direkten Internetzugriff ein wichtiges Feature. Dabei erlaubt die Registry auch das Hochladen von Providern (beispielsweise die der Cloudprovider AWS, Azure oder Google) – diese kapseln die APIs der zu automatisierenden Produkte und werden für jeglichen Terraform-Lauf benötigt. Neben dieser zentralen Speicherung ist insbesondere die Möglichkeit der Versionierung interessant, die sich beim Aufruf von Modulen konfigurieren lässt.
Terraform verwendet intern State-Files, um den aktuellen Zustand des Deployments abzuspeichern. Ändert sich etwas an der Konfiguration im IaC-Code, kann Terraform davon ableiten, welche Anpassungen der Infrastruktur notwendig sind. Die Open-Source-Variante von Terraform passt somit bei jedem Change in der Infrastruktur auch das State-File an. Nichtsdestotrotz kann es beim Debugging hilfreich sein, Zugriff auf das alte State-File zu erhalten. Hier bietet Hashicorp in seinen Terraform-Cloud- und -Enterprise-Versionen Abhilfe: Für jeden Workspace waren wir in der Lage, die Historie der State-Files und somit die einzelnen Versionen zu betrachten. Allerdings beschränkt sich die grafische Benutzeroberfläche auf die Anzeige der State-Files, ändern lassen sich diese nur per CLI.
Hat die IT bislang die freie Variante von Terraform genutzt und ist nun zur Terraform Cloud oder Terraform Enterprise gewechselt, ist der Transfer der State-Files leicht durchführbar. Eine derartige Migration erfolgt in wenigen Schritten, zuerst sind dafür allerdings alle laufenden Terraform-Jobs abzubrechen. Anschließend lassen sich die State-Files in das neue Root-Verzeichnis umkopieren und dies mit dem "terraform init"-Befehl festzurren. Anschließend ist nur noch eine kleine Änderung an der Backend-Konfiguration nötig.
Hashicorp Terraform Enterprise
Produkt
Infrastructure-as-Code-Werkzeug zum Erzeugen, Ändern und Verwalten von IT-Infrastrukturen.
Hersteller
Hashicorp
Preis
Terraform kommt mit unterschiedlichen Lizenzmodellen: Während die Free-Edition kostenfrei, aber ohne Support ist, fällt bei der "Team & Governance"-Variante ein Betrag von 20 US-Dollar pro User an. Für eine größere Anzahl an Usern gibt es entsprechend Preisabschläge. Bei der Business- und Terraform-Enterprise-Variante hat Hashicorp ein anderes Preismodell: Hier dient die Anzahl der genutzten Workspaces als Preisbasis und pro Workspace sind mindestens 1000 Euro zu veranschlagen.
Systemanforderungen
Für die Hardware, auf der Terraform läuft, sind mindestens 10 GByte Plattenplatz im Root-Volume und 40 GByte Plattenplatz im Docker-Data-Directory erforderlich. Zudem sind 8 GByte RAM und vier CPU-Kerne notwendig.
Darüber hinaus gibt es zahlreiche Voraussetzungen in Sachen Netzwerk, Betriebssystem, Storage und Sicherheit, die von der Art der Terraform-Installation abhängen.
Technische Daten
Detaillierte Steuerung und Security mit Policies
Ein weiterer wichtiger Bereich, den Hashicorp mit seinen kommerziellen Terraform-Varianten adressiert, ist "DevSecOps" (Development, Security und Operations). DevSecOps hat zum Ziel, bereits in der Entwicklung eine zusätzliche Sicherheitsebene zu integrieren und so die Lücke zwischen Entwicklungs- und Security-Team zu schließen. Im Idealfall kann dies so geschehen, dass möglichst viele Sicherheitsprozesse automatisiert ablaufen beziehungsweise vom Entwicklungsteam selbst erledigt werden können.
Hier setzt Terraform mit Sentinel an, das in jeder Edition aufwärts von "Team & Governance" dabei ist. Kurz gesagt handelt es sich dabei um ein Embedded-Policy-as-Code-Framework, mithilfe dessen sich feingranularer, mit Logik versehener Code implementieren lässt. Dieser wiederum überprüft, ob anderer Terraform-Code zur Ausführung erlaubt sein sollte oder nicht. Das Arbeiten mit Sentinel umfasst dabei verschiedene Schritte:
- Implementierung der Policies.
- Definieren, welche Workspaces auf welche Policies hören.
- Zur Laufzeit werden Sentinel-Policies ausgeführt, sobald der "terraform plan"-Befehl abgeschlossen ist und bevor der "terraform apply"-Befehl zur Ausführung kommt.
- Zum Ausführen der Sentinel-Checks kann Terraform Cloud mit Mock-Daten arbeiten. Dabei handelt es sich um Platzhalter für echte Objekte, die keine Echtdaten, sondern vorher zum Testfall passend festgelegte Werte zurückliefern.
Beim Verfassen einer Policy geht es also darum, eine Reihe von Regeln zu definieren, die später basierend auf der Ausgabe eines "terraform plan"-Kommandos überprüft werden. Sobald wir nun eine Policy definiert hatten, mussten wir noch angeben, wie die Regeln zur Laufzeit angewandt werden. Dabei standen verschiedene Konfigurationsmöglichkeiten zur Auswahl: Mit "Advisory" wird das Ergebnis der Policy nur protokolliert, es erfolgt aber kein Abbruch im Falle eines Regelverstoßes. Der "Soft Mandatory"-Modus erlaubt es privilegierten Team-Mitgliedern, das Ergebnis des Policy-Checks zu ignorieren – eine Protokollierung findet aber statt. Der Standardmodus ist "Hard Mandatory", der bei einem Regelverstoß die Ausführung des Codes verhindert.
Die Dateien, die die Policies konfigurieren, lassen sich in ein Git-Repository laden und dann in Terraform Cloud auf dieses Repository verweisen. Aktiviert der Nutzer nun für einen Workspace die Sentinel-Policies, starten diese beim Ausführen eines Terraform-Laufes.
Ein weiteres Feature der Terraform-Policies ist die automatische Kostenabschätzung. In jüngster Zeit hat sich Hashicorp bemüht, für einen immer größeren Kreis von Ressourcen die Kosten zu visualisieren. Zur Laufzeit hatten wir so Einblick in die erwarteten Kosten beziehungsweise konnten das Deployment abbrechen, falls die Ausgaben einen gewissen Betrag übersteigen. Insgesamt sind somit Sentinel-Policies ein wichtiges Feature in Sachen Terraform-Security – allerdings validieren sie ausschließlich Terraform-Code.
Bild 2: Terraform kann berechnen, welche Kosten die eingesetzten Cloudressourcen verursachen.
Mit Cloudagenten in private Umgebungen deployen
Insbesondere größere Unternehmen haben ihre Netzwerke abgeschottet, sodass die zum Deployment notwendige API nicht immer öffentlich zugänglich ist. Dies kann zum einen der Fall sein, wenn es um lokale Umgebungen beispielsweise basierend auf vSphere, Nutanix oder OpenStack geht, die Cloudumgebung isoliert ohne Internet-Break-out ist oder in der Cloud die Systeme hinter mehreren VPC-Peerings versteckt sind. Zu diesem Zweck stellt Hashicorp die sogenannten Terraform Cloud Agenten bereit, die Teil von Terraform Cloud for Business und Terraform Enterprise sind. Die Kommunikation zwischen Agenten und der Terraform-Software findet Pull-basiert statt, das heißt, der Verbindungsaufbau geht von den Agenten aus.
Die Agenten stehen als Docker-Containern bereit und sind auf Dockerhub verfügbar. Auf Linux-x86_64-Bit-Betriebssystemen lassen sie sich leicht zum Laufen bringen. Sind also bei der Terraform-Ausführung zusätzliche Tools notwendig, ist es einfach möglich, sich ein eigenes Container-Image zu bauen und dieses in Produktion zu bringen. Bedauerlicherweise sind die Agenten als VMs zu betreiben. Der Einsatz innerhalb eines Kubernetes-Clusters brächte Vorteile in Sachen Hochverfügbarkeit und Skalierbarkeit mit sich.
Begrenzte Erweiterbarkeit
In den meisten Umgebungen kommt Terraform nicht isoliert zum Einsatz, sondern muss in eine bestehende Infrastruktur integriert werden. Von Haus aus die engste Verzahnung erfahren die verschiedenen Versionsverwaltungstools wie zum Beispiel GitHub oder GitLab. Darüber hinaus bietet Hashicorp aber auch eine API an, mit der jegliche Funktionalität der GUI auch programmatisch zur Verfügung steht. Die Authentifizierung gegenüber der API findet wie in vielen anderen Produkten auch mittels eines Bearer-Tokens statt, das in Form eines User-Tokens (an einen Benutzer gebunden), eines Team-Tokens und eines Organisation-Tokens existiert.
Daneben stellt Hashicorp "go-tfe" bereit – dies ist ein Client, der in der Programmiersprache Go implementiert ist. Wem das nicht genug ist, der kann sich verschiedener anderer Clientbibliotheken bedienen. Diese existieren unter anderem für die Programmiersprachen Python, Ruby, .NET sowie Linux Shell, sind aber offiziell nicht von Hashicorp, sondern werden von der Community bereitgestellt. Mithilfe dieser Tools ist eine einfache Integration von Terraform Cloud oder Enterprise in andere Anwendungen möglich.
Kritik gibt es allerdings bei der Erweiterung der Pipeline. Dies ist laut Hashicorp nicht vorgesehen und allen Produkten fehlt die Möglichkeit, eigene Schritte in die Pipeline einzubauen. Für viele Firmen stellt sich daher an dieser Stelle die Frage, ob sich deswegen der Einkauf von Terraform in einer kommerziellen Edition lohnt. Für einfache Anwendungsfälle ist Hashicorps Lösung sehr verlockend, beschäftigt sich der IT-Verantwortliche aber tiefergehend mit der Thematik, ist diese Frage nicht mehr so einfach zu beantworten. Schließlich bieten alle Public-Cloud-Anbieter von Haus aus schon ein Pipeline-System, in das sich Terraform einfach integrieren lässt.
Auch der Einsatz einer Private-Terraform-Registry ist mit frei erhältlichen Tools möglich. Zudem unterstützen DevOps-Plattformen wie zum Beispiel GitLab einen Großteil des Funktionsumfangs von Terraform, sind aber deutlich flexibler erweiterbar und haben auch eine breite Integration in Fremdsysteme. Folgerichtig setzen viele größere Umgebungen neben Terraform auch zusätzlich eine Pipeline-Lösung ein.
Bild 3: Mittels der Terraform-Integration in ServiceNow können Endbenutzer Terraform per Self-Service ausführen.
Integration in andere Produkte
Daneben existiert auch eine direkte Integration in verschiedene andere Tools. Natürlich ist Terraform eng mit den anderen Hashicorp-Produkten wie Hashicorp Vault, Consul oder Nomad verzahnt. Besonders hervorzuheben ist dabei die gelungene Zusammenarbeit mit Vault, einem Speicher für Anmeldedaten.
Darüber hinaus existiert eine Integration in ServiceNow, die erlaubt, auf ServiceNow die Terraform Cloud Integration Software zu installieren. So sind Endbenutzer in ServiceNow dazu in der Lage, durch Terraform bereitzustellende Ressourcen im Self-Service zu erzeugen und zu konsumieren. Hierzu ist jedoch eine Terraform-Enterprise- beziehungsweise Terraform-Cloud-Lizenz im Business Tier notwendig. Für viele Firmen ebenso relevant ist die Splunk-Integration. Dabei ist ein Übertragen der Audit-Logs zu Splunk möglich. Hier gelten jedoch die gleichen Lizenzvoraussetzungen wie bei der ServiceNow-Integration.
Fazit
Mit den kommerziellen Editionen von Terraform erweitert Hashicorp sein Automatisierungstool um zahlreiche Enterprise-Features. Im Zusammenspiel mit einem DevOps-Pipeline-Tool können Firmen damit eine komplette CI/CD-Strecke für Infrastructure-as-Code aufbauen. Zu bemängeln ist allerdings das Preismodell für die Enterprise-Edition, das nach Workspaces abrechnet und leicht ein K.O.-Kriterium bei der Einführung werden kann.
(jp)
So urteilt IT-Administrator
Bewertung
Verwalten und Ausführen von Code 8 Kollaboration 7 Governance und Sicherheit 7 Erweiterbarkeit 3 Integration in Drittprodukte 6
Dieses Produkt eignet sich
optimal
für das Aufsetzen von Umgebungen in Public Clouds.
bedingt
bei der Automatisierung lokaler Systeme, da es hierfür vielfach keine Unterstützung durch die Hersteller gibt.
nicht
als DevOps-Plattform, da Terraform wichtige Features fehlen, wie zum Beispiel erweiterbare Pipelines.