Velká várka oprav

Máme za sebou více jak dva měsíce provozu nové administrace a tak jsme se pustili do nějakého opravování. Něco už je nasazené, něco bude. Ale začneme od začátku.

Minulý týden jsme se byli podívat na LinuxDays a říct vám něco o Dockeru na webhostingu. Rozhodli jsme se to pojmout propagačně a zaměřit se na pokročilejší uživatele, kteří už o Dockeru něco vědí. Přednášel jsem já a moji nervozitu prosím přehlédněte 🙂

A teď už k opravám. Možná jste postřehli, že příkaz „enable-redis„, který vám nakonfiguruje v kontejneru Redis databázi, nefungoval. Používal konfiguraci s chybami a navíc pro jinou verzi Redisu. Naše chyba, málo jsme tuhle vlastnost otestovali, teď už to je opravené.

Měli jsme problém s tím, že se nám na serverech začali množit kontejnery, ke kterým nepatřila žádná appka. Ukázalo se, že někdy v minulosti došlo k výpadku RQ workera pro jednu z našich front, což vedlo k tomu, že se nějaký čas tato chyba projevovala. Důsledky jsme identifikovali a odstranili až nyní. Píši to jen pro zajímavost, protože uživatele to nějak neovlivnilo.

Další problém byl způsobem chováním Dockeru, které popisuji i v přednášce nahoře – mění se chování Docker API. I když používáme stále verzi API 1.18, tak s aktualizací na Docker 1.8.2 došlo k odstranění cpuShare parametru z volání API, které vytváří kontejner. Změnu chápu, ale že se to promítlo i do starších verzí API, to už méně. Výsledek byl nefunkční přepínač „High CPU“ v administraci. Naštěstí byla oprava jednoduchá a nasadili jsme ji rychle.

Další chyba byla logická a týkala se hlášky o tom, že je kontejner v chybovém stavu. Ta se má zobrazit 60 sekund poté, co nebyl kontejner vytvořen, i když o to uživatel skrze administraci požádal. Při rozhodování jestli hlášku zobrazit nebo ne, jsme používali datum vytvoření kontejneru a aktuální čas, takže při změně parametrů se objevila hned, jak se spustil task s vytvořením na pozadí.

Na přání jednoho z uživatelů jsme upravili PHP kontejner tak, aby obsahoval modul pro MongoDB. Z PHP je tedy nyní možné přistupovat do Monga.

PHP image jsme také trochu překopali. Nyní už podporujeme jen verze 5.6 a nově 7.0. Starší aplikace mohou zůstat na současných imagích. Nové už musí použít tyto. Pokud budete chtít starší verzi i k nové aplikaci, napište nám prosím na podporu. V současné době je využití starších verzí opravdu minimální. PHP 7.0 ještě nepoužívejte v produkci, máme ji jen pro otestování. Chybí ji většina modulů, například GD.

Dále jsme na homepage upravili stránku s ceníkem tak, aby vás méně mátla. Ujasnili jsme cenu za zálohování a za certifikáty.

Na starém Roští se objevil problém s placením přes GoPay. Došlo k nějakým úpravám API na straně GoPay, o kterých nám zapomněli říct 🙁 Podpora pro GoPay v novém Roští je na cestě, ale ještě pořád máme před sebou nějaké důležitější tasky. Snad se tedy dočkáte v listopadu.

U PHP kontejnerů se při přesměrování objevil problém, kdy Apache přidával port 8000 do URL adresy a stránka pak nefungovala. Trápilo nás to dlouho, ale konečně jsme to vyřešili. Už se tedy tohoto bugu nemusíte bát.

A to je všechno. Většina oprav už je nasazena, další se objeví během zítřka. Děkujeme za podporu a budeme se těšit u dalšího reportu.

Už to je dobré

Mám radost, že vám mohu oznámit, že teď už je vše v pořádku. Je neděle večer, server má load 0.4 a běží už více než 24 hodin bez zádrhelu. Dnešní plánovaný výpadek jsme museli trochu urychlit a provést ho už v pátek v noci a pokud sledujete náš status twitter, víte že to dopadlo dobře.

Tento servisní zásah jsme měli připravený, takže jsme se výrazně nezasekli. Služby na novém Roští jsme vypnuli kolem 0:30 a kolem 2:30 bylo hotovo. K poškození souborového systému tentokrát nedošlo, takže jsme neměli problémy s nahozením služeb. Jedeme teď na kombinaci Docker+ext4+aufs, což byste měli výrazně pocítit na výkonu IO operací, samozřejmě v tom dobrém slova smyslu 🙂 Kontejnery jsou teď opravdu svižnější.

Btrfs jsme původně vybrali, protože Docker týmem byl označen za stabilní a neměli jsme s ním po celý rok vývoje administrace žádné problémy. Hodně se nám líbili funkce snapshotů, které jsme používali pro zálohování a quote, které nám pomáhali omezovat množství dat, která můžete uložit. Spolehlivost je ale samozřejmě důležitější, takže tyto věci budeme řešit tak, jak jsme je řešili doposud.

Byl to náročný víkend, takže to jen shrnu. Všechno už je v pořádku, systém je teď rychlejší a i když vyšel Docker 1.8. teď rozhodně aktualizovat nebudeme 🙂

Doplněk: Aktualizovat budeme asi až na Docker 1.9, protože 1.8 pro nás nepřináší nic zásadního, ale 1.9 bude podporovat volume pluginy a to nám dá do ruky nástroj, jak decentralizovaně ukládat vaše data. Díky tomu by nás podobné problémy v budoucnu netrápily, protože bychom mohli migrovat vaše aplikace mezi servery v řádu sekund.

Každý commit se počítá

Možná víte, že většina nových funkcí na Roští vzniká během pravidelných hackathonů, které se konají jednou za měsíc. Zbytek měsíce službu udržujeme, opravujeme chyby a sbíráme podněty na další hackathon. Poslední víkend jeden hackathon proběhl, nazvali jsme ho HackX+1 a tady je malý souhrn.

Nejdříve název. Je to první hackathon, při jehož přípravě jsme použili milestony z GitLabu a protože netušíme, kolikátý hackathon už to je, použili jsme X + 1. Až zjistíme hodnotu X, samozřejmě nahradíme 🙂 Milestone jsme připravovali 14 dní a nakonec vybrali 18 issues, které musely být opraveny, aby se vám administrace dobře používala.

Ohromně nám pomohla vaše odezva za posledních 14 dní. Chat, který máme na webu od Smartsupp využíváte hojně a dáváte nám vědět o všem, děkujeme za to. Navíc když dojde k nějaké chybě a my o ní dostaneme hlášení, hned to s vámi přes něj řešíme a vysvětlujeme vám situaci. Chat vnímáme jako velký boost naší podpory a víme, že vy taky.

Mazání PostgreSQL databází

A teď k novinkám. První týden od nasazení jsme hodně bojovali s PostgreSQL databází, konkrétně s mazáním databází. Pokaždé, kdy jsme si mysleli, že je problém odstraněný se objevil někde znovu. Během hackathonu jsme kód znovu prošli a našli poslední místo, kde se tato chyba ještě schovávala. Teď už je to v pořádku.

Máme i Redis a Cron

Potřebovali jsme vám dát už v administraci někde vědět, že můžete použít Redis, Memcached, Cron a supervisor. V tom nám pomohla záložka Servicy a malé info u databáze.

admin1

 

admin1

Oddělení vypnutých aplikací

Jeden z našich uživatelů nás upozornil, že by bylo dobré oddělit aplikace, které neběží od těch, které běží. Už na starém Roští jste po nás chtěli možnost aplikaci vypnout, což jsme v nové implementovali a teď už to je i vidět 🙂 Na screenshotu si všimněte také flagu „Zastaralý obraz„, který se bude zobrazovat, pokud bude existovat nová verze obrazu pro technologii, kterou aplikace používá. Nový obraz většinou obsahuje opravy chyb a novou verzi technologie v minoritní částí označení. Třeba aktualizace PHP 5.6.7 na 5.6.11.

stoppedapps

Překlad údajů v History tabu

Toto máme zatím upraveno napůl. Byly tu chyby, které dělaly History tab úplně nepoužitelný. Teď už je na jeho výstup spolehnutí, ale utekly nám překlady akcí, které se provádějí. Abyste pochopili, že to není úplně triviální problém, vysvětlím, jak to funguje. Když dojde k nějaké akci jako je vytvoření aplikace nebo restart aplikace, přesune se tato úloha do pozadí. To děláme pomoci python-rq. Ten funguje tak, že mu nahrajeme do Redisu co se má dělat a on si to v úplně jiném procesu začne zpracovávat nezávisle na tom, co děláte na webu. Nemusíte díky tomu čekat několik sekund, než se vám načte administrace, ale tento proces na pozadí nemá vůbec představu pro „koho pracuje“, nemá k dispozici původní request a nastavení jazyka. Výchozím jazykem je angličtina a tak jsou tyto hlášky anglicky. Pokusíme se to dořešit v jednom z dalších hackathonů.

admin1

Vychozí DNS záznamy se vytvářeli na pozadí

Při přidání nové domény docházelo k malému nedorozumění. Hned po přidání vás administrace hodila na seznam DNS záznamů, který byl .. prázdný. Vytváření výchozích záznamů jsme přesunuli na pozadí, takže k němu docházelo až několik sekund po přidání domény. Takže jste nám začali přidávat záznamy vlastní, ale než jste uložili první, už tam byly ty výchozí. Chyba je tedy odstraněna a myslím, že bude lepší, když na ní všichni zapomeneme 🙂

Dokumentace

Minulý týden jsme psali dokumentaci a během hackathonu v tom pokračovali. Dokončili jsme stránky o:

  • Emailech
  • Ruby
  • Supervisoru
  • Memcached
  • Redisu
  • a rozebrali jsme základní pojmy

Na výsledek se můžete podívat zde na https://docs.rosti.cz/.

Změna hesla

Během posledního roku, kdy vyvíjíme novou administraci, jsme si nevšimli, že jsme neimplementovali formulář na změnu hesla. Děkujeme trpělivému uživateli, který nás na to upozornil.

admin1

Narazili jsme během implementace na to, že pokud přijdete přes Twitter, nemáme váš e-mail, takže není možné se do administrace přihlásit i když máte heslo. Administrace vás tedy upozorní, že je e-mail potřeba nastavit. Pomůže nám to i při řešení problémů, které se mohou objevit.

Nové kontejnery

Aktualizovali jsme všechny kontejnery. PHP můžete používat ve verzích 5.4.43, 5.5.27, 5.6.11, Node.js 0.10.40, 0.12.7, Ruby 1.9.3, 2.2.2 a Python 2.7.10, 3.4.3 a teď nově 3.5.0b3. Chtěli bychom přinášet buildy zatím beta větví jednotlivých technologií, ale musíme k tomu připravit nějakou automatizaci. I když vytvořit image s novou verzí je jednoduché, trvá to skoro hodinu ho dostat do produkce.

Malou novinkou pro všechny PHP aplikace je ještě možnost editovat nastavení Apache. Užívejte s rozvahou 🙂

Ukazatel využití RAMky a diskového prostoru

Na Roští účtujeme aplikace na základě využité paměti RAM a diskového prostoru, nicméně jsme vám neukázali, kolik toho vlastně aplikace bere. Osobně mám z této novinky největší radost a to nejen proto, že jsem ji implementoval sám 🙂 Je to prostě super mít nějaká metadata. Na pozadí navíc sbíráme historii za posledních 24h, takže vám během dalšího hackathonu dáme snad i nějaký graf.

admin1

Pokud žádná data nevidíte, běžte do karty Parametry a klikněte na uložit. U aplikací vytvořených před víkendem se musí zrebuildnout kontejner, což se dělá právě takto. Rebuild provedeme za vás, ale pravděpodobně až o víkendu. Data se zobrazí během 10 minut.

A to je zatím vše

Na závěr bychom se vám chtěli omluvit, protože jedna ze změn, konkrétně graf využití paměti, si vyžádala restart serveru. Byly tu i další důvody, třeba přechod na poslední verzi Docker API, ale to jsme mohli pozdržet, nebylo to blokující. Každopádně jsme se dohodli, že napíšeme na Twitter, že dojde k výpadku, ale už jsme se nedohodli na tom, kdo to udělá. V noci z neděle na pondělí, kolem 1:00 došlo k půlhodinovému výpadku, který jsme, ač neúmyslně, nehlásili.

Výpadky hlásíme do speciálního Twitter účtu https://twitter.com/rosti_cz_status, tak pokud máte na Roští důležité aplikace a chcete být informovaní, mrkněte občas tam.

Děkujeme za přízeň a zůstaňte s námi. Čeká nás totiž ještě spousta nových a skvělých věcí. Mám nakousnout? Tak jo, ale jen trochu. Prioritou pro příště je pro nás předělat správu domén u aplikací, což povede k tomu, že si budete moci sami bez naší pomoci přidat k doméně SSL certifikát, také možnost doménu registrovat u nás a nebo koupit SSL certifikát u nás na jeden klik. Kromě toho se budeme soustředit také na platby přes GoPay.

GoPay je taková věc, které se k nám nechce. Martin ho už měl skoro hotový, ale pořád se mu nelíbily některé detaily. Místo toho, aby kód odeslal do GITu třeba i nedokončený, spoléhal se na svůj domácí stroj, kterému pak ze dne na den odešel SSD disk. A jaké z toho plyne ponaučení? Každý commit se počítá!

A to už je opravdu všechno, dobrou noc! 🙂

admin1

 

Vyzkoušejte si naše Docker image pro PHP 5.4.4, Python 2.7.8 a Python 3.4.1

Jak bude vypadat další administrace zhruba víme, ale pořád zbývá vyřešit spoustu detailů. Například jsme se rozhodli, že všechny aplikace na Roští pojedou v kontejnerech spravovaných přes Docker, takže stojíme přes vývojem těch nejdůležitějších kontejnerů. To znamená rozhodnout o adresářové struktuře dat, které se budou mountovat do kontejneru a také o způsobu, jakým se kontejnery budou spravovat.

Docker testujeme pořád, některé naše věci na něm běží, například RoundCube a měníme různé aspekty obrazů, kterými budou vybaveny. Původní myšlenka byla taková, že kontejner bude obsahovat všechno, co je potřeba jak pro běh aplikace, tak pro její správu. Postupně, jak jsme Dockeru rozuměli čím dál tím více a to hlavně jeho myšlence, jsme původní kontejner dost okleštili. Původní seznam vlastností vypadat takto:

  • Python/PHP/Node.js
  • SSH
  • Butterfly (přístup k shellu přes web)
  • Cron

Zatímco SSH a Butterfly vyletěly hned v prvních buildech, s cronem jsme tak trochu na vážkách. V současné době ho obrazy nemají a je třeba to řešit jinak. Uvažujeme nad stejným obrazem ale spuštěným s jiným parametrem při volání docker run.

Aktuálně se kloníme k názoru, že by měl existovat kontejner s aplikací a pak pomocný kontejner s cronem a záchranný kontejner s SSHčkem. Ani cron ani SSH zatím nemáme, ale to hlavní, kontejnery pro běh aplikací v Pythonu a PHP už si můžete vyzkoušet.

Naše kontejnery budou mít specifické chování. Zaprvé musí držet následující strukturu:

  • /srv – adresář se všemi uživatelskými daty
  • /srv/app – adresář s vaší aplikací, podobně jako je tomu teď
  • /srv/venv – virtualenv u Pythoních imagů
  • /srv/logs – adresář s logy
  • /srv/conf – adresář s konfigurací, například php.ini

Zadruhé mají všechna data práva 1000:1000, uvnitř kontejneru se to bude jevit jako app:app. Docker se postará o dostatečné oddělení uživatelských dat a nám to umožní synchronizovat data přes několik serverů například přes BitTorrent Sync. Mělo by potom být jednoduché nastavit u aplikace, na kolika fyzických serverech chcete, aby aplikace jela a tím navýšíte výkon i spolehlivost. Samozřejmě to bude mít svá omezení, ale o tom jindy.

Zatřetí je tu start.sh skript, který se spouští při startu kontejneru a stará se o následující:

  • Dotvoří adresářovou strukturu v /srv.
  • Pokud neexistuje žádná aplikace v /srv/app, nahraje výchozí.
  • Pokud neexistuje virtualenv v /srv/venv, vytvoří ho. (Pythoní image)
  • Doinstaluje veškeré závislosti ze souboru /srv/app/requirements.txt. (Pythoní image)
  • Nastaví správně práva na adresář /srv.
  • Spustí skript /srv/app/init.sh. (zatím jen Pythoní image, ale budou to mít i ostatní)
  • Nastaví workdir na /srv/app.
  • Spustí Apache/Gunicorn/jiný webserver.

Z výčtu výše bych chtěl zdůraznit hlavně fakt, že úplně končíme s uWSGI. Stal se z něj ohromný moloch a Gunicorn ho více než dobře nahradí. Možná uWSGI zvážíme někdy příště, ale určitě ne u Pythonu. Druhou věc, kterou bych rád zmínil, je existence /srv/app/init.sh skriptu. V něm si totiž budete moct napsat cokoli, co se má stát před startem vaší aplikace. Tady je malý příklad z existujícího projektu:

 

V tomto příkladu se aktivuje virtualenv, zavolají se migrace a sesbírají statická data. Ještě lépe bude skript fungovat, když do něj přidáme něco takového:

V tomhle případě se rovnou stáhne i nová verze aplikace z GIT repositáře. Novou verzi tedy nasadíte prostým restartem aplikace z administrace.

Obrazy o kterých je řeč jsou dneska už k dispozici. Mrkněte sem. Pokud máte server s Dockerem, zkuste následující:

A to je všechno, po odentrování se stáhne obraz rosti/python:3.4.1, spustí se jako kontejner a namountuje se do něj /srv/myapp. Na http://localhost:10000/ teď najdete ukázkovou aplikaci. Když do /srv/myapp/app nahrajete vlastní kód a zavoláte docker restart myapp, budete mít na stejné adrese svou aplikaci. K dispozici je aktuálně Python 3.4.1 a 2.7.8.

PHP obraz funguje podobně.

A to je všechno, teď máte na stejné adrese phpinfo. Tak zase někdy příště 🙂