A docker-skeleton leírása

A docker-skeleton egy shell script framework, amely Docker konténerekből összeállított (komponált) webszolgáltatások menedzselésére szolgál standalone (nem orkesztrált) Ubuntu Linux Docker host környezetben. Ilyen környezet kialakítását az Ubuntu szerver alaptelepítése, annak általános biztonsági beállításai és a Docker host telepítése wikilapok ismertetik. A framework működése ebben a környezetben részletesen tesztelt, de egyéb, hasonló környezetben is működőképes lehet.

Work in progress - még ne vedd komolyan!

Áttekintés

Házirend

A Docker host telepítése wikilapon részletezett elrendezés használata során az alábbi házirendet valósítjuk meg:

• A hostgépen futó valamennyi dockerezett szolgáltatás egyetlen, nem perszonalizált, dedikált Linux felhasználó (a dockeradmin) tárterületén helyezkedik el (a /srv/docker/services könyvtár alatt). Ezen belül az egyes szolgáltatások elkülönített könyvtárakba kerülnek. Arra törekszünk, hogy a szolgáltatáshoz tartozó minden specifikus állomány a szolgáltatás alapkönyvtárán belül kapjon helyet, így a szolgáltatás ezen könyvtár lemásolásával klónozható, költöztethető, illetve menthető legyen.
• Minden szolgáltatás különálló Docker kompozícióban fut (akkor is, ha azt csak egyetlen konténer biztosítja), és a Dockeren belül a szolgáltatás számára dedikált networkre csatlakozik. Ezek a networkök közvetlenül nem átjárhatóak (azaz az egyes szolgáltatások egymásra nem látnak rá).
• A szolgáltatások publikus portjait a TCP/8201-től kezdve egyesével emelkedő számsorrendben osztjuk ki. Ezek a portok a hostgépen kívülről közvetlenül nem, csak SSH tunnelen vagy reverse proxyn keresztül érhetőek el. A dockerezett webszolgáltatások számára a reverse proxyt a hostgépen futó webszerver biztosítja.
• A dockerezett szolgáltatások konténereinek naplóit (a docker log kimeneteket), valamint a dockerezett webszolgáltatások webnaplóit perzisztensen megőrizzük és rotáljuk.
• A dockerezett szolgáltatásokról automatikus napi mentés készül, amelynek tartalma a szolgáltatás receptjében van meghatározva. A recept definiálásánál törekszünk arra, hogy a mentésből a szolgáltatás (szükség esetén annak újratelepítése után) teljesen visszaállítható legyen. Ez a mentés a naplókat általában nem tartalmazza.
• A dockerezett szolgáltatásokat adminisztráló dockeradmin felhasználó közvetlenül nem sudo-képes, de a docker Linux csoport tagjaként jogosult a docker és docker-compose parancsok teljes körű használatára.
  A dockeradmin felhasználót megbízhatónak tekintjük; tisztában vagyunk avval, hogy a fenti jogosultság birtokában a dockeradmin képes lenne a hostgépen a teljes körű root jogosultság megszerzésére is (TODO!).
• A dockeradmin felhasználó jogosult shell futtatására; mindennapi tevékenysége során parancssori műveleteket használ. Bejelentkezése PPK authentikációval, (a /srv/docker/.ssh/authorized_keys publikus kulcsai közé felvett egyéni magánkulccsal) történik.
• A dockeradmin felhasználó jogosult a hostgépen futó reverse proxy webszerver konfigurációjának teszteltetésére és annak újraolvastatására.
• TODO!

Könyvtárszerkezet

A Docker host telepítése wikilapon részletezett Docker host telepítés esetén a framework az alábbi könyvtárszerkezetben működik:

 /srv                 a dockeradmin Linux felhasználó HOME könyvtára
   /bin               a frameworkhöz tartozó binárisok könyvtára
   /services          a dockerezett szolgáltatások alapkönyvtára
   /tmp               tetszőlegesen felhasználható ideiglenes könyvtár
     .nginx           a dockerezett webszolgáltatások nginx konfigurációira mutató symlinkek könyvtára
     first_service    az első dockerezett szolgáltatás alapkönyvtára
     second_service   a második dockerezett szolgáltatás alapkönyvtára
     ...

A fenti könyvtárszerkezetet a framework telepítése (a konkrét webszolgáltatások könyvtárainak kivételével) kialakítja és megfelelően fel is tölti. Telepítés után a könyvtárszerkezet a dockeradmin:dockeradmin Linux felhasználó tulajdonában van, a könyvtárakra vonatkozón 2771, a fájlokra vonatkozóan 660 (scripteknél 770) jogosultságokkal.

Az egyes szolgáltatások könyvtárszerkezete minden szolgáltatás esetében lényegében azonos:

 service_base         a szolgáltatás alapkönyvtára
   .recipes           előre definiált szolgáltatás-receptek állományai
   .templates         a szolgáltatás testre szabásánál használt sablonok
   .utils             a docker-skeletonhoz kapcsolódó külső szolgáltatások
   configs            konfigurációs állományok (pl. nginx.conf)
     acme             az automatikus SSL tanúsítvány frissítés állományai
     certs            nem automatikusan frissített SSL tanúsítványok
   docker             helyben buildelendő szolgáltatás esetén annak állományai 
   logs               a Dockertől származó naplók
     web              a webszervertől származó naplók
   storage            a szolgáltatáshoz kapcsolódó tárhely
     backup           az automatikus mentések tárhelye
       dumps          az adatbázis-mentések könyvtára
       export         opcionálisan publikált automatikus mentések könyvtára
       tarballs       a konfiguráció- és egyéb tárterület mentések könyvtára
     volumes          a perzisztens Docker kötetek könyvtára
   tools              a framework szolgáltatás-szintű futtatható állományai
     backup.d         az automatikus mentéskor futtatandó scriptek
     build.d          az esetleges buildeléskor futtatandó scriptek
     shutdown.d       a szolgáltatás leállításakor futtatandó scriptek
     startup.d        a szolgáltatás indításakor futtatandó scriptek

A fenti könyvtárszerkezetet a szolgáltatás telepítésekor a docker-skeleton kiadás általános tartalmának és a konkrét szolgáltatás receptjének összefűzésével alakítjuk ki.

A szolgáltatások könyvtárszerkezete alapértelmezésben a dockeradmin:dockeradmin Linux felhasználó tulajdonában marad, a könyvtárakra vonatkozón 2771, a fájlokra vonatkozóan 660 (scripteknél 770) jogosultságokkal. A storage/volumes könyvtárban esetlegesen (a használt receptben meghatározott) ettől eltérő tulajdonosra és jogosultságokra lehet szükség (ennek beállításához a szolgáltatás telepítésénél root jogosultság kellhet). A könnyebb adminisztrálhatóság érdekében törekedjünk arra, hogy ilyen esetben is a dockeradmin felhasználónak legyen (pl. ACL-lel biztosított) olvasási- és írásjoga a szolgáltatás teljes tárterületére.

Webszolgáltatás

A dockerezett webalkalmazások számára a hostgépen telepített natív webszerver (jelenleg Apache vagy nginx) biztosít SSL végződtetést (tanúsítványkezelést) és http(s) => http reverse proxy szolgáltatást. A dockerezett alkalmazás saját szolgáltató portját (esetleg portjait) a hostgépen a localhost:[8201-] tartományban exportálhatja, itt kapja a számára releváns lekéréseket a reverse proxy webszervertől. A fenti elrendezésben a webszolgáltatás akkor is válaszképes, ha az upstream dockerezett webalkalmazás éppen nem fut - ez esetben a webszerver a publikus lekérésre customizált hibaüzenettel válaszol.

A docker-skeleton frameworkben egy-egy komponált szolgáltatás minden webes alkatrésze - konfigurációja, SSL tanúsítványa, tárterülete, naplóállományai - a szolgáltatás alapkönyvtára alatt helyezkedik el, az alábbiak szerint:

service_base         a szolgáltatás alapkönyvtára
  configs            konfigurációs állományok
    acme             az automatikus SSL tanúsítvány frissítés állományai
    certs            nem automatikusan frissített SSL tanúsítványok
    nginx.conf       virtualhost konfiguráció (nginx)
    apache.conf      virtualhost konfiguráció (apache)
  logs               naplóállományok
    web              a webszervertől származó naplók
  storage            a szolgáltatáshoz kapcsolódó tárhely
    volumes          a perzisztens Docker kötetek könyvtára

Minden dockerezett webszolgáltatás a hostgépre vonatkozóan önálló virtualhost konfigurációval rendelkezik, amelyben az alanti beállítások definiálva vannak. Az alapértelmezett konfiguráció sablon alapján történő létrehozását script támogatja, ezután azonban a konfiguráció dockeradmin-ként manuálisan tetszés szerint módosítható és a módosítás érvényesíthető (a dockeradmin felhasználó jogosult a hostgépen a webszerver beállítások újraolvastatására).

A hostgép webszervere számára a ~/services alatt lépezik egy katalógus könyvtár (.apache vagy .nginx néven) amelyben az egyes [service]/configs/ alatti webszerver konfigurációkra mutató (scripttel létrehozott) symlinkek találhatóak. A reverse proxy webszerver ezt a katalógus könyvtárat include-olja, így szerez tudomást az egyes webszolgáltatások egyéni konfigurációiról.

A webalkalmazások virtualhostjainak SSL tanúsítványait (magánkulcsaikkal együtt) a configs/acme illetve configs/certs könyvtárak tartalmazhatják. Amennyiben a virtualhost alkalmas CertBot-jellegű automatikus tanúsítványfenntartásra, annak egyszeri (scriptelt) igénylését követően azt a docker-skeleton automatikusan képes frissíteni, fenntartani. Ezek a tanúsítványok kerülnek a configs/acme könyvtárba. A manuálisan telepített és fenntartott tanúsítványok javasolt helye a config/certs könyvtár - az itt elhelyezett tanúsítványok érvényességét a docker-skeleton naponta ellenőrzi és lejáratuk előtt figyelmeztetést küld. Amennyiben biztonsági, vagy egyéb okból a tanúsítványokat mégsem itt (hanem pl. a szervergép /etc/ssl könyvtára alatt) szeretnénk elhelyezni, javasolt a releváns tanúsítványt a config/certs-be symlinkelni, hogy a lejárati ellenőrzés megmaradjon.

Mind a konfigurációk, mind a tanúsítványok kezdeti beolvasását a host webszervere root-ként végzi, ezért ezen állományok a dockeradmin tulajdonában maradhatnak.

Az egyes webszolgáltatások virtualhostjaira vonatkozó webnaplókat a reverse proxy webszerver szolgáltatás a logs/web könyvtárba írja. Ez a tárhely a dockeradmin számára is írható-olvasható, így a karbantartási feladatok el tudják végezni a naplók rotálását (alapértelmezésben naponta rotálva és tömörítve, 60 nap megőrzésével).

Karbantartási funkciók

A docker-skeleton framework rendelkezik a teljes Docker hostra kiterjedő, illetve az egyes szolgáltatásokon külön-külön használható karbantartási funkciókkal. Ezek a funkciók alapértelmezésben automatikusak (a dockeradmin Linux felhasználó crontab-jából indítottak), de dockeradmin felhasználóként belépve parancssorból manuálisan is elindíthatóak.

Az automatikus karbantartási funkciókat a dockeradmin Linux felhasználó crontab-ja indítja az alábbi híváslánc szerint:

 crontab
 
   ~/bin/maintenance_midnight                          alapértelmezésben minden nap 00:01
     [service]/tools/maintenance_midnight
       [service]/tools/rotate-logs                       Docker- és webnaplók rotálása
 
   ~/bin/maintenance_daily                             alapértelmezésben minden nap 04:00
     [service]/tools/maintenance_daily
       [service]/tools/acme
         ~/bin/acme.sh [service parameters]              SSL webtanúsítvány automatikus frissítése
       [service]/tools/backup
         [service]/tools/configs_backup.sh               konfigurációs állományok tar.gz mentése
         [service]/tools/backup.d/*.sh                   a receptben meghatározott egyéb mentések
       ~/bin/rotate_folder [service parameters]          mentésállományok rotálása
 
   ~/bin/maintenance_reboot                            a szervergép (újra)indításakor
     [service]/tools/maintenance_reboot
       [service]/tools/startup.d/110-startlogs.sh        a Docker naplók elindítása

maintenance_midnight

A teljes Docker hostra kiterjedő, alapértelmezésben 00:01-kor elindított karbantartás. Lefuttatja az egyes szolgáltatások tools/maintenance_midnight scriptjét a szolgáltatások könyvtára szerint betűrendben, egy-egy indítás között alapértelmezésben 60 másodperc türelmi idővel. A szolgáltatásonkénti azonos nevű karbantartó script a szolgáltatás tools/rotate_logs scriptjének meghívásával gondoskodik az aktív (futó) szolgáltatáshoz tartozó Docker- és webnaplók rotálásáról. Nem aktív szolgáltatás naplói nem rotálódnak.

maintenance_daily

A teljes Docker hostra kiterjedő, alapértelmezésben 04:00-kor elindított karbantartás.

Első lépésként összeállít, és a karbantartást futtató Linux felhasználónak elküld egy emailt (napi jelentés), amelyben többek között a hostgép tárterület-foglaltságáról és a Linux disztribúció várakozó csomagfrissítéseiről szerepel tájékoztatás. Ezt az emailt a ~.forward állomány megfelelő beállításával irányíthatjuk létező email címekre. Amennyiben az email küldés az adott hostgépen nem telepített vagy nem biztosított, a ~/bin/mail (fake mailer) scriptre futtatási jogot adva elkerülhető a sikertelen levélküldési kísérlet okozta hibaüzenet.

A levélküldési kísérlet után a karbantartás lefuttatja az egyes szolgáltatások tools/maintenance_daily scriptjét a szolgáltatások könyvtára szerint betűrendben, egy-egy indítás között alapértelmezésben 120 másodperc türelmi idővel. A szolgáltatásonkénti azonos nevű karbantartó script a következő feladatokat látja el:

• webszolgáltatás esetén az SSL tanúsítvány automatikus frissítése

Amennyiben a tools/acme script létezik és futtatható, azt elindítja. Ez a script a ~/bin/acme.sh Certbot variáns hívásával ellenőrzi, és szükség esetén automatikusan frissíti a webszolgáltatáshoz tartozó, a szolgáltatás configs/acme könyvtára alatt található SSL tanúsítványát. Ha ilyen tanúsítvány nem létezik, ez a lépés nem csinál semmit.

• a napi mentés elkészítése

A napi mentés elkészítése a tools/backup.d/*.sh scriptek betűrendben történő, egymás utáni lefuttatásával történik. Ebben a könyvtárban alapértelmezésben egyetlen script szerepel (configs_backup.sh), amely a docker-compose.yml, configs és docker könyvtárak tartalmát menti (az esetleges szimbolikus linkek feloldásával) a storage/backups/tarball alatt létrejövő, egyedi nevű .tgz tömörítvénybe. A használt recept általában tartalmaz további mentő scripteket (adatbázis dump, web tárterület, stb.) amelyek eredménye ugyancsak a storage/backups alatti könyvtárszerkezetbe kerül.

• a mentésállományok rotálása

A mentésállományok rotálása a ~/bin/rotate_folder script egyenkénti, paraméterezett hívásával valósul meg a storage/backups alatti könyvtárakra. csak azok a könyvtártartalmak rotálódnak, amely könyvtárak tartalmaznak .rotate_folder elnevezésű konfigurációs állományt. Ebben az állományban lehet meghatározni a megtartandó állományok körét. Az alapértelmezett rotálás megtartja az elmúlt 7 napban keletkezett valamennyi állományt, az előtte lévő 4 hétből heti egy-egy állományt (a legrégebbieket), illetve az előtte lévő 11 hónapból havi 1-1- állományt (ugyancsak a legrégebbieket). Ez a lépés nem fut le, ha a szolgáltatás nem fut (nem aktív).

maintenance_reboot

A teljes Docker hostra kiterjedő, a szervergép (újra)indításakor lefutó karbantartás.

A szervergép újraindításakor az always, illetve unless-stopped policyvel definiált konténerek automatikusan elindulnak, azonban ez az indulás nem scriptelt (nem futnak le a [service]/tools/startup.d/* scriptek), így az érintett konténerek logjai nem irányítódnak át a [service]/logs alatti fájlokba. Ennek pótlására ez a karbantartás meghívja minden szolgáltatás [service]/tools/startup.d/110-startlogs.sh scriptjét, amely ellenőrzi, hogy a szolgáltatás fut-e, és ha igen, elvégzi a logok átirányítását.

Műveletek

Szolgáltatás telepítése recept alapján

Új szolgáltatás telepítését a Docker hostra dockeradmin felhasználóként belépve végezzük.

Fájlműveletek

• Töltsük le a docker-skeleton legfrissebb változatát a ~/tmp könyvtárba, és tömörítsük ki:

cd ~/tmp
wget https://gitea.marcusconsulting.hu/marcusconsulting/docker-skeleton/archive/master.tar.gz -O docker-skeleton-$(date '+%Y%m%d').tar.gz
tar xzf docker-skeleton-$(date '+%Y%m%d').tar.gz  # => ~/tmp/docker-skeleton

• Futtassuk le a skeleton gyökerében található setpermissions.sh scriptet, amely helyreállítja a jogosultságokat, a fájlok dátum-és idő adatait, valamint törli a felesleges (.gitignore, stb.) fájlokat. Futtatás után ez a script is törölhető:

cd docker-skeleton
/bin/bash setpermissions.sh
rm .metadata README.md setpermissions.sh

• Hozzunk létre egy új szolgáltatáskönyvtárat a ~/services alatt, és másoljuk a skeleton tartalmát a .recipes és .utils kivételével ebbe a könyvtárba (azért másolunk, és nem mozgatunk, hogy érvényesüljenek a services-re beállított, öröklődő ACL-ek). A könyvtár neve egyben a komponált Docker szolgáltatás neve is lesz, ezért ügyeljünk arra, hogy ne használjunk a könytárnévben ékezeteket, írásjeleket (beleértve a pontot), egzotikus karaktereket, illetve kötőjelet sem. Javasolt séma: alkalmazás_webhelynév, pl. wordpress_mysite:

newservice='myapp_mysite'
mkdir ~/services/$newservice
rsync -a --exclude=".recipes" --exclude=".utils" . ~/services/$newservice

• Válasszuk ki a kívánt receptet - lépjünk be a .recipes/[recept] könyvtárba, és tartalmával egészítsük ki az imént létrehozott szolgáltatás könyvtárat:

cd .recipes/wordpress_mariadb  # Csak példa, a megfelelő receptet használjuk :)
rsync -a --exclude="README.md" . ~/services/$newservice

Ezzel a szükséges fájlmásolásokat elvégeztük. A ~/tmp/docker-skeleton könyvtárat tetszés szerint törölhetjük, vagy megtarthatjuk.

A reverse web proxy beállítása

Amennyiben webszolgáltatást telepítünk, érdemes már most beállítanunk a rá mutató reverse web proxy szolgáltatást a host szervergépen. Ehhez szükségünk van egy (vagy több), a szervergépre mutató DNS rekordra (ennek hiányában csak hosts fájllal konfigurált klienseknek fogunk tudni szolgáltatni).

nginx beállítása

A konfiguráláshoz lépjünk be a ~/services/[service] könyvtárba, és szerkesszük meg a tools/customize_nginx.sh állomány alábbi sorait:

PAR_SERVICENAME="myapp_mysite"
PAR_PROXYHOST="localhost"
PAR_PROXYPORT="8201"
PAR_SERVERNAME="mysite.example.com"
PAR_LOCATION=
PAR_WEBMASTER="webmaster@example.com"  # Valid support email address

ahol

• PAR_SERVICENAME kötelezően egyezzen meg a [service] könyvtár nevével;
• PAR_PROXYHOST maradjon localhost;
• PAR_PROXYPORT helyére a házirend szerint válasszuk a szervergépen a 8201-től kezdve első, még nem használt szabad portot - a dockerezett alkalmazás szolgáltató portját erre a külső portra kell exponálni;
• PAR_SERVERNAME az nginx virtualhost neve, egyezzen meg a webszolgáltatásra mutató (valamelyik) DNS névvel;
• PAR_LOCATION az webszolgáltatás URL-jének alkönyvtár része (context - pl. /nextcloud) - ha a webszolgáltatás a gyökér contextben fut, hagyjuk üresen;
• PAR_WEBMASTER a szerverhiba esetén megjelenő tájékoztató oldalon szereplő hibabejelentő e-mail cím.

Ha elkészültünk, futtassuk le a paraméterezett állományt:

/bin/bash customize_nginx.sh

amely létre fogja hozni a configs/nginx.conf állományt, és az erre mutató ~/services/.nginx/[service].conf symlinket, publikálva ezzel a létrehozott konfigurációt a hostgép reverse proxy webszervere számára. Amennyiben szükséges, a létrehozott configs/nginx.conf állományt manuálisan megszerkeszthetjük, pl. több rámutató DNS hostnév esetén azokat felvehetjük a server_name direktívába:

    ...
    server_name mysite.example.com
           myothersite.example.com;
    ...

Ha elkészültünk, ellenőriztessük és érvényesítsük a konfigurációt:

sudo nginx -t                # szintaktikai ellenőrzés
sudo systemctl reload nginx  # módosítások érvényesítése

A fenti parancsok a dockeradmin-tól nem fognak sudo jelszót kérni.

Ezzel a HTTP webszolgáltatást beállítottuk. Gyorstesztként a szervergépet http kapcsolaton elérni képes eszközön, böngészőprogrammal megtekintve a szolgáltatásra mutató bármelyik URL-t, a reverse proxy webszervertől a virtualhost konfigurációjában a @proxy_error location-ben definiált üzenetet fogjuk kapni:

Sorry something went wrong. Try again a bit later.
You may report this at webmaster@example.com.

A lekérések a logs/web/access.log és log/web/error.log naplókban is megjelennek.

Apache beállítása

TODO!

SSL tanúsítás

HTTPs webszolgáltatás esetén a szükséges tanúsítvány(ok) kezelését intézhetjük a docker-skeleton frameworkön kívül, vagy rábízhatjuk annak kezelését a frameworkre.

Tanúsítás a framework közreműködése nélkül

Ha a tanúsítványt a framework közreműködése nélkül szereztük meg, a PEM (Base64/ASCII) formátumú tanúsítványt és annak magánkulcsát elhelyezhetjük a szervergép /etc/ssl/certs illetve /etc/ssl/private könyvtáraiban (Debian/Ubuntu alapértelmezés, ehhez root jogosultság kell), vagy tárolhatjuk a szolgáltatás config/certs könyvtárában, pl. az alábbi (javasolt) elrendezésben:

service_base                      a szolgáltatás alapkönyvtára
  configs                         konfigurációs állományok
    certs                         nem automatikusan frissített SSL tanúsítványok könyvtára
      mysite.example.com          a virtualhosthoz tartozó tanúsítványok könyvtára
        fullchain.cer             Base64/ASCII formátumú tanúsítványlánc 
        mysite.example.com.cer    Base64/ASCII formátumú tanúsítvány
        mysite.example.com.key    Base64/ASCII formátumú magánkulcs

ahol a fullchain.cer állomány a tanúsítványhoz konkatenálva tartalmazza az esetleges köztes (intermediate) tanúsítványokat is.

A fenti elrendezés használata esetén a HTTPs engedélyezéséhez és a tanúsítvány figyelembe vételéhez nginx használata esetén a configs/nginx.conf állományban az alábbi sorok elől távolítsuk el a kommentezést:

server {
    ...
    listen 443 ssl;
    ...
    # For a (possibly symlinked) static certificate.
    ssl_certificate     /srv/docker/services/myapp_mysite/configs/certs/mysite.example.com/fullchain.cer;
    ssl_certificate_key /srv/docker/services/myapp_mysite/configs/certs/mysite.example.com/mysite.example.com.key;
    ...

A sablonból létrehozott konfigurációs állományban alapértelmezetten a fenti elrendezésnek megfelelő útvonalak szerepelnek, de tetszőleges egyéb útvonalakat is megadhatunk.

Apache használata esetén TODO!

Tanúsítás a framework közreműködésével

A tanúsítványok kezelését a frameworkre bízhatjuk, ha a tanúsítandó hostnév a nagyvilág felől http kapcsolaton keresztül folyamatosan elérhető, és üzleti céljainknak a Let's Encrypt, ZeroSSL, stb. jellegű tanúsítvány megfelelő.

Tanúsításhoz a szolgáltatás alapkönyvtárában állva hívjuk meg a framework acme parancsát az alábbi minta szerinti paraméterezéssel:

./tools/acme --issue --keylength 4096 -d mysite.example.com -d myothersite.example.com --standalone --httpport 8100 --accountemail "webmaster@example.com"

ahol tetszőleges számú -d bejegyzéssel tetszőleges számú hostnevet foglaltathatunk bele ugyanabba a tanúsítványba (de * wildcardot nem használhatunk). Az accountemail-re a tanúsítványszolgáltató figyelmeztetést fog küldeni, ha a tanúsítvány automatikus meghosszabbítása valamiért sikertelen lenne, ezért ide valid email címet érdemes megadni. A paraméterek között meghatározott 8100-as TCP porti (technikai) forgalom a localhost-on belül marad, ezt a portot a külvilág felé kinyitni nem szükséges (nem szabad).

Sikeres futtatás esetén a configs alatt létrejön az alábbi könyvtárszerkezet:

service_base                      a szolgáltatás alapkönyvtára
  configs                         konfigurációs állományok
    acme                          automatikusan frissített SSL tanúsítványok könyvtára
      ca                          regisztrációs adatok a tanúsítványszolgáltatókhoz
      mysite.example.com          a virtualhosthoz tartozó tanúsítványok könyvtára
        ca.cer                    Base64/ASCII formátumú tanúsítvány(lánc)
        fullchain.cer             Base64/ASCII formátumú tanúsítványlánc 
        mysite.example.com.cer    Base64/ASCII formátumú tanúsítvány
        mysite.example.com.key    Base64/ASCII formátumú magánkulcs
        ...                       egyéb technikai állományok

Az így létrehozott tanúsítvány lejáratának figyeléséről és annak szükség szerinti periodikus megújításáról a framework maintenance_daily karbantartási feladata gondoskodik. A tanúsítványkezeléssel kapcsolatos műveletek üzenetei a webnaplókkal azonos módon kezelt és rotált logs/web/acme.log naplóba kerülnek.

A HTTPs engedélyezéséhez és a tanúsítvány figyelembe vételéhez nginx használata esetén a configs/nginx.conf állományban az alábbi sorok elől távolítsuk el a kommentezést:

server {
    ...
    listen 443 ssl;
    ...
    # For an ACME-handled certificate.
    ssl_certificate     /srv/docker/services/myapp_mysite/configs/acme/mysite.example.com/fullchain.cer;
    ssl_certificate_key /srv/docker/services/myapp_mysite/configs/acme/mysite.example.com/mysite.example.com.key;
    ...

A sablonból létrehozott konfigurációs állományban alapértelmezetten a fenti útvonalak szerepelnek, ezeket ne változtassuk meg.

Apache használata esetén TODO!

A HTTPs használatba vétele

Ha a fentiekkel elkészültünk, ellenőriztessük és érvényesítsük a konfigurációt, nginx használata esetén:

sudo nginx -t                # szintaktikai ellenőrzés
sudo systemctl reload nginx  # módosítások érvényesítése

Apache használata esetén:

sudo apachectl -t               # szintaktikai ellenőrzés
sudo systemctl reload apache2   # módosítások érvényesítése

A fenti parancsok a dockeradmin-tól nem fognak sudo jelszót kérni.

Gyorstesztként a szervergépet https kapcsolaton elérni képes eszközön, böngészőprogrammal megtekintve a szolgáltatásra mutató bármelyik (tanúsított) URL-t, a korábban látott hibaoldalt tanúsítványhibára utaló figyelmeztetés nélkül kell megkapjuk. Sikeres teszt esetén érdemes az SSL biztonságát pl. a Qualis szolgáltatásával ellenőriztetni (A-t kell kapnunk).

A HTTPs kényszerítése

Amennyiben nincsen nyomós ellenérvünk, érdemes az érdemi webszolgáltatást csak https-en nyújtani (a http klienseket érdemi kiszolgálás helyett már a reverse proxy webszerverben a https URL-re átirányítani).

Az átirányításhoz nginx használata esetén a configs/nginx.conf állományban távolítsuk el a kommenteket az alábbi sorok elől:

    # Forced redirect to https.
    if ($scheme = http) {
        return 301 https://$host$request_uri;
    }

Ellenőriztessük és érvényesítsük a konfigurációt:

sudo nginx -t                # szintaktikai ellenőrzés
sudo systemctl reload nginx  # módosítások érvényesítése

A fenti parancsok a dockeradmin-tól nem fognak sudo jelszót kérni.

Apache használata esetén TODO!

Ellenőriztessük és érvényesítsük a konfigurációt:

sudo apachectl -t               # szintaktikai ellenőrzés
sudo systemctl reload apache2   # módosítások érvényesítése

A fenti parancsok a dockeradmin-tól nem fognak sudo jelszót kérni.

Gyorstesztként a szervergépet http és https kapcsolaton elérni képes eszközön, böngészőprogrammal http-n elkérve a szolgáltatásra mutató bármelyik (tanúsított) URL-t, a korábban látott hibaoldalt (a háttérben lezajló böngésző redirect után) https-en kell megkapjuk.