Google raconte son parcours de Goobuntu à la distribution interne de bureau gLinux
Le siège social de Google à Mountain View, en Californie, regorge de Windows, de Chromebooks, de Mac, etc. Mais en plus de s'appuyer sur des serveurs Linux, le géant de la technologie possède en fait sa propre distribution de bureau Linux. Bien que peu de choses soient connues du monde extérieur, Google se prépare activement. La première version est Goobuntu basée sur Ubuntu.
En 2018, Google a déplacé son bureau Linux interne de Goobuntu vers la distribution gLinux basée sur Debian. La société a expliqué : "La période de deux ans d'Ubuntu LTS signifie que nous devons mettre à niveau plus de 100 000 appareils avant la fin de la période de support du système d'exploitation. La mise à niveau complète de la flotte Goobuntu prendra la majeure partie de l'année, ce qui signifie qu'il ne reste qu'un an dans la fenêtre. Combiné avec le temps requis pour la personnalisation complète des PC d'ingénierie, cela était extrêmement coûteux et pénible. Pour aggraver les choses, lors de la prochaine manche LTS, l'équipe de Goobuntu a dû tout recommencer. L'ensemble du processus a été un énorme facteur de stress pour nous, essayant d'aider à résoudre toutes sortes de situations extrêmes en plus de résoudre des centaines de problèmes.
En ayant assez de tout cela, il n'est pas difficile de comprendre pourquoi Google passe d'Ubuntu à Debian Linux. Il convient de souligner que la société a créé une distribution spéciale Debian roulante - il s'agit de GLinux Rolling Debian Testing (Rodete). La vision est de fournir la meilleure expérience possible aux utilisateurs et aux développeurs, en leur fournissant les derniers correctifs et mises à jour dès qu'ils sont créés et considérés comme prêts pour la production. Les distributions de cette catégorie incluent Arch Linux, Debian Testing et openSUSE Tumbleweed. Mais pour Google, l'objectif le plus urgent à ce stade est de se débarrasser de la limite de cycle de mise à niveau de deux ans.
Comme le montre le passage à l'intégration/déploiement continu (CI/CD), ces changements incrémentiels fonctionnent plutôt bien. Même si vous rencontrez des problèmes, il est plus facile de contrôler et de revenir en arrière. Afin que tout cela fonctionne sans beaucoup de temps et d'efforts, Google a même créé un nouveau système de workflow Sieve. Chaque fois qu'il trouve une nouvelle version d'un paquet Debian, il démarre une nouvelle construction. De plus, ces packages sont également placés dans des groupes, étant donné que les packages individuels doivent généralement être mis à niveau ensemble. L'étape suivante consiste à tester chaque ensemble de packages individuellement à l'aide d'une installation complète du système, d'un démarrage et d'une suite de tests locaux - les versions de packages peuvent être terminées en quelques minutes, mais les tests peuvent prendre une heure. Une fois terminé, tous les nouveaux packages seront fusionnés avec le dernier pool de packages gLinux. Ensuite, lorsque Google décide de le mettre en production, l'équipe active les instantanés de ce pool. La dernière consiste à pousser la nouvelle version à l'ensemble de la flotte, mais pas seulement à la décharger des utilisateurs, mais progressivement en se basant sur les principes de l'ingénierie de la fiabilité du site (SRE) (comme le Canarying incrémental) pour éviter les erreurs majeures.
Google le fait bien depuis des années. Et grâce à Sieve, aujourd'hui, toute l'équipe de développement gLinux est dirigée par un ingénieur de publication qui tourne entre les membres. Même si vous souhaitez mettre à niveau toutes les machines, vous n'avez pas besoin de pousser trop fort - car cela coupe plusieurs étapes de l'alpha, de la bêta à la version générale (GA). Mieux encore, grâce à un calendrier de publication glissant, Google peut rapidement corriger les failles de sécurité dans son parc sans compromettre la stabilité globale. Jusque-là, les ingénieurs en sécurité doivent passer en revue chaque bulletin de sécurité Debian (DSA) pour s'assurer que tous les correctifs sont inclus. De plus, Google améliore sa suite de tests et exécute des tests d'intégration clés sur les principaux systèmes de développement, et les équipes partenaires évaluent l'expérience stable fournie par son dernier noyau/distro Linux. Notre fort désir d'automatiser tout dans le pipeline a considérablement réduit la charge de travail et le stress de l'équipe. Il est désormais également possible de signaler des bogues et des incompatibilités avec d'autres versions de la bibliothèque, tout en s'assurant que les outils Google fonctionnent mieux dans l'écosystème Linux.
À l'avenir, l'équipe Google contribuera également à maintenir l'écosystème de packages Debian en travaillant plus étroitement avec Debian en amont et en contribuant à davantage de correctifs internes. Tout cela a l'air génial, mais Computer World a deux points à souligner : Premièrement, pour certaines organisations, les versions de support à long terme LTS ont toujours un sens. Si votre entreprise n'a pas besoin des programmes les plus récents et les plus performants, Ubuntu ou Red Hat LTS Linux sont toujours de bonnes options. Deuxièmement, la CW ne croit pas que Google ait développé un pipeline de production automatisé capable d'automatiser toute une distribution continue au point où un seul ingénieur peut maintenir un bureau Linux de plus de 100 000 utilisateurs. Plus important encore, si Google est suffisamment confiant, il pourrait tout aussi bien partager le code Sieve directement, afin que tout le monde puisse facilement démarrer avec la distribution de bureau Linux en continu.
