La storia dietro il desktop Linux interno di Google

La storia dietro il desktop Linux interno di Google

Se guardi gli uffici di Google a Mountain View, in California, vedrai macchine Windows, Chromebook, Mac e desktop gLinux. G cosa, chiedi? Bene, oltre a fare affidamento su Linux per i suoi server, Google ha la sua distribuzione desktop Linux.

Non puoi capirlo, dannazione! - ma da oltre un decennio Google ha cucinato e mangiato la propria distribuzione desktop Linux fatta in casa. La prima versione è stata Goobuntu. (Come puoi intuire dal nome, era basato su Ubuntu.)

Nel 2018, Google ha spostato il suo desktop Linux interno da Goobuntu a una nuova distribuzione Linux, gLinux basata su Debian. Perché? Perché, come ha spiegato Google, il rilascio di due anni di supporto a lungo termine (LTS) di Ubuntu "significava che dovevamo aggiornare ogni macchina nella nostra flotta di oltre 100,000 dispositivi prima della data di fine vita del sistema operativo".

è stato un dolore.Aggiungi a ciò la noiosa necessità di personalizzare completamente i PC degli ingegneri e Google ha deciso che era troppo costoso. Inoltre, "Lo sforzo per aggiornare la nostra flotta Goobuntu in genere ha richiesto buona parte di un anno. Con una finestra di supporto di due anni, mancava solo un anno prima che avremmo dovuto ripetere lo stesso processo per il prossimo LTS. Tutti questo processo è stato un enorme fattore di stress per il nostro team poiché abbiamo ricevuto centinaia di bug con richieste di aiuto per casi critici."

Quindi, quando Google ne ha avuto abbastanza, è passato a Debian Linux (ma non solo a Debian standard). L'azienda ha creato una distribuzione Debian a rotazione: GLinux Rolling Debian Testing (Rodete). L'idea è che utenti e sviluppatori siano meglio serviti fornendo loro gli aggiornamenti e le correzioni più recenti man mano che vengono creati e ritenuti pronti per la produzione. Queste distribuzioni includono Arch Linux, Debian Testing e openSUSE Tumbleweed.

Per Google, l'obiettivo immediato era uscire dal ciclo di aggiornamento di due anni. Come ha dimostrato il passaggio all'integrazione continua/distribuzione continua (CI/CD), queste modifiche incrementali funzionano bene. Sono anche più facili da controllare e annullare se qualcosa va storto.

Per far funzionare tutto senza molto sangue, sudore e lacrime, Google ha creato un nuovo sistema di flusso di lavoro, Sieve. Ogni volta che Sieve rileva una nuova versione di un pacchetto Debian, avvia una nuova build. Questi pacchetti sono raggruppati in gruppi di pacchetti perché spesso è necessario aggiornare insieme pacchetti separati. Una volta creato l'intero pool, Google esegue una suite di test virtualizzata per garantire che i componenti principali e i flussi di lavoro degli sviluppatori non vengano interrotti. Ciascun gruppo viene quindi testato separatamente con un'installazione completa del sistema, l'avvio e l'esecuzione della suite di test locale. Il pacchetto viene compilato in pochi minuti, ma i test possono richiedere fino a un'ora.

Fatto ciò, tutti i nuovi pacchetti vengono uniti nell'ultimo gruppo di pacchetti gLinux. Quindi, quando Google decide che è ora di metterlo in produzione, il team scatta un'istantanea di quel pool. Infine, distribuisci la nuova versione della flotta. Naturalmente, questo non verrà solo scaricato per gli utenti. Al contrario, utilizza i principi dell'ingegneria dell'affidabilità del sito (SRE) come il canarying incrementale per garantire che nulla vada storto.

Nel corso degli anni, Google è migliorato in questo settore. Oggi, grazie a Sieve, l'intero team di sviluppo di gLinux è costituito da un'unica posizione di Serving Release Engineer che ruota tra i membri del team. Non ci sono grandi sforzi per modernizzare la flotta. Non sono disponibili versioni alfa, beta e disponibilità generale (GA) multifase.

Ancora meglio, con la pianificazione dei rilasci in sequenza, Google può correggere rapidamente i difetti di sicurezza nell'intero parco istanze senza compromettere la stabilità. In precedenza, gli ingegneri della sicurezza dovevano rivedere attentamente ogni Debian Security Advisory (DSA) per assicurarsi che la patch fosse presente.

Inoltre, "la suite di test avanzata di Google e i test di integrazione con i principali team dei partner che eseguono sistemi di sviluppo mission-critical hanno portato anche a un'esperienza più stabile quando si utilizza una distribuzione Linux che fornisce le versioni più recenti del kernel Linux." Linux Il nostro forte desiderio di automatizzare tutto in la pipeline ha notevolmente ridotto il lavoro e lo stress all'interno del team, e ora è anche possibile per noi segnalare bug e incompatibilità con altre versioni della libreria assicurandoci che gli strumenti di Google funzionino meglio all'interno dell'ecosistema Linux.

Andando avanti, il team di Google ha affermato che "lavorerà più a stretto contatto con Debian a monte e contribuirà maggiormente alle nostre patch interne per mantenere l'ecosistema dei pacchetti Debian".

Tutto suona bene. Ma ho due pensieri da condividere.

Innanzitutto, per alcune organizzazioni, le versioni LTS hanno ancora senso. Se non hai bisogno del software più recente e migliore per la tua azienda, un Ubuntu Linux o Red Hat LTS ha ancora senso.

Secondo e più importante: il setaccio suona come il miagolio di un gatto. Un programma in grado di automatizzare una pipeline di produzione per la distribuzione di trasmissioni al punto in cui basta un solo tecnico per mantenere un desktop utilizzato da oltre 100,000 utenti? Iscrivimi!

Meglio ancora, pubblica il codice per Sieve in modo che tutti possiamo iniziare a produrre build desktop Linux su base continuativa. E Google? Che ne dici?

Copyright © 2022 IDG Communications, Inc.