Implantação por SSH / rsync

O Chinaski pode enviar seu site estático recém-construído a um host remoto após cada build bem-sucedido, por SSH, usando rsync. Você configura um alvo, e cada build termina com a saída espelhada naquele host. Esta página cobre a configuração, os trilhos de segurança e o comportamento em falha.

Configuração

Em Settings → Deploy, dois interruptores decidem se um deploy dispara automaticamente:

Deploy automatically after a successful build é o interruptor mestre. Desligado por padrão; tanto o deploy rsync quanto o deploy S3 permanecem dormentes até que isto esteja ligado, mesmo que as próprias configurações deles abaixo estejam totalmente prontas.
Habilitar deploy SSH/rsync (também desligado por padrão) liga este alvo específico depois que o interruptor mestre está ligado.

Depois preencha:

Host: um hostname como web01.example.com (apenas letras, dígitos, pontos e hífens).
Usuário: a conta SSH (opcional; omita para usar a conta já conhecida do seu ssh config local).
Caminho remoto: o diretório de destino, apenas absoluto (/var/www/site, sem espaços).
Caminho da chave SSH: a chave privada no host do CMS usada para autenticar (opcional, seu ssh config talvez já escolha uma; se definida, também deve ser um caminho absoluto sem espaços).

Depois de configurar os dois interruptores, salve; os deploys acontecem automaticamente no próximo build bem-sucedido. Se suas configurações falharem na validação (um espaço no caminho, um caminho de chave relativo, metacaracteres de shell em qualquer lugar), o deploy simplesmente é pulado em vez de executar pela metade.

O que realmente acontece

Depois que um build promove sua saída, o CMS lança um rsync em segundo plano do diretório de saída ao vivo para o destino:

O formato do comando é rsync -az --delete por SSH: modo archive, compressão e espelhamento exato (arquivos obsoletos são removidos no alvo).
O SSH conecta de forma não interativa (BatchMode): apenas autenticação por chave, sem prompt de senha. Configure o host de destino para autenticação por chave por fora.
Primeiras conexões auto-aceitam a fingerprint do host remoto (accept-new); conexões seguintes verificam contra a chave memorizada.
Executa em segundo plano: um deploy não atrasa a contabilidade do build, e o sucesso do build é independente do do deploy.

No modo air-gap tudo isso está desabilitado. O deploy nunca executa, independente da configuração.

Validações embutidas

As configurações de deploy são guardadas antes da execução:

Host e usuário: nenhum metacaractere de shell (; | & \ $ aspas etc.), apenas caracteres plausíveis de hostname.
Caminho remoto e caminho de chave: ambos devem começar com /, não podem incluir metacaracteres de shell nem espaços.
Qualquer coisa reprovada na validação significa que o deploy silenciosamente executa em lugar nenhum, com uma linha de log; o próprio site ainda foi construído e serve localmente.

Status no admin

Enquanto um deploy executa, o admin mostra um banner de status ao vivo (consultando a cada poucos segundos) que caminha de “Building your update…” para “Build complete. Publishing your update…” e daí para “Your update is live.”, ou um estado de erro se o build ou o deploy falharam. O banner é dirigido pelo estado real do deploy, não por um temporizador, então continua mostrando “publishing” por todo o tempo em que uma sincronização estiver genuinamente executando, inclusive um upload lento por uma conexão ruim. Ele não desaparece antes da hora só porque um deploy está demorando.

Falhas e o que procurar

Os desdobramentos do deployment aparecem no journal (journalctl -u chinaski@<N>):

rsync deploy failed (rc=N): …: a linha exata do motivo; causas comuns são host inacessível, falha de autenticação (chave não autorizada no alvo) ou caminho remoto ausente/incorreto.
rsync deploy complete -> user@host:/path: o sucesso limpo.

Um deploy com falha nunca afeta o conteúdo do site no host do CMS. A saída anterior continua a ser servida; tente novamente disparando um rebuild ou consertando o acesso SSH e reconstruindo.

A irmã: deploy S3

Um segundo canal de saída usa o mesmo pipeline de build: o deploy S3 (bucket, endpoint, região, access key, secret key em Settings → Deploy), executado via rclone após o passo do rsync. Você pode usar um ou ambos: ambos executam a cada build bem-sucedido quando habilitados. Todos os alvos de deployment disparam na mesma ordem por build: webhooks primeiro (build webhook), depois rsync, depois S3.