Containerización: Docker y OCI

Containerización: Docker y OCI

1) Conceptos y normas básicos de la OCI

OCI Image Spec es un formato de imagen (manifiesto, configuración, capas, índice para multi-nat).
OCI Runtime Spec - Cómo ejecutar un contenedor (bundle, 'config. json`); implementación: runc, así como gVisor, Kata Containers.
OCI Distribution Spec - Interacción con los registros (push/pull, autorización).

Docker = UX y el ecosistema alrededor de OCI: Dockerfile/BuildKit/CLI/Compose/Hub. En Kubernetes, Docker Engine es reemplazado por containerd/CRI-O, pero el formato de las imágenes es el mismo.

2) Imágenes: capas, etiquetas, metadatos

Образ = слои (layered filesystem) + config (entrypoint/cmd/env/labels) + manifest.
Etiquetas: no utilice ': latest' en la venta; pinning ': 1. 21. 3 ', git-SHA o fecha + SHA.
LABEL: propietario, contacto, vcs-url, org. opencontainers. (title, description, revision, source).
Multiarch: el índice de manifiesto da la opción correcta para 'amd64/arm64'.

3) Ensamblaje: Dockerfile, BuildKit, multi-stage

3. 1 Principios

Minimice las capas, fije las versiones, limpie los cachés de los gestores de paquetes.
Primero, copie los archivos manifiesto/bloqueado, luego 'RUN install deps' - mejora la caché.
.dockerignore es obligatorio (excluir '.git', artefactos, secretos).
Se prefieren las muestras distroless/alpine/bases mínimas.

3. 2 fichas BuildKit

Bildes paralelos, secretos en el ensamble ('--secret'), montajes en caché, buildx para multi-nat.

dockerfile syntax=docker/dockerfile:1. 6
RUN --mount=type=cache,target=/root/.cache/pip pip install -r requirements. txt

3. 3 ejemplos de Multi-stage

dockerfile syntax=docker/dockerfile:1. 6
FROM golang:1. 23 AS build
WORKDIR /src
COPY go. mod go. sum./
RUN go mod download
COPY..
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o /app

FROM gcr. io/distroless/static:nonroot
USER 65532:65532
COPY --from=build /app /app
ENTRYPOINT ["/app"]

dockerfile syntax=docker/dockerfile:1. 6
FROM node:22-alpine AS deps
WORKDIR /app
COPY package. json./
RUN npm ci --omit=dev

FROM node:22-alpine AS build
WORKDIR /app
COPY --from=deps /app/node_modules./node_modules
COPY..
RUN npm run build

FROM node:22-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY --from=deps /app/node_modules./node_modules
COPY --from=build /app/dist./dist
USER node
CMD ["node","dist/server. js"]

dockerfile syntax=docker/dockerfile:1. 6
FROM python:3. 12-slim AS base
ENV PYTHONDONTWRITEBYTECODE=1 PYTHONUNBUFFERED=1
WORKDIR /app

FROM base AS deps
RUN --mount=type=cache,target=/root/.cache/pip pip install --upgrade pip
COPY requirements. txt.
RUN --mount=type=cache,target=/root/.cache/pip pip wheel --wheel-dir=/wheels -r requirements. txt

FROM base
COPY --from=deps /wheels /wheels
RUN pip install --no-index --find-links=/wheels -r /app/requirements. txt && rm -rf /wheels
COPY..
USER 1000:1000
CMD ["python","-m","app"]

dockerfile syntax=docker/dockerfile:1. 6
FROM maven:3. 9-eclipse-temurin-21 AS build
WORKDIR /src
COPY pom. xml./
RUN mvn -q -e -DskipTests dependency:go-offline
COPY..
RUN mvn -q -DskipTests package

FROM eclipse-temurin:21-jre
WORKDIR /app
COPY --from=build /src/target/app. jar /app/app. jar
ENTRYPOINT ["java","-XX:+UseContainerSupport","-jar","/app/app. jar"]

4) Imágenes mínimas, PID 1 y señales

Distroless - menos superficie de ataque, sin shell/gestor de paquetes.

dockerfile
ENTRYPOINT ["tini","--","/app"]

'HEALTHCHECK' establece razonablemente (frecuencia/tiempo libre, sin carga excesiva).

5) La seguridad de los contenedores

5. 1 Políticas y hardening

Non-root (USER), rootless Docker/containers.
Capabilities: quite el extra ('--cap-drop = ALL --cap-add = NET _ BIND _ SERVICE', etc.).
seccomp/AppArmor/SELinux: incluye perfiles predeterminados o estrictos.
Read-only FS + `tmpfs` для `/tmp`, no-new-privileges.
Secrets: no en imágenes; montar desde el gestor de secretos (K8s/vault/docker secrets).

5. 2 Supply chain

SBOM (CycloneDX/SPDX) y análisis (Trivy/Grype).
Firma (cosign, sigstore) y política a pull (verify).
Ensayos de actualización: las imágenes básicas con parches de CVE se superponen regularmente.

6) Almacenamiento y controladores de archivos

Por defecto, overlay2 (rápido y estable). En entornos rootless, a menudo fuse-overlayfs.
volumes para datos y cachés, bind-mount para el desarrollo.
No escriba en '/' - utilice la ruta de datos ('/data '), separe el estado de la imagen.

7) Red y DNS

Docker de red: puente (predeterminado), host (mínimo de sobremesa, conflictos de puertos), ninguno, macvlan/ipvlan (integración L2/L3).
DNS-resolver Docker toma desde el host/daemon. json; para prod, configure los resolutores de caché locales.
En K8s, la red es operada por el CNI (Calico/Cilium/Flannel). Para sidecar/mesh: interceptaciones (iptables).

8) Recursos y QoS (cgroups v2)

Restricciones: '--cpus', '--memory', '--pids-limit', '--cpuset-cpus'.
Instalar requests/limits (en K8s) → afecta a la planificación y QoS.
Monitor OOMKilled, throttling, latency spikes debido a GC/IO.

bash docker run --cpus=1. 5 --memory=512m --pids-limit=256 --read-only --tmpfs /tmp:rw,size=64m...

9) Registros y observabilidad

Los conductores de los logs son: 'json-file' (con rotación), 'journald', 'gelf', 'awslogs',' syslog '.

json
{ "log-driver":"json-file","log-opts":{"max-size":"10m","max-file":"5"} }

Métricas: API de motor de Docker, cAdvisor, node-exportadores; rastreo a través de un agente en un contenedor o sidecar.

10) Registros y autenticación

Registros privados: Registro ECR/GCR/ACR/Harbor/GitHub Container.
Rate-limits Docker Hub; use espejos/cachés (registry-cache).
Política retention/immutable tags, replicación entre regiones.
'docker login' no almacene en scripts; use los secretos CI y la federación OIDC.

11) docker-compose vs orquestadores

Compose - Desarrollo local/stands de integración.
Прод: Kubernetes (Deployment/StatefulSet/DaemonSet, Ingress, Secrets, PVC) с containerd/CRI-O; políticas de seguridad y estrategias de rollout.
Swarm es obsoleto para grandes ventas, adecuado para clústeres simples.

yaml version: "3. 9"
services:
api:
build:.
ports: ["8080:8080"]
environment: ["DB_URL=postgres://pg/DB"]
depends_on: ["pg"]
pg:
image: postgres:16-alpine volumes: ["pgdata:/var/lib/postgresql/data"]
volumes: { pgdata: {} }

12) Healthcheck, start/stop, graceful shutdown

Use 'HEALTHCHECK' con límites de tiempo y 'retries'.
Correcto graceful: coge SIGTERM, completa las entradas, cierra las conexiones, luego sale.
В K8s: `preStop` hook + `terminationGracePeriodSeconds`, readiness перед liveness.

13) Mejores prácticas por idiomas/pilas (resumen)

Node: 'npm ci', 'NODE _ ENV = producción', desactivar dev-deps en runtime, '--heapsnapshot' off, 'uWS/GZip' detrás del proxy L7.
Python: wheels, 'gunicorn --graceful-timeout', 'GTHREADS'/' UVICorn' por CPU, no almacenar venv dentro de una capa común sin necesidad.
Go: CGO off (si se puede), '-ldflags =' -s -w '', distroless/static, 'GOMAXPROCS' por cgroups.
Java: JAR de capa, '-XX: MaxRAMPercentage', CDS/Layered JAR para caché.

14) Supply chain y política de imágenes

Generar SBOM en CI, guardar junto al artefacto.
Escanee las imágenes en cada cañón; gate en CVEs críticos.
Firme las imágenes (cosign), active el controlador de políticas (en K8s - Kyverno/Conftest/Gatekeeper).
Comparta las cuentas/redes build y run; almacene en caché las dependencias del registro privado.

15) Anti-patrones

': latest' en venta; sin etiquetas inmutables.
Ensamblaje "dentro del host prod' sin aislamiento; almacenar secretos en Dockerfile.
Ejecutar bajo root, '--privileged', amplias capabilities.
Imágenes gruesas (> 1-2 GB), ninguna. dockerignore.
La lógica init en ENTRYPOINT a través de un formulario shell → problemas con las señales.
Escribir datos constantes en una capa de contenedor en lugar de volume.
Healthcheck, haciendo costosas peticiones a prod-DB.

16) Lista de verificación de implementación (0-45 días)

0-10 días

Estandarizar Dockerfile (multi-stage, .dockerignore, LABEL, base pinned).
Habilitar BuildKit/buildx, el soporte de caché para los administradores de paquetes.
Ir a perfiles no root y 'seccomp '/AppArmor/SELinux predeterminados.

11-25 días

Minimizar las imágenes runtime (alpine/distroless), poner orden con los logs (rotación).
Configurar límites de recursos, healthchecks, PID correcto 1/tini.
Levante el registro privado/caché, conecte el escáner CVE y genere SBOM.

26-45 días

Escriba la firma de la imagen y la directiva de admisión en el clúster.
Organizar multiarch (amd64/arm64) para los servicios deseados.
Documentar el runbook de compilación/lanzamiento, informe de tamaño/vulnerabilidades/tiempo de compilación.

17) Métricas de madurez

Etiquetas inmutables y conjuntos reproducibles para ≥ el 95% de los servicios.
Tamaño medio de la imagen runtime <200-300 MB (por pila).
El 100% de los contenedores prod no son root, con capabilities limitadas y FS léase-only.
SBOM y escaneo de CVE por cada inserción; los CVE críticos → están bloqueados.
Firma de imágenes y policy-enforcement en el entorno.
Tiempo de inicio en frío del contenedor ≤ el SLO objetivo (por ejemplo, 2-5 segundos), correcto graceful shutdown.

18) Conclusión

La containerización adulta son estándares de OCI + disciplina de ensamblaje + seguridad predeterminada + observabilidad y política de suministro. Utilice multi-stage y BuildKit, minimice las imágenes runtime, ejecute non-root bajo perfiles estrictos, fije las etiquetas, escanee y firme, mantenga los registros/recursos/red bajo control. Así que los contenedores se convertirán en la base predecible y manejable de su plataforma, desde el desarrollo hasta la producción.