VPS 4 Builder
0a83c0f515
O proxy HTTPS de git.clube67.com corta uploads em ~60 s, a ~0,75 MB/s: blobs
acima de ~45 MB não publicam (o Gitea recebe o corpo truncado e responde 500).
O maior blob daqui tem 39,5 MB — publicava raspando, e qualquer dependência nova
quebraria o deploy. Pelo WireGuard são ~2,4 MB/s, sem corte.
Mesmo Gitea, mesmo repositório, mesmas tags: só muda o caminho de rede. Verificado
na VPS1 que `10.99.0.3:3000/ruicesar/scoreodonto-backend:v1.0.39` entrega o mesmo
image id que o container em execução — o rollback para tags antigas segue válido.
- docker-compose.prod.yml / deploy-prod.sh / workflow: registry passa a ser
10.99.0.3:3000. Requer `insecure-registries` no daemon da VPS1 e do runner
(já aplicado; a porta 3000 não é exposta à internet, só pelo túnel).
- promote: `buildx imagetools` não fala com registry HTTP, então o manifest é
copiado pela API v2 do registry. Byte a byte ⇒ digest idêntico, que continua
sendo conferido antes de deployar.
- promote: autentica com o `docker login` do runner. `secrets.REGISTRY_TOKEN` não
existe neste repo — o `docker login` mascarava isso; o curl não.
- docker-compose.prod.yml: `${SCOREODONTO_TAG:?}` no lugar de `:-latest`. Sem a
tag o deploy agora ABORTA, em vez de subir uma imagem indeterminada em produção.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
35 lines
2.1 KiB
YAML
35 lines
2.1 KiB
YAML
# Override de PRODUÇÃO (VPS1): roda IMAGENS VERSIONADAS do registry em vez de buildar.
|
|
# A produção não builda — só consome a imagem pronta publicada pela CI.
|
|
#
|
|
# Uso (na VPS1), via deploy-prod.sh <tag>, que exporta SCOREODONTO_TAG e faz:
|
|
# docker compose -f docker-compose.yml -f docker-compose.prod.yml pull ...
|
|
# docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d --no-build ...
|
|
# O --no-build garante que o build: do compose base seja ignorado (usa a imagem puxada).
|
|
#
|
|
# VERSÃO EM RUNTIME (Passo 3): a versão semântica EXIBIDA (/api/version → footer/Configurações)
|
|
# vem da TAG promovida, injetada via `environment` abaixo — NÃO do build. `commit` e `build`
|
|
# continuam vindo do ENV carimbado na imagem (imutáveis, propriedade do artefato). Assim a
|
|
# MESMA imagem pode ser promovida sob qualquer tag sem rebuild — pré-requisito do
|
|
# "build once, promote the same artifact". O frontend não precisa de versão aqui: é estático
|
|
# e lê tudo de /api/version (backend) em runtime.
|
|
#
|
|
# REGISTRY PELA VPN (10.99.0.3:3000), não por git.clube67.com: o proxy HTTPS corta
|
|
# uploads em ~60 s e a banda por ele é ~0,75 MB/s, então blobs acima de ~45 MB não
|
|
# publicam (o maior daqui tem 39,5 MB — passava raspando). Mesmo Gitea, mesmo
|
|
# repositório, mesmas tags: só o caminho de rede muda, e o rollback para tags
|
|
# antigas continua funcionando. Exige `insecure-registries: ["10.99.0.3:3000"]`
|
|
# no daemon da VPS1 e do runner.
|
|
services:
|
|
scoreodonto-backend:
|
|
# `:?` (e não `:-latest`): sem SCOREODONTO_TAG o deploy ABORTA, em vez de subir
|
|
# silenciosamente uma imagem indeterminada em produção.
|
|
image: "10.99.0.3:3000/ruicesar/scoreodonto-backend:${SCOREODONTO_TAG:?defina SCOREODONTO_TAG}"
|
|
# Mescla com o environment do compose base (por chave). Sobrescreve o APP_VERSION/APP_ENV
|
|
# que vieram embutidos na imagem pelo build, fixando a versão = tag e o ambiente = PROD.
|
|
environment:
|
|
- APP_VERSION=${SCOREODONTO_TAG}
|
|
- APP_ENV=PROD
|
|
|
|
scoreodonto-frontend:
|
|
image: "10.99.0.3:3000/ruicesar/scoreodonto-frontend:${SCOREODONTO_TAG:?defina SCOREODONTO_TAG}"
|