Terraform bei durchblicker.at: Infrastruktur‑Konfiguration auf das nächste Level heben

Kontext: „Raising Infrastructure Configuration to the next Level“ mit Johannes Brottrager (durchblicker.at)

Als größtes Vergleichsportal in Österreich verarbeitet durchblicker.at rund 15.000 Vergleiche pro Tag – von Versicherungen über Energie bis Banking. In der Session „Raising Infrastructure Configuration to the next Level“ gab Johannes Brottrager (Full‑Stack‑Entwickler bei durchblicker.at) einen konzentrierten Einblick, wie das Team seine Infrastruktur Schritt für Schritt professionalisierte und mit Terraform auf eine verlässlichere, reproduzierbare Basis gestellt hat. Es ist keine Terraform‑Grundlagenschulung, sondern ein präziser Erfahrungsbericht mit Mustern, die Teams in ähnlich gewachsenen Umgebungen sofort weiterhelfen.

Wir fassen die Herausforderungen, Entscheidungen und Lessons Learned zusammen – aus Sicht von DevJobs.at, mit Fokus auf die praktischen Muster, nicht auf Folien.

Vom Startup‑Wildwuchs zur reproduzierbaren Infrastruktur

Ausgangslage: verteilt, manuell, schwer zu pflegen

Der Weg von der Startup‑Phase zur etablierten Produktorganisation hinterließ – wie bei vielen Scale‑ups – Spuren in der Infrastruktur:

• Verschiedene Clouds: AWS, GCP, DigitalOcean, Azure, Hetzner – dazu ein Bare‑Metal‑Server im Firmengebäude. Diese Mischung erleichtert schnelle Experimente, erschwert aber im Betrieb Transparenz, Konsistenz und Automatisierung.
• Prozedurale Provisionierung: Vieles wurde mit Ansible verwaltet. Ansible ist stark für Konfigurationsmanagement über SSH, bleibt aber prozedural: Man beschreibt „wie“ statt „was“. Für übergreifende, idempotente Zustände über mehrere Provider hinweg stößt dieser Ansatz schneller an Grenzen.
• Inkonsistente Testumgebungen: Weil Konfigurationen nicht stringent versioniert waren, konnte jede:r „mal schnell“ an Testsystemen drehen. Der nächste Mensch, der das System brauchte, fand dann womöglich eine unerwartete, intransparente Konfiguration vor.
• Update‑Druck: Betriebssystem‑ und Paket‑Updates über eine Vielzahl unterschiedlich verwalteter Server hinweg waren fehleranfällig und aufwändig – inklusive Risiko, sicherheitsrelevante Updates zu verpassen.

Das Team brauchte also klare Zuständigkeiten, definierte Zustände, reproduzierbare Setups und weniger manuelle Pflegearbeit.

Der Lösungsweg: Provider harmonisieren, Managed Container, Terraform

Durchblicker.at entschied sich für drei große Schritte:

1) Harmonisierung der Cloud‑Provider

• Der Betrieb wurde primär auf GCP konsolidiert. Damit reduzieren sich Reibungsverluste in Provisionierung und Betrieb, und Features/Services lassen sich einheitlicher nutzen.

2) Managed Containerumgebungen

• Statt Servern „überall“ setzt das Team auf gemanagte Container‑Laufzeiten. Das verringert OS‑Pflegeaufwand und passt besser zu elastischen Lastprofilen. Im Talk illustriert Johannes das anhand von Cloud Run: Container‑Images werden nach Bedarf gestartet, skaliert und wieder abgeschaltet.

3) Infrastructure as Code mit Terraform

• Deklarativ statt prozedural: In Terraform wird der Zielzustand beschrieben („welche Ressourcen mit welchen Parametern?“), nicht die Abfolge der Schritte. Terraform berechnet den Plan und setzt ihn um.
• Versionierung: Infrastruktur‑Definitionen als Textdateien im VCS gewährleisten Transparenz, Nachverfolgbarkeit und Reproduzierbarkeit.
• Multi‑Cloud‑Fähigkeit: Terraform unterstützt große Provider. Das erleichtert graduelle Migrationen oder eine bewusste Multi‑Cloud‑Strategie – ohne Toolbruch.
• Einfache Änderung: Parameter anpassen, Plan prüfen, anwenden – Terraform orchestriert die Abhängigkeiten. Oder, in Johannes’ Worten: Ein terraform apply, und die Änderungen sind ausgerollt.

Ein „Hello World“ ohne Code‑Ballast

Im Talk skizziert Johannes ein minimales Beispiel für eine Cloud‑Run‑Service‑Definition: Ressourcentyp, Name und Location; ein Template mit Container‑Image und Limits (z. B. 1 CPU, 512 MB RAM) sowie ein Traffic‑Split (100 % auf die neue Revision). Der Punkt ist nicht der Code selbst, sondern die Lesbarkeit: Wer die Ressource anschaut, versteht, „was“ bereitgestellt wird – ohne Mustersuche in Shell‑Skripten.

Ein Muster für Dev/Staging/Prod ohne Copy‑Paste

Ein zentrales Ziel war es, mehrere Umgebungen konsistent und ohne redundante Konfigurationen zu betreiben: Development, Staging/Testing und Production. In Terraform bedeutet Wiederverwendbarkeit: Module.

Module als Bausteine

• Ein gemeinsames Modul verwaltet z. B. eine Cloud‑Run‑Anwendung. Parametrisierbar sind betriebssensitive Einstellungen wie min/max Scale, Memory oder CPU‑Throttling. Das Team kann so pro Umgebung sinnvolle Standardwerte setzen, ohne das Grundgerüst mehrfach zu pflegen.

„config file location“ als Schalter zur Laufzeit

• Besonders elegant ist der Umgang mit Umgebungs‑Konfigurationen: Statt mehrere Artefakte zu bauen, liegt die Applikationskonfiguration dort, wo sie hingehört – nahe am Anwendungscode.
• Terraform injiziert eine Umgebungsvariable, die den „config file location“ angibt (z. B. prod, staging, dev). Die Anwendung liest diese Variable beim Start und wählt den passenden Konfigurationssatz.
• Ergebnis: Ein Build, mehrere Umgebungen – gesteuert über eine deklarative, nachvollziehbare Variable in Terraform.

Secrets richtig handhaben: Platzhalter plus Secret Manager

Hier liegt der Kern einer sonst heiklen Frage: Wie versioniert man Konfigurationen, ohne Secrets im Git‑Repo zu verteilen?

Das frühere Dilemma

• Früher lagen Konfigurationsdateien nur auf den Servern. Sie wurden bewusst nicht eingecheckt, um Secrets zu schützen. Folge: keine Versionierung, Intransparenz und unzuverlässige Testumgebungen.

Die Lösung: Platzhalter und Secret Manager

• In den Konfigurationsdateien stehen Platzhalter für sensible Werte – etwa im Stil secret::NAME.
• Beim Start wählt der Container anhand der Umgebungsvariable die passende Umgebungskonfiguration (prod/staging/dev), parst die Datei und ersetzt jeden Secret‑Platzhalter mit dem Wert aus dem Google Cloud Secret Manager.
• Zutrittskontrolle: Welche Cloud‑Run‑Services welche Secrets lesen dürfen, wird ebenfalls in Terraform festgelegt. So bleibt Zugriff strikt nach dem „Need‑to‑know“-Prinzip.
• Pro Umgebung existieren eigene Secret‑Werte. Production kann also andere Keys/Tokens/URLs verwenden als Staging oder Development – ohne Mehraufwand an den Artefakten.
• Auch das Befüllen von Umgebungsvariablen mit Secret‑Werten wird deklarativ referenziert: Der Dienst bekommt die Variable, Terraform verweist auf den Secret‑Key, der Laufzeitdienst zieht den Wert sicher beim Start.

Das Ergebnis: Anwendungsnahe Configs werden versioniert, aber ohne Sicherheitskompromisse. Geheimnisse liegen zentral, sicher, mit klarer IAM‑Steuerung. Test‑Setups bleiben reproduzierbar, weil die nicht‑sensiblen Teile versioniert sind und die sensiblen Teile standardisiert nachgeladen werden.

Operative Stolpersteine mit Terraform – und wie man damit umgeht

Terraform löst viel, aber nicht alles. Drei praktische Punkte, die Johannes ausdrücklich adressiert:

1) Parallel arbeiten: State, Konsistenz und Sperren

• Eine Terraform‑Konfiguration beschreibt üblicherweise „das ganze Projekt“. Wenn zwei Personen parallel unterschiedliche Ressourcen hinzufügen und jeweils „applyen“, entsteht ein Problem: Wer ohne die Änderungen der anderen Person apply ausführt, liefert Terraform einen „älteren“ gewünschten Zustand. Terraform würde fehlende Ressourcen dann löschen, weil sie in dieser Arbeitskopie nicht existieren.
• State‑Lock: Terraform sperrt den State beim Apply. Während ein Apply läuft, verhindern Locks konkurrierende Änderungen. Das vermeidet Race Conditions, löst aber nicht das logische Problem getrennter Arbeitsstände.
• Praxis: Änderungen koordinieren, früh pushen und pullen. Für Experimente eignen sich separate Testumgebungen – die sind dank Terraform schnell aufzusetzen und isolieren Risiken.
• Branch‑Fallstrick: Branches mit stark abweichenden Infrastrukturen sind heikel. Ein Apply auf dem „falschen“ Branch würde die laufende Infrastruktur entsprechend umbauen. Das ist weniger ein Tool‑, mehr ein Prozess‑Thema – aber wichtig, wenn Teams Infrastruktur wie Anwendungscode „branchy“ entwickeln möchten.

2) Umbenennen ist Löschen + Neuaufbau – außer man nutzt „move“

• In Terraform ist der Name einer Ressource Teil ihrer Identität im State. Ein einfaches Umbenennen führt deshalb dazu, dass Terraform die Ressource löschen und neu erstellen will – mit potenziellen Ausfällen.
• Es gibt jedoch eine Lösung: der Move‑Befehl. Mit „move“ lässt sich eine Ressource im State auf eine neue Adresse verschieben, ohne sie zu zerstören. Johannes’ Lesson Learned: diesen Mechanismus früh kennen – er spart Nerven.

3) Cutting‑Edge‑Features sind nicht immer sofort verfügbar

• Wer sehr neue Cloud‑Features nutzen will, kann auf Lücken in Providern stoßen. Im Talk nennt Johannes ein Beispiel aus GCP: automatische Kompression für Backend‑Buckets war noch nicht implementiert. Es gibt Workarounds, aber der Hinweis bleibt: Die IaC‑Abdeckung hinkt einzelnen Cloud‑Features gelegentlich hinterher.

Konkrete Handlungsimpulse für Teams

Basierend auf den Mustern aus der Session lassen sich klare Schritte ableiten – ohne Spekulation, direkt aus den gezeigten Entscheidungen und Erfahrungen:

• Cloud‑Landschaft vereinheitlichen
• Jeder Provider weniger reduziert Komplexität. durchblicker.at konsolidierte primär auf GCP – damit wurde der Betrieb berechenbarer und IaC leichter nutzbar.
• Managed Containerumgebungen bevorzugen
• Weniger OS‑Pflege, elastisches Skalieren. In der Session diente Cloud Run als naheliegendes Ziel für containerisierte Dienste.
• Infrastruktur deklarativ beschreiben und versionieren
• Terraform als einheitliche Quelle der Wahrheit: Konfigurationen als Text, im VCS, mit Plans und reproduzierbaren Applies.
• Module für Wiederverwendung etablieren
• Ein Modul pro Dienstart, dazu Parameter für min/max Scale, Memory, CPU‑Policies. So bleiben Dev/Staging/Prod konsistent, aber individuell abstimmbar.
• Config nahe am Code, Umgebung per Variable wählen
• Ein Build, mehrere Umgebungen: Terraform setzt die „config file location“, die App lädt beim Start die passende Datei.
• Secrets per Platzhalter und Secret Manager einbinden
• Keine Secrets im Repo. Platzhalter in Configs, sichere Auflösung zur Laufzeit aus dem Secret Manager, IAM‑Rechte in Terraform.
• State‑Management ernst nehmen
• Apply‑Sperren verstehen, parallel koordinieren, Experimente in isolierte Testumgebungen verlagern. Vorsicht mit Branches, die stark andere Zustände abbilden.
• Ressourcennamen mit Bedacht wählen, Move nutzen
• Umbenennungen führen sonst zu Delete/Replace. Den Move‑Befehl als Standardwerkzeug etablieren.
• Feature‑Gaps einkalkulieren
• Für noch nicht implementierte Provider‑Features Workarounds vorbereiten. Das schützt Projektpläne vor Überraschungen.

Warum der Aufwand sich lohnt

Durch die Kombination aus Provider‑Harmonisierung, Managed Containerumgebungen und Terraform gewann das Team bei durchblicker.at genau das, was in gewachsenen Landschaften am meisten fehlt: Kontrolle und Vorhersagbarkeit.

• Transparenz: Die komplette Infrastruktur ist in Dateien sichtbar. Änderungen sind nachvollziehbar und überprüfbar.
• Reproduzierbarkeit: Dev/Staging/Prod lassen sich konsistent aufsetzen. Testumgebungen entstehen auf Knopfdruck, ohne inkonsistente Handkonfigurationen.
• Sicherheit und Sorgfalt: Secrets bleiben im Secret Manager, Zugriffe sind minimal und explizit geregelt. Konfigurationsdateien sind versioniert, aber bleiben geheimnisfrei.
• Betriebskomfort: Parameter wie Skalierungsgrenzen oder Arbeitsspeicher werden deklarativ pro Umgebung gesetzt – nachvollziehbar und änderbar ohne Shell‑Akte.

Am Ende bringt es Johannes auf den Punkt:

Fazit: Ein pragmatischer Leitfaden aus der Praxis

„Raising Infrastructure Configuration to the next Level“ liefert keine Lehrbuch‑Theorie, sondern eine belastbare Route für Teams, die von verstreuten Servern und manuell gepflegten Testsystemen zu klarer, reproduzierbarer und sicherer Infrastruktur wollen:

• Konsolidiert eure Plattform.
• Nutzt Managed Container, wo es sinnvoll ist.
• Beschreibt Infrastruktur als Code – mit Modulen, Parametern und sauberem State‑Management.
• Verknüpft Konfigurationen mit dem Anwendungscode und löst Secrets erst zur Laufzeit aus einem Secret Manager.

Gerade die kleinen, ehrlichen Hinweise – von Apply‑Locks über Branch‑Fallstricke bis zum Move‑Befehl – machen die Session wertvoll. Wer heute ähnliche Symptome sieht wie durchblicker.at in der Ausgangslage, findet hier einen praktikablen Plan, um die eigene Infrastruktur‑Konfiguration auf das nächste Level zu heben.

• 

  

  Out of the Dark, Into the Light

  Michael Karner von Durchblicker erzählt in seinem devjobs.at TechTalk über den Weg, wie das Team die gesamte Infrastruktur auf die Google Cloud Platform gewechselt hat – und welche Überraschungen es dabei gegeben hat.

  Jetzt ansehen

• 

  

  Andreas Deuschl, CTO von Durchblicker

  Der CTO von Durchblicker Andreas Deuschl gibt im Interview Einblicke in die Organisation des Devteams, wie das Recruiting und Onboarding abläuft und welche Technologien eingesetzt werden.

  Jetzt ansehen