Wir bei FullStackS verwenden Terraform für alles, was wir tun. Wir bauen VMs um Kuberneters-Cluster zu deployen, wir installieren und konfigurieren Rancher damit, manchmal verwenden wir sogar Terraform um Terraform Enterprise zu konfigurieren.
Kurzum: Es gibt vieles, bei dem Terraform uns die Arbeit vereinfacht und wir für unsere Kunden tolle Werte kreieren. Darum ist alles was wir als FullStackS machen Infrastructure as Code. Denn letztlich geht es um Geschwindigkeit und Innovation - das sind echte Mehrwerte für unsere Kunden.
Aber warum verwenden wir Terraform Enterprise obwohl Terraform doch OpenSource ist?
Sagen wir es mal so: Aus guten Gründen!
Und genau auf diese Gründe möchten wir im Folgenden eingehen.
Grund 1: Terraform Module und Private Registry
Wir schreiben für unsere Terraform deployments gerne Terraform Module. Diese Module helfen uns wiederkehrende Tasks schnell und einfach zu bearbeiten. Zum Beispiel haben wir Module um bei allen möglichen Cloud-Providern oder Virtualsierungsplattformen VMs zu erstellen, denn VMs braucht man (fast) immer.
Jetzt könnte man ein solches Modul natürlich lokal in einem Unterverzeichnis speichern und im Terraform Root-Modul aufrufen, VM erstellt, fertig.
Aber Stop! Wir arbeiten im Team. Alle brauchen diese Module, und ab und an ändern wir sie auch, fixen einen Bug, etc. Davon sollen alle profitieren.
Letztlich können Unternehmen über Ihre eigenen Terraform Module Ihre DevOpS und IT-Automation ganz nach Ihrer Compliance und Policy im Unternehmen bereitstellen.
Deshalb verwenden wir die Terraform Enterprise Registry. Für jedes unserer Module gibt es ein eigenes Repository in (z.B.) GitHub. Das Repo ist mit Terraform Enterprise verknüpft. Sobald jemand ein neues Release in GitHub anlegt holt Terraform Enterprise sich die neue Version automatisch und jeder kann sie verwenden.
Ein weiterer Vorteil der eigenen Modul-Registry ist natürlich auch das Durchsetzen von Standards. Dadurch, dass alle VMs mit den gleichen Modulen erstellt wurden sind sie alle nach unserem Standard aufgebaut und es gibt im Nachgang keine Überraschungen.
Grund 2: Terraform Enterprise Workspaces
Jetzt haben wir unsere Module in der Registry und können sie in Projekten verwenden. Auch das machen wir mit Terraform Enterprise. Wir legen uns dazu einen sog. Workspace an. Auch hier bietet Terraform Enterprise die Möglichkeit ein Repository zu verknüpfen. Pusht man einen Change in Git kann z.B. gleich ein "terraform plan" automatisch ausgeführt werden.
Aber nun der Reihe nach:
Was ist ein Terraform Workspace?
Im Workspace werden alle wesentlichen Elemente zusammengefasst und können "an einem Schopf" gepackt werden:
Terraform State
Alle Variablen
Zugriffsberechtigung (RBAC)
Workflows
Benachrichtigungen (z.B. WebHooks, Slack, Teams, etc.)
Als erstes erstellen wir ein Repository in Github und erstellen darin unseren Terraform-Code. Im Beispiel verwenden wir gleich eines unserer Module aus unserer Terraform Enterprise Registry
Nun erstellen wir einen Workspace in Terraform Enterprise vom Typ „VCS“ (Version Control System) und wählen unser GitHub Repository als Quelle.
Neben dem "GitOps" VCS Workflow bietet Terraform Enterprise noch weitere Möglichkeiten:
CLI Driven Workflow: mit Terraform als Single "Go" Binary in einer Shell
API Driven Workflow: Integration in bestehende Systeme, wie z.B. ServiceNow
Ein kleines Problem haben wir noch: "Wohin mit den Variablen?"
Lokal ist das nicht so das Problem, z.B. die Credentials für das vCenter in ein terraform.tfvars file zu schreiben. Aber in GitHub möchten wir die natürlich keinesfalls sehen. Keep calm!
In Terraform Enterprise können Werte für Variablen gespeichert werden. Es bringt dazu einen internen Vault mit in dem unsere Variablen sogar verschlüsselt liegen.
Damit haben wir alles erledigt und können unseren Terraform Code laufen lassen. Das geht mit einem Klick in der UI:
Gibt es Änderungen im Terraform Code, wird also ein Commit in das Repository gepushed, führt Terraform Enterprise automatisch einen „terraform plan“ aus. Mit einem Klick bestätigen wir den Plan und der „terraform apply“
startet.
Grund 3 - X:
Es gibt noch viel mehr gute Gründe, die für Terraform Enterprise sprechen. Diese sind auch gute Gründe für weitere Blog Posts - dazu zählen unter anderem:
Cost Estimation für Cloud Ressourcen und Budgeting
Compliance und Approval
Auditing
Revisionssicherheit
Sentinel - Policy as Code - als Framework für "highly compliant and regulated DevOps" im Enterprise - extrem spannend!
Guiding Principle & Vision: Self Service & Automation
Letztendlich erlaubt uns Terraform Enterprise den Aufbau von durchgängigem und vor allem "compliant" Workload und Lifecycle Management in modernen Unternehmen.
Selbstverständlich in Pipelines (CI/CD) integriert und auf Wunsch auch komplett abgesichert - so, dass niemand mehr auch nur ein Credential in die Finger bekommt - z.B. mit "Secure Infrastructure Pipelines" mit Hashicorp Vault.
Wie das funktioniert? Sprechen Sie uns gerne an!
