Comment faire en sorte qu'un git push mette à jour un site sur un serveur, sans FTP et sans rien taper. Écrit pour quelqu'un qui n'a jamais touché à un fichier .gitlab-ci.yml.
Une chaîne de déploiement, c'est un enchaînement de quatre choses. Aucune n'est compliquée prise isolément ; c'est leur assemblage qui intimide au début.
Le vocabulaire d'abord, parce qu'il revient partout ensuite. Un runner est une machine temporaire que GitLab démarre pour exécuter ton travail : elle naît vide, fait ce que tu lui dis, puis disparaît. Un pipeline est l'ensemble du travail déclenché par un push. Un job est une tâche à l'intérieur de ce pipeline. Et rsync est un outil de copie qui compare source et destination pour ne transférer que les différences — d'où sa vitesse.
Le runner doit prouver au serveur qu'il a le droit d'écrire. Il lui faut donc une clé SSH — et pas la tienne.
ssh-keygen -t ed25519 -f ~/.ssh/id_deploy -N "" -C "gitlab-ci deploy"
Cette commande produit deux fichiers : id_deploy (la clé privée, le secret) et id_deploy.pub (la clé publique, qui se distribue sans risque).
Pourquoi une clé séparée — Tu vas confier cette clé privée à GitLab. Si tu y mettais ta clé personnelle, tu donnerais du même coup l'accès à tous les serveurs qu'elle ouvre. Avec une clé dédiée, le jour où tu veux couper l'accès du runner, tu supprimes une ligne sur le serveur et rien d'autre ne casse.
Le -N "" crée la clé sans phrase de passe. C'est volontaire : personne ne sera là pour la taper au milieu d'un déploiement automatique. C'est précisément pour ça que la clé doit être limitée à un seul usage.
Il faut maintenant dire au serveur : « accepte quiconque présente cette clé ».
ssh-copy-id -i ~/.ssh/id_deploy.pub [email protected]
La commande ajoute la clé publique au fichier ~/.ssh/authorized_keys du serveur. Elle te demandera ton mot de passe habituel : c'est la dernière fois.