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.

Nový SMTP server

Máme pro vás malou novinku, nový SMTP server. Možná jste si všimli, že se náš SMTP server mail.rosti.cz dostal na blacklisty a máme problémy ho dostat pryč. Hlavním důvodem jsou zavirované počítače našich uživatelů, které se občas objeví a posílají desítky tisíc emailů. Bohužel jsme nebyli schopni uspokojivě nasadit žádnou dostupnou ochranu v Postfixu a tak jsme se rozhodli nasadit nové řešení postavené na projektu Haraka.

Haraka je daemon napsaný v Node.js a je navržený na posílání velkého množství zpráv. To nejdůležitější je, že má spoustu pluginů a jednoduché rozhraní pro psaní nových, takže to co od nás chodí budeme mít alespoň částečně pod kontrolou. Nový server je připravený na adrese smtp.rosti.cz a v současné době řešíme poslední problém, který nám brání ho začít používat všude. Pokud jste si změnili heslo přes webmail, neprojde vám proti novému SMTP serveru ověření. Pokud máte ale heslo nastavené přes administraci, tak všechno projde v pořádku. Všechny problémy se nám podařilo vyřešit a server je připravený.

Chcete-li nové řešení vyzkoušet, je to jednoduché. Přejděte do nastavení svého emailového klienta a tam kde máte u SMTP serveru mail.rosti.cz, tam dejte smtp.rosti.cz. V Thunderbirdu to vypadá takto:

spectacle-h13941

Zbytek parametrů zůstává stejný:

  • Zabezpečení přes TLS (někdy označeno jako starttls),
  • heslo PLAIN (někdy označeno jako normální heslo),
  • uživatelské jméno a heslo stejné jako pro přístup k IMAPu/POP/webmailu,
  • a port 587.

S emaily ještě nekončíme. Dalším krokem je implementace DKIM, SPF a také změna pravidel pro posílání pošty. Po zrušení mail.rosti.cz, resp. přesměrování jeho portů na nové smtp.rosti.cz už nebude možné posílat emaily z naší sítě bez ověření. Na smtp.rosti.cz jsme zavedli pravidla maximálně tří emailů za minutu a 100 příjemců za tři hodiny. Obě čísla budeme ještě měnit v závislosti na tom, jak se k tomu budou stavět naši uživatelé. Je také možné udělat výjimky, stačí nás kontaktovat na podpoře.

Důvodem, proč jsme se dostávali na blacklisty byly zavirované počítače našich uživatelů. Máme několik set aktivních emailových schránek, takže je nemožné, abychom tomu utíkali věčně. Když už někomu utečou přihlašovací údaje, tak začne posílat tisíce emailů každou minutu. Během pár minut se pak dostáváme na blacklist, ze kterého nás vyškrtnout v řádech dnů. Poslední dobou se to stávalo každý týden alespoň jednou a tak jsme museli zasáhnout. Tento blogpost je už jen vyvrcholením celé snahy. Nesnažíme se vás tedy omezovat, jen chceme zmírnit dopady situací, které reálně vznikají.

Problémy s disky

Těžko se o takovýchto situacích píše, ale napsat o nich musíme. V jednom ze serverů, které provozujeme, začaly odcházet oba disky v RAID 1 najednou. Server patří k těm starším co máme a i když jsme vydrželi datově bez úhony, nevyhnuli jsme se výpadku.

Celá situace proběhla velmi rychle. Dostali jsme notifikaci, že na jednom z disků se začínají objevovat chybné sektory. Disk jsme odstranili z pole a začali zařizovat disky nové. Máme už delší dobu plán rozšířit kapacity jednoho z nových serverů, který pojme dva naše nejstarší, takže jsme plán jen urychlili.

Chvíli jsme řešili problémy se šroubky a šuplíky, ale než bylo všechno připraveno, začaly se objevovat problémy na druhém disku. Měli jsme připraveny zálohy, ale se zálohama se to má tak, že je nemáme real time, takže když je obnovíme, uživatelé přijdou o část dat mezi dobou zálohy a aktuálním časem.

Rozhodli jsme se situaci ještě zkusit zachránit a virtuální servery přesunout pomalu, s rozvahou a bez velkých neplánovaných výpadků. Disk ještě fungoval, i když občas nemohl nějaký sektor přečíst. Koupili jsme k serveru externí disk, připojili ho přes USB 3.0 a přidali do pole. Přesně v ten moment došlo k poškození obrazů některých virtuálních serverů. Nejvíce byl zasažen jeden ze serverů mimo veřejné Roští, který jsme museli také jako jediný obnovit ze zálohy. Všechna ostatní data se podařilo dostat ven.

Výpadek nového Roští byl v sobotu pod jednu hodinu. Problém totiž zasáhl databáze, kterým jsme dávali prioritu a protože jich není tolik, přestěhovaly se rychle. Hned potom jsme se vrhli na poštu a zmíněný virtuální server. Pošta neběžela kolem šesti hodin někdy od 17 do 23. O emaily uživatelé nepřišli, čekaly ve frontě na serveru, ze kterého měly přijít.

O stavu postiženého serveru a řešení jsme informovali po půlhodinách na Twitteru a naší homepage.

Aby toho nebylo málo, druhý den začal zlobit server alpha-node-2, se kterým máme dlouhodobé problémy. Nicméně jsme přišli na to, co se na něm děje a v nejbližších dnech to vyřešíme. Skript, který měl pomoci s diagnostikou se bohužel ukázal jako problémový, takže musíme opatrně.

Ve stejný týden jsme ještě měli problém s dalším serverem, který ovlivnil jen nové Roští. V serverovně nám dali špatné zásuvky v PDU. Přišli jsme na to náhodou, ale vysvětlily se tím restarty, ke kterým v posledních třech měsících docházelo. Nyní máme nové zásuvky a tak je to také vyřešeno.

Výpadků nám je líto, ale každý takový problém nám pomáhá se posunout dopředu. Celé nové Roští je nyní na novém hardwaru. Zbytek starého Roští čeká migrace během víkendu. Na problémovém serveru už teď nic neběží.

V blízké budoucnosti bychom chtěli prozkoumat možnosti běhu Roští mimo náš vlastní hardware a upravíme zálohování tak, abychom měli k dispozici čerstvější data a hlavně rychleji dostupná.

Problémy s alpha-node-2 by měly být tento týden dočasně vyřešené a do administrace právě implementujeme vlastnost, která by je měla odstranit napořád.

Víme, že Roští ještě není dokonalé a že má své mouchy. Omlouváme se za potíže, které vám tyto problémy způsobily a doufáme, že kroky, které jsme podnikli, vás přesvědčí, že se tyto problémy nebudou opakovat.

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í.

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.