Files
SLA_SEPARACAO/README.md
T
joao.herculano 850eb25f3f corrige links quebrados do README e documenta lacunas pós-limpeza
Os links de Dockerfile/Jenkinsfile/k8s apontavam para caminhos
absolutos do WSL de uma máquina específica (quebrados desde o
primeiro commit). Trocados por caminhos relativos.

Adiciona: fluxo de build/start local de produção, passo a passo de
aplicar o secret via create-secret.sh, explicação do patch em
patches/ (postinstall) e nota sobre o preset node-server do nitro.
2026-08-06 14:11:21 -03:00

3.0 KiB

SLA Separacao

Aplicacao TanStack Start/Node.js para registro de coleta de pedidos, usando SQL Server.

Desenvolvimento local

cp .env.example .env   # preencha com as credenciais do seu ambiente
npm install
npm run dev

O npm install roda um postinstall que reaplica automaticamente o patch em patches/ (veja "Patches de dependências" abaixo).

Build de produção local

Para validar um build antes de mandar pro Jenkins:

npm run build
node .output/server/index.mjs

É o mesmo comando que o Dockerfile roda no container final.

Estrutura de deploy

Este repositorio ja possui a base para subir o app como servico separado:

Variaveis obrigatorias

O app precisa destas variaveis no ambiente de deploy (veja .env.example):

  • DB_HOST
  • DB_PORT
  • DB_NAME
  • DB_USER
  • DB_PASSWORD
  • DB_ENCRYPT
  • DB_TRUST_SERVER_CERT
  • DB_SERVER_NAME
  • SESSION_SECRET

Aplicando o secret no cluster

Com kubectl configurado para o namespace ci-cd, exporte as variaveis acima e rode:

NAMESPACE=ci-cd SECRET_NAME=sla-separacao-env \
DB_HOST=... DB_PORT=... DB_NAME=... DB_USER=... DB_PASSWORD=... \
DB_ENCRYPT=... DB_TRUST_SERVER_CERT=... DB_SERVER_NAME=... SESSION_SECRET=... \
./k8s/create-secret.sh

O script usa kubectl apply (idempotente) e nunca grava os valores em disco.

Patches de dependências

patches/@tanstack+start-server-core+*.patch corrige um bug no @tanstack/start-server-core: a lib cria o middleware de CSRF padrão de forma incondicional ao carregar o módulo, o que colide com um import circular gerado pelo nitro no build de produção e quebra toda requisição (createCsrfMiddleware is not a function). O patch adia essa criação para dentro de uma função. Ele é reaplicado automaticamente pelo postinstall a cada npm install; se atualizar @tanstack/start-server-core, confira se o patch ainda se aplica.

Antes do deploy

Voce precisa validar estes pontos no ambiente da empresa:

  1. O cluster/servidor consegue acessar 10.77.77.10:1433.
  2. O registry 10.77.77.41:5000 aceita push da nova imagem.
  3. O namespace ci-cd e o padrao de deploy pelo Jenkins continuam validos.
  4. A nodePort 30310 esta livre, ou voce vai trocar para outra.
  5. Existe uma forma de expor esse novo servico externamente depois do Service.

Observacoes

  • O app atual usa SQL Server direto, sem API intermediaria.
  • O deploy criado aqui e separado do app Django existente.
  • O repositório nao guarda o secret real de producao; ele deve ser criado no cluster.
  • O build de produção usa o preset node-server do nitro (não Cloudflare) — o Dockerfile roda node .output/server/index.mjs diretamente, então o preset precisa continuar assim.