S3 als Container-Registry verwenden

 (ochagavia.nl)
1 Punkte von GN⁺ 2024-07-13 | 1 Kommentare | Auf WhatsApp teilen

S3 als Container-Registry verwenden

  • In den letzten 4 Monaten wurde in Zusammenarbeit mit Outerbounds ein benutzerdefinierter Builder für Container-Images entwickelt
  • Dabei wurde entdeckt, dass sich S3 als Container-Registry verwenden lässt
  • Wenn man einen S3-Bucket per HTTP bereitstellt und Images unter einem bestimmten Pfad hochlädt, können sie mit dem Befehl docker pull abgerufen werden

Demo

  • Es wurde ein Container-Image erstellt, das cowsay ausführt, und in einen S3-Bucket hochgeladen
  • Für kostenlosen Egress wurde R2 verwendet
  • R2 und S3 sind API-kompatibel
$ docker run --rm pub-40af5d7df1e0402d9a92b982a6599860.r2.dev/cowsay

Warum S3 verwenden?

  • Traditionell werden DockerHub, GitHub Container Registry, ECR usw. verwendet
  • S3 bietet einen großen Vorteil bei der Upload-Geschwindigkeit
  • Beim Vergleich der Upload-Geschwindigkeit von ECR und S3 war S3 bis zu 8-mal schneller

Warum ist S3 schneller?

  • S3 kann die Chunks einer einzelnen Layer parallel hochladen
  • ECR muss zur Einhaltung der OCI Distribution Spec sequentiell hochladen
  • Da bei ECR kein paralleler Upload möglich ist, kann die verfügbare Bandbreite nicht voll ausgeschöpft werden

S3 ist keine Container-Registry

  • Streng genommen ist S3 keine Container-Registry
  • Der Befehl docker pull lädt Dateien über HTTP-Anfragen herunter
  • Wenn ein S3-Bucket passend konfiguriert ist, kann er als Container-Registry verwendet werden

Hinweise

  • Diese Methode ist stark experimentell
  • Sie bietet nicht die Funktionen bestehender Container-Registries (z. B. Security-Scanning, Zugriffskontrolle usw.)
  • Weitere Untersuchungen sind notwendig

PS. Und der Wal?

  • Das ist ein Scherz mit Verweis auf das Docker-Logo

Zusammenfassung von GN⁺

  • Dieser Artikel erklärt, wie sich S3 als Container-Registry verwenden lässt
  • Die schnelle Upload-Geschwindigkeit von S3 kann genutzt werden
  • Vorsicht ist geboten, da die Funktionen bestehender Container-Registries nicht geboten werden
  • Es ist ein experimenteller, aber interessanter Ansatz
  • Andere Projekte mit ähnlicher Funktionalität sind DockerHub, GitHub Container Registry und ECR

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-07-13
Hacker-News-Kommentare

  • Es gibt die Meinung, dass die OCI-Distribution-Spezifikation statische Dateien unterstützen sollte

    • Dadurch könnte man direkt einen einfachen HTTP-Server oder ein Dateiprotokoll verwenden
    • Alle Metadaten sind bereits im Manifest enthalten
    • Content-Type: octet-stream könnte gut funktionieren

  • Es gibt die Meinung, dass die OCI-Distribution-Spezifikation nicht gut entworfen ist

    • Layer-Pushes müssen sequentiell erfolgen
    • Chunked Uploads funktionieren bei DockerHub und GHCR nicht richtig
    • Das Format des Content-Range-Werts stimmt nicht mit dem RFC7233-Format überein
    • Die Chance zur Standardisierung der Paginierung von Tag-Listen wurde verpasst

  • Es gibt die Information, dass Cloudflare einen Open-Source-Container-Registry-Server auf Basis von R2 veröffentlicht hat

    • Man fragt sich, ob ihn jemand ausprobiert hat

  • Es gibt die Meinung, dass man verstehen möchte, warum Layer-Pushes in der OCI-Spezifikation sequentiell erfolgen müssen

    • Der Inhalt eines einzelnen Layers muss sequentiell gepusht werden
    • Mehrere Layer parallel zu pushen ist möglich

  • Es gibt Meinungen zu den Gründen für die Nutzung von Nexus sowie zu Vor- und Nachteilen

    • Es unterstützt verschiedene Pakete und Repositories
    • Konfiguration und Ressourcenverbrauch sind umständlich
    • Docker-Pull-Anfragen bestehen nur aus einfachen HEAD- und GET-Anfragen
    • Es überrascht, dass es an einfacheren Container-Registries mangelt

  • Es gibt die Information, dass die CNCF-Distribution das Spiegeln einer Registry aus S3 über CloudFront-signierte URLs unterstützt

  • Es gibt die Meinung, dass es schade ist, dass die Kosten von S3 und R2 nicht erwähnt wurden

  • Es gibt die Information, dass ECR das Hochladen von Image-Layern in mehreren Teilen unterstützt

    • Zugehörige APIs:
      • InitiateLayerUpload API: wird beim Start des Uploads jedes Image-Layers aufgerufen
      • UploadLayerPart API: wird beim Upload jedes Layer-Chunks aufgerufen (maximal 20 MB)
      • PutImage API: wird nach dem Layer-Upload beim Push des Image-Manifests aufgerufen
    • Es wirkt seltsam, dass Layer-Chunks per Base64-Encoding hochgeladen werden müssen

  • Es gibt Unzufriedenheit mit Dockers Registry

  • Es gibt die Meinung, dass man den Sinn privater Container-Registries nicht versteht

    • Stattdessen könnte es besser sein, einfach Image-Dateien zu erzeugen und zu verwalten