Jednoduché nasazení Sinatra aplikace (thin, nginx)

7.6.2011 13:56 | Přečteno: 1064× | ruby | poslední úprava: 7.6.2011 13:58

Jako základní kámen celé aplikace byl položen Ruby interpreter ve verzi 1.9.2. V případě Ubuntu je třeba provést kompilaci ze zdrojových kódů.

wget ftp://ftp.ruby-lang.org//pub/ruby/1.9/ruby-1.9.2-p0.tar.gz
tar -xvzf ruby-1.9.2-p0.tar.gz
cd ruby-1.9.2-p0/
./configure --prefix=/usr/local/ruby
make && sudo make install

A jako vhodným doplňkem pro práci s Ruby se jeví přidání /usr/local/ruby/bin do PATH. Například úpravou /etc/environment . Po těchto několika oddechových minutkách přijde na řadu instalace důležitých gemů. (Pozn. Svou konfiguraci jsem rozjížděl na VPS u Virtualmaster a všiml jsem si, že 64MB RAM je jen pro instalaci pomocí gem nevyhovující konfigurace)

gem install sinatra gem install thin

Pro otestování serveru nám postačí opravdu jednoduchá Sinatra aplikace, která zabere 5 řádků i s nastavením interpreteru (což vlastně netřeba dělat) a kódování.

#!/usr/local/ruby/bin/ruby
# encoding: UTF-8
get '/' do
        "Ono to funguje!"
end

K samotné konfiguraci webového serveru thin - budeme potřebovat rackup soubor (.ru) a yml konfigurační soubor.

Rackup soubor v podstatatě obsahuje jen:

# encoding: UTF-8
require 'sinatra'
#.rb soubor s vaší aplikací, stejný adresář
require 'app'
run Sinatra::Application

YML soubor vypadá zhruba takto:

---
    environment: production
    chdir: /cesta/k/aplikaci
    address: 127.0.0.1
    user: root
    group: root
    port: 4567
    pid: /cesta/k/aplikaci/thin.pid
    rackup: /cesta/k/aplikaci/config.ru
    log: /cesta/k/aplikaci/thin.log
    max_conns: 1024
    timeout: 30
    max_persistent_conns: 512
    daemonize: true

Na řadu přichází samotné 'nahození' thin serveru. Když jsem poprvé spouštěl thin server, docela jsem koukal, že si můžu vybrat počet serverů, které budou spuštěny. Pro malý webový projekt to asi nemá smysl, ale u velkých projektů to asi nějaký smysl mít bude kvůli otázce dostupnosti. O možném řešení ale až za chvilku.

thin -s 1 -C config.yml -R config.ru start

Na základě údajů v config yml se nám na pozadí rozběhne server na adrese 127.0.0.1 a portu 4567. Návštěvníky svého velkolepého projektu ale asi těžko budeme zvát na domena.tld:port, a proto potřebujeme nějakým způsobem donutit tento server, aby naslouchal na portu 80. Mohli by jsme v config.yml upravit port na 80, ale tím pádem by nám jeden fyzický webový server sloužil pouze pro jednu prezentaci. Nehospodárné. Jako výhodnější varianta se jeví použití takzvané reverzní proxy, v našem případě webový server nginx (stejně tak poslouží i lighttpd či Apache2). Konfiguraci serveru nginx upravíme tak, aby veškeré požadavky směrované na adresaserveru:80 směroval na 127.0.0.1:4567.

Konfiguraci lze samozřejmě spojit s nastavením virtualhostů a podobných záležitostí, ale my pouze upravíme default virtual host, který by měl být po apt-get install nginx v adresáři /etc/nginx/sites-available/.

Přirozeně nás bude zajímat jen location /, takže můžeme s klidem v srdci celý konfigurační soubor pročistit a použít z něj nepatrnou část.

server {
    listen   80;
    server_name  localhost;
    location / {
        error_page 502 504 = @fallback;
        proxy_pass      http://localhost:4567;
                }
        location @fallback {
        proxy_pass      http://localhost:4568;
    }
}

Poměrně zajímavá část začíná u @fallback. Pokud při spouštění thin použijeme -s 2 - spustí se nám dva servery na portech 4567 a 4568. Pasáž error_page 502 504 = @fallback; říká serveru, že pokud výchozí server (http://localhost:4567) vrací chybovou hlašku 502 nebo 504 - dojde k přesměrovaní na location @fallback. A fallback směřuje http://localhost:4568. A nakonec -

service nginx restart

pošle náš server do hry. Hodně štěstí!        

Komentáře

[Shadow]

Pěkný článek, díky. Mám nicméně otázku - není lepší/rychlejší místo TCP/IP použít sockety?

[Shadow]

Btw, netuší někdo, jak se "unix socket" překládá do češtiny?

[mess]

Ve škole do nás tlačili pojem "schránky" (FIT VUT). Ale moc se mi to nelíbí.

[zxtlpn]

Nepřekládal bych to, je to prostě termín.

[defiler]

Díky, informace popsané v článku jsou velmi zajímavé . . . musím prozkoumat :D

[Shadow]

Jak jsem zjistil, s Ruby jsou momentálně problémy, pokud chci nasazovat více různých aplikací, protože některé aplikace (např. Redmine) běží na Ruby 1.8, zatímco pokud člověk vyvíjí, tak by rád vyvíjel na aktuální řadě 1.9. Passenger do Apache umí použít jen jeden Ruby interpret, takže jsem to u sebe nakonec vyřešil přes RVM, pomocí kterého nainstaluji, co aplikace potřebuje, plus thin, který pak socketem propojím s Nginx. Jde to samozřejmě i přes TCP/IP, ale unixové sockety by měly být už z principu rychlejší.

[xHire]

Ono se to takhle nějak řeší i „oficiálně”, byť by se mi nějaké elegantnější řešení také zamlouvalo. :c) (Mít možnost mít víc IPv4 adres, tak je řešení nasnadě, ale bohužel.) A dole v odkazovaném článku je i pěkné srovnání výkonu při použití TCP vs. UNIX socketů hezky v grafu.

[xHire]

Nebylo by bývalo jednodušší do toho nginxu dát passenger?

Navíc trojka integruje právě nginx v sobě, takže býval stačil pouze passenger -- není potřeba prakticky vůbec žádná konfigurace, jen pár malých nezbytností.

[defiler]

Konfiguraci jsem dělal po dlouhé době...vzpomínám si na mou poslední snahu nakonfigurovat NGINX s passengerem. No byla to katastrofa. Ale určitě to vyzkouším. Díky za info.

[xHire]

Při použití integrovaného nginx serveru v passengeru se právě nginx nekonfiguruje vůbec.

[retroslava]

Místo obyčejné kompilace ruby bych doporučil RVM. Pro každý projekt je potom možné používat gemsety a jinou verzi Ruby nebo testovat na ostatních implementacích (JRuby, REE, ...).