Jak Roští dostalo Let’s encrypt

Máme za sebou víkend s velkým V. Poslední dva měsíce jsme strávili vývojem a máme hromadu novinek, které se během minulého víkendu sešly do jedné větve a nakonec se dostaly i do produkce. Některé vlastnosti ještě nejsou aktivované, protože bychom asi nespali vůbec, ale přijde i na ně.

Nejlépe bych dění shrnul asi následujícím seznamem:

  • Let’s encrypt
  • Automatické nabíhání
  • Podpora více lokalit
  • Vylepšení vývojového prostředí
  • Quoty
  • Vylepšená validace DNS záznamů
  • Nový Docker (1.12.2)
  • Nová verze Docker API (1.24)
  • Přišli jsme na to, proč byl pomalý řadič

Změn bylo hodně, u některých jsme počítaly s problémy, ale u žádné s tak velkými. Nedostupnost nebyla úplně malá, ale podařilo se nám ji udržet mezi přibližně jednou a sedmou hodinou ranní, což nám doufám odpustíte, protože odměna za to fakt stojí. Sobotní výpadek mezi 3:00 a 7:00 byl způsobem řadičem a nepočítali jsme s ním. Nicméně se nám podařilo vyřešit i to. Ale pojďme na to postupně.

Let’s encrypt

LE se stávalo takovou naší Nemesis. Celkem jsme ho implementovali třikrát. Ne že by se minimálně druhý pokus nepovedl, ale výsledek byl takový, že bychom ho do produkčního prostředí nedostali. Měli jsme to spojené s provázáním domén u aplikací s DNS zónou, což se ukázalo tak komplikované, že jsme nakonec od nasazení upustili. Několik desítek hodin práce tak vylétlo komínem. O prvním pokusu raději ani nebudu mluvit, byl to výstřel do tmy a nesedlo by to.

Nakonec jsme vyvinuli vlastního daemona, který konfiguruje Nginx tak, aby se choval jako reverzní proxy a stará se o získávání certifikátů. Je napsaný v Go. Vybrali jsme Go spíše jako pokus, ale výsledek je ohromující. Daemon má REST API, které si poradí se stovkami konkurenčních požadavků, aniž by se to nějak významně projevilo na CPU.

Let’s encrypt si můžete zkusit u své aplikace v záložce parametry, kde se dá zapnout. Musíte mít doménu nasměrovanou na náš hlavní load balancer, což jsou záznamy:

Na starém load balanceru to fungovat nebude. U LE přepínače je k tomu velké varování. Také nebudou fungovat wildcard domény, protože je LE nepodporuje. Takové domény zůstanou automaticky na HTTP a ostatní pojedou přes HTTPS.

Hned v prvních dnech jsme narazili na limit dvaceti subdomén k jedné doméně druhého řádu. S tím nic neuděláme, takže subdomény pod rostiapp.cz mohou získávat certifikát i několik týdnů. Mezitím pojedou všechny na HTTP jak jste byli zvyklí.

Automatické nabíhání

Během posledních pár měsíců jsme měli problémy s výpadky napájení. Když už došlo k restartu serveru, nemohli jsme nahodit kontejnery hned a už vůbec nemohly naběhnout sami, protože se load balancer připojuje na jejich interní IP adresy. Ty se s každým startem mění, takže jsme to museli řešit přes administraci a to chvilku trvalo.

Kvůli tomu se také stávalo, že se na chvilku a nebo v případě nějaké chyby i na delší dobu, objevila na doméně A aplikace z domény B. Minimalizovali jsme to procesními změnami, ale teď už je takové chování velmi nepravděpodobné.

Nyní když naběhne server, automaticky se nastartují i všechny kontejnery s pevně danou konfigurací (ta se dřív dynamicky měnila). I díky novému Dockeru, který už umí pracovat s více kontejnery najednou, se tak výpadek služeb během restartu zmenší z řádově desítek minut na minuty.

Doufáme, že neplánované výpadky už nebudeme mít, ale naštěstí nám tato vlastnost pomůže i při těch plánovaných.

Podpora více lokalit

Problémy se servery v posledních měsících nás vedly k tomu, že bychom se mohli porozhlédnout po nějaké cloudové službě a provozovat Roští tam. K tomu potřebujeme, aby administrace párovala server s aplikací a databázový server tak, aby byly u sebe. Nemusí to být úplně stejný server, ale mělo by to být stejné datacentrum. To znamená, že když aplikace poběží v Německu, tak nesmí používat databázi v Česku a podobně.

Nová verze administrace tuto vlastnost má a tak můžeme začít testovat různé cloudové služby a nakonec snad jednu či dvě vybrat.

Ideálně bychom se chtěli dostat do stavu, aby případné problémy nepostihly 50 % služeb, jako tomu je často teď, ale třeba jen 5 nebo 10 %.

Vylepšení vývojového prostředí

Na vývoj používáme Vagrant a jeho konfiguraci jsme řešili skriptem. Teď jsme přešli na Ansible a sestavení vývojového prostředí je díky tomu stabilnější a spolehlivější. Můžeme teď také začít pracovat na integračních testech a stagingu. Administrace je už docela velká a tahle změna nám hodně pomůže.

Staging prostčedí se subsetem produkčních dat by nám měl pomoci minimalizovat problémy, které máme při nasazování nových vlastností. Bohužel to na Roští není tak jednoduché jako u jiných projektů, protože administrace ovládá spoustu serverů a zrcadlení celého stacku je nákladné finančně i časově. Musíme najít tedy nějaký kompromis.

Quoty

Moc jsme o tom nemluvili, ale když jsme přišli o souborový systém Btrfs, přišli jsme i o možnost quote, tedy omezení diskového prostoru pro jednotlivé aplikace. Nechávali jsme to tedy být, ale občas nám to způsobilo nějaké problémy, třeba když jedna aplikace začala vytvářet velké množství obrázků v /tmp a zaplnila celý disk.

Implementace není snadná a ani naše řešení není čisté, protože linuxové quoty jsou vázané na UID a GID procesu a naše kontejnery používají obě čísla stejná, takže tudy cesta nevedla. Druhou možností je Btrfs, přece jen za ty dva pokročilo, ale quoty tam pořád ještě nejsou stabilní a nemáme na to zatím odvahu.

Tak nakonec vytváříme každé aplikaci image s filesystémem a mountujeme ho na místo, kde kontejner očekává data. Nevýhodou je, že s quotami nejde jít dolů, ale jen nahoru. I tak myslíme, že to je lepší řešení než žádné.

Tato vlastnost ještě není zapnutá, ale během pár dnů bude.

Vylepšená validace DNS záznamů

Občas se stávalo, že uživatel udělal chybu při zadávání záznamů v DNS zóně a to vedlo k problému v konfiguraci Bindu a doména zmizela z DNS po přibližně dvou týdnech. Problém je samozřejmě v naší administraci, kde jsme měli chyby ve validaci. Nová verze administrace validaci vylepšila a toto se už nebude stávat. Vycházeli jsme z chyb, se kterými jsme se v posledních pár měsících uživatelé setkali.

Nový Docker (1.12.2) a Docker API (1.24)

Nejstarší server pluto.rosti.cz ještě běžel na Dockeru 1.8 a ostatní servery také byly trochu pozadu, takže jsme aktualizovali na verze 1.12. S tím jsme změnily i verzi API, se kterou komunikuje administrace s Dockerem a to na 1.24. Nejdůležitější změnou pro vás je rychlost startu kontejnerů, protože Docker od verze 1.11 umí pracovat s kontejnery paralelně a je možné spustit stovky kontejnerů během několika sekund.

Přišli jsme na to, proč byl pomalý řadič

Minulý týden v sobotu jsme narazili na novém poli s RAID 5 na problém. Server se začal kolem třetí hodiny ranní chovat neuvěřitelně pomalu a skončilo to vesměs samovolně někdy kolem deváté hodiny ráno. Netušili jsme o co jde a asi si dokážete představit, jak nám bylo. Problém se teď opakoval a naštěstí jsme byli vzhůru a nakonec ho identifikovali. šlo o Patrol Read, funkci, která kontroluje zda v poli nejsou nějaké problémy. Díky tomu může řadič včas odstranit vadný disk.

Patrol Read bylo nastaveno na 30 % zatížení disků, ale u disků je taková hodnota dost imaginární, takže i toto číslo sestřelilo kompletně výkon IO operací. Po nastavení na 2 % se všechno uklidnilo a tento týden už to bylo v pořádku.

A co bude dál

Během prvních pár dní v tomto týdnu se objevil problém, který nás mrzí. Nasazovaly jsme třeba nový PHP image s minoritní opravou composeru, což vedlo k neočekávanému výsledku, kdy v imagi nebylo rozšíření mbsting. Snažíme se problémy vychytat procesními změnami, ale i tak občas narazíme na něco nového. V tomto případě šlo o lidskou chybu. Necommitnul jsem změny v imagích do gitu a když Martin dělal ten malý fix, tak se tam moje změny nedostaly.

V dalších týdnech se zaměříme na zmíněný Cloud, emaily a DDOS útoky, ke kterým ještě vydáme jeden blogpost, protože to je komplikovaná oblast. Taky se chystáme zapnout v současné době vypnuté quoty. Mezitím bychom ještě rádi upravili naši homepage a změnili ceník tak, aby byl čitelnější. K ceníku také přidáme speciální blogpost.

Byl to náročný víkend i týden. Nejlépe to asi zprostředkuje tento tweet:

Držte nám palce a pokud narazíte na chybu, tak nám napište.

Výpadek napájení

Hned ze začátku se chceme omluvit všem našim uživatelům za situaci, ke které došlo před týdnem v sobotu večer. Bohužel došlo k situaci, která byla nepříjemná pro všechny zúčastněné strany a došlo k několika hodinovému výpadku Roští.cz. V pražském datacentru Master DC, kde máme všechny naše servery, došlo k výpadku proudu.

O situaci jsme se dozvěděli z monitoringu a informovali o tom co nejrychleji na Twitteru. Když jsme na podpoře Masteru zjistili, co se děje, nahodili jsme část služeb vzdáleně, ale dva servery bohužel nereagovaly. Jeden z nich nebyl restartován několik měsíců a protože má ještě HDD disky, běžela na něm dlouho jejich kontrola. V době, kdy jsme do serverovny dorazili už naběhl. Druhý server, který nenaběhl, byl backup, kde se objevily problémy s konfigurací sítě, ale na Roští jako takové to nemělo žádný vliv.

Bohužel Roští není aktuálně navržené tak, aby po takovémto výpadku bylo schopné naběhnout samo. Úplně jsme nepočítali s tím, že je možné, aby došlo k vypnutí všeho najednou a tak jsme na to nebyli připravení. Když vypneme nějaký server, musíme kontejnery na něm zapnout v administraci. Používáme pro správu kontejnerů Docker a ten má jednu nepříjemnou vlastnost, že kontejner, který se vypne a zapne, změní IP adresu, což pak vede k takovým situacím na load balanceru, že doména A zobrazí obsah domény B a podobně. Zabránit tomu můžeme jen tak, že všechno řídíme z jednoho místa.

Museli jsme tedy servery zkontrolovat, nahodit administraci a pak postupně nahazovat jednotlivé kontejnery. Chvilku to trvalo a narazili jsme u toho ještě na problémy se sítí, kterých jsme si během zmatků kolem celé situace nevšimli. Některé weby tedy naběhly až druhý den ráno.

Nakonec jsme všechno dali dohromady a odnesli si z toho spoustu zážitku. Nebyli jsme jediní, komu nenaběhly všechny servery a tak to v datacentru vypadalo jak na nádraží a každý chtěl svůj monitor a klávesnici. Viděli jsme chudáka technika, který běhal s telefonem na uchu od serveru k serveru a zapínal je, protože ne všichni mají nastavené zapnutí po obnovení napájení. Také jsme si všimli, že v části serverovny, kde jsou desktopy nebyla ani noha, ale u rackové skříně byly v obležení svých provozovatelů.

Napsali jsme vyjádření na tento blog ještě ten den co se to stalo, ale nakonec jsme ho nezveřejňovali. Bylo napsané ve vlně emocí, kterou později ještě umocnila situace hned z následujícího pondělí, kdy nám někdo vytáhl jeden server ze zásuvky. To už jsme opravdu nevěděli co budeme dělat, protože to je věc, které nemáme jak zabránit. Měli jsme v poslední době více problémů a za ty největší, které nám způsobily několik hodin downtime celé služby, jsme navíc nemohli. Nějak jsme si ale poradili a doufáme, že nás teď smůla na chvilku opustí.

Jsme pod DDOS útokem 5 Gbps

Řada z vás si všimla, že máme poslední dva dny problémy s dostupností. S pomocí technické podpory datacentra Master DC se nám je daří držet na uzdě, bohužel tím, že máme vypnutý provoz směrem ze zahraničí. Ale pojďme se na to podívat popořadě.

DDOS je typ útoku, u kterého desítky tisíc počítačů z celého internetu posílají požadavky na jeden server. V našem případě jde o UDP flood a TCP SYN flood o síle 3 až 5 Gbps v závislosti na denní době. Přes noc útok ustal a ráno zase začal.

V serverech máme 1 Gbps síťové karty, takže podle grafů server končil se svým firewallem někde u 890 Mbps, což je tak 200-400 × víc, než běžný průměrný provoz. Cokoli dalšího se už k serverů nedostalo a bylo zahozeno switchi na cestě přes datacentrum. Na běžný provoz na lince už nedostalo a tak se server tvářil, že neodpovídá. Packet loss v této době byl 95 %, tedy 19 paketů z 20 se nedostalo do cíle.

Podobné útoky jsou bohužel každodenní realitou internetu a neexistuje proti nim efektivnější obrana než linka a síťové prvky, které ten provoz zvládnou.

Cílem útoku jsme s jistotou nebyli my, protože by nám útočník pravděpodobně šel po homepage, která je oddělená od ostatních aplikací. Cílem je jeden z našich klientů a bohužel nemáme jak zjistit, který to je. Všechny aplikace z nového Roští jsou schovány za IP adresu určenou pro load balancery, takže pokud někdo má útočit na našeho klienta, půjde po této adrese, což se stalo.

Naším současným opatřením je vypnutí provozu ze zahraničí. Klienti, o kterých víme, že jsou na tomto provozu závislí, tak je přesměrováváme na jiný load balancer, který není pod útokem. Nemůžeme ale takto přesunout všechny, protože nevíme, na který konkrétní web je veden útok.

Naštěstí ale víme, je infrastruktura Master DC si s něčím takovým umí poradit, takže jediným problém je, dostat tento provoz od serverů pryč. Rozhodli jsme se tedy load balancer umístit do Master Cloudu, kde je k dispozici služba Radware DefensePro. Všechen provoz tedy půjde sem a odsud bude přesměrován na server, kde běží konkrétní aplikace. Řešení je tedy stejné, jen load balancer se přesune z našich serverů do cloudu.

Radware DefensePro funguje na základě statistiky. Dokáže si zmapovat běžný provoz a všechno ostatní odfiltruje. Nemáme s tímto řešením žádné zkušenosti, ale věříme, že v Master DC vědí, proč ho mají. Teď jen doufáme, že útok opadne na dostatečně dlouhou dobu, aby se Radware DefensePro naučilo, jak naši uživatelé komunikují. Tahle změna bude vyžadovat úpravu DNS záznamů. Uživatelé, kteří mají DNS u nás, se nemusí o nic starat. Ostatním pošleme email s informacemi. Ke změně dojde během neděle, takže příští týden už pojedeme zase bez zádrhelů.

Domény a MongoDB

Máme za sebou další PoSobotu a tak je možná čas se podívat trochu zpátky. Poslední měsíc řešíme dva problémy a to je MongoDB a správu domén. Obojí se nám trochu protahuje, takže vám alespoň zkusím nastínit, kde je problém.

MongoDB nám udělala čáru přes rozpočet, když nám ztratila informace s několika přístupy. Data zůstala netknuta, ale uživatelé se k nim nedostali. Rozhodli jsme se kvůli tomuto incidentu podporu pro MongoDB na chvilku vyhodit z administrace. Pokud MongoDB potřebujete, napište nám na podporu, databázi vám samozřejmě dáme.

Abychom mohli MongoDB vrátit zpátky do administrace, musíme udělat jednu důležitou změnu a to vytvořit službu, kterou pracovně nazýváme „services“. Bude to další sekce v administraci pod aplikacemi, kde ale nebudou vaše skripty s HTTP výstupem, ale budou tam databáze, alespoň tedy ze začátku hlavně databáze.

Když se to podaří, budete si moci vytvořit vlastní instanci MySQL, PostgreSQL, ElasticSearch a MongoDB, které budou společné pro všechny vaše aplikace. Všechno bude samozřejmě připravené k použití, ale pokud máte nějaké speciální požadavky na konfiguraci, s touto službou je budete moci realizovat. Cena kontejnerů s databázemi bude stejná jako s aplikacemi. Bude tedy záležet jen na vaší aplikaci, kolik toho bude potřebovat.

S tímhle budeme mít ještě dost práce, takže nebudu říkat, že to za 14 dní bude, ale tohle je naše priorita číslo jedna hned po doménách.

Domény jsou momentálně naše největší bolest, protože jsou uloženy v databázi dost nesystémově, což nám v současnosti komplikuje implementaci SSL certifikátů přes Let’s Encrypt a další služby, které jedna za druhou implementují své API. Podporu pro domény jsme měli už dvakrát napsanou, ale nemůžeme se shodnout, jak to nakonec má být, takže oboje implementace jsme hodili do koše.

A tak jako všechny dobré věci, i tahle se nakonec vyřeší náhodou. Pustili jsme se do mikroservicy s REST API, která bude spravovat naše load balancery. Díky tomu dostaneme z administrace opravdu hodně kódu a přesuneme starosti s SSL úplně mimo ni, což nám nakonec pomůže propojit domény v aplikacích, DNS a poště tak, abychom zajistili bezpečnost i čistý design.

První dvě zahozené implementace sice fungovaly, ale při testování jsme v nich našli chyby, které bychom do produkce poslat nemohli a navíc by nás stálo strašně moc času je vyřešit. Napotřetí to tedy snad vyjde. Nechceme slibovat termíny ale už nadcházející víkend budeme snad vědět, zda to bude za 14 dní nebo někdy později.

A tak pokračujeme dál, držte nám palce a na další PoSobotě snad už s podporou SSL.

Alpha nové administrace je venku, vyzkoušejte si ji ZDARMA

Už nějaký čas bombardujeme Twitter informacemi o připravované administraci pro nové Roští. Za posledních pár dní se nám podařilo doladit a otestovat základní funkcionalitu, takže vám ji můžeme ukázat. Tímto článkem vás chceme seznámit s možnostmi, které se na vás na Roští chystají a také vás chceme poprosit o to, abyste si novou administraci vyzkoušeli. Samozřejmě zdarma.

Webhosting znáte, používáte, možná konkurenci a třeba i Roští.cz. Vždycky jsme k vám, našim uživatelům, přistupovali otevřeně. Máte relativně volné ruce při nasazování nové aplikace, máte téměř neomezené možnosti deploye a když se něco nedaří, snažíme se to vyřešit co možná nejrychleji. Kromě těchto vlastností vám přinášíme podporu pro technologie, které sami používáme. Pracujete v Djangu? To není problém! Chcete psát v JavaScriptu serverové aplikace? I na to jsme vybaveni. Potřebujete někam uložit cache? Na všech serverech běží memcached. Potřebujete redis? Stačí napsat na podporu, jeden pro vám pustíme.

Rostak_2

Bohužel, současný koncept, kdy má každá aplikace svého uživatele, vznikl primárně pro hostování Pythoních aplikací a tak nějak jsme do něj nalepili PHP. Funguje to dobře, funguje to dokonce výborně, ale nějak selháváme v rozšiřování možností. Přidání nové technologie je v současné době zásah do administrace a takový zásah vyžaduje kolečko testování, než ho k vám můžeme pustit. A jak jsme hledali řešení, řešení si našlo nás.

Kontejnery, vlastní systém pro každou aplikaci

Minulý rok se totiž objevil Docker, v té době jsme si hráli s LXC kontejnery, ale u Dockeru nakonec skončili. Hrozně se nám zalíbil a začali jsme ho používat. V současné době máme tři virtuální servery čistě pro Docker. Běží na nich 15 ostrých aplikací, včetně třeba RoundCube pro naše uživatele. Docker sledujeme přibližně od verze 0.7, tedy někdy od března letošního roku. Od té doby ho testujeme a od verze 1.1 můžeme prohlásit, že je stabilní.

Ale tohle vás asi nezajímá, spíš vás zajímá, co vám to přinese. O pár řádků výše jsem psal, že teď má na Roští každá aplikace svého systémového uživatele. Díky tomu se můžete snadno připojit přes SSH, nemusíte vůbec řešit práva a existuje bezpečné oddělení aplikaci na úrovni souborového systému a jádra.

S kontejnery jdeme ale dál a každá aplikace má díky nim svůj systém, svůj root. Díky tomu můžeme připravit hosting nové technologie s minimálním zásahem do administrace. Zároveň mnohem efektivněji můžeme hlídat, jak se která aplikace chová, například kolik vyžaduje procesorového času, paměti RAM nebo I/O operací.

Hlídáme využité prostředky

Bohužel se nám na současném konceptu stává, že některé aplikace využívají třeba procesor výrazně více než jiné. Například jedna instance OwnCloud s jedním uživatelem a dvěma připojenými synchronizačními klienty využije 77× více procesorového času než WordPress, který obslouží 3500 requestů za stejný časový úsek. V praxi to u OwnCloud vypadá tak, že jedno jádro CPU 100% vytíží na 20 minut z 60. Tento nepoměr jsme se rozhodli regulovat tak, že začneme účtovat i procesorový čas.

Určitý balík, který bude odpovídat přibližně 5 % průměrného zatížení jednoho procesoru, dostanete zdarma. Pokud to překročíte, budeme vám z kreditu strhávat za každou propálenou hodinu nějakou malou částku. Výše zmíněný WordPress například při popsaném zatížení vystačí s hodinou procesorového času týdně pouhým zapnutím pluginu WP Super Cache. Ve světle této informace věříme, že naši motivaci chápete.

Nejsme ještě rozhodnutí kolik to bude, ale pomůže nám to udržet vaši aplikaci v provozu za jakýchkoli okolností. Nebudeme vám psát e-maily, jak vaše aplikace vytěžuje server a byli jsme nuceni omezit přidělené systémové prostředky. Napíšeme vám, že vaše aplikace aktuálně využívá tolik a tolik prostředků, že jsme se postarali o to, aby jela bez problémů a že vás to stojí tolik a tolik.

PHP

Máte webový projekt napsaný v PHP a rozhodnete se pro Roští. Vytvoříte si v administraci aplikaci s tím dostanete:

  • Pevně přidělené množství paměti RAM (64 MB až 1 GB)
  • Pevně přidělené místo na disku
  • Plnohodnotný SSH přístup
  • Možnost ovlivnit nastavení libovolného parametru v php.ini
  • Výběr z různých verzí PHP (5.2.x, 5.3.x, 5.4.x, 5.5.x, 5.6.x, ..)
  • HHVM 🙂
  • Možnost zvednout prioritu na procesoru
  • GIT, Mercurial, SVN

Ze seznamu je patrné, že Roští bude některé parametry hostingu garantovat. Nestane se, že by serveru došla paměť, protože paměť si u nás zaplatíte a nikdo jiný ji mít nebude. Stejně tak to bude s prostorem na disku. Pokud navíc máte třeba e-shop a potřebujete, aby jel rychle za každých okolností, budete mít možnost zvednout prioritu vaší aplikaci a ve špičce tak bude mít k dispozici 4x více procesorového času než „běžné“ aplikace.

alpha3

Na svět se pomalu klube HHVM. Sice není několikanásobně rychlejší, jak se nás snaží vývojáři přesvědčit, ale pokud pro něj svou aplikaci optimalizujete, tak rychlejší bude. Každopádně u nás ho budete moci použít. Dokonce na něj můžete přepnout přímo u běžící aplikace a pak se zase vrátit zpět. HHVM vychází o kousek lépe se systémovými prostředky i u neoptimalizovaných aplikací, takže jeho použitím můžete ušetřit i nějaké ty peníze.

S kontejnery se vrací PHP zpátky jako mod_php. Na FCGI jsme přešli kvůli oddělení na úrovni uživatelů a to teď padá, protože každá aplikace má vlastní Apache a tak mod_php nic nebrání. Pokud vám to je ještě málo, tak vás určitě potěší, že na Roští nemáme problémy s APC cachí. V blízké budoucnosti ale budeme preferovat kombinaci PHP-FPM a serveru Nginx. Pravdou je, že mod_php je pomalu na ústupu. Je to pohodlné spojení mezi Apachem a PHP, ale není to nejefektivnější způsob, pod jakým může PHP servírovat obsah.

Mimochodem, už jste slyšeli o PHP implementovaném v Pythonu? Obraz do administrace ještě nemáme, ale bude 🙂

Python

Pro Python částečně platí seznam uvedený u PHP, něco málo se ale samozřejmě změní. Tak si to sesumírujeme:

  • Garantované systémové prostředky (CPU, RAM, disk, ..)
  • SSH přístup
  • Python 2.7.x, 3.4.x, PyPy 2.x
  • Možnost přepínat mezi verzemi Pythonu
  • GIT, Mercurial, SVN

alpha1Python je naše vlajková loď. Pro něj Roští vzniklo a jen tak ho nepustí. Chlubíme se nejlepší podporou Pythonu v České Republice a s kontejnery bude ještě lepší. Že by o něj nebyl zájem se říci nedá, protože na Roští je polovina aplikací napsaných v Pythonu, takže nemáme důvod mu opět nevěnovat maximální péči.

Budeme nyní podporovat více verzí Pythonu včetně PyPy. Více verzí už jsme nabízeli, ale teď máme tuto vlastnost mnohem lépe implementovanou. SSH přístup už je samozřejmostí a velkou změnou je provoz aplikace přes Gunicorn místo uWSGI. Gunicorn je na rozdíl od uWSGI napsaný v Pythonu a stará se dobře o jednu věc, servírování stránek z pythoního kódu. uWSGI to šlo sice také dobře, ale počet jeho funkcí roste závratným tempem a my je rozhodne nevyužijeme. Takže Gunicorn.

Stejně jako u PHP půjdou přepínat verze Pythonu. Na rozdíl od PHP to bude chtít ale trochu vaší asistence. Pro každou aplikaci se vytváří virtualenv a ten musíte při této změně smazat, protože je závislý na konkrétním Pythonu. Můžete to udělat i dodatečně, když aplikace nenajede.

U Pythonu jsme se občas setkávali s dotazy, jak vůbec novou aplikaci nasadit. Pokud vytvoříte novou aplikaci nyní, tak uvidíte funkční web s několika informacemi. V adresáři, kam nakonec svůj kód nakopírujete už tedy budete mít něco funkčního a budete podle toho moci nastavit všechno potřebné. Současná alpha má tuto stránku ještě dost zmatenou, ale na tom pracujeme.

Node.js

Když jsme zveřejnili dotazník na Twitteru, mysleli jsme si, že to jen tak projde timelinou bez zájmu, ale opak byl pravdou, zaujal vás a my jsme za to hrozně rádi. Každopádně zpráva byla jasná, chcete lepší podporu Node.js.

Současná administrace nabízí Node.js v beta režimu. Podpora je otestovaná, ale beta tam zůstala, protože se nám úplně nelíbí, jakým způsobem jsme to uchopili a chybí nám ještě MongoDB databáze, která je pro Node.js prakticky neoddělitelnou sestrou.

Vůbec jsme Node nechtěli do alphy zařazovat, ale protože o něj máte zájem, nakonec jsme obraz připravili, takže kromě PHP a Python, můžete vyzkoušet i hostování aplikace běžící pod Node.js 0.10.32.

Node.js podpora na novém Roští si poradí s package.json soubory a při každém startu aplikace volá npm install. Stejně jako u PHP a Pythonu máte hned ze začátku dostupný skript, který vám zobrazí na adrese, kterou jste nastavili v administraci, základní informace. Nepřijdete tedy do čistého adresáře, ale budete mít čeho se chytit. Dejte si pozor na to, že Node.js aplikace musí běžet na portu 8000, jinak ji nenajde load balancer.

Další jazyky a databáze

alpha2Všemi změnami popsanými na začátku tohoto blogpostu, jsme si otevřeli jsme cestu k dalším technologiím a jazykům. Například z databází podporujeme zatím PostgreSQL a MariaDB, ale tentokrát nenecháme uživatele Node.js na holičkám a přidáme i MongoDB. Redis a Memcached zatím také nemáme, ale pracujeme na tom a určitě to bude hotové do bety.

Měli jsme dlouhé rozpravy nad podporou Ruby, Javy, Go a dalších nových i starších technologiích. Nové Roští je navrženo univerzálně a počítá s čímkoli, jen narážíme na to, že tyto jazyky nepoužíváme. Pokud máte s jazyky výše zkušenosti na webu a chtěli byste nám pomoci, ozvěte se nám, probereme, co vývojáři od hostingu chtějí.

Staré aplikace

Výše je popsáno opravdu mnoho změn a tak se možná ptáte, co bude se současnými aplikacemi. Teď vám mohu říci, že nic, všechno zůstane při starém určitě ještě dlouhou dobu. Po vydání stable verze nové administrace vypneme přidávání aplikací ve staré administraci a budeme se snažit uživatele přesvědčit, aby migrovali.

Není to první změna konceptu v historii Roští. K první došlo na přelomu roku 2012 a 2013, po třech letech provozu a přinesla zmiňované oddělení aplikací, kdy má aplikace vlastního systémového uživatele. Byla to reakce na případy, kdy u nás měli uživatelé třeba 20 aplikací pod jedním uživatelským jménem, které navzájem nebyly nějak odděleny. V té době jsme vůbec nepočítali s tím, že by někdo mohl hostovat tolik aplikací zrovna na našem hostingu 🙂

Kolik za to, shrnutí a další informace

Připravili jsme pro vás službu, která současnou dobu neurazí. Inspirovali jsme se vlastní prací a přinesli vám to, co používáme sami. Těžíme maximum že současných open source technologií a dáváme vám do ruky nástroj, ve kterém spravujete hosting a nemusíte nic řešit. Nemusíte řešit, že na vaši aplikaci přišlo moc lidí, nemusíte řešit správu vlastních serverů. Od toho jsme tady my uděláme vše co je v našich silách, aby vaše služba běžela co nejlépe.

Přístup do alphy najdete na adrese nove.rosti.cz, cokoli tam uděláte je zdarma. Administrace i hosting jsou stabilní tak, jak to jenom v alphě šlo. Nemusíte se bát, že vám bude vytvořená aplikace padat, protože obrazy, které používáme, testujeme už několik měsíců a víme, že fungují. Možná to trochu zaskřípe ve webovém rozhraní, ale od toho alphu spouštíme. Vývoj nešel ve všech okamžicích úplně dobře, někdy jsme narazili na malou nesouvislost:

Pak jsme řešili bug schovaný na pěti řádcích 4 hodiny. Ale povedlo se 🙂

A co je v alphě k dispozici:

  • Vytváření aplikací
  • Přístup přes SSH
  • Nastavení přidělené paměti
  • Výběr technologie
  • Správa PostgreSQL a MariaDB databází

Některé funkce jsme v administraci ještě schovali, protože nejsou kompletní, některé jsme nechali, abyste si je mohli prohlédnout, ale pokud si třeba dobijete kredit, nebudete přesměrování na platební bránu a podobně. Během následujících dnů budou další funkce přibývat, protože jsme je doteď nestačili dostatečně zestabilizovat, ale moc nechybí. Například mazání aplikací. Zároveň přibudou i některé další obrazy. V plánu jsou další verze PHP a HHVM.

Dneska jsme našeho hada popohnali bičem a i když nebudeme zatím uvádět žádná konkrétní data, tak to, do čeho jsme vám dnes dali přístup, bude za pár týdnů finální produkt. A teď šup, běžte se kouknout, jak vypadá hosting hodný roku 2014, jak vypadá hosting, který se nebojí vám dát do ruky moc nad vašim kódem i daty.