Feito com Chinaski

Hospedagem Estática com nginx

O nginx serve a árvore estática construída e encaminha duas famílias de URL ao daemon do CMS. O repositório embarca dois vhosts de exemplo; esta página cobre ambos e a sincronização de root no tempo de deploy.

Os dois arquivos de exemplo

  • deploy/chinaski.nginx.example, o vhost estático mínimo: document root, blocos de proxy /forms/ e /documents/, políticas de cache e headers de segurança.
  • deploy/chinaski.nginx.conf.example, o exemplo mais completo por instância (porta 80 por padrão; adicione TLS via certbot --nginx -d SEU_DOMINIO após habilitar o vhost).
  • Faça symlink em sites-enabled/, execute nginx -t, e então recarregue (systemctl reload nginx) após a configuração.

A document root

Aponte o root para a saída construída:

  • /var/www/chinaski<N>/output/<lang>, para multilíngue por caminho (vhosts individuais de idioma; por exemplo, um por site de idioma).
  • /var/www/chinaski<N>/output, para sites monolíngues (o modo de URL none).

O script de deploy autocorrige a root do nginx para você: a cada deploy, o deploy.sh reescreve a diretiva root em qualquer config nginx que referencie aquele diretório de instalação para corresponder ao modo de idioma atual (apenas output para none; caso contrário output/<idioma padrão>), roda nginx -t, e recarrega, com um aviso se o teste de config falha, para você saber que deve revisar manualmente.

Blocos de proxy de que você precisa

  • location ^~ /forms/ encaminha para http://127.0.0.1:CMS_PORT, obrigatório quando qualquer formulário no site publica submissões (ou renderiza qualquer formulário ao menos). Sem ele: “cada envio de formulário retorna 404”.
  • location ^~ /documents/, obrigatório quando o site usa a funcionalidade de documentos; o rastreamento de downloads de documentos e o estado de publicação não podem ser embutidos em um build estático.

Outros caminhos estáticos não precisam de nada além de try_files $uri $uri/index.html =404 (mais diretivas de cache por asset e headers de segurança).

Headers de cache que os exemplos definem

  • HTML, teto pequeno (revalidação de 5 minutos), para que conteúdo publicado seja oportuno.
  • Service worker, no-cache (sw.js).
  • Fontes, 1 ano imutável.
  • Outros assets, 1 dia.
  • Headers de segurança, como cinto-e-suspensório: o app os define também; o proxy adiciona uma camada para respostas antes que o app tenha chance.

Proxy pelo loopback (e por que não exige configuração extra)

Os exemplos fazem proxy a partir de 127.0.0.1 , loopback, confiável por padrão no app. Se o seu ambiente real encaminha ao CMS a partir de um endereço não-loopback (uma bridge de contêiner, por exemplo), adicione essa rede à CHINASKI_TRUSTED_PROXIES para que IPs reais de clientes sejam registrados e o rate limiting funcione por visitante.

Leia este site em