Rails koos Unicorni ja Nginxiga
Lühidalt on aga lugu selline_
Nginx server
- serveerib staatilisi faile railsi /public kaustast
- kõik muu suunab UNIXi socketile
Idee on selline, et kõige ees on Nginx, mis teeb dünaamilist mass-virtualhostimist ja kõikide RAKENDUS.zoo.tartu.ee domeenimede jaoks üritab leida sobivat UNIXi socketit, kuhu päring edasi anda.
Unicorni server:
- käib plain-useri õigustes
- käima tõmmatud Railsi kodukaustast: bundle exec unicorn -c unicorn.conf -D -E <environment>
- kill -USR2 teeb no-downtime restardi, st Unicorn tõmbab uue masteri käima ja see loadib koodi ja kui ta esimese lapse teeb, siis too saadab vanale masterile surmasõnumi. kasutajate jaoks downtime ei ole.
God:
- tõmmatakse käima local.stardist: /usr/local/bin/god -c /srv/w/app/config/meedia.god
- jälgib, et Unicorn käiks
- jälgib, et Redis käiks
- jälgib, et 3 Resque protsessi käiks
Godi pluss on see, et tema konf on Ruby script, mistõttu on ta ülipaindlik.
Teine võimalus on kasutada God asemel Blessingut.
Blessing hooliseb Socketite olemasolu eest (blessing on inglise keeles ükssarvikute kari), mis on käivitatud selliselt, et leiab üles kõik /srv/w/*/config/unicorn.conf failid ja igaühe kohta tõmbab üne Unicorni käima. Seejärel jääb 10s intervalliga jälgima, kas faili muutmisaeg on muutunud, et Unicorni restartida.
Blessing on võimalik, et nõdram. Eesmärk on see, et ta monitoorib shell-glob mustriga kaustapuud (nt /srv/w/*/unicorn.conf) ja kui avastab mõne uue unicorn.conf faili, siis tõmbab uue Unicorni käima. Kui mõni ära kaob, tapab protsessi maha jne.
nginxi ja Unicorni mass-virtual-hostingu konfinäite:
Seal see Unicorni conf on suht generic ja sobib praktiliselt üks-ühele iga Railsi jaoks, mis Unixi socketi kaudu ühendub front-end serveriga.
