Cloud, Docker és DevOps — gyors és megbízható üzembe helyezés
Minden alkalmazást Dockerbe csomagolunk, Docker Compose-zal vezényeljük (enterprise projekteknél Kubernetesszel), a Caddyt reverse proxyként állítjuk be automatikus SSL-lel, a teljes deployciklust pedig GitHub Actionsön keresztül automatizáljuk — a committól az éles környezetig.
Konténerizálás Dockerrel és Docker Compose-zal
Minden szolgáltatásnak saját, több lépcsős Dockerfile-ja van: a build lépcső telepíti a függőségeket és fordít, a minimális záró lépcső (distroless vagy alpine) pedig már csak a szükséges artefaktumokat tartalmazza. Egy tipikus Next.js-image 150 MB alatt marad, egy FastAPI-image 80 MB alatt. Az image-eket minden main ágra érkező merge után újraépítjük, és szemantikusan címkézzük (`v1.2.3` + `latest`).
A Docker Compose írja le a teljes stacket: frontend, API, adatbázis, Redis, worker. Az érzékeny változók (adatbázisjelszó, API-kulcsok, Stripe-titok) a gitből kizárt `.env` fájlban élnek — soha nem égetjük bele az image-be. A Compose health checkjei gondoskodnak arról, hogy a függőségek készen álljanak az indulás előtt (adatbázis kész → API indul → frontend indul).
- Build cache `--mount=type=cache` segítségével — az `npm ci` a gyorsítótárból dolgozik a CI-ban
- Optimalizált rétegsorrend: előbb a stabil függőségek, utána a forráskód
- Titokkezelés Docker secretsszel vagy HashiCorp Vaulttal enterprise projekteknél
- `restart: unless-stopped` + `docker compose up --no-deps` az atomi deployhoz
Caddy — korszerű reverse proxy automatikus SSL-lel
A Caddy 2.8 az SSL/TLS-t automatikusan kezeli ACME-n keresztül (Let's Encrypt vagy ZeroSSL) — nincs lejárt tanúsítvány és nincs kézi beállítás. A HTTP/2 és a HTTP/3 (QUIC) alapból be van kapcsolva. A biztonsági fejléceket (HSTS, X-Frame-Options, CSP) újrafelhasználható snippetekkel állítjuk be globálisan. A deklaratív Caddyfile jól diffelhető, és gitben verziózzuk.
A rate limitinget, a gzip/brotli tömörítést és a strukturált JSON-naplózást a Caddy natív direktíváival kapcsoljuk be — nginx-modulok és bonyolult Apache-konfiguráció nélkül. Az érzékeny útvonalakra (`/admin`, `.env`, `.git`) érkező kéréseket globális biztonsági snippet zárja le 444-es válasszal (nincs válasz).
- Kizárólag TLS 1.3, modern cipher suite-okkal
- On-demand TLS a dinamikus aldomainekkel dolgozó, több bérlős SaaS-hoz
- Újratöltés újraindítás nélkül — a `caddy reload` a konfigurációt élőben alkalmazza
- Caddy-naplók → Loki → Grafana — forgalomelemzés és riasztás rendellenességekre
GitHub Actions CI/CD és monitoring
A CI-folyamat minden PR-nél lefut: lint, típusellenőrzés, unit tesztek, Docker-image építése és sérülékenységvizsgálat (Trivy). Ha minden lépés átmegy, az image felkerül a registrybe, a staging deploy pedig automatikusan megtörténik. A main ágra érkező merge automatikus éles deployt jelent, utána health checkkel. Ha ez 60 másodpercen belül elbukik, a rendszer automatikusan visszaáll az előző verzióra.
A monitoringhoz Grafanát és Prometheust használunk az alkalmazásmetrikákhoz (késleltetés, hibaarány, sorhossz), a naplók összegyűjtésére pedig Lokit. A riasztások Slacken vagy e-mailben futnak: 1% feletti hibaarány, 500 ms feletti P95-késleltetés, 85% feletti lemezhasználat. A külső elérhetőségfigyelést a Better Uptime végzi — nyilvános SLA-dashboardot kérésre biztosítunk.
- Trivy sérülékenységvizsgálat az image-eken — a kritikus CVE-k blokkolják a deployt
- Dependabot automatikus merge-dzsel a patch frissítésekre (zöld CI szükséges hozzá)
- Automatikus adatbázismentés S3-kompatibilis tárolóba (éjszakánként, 30 napos megőrzéssel)
Előnyök és korlátok
Előnyök
- Atomi átváltású deploy, automatikus visszaállással, ha a health check elbukik.
- Automatikus SSL/TLS a Caddyn keresztül — nincs kézzel lejáratott tanúsítvány.
- Reprodukálható környezet: ugyanaz a Docker-image fut fejlesztésen, stagingen és élesben.
- Monitoring és riasztások (Grafana, Loki) — a hibák riasztással jelezhetők.
Korlátok
- A Docker Compose több csomópontos enterprise környezetben nem skálázódik úgy, mint a Kubernetes.
- A kezdeti CI/CD-beállítás időt és DevOps-tapasztalatot igényel.
- Az image-ek és a naplók lemezhelyet foglalnak — rendszeres takarítás kell.
- A teljes monitoring (Prometheus + Grafana) újabb karbantartandó szolgáltatásokat hoz magával.
Rövid értékelés
A Docker, a Caddy és a GitHub Actions hármasa ideális megbízható deployhoz egy VPS-en vagy néhány csomóponton. Több tucat csomópontnál, agresszív auto-scalinggel viszont már a Kubernetes felé vezet az út.
Specifikációs táblázat
| Képesség | Korlát / küszöb | Tipikus felhasználás | |
|---|---|---|---|
| Vezénylés | Docker Compose, teljes stack | Egy csomópont; a több csomóponthoz Swarm vagy K8s kell | VPS, kis és közepes projektek |
| Reverse proxy | Caddy 2.8, HTTP/3, automatikus SSL | A nagyon összetett szabályok bőbeszédű konfigurációt kívánnak | Több domain, több bérlő |
| CI/CD | GitHub Actions, automatizált deploy | A CI-percek a free tier fölött díjkötelesek | Automatikusan a committól az éles környezetig |
| Tipikus költség | VPS nagyjából 5 €/hónaptól | A monitoring és a backup többletköltséget jelent | Egyetlen weboldaltól a több márkás üzemeltetésig |
Docker Compose és Kubernetes összehasonlítása
| Szempont | Docker Compose | Kubernetes |
|---|---|---|
| A beállítás bonyolultsága | Alacsony | Magas |
| Több csomópontos skálázás / auto-scaling | Korlátozott (egy csomópont) | Kiváló |
| Mire való | VPS, kis és közepes projektek | Nagy flották, enterprise |
Gyakori kérdések
Miért Caddy és miért nem Nginx?
A Caddy automatikusan kezeli az SSL/TLS-t ACME-n keresztül, alapból bekapcsolja a HTTP/2-t és a HTTP/3-at, és rövid, deklaratív konfigurációval beéri. Az Nginxnek ugyanehhez certbot és jóval több kézi beállítás kell.
Szükségem van Kubernetesre?
A legtöbb weboldalhoz nem. Egy VPS-en futó Docker Compose megbízhatóan elvisz egy weboldalt vagy néhány szolgáltatást. A Kubernetes csak több tucat csomópontnál, agresszív auto-scaling mellett térül meg.
Hogyan működik a deploy átváltása?
A GitHub Actions felépít egy új image-et, elindítja a régi mellett, lefuttat egy health checket, majd átirányítja a forgalmat. Ha a health check 60 másodpercen belül elbukik, a rendszer automatikusan visszaáll az előző verzióra.
Milyen monitoringot ajánlotok?
Grafanát és Prometheust a metrikákhoz (késleltetés, hibaarány), Lokit az összegyűjtött naplókhoz, riasztásokkal Slacken vagy e-mailben. A külső elérhetőségfigyelésre pedig egy független szolgáltatás jön hozzá, például a Better Uptime.