Como o GitLab mantém um monólito gigante em Rails à vista de todos
O GitLab é uma plataforma de núcleo aberto que junta controle de código, CI/CD e segurança num app só, e o GitLab.com é a maior instalação dele. A base é um monólito em Ruby on Rails escolhido de propósito por ser previsível, com PostgreSQL, Redis e Sidekiq, mais serviços em Go nos trechos que precisam de velocidade, rodando no Google Cloud e em Kubernetes.
Copiar stackgitlab.com Plataforma DevSecOps para código, CI/CD e segurança · Estados Unidos · fundada em 2011
O cofundador Dmitriy Zaporozhets escolheu Rails mesmo programando mais em PHP na época, em parte porque o GitHub era feito nele. O CEO Sid Sijbrandij defendeu a escolha depois: o ecossistema de gems dá ao time muita coisa pronta para aproveitar, e as convenções do Rails dizem a todos onde cada código deve ficar.
Esse último ponto pesa na missão do GitLab de que qualquer pessoa pode contribuir. Quem chega consegue se achar num código enorme porque ele segue o caminho padrão do Rails, e o time prefere soluções simples a truques espertos.
O Sijbrandij foi direto: o Ruby foi feito para facilitar a vida de quem programa, não para rodar em produção. Por isso os trechos mais acessados, ou os que passam o tempo esperando disco e rede, foram reescritos em Go.
O maior resultado é o Gitaly, um serviço em Go que cuida de todas as chamadas Git do GitLab. Ele nasceu para acabar com a dependência de NFS no armazenamento do Git, e o objetivo declarado é escalar esse armazenamento horizontalmente com tolerância a falhas, principalmente no GitLab.com. Hoje todo o código do app chega aos repositórios por ele.
O GitLab.com rodava no Azure e não estava pronto para trabalho crítico. Em 2018 o time levou tudo para o Google Cloud, citando o desempenho e a estabilidade de que precisava, além de Kubernetes e preço. Eles usaram a própria replicação Geo do GitLab para copiar os dados e passaram cerca de 200 TB de artefatos de CI, anexos e arquivos LFS para o Google Cloud Storage.
Os números melhoraram rápido. A disponibilidade foi de 99,61% antes da mudança para 99,93% em abril de 2019, e os erros diários caíram de uma média de 8,2 para cerca de um.
As máquinas virtuais demoravam para escalar e para receber deploys, então em agosto de 2019 o GitLab.com começou a migrar para o Google Kubernetes Engine, a começar pelo Container Registry. Depois vieram web, API, tráfego Git e as tarefas do Sidekiq, tudo rodando com o mesmo Helm chart oficial que os clientes usam.
O que guarda estado ficou nas máquinas virtuais: PostgreSQL, Redis, GitLab Pages e Gitaly. Um ano depois, o time contou que os deploys ficaram bem mais rápidos e seguros, mas o tráfego de rede entre zonas virou um custo novo para vigiar.
O front-end é misto: o Rails monta páginas em HAML, e apps em Vue.js são encaixados nelas onde a tela precisa de interação. O guia de front-end pede para manter poucos apps Vue por página.
Para buscar dados, o padrão é GraphQL com Apollo, e o REST fica para páginas HAML simples e código antigo. O Vuex foi descontinuado em favor do Pinia ou de componentes que guardam o próprio estado.
