Mode natif vs conteneur
Chaque micro d’un scénario tourne dans l’un des deux modes d’exécution, et vous le choisissez par micro :
| Mode | Ce que c’est | Quand |
|---|---|---|
| natif | Le micro démarre comme un processus sur votre machine (avec Maven, npm, uvicorn…) | Le micro que vous développez : démarrage rapide, hot reload, débogage confortable |
| conteneur | Le micro démarre dans un conteneur Docker | Les micros d’arrière-plan : environnement isolé et reproductible, sans encombrer votre machine |
La combinaison habituelle est mixte : natif pour celui que vous développez, conteneur pour ceux qu’il suffit d’avoir lancés pour que le flux fonctionne.
Changer le mode
Section intitulée « Changer le mode »Dans les vues Cartes ou Tableau du scénario, chaque micro a un basculement natif/conteneur. Vous pouvez aussi fixer le mode par défaut d’un micro dans son éditeur (section Micros).
Le mode conteneur nécessite que Docker soit démarré. Le mode natif utilise le
wrapper du dépôt (mvnw, .venv) ou le binaire du PATH. S’il en
manque un (JDK, Maven, Gradle, Node, Go ou le SDK .NET), Aseptic l’installe dans son propre
dossier (~/.aseptic/toolchains/), sans droits administrateur et sans toucher au PATH de
la machine : le copilote, un agent MCP ou aseptic toolchain install peuvent le demander.
Celui que vous avez déjà installé reste prioritaire.
Natif sans JDK ni Maven : le conteneur d’outils
Section intitulée « Natif sans JDK ni Maven : le conteneur d’outils »Un service Spring Boot ou Quarkus avec Maven, Node, Go, Python ou .NET peut tourner en
mode natif sans ses outils sur la machine (JDK et Maven, Node, Go, Python ou le SDK
.NET) : Aseptic exécute la même
commande native dans l’image officielle de son stack, avec la version demandée par le
service (maven:3.9-eclipse-temurin-<java>, node:<version> selon .nvmrc ou
engines, golang:<version> selon go.mod, python:<version> selon .python-version ou
requires-python, le SDK .NET selon le TargetFramework du projet).
C’est son conteneur d’outils, et ce n’est pas le mode conteneur : le service reste
natif pour tout le reste (sa configuration, ses ports, le débogage).
Chaque service choisit l’origine de ses outils dans son éditeur (champ Outils de la configuration de démarrage local) :
| Option | Ce qu’elle fait |
|---|---|
| Automatique (par défaut) | Utilise ceux de votre machine s’ils sont là ; s’il en manque un et que Docker tourne, utilise le conteneur d’outils ; sans Docker, reste sur la machine et le contrôle d’environnement propose d’installer ce qui manque |
| Machine | Toujours ceux de votre machine |
| Conteneur | Toujours l’image officielle |
Ce que vous avez déjà configuré suit : votre settings.xml (et settings-security.xml)
en lecture seule, les variables ${env.X} qu’il cite et l’AC de votre entreprise des
Réglages, ajoutée à la confiance de l’image. Node reçoit aussi votre .npmrc ; Python, votre pip.conf
et les variables PIP_INDEX_URL ; .NET, votre NuGet.Config ; et Go, les variables de
son proxy de modules (GOPROXY, GOPRIVATE…). Si Docker Hub est inaccessible, le registre
d’images des Réglages ajoute le préfixe d’un miroir interne.
Même sans la configurer, le conteneur fait aussi confiance aux AC que votre système a en plus de celles par défaut (le magasin de Windows, le trousseau de macOS ou /etc/ssl sous Linux), là où l’entreprise installe celle du proxy qui inspecte le trafic : un service qui résout sur le dépôt interne depuis votre machine résout de même à l’intérieur. En Java, le magasin obtenu est conservé et les démarrages suivants se contentent de le copier. La vérification TLS n’est jamais désactivée ; si un build ne fait toujours pas confiance à un certificat, le journal du service l’explique par une note au lieu d’un simple PKIX.
Spring Boot et Quarkus avec Gradle démarrent avec le wrapper du dépôt (./gradlew bootRun ou quarkusDev), sans daemon pour qu’arrêter le service arrête aussi l’application, et leur configuration passe par la variable JAVA_TOOL_OPTIONS avec les mêmes -D qu’avec Maven, sans toucher au build.gradle. Dans leur conteneur d’outils, ils utilisent l’image du JDK (eclipse-temurin:<java>) et un cache Gradle propre. Ils se déboguent comme avec Maven ; avec Spring Boot, le débogueur est ajouté uniquement à la JVM de l’application par un init script Gradle qu’Aseptic passe au démarrage, sans toucher au dépôt.
À chaque démarrage, le dépôt est copié dans un volume et compilé là, donc sans
rechargement à chaud ; les dépendances vont dans un volume partagé rempli une fois
depuis votre ~/.m2 (la première fois prend du temps, et son avancement s’affiche dans
le journal). Le contrôle d’environnement liste les services qui iront dans leur
conteneur et pourquoi, la carte et le tableau les signalent, et la décision est reprise
au redémarrage du service : installez le JDK et il revient sur votre machine.
Beaucoup de serveurs de développement (uvicorn, flask run, dotnet run avec son
launchSettings.json, Vite) n’écoutent que sur 127.0.0.1, et ce port ne peut pas être
publié depuis un conteneur. Pour ces services, un conteneur compagnon minimal
(alpine/socat) démarre à côté du leur, publie le port et le redirige vers le service
sans toucher à sa commande ; il est supprimé avec lui. Les frontaux Angular restent sur
la machine : leur --proxy-config est un fichier de votre machine qui n’existe pas dans
le conteneur. Le débogage dans le conteneur d’outils n’est disponible que sur la JVM.
Personnalisation du démarrage natif
Section intitulée « Personnalisation du démarrage natif »Le démarrage en mode natif peut être ajusté par micro (propriétés, arguments, base de données, commande…) sans toucher au dépôt. Voir Personnaliser le démarrage.