Aktives Profil in Spring Boot

1. Aktives Profil in Spring Boot

Wenn Sie bisher catalog-service nur aus der IDE gestartet haben, mag es scheinen, dass das Problem der „Umgebungen“ übertrieben ist: es funktioniert doch. Aber sobald die Anwendung aufhört, eine „Demo auf meinem Laptop“ zu sein, und beginnt, an mindestens zwei Orten zu leben, stellt sich der Schmerz sofort ein. Auf Ihrem Rechner ist es praktisch, dass der Dienst auf einem nicht standardmäßigen Port startet, mehr Daten anzeigt und experimentierfreundlich ist. In einem sogenannten „produktiven“ Start wünscht man sich Strenge: weniger Lärm, vorhersagbare Standardwerte und keine „zufällig aktivierten Annehmlichkeiten“. Und das Unangenehmste ist, dass man dies alles ohne Umschreiben von Java-Code erreichen möchte, weil man sonst das Deployment in ein Abenteuer auf dem Niveau „welchen if habe ich vor dem Release vergessen zurückzusetzen?“ verwandelt.

Wir haben bereits gesehen, dass Eigenschaften in Boot aus verschiedenen Quellen kommen und nach Precedence streiten. Mit Profilen ist die Logik dieselbe: ein aktives Profil ist auch ein Teil der Konfiguration, und profil-spezifisches YAML ist eine weitere Schicht über der Basis. Daher sollte man Profile besser nicht als eine separate Magie von Spring betrachten, sondern als Fortsetzung des allgemeinen Konfigurationsmodells.

Das Problem hier ist nicht, dass „die Werte unterschiedlich sind“. Das Problem ist, dass die Unterschiede verwaltbar und erklärbar sein müssen. Und genau hier kommt in Spring Boot der Schlüsselbegriff des Tages ins Spiel: Aktives Profil.

2. Profil als Delta zum Basis-YAML

Ein Profil (profile) in Spring ist keine „weitere Anwendung“, kein „spezieller Spring-Modus“ und keine „geheime Annotation für Erwachsene“. Vom Sinn her ist ein Profil der Name des aktuellen Konfigurationsmodus, der Boot mitteilt: „heute arbeiten wir unter diesen Bedingungen“. Das heißt, ein Profil ist ein Label, anhand dessen Spring Boot versteht, welche Teile der Konfiguration als relevant gelten und welche nicht.

Es ist wichtig, den Ton zu treffen: Ein Profil sollte nicht die „Stimmung des Entwicklers“ beschreiben (wie angry-mode), sondern den stabilen Ausführungskontext. Deshalb tauchen in Lehrdienst-Anwendungen (und in vielen realen Projekten) die vertrauten Namen auf wie local, dev, prod. Sie sind nicht ideal, aber verständlich: „lokal“, „in der gemeinsamen Dev-Umgebung“, „im Produktionsbetrieb“.

Dabei ist ein „aktives Profil“ einfach ein Profil, das in einem bestimmten Start der Anwendung ausgewählt wurde. Wenn kein Profil ausgewählt ist, arbeitet die Anwendung im Basismodus (oft sagt man „ohne Profil“), und dann können es null aktive Profile sein. Daran ist nichts Schlimmes: es bedeutet, dass man nur die Basiskonfiguration ohne Umgebungsunterschiede verwendet.

Die häufigste Falle für Anfänger ist, sich ein Profil als „alternatives application.yaml“ vorzustellen. Im Kopf entsteht die Idee: „Oh! Ich mache dev, prod, und in jedem gibt es einen vollständigen Satz von Einstellungen.“ Und das erscheint logisch… bis man merkt, dass man drei fast identische Dateien hat, die man synchron halten muss, sonst beginnen sie auseinanderzudriften wie die Charaktere der Kommilitonen vor der Prüfungssession.

Das richtige mentale Modell ist: Sie haben eine Basis, d.h. eine allgemeine Konfiguration, die fast immer passt, und ein Delta (Override), d.h. eine kleine Schicht von Unterschieden für die jeweilige Umgebung. Ein Profil existiert genau für das Delta.

Hier ist ein Beispiel für eine Basiskonfiguration (das, was „im Großen und Ganzen immer wahr ist“):

spring:
  application:
    # Basisname der Anwendung: identisch für alle Umgebungen
    name: "catalog-service"

app:
  catalog:
    # Standardwert: wenn Profile nicht aktiviert sind, wird dieser verwendet
    title: "Course Catalog"
    # Basislimit – ein vernünftiger Standard, der punktuell durch das Profil überschrieben werden kann
    max-featured-count: 4
    # Standardverhalten: „sicherer“ nur Veröffentlichtes anzeigen
    default-published-only: true

Diese Datei versucht nicht zu „raten“, wo sie ausgeführt wird. Sie setzt einfach vernünftige Werte: den Anwendungsnamen, den Basisnamen des Katalogs und das Standardverhalten.

Ein Profil beantwortet die Frage: „Was soll in dieser Umgebung anders sein?“ Eine gute Profilschicht ist normalerweise kurz, und wenn Sie beim Öffnen einer Profilkonfiguration ein Blatt mit 200 Zeilen sehen, ist das ein Alarmzeichen (etwa wie eine Utils.java mit 2000 Zeilen, nur in YAML).

Um den Unterschied zu festigen, ist es praktisch, folgende Tabelle im Kopf zu behalten (nicht als Dogma, sondern als „Plausibilitätsprüfung“):

Beachten Sie: Ein Profil ist kein „Ort, an dem man alles hinschreiben kann“, sondern vielmehr ein „Ort, an dem die Unterschiede wohnen, die durch die Umgebung gerechtfertigt sind“.

3. Profil und punktuelle Overrides

Profile werden leicht zu einer Sammlung von „Modi für alle Lebenslagen“, besonders wenn Sie sich in die Idee verliebt haben: „Oh, machen wir doch feature-x-on, feature-x-off, debug, debug2, demo-for-qa, demo-for-sales…“. Das ist so, als würde man anfangen, Variablen temp2, temp3, tempFinalFinal zu nennen – im Moment scheint es zu helfen, aber später erkennt man sich selbst im Spiegel nicht wieder.

Ein gesundes Kriterium ist recht einfach: Ein Profil lohnt sich, wenn Sie ein stabiles Paket von Unterschieden haben, das sich von Start zu Start im gleichen Kontext wiederholt. Zum Beispiel unterscheidet sich die „lokale Umgebung“ tatsächlich von der „Produktion“ nicht nur durch eine Einstellung, sondern in der Regel durch mehrere.

Wenn Sie jedoch genau einen Wert „für einen einzigen Start“ ändern müssen (z. B. vorübergehend app.catalog.title für eine Demo ändern), dann kann ein Profil überflüssig sein. Verwenden Sie in diesem Fall besser den Mechanismus, den Sie bereits aus dem Precedence-Thema kennen: Überschreiben Sie eine einzelne Eigenschaft auf externe Weise (Umgebungsvariable, Systemeigenschaft, Kommandozeilenargument). Hier ist Disziplin wichtig: Das Profil ist für Umgebungen gedacht, das Überschreiben eines einzelnen Wertes für punktuelle Konfiguration.

Man kann es sich so vorstellen:

Das sind keine „Verbote“, sondern eine Möglichkeit, keinen Zoo von Profilen zu bekommen, bei dem niemand mehr versteht, welches einzuschalten ist und warum.

4. Überprüfung aktiver Profile über Environment

In der Konfiguration gibt es eine unangenehme psychologische Falle: Sie sind überzeugt, dass „Ihr local-Profil aktiviert ist“, weil Sie das dachten… und Sie sind überzeugt, dass „also das entsprechende YAML angewendet wird“… und Sie sind überzeugt, dass „deshalb der title dieser sein muss“… und am Ende startet der Dienst mit einem anderen Verhalten. Und Sie beginnen, wahllos Dateien zu ändern, als ob Sie versuchen würden, eine Mücke im Dunkeln zu fangen.

Um das zu vermeiden, muss man eine einfache Sache tun: Zu Beginn des Anwendungslebens ausgeben, welche Profile tatsächlich aktiv sind. Das ist kein „Produktionslogging“, kein separates Observability-System – es ist einfach eine Hygienemaßnahme für einen Junior-Entwickler, der lernt, nicht zu raten.

In Spring Boot ist der direkteste Weg, das Environment zu nehmen und nach den aktiven Profilen zu fragen. Zum Beispiel gibt es in unserem Projekt bereits (oder wird es bald geben) den StartupSummaryRunner. Lassen Sie uns ein minimales Fragment zeigen, das die aktiven Profile ausgibt:

import java.util.Arrays;
import org.springframework.boot.ApplicationArguments;
import org.springframework.boot.ApplicationRunner;
import org.springframework.core.env.Environment;
import org.springframework.stereotype.Component;

@Component
public class StartupSummaryRunner implements ApplicationRunner {
    // Environment – ein „Fenster“ zur endgültigen Konfiguration, bereits von Spring Boot zusammengestellt
    private final Environment env;

    public StartupSummaryRunner(Environment env) {
        // Spring injiziert Environment selbst: manuell muss hier nichts „eingeschaltet“ werden
        this.env = env;
    }

    @Override
    public void run(ApplicationArguments args) {
        // Explizites Ausgeben der aktiven Profile, um nicht zu raten „ich habe wohl local aktiviert“
        System.out.println("Aktive Profile: " + Arrays.toString(env.getActiveProfiles()));
        // Beispielausgabe:
        // Aktive Profile: [local]
    }
}

Hier passiert eine für das Verständnis wichtige „Magie-null“-Sache: Environment ist ein „Fenster“ zur endgültigen Konfigurationslandschaft. Wenn es keine Profile gibt, sehen Sie eine leere Liste []. Wenn ein Profil aktiv ist, sehen Sie seinen Namen. Und dann verwandeln sich alle Gespräche der Art „mir scheint, ich habe dev“ in „ich habe tatsächlich [dev] – hier ist der Beweis“.

Beachten Sie, dass wir jetzt nicht versuchen, „Profile aus Java-Code umzuschalten“ und keine Tricks anwenden. Wir lesen einfach das, was Boot bereits gesammelt hat, und halten uns so von konfigurativem Schamanismus ab.

5. Typische Fehler bei der ersten Begegnung mit Profilen

Fehler Nr. 1: Ein Profil für jede Kleinigkeit anlegen.
Profile sind sehr verführerisch: Man denkt, sie seien der universelle Schalter für alles. Aber wenn Sie jedes Mal ein neues Profil anlegen, wenn Sie einen Parameter ändern möchten, bekommen Sie schnell einen Konfigurationsdschungel, in dem es schwer ist, einen Pfad zu finden. In einem normalen Projekt ist ein Profil genau das – ein „Ausführungskontext“, kein „Einweg-Kippschalter“.

Fehler Nr. 2: Die gesamte Basiskonfiguration in jedem Profil duplizieren.
Wenn Profildateien zu Kopien der Basis-application.yaml werden, die sich an drei Stellen unterscheiden, beginnt eine stille Hölle: Sie ändern die Struktur von app.catalog.* in einer Datei und vergessen es in zwei anderen. Dann verhält sich die Anwendung unterschiedlich, und Sie verbringen Zeit nicht mit Spring Boot, sondern mit der Suche „warum YAML nicht mit sich selbst übereinstimmt“. Ein Profil sollte ein kurzes Delta sein, keine zweite „vollständige Konfiguration“.

Fehler Nr. 3: Versuchen, mit Profilen das zu erklären, was einfacher durch einen einzelnen Override zu bewerkstelligen ist.
Wenn Sie eine einmalige Änderung benötigen, ist es einfacher, eine einzelne Eigenschaft extern zu überschreiben, als ein neues Profil „für fünf Minuten“ anzulegen. Ein Profil geht eher um Umgebungsstrategie und Disziplin, nicht um schnelle Experimente „lass es uns mal anders machen“.

Fehler Nr. 4: Sich auf Erwartungen verlassen statt auf Überprüfung.
Der heimtückischste Fehler ist zu denken: „Ich habe das Profil doch eingeschaltet, also ist es aktiv.“ In der Praxis kann das Profil nicht aktiviert werden, das falsche aktiviert werden oder zusammen mit anderen aktiviert werden. Daher ist eine nützliche Gewohnheit, die aktiven Profile beim Start auszugeben (über Environment) und keine Vermutungen auf der Grundlage der Datei anzustellen, die man „zuletzt bearbeitet“ hat. In der Konfiguration gewinnt immer die Tatsache, nicht das Gefühl.

Fehler Nr. 5: Versuchen, ein Profil aus der Profildatei heraus „einzuschalten“.
Wenn Sie anfangen, die Profilauswahl innerhalb von application-*.yaml festzulegen, erhalten Sie leicht eine zirkuläre Logik: Die Datei scheint „sich selbst auszuwählen“. Am Ende landen Sie wieder in der Situation „mir scheint, es ist eingeschaltet“, nur dass es jetzt noch schwieriger ist zu verstehen, wer genau wann die Entscheidung getroffen hat. Ein aktives Profil sollte besser von außen (IDE/ENV/Argumente) gesetzt werden, und die Profildateien sollten als Deltas behandelt werden.