Asi netřeba obšírně rozebírat, že Google (potažmo Alphabet) provozuje spoustu svých služeb a obsluhuje myriádu lidí na YouTube či GMailu a softwarové pozadí těchto služeb v čele s operačním systémem potřebuje mít co nejefektivněji vyvíjené, na pracovních stanicích vývojářů, které jsou vždy aktuální, nejrychleji záplatované a tyto procesy nijak nezatěžují vývojáře. Celou tuto flotilu počítačů Googlu přitom tvoří stovky tisíc strojů skrze všemožné platformy, modely a geografická umístění.
Stabilní verze
V minulosti Google stavěl svojí linuxovou distribuci používanou firemními vývojáři na Ubuntu LTS. Jmenovala se Goobuntu a již čtyři roky je minulostí, neb v roce 2018 Google přešel na model rolling-release, kde jako základ využívá Debian. Ubuntu sloužilo interně v Googlu od doby před více než 15 lety, tedy zhruba od doby vydání Ubuntu 7.04, případně 6.06 (což byla první LTS verze). Bylo vybráno díky své uživatelské přívětivosti a spoustě drobností navíc, kdy tyto věci Google využíval, neb svým zaměstnancům dává možnost upravit si své pracovní prostředí k obrazu svému.
Každopádně dvouletý cyklus LTS vydání znamenal nutnost aktualizací verze OS předtím, než podpora daného TLS vydání skončí. U stovky tisíc provozovaných strojů. Vzhledem na spoustu různých konfigurací tohoto Ubuntu na strojích Googlu a jeho zaměstnanců šlo o složitou, časově náročnou operaci. Dopad na produktivitu, kdy každé dva roky všichni inženýři Googlu zasedli ke svému stroji, aby jej zaktualizovali a opět si jej nakonfigurovali k obrazu svému, byl neudržitelný.
Také s každým cyklem verze docházelo k velkým skokům ve verzích balíčků, což mohlo tu a tam znamená nutnost významných úprav v konfiguraci softwaru. Google se toto snažil zautomatizovat vlastním nástrojem, který byl schopen se postarat o většinu běžných problémů a uživatelé už nemuseli ručně povyšovat systém a následně dolaďovat zpět svoji konfiguraci. Vždy však bylo nutné provádět velmi detailní testování aktualizace OS, aby bylo jisté, že všechny hlavní balíčky fungují i na nové verzi (což u typického vydání Ubuntu znamená několik tisíc balíčků). Nezřídka naráželi na problémy, kdy nějaký balíček byl zastaralý a náhradu nebylo možné nasadit na sto tisících strojů automatizovaně.
Celkově si tak udržování flotily počítačů Googlu s Goobuntu vyžádalo s každou velkou aktualizací OS vždy větší část roku. S dvouletým cyklem aktualizací tak zůstával pouhý 1 rok než se proces opakoval a během kterého příslušný tým řešil stovky nahlášených chyb po aktualizacích. Tým tak obvykle směřoval téměř k vyhoření (mimochodem nezřídka se řešily chyby, které třeba už dávno byly v upstreamu vyřešeny, ale do dané LTS verze se prostě opravy nebackportovaly) a poté už nezbývalo mnoho času do momentu, kdy přijde nové Ubuntu LTS a celý náročný proces se bude opakovat. Vším se také táhly letité speciální případy strojů, které nešlo upgradovat automatizovaně, včetně strojů na které se třeba jen zapomnělo a tým je tak natvrdo ručně aktualizoval a restartoval, například včetně jednoho počítače zapadlého kdesi pod stolem, na kterém běžela kritická část pipeline pro něco důležitého, jak se později ukázalo (aneb v žádné velké firmě neví levá ruka, co dělá pravá).
Průběžné aktualizace přicházejí
Zkrátka toho bylo příliš, navržené postupy nefungovaly dobře a Google se jednoho dne rozhodl přejít na průběžně aktualizovaný systém postavený na Debianu. Ten dostal jméno gLinux Rodete (Rolling Debian Testing). Cílem bylo zbavit se dvouletého cyklu aktualizací a rozložit zátěž na příslušný tým do delšího času. Šlo vlastně o obecný trend IT svět, kdy se průběžné malé dílčí aktualizace lépe řídí a v případě problémů se snadněji vrací k předchozí funkční verzi.
Zvažovány byly mimochodem různé linuxové distribuce, ale volba padla na Debian kvůli možnost provést hladkou migraci z předchozího systému na bázi Ubuntu, včetně známé výhody Debianu v podobě obrovského množství balíčků, velké komunity. Větev Testing se ukázala jako vhodná, díky své víceméně rolující povaze. Doba mezi novou verzí v upstreamu a jejím zabalíčkováním v Debianu, se obvykle pohybuje v řádu několika dnů (snad jen v době příprav nové Stable verze se může zpoždění protáhnout na týdny až měsíce).
Týdenní tempo aktualizací
Na bázi testovací větve Debianu mohli v Googlu hrnout průběžné aktualizace prakticky v denním tempu. Museli předělat spoustu systémů a procesů, aby se nakonec ukázalo, že optimálním tempem pro jejich potřeby jsou týdenní aktualizace, ač původně chtěli držet svižnější tempo.
Pokaždé když v Googlu pracují na novém vydání, stáhnou celý snapshot balíčků, které Debian v danou chvíli poskytuje. Proběhnou akceptační testy a následně je kandidát na tuto novou verzi systému opatrně vypuštěn mezi vyhrazenou flotilu zkušebních strojů a 1 % pokusných králíků. Počká se pár dnů a pokud se neobjeví problémy ani v Googlu, ani přímo u Debianu, je nová verze vyrolována ven mezi celou počítačovou flotilu Googlu.
Podpůrný systém Sieve
Pro správu těchto komplexních úloh s buildováním všech upstream balíčků ze zdroje v Googlu vyvinuli vlastní systém Sieve. Když se objeví nová verze balíčku Debianu, začíná v Googlu nový build. Balíčky jsou sestavovány ve skupinách, aby se zohlednila nutnost je aktualizovat dohromady. Jakmile je skupina sestavena, provedou se virtualizované testy, jejichž účelem je zjistit, že se nic nerozbilo (klíčové komponenty či workflow vývojářů Googlu). Tyto testy mohou pro danou skupinu zabrat až 1 hodinu času, v případě jednotlivých samostatných balíčků jde o minuty.
Když balíčky jsou sestaveny a úspěšně prošly testy, dojde k jejich zahrnutí do velkého poolu dalších. A když je potřeba vyrolovat novou verzi systému, vezme se snapshot tohoto poolu s balíčky v daných zamčených verzích, které jsou otestované na funkčnost a vydá se ven. Tahle flotila balíčků vydaná v souladu s SRE principy je pak bedlivě sledována.
Ne všechny buildy ale projdou takto hladce. Pokud selže sestavování daného balíčku, nejprve v Googlu kontrolují, jestli něco není v debianím bug trackeru a případně chybu sami nahlásí. Někdy jsou inženýři Googlu kreativní a sami aplikují nějaké lokální řešení chyb/nové patche, aby bylo možné balíček v jejich ekosystému sestavit. Tyto věci se pak posouvají do upstreamu.
Nezřídka se stávala jedna z chyb. Například balíčky, které jsou v upstreamu Debianu, jsou typicky buildovány v Debianu unstable. Po několika dnech se takové balíčky mohou přesunout do Debianu Testing, ale ve svých buildovacích závislostech mají unstable, takže jejich sestavování nemusí být ještě proveditelné. Obecně se v Googlu snaží pracovat přímo s upstreamem, což snižuje náročnost údržby tohoto projektu, přičemž současně se něco vrací zpátky komunitě (viz výše).
Každopádně když všechny kroky selžou, Sieve má nástroje na to, aby se pokusil o sestavení jinou cestou. Například když dělá počáteční sestavování nějaké skupiny balíčků, umí udělat slušný odhad toho, které závislosti je nutné buildovat společně. Někdy ale mohou být informace poskytované debianími zdrojovými balíčky nekompletní a pak se odhad netrefí. Proto se Sieve periodicky snaží znovu sestavovat skupiny balíčků, které selhaly. Může se tak klidně stát, že do snapshotu se najednou dostane bez potíží při sestavení skupina balíčků, které až dosud selhávaly. Většina tohoto systému je přitom plně automatizovaná, obvykle při selhání pak stačí zkusit jen jednou znovu sestavení s opravou a pokud je nutné opravu aplikovat pořád dokola, její zaslání do kódu projektu dále sníží náročnost na celý systém u Googlu.
Má to i jisté bezpečností výhody. Pokud dojde na nějaký bezpečností incident, díky takto navržené buildovací architektuře má Google jistotu a může rychle balíček rebuildovat s pár dočasnými patchi, protože tento kód již beztak byl v rámci systému sestaven a otestován. Systém je také nastaven tak, že je možné kryptograficky testovat, že běžící binárky mají svůj původ v daném zdrojovém kódu z projektu Debian (tedy nedošlo k nějakému podvržení kódu).
Přechodné období
Posledním systémem Goobuntu na bázi Ubuntu LTS bylo použití verze Ubuntu 14.04 LTS. Vývoj Rodete započal v roce 2015 a rychle se ukázalo, že prostě nejde chtít po vývojářích, aby ze dne na den přešli na nový systém a zahodila se podpora pro 14.04 LTS. Ale díky velkému překryvu mezi Ubuntu a Debianem běžely práce rychle, některé části Googlí infrastruktury bylo možné použít i pro Rodete.
V rámci přechodu tvůrci v Googlu zmrazili Rodete na jistém snapshotu Debianu Testing z roku 2016. V roce 2017 začal proces migrace strojů na Rodete, doběhl pak v závěru roku 2018, nicméně tento systém obsahoval základní balíčky sahající až dva roky do minulosti. Tým se zaměřil na optimalizace chování Sieve a zrychlení běhu celé architektury sestavování a testování balíčků. Tím, že na sebe převzali běh tohoto řetězce rolujících snapshotů tak tým odlehčil vývojářům Googlu jejich práci s aktualizací svých pracovních stanic.
Počátkem roku 2019 pak začalo vypínání posledních pozůstatků strojů s Goobuntu, baseline systému Rodete v tu chvíli zaostával za upstreamem přibližně o 250 dnů a většina balíčků byla z Debianu Buster. V polovině roku 2020 se pak podařilo stále rychlým rolováním snapshotů dohnat skluz, zhruba v době Debianu Bullseye. Pravděpodobně tak v Googlu při udržení tempa budou používat systém odpovídající příštímu vydání Debianu stable ještě před jeho vydáním v polovině roku 2023.
Dosažení Zenu
Dnes tak život týmu gLinux vypadá jinak. Snížil se objem práce a náročnost z hlediska času i energie vývojářů. Ti už tak neprovádějí současný přechod myriády strojů na nové Ubuntu, honíce přitom poslední zbývající stroje zapomenuté na předchozích verzích. Zvýšila se i bezpečnost celého systému, díky běhu pracovních stanic na verzích blízko upstreamu, nemluvě o tom, že ve starších stále podporovaných vydáním Debianu nebývají hned záplatovány všechny nalezené chyby.
Práce na co největší automatizaci a zrychlení procesů se tedy vyplatily na všech frontách. Do budoucna v Googlu plánují ještě užší spolupráci s upstream Debianem a zasílání ještě většího podílu interních patchů do ekosystému debianích balíčků.
ČLÁNKY DO MAILU