Usar S3 como registro de contenedores

 (ochagavia.nl)
1 puntos por GN⁺ 2024-07-13 | 1 comentarios | Compartir por WhatsApp

Cómo usar S3 como registro de contenedores

  • Durante los últimos 4 meses, se ha estado desarrollando un constructor de imágenes de contenedores personalizado en colaboración con Outerbounds
  • Se descubrió que S3 puede usarse como registro de contenedores
  • Si expones un bucket de S3 por HTTP y subes imágenes a una ruta específica, puedes obtener la imagen con el comando docker pull

Demo

  • Se creó una imagen de contenedor que ejecuta cowsay y se subió a un bucket de S3
  • Se usa R2 para ofrecer egreso gratuito
  • R2 y S3 son compatibles a nivel de API
$ docker run --rm pub-40af5d7df1e0402d9a92b982a6599860.r2.dev/cowsay

¿Por qué usar S3?

  • Tradicionalmente se usan DockerHub, GitHub Container Registry, ECR, etc.
  • S3 ofrece una gran ventaja en velocidad de subida
  • Al comparar la velocidad de subida entre ECR y S3, S3 fue hasta 8 veces más rápido

Por qué S3 es más rápido

  • S3 permite subir en paralelo los chunks de una sola capa
  • ECR, al cumplir con la OCI Distribution Spec, debe subir en forma secuencial
  • Como no puede hacer subidas en paralelo, ECR no aprovecha por completo el ancho de banda

S3 no es un registro de contenedores

  • Estrictamente hablando, S3 no es un registro de contenedores
  • El comando docker pull descarga archivos mediante solicitudes HTTP
  • Si configuras adecuadamente un bucket de S3, puede usarse como registro de contenedores

Precauciones

  • Este método es muy experimental
  • No ofrece las funciones de los registros de contenedores existentes (por ejemplo: escaneo de seguridad, control de acceso, etc.)
  • Hace falta más investigación

P. D. ¿Y la ballena?

  • Es una broma que hace referencia al logo de Docker

Resumen de GN⁺

  • Este artículo explica cómo usar S3 como registro de contenedores
  • Se puede aprovechar la alta velocidad de subida de S3
  • Hay que tener cuidado porque no ofrece las funciones de los registros de contenedores existentes
  • Es un enfoque experimental, pero interesante
  • Otros proyectos que ofrecen funciones similares incluyen DockerHub, GitHub Container Registry y ECR

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-07-13
Comentarios en Hacker News

  • Hay una opinión de que sería bueno que la especificación de OCI Distribution admitiera archivos estáticos

    • Permitirá usar directamente un servidor HTTP simple o un protocolo de archivos
    • Todos los metadatos ya están incluidos en el manifiesto
    • Content-Type: octet-stream podría funcionar bien

  • Hay una opinión de que la especificación de OCI Distribution no está bien diseñada

    • Los pushes de capas deben realizarse de forma secuencial
    • Las subidas por chunks no funcionan correctamente en DockerHub y GHCR
    • El formato del valor de Content-Range no coincide con el formato de RFC7233
    • Se perdió la oportunidad de estandarizar la paginación de la lista de tags

  • Se menciona que Cloudflare liberó como código abierto un servidor de registro de contenedores que usa R2

    • Se pregunta si alguien lo ha probado

  • Hay una opinión de que quisiera saber por qué en la especificación de OCI los pushes de capas deben hacerse de forma secuencial

    • El contenido de una sola capa debe subirse secuencialmente
    • Sí es posible subir varias capas en paralelo

  • Hay opiniones sobre las razones para usar Nexus y sus ventajas y desventajas

    • Soporta varios paquetes y repositorios
    • La configuración y el uso de recursos son engorrosos
    • Las solicitudes de Docker pull consisten simplemente en peticiones HEAD y GET
    • Sorprende que falten registros de contenedores más simples

  • Se menciona que Distribution de CNCF soporta respaldar el registro desde S3 mediante URLs firmadas de Cloudfront

  • Hay una opinión de que es una lástima que no se mencione el costo de S3 y R2

  • Se menciona que ECR soporta subir capas de imágenes en varias partes

    • APIs relacionadas:
      • API InitiateLayerUpload: se llama al iniciar la subida de cada capa de imagen
      • API UploadLayerPart: se llama al subir cada chunk de capa (máximo 20 MB)
      • API PutImage: se llama al hacer push del manifiesto de la imagen después de subir la capa
    • Parece extraño que los chunks de capa deban subirse con codificación base64

  • Hay quejas sobre Docker Registry

  • Hay una opinión de que no se entiende la razón de existir de un registro de contenedores personal

    • Podría ser mejor simplemente generar y gestionar archivos de imagen