Hogyan telepítsük a WordPress-t Docker konténerekkel Ubuntu 20.04-en

Bevezetés

WordPress az egyik legnépszerűbb tartalomkezelő rendszer (CMS) a piacon. Statisztikailag a világhálón látható összes weboldal több mint 39%-át ez működteti. Népszerű választás a bővítmények révén biztosított bővíthetősége és rugalmas sablonrendszere miatt. Lehetővé teszi a megjelenés másodpercek alatti megváltoztatását. Ráadásul az adminisztrációja a webes felületen keresztül is elvégezhető, anélkül, hogy komolyabb technikai tudásra lenne szükség.

Emellett a WordPress ingyenes és nyílt forráskódú, és egy MySQL adatbázisra épül PHP feldolgozással. Telepítheti a WordPress-t LAMP szoftvercsomagra (Linux, Apache, MySQL és PHP) vagy LEMP szoftvercsomagra (Linux, Nginx, MySQL és PHP). Azonban a szoftvercsomag beállítása minden egyes telepítéskor időigényesnek bizonyulhat.

Szerencsére a modern szoftverkézbesítési módszerek, mint például a cloud computing, Docker, valamint a Docker Compose gördülékenyebbé tették a fejlesztői élményt. Ezek az eszközök leegyszerűsítik a szoftvercsomagok beállításának folyamatát azáltal, hogy elkerülik az egyes összetevők telepítésével és konfigurálásával járó többletmunkát minden alkalommal, amikor egy alkalmazást szeretne telepíteni. Ehelyett olyan konfigurációs fájlokat ír, amelyeket a rendszer a tárolóképek letöltésére, létrehozására és Docker-konténerekben való futtatására használ, lehetővé téve az alkalmazás egyetlen paranccsal történő telepítését.

A konténerek könnyűsúlyú, virtualizált, hordozható, szoftveresen meghatározott szabványosított környezetek, amelyek lehetővé teszik a szoftver futtatását a fizikai gazdagépen futó többi szoftvertől elkülönítve. A Docker Compose lehetővé teszi több konténer kezelését és a köztük lévő kommunikáció biztosítását. Például egy alkalmazás forráskódjának és egy adatbázisnak kommunikálnia kell egymással.

Ebben az útmutatóban egy többkonténeres WordPress alkalmazást fogunk felépíteni. Egy teljes WordPress alkalmazáshoz három konténer szükséges: MySQL adatbázis, Nginx szerver és a WordPress forráskódja. Mivel a biztonság kiemelt fontosságú a modern weboldalakon, egy SSL-tanúsítványt fogunk beszerezni a Let’s Encrypt segítségével a telepítés biztosítására. Ezután beállítunk egy cron feladatot a tanúsítványok időszakos ellenőrzésére és megújítására, hogy webhelye biztonsága folyamatosan fenntartható legyen.

Előfeltételek

• Mivel ez egy gyakorlati útmutató, kezdeti operációs környezetként egy Ubuntu 20.04-es telepítéssel kell rendelkeznie. Szüksége lesz egy sudo jogosultságokkal rendelkező, nem root felhasználóra is. Itt található egy lépésről lépésre követhető útmutató az Ubuntu szerver beállításához.
• Telepítenie kell a Dockert is. Ehhez használhatja ezt az útmutatót: hogyan telepítheti és működtetheti a Dockert Ubuntu 18.04-en.
• A Docker Compose telepítése. Követheti a következő útmutató 1. lépését: Hogyan telepítsük és konfiguráljuk a Docker Compose-t Ubuntu 20.04-en.
• Egy regisztrált domain név szükséges a Let’s Encrypt TLS/SSL-tanúsítvány beszerzéséhez. Ebben az útmutatóban az example.com.
• domain nevet fogjuk használni. Állítsa be a DNS-rekordokat, hogy a forgalmat a VPS-re irányítsa. Két DNS-rekordra lesz szüksége:
  • Egy A rekord, ahol az example.com a szerver nyilvános IP-címére mutat.
  • Egy A rekord, ahol a www.example.com a szerver nyilvános IP-címére mutat.

1. lépés: A webszerver konfigurációinak meghatározása

A webszerver tárolja a weboldal fájljait, és lehetővé teszi a felhasználók számára a webalkalmazás elérését. Ezért stílszerűen az első lépésben a webszerver konfigurációját határozzuk meg. Meg fogunk határozni egy Nginx szerverkonfigurációs fájlt, amely WordPress-specifikus location blokkokat fog tartalmazni. Olyan location blokkokat is beiktatunk, amelyek a Let’s Encrypt ellenőrzési kéréseit a Certbot klienshez irányítják a tanúsítvány automatikus megújítása érdekében.

Kezdjük azzal, hogy létrehozunk egy könyvtárat a projektnek. Választhat tetszőleges könyvtárnevet. Ebben az útmutatóban a wordpress_docker nevet fogjuk használni. Írja be a következő parancsot a könyvtár létrehozásához és a belépéshez:

Ezután hozzon létre egy könyvtárat az Nginx konfigurációs fájlok tárolására a következő paranccsal:

Használja a nano szerkesztőt a fájl megnyitásához a következő paranccsal:

Ebben a fájlban alapvető direktívákat fogunk meghatározni egy Nginx szerverblokk konfigurációjához. Ezek közé tartoznak a szervernévre, a dokumentumgyökérre és a location blokkokra vonatkozó direktívák, amelyek a Certbot beépülő modul tanúsítványkéréseit, a statikus fájlokat és a PHP-feldolgozást irányítják. További információért elolvashatja a Hogyan biztosítsuk az Nginx-et Let’s Encrypt segítségével című oktatóanyagunkat. Adja hozzá a következő kódot a fájlhoz, kicserélve a example.com részt a regisztrált domain nevével:

Definiáljuk a hozzáadott szakaszokat:

• Direktívák:

  • listen: arra utasítja az Nginx-et, hogy figyeljen a 80 porton. Ez lehetővé teszi a Certbot webroot beépülő modul használatát a tanúsítványkérésekhez. Miután megszereztük az SSL-tanúsítványt, frissíteni fogjuk ezt a konfigurációt a 443.
  • server_name: ez határozza meg a domain nevet, amelyet ennek a konfigurációnak kezelnie kell. Az itt meghatározott domain névre érkező forgalom erre a konkrét szerverblokkra, és ezáltal a dokumentum root.
  • root: ez határozza meg a fenti domain névre érkező kérések gyökérkönyvtárát. Általában ez a könyvtár tartalmazza a tényleges weboldalunk fájljait. A könyvtárat a következőre állítottuk be: /var/www/html. Ez Docker csatolási pontként lesz létrehozva a konténer felépítése során. Az erre a folyamatra vonatkozó utasításokat a WordPress Dockerfile-on belül fogjuk meghatározni.
  • index: ez határozza meg azokat a fájlokat, amelyek indexként vagy belépési pontként szolgálnak a webszerver számára a kérések feldolgozásakor. Az index.php-t az index.html elé helyeztük, hogy az Nginx előnyben részesítse a index.php.

• Location blokkok:

  • location ~ /.well-known/acme-challenge: kezeli a kéréseket a well-known könyvtárba, ahová a Certbot egy ideiglenes fájlt helyez el annak ellenőrzésére, hogy a DNS a megadott domainhez arra a szerverre mutat, amelyre az SSL-tanúsítványokat kérjük. Ezért kell egy érvényes domaint megadnia ehhez a lépéshez a example.com helyett, amit ebben az útmutatóban használunk.
  • location /: fogadja az URI-kéréseket, és átadja az irányítást a WordPress index.php részére a feldolgozandó argumentumok lekéréséhez.
  • location ~ \.php$: kezeli a PHP-feldolgozást, és továbbítja a kérést a WordPress konténernek (ehhez egy későbbi lépésben határozunk meg egy konfigurációs fájlt). Itt a FastCGI protokollra jellemző konfigurációkat határoztunk meg, mivel a WordPress Docker-kép a php:fpm képen fog alapulni. Az Nginx egy független PHP-feldolgozót használ a PHP-specifikus kérésekhez. A php-fpm feldolgozót fogjuk használni, amely a php:fpm Docker-képpel érkezik.
  • location ~ /\.ht: kezeli a .htaccess fájlokat, amelyeket az Nginx nem használ. A deny all direktíva biztosítja, hogy ezek a fájlok soha ne kerüljenek kiszolgálásra a webhely látogatói számára.
  • location = /favicon.ico, location = /robots.txt: amint az a definícióban látható, ez megakadályozza a /favicon.ico és /robots.txt fájlokra irányuló kérések naplózását.
  • location ~* \.(css|gif|ico|jpeg|jpg|js|png)$: kikapcsolja a statikus fájlokra irányuló kérések naplózását, és biztosítja azok gyorsítótárazását a szerver terhelésének csökkentése érdekében.

Most már elmentheti és bezárhatja a fájlt a CTRL+X, Y, majd az ENTER gombok megnyomásával. Ezzel befejeződött az első lépés.

2. lépés: Környezeti változók meghatározása

A környezeti változók szükségesek a WordPress alkalmazás és az adatbázis közötti kommunikáció megkönnyítéséhez. Biztosítják továbbá az alkalmazásadatok tartós megőrzését is. A környezeti változók érzékeny információkat (például adatbázis-hitelesítő adatokat) és nem érzékeny információkat (például az adatbázis nevét és gazdagépét) egyaránt tartalmaznak.

Biztonsági okokból mindig jó ötlet, ha nem adunk érzékeny információkat a projekt tárhelyeihez. Ezért ahelyett, hogy az érzékeny értékeket a Docker Compose fájlban állítanánk be, a MySQL hitelesítő adatokat a .env fájlban fogjuk meghatározni, amely nem kerül be a projekt tárhelyébe, elkerülve a nyilvános kitettség kockázatát. A projekt root ~/wordpress_docker könyvtárában nyissa meg a .env fájlt:

Adja hozzá a következő MySQL hitelesítő adatokat a fájlhoz, frissítve azt egy Ön által választott erős jelszóval:
Először meghatároztunk egy jelszót a MySQL root adminisztrátori fiókhoz, valamint a WordPress alkalmazásunkra jellemző hitelesítő adatokat. Ha végzett, mentse el és zárja be a fájlt.

A következő dolog, amit meg kell tennie, hogy hozzáadja a .env fájlt a .gitignore és a .dockerignore fájlokhoz, hogy biztosítsa, hogy az ne kerüljön be a tárhelyeibe, illetve a Docker-képekbe.

Ez nem szükséges ehhez az útmutatóhoz, de ha a Git verziókövetővel szeretne dolgozni, írja be a következő parancsot az aktuális könyvtár git tárhelyként való inicializálásához:

Nyissa meg a .gitignore fájlt a nano segítségével:

Adja hozzá a következő sort:

Mentse el és zárja be a fájlt. Ezután nyissa meg a .dockerignore fájlt a nano segítségével:

Adja hozzá a következő sort:

Miközben ezt teszi, opcionálisan hozzáadhat más, az alkalmazás fejlesztéséhez kapcsolódó fájlokat és könyvtárakat is:

Ha végzett, mentse el és zárja be a fájlt. Ezzel a lépéssel megvagyunk. Lépjünk tovább a Docker Compose definícióra.

3. lépés: Szolgáltatások konfigurálása a Docker Compose segítségével

A Docker Compose egy docker-compose.yml fájlt használ a lemezképek felépítéséhez. Ez a fájl tartalmazza a szolgáltatásdefiníciókat egy alkalmazás teljes beállításához. A szolgáltatásdefiníciók alapvetően utasítások arra vonatkozóan, hogyan fog futni egy konténer. A szolgáltatás egy ténylegesen futó konténer.

A Docker Compose lehetővé teszi különböző szolgáltatások meghatározását többkonténeres alkalmazásokhoz azáltal, hogy a különböző szolgáltatásokat megosztott hálózatokkal és kötetekkel kapcsolja össze. Ezt működés közben is láthatja majd, mivel három konténert fogunk meghatározni az alkalmazásunkhoz: webszervert, WordPress telepítést és adatbázist. Hozzáadunk egy negyedik konténert is a Certbot kliens futtatásához a tanúsítványok megújításához.

Írja be a következő parancsot a docker-compose.yml fájl létrehozásához:

Az első sor egy docker-compose.yml fájlban a verziódefiníciós sor. A miénkhez a 3-as értéket állítottuk be. Ezután elkezdheti meghatározni a szolgáltatásait. Adja hozzá a következő kódrészletet a fájlhoz a db szolgáltatás meghatározásához:

Beszéljük meg, mi szerepel a db szolgáltatásdefiníciókban az alábbiakban:

• image: meghatározza azt a lemezképet, amelyen a konténer alapulni fog. Mindig jobb egy konkrét verziót megadni (mysql:8.0), mint a legfrissebb (latest) címkét használni (mysql:latest), mivel a MySQL lemezképek jövőbeli verziói ütközhetnek az alkalmazásunkkal, ha esetleg újraépítjük ezt a lemezképet. További információt talál a Docker-fájlok legjobb gyakorlatairól a hivatalos Dockerfile dokumentációban.
• container_name: itt adjuk meg a konténer nevét.
• restart: ez az irányelv határozza meg a konténer újraindítási viselkedését. Az alapértelmezett érték a no, de mi úgy állítottuk be, hogy mindig újrainduljon, kivéve ha manuálisan leállítják.
• env_file: ez az irányelv az alkalmazásunk által használt környezeti változókat tartalmazó fájl (.env) helyének megadására szolgál.
• environment: további környezeti változók megadására szolgál. Ebben az útmutatóban a MYSQL_DATABASE változót adtuk meg az alkalmazásunk adatbázisnevének tárolására. Az adatbázis neve szerepelhet a docker-compose.yml.
• volumes: a csatolási helyek megadására szolgál. Példánkban egy kötetet csatoltunk dbdata néven a /var/lib/mysql könyvtárhoz, amely általában a MySQL szabványos adatkönyvtára.
• command: ez az irányelv egy olyan parancsot határoz meg, amely felülírja a lemezkép alapértelmezett CMD utasítását. Hozzáadtunk egy opciót a Docker-lemezkép szabványos mysqld parancsához, amely elindítja a MySQL szervert a konténeren belül. Az általunk hozzáadott opció a --default-authentication-plugin=mysql_native_password, amely frissíti a MySQL alapértelmezett hitelesítési bővítményét jelszavas hitelesítés használatára (mysql_native_password). Ez szükséges a PHP (WordPress) alkalmazás működéséhez, mivel felhasználónevet és jelszót használnak az adatbázis eléréséhez. Az újabb MySQL-verziókban az alapértelmezett hitelesítési bővítmény megváltozott. A legtöbb alkalmazás azonban jelszavas hitelesítést használ. Ezért ezt a beállítást meg kell változtatnia az alkalmazás működéséhez.
• networks: ez az irányelv arra szolgál, hogy meghatározza, hogy a db szolgáltatásnak csatlakoznia kell az app-network hálózathoz, amelyet az útmutató során fogunk meghatározni.

Ezután határozzuk meg a WordPress alkalmazásunk szolgáltatáskonfigurációját. A szolgáltatást és a container_name-et a következőképpen fogjuk nevezni: app. Adja hozzá a következő kódrészletet a db szolgáltatásdefiníció alá, ügyelve a megfelelő behúzásra:

Hasonlóan ahhoz, ahogy a db szolgáltatás esetében tettük, elneveztük a konténerünket, és meghatároztuk az újraindítási szabályzatot. Az alábbiakban bemutatunk néhány további hozzáadott opciót:

• depends_on: ez az utasítás biztosítja, hogy a konténerek a függőségi sorrendnek megfelelően induljanak el. A mi esetünkben az app konténer a db konténertől függ. Ezért a db konténer elindulása után fog elindulni. Ennek ebben a sorrendben kell történnie, mivel a WordPress alkalmazás működése a MySQL adatbázis elérhetőségétől függ.
• image: amint az a kódrészletben látható, a WordPress 5.1.1 fpm verziójú alpine képet fogjuk használni. Korábban már beszéltünk a php-fpm processzorról, amelyre az Nginx-nek szüksége van a PHP feldolgozásához. Ez a kép gondoskodik erről. Az Alpine Linux projekten alapuló alpine kép segít kisebb méretűnek megtartani a képet. Ha további információra van szüksége a képváltozatokról, kövesse ezt a linket a Docker Hub Wordpress képekhez.
• env_file: megadja a .env fájl helyét, amely az adatbázis hitelesítő adatait tartalmazza.
• environment: ez az utasítás további környezeti változókat határoz meg. A mi esetünkben a WordPress által elvárt változókat határozzuk meg, és hozzárendeljük hozzájuk a .env fájlunkban található változók értékeit. Ezek a következők: WORDPRESS_DB_USER, WORDPRESS_DB_PASSWORD és a WORDPRESS_DB_HOST, amely a db konténeren futó MySQL szerverre utal, amely a MySQL alapértelmezett portjáról érhető el3306. Végül látható a WORDPRESS_DB_NAME, amelyet WordPress-re állítottunk be. Ugyanez az érték van megadva a db konténer MySQL szolgáltatásdefiníciójában is: MYSQL_DATABASE=wordpress.
• volumes: ez az utasítás egy app nevű kötetet csatol a /var/www/html csatolási ponthoz, amelyet a WordPress kép hozott létre. A kötetek elnevezése lehetővé teszi az alkalmazáskód megosztását más konténerekkel.
• networks: végül hozzáadjuk az app konténert az app-network hálózathoz, hogy biztosítsuk a kommunikációt a hálózat többi konténerével.

Ez minden az app szolgáltatáskonténerhez a WordPress kép esetében. Most határozzuk meg a webserver szolgáltatást az Nginx képhez. Először adja hozzá a következő kódrészletet az app szolgáltatásdefiníció alá a docker-compose.yml fájlban:

Már elmagyaráztuk a depends_on opciót. Ennek a webserver szolgáltatásnak az esetében a konténer az app konténer elindulása után fog elindulni. A webszerver konténer az alpine Nginx képen alapul. Hasonló újraindítási szabályzattal rendelkezik, mint az előző szolgáltatásdefiníciók. A webserver szolgáltatásdefiníció egyéb opciói a következők:

• ports: összeköti a portokat a gazdagép és a konténer között. Az 1. lépésben a(z) 80 portot határoztuk meg az nginx.conf fájlban. Ez a port a konténer 80 portjához van hozzárendelve.
• volumes: a bind mountok és a nevesített kötetek (named volumes) kombinációja található ezen opció alatt:
  • app:/var/www/html: ez a kötetdefiníció a WordPress alkalmazást a /var/www/html könyvtárba csatolja, amelyet korábban gyökérkönyvtárként (root) állítottunk be az Nginx szerverblokkban.
  • ./nginx-conf:/etc/nginx/conf.d: ez a definíció a gazdagép Nginx konfigurációs könyvtárát csatolja (bind mount) a konténerhez meghatározott Nginx konfigurációs könyvtárhoz. Így a gazdagépen végzett bármilyen módosítás automatikusan megjelenik a konténerben is.
  • certbot-etc:/etc/letsencrypt: ez a definíció a domain Let’s Encrypt tanúsítványait és kulcsait csatolja a konténer megfelelő könyvtárába.
• networks: az előző szolgáltatásdefiníciókhoz hasonlóan a networks direktíva hozzáadja a webserver szolgáltatást a app-networks.

Mivel végeztünk a webserver definíciójával, adjuk hozzá a Certbot szolgáltatásra vonatkozó utasításokat. Ez fogja kezelni a TLS/SSL tanúsítványok beszerzését a Let’s Encrypt-től. Ha többet szeretne megtudni az Nginx szerver biztonságossá tételéről, ez az hogyan tegyük biztonságossá az Nginx-et Let’s Encrypt segítségével útmutató jó forrás.

Ezután adja hozzá a következő kódrészletet a webserver szolgáltatás alá. Ne felejtse el beállítani a helyes domain nevet és e-mail címet:

A(z) certbot képfájl (image) csak azután indul el, miután a(z) webserver elindult, a(z) depends_on direktíva miatt. A Docker Compose le fogja tölteni a Certbot képfájlt a Docker Hubról a meghatározottak szerint.

A volumes definíció alatt a Certbot konténer megosztja a domain tanúsítványait és kulcsát a(z) certbot-etc könyvtárban az Nginx webserver konténerrel, az alkalmazás kódját pedig a(z) app konténerrel.

A(z) command definíció alatt megadtunk egy alkonstrukciót a konténer alapértelmezett Certbot certonly parancsának futtatásához az alábbiakban felsorolt további opciókkal:

• • --webroot: a webroot beépülő modul használatát írja elő, amely a hitelesítéshez szükséges fájlokat a webroot mappába helyezi.
  • --webroot-path: a webroot könyvtár elérési útját határozza meg.
  • --agree-tos: azt jelzi, hogy elfogadja az ACME szolgáltatási feltételeit.
  • --no-eff-email: azt jelzi, hogy nem szeretné megosztani az e-mail címét az EFF szervezettel. Ezt elhagyhatja, ha meg szeretné osztani.
  • --staging: jelzi a Certbotnak, hogy először teszt tanúsítványokat szeretne beszerezni a Let’s Encrypt staging (teszt) környezetéből a konfiguráció teszteléséhez a tényleges tanúsítvány beszerzése előtt. A Let’s Encrypt domain-kérelmekre vonatkozó gyakorisági korlátozással (rate limiting) rendelkezik. Ezért a konfiguráció előzetes tesztelése segít elkerülni a domain korlátozását.
  • -d: ez az opció a tanúsítványkérelemhez tartozó domain neveket fogadja el. Ebben az útmutatóban a(z) example.com és a(z) www.example.com domaineket adtuk meg. Kérjük, adja meg a saját, ténylegesen regisztrált domainjét.

A docker-compose.yml fájlunk már majdnem kész. Azonban a hálózati és kötetdefiníciókat is hozzá kell adnia a Certbot szolgáltatás alá:

A(z) volumes kulcs határozza meg azokat a köteteket, amelyeket meg kell osztani az ebben a compose fájlban meghatározott összes szolgáltatással (konténerrel): certbot-etc, app, és dbdata. A Docker által létrehozott kötetek tartalma a gazdagép fájlrendszerén egy Docker által kezelt könyvtárban tárolódik: /var/lib/docker/volumes/. Az egyes kötetek tartalma ezután csatolásra kerül minden olyan konténerhez, amely használja az adott kötetet. Ez lehetővé teszi az adatok és a kód megosztását a konténerek között.

A networks kulcs határozza meg azt a bridge hálózatot, amely lehetővé teszi a konténerek közötti kommunikációt. Az azonos bridge hálózaton lévő konténerek, mint például a(z) webserver és a(z) db biztonságosan tudnak kommunikálni portokon keresztül anélkül, hogy a forgalmat kitennék a külső hálózatnak. Csak a(z) 80 portot tesszük elérhetővé, hogy hozzáférést biztosítsunk a front-end weboldal oldalaihoz.

A teljes docker-compose.yml fájl így fog kinézni:

Mentheti és bezárhatja a fájlt. A következő lépésben elindítjuk és teszteljük a konténert és a tanúsítványkérelmeket.

4. lépés: A konténerek futtatása és az SSL-tanúsítványok beszerzése

A Docker Compose legnagyobb előnye, hogy miután meghatározta az összes szolgáltatást a(z) docker-compose.yml fájllal az összes konténert elindíthatja egyetlen paranccsal: docker-compose up. A parancs minden megadott utasítást végrehajt. Ha a tartományi kérelmek sikeresek, a terminálban a megfelelő kilépési állapotot kell látnia. Írja be a következő parancsot a konténerek létrehozásához. A -d jelző a konténerek háttérben történő futtatására szolgál:

Ha az alábbi képernyőképen látható kimenetet látja, akkor a szolgáltatások sikeresen létrejöttek:

A szolgáltatások állapotának ellenőrzéséhez futtassa a docker-compose ps parancsot:

A parancs kimenete az alábbiak szerint alakul, ha minden sikeres volt. Az app, db, és webserver konténerek állapotának futnia kell (up), a certbot konténernek pedig Exit0 állapottal kell rendelkeznie:

Ha a(z) Up értéktől eltérőt lát az állapot oszlopban a(z) app, db vagy webserver, konténereknél, vagy nem Exit kilépési állapotot, ami nem 0 a(z) certbot konténernél, akkor valami hiba történt. Az egyes konténerek naplóit a docker-compose logs paranccsal ellenőrizheti, megadva a service_name:

Például a certbot konténer naplóit a következő parancs beírásával ellenőrizheti:

Annak ellenőrzéséhez, hogy a tanúsítványok fel lettek-e csatolva a webserver konténerbe, használja a docker-compose exec parancsot:

Ha a(z) example.com helyett egy ténylegesen regisztrált tartománynevet használt, és a tanúsítványkérelmek sikeresek voltak, a következőhöz hasonló kimenetet kell látnia:

Miután megbizonyosodott arról, hogy a tanúsítványkérelem sikeres volt, szerkesztheti a docker-compose.yml fájlt, és eltávolíthatja a --staging jelzőt. Nyissa meg a fájlt a nano:

Görgessen le a Certbot szolgáltatásdefiníciós szakaszához a command opciónál, és cserélje ki a --staging jelzőt a --force-renewal jelzőre. Ez jelzi a Certbotnak, hogy az adott tartományhoz tartozó tanúsítvány megújítását kéri. A Certbot szolgáltatásdefiníciójának most így kell kinéznie:

Mentse el a fájlt, ha végzett a szerkesztéssel.

Írja be a következő parancsot a certbot konténer újralétrehozásához. A megadott --no-deps jelző arra utasítja a Compose-t, hogy hagyja ki a webszerver szolgáltatás újraindítását, mivel az már fut:

A parancs kimenete a következő képernyőképen látható, ami azt mutatja, hogy a tanúsítványkérelem sikeres volt:

Ez minden ehhez a lépéshez. A következő lépésben módosítani fogja az Nginx konfigurációs fájlját az SSL-tanúsítvány hozzáadásához.

5. lépés: Az SSL engedélyezése az Nginx konfigurációban és szolgáltatásdefinícióban

Ahhoz, hogy az Nginx biztonságos SSL-en keresztül szolgálja ki a forgalmat, először módosítania kell az Nginx konfigurációs fájlját egy HTTP átirányítás hozzáadásához a HTTPS-re. Ezután meg kell adnia a tanúsítvány és a kulcs helyét, végül pedig hozzá kell adnia a biztonsági paramétereket és fejléceket.

A konfigurációs fájl módosítása előtt be kell szereznie az recommended Nginx security parameters a Certbot GitHub-tárhelyéről a curl használatával, a következő paranccsal:

https://raw.githubusercontent.com/certbot/certbot/master/certbot-nginx/certbot_nginx/_internal/tls_configs/options-ssl-nginx.conf

A parancs lefut, és az általa lekért paramétereket egy options-ssl-nginx.conf nevű fájlba menti, a(z) nginx-conf könyvtáron belül. Távolítsa el az Nginx konfigurációs fájlt, hogy létrehozhassunk egy újat a következő parancsokkal:

Az immár üres nginx.conf fájlba adja hozzá a következő kódot, amely tartalmaz egy átirányítást a(z) HTTP protokollról a(z) HTTPS, SSL hitelesítési protokollokra, valamint biztonsági fejléceket. Ahogy korábban is tette, cserélje ki az example.com domaint a saját regisztrált domainjére:

Az első szerverblokkban, amely a nem biztonságos kéréseket kezeli a(z) 80 porton, megadjuk a webgyökeret a Certbot megújítási kérésekhez. Tartalmaz egy átirányítási direktívát is, amely átirányítja a(z) HTTP kéréseket a(z) HTTPS.

A második szerverblokk a biztonságos HTTPS forgalmat kezeli a(z) 443 porton. Amint látható, engedélyezzük az SSL-t és a HTTP2-t is. A HTTP/2 javítja a szerver teljesítményét. Erről bővebben az Nginx hivatalos HTTP/2 dokumentációjában.

olvashat. Ebben a blokkban azt is megadtuk, hogy az Nginx tartalmazza az SSL-tanúsítvány és a kulcs helyét, valamint a Certbot által javasolt biztonsági paramétereket, amelyeket a curl a(z) nginx-conf/options-ssl-nginx.conf könyvtárba mentett.

A további biztonsági fejlécek arra szolgálnak, hogy javítsák a webhely értékelését az olyan biztonsági tesztoldalakon, mint a Security Headers és a SSL Labs. A fejléceken található linkeket követve többet is megtudhat róluk: X-Frame-Options, Referrer Policy, X-Content-Type-Options, X-XSS-Protection, Content-Security-Policy. Kikommenteztük a HTTP Strict Transport Security (HSTS) fejlécet. Nyugodtan olvashat a preload (előbetöltési) funkciójáról, és eldöntheti, hogy szeretné-e engedélyezni.

A többi direktíva, mint például a root, index, és a WordPress-specifikus location blokkok megegyeznek az 1. lépésben leírtakkal. Ha végzett a szerkesztéssel, elmentheti és bezárhatja a fájlt.

Most, hogy engedélyeztük a(z) HTTPS forgalmat, amely a(z) 443, portot használja, engedélyeznünk kell ezt a portot a webszerver szolgáltatásdefiníciójában is. Írja be a következő parancsot a docker-compose.yml fájl megnyitásához a nano segítségével:

A webszerver (webserver) szakaszban a ports opció alatt adja hozzá a portleképezést a(z) 443 porthoz az alábbiak szerint kiemelve:

A teljes docker-compose.yml fájlnak most így kell kinéznie:

Miután megbizonyosodott arról, hogy minden helyesnek tűnik, mentse el és zárja be a fájlt. Ezután futtassa a következő parancsot a(z) webserver szolgáltatás újbóli létrehozásához:

A következő paranccsal ellenőrizheti, hogy a szolgáltatások futnak-e:
Az alábbi képernyőképhez hasonlót kell látnia, amely megerősíti, hogy a szolgáltatások megfelelően futnak:

Most, hogy az összes konténer fut, folytathatja a WordPress konfigurálását a webes felületről.

6. lépés: A WordPress konfigurációjának befejezése a webes felületről

A telepítés folytatásához navigáljon a szervere domain nevére. Ekkor meg kell jelennie a WordPress telepítő kezdőlapjának. Itt kiválaszthatja a nyelvet a folytatás előtt:

Válassza ki a nyelvet, majd kattintson a Folytatás gombra a következő oldalra lépéshez:

 

Ezen az oldalon adja meg a webhely címét, válasszon egy könnyen megjegyezhető felhasználónevet és egy erős jelszót. Biztonsági okokból javasoljuk, hogy ne használja az Admin nevet felhasználónévként. Adja meg az e-mail-címét, majd kattintson a WordPress telepítése gombra a WordPress telepítésének megkezdéséhez.

A telepítés befejezése után a bejelentkezési képernyőre lép, ahol meg kell adnia a beállított felhasználónevet és jelszót. Az érvényes hitelesítő adatok megadása után meg kell jelennie a WordPress vezérlőpultjának:

Sikeresen telepítette a WordPresst! Ezután meg kell tennie a szükséges lépéseket annak biztosítására, hogy az SSL-tanúsítványok automatikusan megújuljanak.

7. lépés: Az automatikus SSL-tanúsítvány-megújítás konfigurálása

A Let’s Encrypt TLS/SSL-tanúsítványok csak 90 napig érvényesek. Önnek kell létrehoznia egy automatikus megújítási konfigurációt, hogy ne járjanak le. Ezt egy szkript létrehozásával és annak a cron job segédprogrammal történő ütemezésével érheti el. Ebben a lépésben megmutatjuk, hogyan hozhat létre egy szkriptet, amely megújítja a tanúsítványokat. Ezután ütemezni fogjuk a cron job segédprogrammal, hogy rendszeresen fusson, és megújítsa a tanúsítványokat, ha közeledik a lejárati dátumuk.

A wordpress_docker projektkönyvtárban nyisson meg egy ssl_renewer.sh nevű szkriptet a nano:

Adja hozzá a következő kódot a szkripthez az automatikus megújítás és az Nginx konfiguráció újratöltésének kezeléséhez. Ne felejtse el kicserélni a kiemelt felhasználónevet a saját nem-root felhasználónevére:

Ebben a szkriptben a docker-compose binárist egy COMPOSE nevű változóhoz rendeljük. Tartalmazza továbbá a –ansi never opciót is, amely arra utasítja a szkriptet, hogy a docker-compose parancsokat ANSI vezérlőkarakterek nélkül futtassa. Továbbá a Docker binárist egy DOCKER.

nevű változóhoz rendeljük. A szkript ezután belép a wordpress_docker projektkönyvtárunkba, és végrehajtja a következő parancsokat:

• docker-compose run: elindítja a certbot konténert, és felülírja a certbot szolgáltatás definíciójában megadott parancsot. A certonly alparancs futtatása helyett a renew alparancsot futtatja, amely megújítja a Let’s Encrypt SSL/TLS-tanúsítványait, ha azok lejárni készülnek.
• docker-compose kill: egy SIGHUP jelet küld a webserver konténernek az Nginx konfigurációk újratöltéséhez. Érdemes lehet megnézni ezt a Docker-útmutatót arról, hogyan kell használni a hivatalos Nginx Docker képet.
• docker system prune: ez a parancs eltávolítja az összes használaton kívüli konténert és képet.

Mentse és zárja be a fájlt, ha végzett a szerkesztéssel. Ezután futtassa a következő parancsot, hogy futtathatóvá tegye:

Miután futtathatóvá tette, nyissa meg a root crontab fájlt, hogy a szkriptet rendszeresen futtassa az általunk megadott időközönként:

A crontab megkéri, hogy válassza ki a preferált szerkesztőt, ha most használja először:

Válassza ki a kívánt szerkesztőt, majd nyomja meg az Enter billentyűt a fájl megnyitásához. A fájl aljához adja hozzá a következő sort:

Ez öt perces időközt állít be, hogy tesztelhessük, működik-e a megújító szkriptünk. Megadtunk egy naplófájlt is, amely a feladat kimenetét fogja tárolni: cron_docker.log.

Várjon öt percet, majd ellenőrizze a cron.log annak ellenőrzéséhez, hogy a szkript sikeres volt-e a megújítási kérelemmel:

Az alábbi képernyőképhez hasonlót kell látnia, ha a kérelmek sikeresek voltak:

Most, hogy teszteltük és megerősítettük a működését, módosíthatja a crontab fájlt a napi megújítás megadásához. Például megadhatja, hogy a szkript minden nap délután 6-kor fusson le. Ehhez módosítsa a crontab utolsó sorát, hogy így nézzen ki:

Ezenkívül el kell távolítania a –dry-run jelzőt az ssl_renewer.sh szkriptből, hogy a tényleges megújítás megtörténjen a futásakor. Így kell kinéznie:

Ezután mentse el és zárja be a fájlt. Ezzel a cron feladat érvényben tartja a tanúsítványait, megújítva azokat a 90 nap lejárta előtt.

Összegzés

Ha eljutott idáig az útmutatóban, egy lépéssel közelebb érezheti magát ahhoz, hogy DevOps mérnök legyen. Sikerült létrehoznia egy Nginx konfigurációs szkriptet, létrehozott egy docker-compose.yml fájlt, és meghatározott több olyan szolgáltatást, amelyek szükségesek egy WordPress alkalmazás Docker és Docker Compose segítségével történő futtatásához. SSL/TLS tanúsítványokat szerzett be a Let’s Encrypt-től, hogy biztosítsa a webszerver biztonságát. Végül létrehozott egy cron feladatot, hogy a tanúsítványok ne járjanak le. Szép munka!

Ha szeretne mélyebben elmerülni a DevOps világában, tekintse meg a konténerekkel kapcsolatos további forrásainkat a blogunkon:

• Ismerkedés a Kubernetes-szel
• Hogyan telepítsünk egy Node.js (Express.js) alkalmazást Dockerrel Ubuntu 20.04-en
• PHP alkalmazás telepítése Kubernetes fürtre Ubuntu 18.04-en.
• Laravel, Nginx és MySQL telepítése Docker Compose segítségével

Kellemes számítástechnikát!