Um rollout do Kubernetes e um rollout de feature flag respondem perguntas diferentes. O Deployment decide qual imagem roda em quais pods. A flag decide quais usuários recebem o caminho de código novo dentro desses pods. O rollfuse cuida só da segunda pergunta: ele não cria, não escala e não reverte pods, e não controla qual fatia dos pods um canário recebe.
O que o rollfuse faz dentro do cluster é rápido de ligar. Cada deployment recebe a credencial do ambiente ao qual pertence, e o SDK no pod avalia as flags desse ambiente localmente.
Um ambiente, uma credencial
Ambientes pertencem a um projeto, e você os cria no console ou pela API:
POST /v1/projects/{project_id}/environments
{
"name": "Produção",
"slug": "production"
}
Uma service credential é emitida para exatamente um ambiente (POST /v1/environments/{environment_id}/credentials) e não lê nem altera nenhum outro. Um SDK só precisa do escopo config:read. Como a credencial já define o ambiente, não existe uma configuração separada para dizer ao SDK em que ambiente ele está: um deployment de homologação e um de produção só diferem na credencial que montam.
Passando a credencial para o pod
Guarde a credencial num Secret do Kubernetes e exponha para o contêiner como variável de ambiente:
env:
- name: ROLLFUSE_SERVICE_CREDENTIAL
valueFrom:
secretKeyRef:
name: rollfuse-credential
key: ROLLFUSE_SERVICE_CREDENTIAL
O nome da variável é escolha sua. O SDK nunca lê variáveis de ambiente por conta própria; seu código lê o valor e passa para o cliente, como em rollfuse.NewClient("https://api.rollfuse.com", credential) com o SDK de Go.
Pronto só quando as flags podem ser avaliadas
client.Start(ctx) bloqueia até a primeira busca de configuração dar certo. Se o serviço só abre a porta depois dessa chamada e o readinessProbe aponta para um endpoint servido a partir daí, o pod nunca recebe tráfego antes de conseguir avaliar uma flag.
Mudando quem vê uma funcionalidade sem mexer nos pods
A avaliação acontece no próprio processo, contra uma configuração em cache. O SDK de Go (v0.2.1) mantém essa configuração atualizada consultando a API do rollfuse periodicamente, a cada 30 segundos por padrão. Por isso, mudar o percentual de um rollout ou desligar uma flag não exige imagem nova, revisão nova do Deployment nem reinício.
Onde o guardrail entra
Um guardrail acompanha uma métrica durante o rollout de uma flag. Se a métrica passa do limite, o rollfuse aborta o rollout e a flag volta a servir a variação padrão para 100% daquele ambiente. O Deployment não é tocado: a imagem nova continua rodando, e só o caminho de código atrás da flag deixa de ser servido. Reverter o Deployment em si continua com o Kubernetes ou com a sua ferramenta de deploy. A página do Prometheus mostra como uma métrica chega até um guardrail.
Teste num cluster
O repositório público examples-kubernetes roda um serviço de checkout com flag em qualquer cluster, com manifestos simples (Deployment, Service, ConfigMap e Secret) e um substituto local da API do rollfuse, então não precisa de conta no rollfuse. Editar a divisão do rollout no ConfigMap muda a variação que as duas réplicas servem, sem reinício.