Muitas aplicações da plataforma rodam em servidores das Unidades e de parceiros, implantadas pelo Releaser. Até ontem, essas builds ficavam invisíveis para a dashboard do Embrapa I/O: sem versão no card, sem saúde dos serviços e sem varredura de vulnerabilidades. Logs, erros e acessos funcionavam, pois Loki, Sentry e Matomo são configurados pela própria equipe, mas o Trivy só alcançava os clusters da plataforma.

A versão 1.26.10-2 do Releaser fecha essa lacuna. A partir dela, cada servidor reporta à plataforma o que sabe sobre as builds que implanta, e a dashboard passa a mostrá-las como mostra os estágios dos clusters:

Card com os estágios release e beta vindos do Releaser e o alpha na plataforma

  • a versão aparece em laranja, com o ícone de servidor, para distinguir dos estágios da plataforma, em ciano. Passe o mouse para ver em qual servidor a build está e quando foi o último contato;
  • o coração passa a considerar a saúde dos serviços (estado e healthcheck dos containers) e as CVEs das imagens em execução, para todos os estágios, da plataforma ou do Releaser;
  • o Health Check mostra os serviços, a origem e as vulnerabilidades encontradas pelo Trivy, que agora roda no próprio servidor, hora em hora.

Health Check de uma build implantada pelo Releaser

Esses dados também alimentam a Sentinela, lançada hoje: os relatórios do projeto passam a incluir as builds do Releaser, com suas CVEs e sua saúde, e não só as da plataforma.

O que você precisa fazer

Apenas atualizar a imagem, seguindo o procedimento de sempre. A autenticação usa o mesmo token do GitLab que o Releaser já tem, e as builds, o .env e as chaves do diretório de configuração continuam valendo. Um minuto depois da atualização, os estágios aparecem no card.

O que cada build reporta é controlado pelo atributo stats do seu arquivo de configuração, com tudo ligado por padrão. Faz sentido desligar a varredura de CVEs ("cve": false) em servidores pequenos ou sem acesso ao ghcr.io, de onde o Trivy baixa o banco de vulnerabilidades.

Um detalhe: um estágio é implantado pela plataforma ou por um Releaser, nunca pelos dois. Se uma build antiga ficou configurada num servidor depois de migrada para a plataforma, o relato dela é recusado e o io info mostra o motivo. É a hora de removê-la do servidor.

Mais duas novidades

A mesma versão traz duas mudanças na configuração do Releaser:

  • Um arquivo por build. Em vez de um único builds.json, cada build é um arquivo em builds/<projeto>_<app>_<estágio>.json. Para desativar uma build sem perder a configuração, basta renomear o arquivo para .bkp. O builds.json antigo continua funcionando, e o comando io split migra quando você quiser.
  • io install. Configuração guiada de uma build nova: escolhe o projeto, a app e o estágio por menus, busca na plataforma a equipe, o DSN do Sentry, o site e o token do Matomo e as variáveis do settings.json da aplicação, gera senhas aleatórias e a próxima porta livre, e grava o arquivo pronto para o primeiro deploy. Nada mais de copiar DSN e token à mão.

Tudo está detalhado no capítulo do Releaser da documentação. Dúvidas e problemas na atualização, como sempre, na sala Arquitetos de Soluções do Google Chat.