Implantação no nginx

Uma receita de produção para pôr um site construído pelo Chinaski atrás do nginx: servir a saída estática, encaminhar as poucas rotas dinâmicas de volta ao daemon do CMS, adicionar TLS e deixar os deploys manterem tudo em sincronia.

Pré-requisitos

Uma instância do CMS em execução (a unit chinaski@<N>) com o daemon ligado ao loopback.
Um diretório de saída construída em /var/www/chinaski<N>/output/<lang> (ou output/ para um site monolíngue sem prefixo de idioma).
O vhost de exemplo do repo (deploy/chinaski.nginx.example para um site estático mínimo; chinaski.nginx.conf.example para o padrão mais completo por instância).

Os três valores a substituir

No vhost copiado, defina:

YOUR_DOMAIN: o hostname público do site.
OUTPUT_PATH: o diretório de saída por idioma de cima.
CMS_PORT: a porta correspondente ao LISTEN_URL em /etc/chinaski<N>/env (3001 para a instância 1 por padrão).

Ativação:

ln -s /etc/nginx/sites-available/YOUR_DOMAIN /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx

Então adicione TLS:

certbot --nginx -d YOUR_DOMAIN

Os dois blocos de proxy que você não deve omitir

Um site Chinaski “estático” tem exatamente duas famílias de URL que precisam alcançar o daemon do CMS:

/forms/: placeholders de formulários são incorporados às páginas construídas, mas as submissões fazem POST de volta ao CMS. Sem este bloco, cada submissão de formulário retorna 404.
/documents/: os downloads de documentos são servidos pelo CMS (contagens de downloads rastreadas, janelas de publicação). Sem este bloco, cada URL de documento retorna 404.

Ambos os blocos encaminham os headers padrão (Host, X-Real-IP, X-Forwarded-For, X-Forwarded-Proto) para que o CMS veja o cliente real, o que é necessário para que seu rate limiting e logging funcionem por visitante.

Trate o tráfego de admin separadamente. A interface de admin vive em seu próprio vhost (ou na própria porta de loopback do CMS, se você não a expõe publicamente). O padrão de checklist que faz proxy a partir do loopback mantém a lógica de trusted-proxy do CMS simples: nenhuma configuração extra de CHINASKI_TRUSTED_PROXIES é necessária porque a conexão vem do loopback. Se a sua arquitetura faz o nginx alcançar o daemon a partir de um endereço não-loopback (por exemplo, uma bridge de contêiner), adicione aquela rede à CHINASKI_TRUSTED_PROXIES.

Cache e headers

O exemplo de vhost define tempos de vida de cache ajustados ao ritmo de publicação do Chinaski:

HTML: cache curto (revalide rapidamente após cada build).
sw.js: no-cache, must-revalidate.
Fontes: caching imutável de um ano.
Outros assets: cache de um dia.
Headers de segurança (X-Frame-Options, nosniff, Referrer-Policy, Permissions-Policy, HSTS de 1 ano): cinto e suspensórios ao lado dos headers que o app já define.

Vhosts de idioma

Para sites multilíngues, duplique o bloco de server por idioma: o vhost de subdomínio ou de caminho de cada idioma serve seu próprio diretório de saída (por exemplo es.example.com → /var/www/chinaski1/output/es), cada um com seu próprio bloco /forms/ apontado ao mesmo upstream.

A sincronização da root no tempo de deploy

deploy/deploy.sh varre as configs do nginx após cada deploy: encontra as diretivas root que apontam para a árvore de saída desta instância e as reescreve para o que o modo de idioma atual requer (output/ para sites monolíngues, output/<default language>/ caso contrário), executa nginx -t e recarrega em caso de sucesso, com um aviso (sem reload) quando o teste de config falha, para que o erro possa ser consertado à mão. Se você segue o layout de exemplo, grande parte da manutenção do nginx vira zero-toque a cada deploy.