Jan Štěrba

Vlastní server to je spousta práce, ale také spousta zkušeností. Od hrátek s aptitude přes nastavovaní systému a konečně konfiguraci apache jsem se dostal k deploymentu vlastních Rails aplikací. Klasické první “Hurá!”, když se první pokus rozbělh pod hloupým (a pomalým) CGI nastalo už docela dávno. Od té doby jstem se stihl naučit pracovat s FastCGI (přesněji řečeno mod_fcgid) a všecko běhalo rychle a spolehlivě. Problém je, že fcgi procesy spawnuje (hnusné slovo, já vím) apache a proto bylo potřeba vydat se cestou k hoře jménem Mongrel.

Vezmu to ale pěkně popořádku. Development máme za sebou a v subversion se na nás směje aplikace jakš-takš připravená na nelítostné světlo intenetového světa. Co s tím?

Krok první: Capistrano

Neznáte? Ale jo, určitě znáte. Já si si s Capistranem už několikrát v minulosti zahrával, ale v podmínkách, jaké nabízel Websupport, to prostě nějak nedávalo smysl a skončil jsem u vlastních updatovacích skriptů (jo jo, mělo to i jakýsi rollback). Na vlastním stroji (nebo i vserveru) je situace kapku jiná. Capistrano je prostě nutnost. Pokud jste s Capem v minulosti také hráli, ale pořád to bylo jakési moc složité, zkuste to dnes znovu. Verze 2.x už jsou nějakou dobu venku a konfigurace je konečně jednoduchá jako facka. No posuďte sami:

set :application, "myapp" 
set :repository,  "http://path.to/yourapp/svn/trunk" 
set :user, "remote_ssh_user" 

set :deploy_to, "/deployment/root/#{application}" 

role :app, "www.myapp.cz" 
role :web, "www.myapp.cz" 
role :db,  "www.myapp.cz", :primary => true

Jasně, je to konfigurace kdy všechno běží na jednom serveru, ale stejně, je to sranda. Rozeberme si to. Název aplikace nemá žádný zvláštní význam, můžete ho dále použít jako proměnou (třeba v deploy_to). Následuje cesta ke zdrojákům v SVN. Proměnná user se hodí v případě, že vaše uživatelské jméno na lokále je jiné než to na serveru. deploy_to říká, ve kterém adresáři na serveru bude cap operovat. A pak už stačí jenom třikrát copy&pastnout url serveru, na který se bude nasazovat. Ještě před prvním spuštěním cap příkazu si vytvořte soubor script/spin. Nemusí nic dělat, ale pokud chcete může nastartovat váš první Mongrel. U mě nedělá nikdy nic. Proč? Dozvíte se níže. Teď jenom udělejte následující:

$ cap deploy:setup # vytoří adresářovou strukturu
$ cap deploy:cold # studený deploy - když aplikace ještě neběží

Je libo nahrát na sever poslední změny?

$ cap deploy

Je libo vrátit se zpět, páč se něco po*ralo?

$ cap rollback

Nakonec používate-li cgi, fcgi nebo tak něco, tak doporučuju nastavit svn:executable propety u následujících souborů:

script/**
public/dispatch.*

No a i když nic z toho nepoužíváte, udělejte to stejně. Uštříte hromadu problémů v budoucnu.

Kdok druhý: Pipe | Switch | Pipe

Jak jsem už říkal já si nějakou dobu, vystačil s krokem jedna a mod_fcgid. Jedna věc mě na tom ale docela štvala. Součástí mého deployment recipe (termínus technikus pro config/deploy.rb) musel být následující kód:

task :restart_web_server, :roles => :web do
  sudo "/etc/init.d/apache2 restart" 
end

after "deploy:start", :restart_web_server

after "deploy:restart", :restart_web_server

Prostě fuj. Nepatřím mezi early-adopters nadšence, ale o SwitchPipe se už nějakou dobu píše jako upload & run deployment řešení pro Rails. Narozdíl od mod_rails je už dnes k dispozici, tak proč ho nezkusit? SwitchPipe je jednoduchý, ale velmi mocný process-manager. Prostě spouští a zabíjí procesy jak je potřeba a to je přesně to co kombinace Rails & Monrel potřebuje. Konfigurace? Trivka! Dejme tomu, že máte nastavený virtual-host a vaše aplikace už nějak běží. Jak přejít na SwitchPipe? Nejřív si ho musíte naintalovat, což v podstatě sestává z následujícího:

$ svn co http://switchpipe.org/switchpipe1/tags/release-1.04 \
  /usr/local/switchpipe
$ cd /usr/local/switchpipe
$ cp # config.yml.example # config.yml

Pak je ještě dobré zajistit start SwitchPipe démona po startu zalinkováním script/initdscript do /etc/init.d a toho pak do /etc/rc3.d. A včíl už jenom ty aplikačky. V adresáři switchpipe/apps hledá démon změny a pokud nějaké najde hned reaguje. Konfigurujeme v YAML. Příklad najdete na stránce o konfiguraci a fakt na to není třeba nic vymýšlet. Stačí čtyři řádky, save a cluster mongrelů čeká na requesty. Poslední věci, kterou je třeba udělat, je zahodit celý den dlouhý a složitý .htacces, který generují Rails a nahradit jej následujícím:

  RewriteEngine On
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule ^(.*)$ http://127.0.0.1:10000/myapp/$1 [P]

Nezapomeňte myapp nahradit návem konfiguračního .yml souboru.

Závěr: A co ty restarty?

Ironií osudu je, že SwitchPipe zatím neumí elegantně restartovat cluster pro jednu aplikaci. Je to ale subjektivní. Jakákoli změna konfigurace clusteru způsobí jeho reload (kill všech procesů a začně se znova). Co s tím teda? Řešení se jmenuje touch a pomůže nám s ním opět Capistrano.

task :restart_cluster, :roles => :web do
  sudo "touch /usr/local/switchpipe/apps/myapp.yml" 
end

after "deploy:restart", :restart_cluster

No a teď se o deployment stará Capistrano a restartují se jenom Mongrely příslušné k aktualizované aplikaci. A ještě k tomu nastavování byla fakt sranda, žádné hledání zakopaného psa jako s mod_fcgid.

$ cap deploy

Honzo, diky za clanek. Deployment prave resim, jde mi to docela pomalu … sotva jsem si zvyknul na SVN, tak uz se zase ucit Capistrano :)

BTW tusim, ze se pise skoncil, ne zkoncil (nechci rejpat, jen pro doplneni … ja zase casto blbe pisu i/y)

Botanicus: doporucuju zacit s Capistrano co nejdriv, kdyz si na to clovek zvykne je to fakt krasa.

Chybu opravim. Z pravopisu jsem nikdy nemel dobre znamky…

Nemůžu si pomoct, ale když k deploymentu jednoduché aplikace potřebuju buď být zároveň Unixovým systémovým adimistrátorem nebo rozumět několika specializovaným nástrojům, je s Rails něco strašně špatně. Doufám že mod_rails tu bude co nejdřív (byť to nejspíš nevyřeší všechny problémy, co s deploymentem jsou).

David: Dovolil bych si nesouhlasit. Systémovým adminem být fakt nemusíš (v případě mého článku ano, obecně ale ne). Je sice pravda ze na to abys deploynul PHPkovou aplikaci, tak ti staci skoro cista instalace nejakeho linuxu, ale to srovnavas hrusky s jabkama. Rika nekdo ze s Javou je neco strasne spatne? V jave se vetsion deployment resi tak ze apache dela proxy pro Tomcat ci jiny back-end. V posledni dobe zacinam prichazet na to ze “problemy” s Rails deploymentem vlastne neexistuji. Je to proste jiny model nez Perl/Python/PHP. No a? Proc musi byt Rails jako PHP? Kez by Java mela tak jednoduche a efektivni nastroje pro deployment jako maji Rails.

David, Honza: castecne bych souhlasil s Davidem. Momentalne se snazim do deploymentu proniknout a jde mi to hure nez zacatky s Rails jako takovymi. Mozna je na tom Java hur, ale to neznamena, ze je to takhle dobre :) Capistrano jeste dejme tomu, ale nastaveni webserveru pro Rails, to je docela silenost.

honza: Nejde mi o to, že PHP web rozběhám na skoro čistém Linuxu. Vůbec mi nevadí spustit pár apt-getů nebo gem installů. Jde o to, že je potřeba řešit víc konfigurace – proxyování, recepty pro Capistrano, apod. Taky je třeba přemýšlet nad otázkami jako “kolik mongrelů mi na tuhle apliakci bude stačit?”, “jak budu obsluhovat statické soubory?”, atd. – toto u jiných aplikací bez velkých nároků na výkon řešit prostě nemusím.

Oproti tomu ke zprovoznění PHP webu mi stačí vytvořit adresář, napsat konfigurák pro Apache o 4 řádcích, symlinknout ho a restartovat server.

Sama existence toolů pro udnadnění deploymentu Rails nepřímo indikuje, že je to větší otrava, než je zdrávo.

Otázka “proč musí být Rails jako PHP?” mi přijde špatně položená. Lépe se ptát “proč to s Rails nejde tak jednoduše, jako s PHP?”.

Co se deploymentu javovských aplikací týče, tak nemyslím, že je to pro diskuzi relevantní. Nicméně pokud si dobře pamatuju, stačilo něco jako nahrát Tomcatu na server jeden WAR soubor do správného adresáře a aplikace běžela.

Povinná pole jsou vyznačena tučně.