Modalità nativa vs container
Ogni micro di uno scenario gira in una di due modalità di esecuzione, e la scegli per micro:
| Modalità | Cos’è | Quando |
|---|---|---|
| nativo | Il micro si avvia come processo sulla tua macchina (con Maven, npm, uvicorn…) | Il micro su cui lavori: avvio veloce, hot reload, debug comodo |
| container | Il micro si avvia dentro un container Docker | I micro di sfondo: ambiente isolato e riproducibile, senza sporcare la tua macchina |
La combinazione abituale è mista: nativo quello che sviluppi, container quelli che ti basta avere avviati perché il flusso funzioni.
Cambiare la modalità
Sezione intitolata “Cambiare la modalità”Nelle viste Schede o Tabella dello scenario, ogni micro ha un interruttore nativo/container. Puoi anche fissare la modalità predefinita di un micro nel suo editor (sezione Micro).
La modalità container richiede che Docker sia avviato. La modalità nativa usa il
wrapper del repo (mvnw, .venv) o il binario del PATH. Se ne manca
uno (JDK, Maven, Gradle, Node, Go o l’SDK .NET), Aseptic lo installa nella sua cartella
(~/.aseptic/toolchains/), senza amministratore e senza toccare il PATH della macchina:
lo chiedono il copilota, un agente via MCP o aseptic toolchain install. Quello che hai già
installato resta prioritario.
Nativo senza JDK né Maven: il container degli strumenti
Sezione intitolata “Nativo senza JDK né Maven: il container degli strumenti”Un servizio Spring Boot o Quarkus con Maven, Node, Go, Python o .NET può girare in
modalità nativa senza i suoi strumenti sulla macchina (JDK e Maven, Node, Go, Python o
l’SDK di .NET): Aseptic esegue lo
stesso comando nativo dentro l’immagine ufficiale del suo stack, con la versione richiesta
dal servizio (maven:3.9-eclipse-temurin-<java>, node:<versione> secondo .nvmrc o
engines, golang:<versione> secondo go.mod, python:<versione> secondo .python-version o
requires-python, l’SDK di .NET secondo il TargetFramework del progetto). È il suo container degli strumenti, e non è la modalità container: il
servizio resta nativo in tutto il resto (configurazione, porte, debug).
Ogni servizio decide da dove arrivano i suoi strumenti nel suo editor (campo Strumenti della configurazione di avvio locale):
| Opzione | Cosa fa |
|---|---|
| Automatico (predefinito) | Usa quelli della tua macchina se ci sono; se ne manca uno e Docker è avviato, usa il container degli strumenti; senza Docker resta sulla macchina e il controllo dell’ambiente propone di installare ciò che manca |
| Macchina | Sempre quelli della tua macchina |
| Container | Sempre l’immagine ufficiale |
Ciò che hai già configurato viene incluso: il tuo settings.xml (e
settings-security.xml) in sola lettura, le variabili ${env.X} che cita e la CA
aziendale delle Impostazioni, aggiunta alla fiducia dell’immagine. Node riceve anche il tuo .npmrc; Python, il tuo pip.conf
e le variabili PIP_INDEX_URL; .NET, il tuo NuGet.Config; e Go, le variabili del suo
proxy dei moduli (GOPROXY, GOPRIVATE…). Se Docker Hub non è
raggiungibile, il registro delle immagini delle Impostazioni antepone il prefisso di
un mirror interno.
Anche senza configurarla, il container si fida anche delle CA che il tuo sistema ha in più rispetto a quelle di serie (l’archivio di Windows, il portachiavi di macOS o /etc/ssl su Linux), che è dove l’azienda installa quella del proxy che ispeziona il traffico: un servizio che sulla tua macchina risolve verso il repository interno risolve allo stesso modo dentro. In Java l’archivio risultante viene conservato e gli avvii successivi si limitano a copiarlo. La verifica TLS non si disattiva mai; se un build continua a non fidarsi di un certificato, il log del servizio lo spiega con una nota invece di un PKIX nudo.
Spring Boot e Quarkus con Gradle si avviano con il wrapper del repository (./gradlew bootRun o quarkusDev), senza daemon perché fermare il servizio fermi anche l’applicazione, e la loro configurazione viaggia nella variabile JAVA_TOOL_OPTIONS con gli stessi -D di Maven, senza toccare il build.gradle. Nel loro container degli strumenti usano l’immagine del JDK (eclipse-temurin:<java>) e una cache Gradle propria. Si fanno il debug come con Maven; con Spring Boot, il debugger viene aggiunto solo alla JVM dell’applicazione tramite un init script di Gradle che Aseptic passa all’avvio, senza toccare il repository.
A ogni avvio il repository viene copiato in un volume e compilato lì, quindi senza
ricaricamento a caldo; le dipendenze vanno in un volume condiviso riempito una volta
dal tuo ~/.m2 (la prima volta richiede tempo, e l’avanzamento appare nel log). Il
controllo dell’ambiente elenca i servizi che andranno nel loro container e perché, la
scheda e la tabella li segnalano, e la decisione si ripete al riavvio del servizio:
installa il JDK e torna sulla tua macchina.
Molti server di sviluppo (uvicorn, flask run, dotnet run con il suo
launchSettings.json, Vite) ascoltano solo su 127.0.0.1, e quella porta non si può
pubblicare da dentro un container. Per quei servizi accanto al loro si avvia un container
di accompagnamento minimo (alpine/socat) che pubblica la porta e la inoltra al servizio
senza toccarne il comando; viene rimosso insieme a lui. I frontend Angular restano sulla
macchina: il loro --proxy-config è un file della tua macchina che dentro il container
non esiste. Il debug nel container degli strumenti è disponibile solo sulla JVM.
Personalizzazione dell’avvio nativo
Sezione intitolata “Personalizzazione dell’avvio nativo”L’avvio in modalità nativa può essere affinato per micro (proprietà, argomenti, database, comando…) senza toccare il repo. Vedi Personalizzare l’avvio.