L'histoire derrière le Linux de bureau interne de Google

L'histoire derrière le Linux de bureau interne de Google

Si vous regardez les bureaux de Google à Mountain View, en Californie, vous verrez des machines Windows, des Chromebooks, des Mac et des ordinateurs de bureau gLinux. G quoi, demandez-vous? Eh bien, en plus de s'appuyer sur Linux pour ses serveurs, Google possède sa propre distribution de bureau Linux.

Vous ne pouvez pas l'obtenir, merde! - mais depuis plus d'une décennie, Google cuisine et mange sa propre distribution de bureau Linux maison. La première version était Goobuntu. (Comme vous pouvez le deviner d'après son nom, il était basé sur Ubuntu.)

En 2018, Google a déplacé son bureau Linux interne de Goobuntu vers une nouvelle distribution Linux, gLinux basée sur Debian. Parce que? Parce que, comme l'a expliqué Google, la version de support à long terme (LTS) d'Ubuntu "signifiait que nous devions mettre à jour chaque machine de notre flotte de plus de 100,000 XNUMX appareils avant la date de fin de vie du système d'exploitation".

Ajoutez à cela le besoin fastidieux de personnaliser entièrement les PC des ingénieurs, et Google a décidé que c'était trop cher. De plus, "L'effort de mise à niveau de notre flotte Goobuntu prenait généralement une bonne partie d'un an. Avec une fenêtre de support de deux ans, il ne restait qu'un an avant que nous devions répéter le même processus pour le prochain LTS. Tout ce processus a été un énorme facteur de stress pour notre équipe, car nous avons reçu des centaines de bogues avec des demandes d'aide pour des cas critiques."

Ainsi, lorsque Google en a eu assez, il est passé à Debian Linux (mais pas seulement à Debian standard). La société a créé une distribution Debian roulante : GLinux Rolling Debian Testing (Rodete). L'idée est que les utilisateurs et les développeurs sont mieux servis en leur fournissant les dernières mises à jour et correctifs au fur et à mesure qu'ils sont construits et jugés prêts pour la production. Ces distributions incluent Arch Linux, Debian Testing et openSUSE Tumbleweed.

Pour Google, l'objectif immédiat était de sortir du cycle de mise à jour de deux ans. Comme l'a montré le passage à l'intégration continue/déploiement continu (CI/CD), ces changements progressifs fonctionnent bien. Ils sont également plus faciles à contrôler et à annuler en cas de problème.

Pour que tout fonctionne sans beaucoup de sang, de sueur et de larmes, Google a créé un nouveau système de flux de travail, Sieve. Chaque fois que Sieve détecte une nouvelle version d'un paquet Debian, il démarre une nouvelle construction. Ces packages sont regroupés dans des groupes de packages car des packages distincts doivent souvent être mis à jour ensemble. Une fois l'ensemble du pool créé, Google exécute une suite de tests virtualisés pour s'assurer que les composants principaux et les flux de travail des développeurs ne sont pas perturbés. Chaque groupe est ensuite testé séparément avec une installation complète du système, un démarrage et une exécution de la suite de tests locale. Le package se construit en quelques minutes, mais les tests peuvent prendre jusqu'à une heure.

Une fois cela fait, tous les nouveaux packages sont fusionnés dans le dernier groupe de packages gLinux. Ensuite, lorsque Google décide qu'il est temps de le mettre en production, l'équipe prend un instantané de ce pool. Enfin, déployez la nouvelle version de la flotte. Bien sûr, cela ne sera pas seulement téléchargé pour les utilisateurs. Au lieu de cela, il utilise des principes d'ingénierie de fiabilité de site (SRE) tels que le canarying incrémental pour s'assurer que tout va bien.

Au fil des ans, Google s'est amélioré dans ce domaine. Aujourd'hui, grâce à Sieve, toute l'équipe de développement gLinux se compose d'un seul poste d'ingénieur de publication en service qui tourne entre les membres de l'équipe. Il n'y a pas d'efforts majeurs pour moderniser la flotte. Il n'y a pas de versions alpha, bêta et multi-étapes de disponibilité générale (GA).

Mieux encore, avec le calendrier de publication glissant, Google peut rapidement corriger les failles de sécurité sur l'ensemble de la flotte sans compromettre la stabilité. Auparavant, les ingénieurs en sécurité devaient examiner attentivement chaque avis de sécurité Debian (DSA) pour s'assurer que le correctif était présent.

En outre, "la suite de tests améliorée de Google et les tests d'intégration avec des équipes partenaires clés exécutant des systèmes de développement critiques ont également abouti à une expérience plus stable lors de l'utilisation d'une distribution Linux qui fournit les dernières versions du noyau Linux. Notre fort désir d'automatiser tout dans le pipeline a considérablement réduit le travail et le stress au sein de l'équipe, et il nous est désormais également possible de signaler des bogues et des incompatibilités avec d'autres versions de bibliothèque tout en nous assurant que les outils Google fonctionnent mieux au sein de l'écosystème Linux".

À l'avenir, l'équipe de Google a déclaré qu'elle "travaillerait plus étroitement avec Debian en amont et contribuerait davantage à nos correctifs internes pour maintenir l'écosystème de paquets Debian".

Tout sonne bien. Mais j'ai deux pensées à partager.

Premièrement, pour certaines organisations, les versions LTS ont toujours un sens. Si vous n'avez pas besoin des logiciels les plus récents et les plus performants pour votre entreprise, Ubuntu Linux ou Red Hat LTS a toujours du sens.

Deuxièmement et plus important : Sieve sonne comme le miaulement d'un chat. Un programme capable d'automatiser un pipeline de production de diffusion de diffusion au point où il suffit d'un seul ingénieur pour maintenir un ordinateur de bureau utilisé par plus de 100,000 XNUMX utilisateurs ? Enregistre-moi!

Mieux encore, veuillez publier le code pour Sieve afin que nous puissions tous commencer à produire des versions de bureau Linux de manière continue. Qu'en est-il de Google ? Que dis-tu?

Copyright © 2022 IDG Communications, Inc.