Azt gondolom, hogy az előző feladat sem volt feltétlenül egyszerű és problémától mentes, de ez a mostani már tényleg igazi kihívásokat tartogatott a számomra. Telepítsük most az Azure MySQL-ra épülő Laravel Blog alkalmazásunkat a felhőbe (kvázi az adatbázis mellé).

Fontos: mivel ez a Laravel Blog alkalmazás még Laravel 8-as keretrendszeren működik, ami után számos fontos változás következett be a környezeti feltételekben (Laravel 9 -hez már PHP 8 kellett legalább, annak a támogatása pedig az Azure felhőben már nem Apache webszerver szolgálja ki, hanem az nginx), ezért is érdemesebb már az újabb blogbejegyzésem szerint haladni, ami ezt vezeti végig: https://attila.gludovatz.hu/posts/adatbazis-hozzaferes-4-b-resz-felkoltozes-a-felhobe-laravel-9

"App Service Plan" (Alkalmazás szolgáltatási terv) létrehozása

Most több utasítást is végrehajtunk az Azure Shell segítségével, az előző bejegyzésben megmutattam, hogy hogyan kell megnyitni az Azure Portal-on a Shell terminal-t.

az appservice plan create --name myAppServicePlan --resource-group GA_RG --sku F1 --is-linux

Az én "App Service Plan"-em neve myAppServicePlan lett, de ahogy korábban is hangsúlyoztam, ezek szabadon változtathatók, arra viszont figyeljünk, hogy utána ugyanazt használjuk, amit itt definiáltunk. Én továbbra is a GA_RG Resource Group-omat használom, "amibe pakolom a szolgáltatásokat". Az --sku az árazásra vonatkozik, az F1 pedig azt mutatja, hogy ingyenes lesz a használata. Az --is-linux kapcsolóval tudjuk Linux alapú konténerben működtetni majd az alkalmazásunkat. Később ez kisebb problémával fog járni, hogy nehezebben tudunk fejlesztői szolgáltatásokat igénybe venni, nem csak néhány kattintással, de az ingyenességnek "ez az ára". Ahogy már említettem, a terminal mindig vissza fog jelezni nekünk, remélhetőleg a pozitív eredményről adott JSON válasszal, vagy pedig valamilyen beszédes hibaüzenettel, amelyet majd meg kell oldanunk. Ha hibát kapunk, akkor további információ az "App Service Plan" létrehozásának mikéntjéről, parancshoz tartozó paramétereiről itt olvasható: https://docs.microsoft.com/en-us/cli/azure/appservice/plan#az_appservice_plan_create

"Deployment User" (Telepítési felhasználó) létrehozása

Ugyanúgy az Azure Portal-on belüli Shell terminal-t használjuk:

az webapp deployment user set --user-name aaaa --password bbbb

Itt a --user-name és a --password kapcsolók utáni érték beállítások nyilván az én értékeim ismét. Ha hibát kapunk (Conflict), akkor a Password kulcshoz nem lesz értékünk, és például 409-es hibakódot is kaphatunk, akkor próbáljuk meg módosítani a felhasználónevet a fenti parancsban. Vagy 400-as hibakódot is adhat a rendszer, ekkor próbáljunk meg erősebb jelszót megadni (legalább 8 karakteres és legyen benne kisbetű, nagybetű, szám is, mindegyikből legalább 2).

"Web App" (Webes alkalmazás - helyének) létrehozása

Itt is az Azure Shell-t fogjuk használni. Most hozzuk létre konkrétan a webes alkalmazásunkat ezzel az utasítással:

az webapp create --resource-group GA_RG --plan myAppServicePlan --name laravel-blog-azure-v2 --runtime "PHP|7.4" --deployment-local-git

A szokásos Resource Group-omat (GA_RG) itt is meg kell adni. A korábbi pontban létrehozott "terv"-re (plan) is itt lesz szükségünk, adjuk meg neki a myAppServicePlan nevet. A --name kapcsoló után következik a webes alkalmazásunk neve. A későbbiekben ezzel a névvel azonosítjuk az alkalmazásunkat és a felhős weboldal URL-jébe is ez kerül be. A --runtime (kvázi futtatókörnyezet) nálam a PHP 7.4-es verziója, mert ezt használom lokálisan is és tudom, hogy működik, illetve ez elég a Laravel 8-as verziójához. Az utolsó kapcsoló, --deployment-local-git is fontos, mert majd Git-et fogunk használni a lokális projektünk felhőbe való telepítésére.

A parancs kiadása után itt még fontosabb, hogy figyeljünk a JSON válaszra, ami az Azure-től érkezik, annak is konkrétan a deploymentLocalGitUrl kulcshoz tartozó értéket mentsük el. Ennek az értéknek a formája a következő minta szerint épül fel (nálam a gludovatza, az pedig laravel-blog-azure-v2):

https://<username>@<app-name>.scm.azurewebsites.net/<app-name>.git

Adatbázis-elérés paramétereinek beállítása

Ugye ezek azok a paraméterek, amelyeket lokálisan az .env fájlunkban állítottunk be: DB_HOST, DB_DATABASE, DB_USERNAME, DB_PASSWORD és majd még néhány dolgot beállítunk. Ehhez a következő utasítást adjuk meg, természetesen figyeljetek arra, hogy nálatok mások lesznek ezek a paraméterek:

az webapp config appsettings set --name laravel-blog-azure-v2 --resource-group GA_RG --settings DB_HOST="server197968907.mysql.database.azure.com" DB_DATABASE="laravel_blog_db" DB_USERNAME="phpappuser" DB_PASSWORD="MySQLAzure2020" MYSQL_SSL="true"

A fenti utasításban a webes alkalmazást nevét az imént állítottuk be, azt kell itt is alkalmazni, a többi beállítás adja magát. Figyeljünk arra, hogy az érték oldalon (egyenlőség jeltől jobbra) idézőjelek közé kerüljön.

Laravel blog alkalmazás beállítása

Szükségünk van egy alkalmazás kulcsra (APP_KEY), de úgy, hogy ne kerüljön be a parancs futtatása után az .env fájlba:

php artisan key:generate --show

Amit eredményül adott kulcsot, azt a következő Azure-ös parancshoz fel kell használnunk:

az webapp config appsettings set --name laravel-blog-azure-v2 --resource-group GA_RG --settings APP_KEY="iménti-lekérdezés-eredménye" APP_DEBUG="true"

Az APP_KEY utáni idézőjelek közé kell beilleszteni az iménti "php artisan"-os parancs eredményét. Az APP_DEBUG attribútum true-ra állítása kezdetben segíthet nekünk, ha problémák adódnak, akkor emiatt a beállítás miatt látni fogjuk a konkrét hibákat (exception-öket) a böngészőben. Ha majd hibamentesen fog majd menni az alkalmazásunk, akkor ezt a paramétert átállíthatjuk majd false-ra.

Megjegyzés: a Laravel alkalmazásunk kiszolgálása a public mappából indul alapértelmezetten, nem pedig a projekt gyökeréből. Hiszen a projekt mappában vannak azok a dolgok, amelyek a böngészőben való kiszolgáláshoz és megjelenítéshez szükségesek: index.php, CSS és JavaScript fájlok stb. Lehetőségünk lenne .htaccess fájl létrehozásával és paraméterezésével "beirányítani" a kéréseket a public mappába, de ezt a háttérben a rendszer elvégzi helyettünk, úgyhogy remélhetőleg ebből nem adódik problémánk.

Feltöltjük a Laravel projektünket a Github-ról az Azure-be

A lokális Laravel blog projektben (mondjuk a VSCode terminal-jában) kössük hozzá a projektet a korábban elmentett git repository-hoz, de előtte ellenőrizzük le, hogy melyik fejlesztési ágon (branch-en vagyunk):

git status

Ez valószínűleg master vagy main lesz.

Most van szükség a korábban elmentésre javasolt deploymentLocalGitUrl paraméterre:

git remote add azure https://gludovatza@laravel-blog-azure-v2.scm.azurewebsites.net/laravel-blog-azure-v2.git

Attól függően, hogy master vagy main ágon vagyunk, adjuk ki a következő utasítást (én a master ágon vagyok):

az webapp config appsettings set --name laravel-blog-azure-v2 --resource-group GA_RG --settings DEPLOYMENT_BRANCH="master"

Utána következhet a projekt feltöltése a Github-ról az Azure-be:

git push azure master

Ezzel egy hosszabb folyamat indul be, aminek a végén sikeresen feltöltődik a projekt az Azure-be. Ennek következtében *elvileg* a folyamat végetért és következhet a weboldal megtekintése a böngészőben, ami itt elérhető: https://laravel-blog-azure-v2.azurewebsites.net/ de mindenképpen hozzátenném, hogy nálam elég sok probléma merült fel, amiket meg kellett oldanom ahhoz, hogy valóban megkapjam ezt a csodás végeredményt:

Mert sajnos leginkább ezt kaptam, ami egyáltalál nem volt "segítőkész és beszédes hibaüzenet":

És hiába vártam akárhányszor 5 percet, ahogy a felirat kérte, sosem történt volna meg a megvalósítás, a problémák kijavítása nélkül. De erről már az alábbi részben olvashattok.

Problémák... és megoldásuk

Nálam elég sok probléma feltűnt, sajnos, mivel először telepítettem ilyen alkalmazást a felhőbe. Ezeket próbáltam megoldani lépésről-lépésre, hogy végül sikeres legyen a weboldal megjelenítése. Ezeket itt most összefoglalom, illetve iránymutatásokat adok, hogy milyen eszközök állnak a rendelkezésünkre, mik segíthetnek.

A legbosszantóbb rész az volt, amikor a fenti, elvileg működőképes URL-re, mindig ugyanazt az oldalt kaptam eredményül, ami azt mondta, hogy "Your web app is running and waiting for your content". Nos, amikor ezt láttam, akkor sosem volt remény arra, hogy érdemes legyen kivárni azt a néhány percet, amire eredményes lett volna az oldal betöltődése, és sajnos túl sok információval sem szolgált ez az oldal.

Ami viszont sokat segített: a weboldalam URL-jének kiegészítése az scm szóval, a példámban így: https://laravel-blog-azure-v2.scm.azurewebsites.net/ (de ugyanez elérhető az Azure Portal-on keresztül is: kiválasztva a laravel-blog-azure-v2 Web App-ot, majd a bal oldali menüben a "Development tools" részben válasszuk ki az "Advanced Tools" menüpontot és bal oldalt kattintsunk utána a "Go -->" weblinkre:

Eredményül ugyanazt az oldalt kapjuk, mintha az előbb az "scm"-es bővítéssel ellátott URL-t írtuk volna be a böngészőbe:

Ezen az oldalon számos segítség áll rendelkezésünkre, ami nekem elengedhetetlen volt ahhoz, hogy működésre bírjam a távoli Laravel blog alkalmazásomat. Az itteni oldalon lévő "REST API"-s és "Browse Directory" szekció alatti menüpontokat nyugodtan áttekinthetjük, így is ismerkedhetünk a rendszerrel. Például az "App Settings" linkre kattintva láthatjuk azokat a beállításokat, amelyeket korábban elvégeztünk az Azure Shell segítségével, például a "DB_" kezdetű beállításokat vagy az APP_KEY-t itt ellenőrizhetjük, hogy tényleg azok vannak-e beállítva, amiket mi megadtunk neki. Itt a deployment_branch is fontos, nehogy véletlenül másik ágat toljunk fel az Azure-be, mint amit használtunk amúgy... a végrehajtott commit-eket amúgy a "Deployments" menüpont alatt ellenőrizhetjük szintén. A "Deployment Logs" alatt láthatjuk szöveges fájl(ok)ban a korábban kiadott git push azure master utasítás hatására hosszan lefutott utasítások halmazát, esetleg ez is segíthet megtalálni hiba okát. A "Site wwwroot" link alatt pedig megnézhetjük azt a könyvtár és fájlszerkezetet, amiből próbálja felépíteni az Azure az alkalmazást... és nálam itt adódott az egyik legfőbb hiba forrása! Hiányzott a vendor mappa.

Ugye a vendor mappa tartalmazza a szerveroldali függőségek csomagjait, amit lokálisan korábban már a composer program segítségével telepítettünk a Laravel projektünkbe. Ennek a megoldása többféleképpen is megoldható lehetne, de az első megoldás, amit találtam, az arra vonatkozott, hogy az imént beszúrt képen is látható Azure Portal-on lévő "Development Tools" részben kattintsunk az "Extensions" menüpontra és ott hozzá tudjuk adni a composer-t mint kiterjesztést a webes alkalmazás projektünkhöz. Nálam viszont ez az "Extensions" menüpont inaktív (ahogy a mellékelt képen is látszódott). Ennek utánaolvastam és ez azért van, mert linux-os, illetve ingyenes alkalmazásnál nincs arra lehetőségünk, hogy ilyet használjunk... mivel megpróbáltam az "ingyenes" területen maradni, ezért az nem volt most opció, hogy kiterjesszem az előfizetésemet vagy inkább Windows-os konténert, futtatókörnyezetet használjak.

Az "scm"-es fejlesztői oldalon viszont lehetőségünk van SSH és Bash használatára is. Kiválasztottam az SSH-t a menüpontok közül és először ellenőriztem a PHP elérhetőségét: php -v utasítással. Szerencsére ez megvolt, érzékelte a rendszer. A composer -v utasítás viszont jelezte, hogy probléma van.

A képen látható parancsok sorrendje itt van:

echo 'alias composer="php -d allow_url_fopen=On ${HOME}/composer.phar"' >> ~/.bashrc
source ~/.bashrc
cd ~
curl -k -O https://getcomposer.org/installer
php -d allow_url_fopen=On installer
composer -v

A képen látható, hogy amikor először adtam ki a composer -v utasítást, akkor még ismeretlen parancsként értelmezte, de ezen néhány utasítás hatására sikeresen telepítettem és a composer -v utasítás újbóli kiadása már sikert eredményezett.

Ezután frissítsünk rá a böngészőnkre, hogy "visszajussunk" a home könyvtárba és adjuk ki a következő utasításokat:

cd site
cd wwwroot
composer update

Ennek hatására elkezdenek letöltődni és települni (nálam már frissülni) a szerver oldali csomagok. Ezután már betöltődött a Laravel alkalmazásunk a webcímen (https://laravel-blog-azure-v2.azurewebsites.net/), viszont jelzett még hibákat (exception-öket) a rendszer, amelyeket azonban már a meglévő rutinomnal tudtam kezelni.

Először azt a hibát kaptam, hogy az adatbázis hozzáférésének paraméterei nem megfelelőek, amit egy gyors elírás kijavításával tudtam megoldani. Mindenesetre érdemes felhívni rá a figyelmet, hogy az Azure Portal-on is ellenőrizhetők ezek a paraméterek, itt:

A Settings / Configuration menüponton belül az Application settings részben láthatók azok a beállítások, amelyeket korábban mi parancssoros utasítások segítségével megadtunk.

A javítás után sajnos még mindig nem volt jó a weboldal, de már egy másik hibaüzenetet adott. De "szerencsére" már ezt a hibaüzenetet is ismertem, hiszen jelezte számomra a rendszer, hogy hiányoznak a public mappából a kliens oldali lefordított fájlok. Ekkor tudtam, hogy a megoldás az npm run prod parancs futtatása lesz. Viszont SSH-n keresztül ezt nem tudtam kiadni, mivel az npm-et nem ismerte...

Térjünk vissza ismét az "scm"-es oldalra és most egy Bash-t indítsunk, mert ez már engedni fogja (legalábbis nálam engedte) az utasítás kiadását. Kiegészítés: DE! Még előttfuttassuk le az npm install utasítást, ami jó sokáig fog futni, majd következhet az npm run prod, ahogy alábbi ábra is mutatja:

Az utasítások egymás után:

cd site
cd wwwroot
npm install
npm run prod

Az utolsó után érdemes várni, még ha látszólag nem is reagál a rendszer, látható, hogy nálam is 148,49 másodperc alatt történt meg a művelet és a feladatok végrehajtása.

Nálam ezután már ténylegesen működött a weboldal a https://laravel-blog-azure-v2.azurewebsites.net címen, de azért nem kevés gyötrelem árán jutottam el idáig, úgyhogy senki se essen kétségbe, ha elsőre nem működik és szenvedni kell a sikerért.

A következőkben még egy kicsit foglalkozunk majd ezzel a felhőbeli alkalmazással, teszteljük a működését és megnézzük, hogy hogyan lehet a módosításokat is érvényre juttatni benne.