Canonical přitom volí trochu jiný přístup než Fedora u Silverblue či openSUSE u MicroOS. Principipální základy jsou ale velmi podobné. Cílem Canonicalu bylo a je vybudovat systém, který bude plně kontejnerovaný včetně jádra, každá systémová komponenta bude schována ve svém vlastním sandboxu a bude dobře navržen systém aktualizací i rollbacků, vše dobře použitelné pro autonomně fungující IoT zařízení, která se budou schopna automaticky aktualizovat bez lidského zásahu a budou se moci spolehnout na funkčnost těchto aktualizací.
Co se dozvíte v článku
Jak v úvodu povídání o Ubuntu Core píše Oliver Smith z Canonicalu, desktopový software je trochu jiný kalibr, oproti IoT či serverovému nasazení je složitější jej kontejnerizovat, protože u desktopových aplikací typicky chceme, aby dobře spolupracovaly. Kvůli tomu se hůře definují mantinely jednotlivých sandboxů na úrovních aplikací a systémových komponent.
S tím vším dále souvisí další známý projekt Canonicalu, a sice distribuování aplikací ve formě balíčků Snap. Jak sám Oliver píše, Snapy jsou známy tím, že mají na desktopu trochu neohlazené hrany, nicméně vývojáři Canonicalu jsou nadšení z prozkoumávání ideje plně kontejnerizovaného desktopu, kde každá komponenta je neměnná a izolovaná. Právě toho součástí je Snap, kde Canonical postupně zlepšuje uživatelskou zkušenost z používání aplikací ve Snapech.
Pro příští rok se tak můžeme těšit na architektonicky novou variantu desktopového Ubuntu, které bude plně stát na izolovaných či sandboxovaných prvcích s neměnnou povahou, pojmenovanou Ubuntu Core.
Vlastnosti, výhody a nevýhody neměnného systému
Co si Canonical vytyčil. Daný neměnný systém bude pouze ke čtení, uživatel ani žádná aplikace nebude moci tento systém měnit. Aktualizace budou atomické a aplikované automaticky ve smyslu, že buď půjdou aplikovat všechny, nebo žádný. Systém bude ve svém chodu předvídatelný skrze různá zařízení a jeho aplikace budou izolované od jádra systému a samy od sebe, za pomoci kontejnerů. Změna v jedné aplikaci tak nijak neovlivní jinou či celý systém.
Výhody
Z výše uvedeného plynou logicky výhody takové architektury systému. Tou první je bezpochyby bezpečnost, kdy mezi všemi těmi kontejnery se sandboxy bude škodlivý software těžko hledat skulinky či schopnost šířit se z jedné aplikace na druhou.
Vzhledem k tomu, že budou distribuovány celé hotové neměnné balíky, bez náhodných chyb či smazání systémových souborů, lze očekávat i lepší stabilitu a systém, který se nikdy nedostane do stavu, kdy by aktualizace proběhly třeba jen částečně.
Jelikož je systém stále identický, je snadnější provádět testy, audity či ověřovat, diagnostikovat i řešit jakékoli problémy. Zjednodušuje se i správa takového systému a díky automatickým aktualizacím i možnosti návratu k původnímu stavu budou mít systémoví správci jednodušší život.
Nevýhody
Výše uvedené sebou přináší ale několik omezení. Systém jako celek je méně pružný, uživatelé jej nemohou nijak měnit ani upravovat ke své představě. Kontejnerová či sandboxová povaha nemusí být slučitelná se všemi aplikacemi, ty nemusí s kontenjerovaným prostředím systému vůbec fungovat.
Dále, jak třeba ví každý uživatel Flatpaků, představuje izolovanost aplikací vlekoucích si své závislosti vyšší požadavky na kapacitu úložišť, k čemu se zde přidává i vyšší potřeba diskového prostoru pro snapshoty, které Ubuntu Core hojně využívá. Vývoj aplikací pro takový systém též může být pro vývojáře náročnější.
Blíže k architektuře systému
Předně tu máme mezi neměnnými linuxovými systémy starý dobrý ChromeOS. Ten vyvinul Google primárně pro Chromebooky, přičemž jednou z klíčových vlastností je provázanost na cloudové úložiště a cloudové služby Googlu. Softwarový gigant zde používá read-only systém, sandboxované aplikace a procesy, spolu s hardwarově založeným šifrováním. Boot systému se ověřuje, aby bylo jisté, že nedošlo ke změně firmwaru či jádra (kontrola pomocí podpisu), a to během každé fáze procesu spouštění systému.
Aktualizace Google realizuje jako „A/B proces“, kdy jsou v zařízení drženy dvě verze operačního systému – jedna aktivně používaná a druhá neaktivní, vůči které lze na pozadí aplikovat modifikace a aktualizace. Jsou-li tyto změny provedeny úspěšně, přepne se při příštím bootu na tuto druhou verzi. Pokud ne, nastartuje se první obraz.
Fedora Silverblue a OSTree
Fedora u své neměnné varianty Silverblue používá podobný aktualizační mechanismus jako ChromeOS, a to za použití nástroje OSTree. S jeho pomocí stahuje kompletní obraz systému na pozadí, přičemž při příštím spuštění systému se použije tento nový obraz.
OSTree uchovává snapshoty jednotlivých změn verzí systému a během bootu si uživatel může vybrat, jakou verzi nastartuje. OSTree přitom distribuuje jen delta aktualizace, takže šetří diskový prostor (i přenosovou kapacitu internetového připojení).
openSUSE MicroOS a Btrfs snapshoty
Systémy od SUSE jsou známé svým nasazením souborového systému Btrfs, díky jehož schopnostem v oblasti snapshotů je možné pro uložení stavu systému využít právě tuto vlastnost.
Stejnou věc, tedy použití Btrfs snapshotů pro uložení stavu používá i Ubuntu Core. Doplňme, že openSUSE nově ohlásilo varianty neměnného systému s plným desktopovým prostředím zvané openSUSE Aeon a Kalpa.
MicroOS používá Btrfs snapshoty na kořenový systém tak, že aplikuje aktualizace a pro příští boot systému označí tento nový systém jako cílový. Použitím těchto snapshotů šetří místo.
Aplikace v kontejnerech a Snapy
Oliver dále komentuje, že zatímco reboot systému po aktualizaci je záhodno provádět, neb jinak může být narušen běh aplikací či služeb, u aktualizací aplikací je to naopak nežádoucí. Aby se toto dilema vyřešilo, používají výše uvedené neměnné systémy kontejnerované aplikace (Docker, Flatpak atd.) běžící nezávisle na základním systému, přičemž nejsou považovány za součást souborového systému vlastního operačního systému.
To dává možnost kontrolovat onu proměnlivost aplikací a služeb, které nejsou kritické pro chod systému a jeho boot. Běžné aplikace zkrátka mohou být aktualizovány vlastním tempem bez nutnosti restartovat operační systém či jakkoli narušovat jeho odolnost.
Jak do toho zapadají Snapy? Inu, jde též o neměnné aplikace. Jakmile je snap nainstalován, je v systému ve své dané podobě, v kontejneru schovaném balíčku zahrnujícím aplikaci i všechny její závislosti. Vše je pěkně sbaleno do jednoho balíčku na bázi SquashFS. Při aktualizaci je pak daný balíček Snap atomicky nahrazen a uživatelská data jsou zkopírována do nové verze.
Snap je navíc lépe zabezpečen skrze svoji architekturu a robustní proces podepisování a ověřování. Při instalaci se ověřují veřejné vývojářské klíče ze Snap Store.
V Ubuntu Core je použití návrhu Snapů ještě na jiné úrovni, tento systém zabezpečení je aplikován v rámci celého systému. Ubuntu Core nepovažuje celý svůj systém za jediný neměnný blob, ale rozděluje se na jednotlivé oblasti snapů:
- Gadget: zahrnuje bootloader, rozložení diskových oddílů a výchozí konfigurace snapů
- Kernel: obsahuje jádro systému a ovladače hardwaru
- Base: minimální obraz Ubuntu OS a základní nezbytné služby a nástroje podporující běh aplikací nad nimi
- Snapd: správa životních cyklů všech snapů v Ubuntu Core
Nad to se mohou vrstvit další snapy, například jiná desktopová prostředí. Tento skládačkový přístup k architektuře přináší jisté výhody. Předně si uživatel může zprovoznit holé Ubuntu v základním provedení třeba pro běh jedné jediné aplikace, čímž sníží to, čemu osobně říkám „zahnojení systému zbytečnostmi“. Výhoda holého systému je i v menším množství potenciálních možností jeho napadení, dodává Oliver.
Poznámka: Před měsícem instaloval Mageia 9 s GNOME 44 na Waylandu a Intel CPU+iGPU, mezi instalovanými RPM balíčky byl i X.Org driver for ATI Mach 64VT, ovladač pro stařičkou PCI grafiku z doby před 30 lety a pro grafický server, který se prostě vůbec neinstaloval.
S vrstvením snapů na jednotlivých úrovních systému pak přichází další pružnost s kadenci nových verzí i možností vrátit se zpět v čase k předchozímu stavu (rollback). Jednoduše řečeno: systém – ovladače – nástroje – aplikace se mohou aktualizovat nezávisle na sobě.
Flexibilita aktualizačních kanálů snapů
Snapy jsou vymyšleny tak, že může existovat více kanálů pro distribuci aktualizací. Každý snap má čtyři standardní kanály: stable, candidate, beta a edge. Je na uživateli, jak moc na hraně se bude chtít pohybovat, s pomocí kanálů pak může uživatel využívat i postupné zavádění či snadné návraty.
Vývojáři či administrátoři naopak mohou uživatelům posouvat aktualizace například nejprve menší skupince a až později všem. Pokud je objeven problém, provede se u dotčených uživatelů návrat k původnímu stavu.
Potenciál pro desktopové Ubuntu
Vedle logického nasazení neměnné distribuce typu Ubuntu Core, se nabízí přenesení některých prvků i do desktopového vydání. Oliver jmenuje například Secure Boot, stavy obnovy či hardwarově podporované šifrování.
Dále samotný koncept modulární architektury, kde třeba uživatelé mohou zkoušet jiná desktopová prostředí schovaná ve snapech, zatímco mají stále k dispozici ověřený a stabilní základní desktop s dlouhodobou podporou (LTS).
Snapové kanály zase dávají možnost některé prvky systému prohánět rolujícími aktualizacemi. Hráči třeba mohou chtít používat jaderný kanál obsahující vždy i nejnovější ovladače Nvidia hned po jejich vydání, podobně jako to desktopový tým Ubuntu dělá u standardní verze Ubuntu s Mesa pro Steam.
Avšak to vše představuje změny a práci navíc pro vývojáře a další sestavovače balíčků apod. Jedni mohou být rádi za kontejnerový neměnný systém, druzí zase postrádat plnou kontrolu nad tímtéž. Právě těmito aspekty se budou vývojáři Canonicalu ještě v nadcházejících měsících zabývat. Nechme se tedy překvapit, jaké Ubuntu Core příští rok bude a jaké bude ve srovnání se svými obdobami od Red Hatu, SUSE či dalších.
