PlatformCon: como o Spotify gerencia infraestrutura com GitOps

Para o Spotify, acelerar o desenvolvimento e a implantação de recursos se resume a modelos e pipelines.

O ciclo de lançamento é quase totalmente automatizado. “As únicas pessoas que restam no processo são os desenvolvedores”, disse Tim Hansen, engenheiro sênior, trabalhando no Backstage, no serviço de compartilhamento de música Spotify, falando na conferência virtual PlatformCon 2024 desta semana. “Isso nos permite liberar continuamente milhares de microsserviços, muitas vezes ao dia.”

A receita vem do GitOps, uma implementação de infraestrutura como código (IaC). Com o GitOps, as informações de configuração do sistema, geralmente armazenadas em YAML ou como arquivos de texto simples, são mantidas em um repositório de código-fonte, geralmente git ou serviço de hospedagem de código git-base, onde podem ser chamadas por uma ferramenta de provisionamento para implantação.

Um agente então compara continuamente o “estado desejado”, conforme descrito nos arquivos de configuração, com o estado real de execução e aplica quaisquer alterações necessárias para sincronizar os dois.

“Ao ter tudo declarativo no código e pilhas de tecnologia padrão, (o desenvolvedor) basicamente obtém infraestrutura de graça”, disse ele. “E se você precisar fazer modificações, é fácil.”

Construído em GitOps

Um sistema GitOps requer três aspectos para funcionar, explicou Hansen:

• Um estado desejado do sistema deve ser definido declarativamente.
• Cada novo estado deve ter um número de versão diferente e ser imutável (com quaisquer alterações exigindo um novo número de versão)
• As alterações no ambiente de produção são aplicadas automaticamente

Em um ambiente típico de desenvolvedor, os desenvolvedores fazem alterações no código e verificam-nas no controle de origem, e o código é compilado e criado com ferramentas de Integração Contínua (CI). Mas se o recurso precisar de novos recursos ou exigir alterações no esquema do banco de dados, ele será tratado por um administrador. O teste manual e o descomissionamento da versão anterior também podem fazer parte do processo.

“Portanto, este processo é um pouco lento e há algumas pessoas envolvidas aqui”, disse Hansen. Este processo também é difícil de escalar.

O processo do Spotify é um pouco mais simplificado. O processo de desenvolvimento é bastante rotineiro, seguindo os passos acima, mas os recursos da nuvem são sincronizados automaticamente, com base em declarações de código. As alterações no banco de dados são baseadas em migrações de código. Se houver novos requisitos para pods do Kubernetes, eles também serão baseados em declarações de código.

Automatizar as etapas da infraestrutura automatiza e acelera o ciclo de lançamento. E o git fornece o processo de revisão, controle de versão, histórico e um mecanismo de reversão.

Percorrendo o processo de construção

O Spotify criou seu próprio sistema de compilação, chamado Tingle. Foi construído internamente, por meio de trabalhos semelhantes ao GitHub Actions. Todo o estado da construção do site é armazenado de forma declarativa, explicou Hansen. Tingle usa webhooks GitHub para iniciar novas compilações, assim que uma alteração é feita no código no repositório.

Tingle tem dois conjuntos de pipelines, um para uma construção de revisão e outro para uma construção mestre. Existe um processo de pipeline baseado em YAML para cada processo, onde as ferramentas de construção – como o Maven, são especificadas.

As definições de pipeline podem ser bastante grandes e copiadas em vários locais, graças à arquitetura de microsserviços da empresa. Portanto, o agente Tingle usa um arquivo de modelo menor que remete ao original, que é consultado pelo processo de construção. Alguns aplicativos precisam de uma configuração completa, embora a maioria possa ser suportada apenas com o próprio modelo.

“Este é um superpoder para GitOps: abstração e simplificação”, disse Hansen. “Ao usar GitOps e pilhas de texto padrão, podemos fazer compilações absolutamente estúpidas para os desenvolvedores.”

Embora o Tingle tenha sido desenvolvido internamente, existem muitas outras ferramentas disponíveis para executar seus próprios pipelines de construção internos, incluindo GitLab CI, Google Cloud Build, Tekton Pipelines, Argo Workflows e Dagger.

Qual é o processo de implantação do GitHub?

Logotipo do rebocador

Para implantação, Tingle inicia um sistema de implantação central chamado Tugboat. Um arquivo YAML personalizado mais uma vez estabelece um conjunto de padrões, facilitando a definição de recursos poderosos. Para um serviço de back-end que depende do Kubernetes, o Tugboats procura uma pasta Kubernetes de nível raiz no repositório de código-fonte, que contém instruções padrão do Kubernetes para serviços, implantações e definições personalizadas.

“Portanto, aqui não estamos apenas armazenando instruções sobre como para implantar com git, mas também declarações de o que para implantar”, disse Hansen.

Algumas ferramentas de provisionamento de infraestrutura automatizada compatíveis com GitOps incluem Terraform (e seu equivalente de código aberto OpenTofu), Google Config Connector, Crossplane e Pulumi.

Para monitoramento, o Spotify usa Grafana. Mais uma vez, ele é implantado centralmente por uma linguagem declarativa e é acionado pelo Tingle. Um conjunto de modelos define gráficos que podem ser usados ​​para exibir visualmente o uso nos painéis do Grafana. Os alertas também são pré-configurados para novos aplicativos online. A equipe de produção pode atualizar uma configuração do Grafana uma vez para todos os diferentes aplicativos, simplesmente atualizando o próprio modelo.

Cada serviço obtém seu próprio conjunto de metadados, descrevendo a implantação e outros serviços necessários, como monitoramento. Esses dados são mantidos pelo Backstage, um portal de código aberto para desenvolvedores originalmente desenvolvido pelo Spotify.

Uma entrada do catálogo de software Spotify para Backstage.

“O catálogo de software contém informações sobre o serviço, juntamente com informações sobre os relacionamentos que o serviço tem com outros softwares e recursos”, disse Hansen. “Isso significa que nosso catálogo não é apenas uma lista de serviços, mas um gráfico. ”

O Backstage fornece um único plano de vidro para todos os desenvolvedores do Spotify. Assim como acontece com o processo de construção e implantação, o Spotify fornece um conjunto de modelos, também definidos no git, para criar facilmente um novo aplicativo. Eles são pré-preenchidos com os modelos para o processo de construção e implantação. Além dos templates de construção e implantação, o projeto recebe uma entrada no catálogo de software e também são integrados serviços de monitoramento e alertas.

“Usando um modelo personalizado no Backstage e preenchendo alguns campos, um desenvolvedor do Spotify pode criar um serviço para o Spotify com apenas alguns cliques”, disse Hansen. “Eles nunca precisam tocar no YAML.”

Desde então, o Spotify doou o Backstage para a Cloud Native Computing Foundation e agora é usado por milhares de desenvolvedores em todo o mundo.

Aproveite o vídeo da palestra completa aqui:

A postagem PlatformCon: como o Spotify gerencia a infraestrutura com GitOps apareceu pela primeira vez no The New Stack.