Implantação e Operações

Executando o Chinaski em produção: os serviços systemd, o reverse proxy à frente do site público, os scripts de deploy e as páginas operacionais (logs, performance, air-gap, promoções) que mantêm tudo saudável. A seção pressupõe que a instalação do Getting Started já foi feita; ela cobre o que você está de fato executando.

Nesta seção

• Serviços systemd: as units com template (chinaski@<N>, backup, MCP), o que fazem, seu hardening e como habilitá-las/reiniciá-las.
• Proxy Reverso: os dois alvos de proxy (saída estática + o daemon do CMS), as rotas que precisam ser encaminhadas (/forms/, /documents/), os headers de proxy que importam e a regra de confiar em um IP de cliente real.
• O Servidor Hypnotoad: o modelo de servidor (master + workers), o comportamento de reload sem downtime, a configuração EOTW/offline embarcada e a diferença entre daemon e hypnotoad.
• Configuração: convenções do arquivo de env, o LISTEN_URL/LISTEN, o tratamento de segredos e o layout de configurações por instância.
• Hospedagem estática: servindo a saída construída com nginx ou Caddy; os formatos _redirects e quais rotas um site majoritariamente estático ainda precisa encaminhar.
• Implantação por SSH / rsync: enviando a saída construída a um host remoto após cada build bem-sucedido.
• Publicando de um telefone: executando o admin em um telefone Android com Termux e publicando para o Cloudflare R2 como host público.
• Publicando de um notebook: executando o admin em um notebook Linux e publicando para o Cloudflare R2 como host público.
• Publique seu site com o Cloudflare R2: guia passo a passo para publicar seu site no Cloudflare R2: bucket, chaves de acesso, domínio personalizado, regra de reescrita e configurações de deploy do Chinaski.
• Webhooks de Build e Publicação: disparando webhooks em eventos de build/publicação para notificar sistemas externos.
• Modo Air-gapped: instalando e executando totalmente offline; o que a chave desativa; bundles offline e atualizações offline.
• Logs e Monitoramento: logging no journal, os endpoints de saúde, logs de build e a visão de métricas.
• Performance: paralelismo de build, headers de cache, índices de banco de dados e a história do benchmark.
• Guarda de promoção: como um build se recusa a degradar o site ao vivo (queda de páginas, links quebrados, regressões de acessibilidade) e os caminhos de força/sobrescrita.

Como as peças se encaixam

O layout padrão de produção é pequeno:

1. Uma unit systemd executa o daemon do CMS ligado ao loopback (LISTEN_URL=http://127.0.0.1:<porta>).
2. Um reverse proxy (Caddy ou nginx) serve o site público a partir da árvore de saída estática, encaminhando apenas rotas de formulários/documentos/administrativas ao daemon do CMS.
3. Os builds regeneram a árvore estática, disparados do dashboard, por um webhook ou pelo script de deploy, e o script de deploy (ou o alvo rsync/S3) move a saída para a localização de serviço.
4. O monitoramento roda contra os endpoints de saúde, e o modo air-gap (ativado por padrão em instalações novas) mantém todo o stack longe do negócio de chamadas de saída, a menos que explicitamente aberto.

O ciclo se fecha com backups (uma seção própria) e deploys que falham de forma segura: um build com falha nunca reinicia o serviço sobre uma saída que nunca foi promovida. Assim, toda a história operacional cabe em dois minutos de leitura: o que está executando, o que está sendo servido, o que o reconstrói, como manter ambos atualizados e onde olhar quando não estiverem.