Como uma empresa de observabilidade, a New Relic cria e mantém agentes específicos de múltiplas linguagens e tecnologias para coletar dados de telemetria dos ambientes de nossos clientes. Quando essas equipes de agentes lançam novas atualizações manualmente, elas realizam diversas verificações para garantir que o processo não introduza regressões causadas por erro humano. Para reduzir o tempo necessário para implantar uma nova versão, a equipe de agentes do Kubernetes automatizou totalmente o processo de lançamento do agente de software. O fluxo de trabalho reutilizável do GitHub Actions monitora dependências vulneráveis, escreve documentação e sincroniza com parceiros como o Amazon Elastic Kubernetes Service (Amazon EKS) em qualquer lugar. Anteriormente, as atualizações de envio para nossa integração com o Kubernetes eram manuais e demoravam até duas semanas; agora, um processo automatizado leva uma hora por semana.

Diminuindo o tempo de resposta para incidentes de segurança

Um dos nossos desafios foi a nossa resposta às vulnerabilidades de segurança: reagiríamos a vulnerabilidades apenas quando um cliente contactasse o Suporte Técnico Global (Global Technical Support, GTS) com uma escalada. Isso levaria à frustração dos clientes com nossa integração e ao estresse dos desenvolvedores, porque precisaríamos interromper o trabalho planejado em favor de corrigir nosso software.

Como parte do nosso pipeline de integração contínua (continuous integration, CI), habilitamos ferramentas de verificação de código para nos manter informados sobre as vulnerabilidades mais recentes descobertas em nossa base de código. Habilitamos o CodeQL para procurar vulnerabilidades em nossa base de código e usamos Trivy para garantir que nossas imagens docker não incluam vulnerabilidades injetadas a partir da imagem base e da biblioteca incluída nela. 

Um de nossos casos de uso comuns é detectar vulnerabilidades em nossa imagem base (Alpine). Este processo nos alerta sobre problemas atuais que precisam ser corrigidos. Ao combinar a varredura de vulnerabilidades com o gerenciamento automático de dependência, podemos corrigir automaticamente correções na base de código sem a necessidade de interação humana. Nosso fluxo de trabalho é executado semanalmente, o que significa que os clientes recebem uma versão corrigida uma semana após a disponibilização de uma correção.

Como exemplo concreto do aumento do nosso tempo de resposta, nosso dashboard de segurança nos alerta sobre as seguintes vulnerabilidades de segurança no alpine:3.18.4 (a imagem que estamos usando na integração nri-Kubernetes no momento):

Essas vulnerabilidades foram corrigidas em alpine:3.18.5, lançado em 30 de novembro de 2023, e alpine:3.19.0, lançado em 7 de dezembro de 2023. Renovate, nossa ferramenta universal de gerenciamento de dependência, criou pull request para ambos os lançamentos no mesmo dia em que os lançamentos foram publicados e foram incluídos em nosso lançamento em 8 de dezembro de 2023, apenas um dia após o lançamento de alpine:3:19.0.

Todas as três imagens alpinas mencionadas têm mais duas vulnerabilidades que foram detectadas posteriormente:

Essas duas vulnerabilidades pendentes estão atualmente sinalizadas em nosso dashboard segurança.

Assim que uma correção for lançada pela Alpine, nossos clientes poderão esperar uma versão corrigida de nossa integração dentro de uma semana.

Forneça suporte de ponta para a versão mais recente do Kubernetes

O suporte a novas versões do Kubernetes envolve a atualização de ferramentas de teste de terceiros e a realização de testes de conformidade extensivos para garantir que uma nova versão do Kubernetes não tenha alterações significativas em nossas integrações. Um problema comum que precisamos validar é uma API Kubernetes que está em versão alfa ou beta, pois pode haver alterações sem aviso prévio.

Com nossas ferramentas de gerenciamento de dependência totalmente automatizadas, uma vez instaladas as ferramentas, temos acesso imediato a elas. Além disso, como nossos testes de conformidade são totalmente automatizados, podemos acelerar o tempo de validação, o que nos permite estar na vanguarda do suporte ao Kubernetes.

Quando uma nova versão do Kubernetes estiver disponível, é crucial atualizar nosso fluxo de trabalho de testes para incorporar a versão mais recente. Renovate, nossa ferramenta de gerenciamento de dependência, abriu automaticamente uma pull request (PR) para atualizar o Minikube para a versão mais recente. Usamos o minikube para ativar rapidamente um cluster e, em seguida, executar testes ponta a ponta e, em seguida, executar toda a bateria de testes em cada versão do Kubernetes que oferecemos suporte. Depois que o minikube for atualizado com a versão mais recente do Kubernetes, habilitamos o teste para essa versão em nossa framework de teste. Se os testes confirmarem que a integração está funcionando conforme o esperado, podemos declarar suporte para a versão mais recente do Kubernetes. Devido ao nosso fluxo de trabalho automatizado, atualizamos nosso conjunto de testes para aproveitar a versão mais recente do Kubernetes no mesmo dia em que o minikube anunciou o lançamento. Isso nos permitiu testar a compatibilidade em um dia e comunicar que nossa integração com o Kubernetes era compatível com a versão mais recente, sete dias após o lançamento do minikube.

Sincronize a versão mais recente do agente com complementos do AWS EKS Anywhere

A New Relic oferece suporte ao programa Amazon EKS Anywhere Partner, oferecendo nosso agente Kubernetes como um complemento pronto para uso para o cluster Amazon EKS Anywhere. Desenvolvemos um fluxo de trabalho GitHub Actions para abrir automaticamente uma pull request quando cortamos uma nova versão de nosso agente. Isso mantém nosso usuário final do Amazon EKS Anywhere atualizado com as versões mais recentes do agente, garantindo que a New Relic continue passando nos testes de conformidade mais recentes e permaneça como um parceiro validado do Amazon EKS Anywhere.

Automatize o changelog, as comunicações e a documentação

A criação e atualização de documentação é um grande desperdício de tempo. Para obter uma cadência semanal de lançamentos, precisávamos atualizar todos os canais de comunicação para nossos stakeholders internos, clientes externos e parceiros externos. Para automatizar a comunicação com todas essas partes interessadas, criamos um fluxo de trabalho reutilizável que é executado semanalmente e atualiza automaticamente as notas de lançamento, envia mensagens do Slack sobre os lançamentos mais recentes nos canais internos das partes interessadas da New Relic e atualiza a documentação dos desenvolvedores.

Em seguida, nosso próprio fluxo de trabalho GitHub compila a documentação e as notas de lançamento e envia comunicações por todos os canais. Para melhor nos comunicarmos com as partes interessadas internas, criamos nosso próprio bot agente K8s vinculado ao nosso fluxo de trabalho GitHub Actions, para que nossos clientes e parceiros possam ser notificados automaticamente sobre atualizações de lançamento.

Conclusão

Um pipeline de CI oferece mais benefícios do que simplesmente facilitar a vida dos desenvolvedores: os clientes obtêm acesso a software mais seguro, bem documentado e de última geração. 

Um pipeline de CI eficaz é mais do que apenas criar automação no processo de liberação do agente; envolve melhorar os testes para garantir que não ocorram regressões no processo, detectar vulnerabilidades de segurança rapidamente e resolvê-las prontamente, e comunicar-se com todas as partes interessadas de forma clara e eficaz.