Odoo 20 wird in Docker Official Images aufgenommen
Odoo 20 ist über das Docker Official Images-Programm verfügbar. Docker Hub weist den Container als Docker Official Image aus, das von Odoo gepflegt wird. Das Docker-Repository von Odoo beschreibt sich selbst als Quellrepository für das offizielle Image und enthält ein eigenes Verzeichnis 20.0. Diese Einträge bieten Organisationen, die Odoo 20 bereitstellen oder testen, eine definierte Upstream-Containerquelle. (Odoo; Odoo Docker)
Die offiziellen Image-Datensätze ordnen Odoo 20 derzeit vier Tags zu: 20.0-20261015, 20.0, 20 und latest. Das Image ist außerdem für amd64, arm64v8 und ppc64le gelistet. Zusammen legen der Docker-Hub-Eintrag, der offizielle Image-Datensatz und das Odoo-Quellrepository die verfügbare Imagequelle, die aktuellen Tag-Optionen und die angegebene Prozessorarchitektur-Abdeckung fest. (Docker Library Official Images Blob; Odoo; Odoo Docker)
Zu Prüfzwecken können Teams den Docker-Hub-Eintrag mit dem offiziellen Image-Datensatz und dem Odoo-Quellrepository abgleichen. Die drei veröffentlichten Quellen beschreiben sich ergänzende Teile derselben Image-Verfügbarkeit, den Status als offizielles Image, die aktuellen Tags und Architekturen sowie das Vorhandensein des Verzeichnisses 20.0 im Quellrepository. (Docker Library Official Images Blob; Odoo; Odoo Docker)
Die verfügbaren Tags verstehen
Der datierte Tag 20.0-20261015 ist die spezifischste Kennung in der aktuellen Liste. Die Tags 20.0 und 20 bezeichnen die Odoo-20-Linie allgemeiner, während latest derzeit auf das Odoo-20-Image verweist. Obwohl diese Tags aktuell derselben Hauptversion zugeordnet sind, legen die veröffentlichten Datensätze nicht fest, wie die breiteren Tags künftig zugeordnet werden. (Docker Library Official Images Blob; Odoo)
Teams sollten daher den in Entwicklung, Test und Produktion verwendeten exakten Image-Tag dokumentieren und sich nicht nur auf einen Odoo-20-Container beziehen. Die bereitgestellten Quellen bestätigen die verfügbaren Tag-Namen, schreiben aber keine Tagging-Richtlinie vor. Die Infrastrukturdokumentation sollte den ausgewählten Tag benennen und vor dem Abruf oder der Aktualisierung eines Images bestätigen, dass der Registry-Eintrag weiterhin auf die beabsichtigte Odoo-Version verweist. (Docker Library Official Images Blob; Odoo)
Unterstützung für drei Prozessorarchitekturen
Das Odoo-20-Image ist für amd64, arm64v8 und ppc64le gelistet. Organisationen, die auf unterschiedlichen Prozessorplattformen arbeiten, können daher für jede dieser drei Architekturen ein offizielles Image auswählen. Die Architektur sollte weiterhin als explizite Bereitstellungsanforderung behandelt werden und nicht allein aus der Odoo-Version oder dem Tag abgeleitet werden. (Docker Library Official Images Blob; Odoo)
Vor der Standardisierung auf das Image sollten Administratoren die Prozessorarchitektur jedes Zielhosts überprüfen und bestätigen, dass der gewählte Odoo-Tag die erforderliche Architektur enthält. Die Registry-Einträge gelten für das Odoo-Image selbst. Sie legen keine Kompatibilität für benutzerdefinierte Module, Integrationen oder andere unterstützende Software fest, die separat geprüft werden muss. (Docker Library Official Images Blob; Odoo)
PostgreSQL bleibt eine separate Anforderung
Das dokumentierte Container-Setup erfordert PostgreSQL. Das Odoo-Image ist daher nur eine Komponente der Bereitstellung und keine vollständige eigenständige Umgebung. Ein Bereitstellungsdesign muss den Datenbankdienst, seine Verbindung zu Odoo und den angemessenen Umgang mit den Daten der Datenbank enthalten. Der offizielle Eintrag bestätigt die PostgreSQL-Anforderung, ersetzt jedoch nicht die Datenbankkonfiguration oder die Betriebssteuerung eines Unternehmens. (Odoo)
Organisationen, die ein provisorisches Container-Setup ersetzen, sollten ihre bestehende PostgreSQL-Konfiguration mit dem dokumentierten Setup für das offizielle Image vergleichen. Die Übernahme des Odoo-Anwendungsimages ersetzt oder konfiguriert die Datenbankkomponente nicht automatisch neu. Bestehende Umgebungsvariablen, Netzwerkkonfigurationen und Bereitstellungsdefinitionen sollten vor der Wiederverwendung anhand der offiziellen Dokumentation geprüft werden. (Odoo)
Persistierung des Odoo-Filestores
Docker Hub empfiehlt, den Odoo-Filestore zu persistieren, indem ein Volume unter /var/lib/odoo eingebunden wird. Dadurch werden persistente Dateien vom Lebenszyklus des Anwendungscontainers getrennt. Bereitstellungsdefinitionen sollten den dokumentierten Mount-Pfad und ein Speicher-Setup enthalten, das den Filestore erhält, wenn Container ersetzt oder aktualisiert werden. (Odoo)
Auch beim Ersetzen eines benutzerdefinierten Images oder eines früheren Bereitstellungsrezepts erfordert der Mount-Pfad Aufmerksamkeit. Ein bestehendes Setup verwendet möglicherweise eine bestimmte Volume-Definition oder einen bestimmten Datenpfad. Administratoren sollten diese Konfiguration mit dem dokumentierten Mount /var/lib/odoo vergleichen und bestätigen, dass der vorgesehene Filestore dem neuen Container zur Verfügung steht. Die offizielle Anleitung nennt den empfohlenen Pfad, bietet aber kein organisationsspezifisches Verfahren zur Datenübertragung. (Odoo)
Grenzen der veröffentlichten Informationen
Die Veröffentlichung als Docker Official Image bestätigt die Image-Quelle, Tags, aufgeführten Architekturen sowie grundlegende Hinweise zu Datenbank und Speicher. Sie begründet keine Anwendungs-Kompatibilität, keine Bereitschaft für benutzerdefinierte Module, keine Integrations-Kompatibilität, keine Migrationsverfahren und keine für die Organisation erforderliche Produktionskonfiguration. Der datierte Tag sollte ohne zusätzliche Dokumentation auch nicht als Nachweis eines separaten Veröffentlichungsdatums oder Support-Meilensteins verstanden werden. (Docker Library Official Images Blob; Odoo; Odoo Docker)
Teams, die das Image bewerten, sollten die bestätigte Container-Veröffentlichung von einer weitergehenden Entscheidung zur Einführung von Odoo 20 unterscheiden. Tests sollten ein bewusst ausgewähltes Tag in einer Nicht-Produktionsumgebung verwenden und Prozessorarchitektur, PostgreSQL-Konfiguration und Filestore-Mount dokumentieren. Schlussfolgerungen zu benutzerdefiniertem Code, externen Integrationen oder dem Zeitpunkt der Migration erfordern Nachweise, die über die offiziellen Image-Datensätze hinausgehen. (Docker Library Official Images Blob; Odoo; Odoo Docker)
Prüfungen vor der Einführung
Vor der Freigabe des Images sollten Teams die aktuelle Tag-Zuordnung in der offiziellen Registry prüfen, die erforderliche Prozessorarchitektur auswählen und bestätigen, dass die Bereitstellungsdateien auf das vorgesehene Image verweisen. Das Design sollte PostgreSQL enthalten und den Odoo-Filestore über ein unter /var/lib/odoo eingehängtes Volume persistieren. Die während des Tests verwendete exakte Image-Referenz sollte in den Bereitstellungsunterlagen aufbewahrt werden. (Docker Library Official Images Blob; Odoo)
Diese Prüfungen sollten jedes bestätigte Element der Veröffentlichung separat abdecken. Das ausgewählte Tag kann mit dem Registry-Eintrag abgeglichen werden, die Verfügbarkeit der Architektur kann für den Zielhost bestätigt werden, und die Bereitstellungsdefinition kann sowohl PostgreSQL als auch den Volume-Mount /var/lib/odoo enthalten. So bleibt die Bewertung an den für das offizielle Image dokumentierten Informationen ausgerichtet. (Docker Library Official Images Blob; Odoo)
Das Odoo-Docker-Quell-Repository kann auch bei der Bewertung der Struktur des 20.0-Images herangezogen werden. Die Freigabe für die Produktion sollte weiterhin von den eigenen Tests der Organisation zu Migrationen, Modulen, Integrationen und Betriebsverfahren abhängen. Die bereitgestellten Quellen belegen, dass das offizielle Odoo-20-Image existiert, und dokumentieren seine aktuellen Bezeichner, die Architekturabdeckung, die Datenbankabhängigkeit und den empfohlenen Filestore-Mount. (Odoo Docker; Docker Library Official Images Blob; Odoo)