Déploiement SSH / rsync

Chinaski peut pousser son site statique fraîchement construit vers un hôte distant après chaque build réussi, via SSH, avec rsync. Vous configurez une cible, et chaque build se termine par la sortie répliquée sur cet hôte. Cette page couvre la configuration, les garde-fous et le comportement en cas d’échec.

Configuration

Sous Settings → Deploy, deux interrupteurs décident si un deploy se déclenche automatiquement :

Deploy automatically after a successful build est l’interrupteur maître. Désactivé par défaut ; le deploy rsync comme le deploy S3 restent dormants tant que ce n’est pas activé, même si leurs propres réglages ci-dessous sont entièrement configurés.
Enable SSH/rsync deploy (aussi désactivé par défaut) active cette cible précise une fois l’interrupteur maître activé.

Remplissez ensuite :

Host : un nom d’hôte comme web01.example.com (lettres, chiffres, points, tirets seulement).
User : le compte SSH (optionnel ; omettez pour utiliser le compte déjà connu de votre configuration ssh locale).
Remote path : le répertoire destination, uniquement un chemin absolu (/var/www/site, sans espaces).
SSH key path : la clé privée sur l’hôte du CMS utilisée pour l’authentification (optionnel, votre configuration ssh en prend peut-être déjà une ; si définie, elle doit aussi être un chemin absolu sans espaces).

Après avoir configuré les deux interrupteurs, enregistrez ; les deploys se font automatiquement au prochain build réussi. Si vos réglages échouent à la validation (un espace dans le chemin, un chemin de clé relatif, des métacaractères shell n’importe où), le deploy est simplement ignoré plutôt qu’exécuté à moitié.

Ce qui se passe réellement

Après qu’un build promeut sa sortie, le CMS lance un rsync en arrière-plan du répertoire de sortie vivant vers la destination :

La forme de la commande est rsync -az --delete via SSH : mode archive, compression, et réplication exacte (fichiers périmés retirés sur la cible).
SSH se connecte de façon non interactive (BatchMode) : authentification par clé uniquement, pas de prompt mot de passe. Préparez l’hôte destination pour l’auth par clé par ailleurs.
Les premières connexions acceptent automatiquement l’empreinte de l’hôte distant (accept-new) ; les connexions suivantes vérifient contre la clé mémorisée.
Tourne en arrière-plan : un deploy ne retient pas la comptabilité du build, et le succès du build est indépendant de celui du deploy.

En mode air-gap tout cela est désactivé. Le deploy ne tourne jamais quelle que soit la configuration.

Validations intégrées

Les réglages de deploy sont protégés avant l’exécution :

Host et user : pas de métacaractères shell (; | & \ $ quotes etc.`), uniquement des caractères plausibles de nom d’hôte.
Remote path et key path : doivent tous deux commencer par /, ne doivent pas contenir de métacaractères shell ni d’espaces.
Tout ce qui échoue à la validation signifie que le deploy ne tourne nulle part, en silence, avec une ligne de log ; le site lui-même a toujours été construit et sert localement.

Statut dans l’admin

Pendant qu’un deploy tourne, l’admin montre un bandeau d’état en direct (interrogé toutes les quelques secondes) qui passe de “Building your update…” à “Build complete. Publishing your update…” puis à “Your update is live.”, ou un état d’erreur si le build ou le deploy a échoué. Le bandeau est piloté par l’état réel du deploy, pas par un minuteur, donc il continue d’afficher “publishing” aussi longtemps qu’une synchronisation tourne réellement, y compris un téléversement lent sur une mauvaise connexion. Il ne disparaît pas avant l’heure juste parce qu’un deploy prend son temps.

Échecs et quoi regarder

Les résultats de déploiement apparaissent dans le journal (journalctl -u chinaski@<N>) :

rsync deploy failed (rc=N): … : la ligne de raison exacte ; les causes communes sont un hôte injoignable, un échec d’auth (clé non autorisée sur la cible), ou un remote path manquant/incorrect.
rsync deploy complete -> user@host:/path : le succès propre.

Un deploy en échec n’affecte jamais le contenu du site sur l’hôte du CMS. La sortie précédente continue de servir ; réessayez en déclenchant un rebuild ou réparez l’accès SSH et reconstruisez.

La sœur : le deploy S3

Un second canal sortant utilise le même pipeline de build : le deploy S3 (bucket, endpoint, région, access key, secret key dans Settings → Deploy), tournant via rclone après l’étape rsync. Vous pouvez utiliser l’un, l’autre ou les deux : les deux tournent à chaque build réussi quand activés. Toutes les cibles de déploiement se déclenchent dans le même ordre par build : webhooks d’abord (build webhook), puis rsync, puis S3.