Het verhaal achter de interne desktop Linux van Google

Als je rondkijkt in de kantoren van Google Mountain View, CA, zie je Windows-machines, Chromebooks, Macs en gLinux-desktops. G wat, vraag je? Welnu, naast het vertrouwen op Linux voor zijn servers, heeft Google zijn eigen Linux-desktopdistributie.

Je kunt het niet krijgen – verdorie! – maar al meer dan een decennium bakt en eet Google zijn eigen zelfgemaakte Linux-desktopdistributie. De eerste versie was Goobuntu. (Zoals je zou raden aan de naam, was het gebaseerd op Ubuntu.)

In 2018 verhuisde Google zijn interne Linux-desktop van de Goobuntu naar een nieuwe Linux-distro, de op Debian gebaseerde gLinux. Waarom? Omdat, zoals Google heeft uitgelegd, de tweejarige release van Ubuntu’s Long Term Support (LTS) “betekende dat we elke machine in onze vloot van meer dan 100.000 apparaten moesten upgraden vóór de datum van einde levensduur van het besturingssysteem.”

Dat was een pijn. Voeg daarbij de tijdrovende noodzaak om de pc’s van technici volledig aan te passen, en Google besloot dat het te veel kostte. Bovendien duurde de “inspanning om onze Goobuntu-vloot te upgraden meestal het grootste deel van een jaar. Met een ondersteuningsperiode van twee jaar was er nog maar een jaar over voordat we hetzelfde proces opnieuw moesten doorlopen voor de volgende LTS. Dit hele proces was een enorme stressfactor voor ons team, aangezien we honderden bugs kregen met hulpverzoeken voor hoekzaken.”

Dus toen Google daar genoeg van had, verhuisde het naar Debian Linux (hoewel niet alleen vanille Debian). Het bedrijf creëerde een rollende Debian-distributie: GLinux Rolling Debian Testing (Rodete). Het idee is dat gebruikers en ontwikkelaars het beste geholpen worden door hen de laatste updates en patches te geven zodra ze zijn gemaakt en klaar zijn voor productie. Dergelijke distributies omvatten Arch Linux, Debian Testing en openSUSE Tumbleweed.

Voor Google was het directe doel om uit de tweejarige upgradecyclus te komen. Zoals de overstap naar Continuous Integration/Continuous Deployment (CI/CD) heeft laten zien, werken deze incrementele veranderingen goed. Ze zijn ook gemakkelijker te controleren en terug te draaien als er iets misgaat.

Om dit allemaal te laten werken zonder veel bloed, zweet en tranen, heeft Google een nieuw workflowsysteem gemaakt, Sieve. Telkens wanneer Sieve een nieuwe versie van een Debian-pakket ontdekt, start het een nieuwe build. Deze pakketten zijn in pakketgroepen gebouwd, omdat afzonderlijke pakketten vaak samen moeten worden geüpgraded. Zodra de hele groep is gebouwd, voert Google een gevirtualiseerde testsuite uit om ervoor te zorgen dat er geen kerncomponenten en ontwikkelaarsworkflows worden verbroken. Vervolgens wordt elke groep afzonderlijk getest met een volledige systeeminstallatie, opstart en lokale testsuite. Het pakket is binnen enkele minuten voltooid, maar het testen kan tot een uur duren.

Zodra dat is gebeurd, worden alle nieuwe pakketten samengevoegd met de nieuwste gLinux-pakketpool. Wanneer Google vervolgens besluit dat het tijd is om het in productie te nemen, maakt het team een ​​momentopname van die pool. Ten slotte rolt het de nieuwe release uit naar de vloot. Natuurlijk zal het het niet zomaar op gebruikers dumpen. In plaats daarvan maakt het gebruik van Site-betrouwbaarheidsengineering (SRE)-principes zoals incremental canarying om ervoor te zorgen dat er niets misgaat.

Google is hier in de loop der jaren steeds beter in geworden. Dankzij Sieve bestaat het hele gLinux-ontwikkelteam tegenwoordig uit een enkele dienstdoende release-engineerpositie die rouleert onder de teamleden. Er zijn geen grote pushen om de vloot te upgraden. Geen alfa-, bèta- en algemene beschikbaarheidsreleases (GA) in meerdere fasen.

Sterker nog, dankzij het voortschrijdende releaseschema kan Google beveiligingslekken in de hele vloot snel dichten zonder de stabiliteit in gevaar te brengen. Voorheen moesten beveiligingsingenieurs elk Debian-beveiligingsadvies (DSA) zorgvuldig doornemen om er zeker van te zijn dat de oplossing binnen was.

Bovendien hebben Google’s “verbeterde testsuite en integratietests met belangrijke partnerteams die kritieke ontwikkelaarssystemen gebruiken, ook een stabielere ervaring opgeleverd met behulp van een Linux-distributie die de nieuwste versies van de Linux-kernel biedt. Ons sterke verlangen om alles in de pijplijn te automatiseren heeft Aanzienlijk minder tool en stress binnen het team. Het is nu voor ons ook mogelijk om bugs en incompatibiliteit met andere bibliotheekversies te melden, terwijl we ervoor zorgen dat Google-tools beter werken binnen het Linux-ecosysteem.”

Vooruitkijkend verklaarde het team van Google dat het “nauwer zal samenwerken met upstream Debian en meer van onze interne patches zal bijdragen om het Debian-pakketecosysteem te behouden.”

Dat klinkt allemaal geweldig. Maar ik heb twee gedachten om te delen.

Ten eerste zijn LTS-releases voor sommige organisaties nog steeds zinvol. Als je niet de nieuwste, meest glanzende programma’s voor je bedrijf nodig hebt, is een Ubuntu of Red Hat LTS Linux nog steeds zinvol.

Ten tweede, en dit is de belangrijkste: zeef klinkt als het miauwen van de kat. Eén programma dat een rollende distributiepijplijn kan automatiseren tot het punt waarop er slechts één technicus nodig is om een ​​desktop te onderhouden die door meer dan 100.000 gebruikers wordt gebruikt? Schrijf me in!

Beter nog, geef Sieve’s code vrij, zodat we allemaal Linux-desktopversies kunnen gaan produceren. Hoe zit het, Google? Wat zeg jij?

Copyright © 2022 IDG Communications, Inc.

Leave a Comment