A história por trás da distribuição Linux interna do Google

Se você olhar ao redor dos escritórios do Google em Mountain View, CA, verá máquinas Windows, Chromebooks, Macs e desktops gLinux. “‘G’ o quê?”, você pergunta. Bem, além de contar com o Linux para seus servidores, o Google tem sua própria distribuição de desktop Linux.

Você não pode obtê-lo – mas por mais de uma década, o Google vem cozinhando e comendo sua própria distribuição de desktop Linux caseira. A primeira versão foi Goobuntu. (Como você pode adivinhar pelo nome, foi baseado no Ubuntu.)

Em 2018, o Google mudou seu desktop Linux interno do Goobuntu para uma nova distribuição Linux, o gLinux baseado em Debian. Por quê? Porque, como o Google explicou, o lançamento de dois anos do Suporte de Longo Prazo (LTS) do Ubuntu “significava que tínhamos que atualizar todas as máquinas em nossa frota de mais de 100.000 dispositivos antes da data de fim de vida do sistema operacional”.

Isso doeu. Acrescente a necessidade demorada de personalizar totalmente os PCs dos engenheiros, então o Google entendeu que custava muito caro. Além disso, o “esforço para atualizar nossa frota Goobuntu geralmente levava quase um ano. Com uma janela de suporte de dois anos, restava apenas um ano até que tivéssemos que passar pelo mesmo processo novamente para o próximo LTS. Todo esse processo foi um grande fator de estresse para nossa equipe, pois recebemos centenas de bugs com pedidos de ajuda para corner cases”.

Então, quando o Google deu um basta nisso, ele mudou para o Debian Linux. A empresa criou uma distribuição Debian contínua: GLinux Rolling Debian Testing (Rodete). A ideia é que usuários e desenvolvedores sejam mais bem atendidos ao fornecer as atualizações e patches mais recentes à medida que são criados e considerados prontos para produção. Essas distribuições incluem Arch Linux, Debian Testing, e openSUSE Tumbleweed.

Para o Google, o objetivo imediato era sair do ciclo de atualização de dois anos. Como a mudança para Integração Contínua/Implantação Contínua (CI/CD) mostrou, essas mudanças incrementais funcionam bem. Eles também são mais fáceis de controlar e reverter se algo der errado.

Para fazer tudo isso funcionar sem muito sangue, suor e lágrima, o Google criou um novo sistema de fluxo de trabalho, o Sieve. Sempre que o Sieve detecta uma nova versão de um pacote Debian, ele inicia uma nova compilação. Esses pacotes são construídos em grupos de pacotes, pois pacotes separados geralmente precisam ser atualizados juntos. Após a criação de todo o grupo, o Google executa um conjunto de testes virtualizado para garantir que nenhum componente principal e fluxos de trabalho do desenvolvedor sejam interrompidos. Em seguida, cada grupo é testado separadamente com uma instalação completa do sistema, inicialização e execução do conjunto local de testes. O pacote é concluído em minutos, mas o teste pode levar até uma hora.

Feito isso, todos os novos pacotes são mesclados com o mais novo conjunto de pacotes gLinux. Então, quando o Google decide que é hora de lançá-lo em produção, a equipe faz um instantâneo desse pool. Por fim, lança o novo lançamento na frota. Claro, não vai apenas despejá-lo nos usuários. Em vez disso, ele usa princípios de engenharia de confiabilidade do site (SRE), como canarying incremental para garantir que nada dê errado.

Ao longo dos anos, o Google ficou melhor nisso. Hoje, graças ao Sieve, toda a equipe de desenvolvimento do gLinux consiste em um único cargo de engenheiro de lançamento em serviço que alterna entre os membros da equipe. Não há grandes empurrões para atualizar a frota. Não há versões alfa, beta e disponibilidade geral (GA) em vários estágios.

Melhor ainda, graças ao cronograma de lançamento contínuo, o Google pode corrigir falhas de segurança em toda a frota rapidamente, sem comprometer a estabilidade. Anteriormente, os engenheiros de segurança tinham que revisar cuidadosamente cada Debian Security Advisory (DSA) para ter certeza de que a correção estava correta.

Além disso, o “pacote de testes aprimorado do Google e os testes de integração com as principais equipes de parceiros que executam sistemas críticos de desenvolvimento também renderam uma experiência mais estável, usando uma distribuição Linux que fornece as versões mais recentes do Linux Kernel. Nosso forte desejo de automatizar tudo no pipeline tem reduzido significativamente o trabalho e o estresse da equipe. Agora também é possível relatar bugs e incompatibilidades com outras versões de biblioteca, garantindo que as ferramentas do Google funcionem melhor no ecossistema Linux”.

Olhando para o futuro, a equipe do Google declarou que trabalhará “mais de perto com o Debian upstream e contribuirá mais com nossos patches internos para manter o ecossistema de pacotes Debian”.

Isso tudo soa muito bem. Mas eu tenho dois pensamentos para compartilhar.

Primeiro, para algumas organizações, as versões LTS ainda fazem sentido. Se você não precisa dos programas mais novos e brilhantes para o seu negócio, um Ubuntu ou Red Hat LTS Linux ainda faz sentido.

Segundo, e este é o mais importante: Sieve soa como o canto da sereia. Um programa que pode automatizar um pipeline de produção de distribuição contínua até o ponto em que é necessário apenas um engenheiro para manter um desktop usado por mais de 100.000 usuários? Inscreva-me!

Melhor ainda, libere o código do Sieve para que todos possamos começar a produzir versões contínuas de desktop Linux. Que tal, Google? O que você diz?