Nový a rychlejší server, změny v zálohování

Dostali jsme se opět do bodu, kdy potřebujeme nový node do naší infrastruktury. Normálně o tom nepíšeme, protože to je pro nás otázka několika kliknutí, ale s node-10.rosti.cz přijdou i nějaké změny. Tak se na ně pojďme kouknout.

Než přejdeme k serveru samotnému, máme ještě jednu novinku k zálohování. Všechny servery s [alpha-]node-[X] v názvu jsou zálohovány jednou za tři hodiny s historií až jednoho týdne. Dřívější stav byl jednou denně s historií tři dny. Navýšení nám pomůže se lépe vypořádat s problémy, které jsme měli se Scaleway v září minulého roku. Pokud k takovým problémům znovu dojde, nebudeme se pokoušet stroj vůbec zachránit ale použijeme data ze záloh. Pracujeme ještě na automatizaci obnovy jednotlivých serverů.

Teď k hlavnímu tématu. Nový Node běží na intense instanci s Intel Xeon D-1531, takže je až 3x rychlejší než předchozí stroje se serverovými Atomy. Rozdíl bude znát hlavně u aplikací s většími frameworky jako je RubyOnRails nebo Django. I u ostatních ale dojde ke zlepšení odezvy. Změna se týká pouze nových aplikací a cenu hostingu to neovlivní.

Nový server už nebude mít v názvu alpha. Používali jsme ho pro oddělení názvů serverů od starého Roští, ale protože staré Roští bude letos končit a navíc běží na úplně jiném hardwaru s jinými adresami, postrádá označení smysl. Původ slova alpha je v administraci, které jsme několik let takto říkali, dokud jsme ji po čase nezačali označovat pouze admin.

Společně s touto změnou nebude mít nový stroj ani FTP server. Už jsme to určitě psali, ale raději zopakujeme. FTP je na Roští implementované jako hack. Je to místo, ze kterého je přístup do všech kontejnerů na serveru a vyžaduje přidělenou veřejnou IP adresu. I když to bude znít všelijak, tak kromě load balanceru nechceme mít servery dostupné veřejně.

Důvodů je hned několik. Dá se na ně útočit ať už DDOS útokem či přímo zneužíváním nějakých chyb. Druhým důvodem je nedostatek IPv4 adres, který se bude dále prohlubovat. A nakonec třetí důvod je bezpečnost. Všechno na našich serverech odděluje Docker a jeho mechanismy. FTP tyto mechanismy obchází.

Za pomoci našeho load balanceru v Master DC jsme schopni DDOS útoky potlačovat, ale je to drahá technologie, abychom ji mohli nasazovat u každého serveru.

Zároveň nám to pomůže udělat další krok a to jednotný SSH server. Bez ohledu na jakém serveru bude vaše aplikace umístěna, bude na ní přístup přes ssh.rosti.cz. Port zůstane, změní se pouze hostname. O tomto ale ještě napíšeme.

FTP na starých serverech zůstane prozatím beze změny minimálně do konce tohoto roku. Uvidíme, jak dopadne vypnutí na tomto.

 

Důležité změny na Roští

Bohužel jsme se poslední dva měsíce setkávali s výpadky, které jsme neměli moc možnost ovlivnit. Vypadávaly nám servery ve Scaleway i naše fyzické servery v Master DC. Jsou to věci, kterým se nevyhneme, protože nemáme pod kontrolou každý článek řetězce mezi kód a jeho uživateli. Samozřejmě s tím ale nejsme spokojení a tak se chystáme udělat změny, které by nám mohli pomoci řešit problémy rychleji a nebo jim i kompletně předcházet.

Aktualizace: Kvůli průtahům aktualizujeme plán celého postupu. Původní termíny prodloužíme o dva měsíce, abychom vám dali dost času se na změny připravit. Bohužel se nám zatím nepodařilo připravit dostatečně univerzální a funkční nástroj na migraci aplikací ze starého Roští na nové. Na tom ještě pracujeme. V článku najdete aktualizovaný harmonogram.

Z pohledu moderních aplikací je Roští stále běžný hosting, i když trochu naboostovaný. Běží u nás totiž aplikace na jednoduchém setupu, kdy každá má jeden kontejner a ani v případě, že by zvládla běžet ve více kontejnerech, tak to aktuálně neumíme nabídnout. Zákonitě pak, když aplikace běží na jednom serveru, za jedním load balancerem a nad jednou databází, dřív nebo později se něco stane.

Řešení výpadků je pro nás extrémně drahé i psychicky náročné. Nemůžeme si vybrat hodinu ani den, musíme se postarat aby služba zase jela a u toho odepisovat lidem, kteří chtějí vědět, kdy budeme zase up. Je tedy v zájmu obou stran problémům předcházet.

Některým klientům, kteří u nás mají celý svůj business, nabízíme vysoce dostupný cluster, který je odolný vůči výpadkům jednoho či více kusů hardwaru a nebo se alespoň dají problémy řešit mnohem rychleji. Nicméně to vyžaduje spolupráci nás i programátorů, abychom připravili prostředí, které oni mohou využít. Vysoce dostupná aplikace musí umět pracovat s úložištěm statických dat a někdy i s více databázemi najednou.

Tímto bychom tedy rádi oznámili, že s další aktualizací administrace dostane Roští podporu pro běh aplikací ve více kontejnerech. Zatím půjde o nasměrování load balanceru na dva či více kontejnerů a budeme sbírat odezvu od uživatelů, ale hned v dalším kroku chceme nabídnout úložiště kompatibilní s S3 a replikované custom databáze.

Vysoká dostupnost našich služeb bude další roky naší největší prioritou. Chceme nabídnout standardizované prostředí, ve kterém půjde snadno rozjet aplikaci distribuovaně a tím usnadnit život jak nám tak našim klientům.

Naneštěstí není nic zadarmo a ani v tomto případě nevyhneme nějakým dalším změnám, které nám to umožní. Můžeme být nejlepší v hostování aplikací, ale zároveň nemůžeme být nejlepší v poskytování emailových služeb. Společně se změnou popsanou výše chceme také oznámit, že od března příštího roku přestaneme nabízet naše emailové služby a zároveň zrušíme staré Roští.

Emailové schránky nabízíme od začátku zdarma jako doplňkovou službu. V současné době se ale počet emailů rozrostl přes únosnou mez a to jak množstvím dat, tak co se týče podpory. Většina dotazů na podpoře se týká emailů a i kvůli tomu nás každá schránka stojí přibližně 30 Kč měsíčně.

Zrušení emailů proběhne v několika krocích.

  • V dokumentaci přidáme text popisující tři služby, na které je možné přejít a víme, že fungují spolehlivě.
  • Rozešleme informaci o rušení služby do každé schránky. (leden 2017)
  • Zakážeme přidávat nové schránky. (leden 2017) – už je hotovo
  • Rozešleme znovu informaci o rušení služby do každé schránky. (březen 2018)
  • Poslední upozornění na rušení služby do každé schránky. (květen 2018)
  • Vypnutí emailových služeb. (31. května 2018)
  • Smazání všech dat. (30. června 2018)

Druhou službou, kterou ukončíme, je staré Roští. Aktuálně pracujeme na migračním nástroji, který ale nebude stoprocentní a bude vyžadovat změny v kódu vaší aplikace. Staré Roští tu s námi je šest let a je čas se s jeho prostředím rozloučit. Jeho servery nejsou nějak automatizované a navíc by bylo nutné je brzy aktualizovat na novější verzi Debianu a do toho se už pouštět nebudeme.

Vypnutí proběhne v těchto krocích:

  • Upozornění že staré Roští končí. (leden 2017)
  • Další upozornění, že staré Roští končí. (duben 2018)
  • Vypnutí webů na load balanceru. (květen 2018)
  • Smazání dat (31. června 2018)

Až budeme mít tohle všechno za sebou, uvolní se nám ruce k posunování Roští o kousek dál trochu větším tempem a hlavně trochu jiným směrem. Změny jsou důležité hlavně kvůli uvolnění hardwaru a podpory, abychom mohli provozovat distribuované služby, potřebujeme trojnásobek serverů tak jsou oba kroky nezbytné k tomu, co jsem v prvních části tohoto článku nastínil.

Chápeme, že ne všichni uživatelé z toho budou nadšení, ale doufáme, že oceníte změny, které nám to umožní implementovat. Děkujeme za dosavadní podporu a budeme rádi, když nám napíšete, co si o chystaných novinkách myslíte.

Stěhování do cloudu

Roští se už několikrát stěhovalo a když to bylo naposled, nešlo to úplně dobře. Nyní ho čeká další stěhování, ale z jiných důvodů, chceme totiž omezit počet vlastních serverů. Důvodem je, že nikdo z nás už se nežije v Praze a dostat se k serverům nám tak zabere minimálně hodinu a půl. Jdeme tedy do Cloudu.

Poslední rok testujeme službu Scaleway. Jedná se o poskytovatele cloudových serverů ať už baremetal nebo virtuálních. Nejedná se o nic luxusního jako je třeba Azure nebo AWS, ale tomu také odpovídá cena, která je velmi podobná vlastnímu hardware s housingem. Scaleway toho dosáhlo tím, že dostali přes 700 serverů do jednoho racku.

Testování probíhalo na ostro, server alpha-node-4, alpha-node-5 a alpha-node-6 běží ve Scaleway. Bylo pro nás důležité jak to budou vnímat naši zákazníci, protože servery v Paříži jsou od nás asi 20ms, ale žádné negativní reakce nedorazily. Mimo odezvy nás zajímala spolehlivost, Scaleway je totiž hodně levné, ale stojí za ním velká korporace (Online.net), takže úplně špatně spočítané být nemůže. Začala nás tedy zajímat spolehlivost. Celkem provozujeme ve Scaleway jedenáct serverů a během roku došlo k jednomu problému se sítí, kdy byl jeden z nich odpojen na hodinu a půl a pak k druhému problému, kdy se odpojilo síťové úložiště.

V prvním případě podpora zareagovala rychleji než jsme si toho všimli my a celou věc s námi komunikovali. Druhý případ se týkal jen našeho serveru a tam se nepodařilo najít příčinu.

Výkonově servery nejsou žádné hvězdy, ale ukázalo se, že pro potřeby naší služby máme ještě velké rezervy. Pro jistotu jsme ale implementovali omezení na dvě jádra u nejmenšího balíčku a postupné zvyšování u vyšších balíčků. Od té doby nemáme problém s tím, že by jedna aplikace „sežrala“ výkon celého serveru.

A teď to důležité, v příštích dvou týdnech se bude zbytek nového Roští stěhovat do Scaleway. Jedná se o tři aplikační servery a jeden databázový a všechny čtyři se musejí přenést najednou, resp. přepnout ze starého na nový v jednom okamžiku.

Tento víkend budeme připravovat nové prostředí, což bude vyžadovat přenos přibližně 500 GB dat. Kdy dojde k přepnutí ještě netušíme, ale v plánu máme příští nebo ten další víkend, tedy 26. až 27. srpna nebo 2. až 3. září.

Nemělo by dojít k velkým výpadkům. Je možné, že budete mít během víkendu problémy připojit se na SSH a během noci se mohou weby na pár hodin odmlčet. Důvodem je, že chceme udržet přenos konzistentní a to se nejlépe dělá, když služba neběží. Výpadek se bude týkat všech čtyř serverů najednou. Pokusíme se to provést mezi půlnoci a třetí ráno v noci z pátka na sobotu.

Díky tomuto kroku budeme schopni řešit problémy rychleji. Nebude pro nás ani problém spustit nový server a nasadit na něj zálohu, takže v případě fatálního selhání pronajatého hardwaru budeme schopni zprovoznit službu hned jak se zkopírují data na nový server.

Na fyzických serverech zůstává zatím pošta, staré Roští a zálohování. Výhledově chceme nechat dva fyzické servery. Jeden je velmi výkonný 1U Dell s SSD disky. Druhý je slabý stroj s prostorem 8 TB určený k zálohování.

Nový ceník

Když jsme před dvěma lety začali pracovat na novém Roští, cenová politika byla jedním z velkých otazníků. Neměli jsme zkušenosti s vedením firmy a věděli jsme, že špatně nastavenou cenou bychom mohli potopit Roští ještě před tím, než se rozjede. Máme nyní data ze dvou let provozu a rozhodli jsme se proto upravit ceník tak, abychom mohli Roští dlouhodobě dále rozvíjet.

Nebylo to jednoduché rozhodování a strávili jsme spoustu času debatami nad výší jednotlivých částek. Dnes víme kolik v průměru stojí každá aplikace, takže počítání bylo jednoduché. Nicméně je tu i psychologický aspekt, který řeší každý projekt „Bude to konkurenceschopná cena?“, „Budou to uživatelé ochotni zaplatit?“.

Roští není hosting, který by mířil na masy. Nabízí toho svým uživatelům hodně. Každá aplikace má velmi blízko k prostředí virtuálního serveru a to pro nás dělá správu o poznání komplikovanější než u běžných hostingů, kde je jen PHP a centrem všeho je Apache. Pokud jsme tedy něco za ty dva roky zjistili, tak je to to, že nemůžeme nabízet hosting za 26 Kč měsíčně.

A se současným ceníkem jsme měli ještě jeden problém, nebyli jsme schopni s uživateli komunikovat kolik je vlastně bude hosting stát. Neměli jsme pevné mantinely, do kterých by mohli svou aplikaci zařadit a tak se ptali na otázku, na kterou jsme neznali odpověď: „Kolik mě bude hostingu u vás stát?“. Podle nového ceníku už tedy nebudeme počítat aplikace dynamicky, ale vytvořili jsme 4 balíčky, u kterých budeme schopni říct, k čemu jsou vhodné.

Změnou tedy vyřešíme dva palčivé problémy, které nás aktuálně trápí. Doufáme, že přestaneme odrazovat uživatele, kteří se s ceníkem neztotožnili a zbavíme se aplikací, které jsou pro nás aktuálně ztrátové. U těch nejmenších aplikací (myšleno ve velikosti RAM) dojde k nejcitelnějšímu zdražení. U průměrných aplikací (192 a 256 MB RAM) to už není tak znatelné.

Nemá to smysl dále protahovat, tady je aktuální náhled na balíčky, které budeme od tohoto týdne nabízet:

Start Normal PRO business
256 MB RAM
2 GB prostoru
99 Kč
512 MB RAM
10 GB prostoru
189 Kč
1024 MB RAM
25 GB prostoru
499 Kč
4096 MB RAM
50 GB prostoru
999 Kč

Máte teď asi nějaké otázky, tak na některé zkusím odpovědět a pokud nenajdete odpovědi níže, tak se klidně ptejte v komentářích.


Proč je minimum 256 MB RAM?

Requesty na aplikace s 64 a 128 MB RAM jsou často sestřelovány OOM killerem, protože kontejner nemá dostatek paměti. Hranice 256 MB RAM je rozumná pro 80 % projektů, které aktuálně na Roští hostují. Poběží v tom WordPress i Django a dají se v tom provozovat i velké projekty, pokud jsou dobře napsané. Zatím bohužel nemáme jak detekovat, pokud se OOM killer přihlásí ke slovu, ale rozjeli jsme ukazatel využité RAMky a zkusíme implementovat notifikace, když se bude obsazení paměti dlouhodobě blížit 100 %.

Co za cenu navíc dostanu?

Rozrostli jsme se o dalšího člena týmu, který se věnuje vývoji full time. Pomalu přecházíme na cloudové služby, takže jsme přestali kupovat vlastní hardware. Díky tomu máme více možností na zabezpečení provozu aplikací například před DDOS útoky a také jsme schopni rychleji reagovat na problémy se servery.

Od kdy začnou balíčky platit?

Podporu v administraci máme nasazenou, takže všechny nové aplikace už používají balíčky.

Musím na balíčky přejít?

Zatím ne, ale od nového roku přepneme současné aplikace na nový způsob účtování. Chceme vám tímto dát čas zvážit změny v našem ceníku a rozhodnout se, zda u nás zůstanete nebo použijete alternativní služby.


Změny ceníku, zvlášť když dochází ke zdražení, nejsou nikdy příjemné a chápeme to. Snažíme se s vámi komunikovat důvody, které nás k tomu vedly. Nový ceník je založen na číslech z reálného provozu a všechny alternativní možnosti jsou horší než tato. Omlouváme se za špatné zprávy a doufáme, že na nás i přes to nezanevřete.

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.