Nasazení z Gitu do složek verzí: jak funguje automatický rollback

Co se pokazí při nahrávání přes běžící web

Klasické nasazení přes FTP nebo rsync nahrává soubory jeden po druhém do složky, ze které web právě běží. Několik sekund nebo minut je tedy web ve stavu, kdy má část souborů novou a část starou. Pokud si v té době někdo otevře stránku, dostane kombinaci, která nikdy nebyla otestovaná.

U statického webu se to projeví rozbitým stylem. U aplikace, která má šablony, závislosti a migrace databáze, se to projeví chybou 500 nebo něčím horším: stránka se zobrazí, ale uloží data ve starém formátu.

A hlavně: když zjistíte, že nová verze nefunguje, stará už na disku není. Návrat znamená znovu nahrát předchozí stav, což je ta samá pomalá operace, jen pod větším tlakem.

Složka pro každou verzi

Princip, který používá řada nástrojů od Capistrana po moderní platformy, je jednoduchý. Každé nasazení dostane vlastní složku pojmenovanou podle času nebo commitu. Do ní se naklonuje kód, nainstalují závislosti a aplikace se sestaví. Běžící web se o tom celou dobu nedozví.

Vedle složek verzí stojí dvě věci, které s verzí nesouvisejí:

• Sdílené úložiště pro všechno, co vzniká provozem: nahrané soubory, generované obrázky, cache. Do složky verze se propojí odkazem.
• Proměnné prostředí konkrétního webu: přístupy k databázi, API klíče, nastavení. Do repozitáře nepatří a při nasazení se jen načtou.

Teprve když je nová složka hotová a prošla kontrolou, přepne se na ni symbolický odkaz, který web používá jako svůj korzeň. To je jediná operace, kterou návštěvník může zaznamenat, a trvá zlomek sekundy.

Dobré nasazení poznáte podle toho, že si ho nikdo nevšimne. Ani vy.

Health check, který něco kontroluje

Tady se dělá nejčastější chyba, a my jsme ji udělali taky. Kontrola po nasazení původně volala úvodní stránku a čekala na stavový kód 200. Problém je, že úvodní stránka se často servíruje z vyrovnávací paměti a odpoví i tehdy, když je aplikace pod ní rozbitá.

Užitečná kontrola musí sáhnout na to, co se nasazením mohlo rozbít. U nás volá adresu, která:

• otevře spojení s databází a provede jeden skutečný dotaz,
• přečte alespoň jednu proměnnou prostředí, kterou aplikace opravdu potřebuje,
• vrátí verzi, tedy hash commitu, který se právě nasadil.

Ten poslední bod je důležitější, než se zdá. Bez něj nepoznáte rozdíl mezi „nová verze odpovídá“ a „stará verze pořád odpovídá, protože přepnutí vůbec neproběhlo“.

Proč musí být rollback automatický

Argument proti automatice zní rozumně: nechci, aby mi systém sám měnil, co na webu běží. V praxi je to ale naopak. Rollback potřebujete přesně v těch chvílích, kdy u toho nejste, a čím později k němu dojde, tím víc lidí mezitím vidělo rozbitou stránku.

U nás je pořadí takové: nasadit, zkontrolovat, a pokud kontrola neprojde, nepřepínat. Běžící web zůstane na předchozí verzi a nová složka se označí jako neúspěšná. Pokud se problém objeví až po přepnutí, panel umí vrátit odkaz na předchozí verzi, která je pořád na disku a nemusí se znovu sestavovat.

Lidská část přichází až potom: někdo se v klidu podívá do logu neúspěšného nasazení a zjistí, co se stalo. Rozdíl je v tom, že se dívá na funkční web.

Co si u sebe ohlídat, i bez vlastního panelu

Většina týmů nepotřebuje vlastní hostingový panel, tohle ale stojí za nastavení i s hotovými nástroji:

1. Kolik starých verzí si necháváte. Tři až pět je obvykle dost. Nula znamená, že rollback neexistuje.
2. Co přesně kontroluje health check. Pokud odpovídá i při vypnuté databázi, nekontroluje nic.
3. Kde končí uživatelská data. Pokud jsou ve složce verze, každé nasazení o nich rozhoduje.
4. Jak zjistíte, co na webu běží. Hash commitu viditelný z aplikace ušetří pozdější hádání.
5. Co se stane s databázovými migracemi při rollbacku. Tohle automatika neřeší a je to nejčastější díra v celém schématu.

Ten poslední bod je potřeba říct nahlas: rollback kódu nevrátí změny ve schématu databáze. Pokud migrace odebrala sloupec, předchozí verze kódu ho po vrácení nenajde. Řešení není technické, ale v návrhu: migrace se dělají tak, aby předchozí verze kódu přežila, tedy nejdřív přidat, pak přestat používat, a odebrat až o jedno nasazení později.

Kde to nestačí

Pro úplnost: tohle schéma nepokrývá nasazení do více serverů současně, nic nepřepíná postupně po částech provozu a neumí vrátit, co odešlo mimo server, například odeslané e-maily nebo zápisy do cizích systémů. Na větším provozu se tyhle věci řeší jinak a dražšími nástroji. Pro provoz desítek webů na jednom serveru je to ale ten rozdíl mezi nasazováním v pátek a nasazováním v pondělí ráno.

V příštím díle se podíváme na to, jak na jednom serveru držet čtyři verze PHP a vědět u každého webu, jestli pro tu jeho existují známé zranitelnosti. Jak takový provoz stavíme, popisujeme u hostingu a provozu.