Construir imagens Docker¶
Escolha o Dockerfile do serviço e execute o build na raiz desse repositório: o argumento final . define o contexto. Não substitua a imagem de outro serviço apenas porque ambos usam Java ou Go.
Caminhos disponíveis¶
| Caminho | Como funciona | Atenção |
|---|---|---|
docker/Dockerfile.jvm |
Empacota o target/quarkus-app/ previamente construído |
Execute o build Maven antes; não contém necessariamente a compilação/testes |
docker/Dockerfile.native |
Empacota o binário nativo | Depende do artefato e arquitetura esperados pelo arquivo |
devops/docker/Dockerfile |
Pode compilar, testar e declarar estágios de pipeline | Imagens privadas, credenciais e estágios Sonar variam por serviço |
devops/docker/Dockerfile.local |
Alternativa local quando existente, como no Broker | Não existe em todos os repositórios; não é equivalente ao quality gate da pipeline |
Exemplo JVM comprovado: JSON Handler¶
Na raiz de totvs-gateway-jsonhandler, após ./mvnw.cmd verify:
docker build -f docker/Dockerfile.jvm -t gateway-jsonhandler:docs-20261016-01 .
docker run --detach --rm --name gateway-docs-jsonhandler -p 127.0.0.1:18080:8080 gateway-jsonhandler:docs-20261016-01
docker logs gateway-docs-jsonhandler
O Dockerfile usa ubi9/openjdk-21:1.23, copia o pacote completo e executa como usuário 185. A jornada completa contém health check, chamada funcional e encerramento do container.
Go e imagens privadas¶
O Router compila e testa dentro de devops/docker/Dockerfile, mas suas bases Go/Alpine vêm de um Artifact Registry privado. A tentativa de build nesta execução foi bloqueada por permissão de download. O comando documentado é válido como entrada do build, mas não teve resultado funcional validado neste ambiente.
O Broker possui devops/docker/Dockerfile.local, com bases públicas e compilação de ./cmd/api. Esse arquivo não executa a suíte de testes: testes precisam ser tratados separadamente. Não se presume que o estágio Sonar declarado em um Dockerfile tenha sido executado: confira as dependências dos estágios e o log do build.
Tags e entrega ao Kind¶
Use uma tag nova por iteração. Não use latest nem reutilize a mesma tag para distinguir versões locais. A sequência é: construir → carregar nos nós → atualizar o valor da imagem na release → aguardar rollout → testar a operação.
docker build cria a imagem no daemon Docker; isso não a disponibiliza automaticamente para o containerd dos nós Kind. O guia Kind explica kind load docker-image e o override de imagePullPolicy.