Wird diese Docker-Anwendung auf der CPU-Architektur Ihres Servers ausgeführt? Eine Kompatibilitäts-Checkliste

Warum die Kompatibilität der CPU-Architektur bei einer Docker-Bereitstellung wichtig ist

Ein Docker-Container ist keine virtuelle Maschine mit einem eigenen, unabhängigen Kernel. Container nutzen gemeinsam den Kernel des Hosts. Deshalb muss der Code in einem Image mit der Host-Umgebung kompatibel sein. Docker beschreibt plattformspezifische Image-Varianten wie linux/amd64 und linux/arm64. Wenn ein Image passende Varianten bereitstellt, kann die Laufzeitumgebung eine davon für den Host auswählen. Siehe die Dokumentation zu Multi-Plattform-Builds von Docker: https://docs.docker.com/build/building/multi-platform/.

Die entscheidende Frage ist nicht nur, ob es für eine Anwendung ein Docker-Image gibt. Es geht darum, ob jedes Image und jede architektursensible Komponente der Bereitstellung die Zielplattform unterstützt und ob die Anwendung dort für den vorgesehenen Einsatzzweck funktioniert.

Eine Abweichung bei der Architektur kann in unterschiedlichen Phasen auffallen: Ein Image ist möglicherweise nicht für die Plattform verfügbar, ein natives ausführbares Programm lässt sich eventuell nicht starten oder eine unterstützende Komponente funktioniert möglicherweise nicht wie erwartet. Dass sich ein Image erfolgreich abrufen lässt, beweist allein noch nicht, dass die Anwendung erfolgreich bereitgestellt werden kann.

• Prüfen Sie die Plattform des Servers, auf dem die Workload tatsächlich ausgeführt wird. Leiten Sie sie nicht aus dem Namen oder der Produktkategorie eines Anbieters ab.
• Überprüfen Sie das Haupt-Image der Anwendung und alle Dienste, von denen sie abhängt.
• Behandeln Sie die Verfügbarkeit im Manifest, den Herstellersupport und erfolgreiche Anwendungstests als voneinander unabhängige Nachweise.

Serverarchitektur und erforderliche Plattformen der Anwendung ermitteln

Fragen Sie zunächst den Serverbetreiber nach der Plattform des konkreten Servers oder der Instanz, die Sie in Betracht ziehen. Wenn Sie Zugriff auf deren Docker Engine haben, führen Sie docker info aus und prüfen Sie im Ergebnis das Feld Architecture. In der Docker-CLI-Referenz wird dieses Feld gezeigt; aarch64 ist dort ein Beispiel: https://docs.docker.com/reference/cli/docker/system/info/.

Notieren Sie neben der CPU-Architektur auch das Betriebssystem. Image-Plattformen werden häufig in einer Form wie linux/arm64 oder linux/amd64 angegeben. OCI-Image-Metadaten können außerdem eine Architekturvariante enthalten. Namen und Varianten sind wichtig, wenn Sie den Host mit einem Image oder einer Supporttabelle des Herstellers abgleichen.

Ermitteln Sie anschließend, welche Plattformen die Anwendung voraussetzt oder unterstützt. Verwenden Sie die Dokumentation für genau das Image und die Version, die Sie bereitstellen möchten. Gehen Sie nicht davon aus, dass der neueste Tag, eine allgemeine Repository-Beschreibung oder ein für eine andere Plattform erstelltes Image Ihre Bereitstellung abbildet.

• Betriebssystem und Architektur des Zielhosts: Halten Sie die vom Betreiber bestätigten Werte fest.
• Anwendungs-Image: Notieren Sie den genauen Image-Verweis sowie die Version oder den Tag.
• Erforderliche Plattform: Halten Sie das dokumentierte Betriebssystem, die Architektur und gegebenenfalls die Variante fest.
• Nachweis: Speichern Sie die relevanten Befehlsausgaben oder den Verweis auf die Dokumentation des Herstellers.

Image-Manifeste und offizielle Dokumentation zu unterstützten Plattformen prüfen

Ein Image-Verweis kann auf einen OCI-Image-Index mit separaten Manifesten für verschiedene Plattformen verweisen. Die Plattformdeskriptoren des Index enthalten Felder wie Betriebssystem und Architektur und möglicherweise auch eine Variante. Siehe die OCI-Spezifikation für Image-Indizes: https://github.com/opencontainers/image-spec/blob/main/image-index.md. Auch die Image-Konfiguration gibt das Betriebssystem und die CPU-Architektur an, für die die Binärdateien erstellt wurden. Dies wird in der OCI-Spezifikation für Image-Konfigurationen beschrieben: https://github.com/opencontainers/image-spec/blob/main/config.md.

Für ein Image in einer Registry dokumentiert Docker den Befehl docker buildx imagetools inspect als Möglichkeit, Image-Details und die für dessen Manifeste aufgeführten Plattformen anzuzeigen: https://docs.docker.com/reference/cli/docker/buildx/imagetools/inspect/. Untersuchen Sie beispielsweise einen bestimmten Verweis mit docker buildx imagetools inspect IMAGE:TAG und ersetzen Sie den Platzhalter durch das Image und den Tag, die Sie verwenden möchten. Vergleichen Sie die aufgeführten Plattformen mit dem Zielserver, statt sich auf die allgemeine Beschreibung des Repositorys zu verlassen.

Prüfen Sie anschließend in der offiziellen Dokumentation des Image-Herausgebers die unterstützten Plattformen, Bereitstellungsanforderungen und etwaige plattformspezifische Einschränkungen. Ein Eintrag im Manifest ist ein hilfreicher Nachweis dafür, dass eine Image-Variante existiert. Für sich genommen garantiert er jedoch nicht, dass alle Funktionen der Anwendung, optionalen Komponenten oder Workloads in der Produktion unterstützt werden.

• Führt der untersuchte Image-Verweis das Betriebssystem und die Architektur des Zielsystems auf?
• Dokumentiert der Hersteller diese Plattform für die Anwendungsversion, die Sie bereitstellen möchten?
• Gibt es Hinweise zu Varianten, erforderlichen Build-Optionen oder ausgeschlossenen Funktionen?
• Beziehen sich Image-Verweis und Dokumentation auf dieselbe Version?

Datenbanken, Plugins, Sidecars und weitere unterstützende Container einbeziehen

Eine geschäftliche Anwendung wird häufig mit mehreren Containern bereitgestellt. Prüfen Sie die Plattformunterstützung für Datenbank, Cache, Warteschlange, Proxy, Worker, Sidecar und alle optionalen Dienste in der Bereitstellungskonfiguration. Ein kompatibles Haupt-Image sagt noch nichts über die Kompatibilität des restlichen Stacks aus.

Untersuchen Sie die tatsächliche Compose-Datei oder die Bereitstellungsanweisungen, einschließlich Images, auf die indirekt über Profile, Overrides oder optionale Funktionen verwiesen wird. Docker Compose definiert pro Dienst ein Attribut platform im Format os[/arch[/variant]]. Es kann beeinflussen, welche Image-Version abgerufen oder welche Plattform für einen Build verwendet wird. Siehe die Docker-Referenz zu Compose-Diensten: https://docs.docker.com/reference/compose-file/services/. Betrachten Sie diese Einstellung als Auswahl- oder Build-Anweisung, nicht als Nachweis dafür, dass der Inhalt des ausgewählten Images kompatibel ist.

Prüfen Sie die Dokumentation des Herstellers für jedes unterstützende Image, insbesondere wenn eine Komponente von einem anderen Projekt oder Anbieter gepflegt wird. Führen Sie eine komponentenweise Übersicht, damit eine Plattformlücke bei einer Abhängigkeit nicht in einer pauschalen Aussage zur Unterstützung der gesamten Anwendung untergeht.

• Listen Sie jeden Dienst in der Bereitstellung auf, einschließlich optionaler und profilspezifischer Dienste.
• Notieren Sie für jeden Dienst den Image-Verweis, die Zielplattform und die Quelle des Supportnachweises.
• Kennzeichnen Sie Dienste mit unbekannter Plattform oder mit Dokumentation, die nicht zur geplanten Version passt.
• Prüfen Sie die platform-Einstellungen in Compose und bestätigen Sie, dass sie zum vorgesehenen Host und Image passen.

Auf architekturspezifische Binärdateien, Treiber und Abhängigkeiten für die Modellbereitstellung achten

Manche Kompatibilitätsbeschränkungen stecken im Image oder gehören zu einer Funktion und sind nicht am allgemeinen Namen der Anwendung zu erkennen. Achten Sie auf mitgelieferte native ausführbare Programme, kompilierte Erweiterungen, Plugins, Kommandozeilenprogramme sowie vom Hersteller bereitgestellte Treiber oder Toolkits. Das Architekturfeld in der OCI-Image-Konfiguration beschreibt die Architektur, für die die Binärdateien des Images erstellt wurden. Es erfasst jedoch nicht alle optionalen Abhängigkeiten oder externen Integrationen.

Lesen Sie in der offiziellen Installations- und Hardwaredokumentation der Anwendung nach, welche Anforderungen für optionale Funktionen gelten. Wenn die Bereitstellung GPU-Unterstützung oder ein anderes Hardware-Toolkit verwendet, prüfen Sie die Plattformunterstützung des jeweiligen Anbieters separat. NVIDIA veröffentlicht beispielsweise eine Supporttabelle für das Container Toolkit nach Linux-Distribution und Architektur: https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/supported-platforms.html. Diese Dokumentation ist unabhängig vom Manifest des Workload-Images.

Prüfen Sie bei KI- oder Modellbereitstellungssoftware die Plattformunterstützung jeder relevanten Ebene: Anwendungs-Image, Laufzeitumgebung für die Modellbereitstellung, Hardware-Toolkit und konkreter Funktionsumfang beziehungsweise Modell-Workflow, den Sie testen möchten. Betrachten Sie einen kompatiblen Container für Benutzeroberfläche oder API nicht als Beweis dafür, dass alle Inferenzpfade unterstützt werden.

• Suchen Sie in der offiziellen Dokumentation nach Begriffen wie Plattform, Architektur, nativ, Binärdatei, Treiber, GPU und Hardwareanforderungen.
• Ermitteln Sie optionale Funktionen, die eigene Binärdateien oder Hardwareabhängigkeiten mitbringen.
• Prüfen Sie jedes Tool und jeden Treiber anhand der jeweiligen Supportdokumentation des Herstellers.
• Kennzeichnen Sie nicht dokumentierte Kombinationen als ungeprüft, statt ihre Funktionsfähigkeit anzunehmen.

Den Unterschied zwischen nativer Ausführung und Emulation verstehen

Eine plattformspezifische Image-Variante, die zum Host passt, unterscheidet sich von der Ausführung eines für eine andere Architektur erstellten Images über eine Emulation. In manchen Umgebungen kann Emulation verfügbar sein. Sie ist jedoch kein gleichwertiger Nachweis für native Unterstützung und sollte nicht als identisches Verhalten vorausgesetzt werden.

Docker dokumentiert die QEMU-Emulation zum Ausführen von Intel-basierten Containern auf Apple-Silicon-Geräten und weist darauf hin, dass dies langsamer sein, mehr Speicher benötigen oder zu Fehlern führen kann. Siehe die Dokumentation zu bekannten Problemen von Docker: https://docs.docker.com/desktop/troubleshoot-and-support/troubleshoot/known-issues/. Das ist ein Grund, den konkreten Host, die Laufzeitumgebung, das Image und die Workload zu bewerten, statt von einem erfolgreichen Test auf einem anderen Rechner zu verallgemeinern.

Wenn Sie eine Emulation in Betracht ziehen, bestätigen Sie, dass die Serverumgebung die erforderliche Konfiguration unterstützt und der Hersteller diese Lösung für Ihren Anwendungsfall freigibt. Testen Sie die für Sie relevanten Workloads und dokumentieren Sie die Ausführung als emuliert, nicht als nativ.

• Native Übereinstimmung: Host und Image zielen auf dieselbe Plattform.
• Emulierte Ausführung: Das Image zielt auf eine andere Architektur und nutzt einen Emulationsmechanismus.
• Unbekannt: Die Bereitstellung läuft, aber Ausführungsmodus oder Herstellersupport wurden nicht bestätigt.
• Verwenden Sie eine platform-Einstellung in Compose nicht allein als Nachweis dafür, dass Emulation verfügbar oder die Workload unterstützt ist.

Eine repräsentative Bereitstellung testen und den Erfolg definieren

Führen Sie nach der Prüfung von Dokumentation und Manifesten einen Test in einer Umgebung durch, die der vorgesehenen Serverplattform so weit wie möglich entspricht. Verwenden Sie dieselben Image-Verweise, die Compose-Konfiguration und die wichtigen unterstützenden Dienste, die auch für die Bereitstellung geplant sind. Ein Test auf einer anderen Architektur kann nützliche Informationen liefern, überprüft die Zielplattform aber nicht.

Docker Compose unterstützt docker compose up --wait. Dieser Befehl wartet, bis Dienste laufen oder den Status healthy erreicht haben: https://docs.docker.com/reference/cli/docker/compose/up/. Ein Health-Status ist eine hilfreiche Prüfung, aber kein vollständiger Abnahmetest. Bestätigen Sie, dass die Anwendung startet, ihre Abhängigkeiten erreicht und die für Ihren Anwendungsfall wesentlichen Aufgaben funktionieren. Wenn die Compose-Konfiguration Healthchecks definiert, prüfen Sie, was diese tatsächlich testen.

Legen Sie vor dem Test fest, was als Erfolg gilt. Berücksichtigen Sie die Workflows, die Ihr Team benötigt, nicht nur den Containerstart. Legen Sie bei einer KI-Anwendung beispielsweise fest, ob die Benutzeroberfläche starten, ein konfigurierter Modelldienst antworten oder ein bestimmter Inferenz-Workflow abgeschlossen werden muss. Testen Sie nur die Anforderungen, die für Ihre Bereitstellung gelten.

• Starten Sie den repräsentativen Stack und erfassen Sie Startfehler und Dienststatus.
• Prüfen Sie, ob erforderliche Dienste den erwarteten Status „running“ oder „healthy“ erreichen.
• Führen Sie die wesentlichen Workflows und Integrationen der Anwendung aus.
• Dokumentieren Sie Hostplattform, Image-Verweise, Konfiguration, Testdatum und beobachtete Ergebnisse.
• Wiederholen Sie einen fehlgeschlagenen oder nicht eindeutigen Test, nachdem Sie eine bestimmte Variable geändert haben. So lässt sich die Ursache leichter eingrenzen.

Lücken, Ausweichmöglichkeiten und Auslöser für eine erneute Prüfung dokumentieren

Wenn Nachweise unvollständig sind, halten Sie die Unsicherheit ausdrücklich fest. Unterscheiden Sie zwischen einer bestätigten Plattformübereinstimmung, einer vom Hersteller dokumentierten, aber nicht getesteten Konfiguration, einer getesteten Konfiguration und einer Konfiguration, die auf Emulation beruht. So erhalten technische und kaufmännische Entscheidungsträger eine bessere Grundlage für den Vergleich von Hosting-Umgebungen.

Notieren Sie für jeden offenen Punkt dessen Auswirkungen, wer ihn prüfen kann und den nächsten Schritt: eine Bestätigung vom Anwendungshersteller oder Serverbetreiber einholen, auf der Zielplattform testen, ein dokumentiertes alternatives Image auswählen oder eine Serverplattform wählen, die den Anforderungen der Anwendung entspricht. Gibt es für eine erforderliche Workload keinen unterstützten Weg, behandeln Sie eine Behelfslösung nicht als bestätigte Kompatibilitätslösung.

Prüfen Sie die Nachweise erneut, wenn sich ein wesentlicher Teil der Bereitstellung ändert. Sinnvolle Auslöser sind etwa der Wechsel der Anwendungsversion oder des Image-Verweises, der Austausch eines unterstützenden Dienstes, eine Änderung der Zielserverplattform, die Aktivierung einer optionalen hardwareabhängigen Funktion oder eine Überarbeitung der Bereitstellungskonfiguration.

Managed Hosting kann den Infrastrukturaufwand verringern, nimmt Ihnen aber nicht die Prüfung der Anwendungsanforderungen oder Entscheidungen zu Daten, Zugriff und Governance ab. Airbip führt Anwendungsinstanzen als Docker-Workloads auf Cloud-Servern aus. Wenn Sie eine verwaltete Bereitstellung bewerten, bestätigen Sie die Zielplattform und die Kompatibilität des konkreten Anwendungsstacks, statt sie aus dem Hosting-Modell abzuleiten.

• Komponente und Image-Verweis
• Erforderliche und beobachtete Plattform
• Quelle des Nachweises und Datum der Prüfung
• Ausführungsmodus: nativ, emuliert oder unbekannt
• Testergebnis und noch offene Einschränkungen
• Verantwortliche Person, nächster Schritt und Auslöser für eine erneute Prüfung