Skip to content

Aplicações Backend

Visão Geral

As aplicações backend da plataforma são majoritariamente serviços Java empacotados via Maven e executados em containers com runtime JRE ou OpenJDK slim. O padrão operacional é:

  1. Build multi-stage no Dockerfile
  2. Push da imagem para o OCIR
  3. Deploy via Helm chart + ArgoCD
  4. Configuração por secrets sincronizados do Vault via ESO

Inventário

Aplicação Runtime Porta do app Build Dockerfile Observações
auth-api Spring Boot 3.1.6 / Java 21 7000 Maven padrão Java Chaves privadas/públicas no secret
is-core-api Spring Boot 2.7 / Java 21 7002 Maven multi-módulo Dockerfile-is-core-api NFS para arquivos e mídia
is-notification-api Spring Boot 3.2.8 / Java 21 7006 Maven padrão Java Integração Twilio
is-portal-api Spring Boot 3.2.5 / Java 21 7004 Maven padrão Java Path dedicado no HTTPRoute
is-regulation-api Spring Boot 2.7 / Java 17 7008 Maven padrão Java Outlier de versão Java
is-reports-api Spring Boot 3.2.5 / Java 21 7010 Maven padrão Java Fluxo funcional de relatórios
is-ws-api Spring Boot 2.7 / Java 21 7001 Maven padrão Java NFS para mídia
redeis-auth-api Spring Boot 2.3.4 / Java 8 8080 Maven legado Java 8 Secrets em system/redeis-auth-api/config
redeis-ws-api Chart existente, repositório stub 8080 N/A chart/infra Repositório atual só contém README

Padrão de Build Java

O padrão mais comum usa três estágios:

```dockerfile FROM maven:3.9.9-eclipse-temurin-${JAVA_VERSION} AS dependencies WORKDIR /app COPY pom.xml ./ RUN mvn dependency:resolve dependency:resolve-plugins

FROM dependencies AS build COPY . ./ RUN mvn clean package -DskipTests

FROM openjdk:${JAVA_VERSION}-slim WORKDIR /usr/src/app COPY --from=build /app/target/app.jar ./ EXPOSE 6001 ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -server -jar app.jar"] ```

Porta real do serviço

O EXPOSE do Dockerfile não é a fonte de verdade da aplicação em produção. O que vale no cluster é o containerPort configurado no Helm chart e o server.port exposto pela aplicação.

Detalhes por Aplicação

auth-api

  • Usa o padrão Java simples com build Maven e imagem final enxuta.
  • O chart injeta secrets de tenants/{namespace}/auth-api/config.
  • Há tratamento específico para chaves PEM em base64 no ESO.
  • O path de healthcheck e o HTTPRoute normalmente ficam sob /auth-api.

is-core-api

  • É o único backend multi-módulo relevante neste conjunto.
  • O Dockerfile compila models/ e api/ separadamente para aproveitar cache de dependências.
  • O runtime cria diretórios extras para mídia e arquivos.
  • Requer volumes NFS para arquivos operacionais e mídia compartilhada.
  • É também o caso com maior heap, normalmente -Xmx4096m.

is-notification-api

  • Segue o padrão Java simples.
  • A documentação operacional deve considerar integrações externas, especialmente Twilio, como parte do conjunto de secrets da aplicação.
  • O chart usa path dedicado /is-notification-api e readiness/liveness por HTTP.

is-portal-api

  • Backend Java simples, sem storage especial.
  • O Dockerfile é semelhante ao auth-api.
  • O chart publica a API via path /is-portal-api e usa secrets tenant-scoped.

is-regulation-api

  • É exceção de versão: usa Java 17, não Java 21.
  • Ainda segue o padrão de build Java, mas deve ser tratada como serviço legado intermediário para upgrade futuro.
  • A memória configurada no chart costuma ser maior, em torno de -Xmx3072m.

is-reports-api

  • Mantém pipeline Maven padrão, mas o domínio funcional é voltado a relatórios.
  • Deve ser documentada junto do is-reports-ui porque ambos participam do fluxo de relatórios, embora tenham runtimes distintos.

is-ws-api

  • Backend Java com dependência operacional de NFS.
  • O mount é usado para mídia compartilhada.
  • O Dockerfile não revela essa dependência; ela aparece no chart e na configuração do tenant.

redeis-auth-api

  • Serviço legado com Java 8 e Spring Boot 2.3.4.
  • Os secrets não são tenant-scoped; a configuração vem de system/redeis-auth-api/config.
  • O domínio também é diferenciado em relação aos serviços tenant-scoped.

redeis-ws-api

  • O chart existe, mas o repositório de aplicação inspecionado hoje não contém código executável além de um README.
  • A documentação deve tratá-lo como serviço provisionado via chart/configuração, com validação futura quando o código for disponibilizado.

Secrets e Configuração

Para os backends, o padrão é:

  1. Secret no Vault em tenants/{namespace}/{app}/config
  2. ExternalSecret sincroniza para um Secret do Kubernetes
  3. O Deployment consome o Secret via envFrom
  4. O Reloader reinicia o pod quando o Secret é alterado

Exceções relevantes:

  • redeis-auth-api e alguns serviços system-scoped usam system/{app}/config
  • auth-api precisa de chaves adicionais para autenticação
  • is-core-api exige também volumes e configuração ligada a OCI/NFS

Deploy

O fluxo de deploy é o mesmo do catálogo geral:

  1. PR dispara CI
  2. Merge gera imagem e atualiza configuração do tenant em HML
  3. ArgoCD sincroniza o chart
  4. Secrets são resolvidos via Vault/ESO antes do pod ficar pronto

Para os requisitos de chart por aplicação, consulte Requisitos por Aplicação.