Distribuce perlových webových aplikací

15.5.2010 22:20 | Přečteno: 1050× | programování | | poslední úprava: 19.5.2010 07:49

Poslední dobou jsem hodně přemýšlel nad distribucí webových aplikací napsaných v Perlu. Dneska mě napadlo, že bych mohl dosavadní výsledky sepsat „na papír“ — z velké části jako akt psychohygieny, aby se mi úvahy pořád nemotaly v hlavě.

Už před několika měsíci jsem narazil na blog post, který doporučoval vyvíjet perlové aplikace podobným systémem jako moduly pro CPAN. Tedy s pevnou adresářovou strukturou a využitím Module::Build nebo něčeho podobného. Začal jsem tenhle systém používat, nejdřív v kombinaci s Module::Install a posléze s už zmíněným Module::Build. Byl to dobrý krok. Výhodou je například jednotné programátorské rozhraní — vejdu do adresáře s projektem a hned vím, kde jsou testy a jak je spustit, jak udělat distribuční tarball a podobně.

Oba zmíněné systémy jsou ale dělané spíš pro uživatele než pro autory, spíš pro instalaci modulů než podporu během jejich vývoje. Proto mají například velmi spartánské závislosti, jelikož se musí utkávat s řadou roztodivných perlových instalací „tam venku“. Vadila mi taky fůra nadbytečných souborů, které se kupily v kořenovém adresáři repository.

Naštěstí jsem zanedlouho narazil ještě na Dist::Zillu. Ta je na rozdíl od M::B a M::I dělaná přímo pro autory modulů. Závislosti řeší mnohem velkoryseji a tím pádem je pohodlnější a pružnější. A co se týká samotné instalace modulů, umí jednoduše vyrobit distribuci založenou na M::B nebo M::I.

S tímhle stavem jsem momentálně spokojený. Aplikace mají jednotnou strukturu a Dzilla umí spouštět testy, instalovat závislosti (například po přenosu na jinou vývojářskou mašinu) a sestavit distribuční tarball, aniž bych musel ručně udržovat nadbytečné soubory. Vystačí si s jedním konfiguračním souborem a dá se snadno rozšiřovat (Moose).

¶

Všechny mé větší Perlové aplikace jsou weby, takže druhá podstatná otázka zní, jak takovou aplikaci dostat na server. Základní požadavky:

• Automatizace. Release musí jít udělat jedním příkazem, automatizace šetří čas a nervy. Kdykoliv člověk něco dělá ručně, může na to zapomenout nebo to v časovém stresu přeskočí a kvalita jde dolů.
• Staging. U každého webu potřebuju mít možnost zkusit aktuální změny na oddělené testovací instanci, abych nemusel mít strach, že uploadem na server něco rozbiju. Stejně tak se dá staging použít pro předvedení změn klientům a podobně.
• Testy. Když už je aplikace balená jako běžný modul, bylo by dobré projít tradičním testovacím kolečkem. V opačném případě může aplikace spadnout například na přidané závislosti, kterou jsem na produkční server zapomněl doinstalovat.

Dřív jsem používal například rsync na živý server nebo checkout z repository. Někdo své aplikace dokonce balíčkuje (DEB, RPM), takže se pak může opřít o systémové nástroje. Já momentálně zkouším instalaci z tarballů. Když je připravený nový release, Dzilla udělá tarball postavený nad M::B, rsync tarball hodí na server, tam ho skript rozbalí, projde testy a pokud všechno sedí, přehodí symlink na adresář, nad kterým běží Apache. Když se něco vysype, k přehození symlinku vůbec nedojde a pokud ano, stačí přehodit nazpět.

Tenhle systém se mi líbí, protože dobře splňuje všechny tři vyjmenované požadavky. Bohužel je zatím relativně složitý. O rsync na server se stará plugin pro Dzillu, který bych chtěl zítra hodit na CPAN. Rozbalení tarballu na serveru má na svědomí skript přímo z repository projektu a následnou instalaci dělá ještě další skript. Celkově je to hodně kódu psaného přímo pro daný projekt, čili hodně práce, která se nedá přímo recyklovat jinde. Uvidíme.

¶

Tím tento zápisek splnil svou trapeutickou úlohu a já můžu jít klidně spát, aniž by mě ve spaní honila Dist::Zilla. Děkuji za pozornost a těším se na případnou diskuzi.        

Komentáře

[pht]

Nějak jste nezmínil PAR (perl archive, obdoba WAR/JAR).

Jinak pro balení a distribuci používám cca toto (moje aplikace je sice v javě, ale to na postupu nic nemění):

1) build skriptem se vytvoří RPM (se všemi závislostmi, protože někdy je produkční prostředí bez možnosti stahovat z netu)

2) pro "staging" fázi se nainstaluje RPM na čistý virtuální stroj

3) aktualizace na produkčním prostředí se provede jednoduše upgradem balíku

Testy mám zatím jen v kroku 1 a 2, ale můžete si něco malého nechat spustit i na produkčním stroji. Jen bych nedoporučovat spouštět celou baterii, maximálně jen zkoušku na ty závislosti.

[zoul]

Paru se trochu bojím :) Je to složitý krám a já bych byl nerad, kdyby mi to celé přerostlo přes hlavu.

[pht]

Za zkoušku nic nedáte, vždycky se můžete vrátit.