Imagem

Quando usar: antes de empacotar o NNP. A imagem é uma por serviço, feita do mesmo commit do pacote, e entra no pacote pelo digest — nunca por tag.

./mvnw spring-boot:build-image

O comando monta a imagem OCI com o buildpack do Spring Boot (Paketo) e a marca localmente com ${nn.image.name}:${project.version}.

O que o pai já configura

A configuração canônica está no console-service-parent — o módulo não escolhe builder:

Item	Valor
Builder	Imagem do Paketo pinada por digest (nn.image.builder).
Run image	Imagem de execução pinada por digest (nn.image.run).
Java	BP_JVM_VERSION=26, JRE (sem JDK no runtime).
Native Image / AOT	Desligados por contrato — o alvo é JVM com HotSpot/JIT.
Usuário	Non-root (o baseline do namespace é restricted).
Nome	${nn.image.name}:${project.version} — o repositório do registry vem por propriedade.

# o nome da imagem é do ambiente, não do código
./mvnw spring-boot:build-image -Dnn.image.name=cicd.nnumbers.com.br:5003/nnumbers/nns-sample

O digest é o que vale

A tag é conveniência local; o que viaja é o digest:

docker inspect --format '{{index .RepoDigests 0}}' \
  cicd.nnumbers.com.br:5003/nnumbers/nns-sample:0.1.0
# cicd.nnumbers.com.br:5003/nnumbers/nns-sample@sha256:…

Esse texto vai para nns/build/image.ref, que o nnp/release.yaml referencia:

service:
  deployment: helm
  chart: ../nns/helm/chart
  openapi: ../nns/api/openapi.yaml
  image: file:../nns/build/image.ref

E é ele que o Module Manager confere no upload: imagem por tag é recusada (release_invalid). Imagem e pacote têm de sair do mesmo commit — se o código mudar e o digest não, o pacote aponta para outro binário.

O que a imagem contém

• O JAR executável do serviço (o mesmo do ./mvnw package), com os descritores embutidos.
• O runtime JRE 26 e as camadas do Paketo (memory calculator, launch).
• Nada de configuração de ambiente: descritores, segredos, endereço do banco e o papel da release chegam em runtime (ConfigMap, Secret, variáveis NN_*).

A imagem não contém segredo, nem credencial, nem o conteúdo dos slots: eles são montados no pod.

Verificar a imagem

docker run --rm --entrypoint /cnb/lifecycle/launcher \
  cicd.nnumbers.com.br:5003/nnumbers/nns-sample@sha256:… version

O serviço responde com a release embutida (sample@0.1.0). Em ambiente sem runtime de container, a prova equivalente é o JAR direto:

java -jar target/nns-sample-0.1.0.jar version

Erros comuns

• Publicar a tag e referenciar a tag — o MM recusa; e uma tag pode ser reescrita, o que faria o mesmo pacote apontar para outro binário.
• Trocar o builder "só para testar" — builder por tag no POM é recusado pelo enforcer: o buildpack é parte do contrato de build (reprodutibilidade e non-root).
• Assumir um registry específico no POM — o repositório da imagem é do ambiente (-Dnn.image.name=), não do código.
• Colocar configuração na imagem — o mesmo artefato sobe em dev e em produção; configuração e segredo entram por variável/montagem.
• Esquecer o spring-boot-starter-parent — quem gera a imagem é o spring-boot-maven-plugin configurado pelo pai; um POM sem essa herança não tem build-image.
• Buildar a imagem de outro commit — o digest passa a não corresponder ao release_id do pacote.
• Achar que readOnlyRootFilesystem é opcional — o pod sobe com o root filesystem só de leitura; o chart monta emptyDir em /tmp justamente por isso.