Odoo 20 trafia do Docker Official Images
Odoo 20 jest dostępny w ramach programu Docker Official Images. Docker Hub identyfikuje ten kontener jako Docker Official Image utrzymywany przez Odoo. Repozytorium Docker Odoo opisuje się jako repozytorium źródłowe oficjalnego obrazu i zawiera dedykowany katalog 20.0. Te wpisy zapewniają zdefiniowane źródło kontenera upstream dla organizacji wdrażających lub testujących Odoo 20. (Odoo; Odoo Docker)
Aktualne rekordy oficjalnego obrazu przypisują Odoo 20 cztery tagi: 20.0-20261015, 20.0, 20 oraz latest. Obraz jest również dostępny dla amd64, arm64v8 i ppc64le. Łącznie wpis w Docker Hub, rekord oficjalnego obrazu i repozytorium źródłowe Odoo określają dostępne źródło obrazu, aktualne wybory tagów i deklarowany zakres obsługiwanych architektur procesora. (Docker Library Official Images Blob; Odoo; Odoo Docker)
Na potrzeby weryfikacji zespoły mogą porównać wpis w Docker Hub z rekordem oficjalnego obrazu i repozytorium źródłowym Odoo. Trzy opublikowane lokalizacje opisują uzupełniające się części tej samej dostępności obrazu: jego status jako oficjalnego obrazu, aktualne tagi i architektury oraz obecność katalogu 20.0 w repozytorium źródłowym. (Docker Library Official Images Blob; Odoo; Odoo Docker)
Zrozumienie dostępnych tagów
Tag datowany 20.0-20261015 jest najbardziej szczegółowym identyfikatorem w bieżącym zestawieniu. Tagi 20.0 i 20 oznaczają linię Odoo 20 w szerszym ujęciu, natomiast latest obecnie wskazuje na obraz Odoo 20. Chociaż te tagi są obecnie powiązane z tą samą wersją główną, opublikowane rekordy nie określają, jak szersze tagi będą mapowane w przyszłości. (Docker Library Official Images Blob; Odoo)
Zespoły powinny więc zapisywać dokładny tag obrazu używany w środowisku deweloperskim, testowym i produkcyjnym, zamiast odnosić się wyłącznie do kontenera Odoo 20. Dostarczone źródła potwierdzają dostępne nazwy tagów, ale nie narzucają polityki tagowania. Dokumentacja infrastruktury powinna wskazywać wybrany tag i potwierdzać, że wpis w rejestrze nadal wskazuje na zamierzoną wersję Odoo, zanim obraz zostanie pobrany lub zaktualizowany. (Docker Library Official Images Blob; Odoo)
Obsługa trzech architektur procesorów
Obraz Odoo 20 jest dostępny dla amd64, arm64v8 i ppc64le. Organizacje działające na różnych platformach procesorowych mogą więc wybrać oficjalny obraz dla dowolnej z tych trzech architektur. Architekturę należy nadal traktować jako jawny wymóg wdrożenia, a nie wnioskować o niej wyłącznie na podstawie wersji Odoo lub tagu. (Docker Library Official Images Blob; Odoo)
Przed ujednoliceniem obrazu administratorzy powinni zweryfikować architekturę procesora każdego hosta docelowego i potwierdzić, że wybrany tag Odoo obejmuje wymaganą architekturę. Rekordy w rejestrze dotyczą samego obrazu Odoo. Nie potwierdzają zgodności niestandardowych modułów, integracji ani innego oprogramowania wspierającego, które należy ocenić osobno. (Docker Library Official Images Blob; Odoo)
PostgreSQL pozostaje osobnym wymaganiem
Udokumentowana konfiguracja kontenera wymaga PostgreSQL. Obraz Odoo jest więc jednym z elementów wdrożenia, a nie kompletnym samodzielnym środowiskiem. Projekt wdrożenia musi obejmować usługę bazy danych, jej połączenie z Odoo oraz odpowiednią obsługę danych bazy. Oficjalny wpis potwierdza wymaganie PostgreSQL, ale nie zastępuje konfiguracji bazy danych ani mechanizmów operacyjnych organizacji. (Odoo)
Organizacje zastępujące tymczasową receptę kontenera powinny porównać istniejącą konfigurację PostgreSQL z udokumentowanym ustawieniem dla oficjalnego obrazu. Samo wdrożenie obrazu aplikacji Odoo nie zastępuje automatycznie ani nie rekonfiguruje składnika bazy danych. Istniejące zmienne środowiskowe, ustawienia sieciowe i definicje wdrożenia należy sprawdzić względem oficjalnej dokumentacji przed ich ponownym użyciem. (Odoo)
Trwałe przechowywanie filestore Odoo
Docker Hub zaleca trwałe przechowywanie filestore Odoo przez zamontowanie woluminu w /var/lib/odoo. Oddziela to pliki trwałe od cyklu życia kontenera aplikacji. Definicje wdrożenia powinny uwzględniać udokumentowaną ścieżkę montowania oraz sposób przechowywania, który zachowa filestore po zastąpieniu lub aktualizacji kontenerów. (Odoo)
Ścieżka montowania wymaga uwagi także przy zastępowaniu niestandardowego obrazu lub wcześniejszej recepty wdrożenia. Istniejąca konfiguracja może używać określonej definicji woluminu lub lokalizacji danych. Administratorzy powinni porównać to ustawienie z udokumentowanym montowaniem /var/lib/odoo i potwierdzić, że zamierzony filestore będzie dostępny dla nowego kontenera. Oficjalne wskazówki określają zalecaną ścieżkę, ale nie podają procedury przeniesienia danych właściwej dla konkretnej organizacji. (Odoo)
Ograniczenia opublikowanych informacji
Publikacja jako Docker Official Image potwierdza źródło obrazu, tagi, wymienione architektury oraz podstawowe wskazówki dotyczące bazy danych i przechowywania. Nie potwierdza zgodności aplikacji, gotowości modułów niestandardowych, zgodności integracji, procedur migracji ani wymaganej przez organizację konfiguracji produkcyjnej. Oznaczony datą tag nie powinien być też traktowany jako dowód odrębnej daty wydania lub etapu wsparcia bez dodatkowej dokumentacji. (Docker Library Official Images Blob; Odoo; Odoo Docker)
Zespoły oceniające obraz powinny rozróżnić potwierdzoną publikację kontenera od szerszej decyzji o wdrożeniu Odoo 20. Testy powinny być prowadzone z celowo wybranym tagiem w środowisku innym niż produkcyjne i powinny rejestrować architekturę procesora, konfigurację PostgreSQL oraz montowanie filestore. Wszelkie wnioski dotyczące kodu niestandardowego, integracji zewnętrznych lub terminu migracji wymagają dowodów wykraczających poza oficjalne rekordy obrazu. (Docker Library Official Images Blob; Odoo; Odoo Docker)
Kontrole przed wdrożeniem
Przed zatwierdzeniem obrazu zespoły powinny zweryfikować bieżące mapowanie tagów w oficjalnym rejestrze, wybrać wymaganą architekturę procesora i potwierdzić, że pliki wdrożenia wskazują zamierzony obraz. Projekt powinien obejmować PostgreSQL oraz trwałe przechowywanie filestore Odoo przez wolumin zamontowany w /var/lib/odoo. Dokładne odwołanie do obrazu użyte podczas testów należy zachować w zapisach wdrożeniowych. (Docker Library Official Images Blob; Odoo)
Te kontrole powinny osobno obejmować każdy potwierdzony element publikacji. Wybrany tag można sprawdzić względem wpisu w rejestrze, dostępność architektury można potwierdzić dla docelowego hosta, a definicję wdrożenia można przejrzeć pod kątem PostgreSQL oraz montowania woluminu /var/lib/odoo. Dzięki temu ocena pozostaje zgodna z informacjami udokumentowanymi dla oficjalnego obrazu. (Docker Library Official Images Blob; Odoo)
Repozytorium źródłowe Odoo Docker można również przejrzeć podczas oceny sposobu organizacji obrazu 20.0. Zatwierdzenie produkcyjne powinno nadal zależeć od własnych testów organizacji dotyczących migracji, modułów, integracji i procedur operacyjnych. Dostarczone źródła potwierdzają istnienie oficjalnego obrazu Odoo 20 i dokumentują jego bieżące identyfikatory, zakres architektur, zależność od bazy danych oraz zalecane montowanie filestore. (Odoo Docker; Docker Library Official Images Blob; Odoo)