Dolibarr Docker-frissítés: image, adat és verziózár

2026. szeptember 3. · Üzemeltetés

A konténer frissül, de az ERP nem magától: mit változtat a Dolibarr új Docker-kiadási folyamata?

A Dolibarr kiadásai már automatikusan indítják a hivatalos Docker image-ek készítését. Ez gyorsabb és követhetőbb terjesztést ad, de a biztonságos ERP-frissítéshez továbbra is verziózár, mentés és migrációs próba kell.

← Vissza a blogbejegyzésekhez

A Dolibarr kiadási folyamatának egyik kevésbé látványos, mégis fontos újdonsága, hogy egy GitHub-release automatikusan elindíthatja a hivatalos Docker image elkészítését. A változás a 22.0.4 kiadási jegyzetében jelent meg, a Docker Hubon pedig már elérhetők a 24.0.0 és 23.0.4 verzióhoz tartozó hivatalos, AMD64 és ARM64 architektúrájú image-ek.

Mi változott valójában?

Korábban a Dolibarr alkalmazás kiadása és a hivatalos konténer-image megjelenése könnyebben válhatott két külön kézi folyamattá. Az automatizálás ezeket közelebb hozza egymáshoz: a release eseménye elindítja a Docker-csomag elkészítését. Ennek gyakorlati haszna a rövidebb átfutás és az ismételhetőbb csomagolás.

Az official Docker repository leírása szerint az image a hivatalos PHP- és Dolibarr-forrásokra épül, az adatbázist azonban nem tartalmazza. A támogatott architektúrák között az x86-64 (AMD64) és az ARMv8 64 bites (ARM64) szerepel. Ez azt jelenti, hogy ugyanaz a kiadási ág hagyományos szerveren és megfelelő ARM-alapú infrastruktúrán is használható — de az architektúra-támogatás önmagában még nem igazolja a saját modulok kompatibilitását.

A három név, amely nem ugyanazt ígéri

• dolibarr/dolibarr:latest: mozgó címke; később más image-re mutathat.
• dolibarr/dolibarr:24: főverzióhoz kötött, de a 24-es ág új javítókiadásával szintén továbbmozdulhat.
• dolibarr/dolibarr:24.0.0: pontos alkalmazásverziót nevez meg. Szabályozott telepítéshez ez jobb kiindulópont; a teljes reprodukálhatósághoz az image digestjét is érdemes rögzíteni.

A digest tartalomazonosító. Ha az üzemeltetési szabályzat megköveteli, hogy ugyanazt a kipróbált image-et lehessen újratelepíteni, ne csak egy címkét, hanem az elfogadott digestet és a hozzá tartozó konfigurációt is őrizzük meg. Biztonsági javításkor ezt tudatosan kell új verzióra vagy új digestre cserélni; a verziózár nem indok az elavult image megtartására.

A konténer cserélhető, az üzleti adat nem

A hivatalos dokumentáció külön figyelmeztet: frissítéskor csak a perzisztens könyvtárakba helyezett adat marad meg. A példakonfiguráció a dokumentumtárat a /var/www/documents, az egyedi fejlesztéseket pedig a /var/www/html/custom útvonalon kezeli külső volume-ként. Az adatbázis külön szolgáltatás.

Ezért a „lehúzzuk az új image-et és újraindítjuk” mondatból legalább négy ellenőrzés hiányzik:

1. van-e konzisztens, visszaállítható mentés az adatbázisról és a dokumentumokról;
2. perzisztens-e a documents és a custom tartalma;
3. kompatibilisek-e az egyedi modulok, sablonok és integrációk a célverzióval;
4. lefutott-e és sikeres volt-e a Dolibarr adatbázis-migrációja.

Egy biztonságosabb Docker-frissítés rövid menete

1. Leltár: rögzítsük a futó Dolibarr-verziót, image taget és digestet, PHP-verziót, adatbázis-verziót, volume-okat és külső modulokat.
2. Mentés és visszaállítási próba: ne csak mentésfájl készüljön; egy elkülönített környezetben bizonyítsuk is, hogy az adatbázis és a dokumentumok együtt helyreállnak.
3. Tesztkörnyezet: ugyanazzal a cél-image-dzsel futtassuk le a migrációt, majd próbáljuk végig a kritikus üzleti folyamatokat.
4. Verziózár: az elfogadott tag vagy digest kerüljön a Compose-konfigurációba. Az éles környezet ne a latest címkéből tudja meg véletlenül, hogy főverziót váltott.
5. Időzített élesítés: legyen karbantartási ablak, felelős, naplófigyelés és dokumentált visszaállítási döntési pont.

Mit nyerünk az automatizálással?

Az új kiadási kapcsolat legnagyobb értéke nem az, hogy kevesebbet kell gépelni a szerveren. Hanem az, hogy a forráskiadás és a futtatható csomag között rövidebb, követhetőbb út jöhet létre. Ez megkönnyítheti a tesztkörnyezetek egységesítését, a CI-folyamatokat és a gyors biztonsági frissítést.

A felelősségi határ viszont nem tűnik el. A Dolibarr-projekt elkészíti és közzéteszi az image-et; az üzemeltető dönti el, melyik változatot, milyen adatokkal, modulokkal, hálózati védelemmel és mentési renddel futtatja. A konténer reprodukálható csomag, nem frissítési stratégia és nem biztonsági mentés.

Források

• Dolibarr 22.0.4 hivatalos kiadási jegyzet – az automatikus Docker-release bevezetése
• Dolibarr hivatalos Docker repository – architektúrák, Compose-példa, volume-ok és frissítési folyamat
• Docker Hub – a hivatalos Dolibarr image-ek aktuális tagjei és digestjei
• Dolibarr Wiki – telepítési és Docker-ajánlások

Forrásállapot: 2026. szeptember 3. A Docker Hub tagjei és digestjei változhatnak; telepítés előtt mindig az aktuális hivatalos adatot és a saját célkörnyezetet kell ellenőrizni.

Ez a Dolibarr.hu szerkesztett, magyar nyelvű útmutatója.