Modo nativo vs contentor
Cada micro de um cenário corre num de dois modos de execução, e escolhe-o por micro:
| Modo | O que é | Quando |
|---|---|---|
| nativo | O micro arranca como um processo na sua máquina (com Maven, npm, uvicorn…) | O micro em que está a trabalhar: arranque rápido, hot reload, depuração cómoda |
| contentor | O micro arranca dentro de um contentor Docker | Os micros de fundo: ambiente isolado e reproduzível, sem sujar a sua máquina |
A combinação habitual é mista: nativo o que desenvolve, contentor os que só precisa de ter iniciados para que o fluxo funcione.
Mudar o modo
Seção intitulada “Mudar o modo”Nas vistas de Cartões ou Tabela do cenário, cada micro tem um comutador nativo/contentor. Também pode fixar o modo predefinido de um micro no seu editor (secção Micros).
O modo contentor requer que o Docker esteja iniciado. O modo nativo usa o wrapper
do repo (mvnw, .venv) ou o binário do PATH. Se faltar
algum (JDK, Maven, Gradle, Node, Go ou o SDK de .NET), o Aseptic instala-o na sua própria
pasta (~/.aseptic/toolchains/), sem administrador e sem mexer no PATH da máquina:
pedem-no o copiloto, um agente por MCP ou aseptic toolchain install. O que já tiver
instalado continua a prevalecer.
Nativo sem JDK nem Maven: o contentor de ferramentas
Seção intitulada “Nativo sem JDK nem Maven: o contentor de ferramentas”Um serviço Spring Boot ou Quarkus com Maven, Node, Go, Python ou .NET pode correr em
modo nativo sem as suas ferramentas na máquina (JDK e Maven, Node, Go, Python ou o
SDK do .NET): o Aseptic executa o mesmo
comando nativo dentro da imagem oficial do seu stack, com a versão que o serviço pede
(maven:3.9-eclipse-temurin-<java>, node:<versão> segundo .nvmrc ou engines,
golang:<versão> segundo go.mod, python:<versão> segundo .python-version ou
requires-python, o SDK do .NET segundo o TargetFramework do projeto). É o seu
contentor de ferramentas, e não é o modo contentor: o serviço continua nativo em
tudo o resto (configuração, portas, depuração).
Cada serviço decide de onde vêm as suas ferramentas no seu editor (campo Ferramentas da configuração de arranque local):
| Opção | O que faz |
|---|---|
| Automático (por omissão) | Usa as da sua máquina se existirem; se faltar alguma e o Docker estiver iniciado, usa o contentor de ferramentas; sem Docker fica na máquina e a verificação do ambiente oferece instalar o que falta |
| Máquina | Sempre as da sua máquina |
| Contentor | Sempre a imagem oficial |
O que já tem configurado entra igual: o seu settings.xml (e settings-security.xml)
só de leitura, as variáveis ${env.X} que cita e a AC da sua empresa das Definições,
adicionada à confiança da imagem. No Node entra também o seu .npmrc; no Python, o seu
pip.conf e as variáveis PIP_INDEX_URL; no .NET, o seu NuGet.Config; e no Go, as
variáveis do seu proxy de módulos (GOPROXY, GOPRIVATE…). Se não conseguir usar o Docker Hub, o registo de
imagens das Definições antepõe o prefixo de um espelho interno.
Mesmo sem a configurar, o contentor confia também nas AC que o seu sistema tem a mais em relação às de série (o armazém do Windows, o porta-chaves do macOS ou /etc/ssl no Linux), que é onde a empresa instala a do proxy que inspeciona o tráfego: um serviço que na sua máquina resolve contra o repositório interno resolve igual lá dentro. Em Java, o armazém resultante guarda-se e os arranques seguintes só o copiam. A verificação TLS nunca se desativa; se mesmo assim um build não confiar num certificado, o log do serviço explica-o com uma nota em vez de um PKIX seco.
Spring Boot e Quarkus com Gradle arrancam com o wrapper do repositório (./gradlew bootRun ou quarkusDev), sem daemon para que parar o serviço pare também a aplicação, e a sua configuração viaja na variável JAVA_TOOL_OPTIONS com os mesmos -D que no Maven, sem tocar no build.gradle. No seu contentor de ferramentas usam a imagem do JDK (eclipse-temurin:<java>) e uma cache própria do Gradle. Depuram-se tal como com Maven; no Spring Boot, o depurador é adicionado apenas à JVM da aplicação através de um init script do Gradle que o Aseptic passa ao arrancar, sem tocar no repositório.
Em cada início o repositório é copiado para um volume e compilado aí, por isso não há
recarga a quente; as dependências vão para um volume partilhado preenchido uma vez a
partir do seu ~/.m2 (a primeira vez demora, e o progresso aparece no registo). A
verificação do ambiente lista os serviços que irão para o seu contentor e porquê, o
cartão e a tabela assinalam-nos, e a decisão repete-se ao reiniciar o serviço: instale o
JDK e ele volta à sua máquina.
Muitos servidores de desenvolvimento (uvicorn, flask run, dotnet run com o seu
launchSettings.json, Vite) escutam só em 127.0.0.1, e essa porta não pode ser
publicada a partir de um contentor. Para esses serviços, ao lado do seu inicia-se um
contentor acompanhante mínimo (alpine/socat) que publica a porta e a reencaminha para o
serviço sem tocar no seu comando; é eliminado com ele. Os frontends Angular ficam na
máquina: o seu --proxy-config é um ficheiro da sua máquina que não existe dentro do
contentor. A depuração no contentor de ferramentas só está disponível na JVM.
Personalização do arranque nativo
Seção intitulada “Personalização do arranque nativo”O arranque em modo nativo pode ser afinado por micro (propriedades, argumentos, base de dados, comando…) sem tocar no repo. Ver Personalizar o arranque.