Il arrive que des clients souhaitent héberger leur site sur un petit hébergement OVH et pour se caler sur nos process, ce n’est pas toujours simple.

Nous avons un projet où nous disposions uniquement des accès FTP, du coup notre seul moyen de déployer assez “proprement”, c’était avec Git-FTP. Aujourd’hui, nous avons récupéré des accès SSH, nous avons voulu mettre en place le déploiement continue.

Pour compliquer les choses, vous allez vite vous rendre compte que vous pourrez uniquement cloner des projets depuis un nombre limité de service, donc si comme dans mon agence vous avez un gitlab hébergé, vous serez bloqué par le par feu.

Voici donc la combine que j’ai trouvé pour arriver à faire des git pull dans le projet sur les déploiements continues 😄.

Commencez par générer une paire de clés, et envoyez la clé publique sur votre serveur OVH :

$ ssh-keygen -t rsa -b 4096 -C ovh -f /tmp/id_rsa -q -N ""
$ ssh-copy-id -i /tmp/id_rsa.pub ovh-user@ovh-host

Et ajoutez une variable de build SSH_KEY sur le projet avec le contenu de /tmp/id_rsa dans Gitlab (ou votre autre service de déploiement continue).

Vous pouvez faire un premier déploiement, avec un .gitlab-ci de ce genre :

image: tennox/rsync-ssh-git

stages:
  - deploy

deploy:production:
  stage: deploy
  only:
    - master
  script:
    - mkdir -p ~/.ssh/
    - echo "$SSH_KEY" > ~/.ssh/id_rsa
    - chmod 600 ~/.ssh/id_rsa
    - git clone --bare ${CI_REPOSITORY_URL} /tmp/project.git
    - rsync -az --delete -e "ssh -o StrictHostKeyChecking=no -i ~/.ssh/id_rsa" /tmp/project.git/ ovh-user@ovh-host:~/project.git/
    #- echo "cd ~/www/ && git fetch && git checkout master && git pull" | ssh -o StrictHostKeyChecking=no -i ~/.ssh/id_rsa ovh-user@ovh-host

Je n’ai pas testé l’image tennox/rsync-ssh-git car nous avons notre propre image de build, l’idée est d’avoir rsync, ssh et git de disponible.

Le script va dans un premier temps ajouter la clé ssh (que nous avons mis en variable d’environnement juste avant) dans le dossier de l’utilisateur et y mets les bons droits.

Ensuite, on clone le projet dans sa totalité avec l’option --bare qui consiste à créer un repository vide sans répertoire de travail. Ce dossier-là est synchronisé avec rsync à l’identique sur le serveur OVH, dans un dossier project.git à côté de notre site en production.

À partir de là, si vous n’avez pas encore déployé votre site en production, vous pouvez simplement vous rendre sur le serveur OVH et faire un git clone de ce dossier :

# Je clone le projet
$ git clone ~/project.git www

Si le projet est déjà existant, c’est un peu plus compliqué, il faut déplacer le .git dans le dossier et faire un “nettoyage” du projet :

# Je clone le projet
$ git clone ~/project.git ~/tmp

# Je déplace le .git dans le dossier www du projet
$ mv ~/tmp/.git ~/www

# Je supprime le dossier tmp qui ne sera plus utile
$ rm -rf ~/tmp

# Je vérifie si mon projet est "nettoie"
$ cd ~/www && git status

Ça se complique si le projet comporte des fichiers non suivis ou modifié, vous allez devoir mettre à jour le repository :

$ git add -p # Sélectionnez ce que vous voulez ajouter ou pas
$ git add mes/nouveaux/fichiers # Ajoutez-y vos nouveaux fichiers
$ git commit -m "Mise à jour de la prod"
$ git push # On push, mais ça va pusher dans ~/monprojet.git
$ git checkout . # je nettoie le reste que je ne souhaite pas garder
$ exit # je sors de OVH
$ rsync -avz ovh-user@ovh-host:~/www /tmp/www # je récupère le projet chez moi
$ cd /tmp/www
$ git remote set-url origin git@urldemonreposurgitlab/monprojet.git
$ git push

Ouf 😅 ! Maintenant que vous avez votre status git “propre”, vous pouvez décommenter la dernière ligne du script du .gitlab-ci qui consiste simplement à aller dans le dossier du projet, et faire le git pull.

De cette façon, nous avons pu remettre cet ancien projet sur un process de déploiement “propre” et moderne, qui va permettre aux équipes de se concentrer sur le code et déployer sans se soucier de ce qui se passe chez OVH 🎉.