Konfiguration und Profile übertragen

Konfiguration und Profile übertragen

0:00 Konfiguration hat in Migrationsprojekten einen schlechten Ruf: Sie gilt als Fleißarbeit, die man zwischendurch erledigt. Tatsächlich ist sie die Stelle, an der eine Migration am leisesten scheitert. Denn ein falsch übertragener Schlüssel bricht nicht den Build und meldet sich nicht im Test — er sorgt nur dafür, dass in Produktion etwas anders ist, als alle denken.

0:20 In diesem Modul sehen wir uns an, woher Quarkus seine Werte nimmt, wie Profile funktionieren und warum manche Schlüssel nach dem Build schlicht nicht mehr veränderbar sind.

Konfiguration und Profile übertragen

0:30 Der dritte und letzte Baustein des ersten Tages. Nach diesem Modul kennen Sie die Rangfolge der Konfigurationsquellen, können Profile und Secrets sauber trennen und — das ist der wichtigste Punkt — Sie erkennen einen Build-Time-Schlüssel, bevor er Ihnen eine Stunde Fehlersuche kostet. Damit ist das Fundament gelegt, und morgen geht es an Persistenz, Tests und Security.

Schlüssel, Namensräume und Typisierung

0:51 Beginnen wir mit der Frage, die im Container am häufigsten gestellt wird: Welcher Wert gewinnt eigentlich, wenn derselbe Schlüssel an mehreren Stellen steht? Quarkus liest Konfiguration nicht aus einer Datei, sondern aus mehreren Quellen, und jede Quelle hat eine Rangzahl — das sogenannte Ordinal. Die Endkonfiguration ist die Zusammenführung aller Quellen, wobei die höhere Rangzahl gewinnt.

1:14 Das Bild: Mehrere Personen füllen dasselbe Formular aus, und es gibt eine klare Rangordnung, wessen Eintrag zählt. Wer diese Rangordnung kennt, versteht sofort, warum ein Wert in der Datei steht und trotzdem etwas anderes wirkt. Und dieses Prinzip erklärt nebenbei, warum Konfiguration im Container überhaupt funktioniert: Nicht die Datei im Artefakt gewinnt, sondern das, was die Umgebung beisteuert.

1:38 Die Zahlen müssen Sie nicht auswendig können, das Muster schon: Je näher eine Quelle am laufenden Betrieb liegt, desto höher ihr Rang. System-Properties und Umgebungsvariablen stechen die Datei im Classpath — genau deshalb funktioniert Konfiguration in Containern überhaupt. Beachten Sie die beiden mittleren Zeilen: Eine Datei im Arbeitsverzeichnis und eine im Classpath sind zwei verschiedene Dinge mit verschiedenen Rängen.

2:01 Und die Fußnote ist der praktische Teil: Quarkus sucht denselben Schlüssel auch in Schreibweisen mit Unterstrichen und in Großbuchstaben — sonst könnten Umgebungsvariablen die Punkte in den Schlüsseln gar nicht abbilden. Oben der empfohlene Weg, unten der Einzelwert. Der obere ist mehr als Kosmetik: Sie bekommen ein Interface mit echten Typen, das sich injizieren lässt, und Ihre fachlichen Einstellungen stehen an einer Stelle statt verstreut über zehn Klassen.

2:28 Achten Sie auf die Fußnote — die Namen werden automatisch in Bindestrich-Schreibweise übersetzt. Das ist die häufigste Irritation beim ersten Mal: Man sucht einen Schlüssel in Binnenmajuskel-Schreibweise und findet ihn nicht. Der Einzelwert unten ist für Ausnahmen gedacht, nicht als Standard. Der erste Punkt betrifft alle, die Ausdrücke in Werten gewohnt sind: Die einfache Annotation kennt keine Expression Language.

2:52 Der zweite ist ein Startabbruch, der zunächst hart wirkt, aber richtig ist — ein fehlender Pflichtschlüssel bricht ab, statt mit einem stillen Standardwert weiterzulaufen. Der dritte ist ein Sicherheitsthema: Die Entwicklungsdatei mit Zugangsdaten landet versehentlich im Image; prüfen Sie das einmal bewusst. Und der vierte ist eine Zeitbombe fürs nächste Update: Eigene Schlüssel gehören nicht in den Framework-Namensraum.

Profile, Umgebungen und Secrets

3:16 Weiter mit Profilen. Das Konzept kennen Sie, die Schreibweise ist anders — und beim Thema Secrets lohnt sich ein Moment Aufmerksamkeit. Quarkus kennt drei eingebaute Profile: Entwicklung, Test und Produktion, wobei Produktion die Vorgabe ist. Profilbezogene Werte stehen mit einem vorangestellten Prozentzeichen in derselben Datei — das ist die kompakte Variante.

3:38 Alternativ gibt es eigene Dateien je Profil, und die haben Vorrang. Diesen Vorrang sollten Sie sich merken: Wenn ein Wert nicht wirkt, obwohl er richtig aussieht, steht er vielleicht in der kompakten Schreibweise und wird von einer Profildatei überstimmt. Merken Sie sich diesen Vorrang: Wenn ein Wert nicht wirkt, obwohl er richtig aussieht, steht er vielleicht in der kompakten Schreibweise und wird von einer Profildatei überstimmt.

4:03 Drei Muster auf einer Folie. Oben die Profilschreibweise, einschließlich eines selbst gewählten Profils — Sie sind nicht auf die drei eingebauten beschränkt. In der Mitte der Verweis auf Umgebungsvariablen mit einem Vorgabewert nach dem Doppelpunkt; praktisch, aber mit Vorsicht zu genießen, dazu gleich mehr. Und unten eine Möglichkeit, die wenig bekannt ist: Profile können ein Elternprofil haben, sodass gemeinsame Werte nur einmal stehen.

4:28 Das spart in Projekten mit vielen Umgebungen erstaunlich viel Wiederholung. Die kurze Antwort: nicht ins Image. Zugangsdaten kommen über Umgebungsvariablen oder eingehängte Secrets, im Cluster über die dafür vorgesehenen Objekte. Der Punkt mit den Vorgabewerten verdient eine Warnung: Ein Vorgabewert nach dem Doppelpunkt ist bequem, aber er verdeckt, dass die eigentliche Quelle gar nicht greift.

4:52 Im schlimmsten Fall läuft Ihre Anwendung monatelang mit einem Platzhalter und niemand merkt es, weil nichts abstürzt. Verwenden Sie Vorgabewerte für Unwichtiges und lassen Sie Wichtiges lieber laut scheitern. Vier Klassiker. Erstens: Ein Wert steht in zwei Profilen, und im Container weiß niemand mehr, welches Profil aktiv ist — protokollieren Sie das aktive Profil beim Start, das kostet eine Zeile.

5:16 Zweitens sticht die Profildatei die kompakte Schreibweise, unbemerkt. Drittens wandern Secrets in die Konfigurationsdatei, weil es beim Ausprobieren schneller ging und danach niemand aufgeräumt hat. Und viertens der Punkt von eben: Ein Vorgabewert verdeckt eine Quelle, die gar nicht greift.

Build-Time gegen Runtime-Konfiguration

5:34 Und jetzt der Teil, den es in Spring Boot so nicht gibt und der deshalb regelmäßig für Verwirrung sorgt: Schlüssel, die nach dem Build nicht mehr veränderbar sind. Ein Teil der Quarkus-Schlüssel wird zur Bauzeit ausgewertet und ist danach festgeschrieben. In der Konfigurationsreferenz sind diese Einträge mit einem Schloss markiert — gewöhnen Sie sich an, dort nachzusehen.

5:55 Wer einen solchen Schlüssel zur Laufzeit ändert, ändert nichts; es passiert einfach gar nichts. Immerhin gibt es eine Einstellung, mit der Quarkus in diesem Fall den Start abbricht statt stillzuschweigen. Das ist unbequem und genau deshalb empfehlenswert. Das Bild: Manche Schalter sitzen hinter dem Putz. Sie können davor stehen und drücken, so oft Sie wollen — geändert wird erst beim nächsten Umbau.

6:19 Diese Gegenüberstellung ist die praktische Zusammenfassung. Links das Festgeschriebene: Was zur Bauzeit entschieden wurde, braucht für eine Änderung einen neuen Build. Typisches Beispiel sind die aktivierten Extensions — das leuchtet ein, denn sie wurden ja in das Artefakt hineingebaut. Rechts das, was beim Start gelesen wird, etwa die Datenbankadresse. Die entscheidende Zeile ist die unterste links: still wirkungslos.

6:44 Kein Fehler, keine Warnung, nur ein Wert, der nichts tut. Deshalb der dringende Rat: Diese Einstellung einmal bewusst ausprobieren, bevor es im Ernstfall passiert. Eine gute Nachricht für alle, die einen zentralen Konfigurationsserver betreiben: Quarkus kann dessen Werte über eine eigene Extension beziehen. Das heißt, Sie müssen nicht gleichzeitig die Anwendung und die Konfigurationsinfrastruktur austauschen — und das ist bei Migrationen fast immer die richtige Reihenfolge.

7:12 Ein Schlüssel verdient besondere Beachtung: Die Einstellung, ob der Start ohne erreichbaren Server abbrechen soll. Steht sie auf Nachsicht, startet Ihre Anwendung im Zweifel mit halber Konfiguration. Das ist selten das, was man will. Der erste Punkt ist der, weswegen dieses Kapitel existiert: Ein Schlossschlüssel wird im Deployment gesetzt und wirkt nicht — und weil nichts abstürzt, sucht niemand.

7:35 Der zweite ist der eben erwähnte Startabbruch, der ausgeschaltet bleibt. Der dritte trifft Migrationen mit gemischten Ständen: Der Konfigurationsserver wird abgeschaltet, obwohl noch Dienste daran hängen. Und der vierte ist eine Reihenfolgefrage: Die strenge Build-Time-Prüfung einzuschalten ist richtig, aber die Pipeline muss darauf vorbereitet sein, sonst steht plötzlich alles.

Übung

7:57 In der Übung übertragen Sie die Konfiguration von Pfandkreis — und machen einen Gegenversuch, der mehr hängen bleibt als jede Folie. Der Kern der Aufgabe steht im Hinweis: Setzen Sie einen Build-Time-Schlüssel im laufenden Container und schauen Sie sich an, was passiert — nämlich nichts. Diese eine Erfahrung ersetzt drei Folien Theorie und sorgt dafür, dass Sie den Fall im Projekt sofort erkennen.

8:20 Daneben geht es um das Handwerk: Schlüssel übertragen, fachliche Werte typisiert bündeln, Profile anlegen und Zugangsdaten aus der Datei herausnehmen. Daneben geht es um das Handwerk: Schlüssel übertragen, fachliche Werte typisiert bündeln, Profile für alle drei Umgebungen anlegen und die Zugangsdaten konsequent aus der Datei herausnehmen.

8:39 Erfolgreich sind Sie, wenn der Dienst in allen drei Profilen startet. Die ersten vier Schritte sind Routine, der fünfte ist der Lerneffekt. Ein Rat zum ersten Schritt: Gehen Sie die Schlüssel einzeln durch und sehen Sie in die Referenz, statt zu suchen und zu ersetzen. Das dauert eine halbe Stunde länger und spart im Zweifel einen Produktionsvorfall. Und beachten Sie die Fußnote: Das Ergebnis des Gegenversuchs gehört ins Betriebshandbuch.

9:04 Die Kolleginnen und Kollegen, die nachts eine Umgebungsvariable setzen wollen, müssen wissen, welche Schlüssel darauf reagieren und welche nicht. Vier Dinge für die Nachbesprechung. Suchen und Ersetzen ohne Blick in die Referenz erzeugt Schlüssel, die plausibel aussehen und nicht existieren — und niemand beschwert sich.

9:23 Profile werden angelegt, aber nur eines wird je gestartet. Der Gegenversuch wird übersprungen, weil das Ergebnis vermeintlich klar ist; nur bleibt dann eben nichts hängen. Und fachliche Werte bleiben als einzelne Strings verstreut, statt in ein typisiertes Interface zu wandern — eine Gelegenheit, die während einer Migration günstig ist und danach nie wieder kommt.