Nativ- vs Container-Modus
Jeder Micro eines Szenarios läuft in einem von zwei Ausführungsmodi, und Sie wählen ihn pro Micro:
| Modus | Was es ist | Wann |
|---|---|---|
| nativ | Der Micro startet als Prozess auf Ihrer Maschine (mit Maven, npm, uvicorn…) | Der Micro, an dem Sie arbeiten: schneller Start, Hot Reload, bequemes Debugging |
| Container | Der Micro startet in einem Docker-Container | Die Hintergrund-Micros: isolierte, reproduzierbare Umgebung, ohne Ihre Maschine zu verschmutzen |
Die übliche Kombination ist gemischt: nativ der, den Sie entwickeln, Container die, die Sie nur gestartet brauchen, damit der Ablauf funktioniert.
Den Modus ändern
Abschnitt betitelt „Den Modus ändern“In den Ansichten Karten oder Tabelle des Szenarios hat jeder Micro einen Nativ/Container-Umschalter. Sie können auch den Standardmodus eines Micros in seinem Editor festlegen (Bereich Micros).
Der Container-Modus erfordert, dass Docker gestartet ist. Der Nativ-Modus verwendet den
Wrapper des Repos (mvnw, .venv) oder das Binary im PATH. Fehlt eines
(JDK, Maven, Gradle, Node, Go oder das .NET SDK), installiert Aseptic es in seinen eigenen
Ordner (~/.aseptic/toolchains/), ohne Administratorrechte und ohne den PATH des
Rechners anzufassen: Das können der Copilot, ein MCP-Agent oder aseptic toolchain install anstoßen. Ein bereits installiertes behält Vorrang.
Nativ ohne JDK und Maven: der Werkzeug-Container
Abschnitt betitelt „Nativ ohne JDK und Maven: der Werkzeug-Container“Ein Spring-Boot- oder Quarkus-Dienst mit Maven oder ein Node-, Go-, Python- oder
.NET-Dienst kann im nativen Modus laufen, ohne seine Werkzeuge auf dem Rechner (JDK
und Maven, Node, Go, Python oder das .NET SDK): Aseptic führt denselben nativen Befehl im offiziellen Image seines Stacks aus, mit der
Version, die der Dienst verlangt (maven:3.9-eclipse-temurin-<java>, node:<Version>
laut .nvmrc oder engines, golang:<Version> laut go.mod, python:<Version> laut .python-version oder
requires-python, das .NET SDK laut TargetFramework des Projekts). Das ist sein Werkzeug-Container, nicht der Container-Modus: Der Dienst
bleibt in allem anderen nativ (Konfiguration, Ports, Debugging).
Jeder Dienst legt in seinem Editor fest, woher seine Werkzeuge kommen (Feld Werkzeuge der lokalen Startkonfiguration):
| Option | Was sie tut |
|---|---|
| Automatisch (Standard) | Nutzt die deines Rechners, wenn vorhanden; fehlt eines und Docker läuft, den Werkzeug-Container; ohne Docker bleibt es auf dem Rechner und die Umgebungsprüfung bietet an, das Fehlende zu installieren |
| Rechner | Immer die deines Rechners |
| Container | Immer das offizielle Image |
Was du schon eingerichtet hast, kommt mit: deine settings.xml (und
settings-security.xml) schreibgeschützt, die darin genannten ${env.X}-Variablen und
die Firmen-CA aus den Einstellungen, die dem Vertrauen des Images hinzugefügt wird. Node bekommt außerdem deine .npmrc; Python deine
pip.conf und die PIP_INDEX_URL-Variablen; .NET deine NuGet.Config; und Go die
Variablen seines Modul-Proxys (GOPROXY, GOPRIVATE…). Ist
Docker Hub nicht erreichbar, stellt die Image-Registry der Einstellungen das Präfix
eines internen Spiegels voran.
Auch ohne Einstellung vertraut der Container den CAs, die dein System zusätzlich zu den Standard-CAs hat (Windows-Zertifikatspeicher, macOS-Schlüsselbund oder /etc/ssl unter Linux) – dort installiert die Firma die des Proxys, der den Verkehr prüft: Ein Dienst, der auf deinem Rechner gegen das interne Repository auflöst, löst im Container genauso auf. Bei Java wird der entstandene Speicher aufbewahrt, spätere Starts kopieren ihn nur. Die TLS-Prüfung wird nie abgeschaltet; vertraut ein Build einem Zertifikat trotzdem nicht, erklärt das Dienst-Log es mit einem Hinweis statt eines nackten PKIX.
Spring Boot und Quarkus mit Gradle starten mit dem Wrapper des Repos (./gradlew bootRun oder quarkusDev), ohne Daemon, damit das Stoppen des Dienstes auch die Anwendung stoppt, und ihre Konfiguration reist in der Variablen JAVA_TOOL_OPTIONS mit denselben -D wie bei Maven, ohne das build.gradle anzufassen. In ihrem Werkzeug-Container nutzen sie das JDK-Image (eclipse-temurin:<java>) und einen eigenen Gradle-Cache. Sie lassen sich wie mit Maven debuggen; bei Spring Boot wird der Debugger nur der JVM der Anwendung hinzugefügt, über ein Gradle-Init-Script, das Aseptic beim Start übergibt, ohne das Repo anzufassen.
Bei jedem Start wird das Repo in ein Volume kopiert und dort gebaut, daher ohne Hot
Reload; die Abhängigkeiten liegen in einem gemeinsamen Volume, das einmal aus deinem
~/.m2 befüllt wird (das erste Mal dauert, der Fortschritt steht im Log). Die
Umgebungsprüfung listet die Dienste, die in ihren Container gehen, und warum; Karte und
Tabelle markieren sie, und die Entscheidung fällt beim Neustart des Dienstes neu:
Installierst du das JDK, kehrt er auf deinen Rechner zurück.
Viele Entwicklungsserver (uvicorn, flask run, dotnet run mit seiner
launchSettings.json, Vite) lauschen nur auf 127.0.0.1, und dieser Port lässt sich aus
einem Container nicht veröffentlichen. Für diese Dienste startet neben ihrem Container
ein minimaler Begleit-Container (alpine/socat), der den Port veröffentlicht und an den
Dienst weiterleitet, ohne seinen Befehl anzufassen; er wird mit ihm entfernt.
Angular-Frontends bleiben auf dem Rechner: Ihre --proxy-config ist eine Datei deines
Rechners, die es im Container nicht gibt. Debugging im Werkzeug-Container gibt es nur für
die JVM.
Anpassung des nativen Starts
Abschnitt betitelt „Anpassung des nativen Starts“Der Start im Nativ-Modus kann pro Micro feinjustiert werden (Eigenschaften, Argumente, Datenbank, Befehl…), ohne das Repo zu berühren. Siehe Start anpassen.