Docker
Build, test, push, promoción, cache y despliegue reproducible.
Un pipeline Docker confiable construye el artefacto una sola vez, prueba exactamente ese resultado y promueve su digest entre ambientes.
commit protegido
→ tests
→ build
→ scan + attestations
→ push
→ digest aprobado
→ staging
→ producciónReconstruir durante deployment produce un artefacto distinto, aunque use el mismo commit. Las bases, dependencias, clocks, registry y parámetros pueden haber cambiado.
La frontera es el digest publicado.
checkout SHA
→ validar Dockerfile/Compose
→ construir target test
→ construir runtime
→ ejecutar tests sobre runtime
→ generar SBOM/provenance
→ escanear
→ push
→ firmar digest
→ desplegar staging
→ smoke/integration
→ promover mismo digest
→ rollout producciónTests fuera del container son rápidos, pero no prueban el artefacto final.
Combina:
Ejemplo:
docker build --target test .
docker build --target runtime -t api:test .
docker run --rm api:test node --version
docker run --rm api:test npm run smokeUn builder moderno permite:
El pipeline debe fijar versión/configuración del builder y registrar logs suficientes para reproducir fallos.
Tags útiles:
api:git-abc1234
api:1.8.2
api:mainPero la salida autorizada es:
api@sha256:...Registra el digest como output del job y úsalo en todos los stages posteriores.
No promuevas copiando latest; promueve el subject digest o crea tags adicionales que apunten al mismo contenido.
cache key/scope
→ layers reutilizables
→ build más rápidoDiseña scopes:
Una PR externa no debe escribir cache consumida por releases privilegiados.
El build debe funcionar con cache vacía. La cache es optimización, no fuente única.
Cambios que deben invalidar:
No uses timestamps artificiales que destruyan cache sin motivo. Para rebuild de seguridad, actualiza el digest/base o usa un input versionado y auditable.
Usa BuildKit secrets:
docker build \
--secret id=npmrc,src="$RUNNER_TEMP/npmrc" \
.No uses:
ARG TOKEN;.env copiado;Prefiere identidad federada/OIDC o tokens cortos cuando el registry y plataforma lo soporten.
Los secrets de producción no deben existir en el build.
Aplica mínimo privilegio:
Protege environments con approvals cuando el riesgo lo requiera.
Riesgos de runners persistentes:
Prefiere runners efímeros para builds sensibles. Si son persistentes:
Controlar /var/run/docker.sock suele equivaler a control administrativo del runner.
No ejecutes código de PR no confiable con acceso a un socket de un host que contiene secrets o workloads de otros proyectos.
Alternativas:
Asocia cada resultado al digest:
sha256:A
├── SBOM
├── scan result
├── provenance
└── signatureEscanea cada plataforma. Define política de findings:
No ocultes el exit code del scanner para que el pipeline “pase”. Tampoco bloquees por conteo bruto sin contexto.
En builds multi-platform, el índice y manifests deben publicarse correctamente. Evita desplegar un tag mientras todavía está incompleto.
Publica a un tag temporal o por digest, verifica y después crea referencias de release.
docker compose -p ci-${CI_RUN_ID} up -d --wait
docker compose -p ci-${CI_RUN_ID} run --rm tests
docker compose -p ci-${CI_RUN_ID} logs --no-color > compose.log
docker compose -p ci-${CI_RUN_ID} down -vUsa project name único para evitar colisiones. Ejecuta cleanup incluso si los tests fallan.
No reutilices volumes de datos entre jobs salvo diseño explícito.
Patrón:
pre-deploy compatible migration
→ rollout app
→ post-deploy cleanup posteriorLas migrations deben ejecutarse como job coordinado y producir logs/exit code.
Antes de una migration destructiva:
Reemplaza instancias gradualmente. Requiere compatibilidad entre versiones simultáneas.
Mantiene versión anterior y nueva. Permite cambio rápido, pero datos/schema deben ser compatibles.
Envía pequeña fracción de tráfico y compara métricas.
Compose single-host no proporciona por sí solo todas estas estrategias. Puede implementarse con proxy y procedimientos, pero el riesgo debe aceptarse.
Después del deploy verifica:
Un health 200 superficial no basta.
Define ventana y criterios:
No marques éxito inmediatamente después de docker compose up -d.
Un rollback necesita:
nuevo digest B falla
→ volver a digest ASi una migration destruyó datos o cambió formato, volver la image no restaura el estado. Por eso database changes requieren estrategia separada.
Conserva:
Define retención suficiente para rollback e incident response. Garbage collection prematura puede eliminar el único artefacto recuperable.
Aunque no cambie source:
scheduled rebuild
→ nueva base parcheada
→ tests
→ scan
→ rolloutTrátalo como release. Un nuevo digest puede cambiar comportamiento.
jobs:
build:
permissions:
contents: read
packages: write
id-token: write
steps:
- uses: actions/checkout@v4
- uses: docker/setup-buildx-action@v3
- uses: docker/login-action@v3
- uses: docker/build-push-action@v6
with:
context: .
push: true
tags: registry.example.com/api:git-${{ github.sha }}
cache-from: type=registry,ref=registry.example.com/api:buildcache
cache-to: type=registry,ref=registry.example.com/api:buildcache,mode=max
provenance: true
sbom: trueLas versiones concretas deben mantenerse actualizadas y revisadas. Fija actions por política de supply chain cuando corresponda.
docker inspect api --format '{{.Image}}'
docker image inspect registry.example.com/api@sha256:...Compara el digest esperado con el ejecutado. Un tag correcto no es evidencia suficiente.
Repite con cache vacía y revisa trust boundary.
No promociones hasta verificar manifests y attestations.
Añade wait/smoke y observación.
Schema o secret no son backward compatible.
latest como release;Multi-platform builds, donde un solo tag puede resolver a imágenes diferentes según arquitectura y sistema operativo.