Repositorios para almacenar, versionar y distribuir imágenes de contenedores, desde registros públicos como Docker Hub hasta registros privados como ECR.
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.
| Registro | Tipo | Límites gratuitos | Características clave | Casos de uso |
|---|---|---|---|---|
| Docker Hub | Público/Privado | 1 repo privado, 200 pulls/6h | Imágenes oficiales, mayor ecosistema | Proyectos open source, prototipado |
| Amazon ECR | Privado (AWS) | 500MB/mes gratis | Integración nativa ECS/EKS, escaneo vulnerabilidades | Aplicaciones AWS, entornos empresariales |
| GitHub GHCR | Público/Privado | 500MB gratis | Integración GitHub Actions, autenticación SSO | Proyectos en GitHub, CI/CD automatizado |
| Google Artifact Registry | Privado (GCP) | 0.5GB gratis | Multi-formato (Docker, npm, Maven), análisis vulnerabilidades | Ecosistema GCP, proyectos multi-lenguaje |
| Azure ACR | Privado (Azure) | Ninguno | Geo-replicación, Tasks para builds automáticos | Aplicaciones Azure, distribución global |
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-----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.0Para organizaciones con múltiples regiones o restricciones de red, los registros ofrecen capacidades de mirroring:
# 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.comLos 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"
}
}
]
}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=maxLa 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.
Plataforma de contenedores que empaqueta aplicaciones con todas sus dependencias en unidades portables y consistentes que se ejecutan igual en cualquier entorno.
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.
Prácticas y herramientas para asegurar contenedores en todo su ciclo de vida: construcción de imágenes, runtime, orquestación y cumplimiento.
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.
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.