Estático primeiro
O site público do Chinaski é HTML estático simples servido do disco, e o banco de dados só é acessado enquanto você cria conteúdo. Esta página explica por que ele é construído assim e o que isso significa para o seu trabalho diário.
Como o seu site é realmente entregue
O Chinaski roda como duas peças que cooperam:
- O CMS , uma aplicação de administração privada, onde você escreve e organiza o conteúdo. Ela guarda tudo em um banco de dados embutido e traz consigo a interface de administração do site.
- O builder , um processo separado que lê esse banco de dados, renderiza suas páginas por meio de templates e escreve arquivos de HTML estático simples no disco.
O seu servidor web serve esses arquivos estáticos diretamente. A aplicação do CMS nunca está no caminho público das requisições. Na implantação padrão, os hosts públicos são servidores de arquivos estáticos, e a configuração do servidor reforça essa arquitetura , ela serve o diretório de saída gerado direto do disco, com uma única exceção estreita descrita abaixo.
Por que é estático, não dinâmico
Porque o site publicado é apenas arquivos:
- Nenhum rastreador consegue se infiltrar. Nada é executado no site público por padrão, e não existe mecanismo que pudesse injetar um beacon nas suas páginas.
- A superfície de ataque permanece pequena. A aplicação de administração roda vinculada a um endereço de loopback (apenas localhost), não a uma interface pública.
- Nada para vazar. O banco de dados , conteúdo, contas, rascunhos , vive do lado da criação de conteúdo e não é exposto a requisições públicas.
Os builds são explícitos
Salvar ou publicar conteúdo não reconstrói o site automaticamente. Um build é disparado quando você o inicia pelo painel de administração, por um webhook configurado ou executando o builder você mesmo. Builds são operações deliberadas, com um log visível, não efeitos colaterais em segundo plano. Cada build é registrado em log para que você possa revisar exatamente o que foi escrito.
Apenas um build roda por vez; um segundo disparo informa que o build já está em andamento em vez de competir com ele. Os builds são incrementais por padrão, com um rebuild completo disponível quando necessário.
O site nunca sai do ar no meio de uma atualização
A escrita da saída é deliberadamente defensiva:
- Os arquivos são escritos atomicamente: o novo conteúdo é preparado e renomeado para o lugar, de modo que o servidor público nunca sirva um arquivo escrito pela metade.
- Se o build falha ou expira, o site construído anteriormente permanece no ar, intocado e intacto.
- Antes de um novo build entrar no ar, o builder o compara com o último build bom. Se algo deu errado , uma queda súbita na contagem de páginas, um pico contabilizado de links quebrados , o builder se recusa a promovê-lo e o site anterior continua servindo. Saída desatualizada é o pior caso, não uma quebrada.
- Os builds têm um teto de 2 GiB de escrita, com limpeza automática, de modo que um estouro aborta o build em vez de encher o disco.
A única exceção: formulários
Como o site público é estático, os envios de formulários não podem ser tratados pelo servidor de arquivos. Isso afeta os formulários dos blocos de contato e de newsletter: os envios fazem POST para /forms/<the form's address>, que o servidor web encaminha por proxy para a aplicação do CMS. A configuração padrão da implantação inclui esse proxy; removê-lo só é seguro se o site não tiver formulários.
Páginas protegidas por senha também são estáticas: o conteúdo protegido vai dentro do arquivo HTML e é desbloqueado no navegador do visitante por uma verificação de senha. Isso significa que o conteúdo está tecnicamente presente na página mesmo com o portão trancado , um visitante que leia o HTML bruto pode extraí-lo.