Babiel Tech Blog

Wir benutzen Renovate um alle Stellen, an denen wir Container-Images verwenden (z.B. Kubernetes-Manifeste, Puppet-Code und Gitlab-Pipelines), aktuell zu halten. Renovate sammelt Image-Referenzen aus allen unseren Repos, prüft dann die entsprechende Container-Registry auf neue Versionen der jeweiligen Images und ändert die Angabe im Repo.

no matching manifest for linux/amd64

Dabei haben wir eine sehr seltsame Feststellung gemacht. Renovate hat z.B. diese Änderung gemacht:

Aber bei der Ausführung gab es einen Fehler:

ERROR: Job failed: failed to pull image "docker:27.1.0-dind@sha256:eb37f58646a901dc7727cf448cae36daaefaba79de33b5058dab79aa4c04aefb" with specified policies [if-not-present]: no matching manifest for linux/amd64 in the manifest list entries (manager.go:250:0s)

OK, es ist kein Image für linux/amd64 mehr enthalten? Wir haben ja gehört, dass ARM populärer wird für Server, aber dass Docker plötzlich ihre Images nicht mehr für AMD64 anbietet, wäre dann doch eine Überraschung. Allerdings: linux/arm64 wird auch nicht unterstützt:

docker: no matching manifest for linux/arm64/v8 in the manifest list entries.

Es wurde noch seltsamer: Der Digest des Image, eb37f58646a901dc7727cf448cae36daaefaba79de33b5058dab79aa4c04aefb, tauchte auch bei anderen Image-Versionen und völlig anderen Images auf:

• docker:27.1.1
• docker:27.1.1-dind
• wordpress:6.6.1
• rabbitmq:3.13.1-management

Was war hier los?

Aufbau von Multi-Arch-Images

Es ist wichtig zu verstehen, wie sog. Multi-Arch-Images bei Docker funktionieren: sie sind einfach nur eine Liste der konkreten Images für die verschiedenen Architekturen. Mit dem Tool crane können wir das abfragen für unser problematisches Image:

$ crane manifest docker:27.1.0-dind@sha256:eb37f58646a901dc7727cf448cae36daaefaba79de33b5058dab79aa4c04aefb | jq '[.manifests[].platform]' 

[]

OK, es wird einfach gar nichts unterstützt?! Zum Vergleich ein funktionierendes Image:

$ crane manifest docker:27.0.3-dind@sha256:75f620cbf8e87543ec1fb0bf98fa2cfde8f684308dafb6c50cc75f3a235fa1fc | jq '[.manifests[].platform]'

[
  {
    "architecture": "amd64",
    "os": "linux"
  },
[…]
  {
    "architecture": "arm64",
    "os": "linux",
    "variant": "v8"
  },
[…]
]

D.h. unser Verständnis des Formats ist richtig – im Manifests sollten die Architekturen aufgelistet sein.

Die Funktionsweise der Multi-Arch-Images erklärt auch, wieso wir den Digest an mehreren Stellen gesehen haben: der Digest ist nur der SHA256-Hash eines leeren Multi-Arch-Image, komplett unabhängig vom Image-Namen/Tag:

$ crane manifest docker:27.1.0-dind@sha256:eb37f58646a901dc7727cf448cae36daaefaba79de33b5058dab79aa4c04aefb | sha256sum

eb37f58646a901dc7727cf448cae36daaefaba79de33b5058dab79aa4c04aefb  -

$ crane manifest rabbitmq:3.13.1-management@sha256:eb37f58646a901dc7727cf448cae36daaefaba79de33b5058dab79aa4c04aefb | sha256sum

eb37f58646a901dc7727cf448cae36daaefaba79de33b5058dab79aa4c04aefb  -

Aber wieso veröffentlicht Docker Inc leere Images?

Unsere Recherche führte uns zu verwandten Problemen — Fälle, wo neue Image-Versionen nicht für alle Architekturen verfügbar waren. Wir selbst hatten schon mal das Problem, dass bei einem Update aus einem amd64-Image ein i386-Image wurde. Wie kommt das?

Der Grund ist, dass Docker (die Firma) neue Images nicht gemeinsam für alle Architekturen pusht, sondern dass die Liste schrittweise auf dem Docker Hub aufgebaut wird. Als erstes pushen sie eine leere Liste, und diese leere Liste wird auch bereits getaggt, so dass Renovate sie findet.

Erst dann laufen die Builds für die verschiedenen Architekturen, wodurch die Liste jeweils erweitert wird (und es jedes Mal einen neuen Digest gibt). Je nachdem in welcher Reihenfolge die Builds fertig werden, und wann man das Image abruft, bekommt man andere Architekturen. amd64-Maschinen können auch i386-Images ausführen – d.h. wenn man pullt, wenn es i386 schon gibt, aber noch nicht amd64, dann bekommt man die i386-Variante.

Als Workaround haben wir Renovate konfiguriert, dass es für Docker Hub einige Stunden wartet, bevor es ein neues Image verwendet:

packageRules: [
        {
            matchDatasources: ["docker"],
            minimumReleaseAge: "4 hours",

            // nur Docker Hub (Images ohne Punkt = Images ohne Hostname)
            // wobei aktuell sowieso nur Docker Hub Release-Timestamps liefert.
            excludePackagePatterns: ["\\."],
        },
]

Eine Garantie ist das leider auch nicht — es gibt keine Möglichkeit zu erkennen, dass ein Multi-Arch-Image vollständig gepusht wurde. Alternativ könnte Renovate ein Feature bekommen, wo man seine verwendeten Architekturen konfiguriert, und es dann nur Images berücksichtigt, die diese Architekturen beinhalten. Aber die saubere Lösung wäre, dass Docker Inc ihre Images atomic updatet – d.h. alle Architekturen baut, und erst dann das Gesamtergebnis taggt. Wir hatten dieses Problem bisher mit keinen Images anderer Quellen oder auf anderen Registries.

Wenn diese Analyse dein Interesse geweckt hat, interessieren dich vielleicht auch unsere Stellenangebote. 😉

Wir hatten ein seltsames Problem in einem unserer MySQL-Cluster: Die primäre Node konnte keine neuen Verbindungen mehr annehmen. Die Verbindungen wurden nicht abgelehnt, aber sie wurden auch nicht vollständig aufgebaut.

Ein Restart von mysqld hat das Problem gelöst – aber wir haben uns gefragt, was da passiert ist. Daher war eine der Maßnahmen im Post-Mortem, dass wir für die Zukunft dokumentieren, wie man Stacktrace aller MySQL-Threads dumpen kann.

Als das Problem kurz später noch mal auftrat, waren wir vorbereitet: Wir haben einen Coredump erstellt und uns dann mit gdb die Threads angesehen:

„MySQL-Deadlock finden — Flamegraph ohne Profiling“ weiterlesen

In Kubernetes ermöglichen Persistent Volumes (PVs) den Betrieb von Workloads mit persistentem State. Der Inhalt dieser Volumes existiert unabhängig von der Lebensdauer der Pods, die sie verwenden.

Es gibt viele verschiedene Implementierungen/Provider für PVs. Wenn man Kubernetes bei einem Cloud-Anbieter betreibt, kann man deren Blockdevice- oder Netzwerkdateisystem-Service verwenden, z.B. Elastic Block Store (EBS) bei AWS. 

Auch in einer on-prem-Umgebung wie unserer gibt es Möglichkeiten: die meisten unserer Persistent Volumes liegen auf NetApps. Mit dem offiziellen NetApp-Provisioner Trident werden diese bei Bedarf automatisch angelegt.

In manchen Fällen möchte man aber nicht Volumes per Netzwerk einbinden, sondern diese direkt auf der Node haben, d.h. Local Storage nutzen. Das kann z.B. schneller oder kostengünstiger sein, und hat weniger Abhängigkeiten. Es passt insbesondere dann, wenn die Redundanz der Daten auf Anwendungsebene sichergestellt ist, so dass ein Verlust eines einzelnen PVs keinen Datenverlust bedeutet.

Pods verwenden die PVs nicht direkt, sondern sie referenzieren einen Persistent Volume Claim (PVC). Ein PVC ist ein „Wunsch“ nach einem Volume einer bestimmter Art und Größe. Eine Controller-Loop in Kubernetes sorgt dafür, dass ein PVC mit einem passenden PV verknüpft wird. Erst dann kann das PVC von Pods verwendet werden.

Für die meisten Arten von Volumes gibt es dynamisches Provisioning: wenn jemand ein PVC erstellt, wird automatisch vom Hersteller-spezifischen Provisioner (wie NetApp Trident) ein passendes PV erstellt. Da das neue PV genau auf das PVC passt, werden diese dann von Kubernetes verknüpft. 

Bei den local Volumes gibt es stattdessen ein statisches Provisioning: der local-static-provisioner scannt nur auf der jeweiligen Node, wo er läuft, nach schon bestehenden Mountpoints oder Blockdevices, und erstellt dafür die PV-Objekte. Wenn man also ein PVC anlegt, und es gar kein passendes PV gibt, dann wird das PVC pending bleiben, bis man selbst ein Volume erstellt.

„Kubernetes Local Persistent Volumes mit virtio-Disks“ weiterlesen