Modo nativo vs contenedor
Cada micro de un escenario corre en uno de dos modos de ejecución, y lo eliges por micro:
| Modo | Qué es | Cuándo |
|---|---|---|
| nativo | El micro se arranca como un proceso en tu máquina (con Maven, npm, uvicorn…) | El micro que estás tocando: arranque rápido, hot reload, depuración cómoda |
| contenedor | El micro se arranca dentro de un contenedor Docker | Los micros de fondo: entorno aislado y reproducible, sin ensuciar tu máquina |
La combinación habitual es mixta: nativo el que desarrollas, en contenedor los que solo necesitas levantados para que el flujo funcione.
Cambiar el modo
Sección titulada «Cambiar el modo»En las vistas de Tarjetas o Tabla del escenario, cada micro tiene un conmutador nativo/contenedor. También puedes fijar el modo por defecto de un micro en su editor (sección Micros).
El modo en contenedor requiere que Docker esté iniciado. El modo nativo usa el
wrapper del repo (mvnw, .venv) o el binario del PATH. Si falta
alguna herramienta (JDK, Maven, Gradle, Node, Go o el SDK de .NET), Aseptic la instala en su
propia carpeta (~/.aseptic/toolchains/), sin administrador y sin tocar el PATH de la máquina:
lo piden el copiloto, un agente por MCP o aseptic toolchain install. La que ya tengas
instalada sigue mandando.
Nativo sin JDK ni Maven: el contenedor de herramientas
Sección titulada «Nativo sin JDK ni Maven: el contenedor de herramientas»Un micro de Spring Boot o Quarkus con Maven, de Node, Go, Python o .NET puede ir en modo
nativo sin tener sus herramientas en la máquina (JDK y Maven, Node, Go, Python o el
SDK de .NET): Aseptic ejecuta el
mismo comando nativo dentro de la imagen oficial de su stack, con la versión que pide el
micro (maven:3.9-eclipse-temurin-<java>, node:<versión> según .nvmrc o engines,
golang:<versión> según go.mod, python:<versión> según .python-version o
requires-python, el SDK de .NET según el TargetFramework del proyecto). Es su contenedor de herramientas, y no es el modo contenedor: el micro sigue
siendo nativo en todo lo demás (su configuración, sus puertos, la depuración).
Cada micro decide de dónde salen sus herramientas en su editor (campo Herramientas de la configuración de arranque local):
| Opción | Qué hace |
|---|---|
| Automático (por defecto) | Usa las de tu máquina si están; si falta alguna y Docker está iniciado, usa el contenedor de herramientas; sin Docker se queda en la máquina y el chequeo de entorno ofrece instalar lo que falta |
| Máquina | Siempre las de tu máquina |
| Contenedor | Siempre la imagen oficial |
Lo que ya tienes configurado entra igual: tu settings.xml (y settings-security.xml)
en solo lectura, las variables ${env.X} que cite y la CA de tu empresa de Ajustes,
que se añade a la confianza de la imagen. En Node también entra tu .npmrc; en Python, tu
pip.conf y las variables PIP_INDEX_URL; en .NET, tu NuGet.Config; y en Go, las
variables de su proxy de módulos (GOPROXY, GOPRIVATE…). Si no puedes bajar de Docker Hub, el registro de
imágenes de Ajustes antepone el prefijo de un espejo interno.
Aunque no la configures, el contenedor confía también en las CA que tu sistema tiene de más respecto a las de serie (el almacén de Windows, el llavero de macOS o /etc/ssl en Linux), que es donde la empresa instala la del proxy que inspecciona el tráfico: un micro que en tu máquina resuelve contra el repositorio interno resuelve igual dentro. En Java, el almacén resultante se guarda y los siguientes inicios solo lo copian. La verificación TLS no se desactiva nunca; si aun así un build no se fía de un certificado, el log del micro lo explica con una nota en lugar de dejar el PKIX a secas.
Spring Boot y Quarkus con Gradle se arrancan con el wrapper del repo (./gradlew bootRun o quarkusDev), sin daemon para que parar el micro pare también la aplicación, y su configuración viaja en la variable JAVA_TOOL_OPTIONS con los mismos -D que en Maven, sin tocar el build.gradle. En su contenedor de herramientas usan la imagen del JDK (eclipse-temurin:<java>) y una caché propia de Gradle. Se depuran igual que con Maven; en Spring Boot, el depurador se añade solo a la JVM de la aplicación con un init script de Gradle que Aseptic pasa al arrancar, sin tocar el repo.
En cada inicio el repo se copia a un volumen y se compila allí, así que no hay recarga
en caliente; las dependencias van a un volumen compartido que se llena una vez desde
tu ~/.m2 (la primera vez tarda, y su avance sale en el log). El chequeo de entorno
lista los micros que irán a su contenedor y por qué, la tarjeta y la tabla lo marcan, y
la decisión se repite al reiniciar el micro: si instalas el JDK, vuelve a tu máquina.
Muchos servidores de desarrollo (uvicorn, flask run, dotnet run con su
launchSettings.json, Vite) escuchan solo en 127.0.0.1, y desde dentro de un
contenedor ese puerto no se puede publicar. Para esos micros, junto al suyo se inicia un
contenedor acompañante mínimo (alpine/socat) que publica el puerto y lo reenvía al
micro, sin tocar su comando; se elimina con él. Los frentes Angular se quedan en la
máquina: su --proxy-config es un fichero de tu máquina que dentro del contenedor no
existe. La depuración en el contenedor de herramientas solo está disponible en la JVM.
Personalización del arranque nativo
Sección titulada «Personalización del arranque nativo»El arranque en modo nativo se puede afinar por micro (propiedades, argumentos, base de datos, comando…) sin tocar el repo. Ver Personalizar el arranque.