| Du må logge inn for å se denne siden | ||
 irb.noSamlingsplass for rubyister i Oslo Sonen følges av 238 medlemmer.  irb.no er en sone på Origo. Rails-hostingJeg sitter her og lurer på hva de gode Rubyister i Norge har å mene om Rails-hosting. Eller mer korrekt, vedlikehold av Rails-hosting. Utfordringene med å hoste en Rails-app har minket med årene til et nivå hvor det er så enkelt som å sette opp en vhost og pushe til et git-repo. Sannsynligvis roper du ganske enkelt på Passenger når du setter opp vhosten din. Capistrano gjør deploys til en breeze. For meg personlig har utfordringene heller begynt å vise seg i form av at jeg i større og større grad må leke sysadmin for virtuelle servere, noe jeg i mindre og mindre grad liker spesielt godt siden jeg helst vil bruke tiden min på å skrive flere webapps. Jeg er lei av å følge security-announce, oppgradere pakker, gå til krig mot Xen og generelt bekymre meg for at en server en plass skal tryne i natt. Dette er det selvsagt folk som har skjønt og tilbyr spesialisert Rails-hosting for en neve dollars, samt kan tilby 24/7 pro-aktiv support av hele infrastrukturen din for en neve dollars mer. Engine Yard er nok den største aktøren som kan tilby alt dette og mer til. Heroku er samtidig et godt og rimelig alternativ, dersom du ikke behøver all whizz-bangen du får med EY. Problemet er bare at Engine Yard og Heroku er basert på EC2 i USA, og 100ms latency over dammen kan ofte være grunn nok til å lete andre steder. Man kan selvsagt hive seg på EC2 i europa på egen hånd med poolparty, chef, load-balancing og redundante instanser & whatnot på alle plan, men da er vi i Sysadmin-Land igjen. Det jeg vil spørre dere om er:
Er vi alle sysadmins på deltid? 
| ||
Kommentarer
Jeg hoster mine små koseapper (f.eks figureoutwhen.com) hos Linode. De har VPS-er i UK. Da må man sette opp ting selv, naturlig vis, men det tar vel knappe timen med Ubuntu. Drifting vet jeg lite om, da jeg aldri har driftet apper med noe særlig trafikk.
Takk, August. Drifting hadde vært et mye bedre ord å bruke i posten min. Oppsettet har aldri vært noe problem. Cloud-oppsett med Poolparty og Chef kan til og med være gøy. Men moroa forsvinner noe (for meg) når det går over i drifting og support, backups og pingdom.
Jeg har en følelse av at uansett hva man velger blir man nødt å velge hvor skillet mellom det du gjør og det drifteren/ISPen/whatever gjør. Definere hva som ligger i SLA-en, om denne finnes eksplisitt eller ikke.
Selv om man har en leverandør som har alarmer som går av når appen ikke svarer på HTTP natt til første nyttårsdag er man nødt å gå opp en skillelinje mellom du som lager appen og de som drifter den, og dette er en øvelse man er nødt til å være skikkelig nøye med.
Helt “nederst” i kjeden er ting som å sørge for at XEN kjører og at sikkerhetspatcher installeres. Personlig er dette jeg ikke har noen interesse av. Helt “øverst” i kjeden er for eksempel varslinger om 500-errors i appen din; dette ville jeg mene det er utenkelig å sende til en ekstern leverandør. Og midt mellom disse ytterpunktene finner man alt det andre.
Vi bruker Linpro til å drifte Gitorious.org, og de sørger for ganske mye (og får betalt for det). En av ulempene med dette er at vi er nødt til å gi opp muligheten til å gjøre som vi vil på serverne og heller sende en bestiling når vi vil ha gjort noe. Siden vi selger tjenester til andre rundt Gitorious.org og disse tjenestene er omfattet av en SLA er det egentlig ikke noe valg å ikke ha en SLA mot vår leverandør, men det er en overhead forbundet med en slik “full service”-løsning.
I den andre enden av skalaen leier vi en server hos ITPays, et lite men solid firma som holder til her i byen. Der leier vi blant annet en Linuxboks som er virtualisert og vi selv setter opp nye instanser når vi trenger det. De tar seg av å patche host-OSet og stiller med noen ekstratjenester som en server vi kan ta backup til, men resten ordner vi sjøl. De årene vi har hatt denne serveren har det vært overraskende lite jobb med den, men det er ingen andre enn oss som kan håndtere situasjonen som oppstår første nyttårsdag, bortsett fra helt basic ting som strøm- og nettbrudd.
Alt til sitt bruk…
Bra innspill her Marius. Jeg er helt enig i at man må trekke linjen en plass. Jeg tror jeg har funnet ut at linjen min går direkte under applikasjonen. 500 fra min kode er og blir mitt bord og jeg ville ikke hatt det på noen annnen måte. At openssl må oppgraderes vil jeg derimot ikke bry meg med. Klare definisjoner av hvor et ansvar ligger er key, men problemet mitt er å finne nære samarbeidspartnere som kan ta seg av det ansvaret jeg ikke vil ha som en del av arbeidsdagen min. For å introdusere en ny skala:
I den ene enden leier jeg en dedikert server i Oslo hvor jeg drifter host-OS, alle domUs og manuelt håndterer stagingmiljø og backups. I den andre enden finner man Engine Yard på Ensjø.
Engine Yard på Ensjø? Hvorfor bruker ikke de da europe? Dette er interessant for meg, som selv kjører på EC2. Men jeg har ikke holdt på lenge nok til at jeg føler jeg har hatt noen problemer. Jeg antar man kan scripte en del, eller fikse på en instans, ta snapshot eller lignende og bytte ut instansene. Kom på irb-møtet da, jeg vil gjerne diskutere rundt det!
Hvorfor EY er US-only: Europe availability
Jeg brukte railsmachine.com for en kunde. Betalte ca 12000,- årlig for en “halv server”. Måtte sette opp en automatisk restart med jevne mellomrom, og installere MTA selv, men ellers gikk det greit. Dette er min første og eneste rails-app, så ikke testet noen andre.
Ellers bruker jeg pair.com i USA til en rekke av mine php-applikasjoner. De tilbyr også Rails via Passenger, men jeg har aldri testet dette.
pair.com har jeg alltid vært godt fornøyd med. De tar seg av alt av oppgradering, installasjon etc, men har da også et strengt regime i forhold til hva som kan installeres, og gir kun begrensede rettigheter.
Hvor mye OS-drift er det egentlig? Hvor mange timer pr maskin bruker du, Rune?