API

Je to už dlouho, co jsme se o API zmiňovali poprvé. To jsme si ještě nemysleli, že to potrvá tak dlouho. Nakonec jsme se k tomu dostali až po dlouhých dvou letech. Ale o to lepší nakonec výsledek je. Nyní máme hroznou radost, že vám můžeme oznámit, že API pro aplikace a databáze je hotové.

Tahle novinka je pro Roští milníkem v jeho vývoji, protože API otevírá v jeho službách úplně nové možnosti. Je to základ, na kterém budeme stavět v následujících měsících. S API můžete integrovat deployment do vašeho build systému, případně upravit deployovací skripty. Možností je hodně. Na implementaci některých se chystáme sami, jiné necháme v rukou komunity.

Naši hlavní prioritou v téhle oblasti bude utilitka s názvem rostictl, se kterou půjde naše API integrovat do vašich shell scriptů pro deploy a testování. Díky tomu, že používáme Django a Django REST framework je to možné už dnes díky coreapi schématům a nástroji coreapi-cli. Vytvoření aplikace tak lze provést z BASHe třeba takto:

Naše utilitka k tomu ale přidá jedno malé vylepšení, Rostifile – definice toho co aplikace potřebuje

Další varianty volání coreapi lze nalézt v naší dokumentaci pro API. Dokumentace je v angličtině. Odpovědi z API budou chodit zatím v češtině, ale co nejdříve se je pokusíme také přepnout do angličtiny. Bojujeme trochu s tím, že je admin spojený s API. Řešení je několik a nakonec jedno vybereme, ale teď jsme chtěli API hlavně vypustit.

Je možné, že během následujících týdnů a měsíců tuto verzi budeme ještě upravovat, ale nebude to větší změna než datový typ nějakého fieldu.

Chybí nám ještě API pro DNS a platby. DNS doplníme hned jak to bude možné, protože to budeme potřebovat pro rostictl. U plateb uvidíme, není to zatím priorita.

Další změny

Společně s API přišly i nějaké další změny. Pojďme mrknout na screenshot.

Hned na první pohled je vidět první změna. Úložiště už nejsou vázaná na aplikaci. Chtěli jsme dřív nabídnout službu zálohování aplikace včetně databáze. Tedy takový snapshot stavu v čase. Nakonec se to ukázalo být komplikované. Navíc jsme na základě zpětné vazby zjistili, že uživatelé chtějí spíše jednu databázi k více aplikacím. Tento krok tedy usnadní fungování nám a snad i většině uživatelů.

Druhou změnou je přesun položky upozornění ze side menu nahoru do loga, kde byl v našem původním návrhu. Potřebovali jsme tuhle vlastnost rychle a tak jsme úplně neřešili kde se zobrazí. Tímto jsme to tedy opravili.

Třetí změna ani tak změna není, protože tohle už v administraci nějaký čas je. Ale je to místo, kde se nastavuje token pro API a taky tu můžete změnit heslo pro svůj účet. Token je generovaný pro uživatele, ne pro firmu. Takže s jedním tokenem můžete přistupovat ke všem aplikacím firem, ke kterým máte práva i v administraci.

A to je všechno. Budeme rádi, když si naše API zkusíte a když nám nahlásíte jakýkoli bug na který narazíte. Většinu toho chytneme v Sentry, ale i tak budeme rádi za zpětnou vazbu.

Migrace do DigitalOcean

Na Twitteru už jste mohli postřehnout, že chystáme stěhování ze Scaleway do DigitalOcean. Psali jsme o tom i minulém zápisku a tento zápisek je jen popsání toho, co se bude v příštích týdnech dít.

Migrace se týká všech aplikací, které jsou hostovány v novém Roští, což jsou ty, co byly vytvořeny v posledních třech letech. Ze strany uživatelů není potřeba žádná spolupráce, pouze budeme měnit doménové názvy serverů, na kterých jsou aplikace hostované. Ty si prosím upravte ve svých skriptech či nastavení podle tabulky níže.

To nejdůležitější, migraci administrace, máme již za sebou. Neobešlo se to bez problémů, ale to už je za námi a také jsme díky nim upravili kontaktní formulář a schránku podpory tak, aby nebyla na našem mail serveru jakkoli závislá.

V druhém kroku musíme přenést servery pro aplikace. Rozhodli jsme se jít cestou, která je pro nás nejjednodušší, protože jednoduchý proces bude méně náchylný na chyby. Přeneseme aplikace ve dvou vlnách. V první půjdou aplikace, které používají databázi store3.rosti.cz. V druhé pak ty, co používají store4.rosti.cz.

Databázi už jsme přenesli a máme připravený skript, který je udělá finální synchronizaci. U aplikací je to složitější, protože budeme spojovat některé servery. Scaleway používá méně výkonné serverové procesory Atom, takže jsme na jeden stroj dávali méně aplikací. DO na druhou stranu má rychlé Xeony a dává i dostatek prostoru, takže limitujícím faktorem pro nás není procesor, ale paměť RAM a tam jsme schopni přesně říct, kolik aplikací může na jednom serveru být.

Prozatím plánujeme jednoduché spojení serverů podle následující tabulky. Později ho ještě upravíme po jednotlivých aplikací tak, abychom měli servery rovnoměrně zatížené. Zároveň přidáme čtvrtý, node-14, na kterém budou hostovány nové aplikace.

Původní server Nový server
alpha-node-4.rosti.cz node-12.rosti.cz
alpha-node-5.rosti.cz node-12.rosti.cz
alpha-node-6.rosti.cz node-13.rosti.cz
alpha-node-7.rosti.cz node-11.rosti.cz
alpha-node-8.rosti.cz node-11.rosti.cz
alpha-node-9.rosti.cz node-11.rosti.cz
node-10.rosti.cz node-14.rosti.cz

Pokud tato doménová jména používáte ve svých skriptech, tak je prosím změňte na nová. Stará přesměrujeme, ale na konci února je smažeme.

Status

  • 1.-2. února*: Úprava administrace – funkce pro notifikování uživatelů o změnách
  • 1.-2. února*: Úprava administrace – nástroje pro jednodušší migraci mezi servery
  • 3. února: v ranních hodinách*: Migrace alpha-node-7, 8, 9 a store3
  • 10. února: v ranních hodinách: Migrace alpha-node-4, 5, 6, 10 a store4
  • 28. února**: smazání starých doménových jmen

* Termíny nejsou pevné a mohou se změnit.

Kdy k jednotlivým krokům dojde ještě doplníme.

Celý proces je vzhledem k naší softwarové architektuře velmi přímočarý a není v něm moc prostoru na chyby. Kromě výpadku během přenášení by nemělo dojít k žádným dalším problémům. Před migrací se prosím přesvědčte, zda vaše aplikace přežije restart kontejneru. V administraci stačí kliknout na tlačítko restart.

Nedostupnost

Do migrace se pustíme během noci, přibližně od půlnoci a bude trvat kolem dvou až tří hodin. Během této doby budou aplikace nedostupné. Plánovali jsme to udělat mnohem rychleji s výpadkem maximálně několik minut, ale spojování serverů nám do toho hodilo trochu vidle.

K migraci dojde během následujících dvou týdnů a o krocích, které mohou ovlivnit dostupnost vaší aplikace budete informování emailem. Proto chceme do administrace přidat novou sekci podpory, kde vám budeme moci poslat notifikace o změnách a zároveň je patřičně cílit.

Jiných služeb, než hostingu aplikací, se migrace nedotkne. Emaily jsou umístěny na našich fyzických serverech v Master DC v Praze, stejně jako všechno okolo starého Roští a záloh.


Aktualizace 3.2.2018 4:00

Server node-11.rosti.cz už běží a jsou na něj přemigrovány všechny aplikace podle tabulky výše. Pokud vše půjde dobře, druhé vlně příští týden v pátek nic nebrání.

Aktualizace 3.2.2018 14:15

Kvůli nepatrnému překliku před pěti dny musíme dnes ještě na chvíli shodit všechny aplikace na node-11. Máme ho totiž ve špatné lokalitě. Půjde o jednodušší proces než z dnešní noci, protože to je přenesení 1:1 a aplikace by neměly být dole déle než pár minut. Akci provedeme mezi 1:00 a 3:00. Jinak vše běží v pořádku a nový stroj je zatížen podle očekávání.

Zatížení node-11.rosti.cz

Aktualizace 9.2.2018

Na zítřejší migraci je vše připraveno. Přes týden jsme nezaznamenali žádné problémy a tak nám nic nebrání v přenesení zbytku.

Aktualizace 9.2.2018 13:30

Aktualizovali jsme tabulku s doménovými názvy nodů. Prohodil se cílový node mezi alpha-node-4,5 a 6.

Aktualizace 10.2.2018 2:50

Všechny servery jsou přenesené. Děkujeme za trpělivost. Tahle zkušenost nám pomohla dopilovat role v Ansiblu a implementovali jsme kvůli ní notifikační systém do administrace, přes který vám můžeme posílat emaily, pokud se bude dít něco důležitého. Ale o tom ještě napíšeme nějaký článek. Prozatím dobrou noc.

Aktualizace 28.2.2018 18:00

DNS záznamy byly upraveny.

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.

Let’s encrypt už brzy

Špatných zpráv bylo za poslední týden víc než jsme zvyklí a tak trochu odlehčím atmosféru. Před 14 dny jsme dokončili kód, který umožní spustit podporu Let’s encrypt na Roští. Zmiňoval jsem to i dřív, ale raději ještě jednou napíši: Museli jsme kompletně přepsat způsob, jakým jsou domény u aplikací uloženy. A co z toho plyne? Čeká nás masivní migrace.

V současné době jsou domény u aplikací uloženy ve velkém text fieldu a oddělené mezerou nebo novým řádkem. Systém s tím doposud nějak pracoval, ale určitě vás napadne, že spravovat tímto způsobem domény je nepohodlné. Nejvážnější problém jsou oprávnění. Tedy že subdomény z jedné domény druhého řádu je možné používat mezi více účty. Kontrola tohoto stavu je v současné době obalena hromadou kódu, který není nutný, protože ho může pohlídat databáze. A to je také to, oč jsme se snažili.

V nové verzi administraci bude mít každá doména druhého řádu zónu a v ní subdomény a tyto subdomény budou přiřazeny aplikacím. Pokud budete chtít použít u aplikace jen doménu třetího řádu, tak to samozřejmě nevadí, ale zónu pro celou doménu vám stejně vytvoříme. Není nějak povinné ji používat, ale je lepší, když na ní svoji doménu u registrátora namíříte.

Nicméně, tímto krokem získáme záznam v databázi pro každou doménu/subdoménu a můžeme k němu ukládat i další věci jako třeba informaci, že má být s SSL certifikátem nebo že pro ni máme získat certifikát ze služby Let’s encrypt.

A to je důvod, proč to tak dlouho trvá a ještě chvilku trvat bude. Migrace, kterou chystáme nebude snadná, nebude bez problémů a nebude hotová během pár minut. Musíme se na ní připravit, upravit naše vývojové prostředí a všechno pořádně otestovat. Všechno by se mělo rozjet příští týden ve čtvrtek a pokud to půjde dobře, další týden už bude možné aktivovat Let’s encrypt u vašich domén.

Kromě toho budeme schopni začít s implementací registrace domén, ale ještě předtím se chceme věnovat nové funkci „Služby“, která vrátí MongoDB tam kam patří, do naší administrace.

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.