Tema: deployment
-
Quais regras de retenção de imagens mantêm um container registry enxuto sem apagar imagens que ainda estão implantadas?
Pergunta em aberto: registries só coletam como lixo os blobs que nenhum manifest referencia, e as políticas de ciclo de vida expiram imagens por idade, quantidade ou padrão de tag; que combinação de regras equipes já mantêm por anos sem crescimento descontrolado nem um rollback que falhou porque a imagem tinha sumido?
-
Qual estratégia de rollout funciona em um único host com Docker Compose e proxy reverso?
Pergunta em aberto: rolling, blue-green e canary são descritos para orquestradores, mas muitos serviços pequenos rodam em um único host com Docker Compose atrás de Traefik, nginx ou Caddy. Que adaptações – segundo contêiner com regra de proxy alternada, distribuição ponderada, start-first – equipes mantiveram em produção por meses, o que quebrou e a partir de que porte um orquestrador compensa?
-
Tags e releases: tags leves versus anotadas e como elas se propagam
Uma tag leve é apenas um nome para um commit; uma tag anotada é um objeto com autor, data, mensagem e assinatura opcional. Por isso o git describe ignora tags leves por padrão e os releases devem usar tags anotadas ou assinadas. As tags não são enviadas junto com os branches, a menos que se use --follow-tags ou --tags, e uma tag já publicada nunca deve ser movida.
-
Encerramento gracioso: tratando SIGTERM em serviços
Os runtimes de contêiner enviam SIGTERM e aguardam um período de tolerância antes do SIGKILL; o serviço deve parar de aceitar novo trabalho, concluir ou devolver o trabalho em andamento, fechar conexões e encerrar dentro desse período. Ignorar o sinal transforma cada deploy em uma indisponibilidade.
-
Projetar o rollback antes do rollout
Escreva uma árvore de decisão de recuperação antes do deploy, distinguindo mudanças de configuração reversíveis de migrações de dados que exigem compensação.
-
Alterações de banco de dados sem indisponibilidade: Expand e Contract
Como alterar um esquema em três etapas que podem ser entregues separadamente: expandir (criar a nova coluna ou tabela e manter a antiga), migrar (gravar nos dois lugares e preencher os dados antigos em lotes pequenos) e contrair (remover o antigo quando todo o código já usa o novo). Para evitar bloqueios longos, nenhuma tabela é reescrita em um único comando e o lock_timeout limita qualquer espera.
-
Faça um canary de mudanças de comportamento antes do rollout
Exponha um grupo limitado a um novo comportamento, compare-o com uma linha de base e interrompa o processo com base em condições de falha declaradas de antemão.
-
Modo de manutenção somente leitura: continuar a atender leituras com as escritas em pausa
Em migrações de armazenamento, failovers e migrações longas, um serviço pode continuar a atender leituras e recusar escritas com uma mensagem clara, em vez de ficar fora do ar. O `default_transaction_read_only` do PostgreSQL torna as novas transações somente leitura no banco como rede de segurança, e o HTTP 503 com `Retry-After` indica aos clientes quando tentar de novo. O modo exige um único interruptor, uma mensagem para o usuário e um ensaio.
-
Implantações rolling, blue-green e canary: comparação
A atualização rolling substitui as instâncias gradualmente, dentro de limites de excedente e de indisponibilidade; a blue-green executa a nova stack completa ao lado da antiga e troca o tráfego de uma só vez; a canary envia uma pequena parcela do tráfego real à nova versão e só a promove com base em evidências. A escolha depende da capacidade disponível, da velocidade de rollback e de duas versões poderem ou não atender ao mesmo tempo.
-
A metodologia twelve-factor app como checklist para serviços
Os doze fatores descrevem convenções para serviços implantáveis: uma única base de código, dependências declaradas, configuração no ambiente, serviços de apoio como recursos anexados, separação estrita entre build, release e run, processos sem estado e logs como fluxo de eventos.
-
Gerenciar segredos fora do repositório
Credenciais devem ficar em configuração protegida, injetada em tempo de execução, e nunca em controle de versão, imagens ou logs; faça a rotação periodicamente e em caso de suspeita, e use credenciais próprias para cada serviço.
-
Promover um único build entre ambientes: promoção de configuração e paridade entre dev e prod
Construa o artefato uma só vez, dê-lhe uma identidade imutável e promova esse mesmo artefato de teste para staging e produção, alterando apenas a configuração específica de cada ambiente; mantenha os ambientes semelhantes em serviços de apoio e topologia, para que uma etapa aprovada permita prever a seguinte.
-
Migrações de esquema com lock_timeout curto e nova tentativa automática causam menos incidentes no deploy do que migrações sem esse mecanismo
Hipótese: como a maioria das formas de ALTER TABLE exige um lock ACCESS EXCLUSIVE que fica na fila atrás de qualquer transação longa e bloqueia todas as consultas seguintes, migrações executadas com lock_timeout de poucos segundos e um laço de nova tentativa limitado geram menos interrupções, e mais curtas, durante o deploy do que as mesmas migrações com a espera ilimitada padrão. O custo é que algumas migrações precisarão ser reexecutadas manualmente.
-
Como publicar um service worker com segurança: escopo, caches versionados, worker em espera e kill switch
Um service worker que guarda HTML em cache pode prender os usuários a código antigo depois de um deploy. Registre-o com escopo explícito, busque o script sempre da rede nas verificações de atualização, versione os caches por build e apague os antigos no activate, escolha estratégias por recurso, defina como o worker em espera assume o controle e entregue um kill switch testado antes da primeira versão.
-
Quais verificações pré-implantação realmente barraram uma versão ruim no último ano, e quais nunca dispararam?
Pergunta em aberto: pipelines acumulam gates (testes, varreduras, smoke tests, análise de canary, aprovações manuais, prazos de rollout), e a documentação do Kubernetes indica que um Deployment travado apenas é reportado, sem rollback; quais gates têm histórico de barrar uma versão ruim, quais nunca dispararam e quais só dispararam em falsos positivos?
-
Feature toggles: tipos, tempo de vida e remoção
Os toggles separam o deploy do release, mas cada toggle é uma ramificação no código; classifique-os por finalidade (release, experimento, operação, permissão) e atribua a cada um um responsável e uma data de remoção.
-
Alterações de esquema sem downtime com expand and contract
Altere um esquema em três etapas implantáveis: expandir (adicionar a nova coluna ou tabela mantendo a antiga), migrar (escrita dupla e backfill em lotes) e contrair (remover a antiga depois que todo o código usar a nova); evite locks longos não reescrevendo tabelas em uma única instrução.
-
Como construir imagens de contêiner pequenas e reproduzíveis
Fixe as imagens base por digest, instale dependências a partir de lockfiles com verificação de hash, copie apenas o que o runtime precisa, execute como usuário não root, adicione um health check e mantenha segredos fora das camadas e dos argumentos de build.
-
Tags versus digests de imagens de contêiner: nomes mutáveis e endereços de conteúdo
Uma tag é um ponteiro legível que pode ser movido para outro manifest a qualquer momento; um digest é o hash dos bytes do manifest e identifica exatamente uma imagem, para sempre. Faça build e teste por tag, faça deploy e fixe a versão por digest, e registre o digest em cada nota de release.
-
Executar um serviço com o systemd
Um arquivo de unidade declara como um serviço é iniciado, reiniciado e isolado; use Type, Restart=on-failure, limites de recursos e diretivas de sandboxing, e leia os logs com journalctl em vez de escrever sua própria daemonização.
Legível por máquina: JSON