Files
DeskcommCRM/docker-compose.build.yml
Rafael MelgaçoandClaude Opus 5 eb1ee9e50f docs(packaging): o build local cobre os três serviços, e o CHANGELOG fala com quem opera a VPS
O docker-compose.build.yml só conhecia o `app`. Com worker e scheduler virando
imagem publicada, construir um deles localmente precisava do mesmo
`pull_policy: never` — sem ele, o `up -d` seguinte volta ao registry e
substitui a imagem local em silêncio, que é o modo de falha que o runbook já
descreve para o app.

APP_VERSION entra como build-arg também no caminho local. Não é segredo: é o que
o /api/v1/health responde, e o default "local" é a resposta honesta para uma
imagem que não veio de release nenhuma.

O runbook deixa de dizer que o deploy é um `up -d` na mão (numa instalação real
é o update.sh, que faz backup e re-aplica o baseline) e passa a avisar que
`latest` segue a `main`, não a última release. E separa as duas réguas de RAM
que estavam se misturando: os 4 GB da seção 4 são do caminho de BUILD, exceção;
a régua de operação é outra e não mudou.

O CHANGELOG está escrito para quem opera a VPS, não para quem lê o diff: o item
do worker diz "o agente continuava rodando o código do dia da instalação, para
sempre" em vez de "serviço build-only não é alcançado por docker compose pull".

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RKm2XcTcfgi1vdMcDYSRWa
2026-08-13 11:26:06 -03:00

41 lines
1.6 KiB
YAML

# Override OPCIONAL para buildar a imagem localmente em vez de puxar do registry.
# Uso (avançado — requer VPS >=4GB RAM ou swap; build leva ~15-25min num VPS):
# docker compose -f docker-compose.prod.yml -f docker-compose.build.yml build
# docker compose -f docker-compose.prod.yml up -d
#
# O caminho normal (leigo) NÃO usa este arquivo — puxa a imagem pronta do GHCR.
services:
app:
build:
context: .
dockerfile: Dockerfile
# Sem args de segredo: a imagem é genérica (NEXT_PUBLIC_* viram placeholder
# no build e os valores reais entram em runtime via env_file). APP_VERSION
# não é segredo — é o que /api/v1/health responde, e sem ele a imagem
# local diria "desconhecido", que é a resposta certa para uma imagem que
# não veio de release nenhuma.
args:
APP_VERSION: ${APP_VERSION:-local}
image: ${APP_IMAGE:-deskcomm-app:local}
pull_policy: never
# O worker e o scheduler já têm `build:` no compose de produção (é o escape
# que mantém a mudança aditiva). O que este override acrescenta é o
# `pull_policy: never`: sem ele, um `up -d` iria ao registry e substituiria a
# imagem local em silêncio — o mesmo modo de falha que o runbook descreve
# para o app, e que já mordeu uma vez.
worker:
build:
args:
APP_VERSION: ${APP_VERSION:-local}
image: ${WORKER_IMAGE:-deskcomm-worker:local}
pull_policy: never
scheduler:
build:
args:
APP_VERSION: ${APP_VERSION:-local}
image: ${SCHEDULER_IMAGE:-deskcomm-scheduler:local}
pull_policy: never