PHPPamokos.lt


12. Laravel ir Shared hostingas

Iki šiol kūrėme mūsų krepšinio aikštelių projektą lokaliai - localhost serveryje. O kaipgi visa tai veikia realiame gyvenime - kaip įkelti visa tai į serverį ir realų adresą? Yra, iš esmės, du variantai: jeigu turite nuosavą dedikuotą serverį, tai viskas paprasta - įkeliate failus (per FTP ar iš kokio GIT), prisijungiate per SSH, praleidžiate reikalingas komandas (composer install, php artisan migrate, php artisan db:seed ir t.t.), ir viskas. Bet jei neturite SSH prieigos - tada jau prasideda žaidimai.

Tad atskirą skyrelį nusprendžiau paskirti tiems, kas naudojasi Shared tipo hostingo paslauga, kai užsakoma vieta serveryje, kur dar talpinamos kitų žmonių svetainės. Tai yra dažniausiai pigiau, o ir nereikia pačiam administruoti serverio - bet problema yra apribojimai. Negalime pakeisti serverio nustatymų (nes jis priklauso ne tik mums), o taip pat neturime prieigos prie komandinės eilutės serveryje ar prisijungimo per SSH. O juk būtent per komandinę eilutę vykdoma dalis Laravel veiksmų. Ką daryti - apie tai šis skyrelis.

Pradėkime gal kiek iš toliau - kad kiekvienas kuriamas projektas turi turėti bent kelias "aplinkas". Paprasčiausias pavyzdys - versija jūsų lokaliame kompiuteryje ir reali "gyva" versija serveryje. Ir darbo principas turėtų būti toks - dirbame lokaliai ir viską testuojame lokaliai, ir tik užbaigę kažkokią funkciją ar porciją darbų - keliame į gyvą versiją.

Pastaba: pagal bendrą programavimo teoriją, rimtesni projektai turėtų turėti ne dvi, o keturias aplinkas:

  • local - lokali versija, prieinama tik jums iš jūsų kompiuterio
  • live - gyva versija, prieinama visiems internete
  • dev - kopija, įkelta į serverį (kas reiškia kad visi serverio parametrai turi sutapti su "gyvo" serverio nustatymais, arba tiesiog fiziškai talpinama tame pačiame serveryje tik kitame kataloge) - ir ta versija skirta developeriams testuoti projektą serverio aplinkoje
  • stage - versija, analogiška "dev" versijai, tik prie jos prieigą jau turi visa komanda bei klientas, jei toks yra. Skirtumas kad "dev" versijoje gali būti klaidų ar kokių nors logų išvedimas į ekraną, o "stage" jau turi būti kiek įmanoma artimesnė "live" aplinkos kopija.

Taigi, toliau laikysime, kad turite dvi versijas: "local" ir "live".

Taip pat su shared-hostingu turbūt turite:

  • Prieiga prie savo katalogo serveryje per FTP
  • Kokį nors vizualų įrankį MySQL valdymui, dažniausiai PhpMyAdmin

Taigi, darbo principas turėtų būti toks - kiek įmanoma daugiau darome lokaliai, ir uploadiname į gyvą serverį tik tada kai tikrai reikia. Nes su Laravel kiekvienas toks įkėlimas gali būti skausmingas, ypač jeigu nuo praeitos įkeltos versijos keitėsi duomenų bazės struktūra arba composer.json failo turinys.

Jeigu žiūrėti nuo pat pradžių:

  1. Diegiame Laravel lokaliai
  2. Laravel migrations pagalba Sukuriame duomenų bazę (pageidautina visą struktūrą iškart)
  3. Jeigu mums reikia daugiau išorinių bibliotekų, negu turi paprastas Laravel, paredaguojame composer.json ir viską įdiegiame lokaliai
  4. Sukoduojame savo projekto pagrindą ir ištestuojame viską lokaliai
  5. Tik tada pirmą kartą keliame viską į "gyva" serverį
 

Ką daryti su /public katalogu

Pirmiausiai turbūt susidursite su problema, į kurį katalogą kelti visą Laravel projektą. Tai sprendimas gali priklausyti nuo to, kokias teises jums suteikia hostingo konpanija, bet dažniausiai turėsite prieigą prie savo public_html katalogo ir dar vieno lygio aukščiau.

Taigi, iš esmės, jūsų public_html katalogas yra analogiškas Laravel sistemos /public katalogui, o visą likusį projektą reikia kelti vienu katalogu aukščiau. Tai yra vienas iš saugumo principų - viešai internete rodome tik /public katalogą, kuriame iš esmės, yra tik pagrindiniai PHP failai ir visi resursai - CSS, JS ir paveiksliukai.

 

Ką daryti su duomenų bazės pakeitimais

O kaip su tokiu atveju, kai norime pridėti naują lauką duomenų bazėje? Arba kažką nežymaus pakeisti?

Bendrai Laravel sistemoje yra patogi ir galinga migracijų sistema, bet problema - kad ji priklausoma nuo Artisan ir nuo komandinės eilutės, o shared-hostingai vėlgi to neduoda. Ką daryti? Nepasakysiu nieko guodžiančio - reikia daryti viską rankomis. Šiuo atveju yra įvairių variantų, bet pats pripratau tiesiog atskirame kataloge saugoti SQL failus, susijusius su duomenų bazės pakeitimais. Ir tada tuos pačius skriptus leisti visose aplinkose ir visuose serveriuose.

Svarbiausia čia yra nepasiklysti - saugoti kiekvieną pakeitimą, panašiai kaip saugome kodo pakeitimus versijų kontrolės sistemoje. Tiesą pasakius, būtent ten ir saugau SQL užklausas - repozitorijoje atskirame kataloge.

 

Ką daryti su Composer pakeitimais?

Sakykime, kad projekto eigoje pamatome, kad mums reikės bibliotekos darbui su PDF. Jų yra nemažai, ir diegimas nesudėtingas - tiesiog pakeičiame composer.json failą ir praleidžiame "composer install", ar ne? Bet vėlgi - neturime prieigos prie komandinės eilutės!

Tai šiuo atveju turėsime naują biblioteką iš /vendor katalogo įkelti rankomis per FTP. Bet, deja, tuo mūsų problemos nesibaigs - kiekvieną kartą darant composer install ar composer update, yra pergeneruojami kai kurie Laravel failai, ir jeigu jų neįkelsime, tai bus bėdos - projektas net nepasileis.

Taigi, reikia dar įkelti:

  • /vendor/autoload.php failą
  • /vendor/composer visą katalogą
 

Ką daryti su duomenų bazės ir kitais nustatymais, jei jie skirtingi?

Lokaliai jūsų duomenų bazės slaptažodis greičiausiai skirsis nuo gyvo serverio - gal net skirsis ir pavadinimas. Kaip tai suvaldyti, nekaitaliojant kiekvieną kartą config/database.php failo? Tam Laravel kataloge config turi pakatalogius - su diegimu kartu eina tokie kaip local, packages ir testing, bet realiai galite prikurti savo kiek norite. Tai kiekvieno tokio katalogo paskirtis - įrašyti nustatymus, kurie skirtųsi nuo pagrindinių.

Sakykime, pagrindiniame config/database.php faile saugosite gyvo serverio nustatymus, o tada galite susikurti savo config/local/database.php, kuriame nurodysite lokalios duomenų bazės nustatymus ir slaptažodžius. Iš esmės, tiesiog nukopijuokite pagrindinio database.php failo turinį į tą local/database.php failą ir pakeiskite nustatymus.

Laravel principas toks: paimami pagrindinio katalogo config failai ir nustatymai priskiriami sistemai. Tada ieškomi pakatalogiai tokie kaip local ir žiūrimi ten esantys failai. Jei randami kitokie nustatymai - tai jie "perrašo" numatytuosius iš pagrindinio katalogo. Taigi, iš to seka išvada - kad pakatalogiuose galite kurti visus config failus pagal savo nuožiūrą - ne tik database.php, bet ir app.php, auth.php ir t.t. - viską ką matote config kataloge.

Turbūt, dabar esminis klausimas - kaip Laravel nustato, kokį katalogą imti? Automatiškai jis to nepadarys, mes jam turime tai nurodyti. Tam skirtas failas bootstrap/start.php, jame mums įdomios štai šios eilutės:

$env = $app->detectEnvironment(array(
  'local' => array('homestead'),
));

Būtent pagal šį masyvą Laravel nustatys, kokia aplinka šiuo metu yra aktyvi. Tam ji naudos kompiuterio vardą. Taip taip, tai tas pats pavadinimas, kurį jūs įvedate diegdami Windows operacinę sistemą, kur dažniausiai įrašote bet ką - savo vardą (pvz Povilas) ar tiesiog "Home". Tai būtent šį vardą Laravel priims kaip aplinkos sąlygą. Šiame pavyzdyje tai yra "homestead" - taip vadinasi virtuali aplinka, jei lokaliai įdiegtas serveris Laravel Homestead. Taigi, keičiame tai į mūsų "home" ir gauname lokalią aplinką.

Šiame masyve galima (ir patartina) nurodyti kelias aplinkas, priskiriant jiems vardus, kuriuos po to Laravel interpretuos kaip katalogus.

$env = $app->detectEnvironment(array(
  'local' => array('homestead', 'home'),
  'staging' => array('178.xx.xx.xx'),
  'production' => array('phppamokos.lt'),
));
 

Naudokite versijų kontrolės sistemas

Ir paskutinis patarimas dėl deployment proceso ir kodo valdymo - būtinai būtinai naudokite versijų kontrolę, tokią kaip GIT, SubVersion ar Mercurial. Kokią pasirinkti - jau jūsų nuožiūra, bet tai suteikia darbui prie projekto didelį patogumą ir apsaugo nuo galvos skausmų dėl prarasto kodo ar praeitos versijos atstatymo. Net jei dirbate vienas, net jei dirbate tik viename kompiuteryje - primygtinai rekomenduoju. Kaip šalutinis poveikis - jei turite nuosavą serverį, galima pasidaryti deployment skriptą, kuris padarytų, sakykim, "git pull origin master", kas reiškia, kad kai tik jūs įkeliate naują kodą su "git push", tas kodas iš karto atsiduria serveryje, nereikia nieko rankomis kilnoti.



(c) 2015-2018. Visais klausimais kreipkitės povilas@laraveldaily.com