Implantação no Caddy
O Caddy é o servidor web de referência do Chinaski: TLS automático e duas peças de ligação por instância, um bloco de site que serve a saída estática e o snippet de redirecionamentos gerado pelo builder, incluído por site. Esta página atravessa um setup Caddy de produção; o exemplo de Caddyfile embarcado é a cópia-fonte de onde partir.
Pré-requisitos
- Uma instância do CMS em execução (a unit
chinaski@<N>), daemon ligado ao loopback. - Um diretório de saída construída por idioma (
/var/www/chinaski<N>/output/<lang>, ououtput/para sites monolíngues). - O exemplo embarcado
deploy/chinaski.Caddyfile.examplepara copiar.
Copie e adapte o exemplo
O Caddy não tem templing de instância, então cada deployment ganha sua própria cópia editada. No exemplo, defina por instância:
- Os hostnames do site (domínio de admin mais quaisquer vhosts de idioma).
- A porta de upstream: o endereço de loopback correspondente ao
LISTEN_URLno arquivo de env daquela instância (instância 1 → 3001, instância 2 → 3002). - As document roots: diretórios de saída por idioma.
O Caddy obtém e renova certificados TLS automaticamente assim que o DNS aponta para o host e as portas 80/443 estão acessíveis, sem nenhum passo de certbot. Verifique com curl -I https://<host> após a primeira inicialização.
Os encaminhamentos que o exemplo inclui
Um site Caddy majoritariamente estático ainda encaminha isto ao daemon do CMS no loopback:
/forms/*: renderização de formulários públicos e tratamento de POST. Sem isso, submissões de formulários incorporados retornam 404./documents/*: downloads de documentos (o caminho de rastrear-e-contar que um servidor de arquivos estático não pode fazer).- Caminhos de honeypot de scanner (
/.env,/.git/config,wp-login.phpe amigos): roteados ao CMS para que sondagens sejam registradas e estranguladas em vez de respondidas com um 404 ordinário de servidor.
O exemplo também inclui uma rota de download-de-instalador servida direto do diretório de deployment, prática para o padrão de URL de instalador por curl documentado.
As chamadas do proxy definem X-Forwarded-For, X-Forwarded-Proto e X-Forwarded-Host explicitamente, que é o próprio pedido do checklist de produção do README. Como o exemplo faz proxy a partir do loopback (confiável por padrão), nenhuma CHINASKI_TRUSTED_PROXIES extra é necessária; apenas um salto de rede de contêiner a exigiria.
Headers de cache
O bloco embarcado casa com a política de cache padrão (HTML com cache curto revalidado a cada build; sw.js no-cache; fontes imutáveis por ano; outros assets diários) e repete o conjunto de headers de segurança do app como cinto-e-suspensório para respostas servidas antes de o app poder.
Incluindo os redirecionamentos gerados
Após cada build, o builder escreve _redirects.caddy na raiz da saída: seus redirecionamentos de slug mais (quando uma URL de Site está configurada) a imposição de domínio canônico no _redirects do mesmo arquivo. Inclua o snippet em sintaxe Caddy em cada bloco de site conforme o próprio comentário de cabeçalho do arquivo orienta; como a linha de domínio canônico do Caddy usa o marcador de força 301!, este arquivo é destinado especificamente ao Caddy (outros hosts devem revisar essa sintaxe como descrito na página de redirect-formats).
A confiança no loopback local significa nenhuma configuração extra
O exemplo faz proxy a partir de 127.0.0.1, no qual o CMS já confia, de modo que o registro de IP de cliente e o rate limiting por IP funcionam sem configurações extras. Caso a sua topologia em vez disso faça proxy de um endereço não-loopback (uma bridge de contêiner, por exemplo), adicione aquela rede à CHINASKI_TRUSTED_PROXIES para que o IP real do visitante seja o que é registrado e limitado.