1 points par GN⁺ 2024-07-13 | 1 commentaires | Partager sur WhatsApp

Utiliser S3 comme registre de conteneurs

  • Au cours des 4 derniers mois, l’auteur a collaboré avec Outerbounds pour développer un constructeur d’images de conteneurs personnalisé
  • Il a découvert qu’il était possible d’utiliser S3 comme registre de conteneurs
  • En exposant un bucket S3 en HTTP et en téléversant une image vers un chemin précis, il est possible de récupérer l’image avec la commande docker pull

Démo

  • Une image de conteneur exécutant cowsay a été créée puis téléversée dans un bucket S3
  • R2 est utilisé pour fournir un egress gratuit
  • R2 et S3 sont compatibles au niveau de l’API
$ docker run --rm pub-40af5d7df1e0402d9a92b982a6599860.r2.dev/cowsay

Pourquoi utiliser S3 ?

  • Traditionnellement, on utilise DockerHub, GitHub Container Registry, ECR, etc.
  • S3 offre un avantage important en matière de vitesse d’upload
  • La comparaison des vitesses d’upload entre ECR et S3 montre que S3 peut être jusqu’à 8 fois plus rapide

Pourquoi S3 est plus rapide

  • S3 permet de téléverser en parallèle les chunks d’une même couche
  • ECR, en respectant l’OCI Distribution Spec, doit effectuer les uploads de manière séquentielle
  • Comme ECR ne permet pas l’upload parallèle, il n’exploite pas pleinement la bande passante disponible

S3 n’est pas un registre de conteneurs

  • À proprement parler, S3 n’est pas un registre de conteneurs
  • La commande docker pull télécharge des fichiers via des requêtes HTTP
  • En configurant correctement un bucket S3, il est possible de l’utiliser comme registre de conteneurs

Points d’attention

  • Cette méthode est très expérimentale
  • Elle ne fournit pas les fonctionnalités des registres de conteneurs classiques (par ex. analyse de sécurité, contrôle d’accès, etc.)
  • Des recherches supplémentaires sont nécessaires

PS. Et la baleine ?

  • C’est une plaisanterie qui renvoie au logo de Docker

Le résumé de GN⁺

  • Cet article explique comment utiliser S3 comme registre de conteneurs
  • Il permet de tirer parti de la vitesse d’upload élevée de S3
  • Comme il ne fournit pas les fonctionnalités des registres de conteneurs classiques, il faut l’utiliser avec prudence
  • L’approche est expérimentale, mais intéressante
  • Parmi les autres projets offrant des fonctions similaires, on trouve DockerHub, GitHub Container Registry et ECR

1 commentaires

 
GN⁺ 2024-07-13
Avis Hacker News
  • Certains estiment qu’il serait souhaitable que la spécification OCI Distribution prenne en charge les fichiers statiques

    • Cela permettrait d’utiliser directement un simple serveur HTTP ou un protocole de fichiers
    • Toutes les métadonnées sont déjà incluses dans le manifeste
    • Content-Type: octet-stream pourrait très bien fonctionner
  • Certains estiment que la spécification OCI Distribution est mal conçue

    • Le push des couches doit se faire de manière séquentielle
    • L’upload par chunks ne fonctionne pas correctement sur DockerHub et GHCR
    • Le format de la valeur Content-Range ne correspond pas au format RFC7233
    • L’occasion de standardiser la pagination de la liste des tags a été manquée
  • Il est mentionné que Cloudflare a open source un serveur de registre de conteneurs utilisant R2

    • La personne se demande si quelqu’un l’a déjà utilisé
  • Certains veulent savoir pourquoi, dans la spécification OCI, le push des couches doit être séquentiel

    • Le contenu d’une couche unique doit être poussé séquentiellement
    • Il est possible de pousser plusieurs couches en parallèle
  • Avis sur les raisons d’utiliser Nexus ainsi que sur ses avantages et inconvénients

    • Il prend en charge divers packages et dépôts
    • Sa configuration et sa consommation de ressources sont contraignantes
    • Les requêtes Docker pull se résument à de simples requêtes HEAD et GET
    • Cela surprend qu’il existe si peu de registres de conteneurs plus simples
  • Il est indiqué que Distribution de la CNCF prend en charge la sauvegarde du registre depuis S3 via des URL signées Cloudfront

  • Certains regrettent qu’il n’y ait aucune mention des coûts de S3 et de R2

  • Il est indiqué qu’ECR prend en charge l’upload des couches d’image en plusieurs parties

    • API associées :
      • API InitiateLayerUpload : appelée au début de l’upload de chaque couche d’image
      • API UploadLayerPart : appelée lors de l’upload de chaque chunk de couche (maximum 20 MB)
      • API PutImage : appelée pour pousser le manifeste d’image après l’upload des couches
    • Il est étrange qu’il faille uploader les chunks de couche avec un encodage base64
  • Il y a des critiques à propos du Registry de Docker

  • Certains disent ne pas comprendre l’intérêt d’un registre de conteneurs privé

    • Il pourrait être préférable de simplement créer et gérer des fichiers image