Comment utiliser Rsync et SSH dans un pipeline GitLab CI Dockerisé

rsync est un utilitaire de synchronisation de fichiers populaire qui utilise un algorithme efficace pour minimiser la consommation de bande passante. L'un des rôles courants de rsync est de déployer une compilation de site web sur un serveur de production distant. Voici comment combiner la polyvalence de rsync avec l'automatisation fournie par les pipelines GitLab CI.

Exécuteurs de pipeline

GitLab CI prend en charge plusieurs types d'exécuteurs de pipeline. Ceux-ci définissent l'environnement dans lequel votre tâche s'exécutera. Le

shell

L'exécuteur est par défaut et fonctionne en mode natif sur la machine hôte. Il permet à vos pipelines d'utiliser n'importe quelle commande disponible sur l'hôte sans configuration supplémentaire. Comme la plupart des distributions Linux populaires livrent avec rsync installé, cette approche est facile à comprendre.

Malheureusement, le

shell

l'exécuteur ne fournit pas une forte isolation et peut polluer l'environnement de votre hôte au fil du temps. Une meilleure alternative est le

docker

exécuteur, qui lance un nouveau conteneur Docker pour chaque tâche CI. Toutes les tâches s'exécutent dans un environnement propre qui ne peut pas affecter l'hôte.

L'inconvénient ici est que les images de base Docker n'incluent généralement pas rsync ou

ssh

. Même les images officielles de l'OS telles que

ubuntu:latest

expédier en tant que constructions minimales sans ces commandes. Cela rend le script de pipeline légèrement plus compliqué pour ajouter les dépendances et rsync vos fichiers.

Voici comment ajouter rsync à votre pipeline. Assurez-vous d'avoir un GitLab Runner basé sur Docker disponible avant de continuer. Nous supposerons également que vous avez un projet GitLab prêt à être utilisé.

Se préparer

Vous aurez besoin d'une paire de clés SSH si vous prévoyez d'utiliser rsync pour vous connecter à un hôte SSH distant. Vous pouvez générer des clés publiques et privées en exécutant

ssh-keygen -t rsa

Copiez la clé publique sur le serveur auquel vous allez vous connecter.

Ensuite, copiez la clé privée générée dans votre presse-papiers :

cat ~/.ssh/id_rsa | xclip -selection c

Accédez à votre projet GitLab et cliquez sur "Paramètres" en bas du menu de navigation de gauche. Cliquez sur l'élément "CI/CD" dans le sous-menu. Faites défiler vers le bas jusqu'à la section "Variables" sur la page résultante.

Cliquez sur le bouton bleu "Ajouter une variable". Donnez un nom à votre nouvelle variable dans le champ "Clé". Nous utilisons SSH_PRIVATE_KEY. Collez votre clé privée dans le champ "Valeur", en incluant la ligne de début ----BEGIN et la ligne de fin -----END.

Ajouter la clé en tant que variable CI vous permet de la référencer ultérieurement dans votre pipeline. Elle sera ajoutée à l'agent SSH dans les conteneurs que votre pipeline crée.

Ajout de votre fichier de pipeline

GitLab CI exécute des travaux en fonction du contenu d'un fichier .gitlab-ci.yml dans votre dépôt. GitLab trouvera automatiquement ce fichier et exécutera le pipeline qu'il définit lorsque vous pousserez des modifications vers vos branches.

deploy: stage: deploy image: alpine:latest script:

- rsync -atv --delete --progress ./ user@example.com:/var/www/html

Ce .gitlab-ci.yml contient un travail qui utilise rsync pour synchroniser le contenu du répertoire de travail vers /var/www/html sur le serveur example.com. Il utilise l'image Docker alpine:latest comme environnement de construction. Le pipeline échouera actuellement car rsync n'est pas inclus dans l'image Alpine.

Installer SSH et rsync

Alpine est une bonne base pour le travail car c'est une image légère avec peu de dépendances. Cela réduit l'utilisation du réseau lorsque GitLab tire l'image au début du travail, accélérant votre pipeline. Pour faire fonctionner rsync, ajoutez SSH et rsync à l'image, puis lancez l'agent SSH et enregistrez la clé privée que vous avez générée précédemment.

deploy: stage: deploy image: alpine:latest before_script: - apk update && apk add openssh-client rsync - eval $(ssh-agent -s) - echo "$SSH_PRIVATE_KEY" | ssh-add - script:

- rsync -atv --delete --progress ./ user@example.com:/var/www/html

OpenSSH et rsync sont installés en utilisant le gestionnaire de paquets apk d'Alpine. L'agent d'authentification SSH est démarré, et votre clé privée est ajoutée via ssh-add. GitLab injecte automatiquement la variable d'environnement SSH_PRIVATE_KEY avec la valeur que vous avez définie dans les paramètres de votre projet. Si vous avez utilisé une clé différente sur l'écran des variables GitLab, assurez-vous d'ajuster votre pipeline en conséquence.

Gestion de la vérification de l'hôte

SSH demande interactively une confirmation la première fois que vous vous connectez à un nouvel hôte distant. Cela est incompatible avec l'environnement CI, où vous ne pourrez pas voir ni répondre à ces demandes.

Deux options sont disponibles pour y remédier : désactiver les vérifications strictes des clés d'hôte, ou enregistrer votre serveur en tant qu'hôte "connu" à l'avance.

Pour la première option, ajoutez la ligne suivante à before_script de votre pipeline :

- echo "Host *ntStrictHostKeyChecking no" >> ~/.ssh/config

Bien que cela fonctionne, c'est un risque potentiel pour la sécurité. Vous n'auriez aucun avertissement si un attaquant prenait le contrôle du domaine ou de l'adresse IP de votre serveur. L'utilisation de la vérification de la clé d'hôte vous permet de vérifier que l'identité de l'hôte distant est celle que vous attendez.

Vous pouvez ajouter le télécommande en tant qu'hôte connu de manière non interactive en vous y connectant depuis votre propre machine en dehors de votre pipeline. Examinez votre fichier ~/.ssh/known_hosts et trouvez la ligne contenant l'IP ou le nom d'hôte du télécommande. Copiez cette ligne et utilisez la procédure précédente pour ajouter une nouvelle variable GitLab CI. Nommez cette variable SSH_HOST_KEY.

Maintenant, mettez à jour votre section before_script avec la ligne suivante :

- echo "$SSH_HOST_KEY" > ~/.ssh/known_hosts

Maintenant, vous pourrez vous connecter au serveur sans recevoir de demandes de confirmation. Poussez votre code vers votre dépôt GitLab et regardez votre pipeline se compléter.

Améliorations supplémentaires

Ce pipeline est un exemple simple de la façon de commencer avec SSH et rsync dans un environnement Dockerisé. Il existe des opportunités pour améliorer davantage le système en englobant les étapes de préparation dans une étape de construction dédiée qui construit une image Docker que vous pouvez réutiliser entre les pipelines.

Le .gitlab-ci.yml bénéficierait également d'une plus grande utilisation de variables. L'abstraction du nom d'hôte du serveur distant (example.com), du répertoire (/var/www/html) et de l'utilisateur (user) en variables GitLab CI aiderait à garder le fichier propre, à empêcher les navigateurs de dépôts occasionnels de voir les détails environnementaux, et à vous permettre de changer les valeurs de configuration sans éditer votre fichier de pipeline.

Résumé

L'utilisation de rsync dans les pipelines GitLab CI nécessite un peu de configuration manuelle pour former un environnement de construction qui a les dépendances dont vous avez besoin. Vous devez injecter manuellement une clé SSH privée et enregistrer le serveur distant comme hôte connu.

Bien que des images Docker communautaires soient disponibles, superposant SSH et rsync sur des images de base populaires, celles-ci vous donnent finalement moins de contrôle sur votre construction. Vous étendez la chaîne d'approvisionnement de votre pipeline avec une image que vous ne pouvez pas nécessairement faire confiance. Commencer avec une image de base OS et ajouter ce dont vous avez besoin vous aide à avoir confiance dans vos constructions.