Nur einen Teil der Microservices starten
Dein System hat zwölf Services und du wirst zwei anfassen. Die Maschine schafft zwölf —gerade so— aber sie alle zu starten dauert vier Minuten, frisst den Speicher und trägt nichts zu der Änderung bei, die du machst. Die Frage ist nicht, ob man kürzen kann: sie ist, wohin die rufen, die du startest.
Das Kürzen ist nicht das Problem; das Ziel schon
Eine Teilmenge zu starten ist in jedem Werkzeug trivial: du wählst zwei und startest. Was dir niemand abnimmt, ist, was passiert, wenn einer dieser zwei einen dritten aufruft, der nicht mehr da ist.
Jede Abhängigkeit, die aus dem Schnitt herausfällt, hat genau drei mögliche Ziele:
- Lokal — er läuft direkt nebenan. Der einfache Fall, und auch der, der nachzieht: startest du ihn, ziehst du seinen eigenen Rattenschwanz an Abhängigkeiten mit.
- Die Cloud — eure gemeinsame Umgebung. Sie erspart dir den Start, im Tausch gegen VPN, gegen Daten, die sich unter deinen Füßen ändern, und dagegen, dass du auch unten bist, wenn jene Umgebung unten ist.
- Ein Mock — perfekt, wenn seine Antwort nicht das ist, was du testest. Im Tausch dafür, den Stub zu pflegen.
Die Entscheidung fällt pro Abhängigkeit, nicht pro Umgebung. Darin liegt der Unterschied zu fast allem anderen: du willst keinen „lokalen Modus“ oder „Cloud-Modus“, du willst diesen Aufruf zum Service, den du offen hast, jenen in die Cloud und einen dritten zu einem Mock — und mitten am Nachmittag deine Meinung ändern.
Warum eine Compose-Datei den Unterschied nicht kennt
docker compose up bff orders startet tatsächlich zwei Services. Aber in einer
Compose-Datei ist alles ein Container desselben Netzes, und die URLs
zwischen ihnen sind Servicenamen dieses Netzes. Die Konfiguration von bff
sagt http://payments:8081, und payments ist jetzt nicht da: du
bekommst einen Namensauflösungsfehler.
Der übliche Ausweg ist, die URL von Hand in der Konfiguration von bff zu
ändern —einem Repository, das oft nicht deines ist—, daran zu denken, sie nicht zu
committen, und es rückgängig zu machen, wenn du etwas anderes probieren willst.
Multipliziert mit Services und mit Malen pro Tag ist das der Ursprung der
vierzigschrittigen LOCAL_SETUP.md.
Was kaputtgeht, wenn du falsch kürzt
Zwei Fehler, und der zweite ist weit schlimmer als der erste:
-
Es scheitert laut.
connection refused, oder ein Name, der nicht auflöst. Lästig, aber ehrlich: du merkst es beim ersten Versuch. - Es funktioniert, ohne dass jemand es entschieden hätte. Die Konfiguration brachte als Standard die URL der gemeinsamen Umgebung mit, also geht der Aufruf in die Cloud, antwortet, und alles sieht gut aus. Du merkst es an dem Tag, an dem jener Aufruf schreibt: eine Migration, eine Testbestellung, eine E-Mail von deiner Maschine an einen echten Kunden.
Der zweite ist es, der rechtfertigt, daraus eine ausdrückliche Entscheidung statt eines Standardwerts zu machen. Eine lokale Umgebung, die aus Versehen die Produktion erreicht, warnt nicht vorher.
Und ein Fall, den fast alle falsch machen
Wenn ein Service direkt nebenan läuft, sollte der Aufruf zu ihm gehen —auch wenn die allgemeine Konfigurationsdatei „Cloud“ sagt—. Das klingt offensichtlich und kaum ein Werkzeug tut es: du endest mit einem Service, der auf deiner Maschine läuft und den sein Nachbar über das Internet aufruft. Das verbraucht VPN, ist langsamer, und an dem Tag, an dem das VPN ausfällt, hast du ein ganzes lokales Szenario, das wegen eines Service nicht startet, den du direkt danebenstehen hattest.
Die richtige Regel: was direkt nebenan läuft, wird lokal aufgerufen, und die allgemeine Konfiguration entscheidet nur über das, was nicht im Szenario ist.
Wie Aseptic es löst
Ein Szenario ist genau das: die Teilmenge, die du starten willst, mit der getroffenen Entscheidung für jede Abhängigkeit, die daraus herausfällt.
- Du wählst, was hineinkommt. Zwei von zwölf, oder wie viele auch immer, gruppiert nach Ablauf —„Checkout“, „Kundenanlage“— und mit Namen gespeichert, damit du es morgen nicht wieder entscheiden musst.
- Für jede Abhängigkeit wählst du ein Ziel —lokal, Cloud oder Mock—
und die Engine schreibt die URL beim Start um, injiziert als
-D-Property oder Umgebungsvariable. Deine Repositories werden nicht angefasst. - Was im Szenario ist, wird lokal aufgerufen, über dem, was das Manifest sagt: die jüngere, spezifische Entscheidung schlägt die allgemeine.
- Widersprechen sich die Deklarationen, wird der Start abgebrochen, statt still zu entscheiden. Zwei Wahrheiten über dieselbe Abhängigkeit ist der Fehler, der damit endet, dass das Panel „Cloud“ sagt, während ein Service seinen lokalen Nachbarn aufruft.
- Das Szenario wird geteilt als in sich geschlossene Datei: wer neu dazukommt, importiert und startet, ohne irgendjemandes Dokument zu lesen.
Wie viel man wirklich starten muss
Die Regel, die funktioniert: nur die Services, die du ändern wirst, plus die, deren Verhalten du prüfst. Alles andere ist eine URL, die woanders hinzeigt. In der Praxis sind das an den meisten Nachmittagen zwei oder drei Services aus einem System von zwölf.
Wenn beim Kürzen einer der beiden nicht startet, gibt es warum ein Microservice lokal nicht hochkommt; und wenn du die ersetzen musst, die du draußen lässt, einen Service mocken, den du nicht kontrollierst. Das Gesamtbild steht in was eine lokale Microservice-Umgebung braucht.
Häufige Fragen
Kann ich nur zwei von zwölf Services starten und der Rest funktioniert weiter?
Ja, aber du musst entscheiden, wohin die rufen, die du startest. Jede Abhängigkeit, die auf einen Service zeigt, der nicht oben ist, muss woanders hin: zu deiner Cloud-Umgebung oder zu einem Mock. Wird es nicht entschieden, entscheidet es sich selbst und scheitert.
Warum lässt mich docker compose das nicht ohne Änderung der Datei machen?
Weil in einer Compose-Datei alles ein Container desselben Netzes ist und die URLs Servicenamen sind. docker compose up bff orders startet zwei, aber die URL, mit der bff einen dritten aufruft, zeigt weiter auf einen Namen, den es jetzt nicht mehr gibt.
Was geht kaputt, wenn ich falsch kürze?
Der typische Fall ist ein connection refused auf einen Servicenamen, der weg ist, oder schlimmer: ein Aufruf, der standardmäßig in die gemeinsame Umgebung hinausgeht, ohne dass es jemand entschieden hätte. Das Zweite ist schlimmer, weil es funktioniert, und du merkst es erst, wenn du in die Datenbank aller schreibst.
Wie viel von einem System muss man wirklich starten?
Weniger, als üblicherweise gestartet wird. Die nützliche Regel: nur die Services, die du ändern wirst oder deren Verhalten du prüfst. Alles andere ist eine URL, die woanders hinzeigt.