Operadores do Kubernetes: automatizando o processo de lançamento

A Snyk ajuda nossos clientes a integrar segurança aos pipelines de CI/CD, por isso dedicamos bastante tempo à automação. Quando se trata de lançar nosso próprio software, estamos sempre buscando adotar as melhores práticas de teste e lançamento.

Neste artigo, vou falar sobre o processo de lançamento do nosso Kubernetes Operator e mostrar como automatizamos a distribuição da versão para vários repositórios.

O que é um Kubernetes Operator?

Um Operator é um “... método de empacotar, implantar e gerenciar uma aplicação Kubernetes...”. Basicamente, os Operators encapsulam em código as ações do ciclo de vida de uma aplicação, permitindo controlá-las usando a API nativa do Kubernetes.

Por que os Kubernetes Operators são importantes?

O padrão Operator oferece uma maneira de controlar aplicações depois que elas estão em execução, usando as APIs do Kubernetes. Se nossas aplicações precisam fazer mais do que simplesmente iniciar ou parar, isso nos permite controlá-las durante a operação, de forma declarativa, assim como gerenciamos todos os outros recursos do Kubernetes.

O que é automação do lançamento de aplicações?

Com o crescimento dos catálogos online para os quais implantamos software para que nossos usuários possam consumi-lo, o processo de distribuição de uma versão lançada pode se tornar bastante complexo. Talvez seja necessário concluir várias etapas para distribuir nossos artefatos em diferentes repositórios e fornecer diferentes tipos de metadados para que a aplicação possa ser consumida de diversas maneiras. Automatizar esses processos é essencial para garantir que cada versão seja distribuída sem erros e permitir que nossos usuários tenham acesso às novas versões assim que estiverem disponíveis.

Vamos entender melhor

Há alguns meses, a equipe por trás do Container Scanning lançou o Snyk Operator, um Operator para o Snyk Controller que facilita a implantação em clusters Kubernetes nativos e OpenShift.

O Snyk Controller é uma aplicação da Snyk implantada no cluster do usuário, onde verifica as imagens dos contêineres em execução. Saiba mais sobre essa ferramenta incrível aqui e descubra aqui como ela pode ajudar você a encontrar vulnerabilidades nas imagens e aplicações.

Há várias maneiras de criar Operators para Kubernetes. Uma das mais comuns é o Operator Framework, que surgiu na CoreOS e hoje é um projeto da CNCF. Além de oferecer um SDK para o desenvolvimento de Operators, o Operator Framework também disponibiliza um repositório de Operators criados pela comunidade.

O Snyk Operator é desenvolvido com esse framework, e distribuímos cada versão para os repositórios upstream. Ao lançar uma nova versão do Operator, precisamos concluir várias etapas, que poderiam estar sujeitas a erros se fossem realizadas manualmente.

Primeiro, vamos entender o processo de lançamento do Snyk Controller e como incluímos nele a compilação do Operator.

Quando um Pull Request de qualquer colaborador é integrado ao nosso repositório do Snyk Controller, nosso pipeline de integração e entrega contínuas é iniciado. Ele compila o Operator e sua imagem e executa testes unitários, de sistema e de integração para testar o Operator em diferentes ambientes.

Precisamos testar em uma grande variedade de ambientes, incluindo diferentes versões do OpenShift e do Kubernetes upstream. Em todos eles, testamos com o Operator Lifecycle Manager, que faz parte do Operator Framework e estende o Kubernetes para oferecer uma maneira declarativa de instalar, gerenciar e atualizar Operators e suas dependências em um cluster.

Depois que uma versão do Snyk Operator é testada, precisamos distribuir a versão final. Atualmente, lançamos o Snyk Operator no Operator Hub, que permite aos usuários instalá-lo em qualquer cluster Kubernetes com o Operator Lifecycle Manager, além de disponibilizá-lo no catálogo do OpenShift.

Esse processo de lançamento envolve dois Pull Requests distintos, o que geraria bastante trabalho extra se fosse feito manualmente: um para incluir o Snyk Operator na pasta community-operators e outro para incluí-lo na pasta upstream-community-operators. O primeiro publica o Snyk Operator no OperatorHub.io, e o segundo o disponibiliza no catálogo do OpenShift.

Para eliminar o trabalho extra dessas etapas, queremos automatizar por completo o processo de lançamento para os dois repositórios. Por isso, criamos scripts para todo esse processo no nosso pipeline do CircleCI.

Primeiro, copiamos todos os arquivos necessários para a pasta snyk-operator, substituindo a versão da aplicação pela mais recente. Baixamos a ferramenta operator-sdk e a usamos para compilar a imagem do Snyk Operator. Depois, enviamos a imagem para nosso registro público no Docker Hubs.

Fonte: GitHub

Essa imagem nos permite executar os testes de integração no pipeline e garantir que estamos lançando algo que funciona em clusters OpenShift das versões 3.x e 4.x e em clusters Kubernetes com OLM. Aqui, usamos um truque para executar os testes de integração: enviamos a imagem do Operator para o registro Quay, criamos um operator-source.yaml e o instalamos no cluster aplicando este install.yaml.

Nossa intenção é reproduzir o mesmo processo que ocorre quando os usuários instalam o Operator pela interface. Tratamos esse processo como uma caixa-preta e seguimos algumas etapas que o OpenShift executaria quando o usuário clicasse em “instalar” na interface.

Fonte: GitHub

Fonte: GitHub

Fonte: GitHub

Por fim, com todos os testes aprovados, podemos iniciar o lançamento do Snyk Operator, que exige a criação de alguns metadados adicionais. Isso inclui o ClusterServiceVersion e as CustomerResource Definitions, usados para preencher a página do Snyk Controller no Operator Hub e permitir a integração com o Operator Lifecycle Manager. O OLM permite que o usuário assine um Operator, reunindo instalação e atualizações em uma única etapa.

Como esses metadados não mudam com frequência, usamos modelos e alteramos apenas a versão para corresponder à versão mais recente do Snyk Operator.

Fonte: GitHub

Depois de concluir todas essas etapas, podemos finalmente criar nossos commits: um para incluir os novos metadados do Operator na pasta community-operators e outro para a pasta upstream-community-operators. Para cada commit, vamos abrir um Pull Request no repositório de Operators da comunidade, incluindo a mensagem solicitada.

Fonte: GitHub

Você pode ver exemplos desses PRs aqui e aqui.

Depois que os PRs são criados, testes automatizados são executados no OperatorHub e no OpenShift. Por fim, os mantenedores desses repositórios integram nossa nova versão.

Para concluir

Ao automatizar por completo o processo de lançamento do nosso Operator, economizamos tempo e recursos significativos da equipe de engenharia e continuamos disponibilizando novas versões do software da maneira mais rápida e eficiente possível.

O Snyk Controller integra a verificação da Snyk aos seus clusters Kubernetes, permitindo importar e testar as cargas de trabalho em execução e identificar vulnerabilidades nas imagens e configurações associadas que podem reduzir a segurança dessas cargas. Saiba mais aqui e comece a usar a Snyk criando uma conta gratuita.