frissítve: 2023. 05. 02.
Olvasási idő: 9 perc
Útmutató

Docker alapú VPS tárhely éles környezetben

A korábbi, témához kapcsolódó bejegyzésben már feszegettem a kérdést, hogy shared hosting helyett érdemes lehet saját üzemeltetésű VPS-t használni teszt környezetként. Újra felvéve ezt a fonalat, megírom, hogy én hogyan hosztolom élesben a saját és ügyfeleim weboldalait, VPS-en - ígérem, hogy nem lesz bonyolult. :)


Kezdjük először is azzal, hogy hova tervezünk eljutni, vagyis mik az elvárásaink:

  • a VPS-ről kiszolgált összes domain kapjon automatikusan SSL tanúsítványt, emberi közreműködés nélkül,
  • az újonnan felhúzott oldalak és domainek automatikusan legyenek elérhetőek az Internetről azt követően, hogy a domaineket a VPS-re irányítottuk és a konténereik futnak
  • a projektek teljes mértékben testreszabható futási konfigurációval rendelkezzenek, melyet verziókövetni is lehet
  • a projektek önállóan szabályozható infrastruktúrával rendelkezzenek, vagyis tetszőleges PHP, MySQL, Apache, nginx, whatever verziót használhassunk anélkül, hogy ez a többi projektet befolyásolná
  • tartsuk alacsonyan a VPS-specifikus konfigurációt, gyors "menekülési lehetőséget" hagyva magunknak egy másik VPS-re, ha valami rosszul sülne el

A fenti követelményeket hatékonyan és teljes mértékben teljesíteni tudjuk egy Docker-re épülő infrastruktúrával, mely a következőképpen épül majd fel:

  • az egyes projektek és oldalak tartalmazzák a saját production konfigurációjukat is, vagyis önálló szolgáltatáscsomagot szállítsanak a pl. docker-compose.yml fájlukban
  • a projekt önálló webszerverrel rendelkezik majd, ami (környezeti változókon keresztül) közli az egyetlen, minden projekt előtt "ülő" reverse proxy-val, hogy milyen domainhez tartozó lekéréseket szükséges az adott projekthez irányítani
  • kizárólag a reverse proxy érintkezik a külvilággal, a projektek konténerei nem elérhetőek
  • a reverse proxy a 80-as és 443-as porton keresztül érhető el, de minden forgalmat automatikusan a HTTPS protokollra irányít
  • a HTTPS-hez szükséges tanúsítványt automatikusan, a mögötte ülő projekt elindítását követően beszerzi a Let's Encrypt-et használó kísérő (companion) konténeren keresztül

Segítségül készítettem egy illusztrációt, hátha könnyebben átlátjuk így a működést:

Docker based hosting with VPS

a képen látható "elérési útvonalak" tetszőlegesek, csak a példa kedvéért szerepelnek

NB: A cikk további része feltételez egy beállított VPS-t, ami elérhető az Internetről, így ha ilyennel nem rendelkezel, akkor először mindenképpen hozz létre egyet. A létrehozást és beállítást követően pedig telepítsd a Docker-t is.

Reverse proxy

A reverse proxy-nk elindításához szükséges fájlok megtalálhatóak ebben a GitLab tárolóban - a folytatáshoz klónozzuk a repó-t, majd lépjünk be a könyvtárba:

Itt találunk egy docker-compose.yml fájlt, a következő tartalommal:

Nem túl bonyolult konfiguráció: alapvetően csatoljuk a mappákat a konténerek azon pontjaira, ahova azokat csatolni kell (^.^), illetve beállítunk néhány alapértelmezést - ezek részleteiért keresd fel a reverse proxy, a companion image, illetve az nginx dokumentációt.

Fontos: ez a konfiguráció csak olyan böngészőkkel működik, melyek támogatják az SNI-t (vagyis Internet Explorer 8 + Windows XP kombinációval biztosan nem fog működni), cserébe a Qualys SSL Labs tesztjén A+ értékelést ér el.

Projekt konfiguráció

Ahhoz, hogy a reverse proxy megfelelően tudja a projektünk konténereire irányítani a forgalmat, jeleznünk kell, hogy melyik domainhez tartozó kéréseket szeretné a projekt, hogy a reverse proxy oda irányítsa. Ehhez a VIRTUAL_HOST és LETSENCRYPT_HOST környezeti változókat fogjuk használni: előbbi a konténerre irányítandó domainek listáját tartalmazza, a második pedig azoknak a domaineknek a listáját jelzi a companion konténernek, melyekre tanúsítványt szeretnénk igényelni. Mivel ezek nagy eséllyel megegyeznek, ezért a docker-compose.yml fájlunk "melletti" .env fájlban akár definiálhatnánk is egy változót, melyet a docker-compose.yml-ben használni fogunk. Ezenkívül a projektünkben a webszervert (a fenti ábrán kékkel jelölt elemet) csatlakoztatnunk is kell ahhoz a hálózathoz, amin az nginx reverse proxy ül (ez a példában az nginx_reverse_proxy nevű hálózat).

.env:

docker-compose.yml:

Látszik, hogy több változót is használunk, ennek pedig az oka az, hogy - mivel a Docker képes a .env fájl használatára - a docker-compose.yml fájlunk ezáltal újrahasznosíthatóvá vált: elég, ha projektenként csak a .env fájl tartalma tér el, és akkor a docker-compose.yml fájlunkhoz nem is kell nyúlnunk (a fenti minta az aktuálisan kedvenc tartalomkezelőmhöz, Craft CMS-hez készült, WordPress-hez példa docker-compose.yml-t itt találhatsz).

Ami még említésre méltó:

  • nem teszünk elérhetővé egyetlen portot sem a hoszton, csak a Docker hálózaton keresztül (expose),
  • rövid logolást állítunk be (max 3 fájl, fájlonként max. 1 MB)
  • a konténereket MINDIG újraindítjuk: rossz lenne arra riadni, hogy nem elérhető valamelyik weboldalunk

Elindítva tehát a projektet (docker-compose up -d) a letsencrypt_nginx_proxy_companion image máris érzékeli az eventet, hogy Docker konténer indult el (docker logs letsencrypt_nginx_proxy_companion), és el is indítja a tanúsítvány generálási folyamatot. Amire eddig nem sikerült rájönnöm (vagy csak béna voltam), hogy Cloudflare-rel hogyan tudna együttműködni ez a konfiguráció, erre tehát figyelj te is: ha redirect loop-ba kerülsz, akkor törölj HSTS cache-t és vedd ki a Cloudflare-en a kapcsolódó aldomainek mögül a narancs felhőt. Frissítés: Matt Stein javaslatára átállítottam a Crypto -> SSL részt Flexible-ről Full-ra, ami - úgy tűnik - megoldotta a problémát. Ha a nem-www vagy www-s aldomained átirányítási hurokba kerülne, állíts be egy redirect rule-t a Cloudflare-n arról az aldomainről a másikra (tehát ha pl. a nem-www-s kerül loopba, akkor a nem-www => www átirányítási szabály megoldja a gondot).

Ezzel nagyjából a bejegyzés végére is értünk: ha mindent jól csináltunk (te is és én is), akkor most van egy szervered, ami A+ minősítésű HTTPS kapcsolatot tud kiépíteni, miközben szeparáltan futnak rajta a projektjeid (akár teljesen eltérő, vagy csak verziókban különböző stackeken), és addig pakolhatsz ügyfél siteokat a szerverre, amíg bírja a VPS-ed.

Utóirat: a DigitalOcean-en már 200 dollárnak megfelelő kezdeti kreditet adnak a friss regisztrálóknak. Ha VPS-t szeretnél, akkor ez egy jó lehetőség a kipróbálásra. A kreditek 60 napig használható fel.

A sorozat itt még nem ért véget: ha már nem az első gépedet húzod fel, tuti, hogy nem egyesével szeretnél bejelentkezni rájuk és megnézni, mi a helyzet velük - rakj össze hát egy Grafana alapú monitorozó rendszert!

Ha bármilyen kérdésed, kérésed van, vagy hibát találtál, keress bizalommal!

Videó

Időközben készült egy videó is a teljes folyamatról: Buxbaum Barnával beszélgetünk, és az utolsó 45-50 percben meg is mutatom a teljes folyamatot.

Változások követése

Frissítések

2023. 05. 02.

A DigitalOcean ajánlói ajánlata frissült: már 200 dollárnyi kreditet kap az ajánlott, melyet 60 napja van felhasználni.