Doco CD teszt: GitOps a Docker Compose-hoz Kubernetes-teher nélkül

Minden push ugyanazzal a rituáléval jár: belépés SSH-n, a repó lehúzása, a Compose stack újraindítása, reménykedés, hogy semmi nem tört el, és próbálod felidézni, lefuttattad-e a migrációt. Ez a kézi kör addig működik, amíg nincs szükséged ismételhető telepítésekre, tiszta képre arról, mi fut, vagy a sodródásból való visszaállásra.

A Doco CD egy közvetlen válasz erre. Egy kis Go-szolgáltatás, amely figyeli a Git-repódat, és push esetén alkalmazza a Compose-változásokat: webhook vagy lekérdezés, te döntöd el. Az ArgoCD és a Flux ugyanezt teszi Kubernetesen, de a Doco CD megkerüli a Kubernetest, mert nincs szüksége control plane-re.

Ez a teszt bemutatja, mit tud a Doco CD, mit nem, és hogyan áll a Komodo eszközzel, a Portainer GitOps módjával, a Dokployjal és egy egyszerű GitHub Actions + SSH szkripttel szemben. A végén tudni fogod, illik-e a környezetedhez, és mit válassz, ha nem.

Röviden

• A Doco CD egy pici, Compose-natív GitOps ügynök: figyel egy Git-repót (GitHub, GitLab, Gitea, Forgejo és mások), és ha valami változik, összehangolja a stacket.
• A külső titokszolgáltatók beépített támogatása, valamint a SOPS-alapú titkosítás az, ami megkülönbözteti a saját kezűleg írt telepítőszkripttől.
• A README szerint úgy pozicionálja magát, mint „egyszerű Portainer- vagy ArgoCD-alternatíva Dockerhez”. Ez a keretezés nagyjából pontos.
• A valódi korlátok: egyetlen kódtulajdonos, 1.0 előtti verziózás, flottakezelő felület hiánya, és olyan összehangolási állapot, amely csak a következő lekérdezés vagy webhook-esemény után épül újra.
• Akkor válaszd, ha egy vagy néhány Compose-hosztot üzemeltetsz, és felület nélkül szeretnéd a Gitet igazságforrásnak. Flottához a Komodo való, felülethez a Portainer, PaaS-érzethez a Dokploy, és ha tényleg egy szolgáltatás fut egy gépen, a GitHub Actions + SSH.

A rés, amit a Doco CD be akar tölteni

Furcsa köztes helyzet vár mindenkire, aki 2026-ban Docker Compose-t üzemeltet. A nagy GitOps-eszközök, mint az Argo CD és a Flux, a Kubernetesre készültek, a Watchtower registry-lekérdezésen alapuló modellje pedig image-változásokra reagál ahelyett, hogy verziózott Compose-állapotot alkalmazna. A Watchtower tárolója 2025. december 17-én archiválásra került, és ma már azt közli, hogy a projekt nem karbantartott.

A GitHub Actions és egy SSH-s telepítési lépés működik. Egy gépen futó egyetlen szolgáltatáshoz ez a helyes döntés. A baj akkor kezdődik, amikor jön a második gép vagy a második stack, esetleg tudni akarod, melyik commit fut éppen. A workflow naplói megmaradnak, de Compose-natív összehangolás, sodródásból való visszaállás és arról szóló tartós kép, hogy a gép még egyezik-e a repóval, nem.

A Doco CD önmeghatározása, közvetlenül a README-ből, az, hogy „egyszerű Portainer- vagy ArgoCD-alternatíva Dockerhez”. Épp ez a keretezés a lényeg: kicsi, Compose-natív, nincs Kubernetes, nincs karbantartandó felület, nincs központi control plane, amit dajkálni kell. Ha nem futtatsz K8s-t, és nem is akartál, pontosan ezt a kategóriát kerested.

Hogyan működik valójában a Doco CD

A Doco CD egyetlen Go bináris, amely Docker-konténerben fut, figyel egy Git-repót, és alkalmazza a Compose-változásokat, amint a repó állapota változik. Ennyi az egész koncepció. Az érdekes részek az alapértelmezésekben és az integrációkban rejlenek.

Kiváltó események. Két mód van: webhook vagy lekérdezés. A webhook szinte azonnali, de nyitott portot igényel, reálisabban egy fordított proxyt a Doco CD előtt. A lekérdezés időszakos letöltés: kissé késleltetett, bejövő port nélkül. A lekérdezés az egyszerűbb alapértelmezés, és a hivatalos dokumentáció szerint mindkettő teljes értékű. Az alapján válassz, hogy a géped rendelkezik-e elérhető nyilvános végponttal, és milyen gyors telepítésre van szükséged.

Repónkénti konfiguráció. Egy .doco-cd.yaml fájl (vagy .doco-cd.yml) a repó gyökerében, a Compose-fájlod mellett foglal helyet. Az egyetlen kötelező mező a telepítés neve. Egy minimális konfiguráció így néz ki:

# .doco-cd.yaml
name: my-stack
# Everything below is optional. These are the defaults.
timeout: 180          # seconds
remove_orphans: true
prune_images: true
force_recreate: false

Ezek a dokumentált alapértelmezések: 180 másodperces időkorlát, az árva konténerek törlése, a képfájlok kitakarítása és a kényszerített újralétrehozás kikapcsolása.

Automatikus felderítés. Bekapcsolt automatikus felderítéssel a Doco CD végigpásztázza az alkönyvtárakat Compose-fájlok után, így egyetlen repó több stacket is tarthat. Emellett egy fájlban több telepítési konfigurációt is támogat, három kötőjeles sorral elválasztott YAML-dokumentumok formájában. A takarítás alapértelmezései óvatosak, és érdemes elolvasni őket, mielőtt rájuk támaszkodnál:

Más szóval a hátad mögött semmit nem bontanak le, amíg te magad nem kapcsolod be a törlést, és még akkor is az adatkötetek mennek utoljára.

Támogatott Git-szolgáltatók. Támogatott a GitHub, a GitLab, a Gitea, a Forgejo, a Gogs és az Azure DevOps. Webhook terén az Azure DevOps a kivétel, mert az Azure Service Hooks nem támogatott. A Gitea és a Forgejo támogatása akkor számít, ha saját forge-ot üzemeltetsz.

Docker Swarm. Célként támogatott. Amit a telepítési beállítások oldala kifejezetten jelez: Swarm módban az összehangolás nem ellenőrzi sem a konténerek újraindulását, sem az állapotot, és a képfájlok takarítása sem támogatott Swarmban. Ha a célod a Swarm, telepítéseket kapsz, teljes állapot-összehangolást nem.

Összehangolás. Alapból 5 újraindítás a korlát egy 300 másodperces ablakon belül, hogy a kapkodó állapotellenőrzések ne pörögjenek a végtelenségig. Ugyanaz a repó eltérő referenciával sorosan fut, ugyanaz a repó azonos referenciával párhuzamosan. Ez az utolsó apróság finom, de hasznos: ugyanannak a referenciának a több telepítése nem áll sorba egymás mögé.

Beépített külső titokszolgáltatók. Ez az egyik legerősebb érv a Doco CD mellett egy egyszerű telepítőszkripttel szemben: támogatja az AWS Secrets Managert, a Bitwarden Secrets Managert, a Bitwarden Vault / Vaultwardent, az 1Passwordöt, az 1Password Connectet, az Infisicalt, az OpenBao-t és a Webhookot. Ettől függetlenül SOPS-alapú titkosítást is kínál az érzékeny telepítési adatokhoz. Így tiszta úton szabadulhatsz a Gitben tárolt, sima szöveges env fájloktól anélkül, hogy a teljes titokfeloldási folyamatot magad építenéd meg.

A többi. A Doco CD Prometheus-metrikákat, feladatütemezést, értesítéseket, distroless konténerképet és Apache-2.0 licencet ad. A projekt kiadási előzményei szerint 2026. augusztus 20-i állapot szerint a v0.109.2 a legfrissebb stabil kiadás, a v0.110.0-rc.1 pedig a legújabb előzetes.

A Doco CD munkája a „alkalmazd a manifestet” pontnál véget ér, onnantól szokványos Docker következik. A Compose saját naplóparancsai azok, amikkel megnézed, mi fut éppen.

Gyakorlati tipp a titkokhoz. Ha a privát repódban még mindig sima szöveges env fájlok hevernek, kezdd a Doco CD külső titokszolgáltatóival vagy a SOPS-támogatással. A cél egyszerű: a nyílt szöveges titkok kerüljenek ki a Gitből, a telepítések mégis feloldhassák az értékeket futásidőben.

Hol marad el a Doco CD

Minden eszköznek vannak korlátai, és a Doco CD-éit érdemes ismerni, mielőtt egy egész hétvégét áldoznál a beüzemelésére.

Egyetlen kódtulajdonos. A tároló CODEOWNERS fájlja minden útvonalat a kimdre felhasználóhoz rendel. A kiadások továbbra is sűrűn jönnek, de az irányítás egyetlen emberre összpontosul.

1.0 előtt. A Doco CD még mindig 0.x verziózást használ, ezért rögzíts egy letesztelt kiadást, és a bevezetés előtt olvasd el a frissítési jegyzeteket. A lezárt GitHub #851-es hibajegy jól mutatja, miért: a Docker v29 arra kényszerítette a projektet, hogy elhagyja az elavult Docker Go modulokat.

A Doco CD konténerében nincs parancsértelmező. Biztonsági okokból a Doco CD nem ad parancsértelmező környezetet, és nem futtat tetszőleges szkripteket a gazdagépen. A telepítés előtti és utáni feladatoknak init konténereken, oldalkocsi konténereken vagy Compose életciklus-horgokon kell áthaladniuk, ami több konfigurációt jelent, mint azoknál az eszközöknél, amelyek egyszerűen lefuttatnak egy telepítőszkriptet.

Állapotvesztés újraindításkor. Az összehangolási állapot a memóriában él. Ha a Doco CD újraindul, ez az állapot csak a következő lekérdezés vagy webhook-esemény után épül újra, így a kiesés hossza a lekérdezési intervallumtól függ, vagy attól, milyen hamar érkezik újabb webhook.

Nincs flottakezelő felület. A többgépes működéshez már nem kell gépenként egy ügynök. A v0.102.0 óta a telepítési konfigurációk célozhatnak távoli Docker-kontextusokat, köztük SSH-kontextusokat is, és egyetlen tároló több telepítési célt is meghatározhat. Gépenként egy Doco CD példányt futtatni továbbra is helytálló, de egy központi példány mostantól távoli Docker-gépekre is telepíthet. Ami a Doco CD-ből még hiányzik, az a Komodo flottakezelő felülete és a központosított géplista.

A RAM- és CPU-igény nincs számszerűen dokumentálva. A hivatalos dokumentáció „elenyészőnek” nevezi az igényeket, de semmilyen alapértéket nem közöl. A VPS méretét a rajta futó alkalmazásokhoz szabd, hagyj üzemeltetési tartalékot, és a Doco CD tényleges fogyasztását a saját környezetedben mérd meg.

Gyakorlati tipp több géphez. Használj gépenként külön Docker-kontextust és külön telepítési célt, korlátozd az SSH-hozzáférést, és tartsd egyedinek a webhook- vagy API-titkokat. Ha az elszigetelt ügynököket kedveled, a gépenként egy Doco CD példány továbbra is helytálló.

Doco CD az alternatívákkal szemben

A másik négy eszköz, amelyet a szűkített listára tennék, mind ugyanazt próbálja megoldani, vagyis a „Compose automatikus telepítését Gitből”, csak nagyon eltérő kompromisszumokkal. A kérdés nem az, hogy megcsináld-e; azt már eldöntötted. A kérdés az, milyen formájú eszköz illik a környezetedhez. Íme az egymás melletti összevetés.

Röviden mindegyikről, mert a táblázat a formát adja, a kommentár pedig a miértet:

Komodo. A komoly többgépes alternatíva. Egy központi Core szolgáltatás, minden gépen egy Periphery ügynök, egyetlen felület, amely mindet látja, a telepítések mellett Git-vezérelt buildek, és Docker Swarm támogatás. Nehezebb beüzemelni, hiszen adatbázist és control plane-t is futtatsz, de ez a helyes forma, ha flottád van. A Komodo akkor illik jobban, amikor a központosított flottavezérlés számít.

Portainer (CE vagy BE) GitOps-szal. Teljes értékű grafikus felület a Git-szinkronizálás tetején. Akkor a helyes választás, ha a csapat kattintgatós konténerkezelést szeretne a CD mellé. Ha úgyis lesz valaki, aki a felületen nézi a naplókat és indítja újra a konténereket, akkor a CD is lakhat ugyanott. Erőforrásból többet fogyaszt, mint a Doco CD. Az OIDC/SSO és a finomhangolt RBAC a fizetős Business Edition mögött van. Erről bővebben a Portainer-alternatívák útmutatónk a tágabb Docker-kezelési tájképet mutatja be.

Dokploy. PaaS-stílus. Határozott elképzelései vannak, pushra automatikusan telepít, mindenhez van webes felülete, és rögtön beállítja neked a Traefiket meg a tiszta URL-eket. Inkább azoknak a csapatoknak jó, akik Heroku-érzést szeretnének, és hajlandók ezért feladni a Compose nyers rugalmasságát. Ha allergiás vagy a YAML-ra, ez a legkönnyebb út a „git push, és az app kinn van” állapotig.

GitHub Actions + SSH. Nulla plusz infrastruktúra. A telepítési feladat abban a workflow-ban lakik, ami már megvan. Megkapod a workflow naplóit, de nem kapsz Compose-natív összehangolást, sodródásból való visszaállást, sem tartós képet a gépek állapotáról, hacsak nem építed meg magad ezeket a darabokat. Egy gépen futó egyetlen szolgáltatáshoz teljesen rendben van. Akkor omlik össze, amikor jön a második cél, vagy tudni akarod, mi hol fut anélkül, hogy SSH-val belépnél. Az olvasók legegyszerűbb rétegének a GitHub Actions + SSH továbbra is a helyes válasz.

Van egy újabb jelölt is, a stackd , amely hasonló nyelvezettel írja le magát: „GitOps a Kubernetes-adó nélkül”. Érdemes tudni, hogy a kategória él, de nem érdemes ma pénzfeldobással a Doco CD elé sorolni.

OLVASD

Coolify vs Dokploy: alapos összehasonlítás önállóan üzemeltetett PaaS-hoz egy VPS-en

Mikor jó választás a Doco CD (és mikor nem)

Akkor válaszd a Doco CD-t, ha:

• Egy vagy néhány Docker Compose gépet üzemeltetsz, és a Gitet szeretnéd igazságforrásnak.
• Szívesebben szerkesztesz YAML-t a szerkesztődben, mint hogy egy felületen kattintgass.
• Külső titokszolgáltatók támogatását és SOPS-alapú titkosítást szeretnél anélkül, hogy a teljes folyamatot magad építenéd meg.
• Rendben van számodra egy egyetlen karbantartóval működő, 1.0 előtti, de aktívan fejlesztett projekt.

Komodo. Akkor válaszd, ha sok gépet kezelsz és központosított flottavezérlést szeretnél, vagy ha egy fedél alatt nemcsak telepítésre, hanem Git-vezérelt buildekre is szükséged van.

Portainer (CE vagy BE). Akkor válaszd, ha a csapat a CD mellé felületet szeretne a napi konténerműveletekhez, vagyis ha a vizuális réteg az igazi oka annak, hogy egyáltalán fontolgatod az eszközt.

Dokploy. Akkor válaszd, ha PaaS-stílusú telepítési élményt szeretnél, és nincs szükséged a Compose nyers vezérlésére.

GitHub Actions + SSH. Maradj ennél, ha egy szolgáltatásról és egy gépről van szó, és nincs szükséged összehangolásra vagy sodródás utáni visszaállásra.

Azoknak, akik ebben a köztes sávban vannak, Watchtower után és Kubernetes előtt, a Doco CD erős, könnyű választás. Az én olvasatom: új homelabhoz vagy kis SaaS-hoz a Doco CD-vel kezdenék, amíg a Git-központú, felület nélküli működés megfelel, majd a Komodo eszközre váltanék, amint a központi nyilvántartás, a jogosultságok és a flotta átláthatósága követelménnyé válik.

Bármelyik eszközt választod, olyan Linux VPS-en futtasd, amelyet a rajta futó Compose terhelésekhez méreteztek. A Cloudzy Linux VPS-e ésszerű otthon ehhez, alapból root hozzáféréssel. Ha pedig ki akarod hagyni az apt-tánclépéseket, akkor egy kattintással telepítheted a Dockert a marketplace-ünkről.

A marketplace-ünkön egykattintásos képfájlok is vannak: Gitea, amellyel a Doco CD natívan együttműködik. Emellett képfájl érhető el a Komodo és a Portainerszámára is, ha úgy döntesz, hogy valamelyikük felel meg jobban.

Gyakran ismételt kérdések

Éles környezetre kész a Doco CD?

A Doco CD használható élesben, ha a kockázati profilja illik a terheléshez. Aktívan fejlesztik, de még mindig 1.0 előtti verziózást használ, a CODEOWNERS fájlja pedig egyetlen emberhez rendeli a projektet. Rögzíts egy letesztelt kiadást, a frissítéseket bevezetés előtt próbáld ki, kritikus infrastruktúránál pedig gondolkodj szélesebb irányítási modellben.

Hogyan kezeljek több gépet a Doco CD-vel?

Használj gépenként külön Docker-kontextust és külön telepítési célt. Egyetlen Doco CD példány több távoli Docker-gépre is telepíthet SSH-n vagy TCP-n; a gépenként egy példány továbbra is választható elszigetelési modell. Válaszd a Komodo eszközt, ha központi nyilvántartásra, jogosultságokra és flottaszintű átláthatóságra van szükséged.

Mi a különbség a webhook és a lekérdezéses mód között?

A webhook mód szinte azonnal telepít, amint push érkezik a Gitbe, de internetről elérhető portot igényel, vagy egy fordított proxyt a Doco CD előtt. A lekérdezéses mód ütemezés szerint nézi meg a repót, így a telepítések kissé késnek, viszont semmilyen portot nem kell kinyitni. A lekérdezés az egyszerűbb alapértelmezés; a webhook akkor éri meg, ha gyakran pusholsz, vagy gyors visszajelzésre van szükséged.

Hogyan viszonyul a Doco CD a Komodo eszközhöz?

A Doco CD könnyebb és felület nélküli, több gépet pedig távoli Docker-kontextusokon át kezel. A Komodo központi Core szolgáltatásra és Periphery ügynökökre épül, és flottafelülettel meg Git-vezérelt buildekkel egészül ki. Felület nélküli Compose-telepítéshez a Doco CD-t válaszd, központosított flottavezérléshez a Komodót.

Kiválthatja a Doco CD a Watchtowert?

Arra a felhasználásra, amit a Watchtower felhasználóinak többsége valójában akart, vagyis hogy „telepítsd azt, ami a Gitben van, amikor a Git változik”, a válasz igen: pontosan ezt csinálja a Doco CD. A Watchtower szó szerinti modelljére, vagyis egy registry lekérdezésére és letöltésre, amint új image-címke jelenik meg, a válasz nem; a Doco CD-t a Git indítja, nem a registry. A Git által indított modell biztonságosabb és jobban auditálható választás minden olyasmire, ami túlmutat a játékszolgáltatásokon.