A cloud hosting beúszott az életünkbe. Nincs is egyszerűbb dolog, mint rábízni az üzemeltetést egy erre szakosodott csapatra, akik megoldják a skálázást is. A tapasztalatok nagyon jók. Rengetegett fejlődött ez terület. Rails csapatként mi eddig a Heroku, az Engine Yard és a Joyent szolgáltatását próbáltuk ki. Most a Heroku-val kapcsolatban írok le pár hasznos tanácsot a kezdéshez.
Elinduláshoz érdemes átböngészni a Heroku fejlesztői oldalait: http://devcenter.
Figyeljünk rá, melyik stack-et használjuk.
A Heroku nem homogén platform, hanem több, különböző tulajdonsággal rendelkező szoftver környezet is elérhető benne. Telepíteni rájuk és használni ezeket ugyanúgy kell, viszont az egyes stack-ek más és más filozófia mentén lettek felépítve, más alap szoftverek futnak rajtuk. Ez mit is jelent? A legrégebbi stack az aspen, majd a bamboo. Ezeken például még reverse http proxy is fut(Varnish), vagyis a platform komoly cache képességekkel lett felvértezve. Időközben kiderült, hogy ez nem jó irány. Az a jó, ha minél kevesebb réteg van a backend és a felhasználók között. Így a cedar stack már ezt a funkciót nem tartalmazza. Általánosságban igaz: friss projektekhez a legújabb stack használható szinte kizárólag, hiszen a szoftver verziók miatt a régebbiekre nem is lehet sokszor felrakni.
Új alkalmazást így hozhatunk létre cedar stack-re:
$ heroku create my-app-name --stack cedar
$ heroku stack --app my-app-name
aspen-mri-1.8.6
bamboo-ree-1.8.7
bamboo-mri-1.9.2
* cedar (beta)
Ha már fut a friss ropogós Rails alkalmazásunk, akkor használjuk is ki az előnyöket.
A Rails 3.1 legnagyobb újdonsága az asset pipeline, ami beemeli a js, css fájlokat is a keretrendszer alá. Így megoldhatóvá válik az előfeldolgozásuk. Egy éles alkalmazás viszont már nem szabad, hogy asset generálással foglalkozzon. A Heroku esetében külön bonyolítja a helyzetet, hogy a futó alkalmazás nem írhat a fájlrendszerbe, hiszen az írásvédett. Hogyan oldjuk meg ezt a kérdést? Előre legenerálhatjuk egy projekt js és css fájlait a következő paranccsal:
RAILS_ENV=production rake assets:precompile
Az így létrejött fájlokat(public/assets) nyugodtan elmenthetjük a verziókezelőbe is. Ha ezt az utat választjuk, akkor egy csomó felesleges fájlt fogunk verziózni, cserébe telepítéskor nem kell asset generálással foglalkoznunk. A másik, szebb megoldás az, ha rábízzuk mindezt a Heroku-ra. Telepítéskor ugyanis megpróbálja lefuttatni a fenti parancsot ha nem találja a projektben a public/assets könyvtárat. Arra kell mindössze figyelni, hogy eközben az alkalmazás nem tud csatlakozni semmihez! Szeparált környezetben fut. Nincs adatbázis sem! Így egyrészt minden külső szolgáltatás initializálását úgy kell megtenni, hogy hibatűrő legyen. Másrészt az adatbázis csatlakozás megakadályozásához pedig a következő beállítást kell elhelyezni a config/application.rb fájlba:
config.assets.initialize_on_precompile = false
Ha ezekre odafigyelünk, nem érhet nagy meglepetés. Nagyon kezes platfom a Heroku, érdemes megtanulni rendesen használni.
| És egy közérdekű közlemény: továbbra is keresünk RoR fejlesztőket, bővebben a weboldalunkon olvashatsz az állásról. |
