Deployment v PHP? Zkusili jste Magallanes?

Čím více kromě Drupalu a WordPressu stavím aplikace na míru, tím více vidím, že mi prostě nestačí kopírování práce na server přes FTP či jiný protokol. Určitou možností, jak se vyhnout sofistikovaným a přebujelým nástrojům, je použití nástroje Magallanes.

V Drupalu je to více méně dané. Kvůli závislosti na databázi a na tom, že spousta nastavení je uložena v ní, takže není možné udělat něco tak jednoduchého jako překopírování souboru pro dosažení nové funkcionality, dělám spoustu věcí za chodu. Větší úpravy samozřejmě dělám na kopii webu a následně je snadněji či složitěji reprodukuji do ostrého webu. Už se těším na Drupal 8 a jeho přenášení konfigurace.

Co se týče projektů na míru, ať už v CodeIgniteru, Symfony 2 nebo Silexu, tak je situace o něco jednodušší. Zejména Symfony je super. Změna ve struktuře databáze? Stačí spustit povel přes příkazový řádek a je to. Možná to moc zjednodušuji, každopádně přenášení kódu z vývojového počítače na produkčního prostředí mi přijde jednodušší než u Drupalu nebo WordPressu.

Nicméně je třeba počítat s několika úkony. Po zkopírování souborů (a neopomenutí některé z nich vynechat) je potřeba vymazat cache, zaktualizovat databázi, připravit novou cache a provést nějaké další věci. Jsou to v podstatě jednoduché úkoly, ale pokud je jich větší počet, člověk snadno na něco zapomene.

A právě zde přicházejí ke slovu nástroje pro deployment. Je jich celá řada, na školení Symfony 2 nám ukazovali pár ukázek napsaných v Ruby. Já jsem si našel jiného favorita. Nedovedu posoudit, zda toho umí více než třeba Capistrano, ale je psaný v PHP a lze ho snadno rozšiřovat o další funkce. Jmenuje se Magallanes.

Jak funguje Magallanes pro deployment v PHP

Magallanes slouží k tomu, aby zautomatizoval několik po sobě jdoucích úloh, které provádíte při kopírování projektu na server. Nainstalujete jej naprosto jednoduše přes Composer, ale je možná i ruční instalace. Následně spustíte inicializaci projektu, čímž vám v něm vznikne skrytá složka .mage a v ní konfigurační soubory.

V základní konfiguraci upravíte název aplikace, nastavení logů a notifikace. Následně přidáte minimálně jedno prostředí, do kterého chcete projekt pomocí Magallanes kopírovat (typicky produkci a případně další servery).

Vznikne další konfigurační soubor, ve kterém postupně specifikujete, odkud kam se má co kopírovat a co se má vynechat. Magallanes umí také systém verzování (releases), kdy v cílovém umístění vytvoří složku releases, v ní pak složky pro jednotlivé verze projektu a rovněž složku current směřující do aktuální verze. Dále specifikujete cílový server a úlohy spouštěné před a po nasazení (deploymentu, chcete-li) a po vytvoření release.

Samotné nasazení, tedy překopírování projektu a spuštění potřebných úloh na vzdáleném serveru, znamená na vývojovém stroji spustit jednoduchý příkaz mage deploy to:production. Production samozřejmě nahradíte názvem prostředí, pro které máte připravenu konfiguraci.

Líbí se mi, že v rámci jednoho konfiguračního souboru je možné upravit různé nastavení v závislosti na cílovém stroji.

Magellanes využívá pro kopírování rsync, při práci s releases pak ještě tar. Kromě toho umí kopírovat data i do repozitáře Gitu. Kopírování je možné potlačit a Magallanes tak používat jen pro automatizované spouštění různých úloh.

Úkoly a příkazy snadno vyrobíte podle svých potřeb. To v případě, že vám nestačí několik příkazů podporujících projekty v Symfony 2, Magento, SCM a podpora Composeru.

Magallanes zatím používám několik málo dnů, ale už teď vidím, že je to další nástroj do škatulky s názvem užiteční pomocníci při práci. Vyzkoušejte.

Buďme ve spojení, přihlaste se k newsletteru

Odesláním formuláře souhlasíte s podmínkami zpracováním osobních údajů. 
Více informací v Ochrana osobních údajů.

Autor článku: Jan Polzer

Tvůrce webů z Brna se specializací na Drupal, WordPress a Symfony. Acquia Certified Developer & Site Builder. Autor několika knih o Drupalu.
Web Development Director v Lesensky.cz. Ve volných chvílích podnikám výlety na souši i po vodě. Více se dozvíte na polzer.cz a mém LinkedIn profilu.

Komentáře k článku

návštěvník

S Magallanes jsem se nikdy nesetkal, ale potkal jsem se třeba s deployer.in nebo kluci na wordpress používali rocketeer. Postupně jsme ale evolucí přešli na ansible/chef/capistrano a rpm balíčky, to už ale u větších projektů.

Největší problém vždy nastává při zpětně nekompatibilní změně db modelu nebo při nutnosti migrovat současná data (session, uploadované soubory atd.), je vždy lepší se tomu vyhnout, protože pak člověk už musí šachovat s replikací či třeba s polymorfismem v aplikaci (funguje zároveň s novou i starou strukturou dat).

Pár rad na co je dobré si dát pozor:
- vždy se něco může po**at, takže počítej za každý okolností s možností rollbacku
- vždy novou verzi, kterou deployuješ, odzkoušej, žádné "ono to určitě bude fungovat, vždyť jsem měnil jen text" nikdy neplatí věčně
- dej pozor, abys si nesmazal živá data (uploadované soubory, generované css/image atd.). S rsyncem to jde vždy hodně snadno. Živá data měj vždy mimo aplikaci a snaž se omezovat práva na úrovni filesystému na max, tj. klidně právo na zápis oddělit od práva na čtení
- vždy před deployem nové verzi vytvoř záloh všeho (vč. živých dat), ač ti to může připadat jako zbytečnost, v jednom z 1000 případů ti to může zachránit mnoho hodin/dní práce a ušetřit řadu problémů
- doba deploye není nulová, neboj se během deployování hodit na webu režim údržby. Kontroluj jak dlouho to trvá a hlídej to. Není větší opruz než, když řada českých webů po půlnoci několik desítek minut vyhazují náhodné chyby, protože se provádí deploy, netýká se to jen těch malých...
- čím víc do workflow dáváš automatizaci, tím větší problém může nastat při nějaké chybě, ať už smazání dat uživatelů tak jakákoliv věc, která se rozbije po cestě

Určitě s tímhle máš zkušenosti, ale opakování je matka moudrosti. Tvůj blog čte hodně začínajících uživatelů a mohou se zbytečně dostat do pasti.

Profile picture for user Jan Polzer

Díky za tipy. Se vším mám, leckdy bohužel, zkušenosti, tak snad se ostatní vyvarují podobných chyb. Zvláště, jak člověk dostane pocit, že už jej nemůže nic překvapit a stane se z podobných procesů rutina, hned se něco potentuje :-)

návštěvník

V praci nam bezia vsetky projekty na Pantheone. Najlacnejsi variant sotji 25 dolarov mesacne. Pokial sa nejedna o web za 1000€ tak nevidim dovod nedonutit klienta prejst na nieco taketo.

Profile picture for user Jan Polzer

Pantheon je sice fajn, ale bojím se, že non-IT klienti by asi nepochopili, proč to využít. 25 USD je pro některé dost, když vidí nabídky WEDOSu a spol ;-)

návštěvník

Protože jsem bohužel nucen pracovat většinou se sdílenými hostingy, kde není SSH ani Composer, požívám FTPloy (ftploy.com). Mám ho napojen na repository na Bitbucketu s tím, že při každé commit/push to automaticky nahraje změny na FTP (funguje to tedy právě i na obyčejném sdíleném hostingu, kterých jsou v ČR pořád mraky). Nepoužívám to zatím na production serverech, spíše na rychlý preview změn na "development" serveru, pokud pracuji na více počítačích (desktop doma, laptop na cestách). Mám práci vždy po ruce a nemusím instalovat lokální server ani Vagrant, se kterým jsem měl zatím jen samé problémy...

Profile picture for user Jan Polzer

Díky za zmínku o FTPloy. Já na něj někdy na podzim koukal právě kvůli FTP a běžným hostingům. Funguje to spolehlivě?

Přidat komentář

Odesláním komentáře souhlasíte s podmínkami Ochrany osobních údajů

reklama
Moje kniha o CMS Drupal

 

Kniha 333 tipů a triků pro Drupal 9


Více na KnihyPolzer.cz

Sledujte Maxiorla na Facebooku

Maxiorel na Facebooku

Poslední komentáře
Hosting pro Drupal a WordPress

Hledáte český webhosting vhodný nejenom pro redakční systém Drupal? Tak vyzkoušejte Webhosting C4 za 1200 Kč na rok s doménou v ceně, 20 GB prostoru a automatické navyšováním o 2 GB každý rok. Podrobnosti zde.

@maxiorel na Twitteru

Maxiorel na Twitteru