Jonatan Matajonmatum.com
conceptosnotasexperimentosensayos
© 2026 Jonatan Mata. All rights reserved.v2.1.1
Conceptos

Registros de Contenedores

Repositorios para almacenar, versionar y distribuir imágenes de contenedores, desde registros públicos como Docker Hub hasta registros privados como ECR.

evergreen#containers#registry#docker#ecr#ghcr#images

¿Qué es?

Un registro de contenedores es un repositorio centralizado para almacenar, versionar y distribuir imágenes de contenedores Docker. Funciona como npm para paquetes Node.js o Maven para artefactos Java, pero específicamente diseñado para imágenes de contenedores que siguen el estándar OCI (Open Container Initiative).

Los registros de contenedores implementan la especificación OCI Distribution, que define APIs REST para subir (push), descargar (pull) y gestionar imágenes de contenedores. Cada imagen se identifica por un nombre de repositorio y una etiqueta (tag), como nginx:1.25 o myapp:v2.1.0. Los registros también soportan direccionamiento por digest SHA256 para referencias inmutables.

En arquitecturas modernas basadas en contenedores, el registro actúa como el punto central de distribución entre el proceso de construcción (CI/CD) y los entornos de ejecución (Kubernetes, ECS, Docker Swarm). Sin un registro confiable, no hay forma escalable de distribuir aplicaciones containerizadas.

Comparación de registros principales

RegistroTipoLímites gratuitosCaracterísticas claveCasos de uso
Docker HubPúblico/Privado1 repo privado, 200 pulls/6hImágenes oficiales, mayor ecosistemaProyectos open source, prototipado
Amazon ECRPrivado (AWS)500MB/mes gratisIntegración nativa ECS/EKS, escaneo vulnerabilidadesAplicaciones AWS, entornos empresariales
GitHub GHCRPúblico/Privado500MB gratisIntegración GitHub Actions, autenticación SSOProyectos en GitHub, CI/CD automatizado
Google Artifact RegistryPrivado (GCP)0.5GB gratisMulti-formato (Docker, npm, Maven), análisis vulnerabilidadesEcosistema GCP, proyectos multi-lenguaje
Azure ACRPrivado (Azure)NingunoGeo-replicación, Tasks para builds automáticosAplicaciones Azure, distribución global

Firma y verificación de imágenes

La seguridad de contenedores moderna requiere verificar la integridad y procedencia de las imágenes. Los registros soportan múltiples mecanismos de firma:

# Firma con cosign (recomendado)
cosign sign --key cosign.key myregistry.io/myapp:v1.0.0
 
# Verificación antes del despliegue
cosign verify --key cosign.pub myregistry.io/myapp:v1.0.0
 
# Firma con notación (estándar CNCF)
notation sign myregistry.io/myapp:v1.0.0
 
# Política de admisión en Kubernetes
apiVersion: v1
kind: ConfigMap
metadata:
  name: cosign-policy
data:
  policy.yaml: |
    apiVersion: v1alpha1
    kind: ClusterImagePolicy
    metadata:
      name: require-signature
    spec:
      images:
      - glob: "myregistry.io/**"
      authorities:
      - key:
          data: |
            -----BEGIN PUBLIC KEY-----
            MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...
            -----END PUBLIC KEY-----

Construcción multi-arquitectura

Los registros modernos soportan manifests multi-arquitectura para distribuir la misma imagen a diferentes plataformas (AMD64, ARM64, etc.):

# Dockerfile con soporte multi-arch
FROM --platform=$BUILDPLATFORM node:20-alpine AS builder
ARG TARGETPLATFORM
ARG BUILDPLATFORM
RUN echo "Building on $BUILDPLATFORM for $TARGETPLATFORM"
 
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
 
FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]
# Build y push multi-arch con Docker Buildx
docker buildx create --use
docker buildx build --platform linux/amd64,linux/arm64 \
  -t myregistry.io/myapp:v1.0.0 --push .
 
# El registro almacena un manifest list que referencia
# las imágenes específicas de cada arquitectura
docker manifest inspect myregistry.io/myapp:v1.0.0

Mirroring y distribución

Para organizaciones con múltiples regiones o restricciones de red, los registros ofrecen capacidades de mirroring:

Loading diagram...
# Configuración de pull-through cache en ECR
apiVersion: v1
kind: ConfigMap
metadata:
  name: registry-mirror-config
data:
  config.yaml: |
    mirrors:
      docker.io:
        endpoint:
          - https://123456789.dkr.ecr.us-east-1.amazonaws.com
      registry-1.docker.io:
        endpoint:
          - https://123456789.dkr.ecr.us-east-1.amazonaws.com

Políticas de retención y limpieza

Los registros acumulan imágenes rápidamente. Las políticas de retención automatizan la limpieza:

{
  "rules": [
    {
      "rulePriority": 1,
      "description": "Keep last 10 production images",
      "selection": {
        "tagStatus": "tagged",
        "tagPrefixList": ["v"],
        "countType": "imageCountMoreThan",
        "countNumber": 10
      },
      "action": {
        "type": "expire"
      }
    },
    {
      "rulePriority": 2,
      "description": "Delete untagged images older than 1 day",
      "selection": {
        "tagStatus": "untagged",
        "countType": "sinceImagePushed",
        "countUnit": "days",
        "countNumber": 1
      },
      "action": {
        "type": "expire"
      }
    }
  ]
}

Integración con pipelines de CI/CD

Los registros son componentes críticos en pipelines de CI/CD modernos:

# GitHub Actions con GHCR
name: Build and Push
on:
  push:
    branches: [main]
 
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
      
      - name: Login to GHCR
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      
      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: |
            ghcr.io/${{ github.repository }}:latest
            ghcr.io/${{ github.repository }}:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

¿Por qué importa?

La elección del registro de contenedores afecta directamente la velocidad de despliegue, la seguridad y los costos operacionales. Un registro mal configurado puede convertirse en un cuello de botella que ralentiza todos los despliegues, especialmente en arquitecturas de microservicios con decenas de servicios.

Los equipos de plataforma deben considerar la latencia de red (registros cercanos a los clusters), las capacidades de seguridad (escaneo de vulnerabilidades, firma de imágenes), y la integración con herramientas existentes. Un registro privado es esencial para aplicaciones empresariales, pero añade complejidad operacional que debe gestionarse proactivamente.

La tendencia hacia registros gestionados (ECR, GHCR, Artifact Registry) reduce la carga operacional, pero introduce dependencias de proveedor que deben evaluarse contra los beneficios de disponibilidad y escalabilidad automática.

Referencias

  • Amazon ECR — AWS, 2024. Documentación oficial del registro de contenedores de AWS.
  • Docker Hub | Docker Docs — Docker, 2024. Guía completa del registro de contenedores más utilizado.
  • Working with the Container registry - GitHub Docs — GitHub, 2024. Documentación oficial de GitHub Container Registry.
  • GitHub - opencontainers/distribution-spec: OCI Distribution Specification · GitHub — OCI, 2024. Especificación estándar para APIs de registros de contenedores.
  • Cosign - Sigstore — Sigstore, 2024. Herramienta para firma y verificación de imágenes de contenedores.
  • Artifact Registry documentation | Google Cloud Documentation — Google Cloud, 2024. Registro multi-formato de Google Cloud.
  • Continuous Integration — Martin Fowler, 2006. Artículo fundamental sobre integración continua y artefactos.

Contenido relacionado

  • Docker

    Plataforma de contenedores que empaqueta aplicaciones con todas sus dependencias en unidades portables y consistentes que se ejecutan igual en cualquier entorno.

  • CI/CD

    Continuous Integration y Continuous Delivery/Deployment — prácticas que automatizan la integración de código, testing y entrega a producción. Fundamento de la ingeniería de software moderna.

  • Seguridad de Contenedores

    Prácticas y herramientas para asegurar contenedores en todo su ciclo de vida: construcción de imágenes, runtime, orquestación y cumplimiento.

  • Módulos Terraform para AWS Serverless

    Colección de 13 módulos Terraform publicados en el Terraform Registry para desplegar arquitecturas serverless en AWS, con 12 ejemplos que cubren desde ECS básico hasta CRUD full-stack con DynamoDB y AgentCore con MCP.

  • Kubernetes

    Plataforma de orquestación de contenedores que automatiza el despliegue, escalado y gestión de aplicaciones containerizadas a escala, convirtiéndose en el estándar de facto para cloud native.

Conceptos