Django beállítása PostgreSQL, Nginx és Gunicorn használatával Ubuntu 20.04-en

Django egy ingyenes és nyílt forráskódú webes alkalmazás-keretrendszer, amely a Python programozási nyelven íródott. A Django szupergyors, biztonságos és rendkívül jól skálázható. Egy képzett fejlesztő kezében a Django gyorsan képes létrehozni egy hatékony weboldalt. Zökkenőmentesen integrálható a népszerű webszerverekkel (Apache, Nginx), és adatbázisokkal (MySQL, MariaDB, PostgreSQL, Oracle, és SQLite), stb. A Django hajtja a világ néhány legnagyobb weboldalát, mint például az Instagram, a Mozilla és a NASA. Ez az útmutató bemutatja egy webalkalmazás alapjainak beállítását a Django segítségével, PostgreSQL, Nginx és Gunicorn használatával Ubuntu 20.04-en.

Előfeltételek

Ez az útmutató feltételezi, hogy egy olyan Ubuntu 20.04 szervert futtat, amely alapvető tűzfallal és egy sudo jogosultsággal rendelkező, nem root felhasználóval van konfigurálva. Tekintse meg ezt a részletes útmutatót arról, hogyan kell beállítani egy Ubuntu szervert. Kövesse ezt az útmutatót a sudo jogosultsággal rendelkező, nem root felhasználó konfigurálásához. Továbbá konfigurálhat egy Iptables tűzfalat is az útmutató lépéseit követve.

A Djangót egy virtuális környezetben fogjuk telepíteni. A projektspecifikus környezet lehetővé teszi több projekt egyszerűbb kezelését ugyanazon a szerveren. Miután az adatbázisok és az alkalmazások a helyükre kerültek, telepíteni fogjuk a Gunicorn alkalmazásszervert. A Gunicorn lesz az az alkalmazás-interfész, amely a kliens kéréseit HTTP-ről Python-hívásokká fordítja, amelyeket az alkalmazásunk használni tud. Ezután az Nginx-et fogjuk bevetni a Gunicorn elé a gyors kapcsolatkezelési teljesítménye és a könnyen megvalósítható biztonsági funkciói miatt.

A szükséges csomagok telepítése

Első lépésként telepítse az összes szükséges csomagot. Szerencsére mindezek a csomagok közvetlenül elérhetők a hivatalos Ubuntu csomagtárolókból. Nyissa meg a terminált, és frissítse az APT csomaggyorsítótárat:

A csomaglista attól függ, hogy a webalkalmazás a Python 2-t vagy a Python 3-at fogja-e használni. Futtassa a következő parancsot a Django Python 3-mal történő telepítéséhez:

A Django 1.11 LTS a Django utolsó olyan kiadása, amely támogatja a Python 2-t. Ha a Djangót Python 2-vel szeretné használni, akkor telepítse a következő csomagokat:

PostgreSQL adatbázis és felhasználó

Ami az adatbázis-megoldást illeti, a PostgreSQL-t fogjuk használni. Ez egy nagy teljesítményű, nyílt forráskódú objektum-relációs adatbázis-rendszer. A PostgreSQL megbízhatóságot, robusztusságot és teljesítményt kínál. A PostgreSQL beállításának részletes lépéseiért tekintse meg ezt az útmutatót a PostgreSQL beállításáról az Ubuntu szerveren webhelyen. Ebben az útmutatóban egy dedikált adatbázist és felhasználót fogunk beállítani a Django alkalmazásunkhoz.

Alapértelmezés szerint a PostgreSQL a „peer hitelesítést” alkalmazza a helyi kapcsolatok hitelesítési sémájaként. Röviden, a „peer hitelesítés” akkor hitelesíti a bejelentkezést, ha a felhasználó operációs rendszerbeli felhasználóneve megegyezik egy érvényes PostgreSQL felhasználónévvel. A telepítés során a PostgreSQL beállított egy postgres nevű operációs rendszer felhasználót, amely megfelel a postgres PostgreSQL adminisztrátori felhasználónak. Jelentkezzen be az interaktív PostgreSQL shell munkamenetbe postgres felhasználóként a következő paranccsal:

A PostgreSQL parancssorba fog kerülni. Az első lépés egy dedikált adatbázis létrehozása a projekt számára. A bemutatóhoz az adatbázis neve viktor_project:

A következő lépés egy dedikált felhasználó létrehozása a projekt adatbázisához. A felhasználónak erős felhasználónévvel kell rendelkeznie. A bemutatóhoz a felhasználónév viktor_project_user:

Most módosítani fogunk néhány paramétert:

• Bizonyos kapcsolati paraméterek. Röviden: nem lesz szükség a helyes értékek lekérdezésére és beállítására minden egyes kapcsolat létrehozásakor. Ez jelentősen javítja az adatbázis teljesítményét.
• Alapértelmezett kódolás: UTF-8. Ez egy univerzális kódolás, és a Django ezt várja el.
• Alapértelmezett tranzakció-elszigetelési séma „read committed”-re. Ez blokkolja a nem véglegesített tranzakciókból való olvasást.
• Időzóna: UTC.

Mindezeket a paramétermódosításokat maga a Django projekt javasolja. A módosítások végrehajtásához futtassa a következő parancsokat. Ne felejtse el kicserélni az adatbázis-felhasználónevet a megfelelőre:

Változtassa meg az adatbázis-adminisztrátort a dedikált adatbázis-felhasználóra:

Egyelőre végeztünk a PostgreSQL-lel. Lépjen ki a PostgreSQL interaktív parancssorából:

Python virtuális környezet

Az adatbázis előkészítése után most a projekt többi követelményének kialakítására összpontosíthatunk. A könnyebb kezelhetőség érdekében létrehozunk egy virtuális környezetet, és oda telepítjük az összes Python-követelményt. A virtuális környezet létrehozásához a virtualenv-re van szükségünk. Ez könnyen telepíthető a pip segítségével.

A következő parancsok frissítik a pip-et és telepítik a virtualenv-et. Python 3 esetén futtassa a következő parancsokat:

Python 2 esetén futtassa inkább a következő parancsokat:

Miután a virtualenv telepítve van, ideje létrehozni egy virtuális környezetet. Ezután hozzon létre egy dedikált könyvtárat a virtuális környezet számára:

Ezt követően váltson át a virtuális környezet dedikált könyvtárára:

A könyvtáron belül futtassa a következő parancsot. A virtualenv eszköz létrehoz egy virtuális környezetet a projekt nevével:

Ez létrehoz egy alkönyvtárat a projekt nevével. Az alkönyvtár tartalmazni fogja a Python helyi verzióját és a pip eszközt. Ez rugalmasságot biztosít egy elkülönített Python-környezet telepítéséhez és konfigurálásához a projekt számára.

A következő parancs aktiválja a virtuális környezetet:

A terminál parancssora megváltozik, jelezve, hogy egy Python virtuális környezetben dolgozik. Most, hogy a virtuális környezetben vagyunk, telepíteni fogjuk a szükséges Python-követelményeket. Szükségünk van a Django-ra, a Gunicorn-ra és a psycopg2-re (PostgreSQL adapter). A következő parancs utasítja a helyi pip-et az összetevők telepítésére:

Még ha Python 3-at is használ, a pip a helyes parancs. Ez azért van, mert a virtuális környezeten belül a pip3 át van nevezve pip-re.

Új Django projekt

A Python-összetevők meglétével elkezdhetünk dolgozni a tényleges Django projektfájlokkal.

• Django projekt létrehozása

A projektkönyvtár már létrejött. Megmondjuk a Django-nak, hogy oda telepítse a fájljait. Ez az eljárás létrehoz egy másodszintű könyvtárat, amely a tényleges kódokat tartalmazza. A könyvtár tartalmazni fog egy kezelőszkriptet is. A lényeg az, hogy kifejezetten megadjuk a Django-nak a célkönyvtárat, ahelyett, hogy hagynánk, hogy az aktuálishoz képest határozza meg azt:

A Django ennek megfelelően hozza majd létre a projektet. Íme néhány fontos fájl és könyvtár, amelyekre összpontosítani fogunk. A könyvtár- és fájlnevek a bemutatónak megfelelően kerülnek felhasználásra.

• ~/viktor_project/manage.py: A Django projektkezelő szkriptje.
• ~/viktor_project/viktor_project/: Ez a Django projektet tartalmazó csomag. Tartalmaznia kell a __init__.py, settings.py, urls.py, asgi.py és wsgi.py fájlokat.

• Projektbeállítások módosítása

A projekt létrehozása után az első dolog a konfiguráció módosítása. Nyissa meg a settings.py fájlt egy szövegszerkesztőben:

Az első direktíva, amit keresünk, az ALLOWED_HOSTS. Ez határozza meg azokat a szervereket vagy domain neveket, amelyek csatlakozhatnak a Django példányhoz. Ha bármely bejövő kérés, amely Host fejléccel rendelkezik, nem egyezik az ALLOWED_HOSTS listájával, az kivételt fog generálni. A Django ezt javasolja bizonyos típusú biztonsági sebezhetőségek elkerülése érdekében:

A következő szakasz, amire összpontosítani fogunk, a DATABASE. Ez kezeli az adatbázis-hozzáférést. Alapértelmezés szerint az SQLite adatbázis-motor konfigurációját tartalmazza. Mi azonban a PostgreSQL adatbázist fogjuk használni a projekthez. A Django a psycopg2 adaptert fogja használni a PostgreSQL-lel való kommunikációhoz:

Most lépjen a fájl aljára. Adja hozzá a következő sorokat a statikus fájlok helyének megadásához. Ez segít az Nginx-nek kezelni az ezekre az elemekre vonatkozó kéréseket:

A munkánk a settings.py fájllal egyelőre véget ért. Mentse el a fájlt, és zárja be a szerkesztőt.

• A projekt kezdeti beállításának véglegesítése

Most már migrálhatjuk a kezdeti adatbázis-sémát a dedikált PostgreSQL adatbázisba. Futtassa a következő parancsot:

Ezután létre kell hoznunk egy szuperfelhasználót (superuser) a projekthez. A szuperfelhasználó létrehozásához futtassa a következő parancsot:

Gyűjtse össze az összes statikus fájlt a settings.py fájlban megadott helyre. A statikus fájlok egy külön, „static” nevű könyvtárba kerülnek a projekt könyvtárában:

Most pedig foglalkoznunk kell a szerver tűzfalával. Ha követte a szerverkonfigurációs útmutatót, akkor az UFW már be van állítva és aktiválva van. Létrehozunk egy kivételt a 8000-es porthoz. Ez az az alapértelmezett port, amelyet a Django használ. Tekintse meg ezt az útmutatót, ha többet szeretne megtudni az UFW tűzfal alapjairól és használatáról.

Ezután ellenőrizze a műveletet:

Végül tesztelhetjük a szervert működés közben. Indítsa el a Django fejlesztői szervert:

Ha a konfiguráció sikeres volt, a Django fejlesztői szervernek el kell indulnia, és fogadnia kell a bejövő kéréseket. Nyisson meg egy böngészőt, és lépjen a szerver IP-címére/domainjére a 8000-es porton:

A Django alapértelmezett kezdőlapjára kell érkeznie. Az adminisztrációs panel eléréséhez fűzze az /admin részt az URL végére. Az adminisztrációs panelhez csak az előzetesen létrehozott szuperfelhasználó férhet hozzá:

Bejelentkezés után az alapértelmezett Django adminisztrációs felületre érkezik:

Egyelőre végeztünk a teszteléssel. A szerver leállításához nyomja meg a „Ctrl + C” billentyűkombinációt a terminálablakban.

• A Gunicorn tesztelése

Mielőtt elhagynánk a virtuális környezetet, meg akarunk bizonyosodni arról, hogy a Gunicorn képes kiszolgálni az alkalmazásokat. Ennek teszteléséhez a Gunicornt használjuk a projekt WSGI moduljának betöltésére.

A Gunicorn parancs a projekt könyvtárában található:

Ez elindítja a Gunicornt ugyanazon a felületen, amelyen a Django futott. Az alkalmazást újra tesztelhetjük egy normál webböngészőből. Vegye figyelembe, hogy az adminisztrációs felületen nem jelennek meg a stílusok, mert a Gunicorn még nem tudja, hogyan találja meg a statikus CSS-tartalmakat:

Ha végzett, nyomja meg a „Ctrl + C” billentyűkombinációt a terminálablakban a Gunicorn szerver leállításához.

• Kilépés a virtuális környezetből

A Django alkalmazás konfigurációja befejeződött. Futtassa a következő parancsot a virtuális környezetből való kilépéshez:

Gunicorn socket- és service-fájlok

Ellenőriztük, hogy a Gunicorn képes együttműködni a Django alkalmazással. Azonban robusztusabb módszerre van szükségünk az alkalmazásszerver kezeléséhez. Itt jön a képbe a systemd. A systemd az egyik legnépszerűbb init rendszer Linuxon. Itt egy részletes útmutató arról, hogyan kezelhetők a systemd szolgáltatások és egységek.

Létrehozhatunk socket- és service-fájlokat a Gunicorn számára, hogy a systemd úgy kezelhesse azt, mintha egy szolgáltatás lenne. Rendszerindításkor létrejön a Gunicorn socket. A socket figyelni fogja a bejövő kapcsolatokat. Amikor kapcsolat jön létre, a systemd elindítja a Gunicorn folyamatokat a kapcsolat kezelésére.

• Gunicorn socket

Kezdjük egy Gunicorn socket létrehozásával. A fájlt sudo jogosultsággal kell létrehozni:

Írja be a következő kódot a fájlba:

Mint látható, a kód három szakaszból áll.

• [Unit]: Ez a szakasz írja le a socketet.
• [Socket]: Ez határozza meg a socket helyét.
• [Install]: Ez a rész biztosítja, hogy a systemd a megfelelő időben hozza létre a socketet.

Mentse el a fájlt, és zárja be a szerkesztőt.

• Gunicorn service

Ezután létrehozunk egy service-fájlt a Gunicorn számára. A socket-fájlhoz hasonlóan ezt is sudo jogosultsággal kell létrehozni:

Írja be a következő kódot:

A kód több szakaszból áll:

• [Unit]: Ez a szakasz határozza meg a metaadatokat és a függőségeket. Azt is leírja, hogy csak a hálózati cél (network target) elérése után induljon el.
• [Service]: Ez a szakasz határozza meg azt a felhasználót és csoportot, amely alatt a folyamat futni fog. A csoport tulajdonosa a „www-data” értékre van beállítva, hogy az Nginx kommunikálni tudjon a Gunicornnal. Emellett feltérképezi a munkakönyvtárakat és meghatározza az indító parancsokat.
• [Install]: Ez a szakasz megmondja a systemd-nek, hogy mihez kapcsolja ezt a szolgáltatást, ha engedélyezve van a rendszerindításkor. Akkor kell elindulnia, miután a normál több-felhasználós rendszer elindul.

Ezután mentse el a fájlt, és zárja be a szerkesztőt.

• A Gunicorn socket engedélyezése

A Gunicorn socket használatra kész. Ezért futtathatja a következő parancsokat. Ez elindítja és engedélyezi a socketet. A socket fájl itt fog létrejönni: /run/gunicorn.sock a rendszerindításkor. Amikor kapcsolat jön létre a sockettel, a systemd elindítja a Gunicorn szolgáltatást annak kezelésére:

Ellenőrizze a Gunicorn socket állapotát:

Most ellenőrizze a socket fájl létezését:

Ha a systemctl állapota hibát jelez, vagy a gunicorn.sock fájl nem található, az azt jelzi, hogy a socket nem jött létre megfelelően. Nézze meg a részletes naplót a nyomokért:

Ne felejtse el újra megnézni a gunicorn.socket fájlt az esetleges hibákért.

• Socket aktiválás

Eddig elindítottuk a gunicorn.socket socketet. Kapcsolati kérés nélkül azonban a gunicorn.service nem fog aktiválódni. Ezután ellenőrizze a Gunicorn állapotát:

A socket aktiválási mechanizmust egy kapcsolati kérés elküldésével tesztelhetjük a curl segítségével:

Egy HTML kimenetet kell kapnia az alkalmazástól. Ez azt jelzi, hogy a Gunicorn sikeresen elindult, és képes volt kiszolgálni a Django alkalmazást. Ellenőrizze a Gunicorn szolgáltatás jelenlegi állapotát:

Ha bármilyen váratlan viselkedést vagy kimenetet tapasztal (ami hibát jelez), nézze meg a részletes naplókat a nyomokért:

Ha változtatások történtek a gunicorn.service fájlban, akkor újra be kell töltenie a démont a szolgáltatásdefiníció újbóli beolvasásához. Ez a Gunicorn szolgáltatás újraindítását is igényli:

Az Nginx konfigurálása

Most beállítjuk az Nginx-et, hogy a bejövő forgalmat továbbítsa a folyamatnak. Először hozzon létre egy új szerverblokkot az Nginx-ben:

Ezután írja be a következő kódot:

 

Íme a konfiguráció több blokkja:

• szolgáltatás: Ez a blokk határozza meg, hogy a szervernek normál módon a 80-as porton kell hallgatóznia, és válaszolnia kell a szerver domain nevére vagy IP-címére.
• location: Ez az első location bejegyzés. Meghatározza, hol találhatók a statikus elemek.
• location: Ez a második location bejegyzés. Ez a blokk határozza meg a szabványos proxy paramétereket és azt, hogyan kell a forgalmat a Gunicorn socketnek továbbítani.

Mentse el a fájlt, és zárja be a szerkesztőt. Kapcsolja a fájlt a „sites-enabled” könyvtárhoz az aktiváláshoz:

Ezt követően ellenőrizze, hogy van-e szintaktikai hiba az Nginx konfigurációjában:

Ha nem talált hibát, indítsa újra az Nginx-et a változtatás alkalmazásához:

Ismét módosítanunk kell az UFW szabályokat. Már nincs szükségünk a fejlesztői szerver elérésére, így eltávolíthatjuk a 8000-es portra vonatkozó kivételt. Emellett meg akarjuk nyitni a 80-as portot a normál forgalom számára:

Ellenőrizze a tűzfalszabályok változásait:

A szervernek most már elérhetőnek kell lennie egy normál webböngészőből.

Hibaelhárítási folyamatok

Ha minden lépést megfelelően követett, a Django alkalmazásnak elérhetőnek kell lennie az interneten keresztül. Ha nem, az azt jelzi, hogy a telepítés nem a tervek szerint alakult. Hibaelhárítást kell végeznünk, hogy kiderítsük a probléma forrását.

• Az Nginx az alapértelmezett oldalt jeleníti meg

Ha az Nginx az alapértelmezett oldalt jeleníti meg az alkalmazás proxy helyett, az általában azt jelenti, hogy a server_name hibásan lett konfigurálva a szerverblokkban.

Ebben a példában a szerverblokk a következő helyen van tárolva:

A server_name bejegyzés határozza meg, hogy az Nginx melyik szerverblokkot használja a kérések megválaszolására. Ha az alapértelmezett oldal jelenik meg, akkor az Nginx valószínűleg nem tudta illeszteni a kérést egy kifejezett szerverblokkhoz, így helyette az alapértelmezett blokkra esik vissza:

Ellenőrizze, hogy a Django projekt szerverblokkja megfelelő server_name.

• 502 Bad Gateway

Az 502-es hiba azt jelzi, hogy az Nginx nem tudta sikeresen továbbítani a kérést. A konfigurációs problémák széles skálája vezethet 502-es hibához, ezért nyomokra van szükségünk a megfelelő hibaelhárításhoz.

A nyomok elsődleges forrása az Nginx hibanaplói. Általában ezek utalnak azokra a körülményekre, amelyek a problémákat okozták a proxyzás során. Ellenőrizze az Nginx hibanaplóját a következő paranccsal:

Miután a napló megnyílt, próbálja meg újra elérni a szervert. Ennek egy új hibaüzenetet kell generálnia a naplóban. Ez segíthet szűkíteni a problémát. Íme néhány lehetséges üzenet:

• connect() to unix:/run/gunicorn.sock failed (2: No such file or directory)

Ez azt jelzi, hogy az Nginx nem találta a gunicorn.sock fájlt a konfigurációban meghatározott helyen. A helyet a proxy_pass direktíva írja le a site blokk alatt. Ellenőrizze, hogy a proxy_pass a gunicorn.sock megfelelő helyére mutat-e, amelyet a gunicorn.socket systemd egység generált:

Ha a gunicorn.sock nem található a /run könyvtárban, az azt jelenti, hogy a systemd nem tudta létrehozni. Ellenőrizze újra a Gunicorn socket fájl konfigurációs lépéseit.

• connect() to unix:/run/gunicorn.sock failed (13: Permission denied)

Ez azt jelzi, hogy az Nginx jogosultsági problémák miatt nem tudott csatlakozni a Gunicorn sockethez. Ez akkor fordulhat elő, ha a folyamat root felhasználóként lett végrehajtva egy sudo felhasználó helyett. Bár a systemd sikeresen létrehozta a gunicorn.sock fájlt, az Nginx nem tudja használni azt.

Az egyik lehetséges ok a gyökérkönyvtár (/) és a gunicorn.sock fájl közötti korlátozott jogosultságok lehetnek. Ellenőrizze a socket fájl és mindegyik szülőkönyvtárának jogosultságait és tulajdonosát:

Az első oszlop a fájljogosultságokat írja le. A második oszlop a tulajdonos felhasználót, a harmadik oszlop pedig a tulajdonos csoportot mutatja. Ha a gunicorn.sock fájlhoz vezető könyvtárak bármelyike nem rendelkezik megfelelő olvasási és végrehajtási jogosultságokkal, az Nginx nem fogja tudni elérni a socketet.

• A Django a „could not connect to the server: Connection refused” hibaüzenetet jeleníti meg

Ez azt jelzi, hogy a Django nem tudott csatlakozni a PostgreSQL szerverhez. Győződjön meg arról, hogy a PostgreSQL szerver fut:

Ha nem fut, futtassa a következő parancsokat az elindításához és engedélyezéséhez:

Ha továbbra is fennáll ez a hiba, ellenőrizze, hogy az adatbázis hitelesítési adatai megfelelően vannak-e meghatározva a következő helyen: settings.py:

További hibaelhárítás

A további hibaelhárításhoz különféle naplófájlok állnak rendelkezésre. Ezek a naplók segíthetnek szűkíteni a problémák forrását.

Íme a segítséget nyújtó naplók listája:

• Nginx naplók

• Hozzáférési naplók-Nginx

• Hibanaplók-Nginx

•  Alkalmazásnaplók-Gunicorn

•  Socket naplók-Gunicorn

A konfiguráció vagy az alkalmazás frissítése után előfordulhat, hogy újra kell indítania a folyamatokat a módosítások alkalmazásához. Ha a Django alkalmazás frissült, indítsa újra a Gunicorn folyamatot a változtatások átvételéhez:
Abban az esetben, ha a Gunicorn socket vagy service fájlok módosulnak, töltse be újra a démont, és indítsa újra a folyamatokat:
Ha az Nginx szerverblokk konfigurációja módosult, azt élesítés előtt tesztelni kell. Ehhez az Nginx újraindítása is szükséges:

Záró gondolatok

Ez az útmutató sikeresen bemutatja, hogyan kell lefektetni a Django alapjait. A Django egy webalkalmazás számos gyakori összetevőjét biztosítja, lehetővé téve, hogy az egyedi elemekre összpontosítson. A Django projekt a virtuális környezeten belül fog működni. A Gunicorn kezeli az ügyfélkérések és a Django közötti kommunikációt. Végül az Nginx fordított proxyként működik az ügyfélkapcsolatok kezelésére.

Kellemes számítógép-használatot!