Resumo

Neste artigo, exploramos por que a execução do Linux na plataforma do Google Cloud é uma combinação poderosa. Também nos aprofundamos nas razões por trás da decisão do Google de usar o Linux internamente e os desafios que eles enfrentaram com as atualizações tradicionais. Em seguida, discutimos como o Google implementou lançamentos rolantes com o Glinux Rodete, com base no Debian, e os benefícios que ele traz para suas operações.

Pontos chave:

1. O Google administra grandes frotas de produção, incluindo YouTube e Gmail, usando uma variedade de plataformas OS, incluindo Linux.
2. Por um longo tempo, a distribuição interna do Google, Goobuntu, foi baseada em lançamentos do Ubuntu LTS.
3. O ciclo de atualização de dois anos para lançamentos de LTS apresentou desafios para a frota do Google de mais de 100.000 dispositivos.
4. Para automatizar o processo de atualização, o Google desenvolveu uma ferramenta de atualização no local não atendida que minimizou a configuração manual.
5. O processo de atualização geralmente levava quase um ano, levando a altos níveis de estresse e esgotamento na equipe.
6. Usar versões LTS significava que algumas correções e melhorias de bugs podem não ter sido backports.
7. Atualizações de casos especiais e desafios de gerenciamento de mudanças adicionados à complexidade e duração do processo de atualização.
8. Para resolver essas questões, o Google passou para lançamentos rolantes com o Glinux Ridete, com base nos testes do Debian.
9. Em vez de um ciclo de dois anos, lançamentos de rolamento espalham a carga de trabalho e permitiram pequenas mudanças incrementais.
10. A disponibilidade de pacotes em Debian, a comunidade Debian e os pacotes internos existentes influenciaram a escolha do Debian como distribuição base.

Questões:

1. Em quais plataformas o google executa?

O Google executa grandes frotas de produção em plataformas como o YouTube e o Gmail. Eles também têm uma frota corporativa com centenas de milhares de dispositivos em várias plataformas, modelos e locais.

2. Por que o Google escolheu o Ubuntu como base para sua distribuição interna do Linux?

O Google escolheu o Ubuntu para sua distribuição interna do Linux, porque foi fácil de usar, fácil de usar e ofereceu lançamentos de suporte a longo prazo (LTS) com mais de 2 anos de atualizações de segurança.

3. Que desafios o Google enfrentou com o ciclo de atualização de dois anos de lançamentos LTS?

A natureza complexa das cargas de trabalho na frota do Google tornou a reinstalação e a personalização das máquinas para cada atualização uma operação difícil e demorado. Isso não era financeiramente sustentável, e os engenheiros tiveram que configurar seu espaço de trabalho do zero a cada dois anos, levando a uma queda na produtividade.

4. Como o Google automatizou o processo de atualização?

O Google desenvolveu uma ferramenta de atualização no local não atendida que automatizou os problemas de caso comum durante o processo de atualização. Esta ferramenta salvou os engenheiros de atualizar manualmente suas máquinas, reinstalando-as e recriando todas as configurações.

5. Por que estava saindo de uma versão LTS estressante para a equipe do Google?

A atualização da frota Goobuntu levou quase um ano, deixando apenas uma pequena janela de tempo de inatividade até a próxima atualização. Esse ciclo constante de atualizações criou um ambiente de alto estresse para a equipe, levando a uma sensação de esgotamento. Bugs e solicitações de ajuda também adicionados à carga de trabalho.

6. Qual foi a motivação por trás da mudança do Google para lançamentos rolantes?

Em vez de seguir um ciclo de atualização de dois anos, o Google queria espalhar a carga de trabalho e permitir mudanças incrementais menores. Rolling comunicados com distribuições Linux mostraram que mudanças menores são mais fáceis de controlar e reverter.

7. Por que o Google escolheu o Debian para sua distribuição de lançamento de rolamento?

O Google escolheu Debian por sua distribuição de lançamento rolante, Glinux Ridete, porque ofereceu uma migração suave no local e teve uma grande comunidade debian. Pacotes internos e ferramentas existentes também usaram o formato Debian.

8. Que vantagens a faixa de teste do Debian fornece?

A faixa de teste do Debian Works como um lançamento rolante, fornecendo a piscina de todos os pacotes ingeridos e construídos a partir do upstream. Isso permite que o Google obtenha mudanças mais granulares e forneça o software mais recente para seus engenheiros sem períodos de espera mais longos.

9. Com que frequência as atualizações de lançamento do Google com sua distribuição de lançamento de rolamento?

O Google inicialmente destinou -se a lançamentos mais frequentes, mas descobriu que os lançamentos semanais alcançaram um equilíbrio entre se mover rapidamente e permitir a qualificação adequada de liberação. Isso ajudou a limitar a interrupção da produtividade do desenvolvedor.

10. Que abordagem o Google adotou para garantir versões suaves no processo de liberação do rolamento?

O Google tira um instantâneo de todos os pacotes ingeridos do Debian ao iniciar um novo lançamento. Após os testes de aceitação, o candidato à liberação hermética é com cautela para um grupo escolhido de usuários para testes adicionais.

Respostas:

1. O Google administra grandes frotas de produção que servem produtos como YouTube e Gmail. Eles também têm uma frota corporativa com centenas de milhares de dispositivos operando em várias plataformas, modelos e locais. Para apoiar seus funcionários, incluindo engenheiros, o Google opera com várias plataformas OS, incluindo Linux. Em 2018, o Google concluiu sua transição para um modelo de lançamento rolante baseado no Debian.
2. O Google escolheu o Ubuntu como base para sua distribuição interna do Linux, porque era fácil de usar, fácil de usar e ofereceu lançamentos de suporte a longo prazo (LTS) com mais de 2 anos de atualização de segurança. Esses lançamentos do LTS forneceram estabilidade e atualizações regulares de segurança para a frota de dispositivos do Google.
3. O ciclo de atualização de dois anos de lançamentos de LTS apresentou desafios para o Google. Com mais de 100.000 dispositivos em sua frota, atualizando e personalizando manualmente cada máquina antes da data de final de vida do sistema operacional era demorada e não é viável financeiramente. A natureza complexa das cargas de trabalho nas máquinas corporativas complicou ainda mais o processo de atualização.
4. Para automatizar o processo de atualização e minimizar a configuração manual, o Google desenvolveu uma ferramenta de atualização no local não atendida. Essa ferramenta se concentrou em automatizar problemas de casos comuns durante a atualização e salvar os engenheiros de ter que reinstalar máquinas e recriar todas as configurações manualmente.
5. O escapamento de uma versão LTS foi estressante para a equipe do Google devido ao extenso tempo e esforço necessários para o processo de atualização. Com um período de um ano entre as atualizações, a equipe experimentou um ciclo constante de atualizações e correções de bugs. Esse ambiente de alto estresse geralmente levava a uma sensação de esgotamento entre os membros da equipe.
6. A motivação por trás da mudança do Google para lançamentos de laminação foi espalhar a carga de trabalho e permitir mudanças incrementais menores. Essa abordagem está alinhada com a tendência da indústria de CI/CD e mostrou que mudanças menores são mais fáceis de controlar e reverter em comparação com atualizações grandes e pouco frequentes.
7. O Google escolheu o Debian como a base para sua distribuição de lançamento de rolamento, Glinux Ridete. A decisão foi influenciada por diferentes fatores, incluindo a disponibilidade de pacotes no Debian, a grande comunidade do Debian e a compatibilidade de pacotes internos existentes e ferramentas usando o formato Debian.
8. A faixa de teste do Debian oferece várias vantagens para a distribuição de lançamento do Google Rolling. A pista de teste funciona como um lançamento rolante, constantemente ingerindo e construindo pacotes de upstream. Isso permite que o Google tenha mudanças mais frequentes e granulares, fornecendo aos engenheiros acesso ao software mais recente sem períodos de espera prolongados.
9. O Google inicialmente destinou -se a lançamentos mais frequentes com sua distribuição de liberação rolante, mas posteriormente liquidados em lançamentos semanais. Os lançamentos semanais alcançaram um equilíbrio entre se mover rapidamente e permitir a qualificação adequada de liberação, minimizando a interrupção da produtividade do desenvolvedor.
10. Para garantir lançamentos suaves no processo de lançamento do rolling, o Google tira um instantâneo de todos os pacotes ingeridos do Debian no início de um novo lançamento. Após os testes de aceitação, o candidato à liberação hermética é impulsionada cautelosamente para um grupo selecionado de usuários para testes adicionais, garantindo uma liberação gradual e controlada.

Por que executar o Linux no Google Cloud

Linux e Google Cloud Platform são uma forte combinação para mover sua empresa para a nuvem e para o futuro. Deixar’s Dê uma olhada em cada um antes de aprender o que os faz se destacar como uma equipe.

Google é executado no Linux

Crédito da imagem do herói: Markus Teich

No Google, administramos grandes frotas de produção que servem produtos do Google como YouTube e Gmail. Para apoiar todos os nossos funcionários, incluindo engenheiros, também administramos uma frota corporativa considerável com centenas de milhares de dispositivos em várias plataformas, modelos e locais. Para permitir que cada googler trabalhe no ambiente em que são mais produtivos, operamos muitas plataformas OS, incluindo um sistema Linux. Por um longo tempo, nossa distribuição interna de Linux, Goobuntu, foi baseada nos lançamentos do Ubuntu LTS. Em 2018, concluímos uma mudança para um modelo de lançamento rolante baseado no Debian.

Atualizar o trabalho

Mais de 15 anos atrás, o Ubuntu foi escolhido como base para a distribuição interna do Linux, pois era fácil de usar, fácil de usar e tinha muitos extras sofisticados. Os lançamentos de suporte a longo prazo (LTS) foram escolhidos como foi valorizado que canônico, por mais de 2 anos de atualizações de segurança.

No entanto, esse ciclo de lançamento de dois anos para lançamentos de LTS também significava que tivemos que atualizar todas as máquinas em nossa frota de mais de 100.000 dispositivos antes da data de final de vida do sistema operacional. A natureza complexa das cargas de trabalho executadas em máquinas corporativas significava que a reinstalação e a personalização de máquinas pode ser uma operação difícil e demorada. O sucesso da produtividade de ter todos os engenheiros configurar seu espaço de trabalho do zero a cada dois anos não era uma opção financeiramente responsável.

Para cada ciclo do sistema operacional, tivemos um salto de versão bastante grande nos principais pacotes que poderiam exigir alterações significativas na configuração do software. Para automatizar esse processo, escrevemos uma ferramenta de atualização no local não atendida que cuidava de muitos problemas de caso comum. Essa abordagem focada na automação significava que a maioria dos funcionários do Google não precisava atualizar manualmente suas máquinas, reinstalando-as e recriando toda a sua configuração. Para tornar isso possível, no entanto, precisávamos fazer testes abrangentes do processo de atualização e verificar se todos os principais pacotes que haviam mudado continuaram funcionando (no Ubuntu, isso pode chegar a vários milhares de pacotes para atualizar entre as principais versões). Às vezes, era difícil fornecer automação nos casos em que as depreciações aconteciam e os engenheiros tiveram que tomar decisões sobre como avançar.

Esse esforço para atualizar nossa frota Goobuntu geralmente levou a maior parte de um ano. Com uma janela de suporte de dois anos, restava apenas um ano até que tivéssemos que passar pelo mesmo processo de novo para o próximo LTS. Todo esse processo foi um enorme fator de estresse para nossa equipe, pois obtivemos centenas de insetos com pedidos de ajuda para casos de canto. Uma vez que uma atualização foi feita, havia um senso geral de ser “perto de esgotamento” na equipe que mal conseguimos nos recuperar até a próxima rodada de atualizações surgiu. Executar uma versão LTS também significava que alguns bugs encontrados pelos usuários de nossa distribuição podem’já foi corrigido a montante, mas essas melhorias podem’nunca estive de volta para a versão LTS.

Havia também uma longa cauda de atualizações de casos especiais que às vezes podiam se arrastar por vários anos. Lidar com esse processo foi um enorme desafio de gerenciamento de mudanças para fazer com que os engenheiros atualizem as máquinas que não fizeram’t trabalho no processo automático. Ficamos criativos ao motivar nossos usuários a atualizar suas máquinas. As medidas variaram de mensagens incômodas em sua interface do usuário, e -mails, reinicializações programadas e até desligando as máquinas, para aumentar a conscientização de que ainda havia algumas máquinas com extrema necessidade de uma atualização. Às vezes, essas máquinas capturadas que as pessoas esqueceram totalmente, como a única máquina sob uma mesa que estava executando um pipeline crítico para algo importante, pois acabou.

Lançamentos de rolamento

Quando projetamos o Glinux Ridete (Rolling Debian Testing), pretendemos remover o ciclo de atualização de dois anos e, em vez disso, espalhar a carga na equipe ao longo do tempo. A mudança geral para CI/CD na indústria mostrou que mudanças incrementais menores são mais fáceis de controlar e reverter. Os lançamentos rolantes com as distribuições Linux hoje estão ficando mais comuns (Arch Linux, Nixos).

Consideramos outras distribuições do Linux, mas acabamos escolhendo o Debian porque novamente queríamos oferecer uma migração suave no local. Isso incluiu considerações sobre a disponibilidade de pacotes no Debian, a grande comunidade Debian e também os pacotes e ferramentas internos existentes que estavam usando o formato Debian. Enquanto a faixa estável do Debian segue um salto de aproximadamente dois anos entre os lançamentos, a pista de testes do Debian funciona como um lançamento, pois é a piscina de todos os pacotes ingeridos e construídos a partir de montante, esperando a próxima versão estável acontecer.

O tempo desde a liberação upstream até a disponibilidade nos testes geralmente é apenas alguns dias (embora durante os períodos de congelamento antes de um lançamento estável do Debian, às vezes pode ficar atrasado alguns meses atrás). Isso significa que podemos obter mudanças muito mais granulares em geral e fornecer o software mais recente para nossos engenheiros no Google sem ter que esperar períodos mais longos.

Essa frequência de atualizações nos exigia redesenhar muitos sistemas e processos. Embora originalmente pretendam lançamentos mais frequentes, descobrimos que, para nós, os lançamentos semanais eram um ponto ideal entre se mover rapidamente e permitir a qualificação adequada de liberação, limitando a interrupção da produtividade do desenvolvedor.

Sempre que iniciamos um novo lançamento, tiramos um instantâneo de todos os pacotes ingeridos do Debian naquele momento. Após alguns testes de aceitação, o novo candidato à liberação hermética é então cautelosamente lançada para uma frota de testes dedicada e um canário de frota de 1%. O canário é mantido intencionalmente ao longo de alguns dias para detectar problemas com pacotes debianos ou pacotes internos do Google antes de progridir para toda a frota.

Apresentando peneira

Para gerenciar todas essas tarefas complexas da criação de todos os pacotes a montante da fonte, construímos um sistema de fluxo de trabalho chamado peneira. Sempre que vemos qualquer nova versão de um pacote Debian, começamos uma nova compilação. Construímos pacotes em grupos de pacotes, para levar em consideração pacotes separados que precisam ser atualizados juntos. Depois que todo o grupo foi construído, executamos uma suíte de teste virtualizada para garantir que nenhum dos nossos principais componentes e fluxos de trabalho dos desenvolvedores estejam quebrados. Cada grupo é testado separadamente com uma instalação completa de instalação, inicialização e suíte de teste local executada nessa versão do sistema operacional. Enquanto as compilações para pacotes individuais geralmente são concluídas em minutos, esses testes podem levar até uma hora, dada a complexidade do grupo de pacotes.

Depois que os pacotes são construídos e todos os testes passados, mesclamos todos os novos pacotes com nosso último pool de pacotes. Quando reduzimos um novo lançamento, instantâneos que se acumulamos com cada versão do pacote bloqueada para esse lançamento. Em seguida, prosseguimos para guiar cuidadosamente esta liberação para a frota, utilizando princípios de SRE, como Canarying Incremental e monitorar a saúde da frota.

Mas nem todas as construções têm sucesso na primeira tentativa. Se um pacote não conseguir construir, geralmente verificamos bugs conhecidos com o rastreador de insetos do Debian e potencialmente o relatam, caso ainda não seja conhecido. Às vezes, nossos engenheiros de liberação precisam se tornar criativos e aplicar soluções/patches locais para obter um pacote para construir dentro do nosso ecossistema e, mais tarde, soltar essas soluções alternativas quando a Upstream lançar uma correção.

Uma questão que encontramos algumas vezes, por exemplo, é que, no Debian Upstream, os pacotes geralmente são construídos em Debian Instable. Depois de alguns dias, esses pacotes já construídos migram para os testes do Debian. Em alguns casos, é possível, no entanto, que uma dependência de construção esteja presa em instável e, assim, construir dentro dos testes, ainda não é possível. Geralmente tentamos trabalhar a montante primeiro nesses casos, por isso reduzimos a complexidade e a carga de manutenção para manter esses patches locais, além de devolver à comunidade.

Se alguma das etapas falharem, a peneira tem uma caixa de ferramentas de truques para tentar novamente as compilações. Por exemplo, quando inicia a construção inicial de um grupo de pacotes, o sistema faz um palpite educado sobre quais dependências precisam ser construídas juntas. Mas às vezes as informações da versão fornecidas nos pacotes de origem do Debian podem ser incompletas e esse palpite está errado. Por esse motivo, peneiram periodicamente grupos de construção que falharam. Como o instantâneo mais recente de nossos pacotes é um alvo em movimento, pode acontecer que, depois que um grupo de pacotes aparentemente independente é adicionado ao instantâneo, um grupo anteriormente quebrado constrói e passa os testes corretamente. Todos esses fluxos de trabalho são principalmente automáticos e isso destaca a importância de pensar como um SRE neste campo. Ao enfrentar um fracasso, geralmente parece mais fácil corrigir uma construção falhada uma vez, mas se precisarmos aplicar a mesma solução alternativa repetidamente, colocar a solução alternativa no código reduzirá a carga geral em nossos engenheiros.

Existem também alguns benefícios de segurança em construir todos os nossos binários a partir da fonte e ter uma proveniência adicional do código -fonte que verifica a origem do binário em execução. Durante um incidente de segurança, por exemplo, somos capazes de reconstruir rapidamente e confiar na construção trabalhando com um patch temporário, pois estamos construindo todos os pacotes antes, que aterrissa em nossa distribuição. Além disso, também reduzimos o envelope de confiança que precisamos colocar em Debian a montante e os artefatos de construção binária produzidos por sua infraestrutura. Em vez disso, uma vez que o código -fonte é ingerido e o binário construído verificamente, podemos atestar criptograficamente que o binário em execução se originou exatamente desse código -fonte.

Atualizando para Rodete

O último lançamento do Goobuntu foi baseado no Ubuntu 14.04 LTS (Codename Trusty). O desenvolvimento de Rodete começou em 2015 e ficou rapidamente claro que não podíamos’T Apenas solte suporte para confiabilidade e exige que toda a população de engenharia instale uma nova distribuição. Desde a experiência anterior de atualizar no local entre as versões LTS, já tivemos uma boa experiência de saber o que nos esperava com essa migração. Como o Ubuntu é um derivado do Debian e usa muitas das mesmas infraestruturas/formatos de embalagem (APT), não foi’Uma ideia totalmente louca de atualizar a frota do goobuntu 14.04 para o Debian no local. Reutilizamos algumas partes da nossa ferramenta de atualização anterior no local e trabalhamos para torná-la mais confiável, adicionando mais automação e muito mais testes.

Para facilitar a criação dessa ferramenta, testá -la e mantê -la durante a migração, optamos por congelar temporariamente Glinux Rodete como um instantâneo de testes debian em uma data específica que chamamos de linha de base. Podemos avançar nessa linha de base por conta de nossa própria escolha, para equilibrar o que os pacotes peneiram ingestões. Para reduzir o atrito, estabelecemos intencionalmente a linha de base de Rodete no atual lançamento estável do Debian em 2016, que estava muito mais próximo do estado geral do Ubuntu Trusty. Dessa forma, poderíamos separar a atualização no local de confiança para o Debian e as principais alterações da versão do pacote que aconteceram no Debian em uma data posterior.

Em 2017, começamos a migrar as máquinas para Rodete e concluímos o último migração no local até o final de 2018. No entanto, ainda tínhamos uma linha de base de pacotes que naquele momento datavam quase dois anos no passado. Para acompanhar os testes do Debian, iniciamos um esforço de equipe para focar em otimizar o comportamento da peneira e acelerar o tempo necessário para criar / testar pacotes. Reparar as atualizações dessa maneira incremental e ter um alvo de lançamento em movimento que controlamos aliviou a carga de trabalho para os engenheiros do Google e nossa equipe.

No início de 2019, começamos a fechar os últimos restos de Goobuntu Machines. Nossa linha de base também avançou apenas para trás por ~ 250 dias, o que na época significava que estávamos usando a maioria das versões do pacote que faziam parte do Buster. Em meados de 2020, finalmente alcançamos completamente o mesmo tempo quando o Bullseye Debian foi lançado. Continuamos a avançar em nossa linha de base e provavelmente já estaremos usando uma versão semelhante do próximo lançamento estável do Debian, antes de seu lançamento em meados de 2023.

Chegando ao zen

Hoje, a vida de um membro da equipe do Glinux parece muito diferente. Reduzimos a quantidade de tempo e energia de engenharia necessários para lançamentos para um engenheiro de liberação de serviço que gira entre os membros da equipe. Não temos mais um grande empurrão para atualizar toda a nossa frota. Não há mais necessidade de alfa, betas e gás multi -estágios para novos lançamentos de LTS, enquanto perseguia máquinas mais antigas que ainda estavam executando o Ubuntu Precise ou Lucid.

Também melhoramos dramaticamente nossa posição de segurança, operando nossa frota mais próxima de lançamentos upstream. Enquanto Debian fornece uma boa fonte de patches de segurança para as faixas estáveis ​​e antigas, percebemos que nem todos os buracos de segurança que recebem patches, necessariamente tem um consultor de segurança do Debian (DSA) ou número CVE. Nosso cronograma de lançamento rolante garante que corrigimos os orifícios de segurança em toda a frota rapidamente, sem comprometer a estabilidade, enquanto os engenheiros de segurança anteriormente tinham que revisar cuidadosamente cada DSA e garantir que a correção chegasse à nossa frota.

Nosso conjunto de testes aprimorado e testes de integração com equipes parceiras -chave que executam sistemas críticos de desenvolvedores também produziram uma experiência mais estável usando uma distribuição Linux que fornece as versões mais recentes do kernel Linux. Nosso forte desejo de automatizar tudo no pipeline reduziu significativamente o trabalho e o estresse dentro da equipe. Agora também é possível relatar insetos e incompatibilidades com outras versões da biblioteca, garantindo que as ferramentas do Google funcionem melhor no ecossistema Linux.

Se você estiver interessado em fazer um sucesso em sua empresa, considere equilibrar as necessidades da empresa contra a agilidade de atualização. Estar no controle de nosso próprio alvo em movimento e linha de base ajudou a desacelerar sempre que encontramos muitos problemas e quebraram qualquer um de nossos times SLOS. Nossa jornada acabou reforçando nossa crença de que as mudanças incrementais são melhor gerenciáveis ​​do que as liberações do Big Bang.

Se você é capaz de controlar o influxo de novos trabalhos e manter isso previsível, tornamos a experiência de que nossos engenheiros permanecem mais felizes e estão menos estressados. Isso acabou diminuindo a agitação da equipe e garantiu que possamos construir conhecimentos em vez de lidar com vários incêndios em chamas ao mesmo tempo.

No futuro, estamos planejando trabalhar ainda mais de perto com o Debian Upstream e contribuir com mais de nossos patches internos para manter o ecossistema de pacotes do Debian.

• Desenvolvedores e praticantes
• Sistemas
• DevOps & Sre

Por que executar o Linux no Google Cloud?

As empresas na nuvem têm muito a sua vontade: aumento da agilidade, adaptabilidade, flexibilidade e confiabilidade – que facilita muito a curva da curva. A combinação de infraestrutura local com serviços em nuvem pode dar uma nova vida aos processos existentes e aumentar o número de ferramentas e tecnologias à sua disposição.

Parece ótimo, certo? É – mas primeiro, você precisa considerar sua escolha de provedor de nuvem e sistema operacional. Quais forneceriam a melhor base para construir seu ambiente híbrido em nuvem, enquanto ainda permite a flexibilidade de adotar os serviços e tecnologias que você deseja?

Linux e Google Cloud Platform são uma forte combinação para mover sua empresa para a nuvem e para o futuro. Deixar’s Dê uma olhada em cada um antes de aprender o que os faz se destacar como uma equipe.

Como o Linux e o Google Cloud Platform funcionam juntos

Plataforma do Google Cloud

Plataforma do Google Cloud, como a Amazon’S AWS e Microsoft Azure, são uma plataforma de nuvem pública e faz parte do Google Cloud, que é construída no Google’s infraestrutura global. O Google Cloud fornece serviços em nuvem e ferramentas de gerenciamento – VIA o Google Cloud Console – que entrega tudo o que é necessário para criar ambientes de nuvem e multicloud eficazes, implantar aplicativos e APIs e suportar cargas de trabalho em ambientes.

A plataforma do Google Cloud possui as ferramentas e recursos focados em segurança para permitir que sua empresa aproveite todos os benefícios da computação em nuvem com uma estratégia clara (Google Cloud Multicloud Solutions), toma decisões com base em empresas precisas e atualizadas da empresa e das informações de inventário (análise de dados), além de transformar como as equipes se comunicam e se comunicam (Google Google Workspace).

O Google Cloud inclui o Google Cloud Platform, além de um conjunto de produtos e ferramentas como o Google Cloud Storage (armazenamento de objetos), Google Cloud DataStore (banco de dados NoSQL), funções do Google Cloud (plataforma de computação orientada a eventos como serviço), Google Compute Engine ou GCE (máquinas virtuais em execução no Google’s Data Center) e Google App Engine (plataforma de aplicativo sem servidor) – bem como muito mais.

Linux foR Computação em nuvem

Linux é um sistema operacional de código aberto. Devido ao seu modelo de desenvolvimento de código aberto, o Linux é ideal para a computação em nuvem, pois permite que as empresas escolham as plataformas e tecnologias que melhor atendem às suas necessidades e propósitos, além de permitir a escolha de serviços e fornecedores necessários, evitando assim despesas desnecessárias e bloqueio de fornecedores. Com o Linux for Cloud Computing, você obtém todos os benefícios do Linux para implantações tradicionais de TI com flexibilidade de crescer usando tecnologias mais recentes como Kubernetes, AI/ML e Computação de Edge. Por esses motivos, o Linux continua sendo a principal escolha do sistema operacional na computação em nuvem.

Melhor juntos: benefícios da execução do Linux na plataforma do Google Cloud

O Google Cloud Platform é construído no Linux e trabalha com várias distribuições Linux, como CentOS, Ubuntu e Red Hat Enterprise Linux. A natureza de código aberto de um sistema Linux com a plataforma do Google Cloud significa que os usuários obtêm os seguintes benefícios:

• Flexibilidade de fornecedores e serviços
• Migração mais fácil de aplicações e informações
• Consistência de informações e processos nas pegadas
• A inovação de uma estrutura de código aberto e comunidade

Basicamente, um forte provedor de nuvem em uma fundação Linux estabelecida significa que sua estratégia de nuvem corporativa está indo na direção certa.

Benefícios do Red Hat Enterprise Linux na plataforma do Google Cloud

Adotar uma abordagem híbrida ou multicloud pode ser desafiadora – especialmente quando você’eu é usado em hardware legado e infraestrutura tradicional. Mas o provedor de serviços em nuvem certo e a distribuição Linux fornecem um início sólido. Com o Red Hat® Enterprise Linux® na plataforma do Google Cloud, você tem a base para uma estratégia em nuvem que o levará aonde você quiser. E porque o Red Hat Enterprise Linux é executado no Google, assim como todo o resto do Red Hat’s produtos.

Red Hat Enterprise Linux e Google Cloud Platform Ajuda simplificar sua plataforma de infraestrutura, acelerar o desenvolvimento e entrega de aplicativos e incorporar automação para seus processos de negócios e gerenciamento, para que você possa inovar mais rapidamente e se adaptar às mudanças da indústria, regulatória e global com um ambiente de nuvem híbrida ágil.

E aqui’s Outra coisa-o Red Hat Enterprise Linux for SAP Solutions no Google Cloud é uma plataforma de alto desempenho para operações de banco de dados que inclui conteúdo e recursos específicos do SAP e permite que as organizações implantem SAP em ambientes de nuvem híbridos. Red Hat Enterprise Linux é uma das duas distribuições Linux certificadas para uso com SAP HANA® e SAP S/4HANA®.

Com configuração flexível, código aberto e base focada em segurança, infraestrutura de rede global e gerenciamento e análise de dados avançados, Red Hat e Google Cloud oferecem as funções e recursos necessários para criar e operar ambientes híbridos e multicloud de maneira eficaz e eficiente. Cada componente oferece funcionalidade e valor-chave e um ambiente operacional confiável e de alto desempenho para suas cargas de trabalho e aplicativos em infraestrutura física, virtualizada, contêinerizada, baseada em nuvem e de borda.

A história por trás do Google’S Linux da área de trabalho interno

Se você olhar em torno dos escritórios da Mountain View, da CA do Google, verá máquinas Windows, Chromebooks, Macs – e Glinux Desktops. G o que você pergunta? Bem, além de confiar no Linux para seus servidores, o Google tem sua própria distribuição de desktop Linux.

Você não consegue entender – maldito! – Mas há mais de uma década, o Google está assando e comendo sua própria distribuição caseira de desktop linux. A primeira versão foi Goobuntu. (Como você imagina do nome, foi baseado no Ubuntu.)

Em 2018, o Google mudou seu desktop de Linux interno do Goobuntu para uma nova distro Linux, o Glinux, com sede no Debian. Por que? Porque, como explicou o Google, o lançamento de dois anos do Ubuntu’s Long Term Support (LTS) “significava que tínhamos que atualizar todas as máquinas em nossa frota de mais de 100.000 dispositivos antes da data de final de vida do OS.”

Isso foi uma dor. Adicione a necessidade demorada de personalizar totalmente os PCs dos engenheiros, e o Google decidiu que custou muito. Além disso, o “esforço para atualizar nossa frota goobuntu geralmente levou a maior parte de um ano. Com uma janela de apoio de dois anos, restou apenas um ano até que tivéssemos que passar pelo mesmo processo de novo para o próximo LTS. Todo esse processo foi um enorme fator de estresse para nossa equipe, pois obtivemos centenas de insetos com pedidos de ajuda para casos de canto.”

Então, quando o Google teve o suficiente disso, ele se mudou para o Debian Linux (embora não apenas Vanilla Debian). A empresa criou uma distribuição rolante do Debian: Glinux Rolling Debian Testing (Rodete). A idéia é que usuários e desenvolvedores sejam mais bem servidos, dando a eles as últimas atualizações e patches, conforme são criados e considerados prontos para a produção. Tais 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 a integração contínua/implantação contínua (IC/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ágrimas, o Google criou um novo sistema de fluxo de trabalho, peneira. Sempre que peneira vê uma nova versão de um pacote Debian, ele inicia uma nova compilação. Esses pacotes são construídos em grupos de pacotes, uma vez que pacotes separados geralmente devem ser atualizados juntos. Depois que todo o grupo foi construído, o Google executa um conjunto de testes virtualizado para garantir que nenhum componente principal e fluxos de trabalho do desenvolvedor sejam quebrados. Em seguida, cada grupo é testado separadamente com uma instalação completa do sistema, inicialização e pacote de testes local, execução. O pacote aumenta em minutos, mas os testes podem levar até uma hora.

Uma vez feito isso, todos os novos pacotes são fundidos com o mais novo pool de pacotes Glinux. Então, quando o Google decide que é hora de lançá -lo em produção, os instantâneos da equipe que piscina. Finalmente, ele lançou o novo lançamento para a frota. Claro, isso’não vai apenas despejar 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 uma única posição de engenheiro de lançamento em serviço que gira entre os membros da equipe. Não há grandes empurrões para atualizar a frota. Não há versões alfa, betas e disponibilidade geral de vários estágios (GA).

Melhor ainda, graças ao cronograma de lançamento, o Google pode consertar os orifícios de segurança em toda a frota rapidamente, sem comprometer a estabilidade. Anteriormente, os engenheiros de segurança tinham que revisar cuidadosamente cada Advisory de Segurança Debian (DSA) para garantir que a correção estivesse em.

Além disso, o “suíte de teste aprimorado do Google e os testes de integração com equipes parceiras que executam sistemas críticos de desenvolvedores também produziram uma experiência mais estável usando uma distribuição Linux que fornece as mais recentes versões do kernel Linux. Nosso forte desejo de automatizar tudo no pipeline reduziu significativamente o trabalho e o estresse dentro da equipe. Agora também é possível relatar insetos e incompatibilidades com outras versões da biblioteca, garantindo que as ferramentas do Google funcionem melhor no ecossistema Linux.”

Olhando para o futuro, a equipe do Google declarou que isso’Funciona “mais de perto com o Debian Upstream e contribua com mais de nossos patches internos para manter o ecossistema de pacotes do Debian.”

Tudo isso parece ótimo. Mas eu tenho dois pensamentos para compartilhar.

Primeiro, para algumas organizações, os lançamentos do 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 importante: peneira soa como o miau do gato. Um programa que pode automatizar um pipeline de produção de distração rolante até o ponto em que leva apenas um engenheiro para manter uma área de trabalho usada 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 lançamentos de desktop linux rolling. Que tal isso, Google? O que você diz?

• Desktop Linux
• Google

Copyright © 2022 IDG Communications, Inc.