alwaysdata vous offre un grand nombre d’accès distants à vos comptes : SSH, FTP, WebDAV… Pourtant, déployer un site ou un service en production manque parfois de souplesse. Alors nous avons pensé à vous.
Oh oui alwaysdata, raconte-nous le déploiement !
Il y a des choses parfois plus simples que d’autres dans nos métiers de développeur·euse·s. Le déploiement ne fait malheureusement pas partie de celles-ci. Entre la livraison en FTP, à l’ancienne ; la copie de fichier en SFTP ; l’application de patch à distance… Il y en a pour tous les goûts et tous les projets.
Une solution comme Heroku l’a bien compris : celui ou celle qui produit le code n’a pas à s’ennuyer avec les problématiques liées au déploiement, mais doit se concentrer sur son métier : produire un code de qualité. Or tout le monde n’a pas la main sur un·e DevOp qui va se charger de mettre en production la dernière version pour vous laisser travailler. Dans ce cas, vous n’avez pas le choix, il va falloir vous en occuper vous-même.
Parce qu’alwaysdata est un hébergement pensé par des développeurs, nous nous sommes interrogés sur la bonne manière de déployer en production. Nous avons dans nos projets un outil d’automatisation des processus de déploiement, mais la priorité va d’abord au support d’autres technos comme HTTP/2.
Alors en attendant, nous avons cherché à vous simplifier la vie. Et tout comme vous, nous préférerions faire nos livraisons en une ligne de commande. On s’est donc penchés sur un déploiement via Git.
Git push. Point.
Voilà donc ce que nous vous proposons, à l’image de services conteneurisés : un simple git push d’une branche de production et c’est réglé.
TL;DR : Si vous souhaitez comprendre la mécanique parce que vous êtes curieux·euse, continuez ici. Si vous souhaitez juste mettre en place le déploiement, vous pouvez directement vous rendre sur le dépôt GitHub alwaysdata/autodeploy-git-hook où un README succinct vous guidera sur la mise en place.
Voyons comment démarrer. Il vous faudra :
- un accès SSH pour les réglages
- votre code versionné avec Git
- connaître les principes des git-hooks (mais ça, on va vous expliquer)
des œufs, de la farine, du lait
Côté serveur
Commençons par créer un dépôt git contenant votre projet sur votre serveur alwaysdata (bien entendu, je vous laisse le soin d’adapter les chemins à votre convenance, rien d’obligatoire) :
1 2 3 | $ ssh mon-compte@ssh-mon-compte.alwaysdata.net $ git init --bare ~/mon-projet.git |
Nous initialisons le dépôt en version bare, c’est-à-dire qu’il ne contient que les fichiers de config et de versioning. Dans notre cas, comme nous ne cherchons à faire que du déploiement, nous n’avons pas besoin de plus.
Ensuite, nous allons créer un script de post-receive. C’est lui qui, comme son nom l’indique, sera appelé lors d’un push vers ce dépôt, avec les références vers la branche poussée. Nous allons nous en servir pour tester la branche (par exemple, une branche nommée production), et déployer le contenu de celle-ci vers le dossier servi par notre instance Apache. Créez donc sur votre serveur un fichier ~/mon-projet.git/hooks/post-receive avec le contenu suivant :
1 2 3 4 5 6 7 8 9 10 11 | #!/bin/bash while read oldrev newrev ref do if [[ $ref = refs/heads/production ]]; then echo "Deploying 'production' branch to production" git --work-tree=$HOME/www/mon-projet --git-dir=$(dirname $PWD) checkout --force production exit 0 fi done |
Nous testons que c’est bien la branche production qui vient d’être poussée, et nous réalisons dans ce cas un checkout vers le dossier ~/www/mon-projet (le chemin que vous avez défini pour votre site dans l’interface d’administration) qui contient les fichiers servis par le serveur HTTP.
N’oubliez pas de rendre le script exécutable avec chmod +x ~/mon-projet.git/hooks/post-receive.
En local
Revenez maintenant dans votre dépôt local sur votre machine de développement. Rendez-vous dans votre projet, et ajoutez le dépôt de déploiement situé sur votre serveur alwaysdata :
1 2 3 | $ cd mon-projet $ git remote add deploy mon-compte@ssh-mon-compte.alwaysdata.net:~/mon-projet.git |
Et voilà ! Il vous suffit maintenant de pousser la branche production vers ce dépôt, et le déploiement sera automatique :
1 2 3 4 5 6 7 8 9 10 11 | $ git push deploy production Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 291 bytes | 291.00 KiB/s, done. Total 3 (delta 1), reused 0 (delta 0) remote: Deploying 'production' branch to production remote: Already on 'production' To mon-compte@ssh-mon-compte.alwaysdata.net:~/mon-projet.git 39949b8..86bd6c7 production -> production |
Désormais, il vous suffit de merge sur votre branche de production la dernière version à déployer, de git push sur le serveur, et le tour est joué !
Oui, mais moi, je ne fais pas que déployer des fichiers statiques
Alors effectivement, nous avons illustré un cas assez simple ici, et nous sommes conscients que vous avez probablement d’autres routines à mettre en place lors d’un déploiement.
Vous pouvez, par exemple, avoir besoin de relancer votre instance Apache pour que les changements soient pris en compte. Dans ce cas, il suffit d’ajouter au hook post-receive la ligne suivante, juste après l’instruction git checkout :
1 2 | curl --basic --user "API_KEY account=ACCOUNT:" --data '' --request POST https://api.alwaysdata.com/v1/site/SITE_ID/restart/ |
Cette requête cURL va appeler l’API d’alwaysdata en utilisant votre clé d’API, nom de compte, et identifiant de site à redémarrer pour relancer le service de façon transparente.
Là encore, rien de plus à faire désormais que de pousser la branche de production.
Encore !
Vous en voulez encore ? Avec plaisir !
Vous avez probablement besoin d’automatiser le processus sur plusieurs sites. Nous avons donc libéré le code source de ce petit hook sur le dépôt GitHub alwaysdata/autodeploy-git-hook. Le script est configurable avec des variables bash en haut du fichier, pour que vous ayez le moins de changements à effectuer.
Nous sommes malgré tout conscients que ce script est encore rudimentaire. Vous avez probablement des migrations à jouer sur vos bases de données, ou des appels à faire pour mettre à jour vos assets statiques lors d’une mise à niveau. N’hésitez pas à nous faire part de vos besoins dans les issues du dépôt, ou à proposer vos pull-requests pour que nous puissions améliorer encore cet outil ensemble.
thanks
Loin de moi l’idée de paraître grognon, mais je suis le seul qui n’arrive pas à lire vos articles à cause de tous les GIFS qu’il y a ?
C’est pas très conforme aux WCAG ça ! ;)
Salut @LM, pas de souci, je comprends aussi la frustration qu’il peut y avoir lors d’une lecture longue. Nous sommes en train de refondre le site, le blog en fera partie, et je mettrai en place à ce moment là de quoi bloquer l’animation des GIF par défaut pour ne pas gêner la lecture :)
C’est parfait …
Le script fonctionne parfaitement
Merci
J’utilisais jusqu’alors un script plus simple avec post-update, je viens de changer pour celui-ci qui a l’avantage de vérifier la branche, cependant j’ai dû remplacer les double crochets par des simple pour qu’il fonctionne. Est-ce que les double crochets fonctionnent pour vous, ou quelque chose a changé depuis ce post ?
@Florian : vous avez raison, c’était incorrect (un « bashism »), et ne fonctionnait que lorsque sh était bash (ce qui n’est pas le cas sur nos serveurs : sh est dash). J’ai remplacé par les crochets simples dans l’article.
Ok super, merci pour le retour.
Et surtout merci pour tous ces articles de blog super intéressants !!
Oh oui, j’aime l’humour à base de GIF mais pouvoir les mettre en pause !
Oh oui, le déploiement automatisé, le genre de chose qui m’avait fait partir pour tenter un truc à base de Docker de mon côté !
Oh oui pour toutes ces nouveautés depuis des mois ! <3
Bonjour. On comprend pas bien ce qui est écrit.
git init –bare ~/mon-projet.git
cannot mkdir /mon-projet.git : Permission denied
@Jean Claude : vous avez bien saisi le ~ (tilde) avant le / ?
Oui, j’ai bien écrit le tilde.
Ce n’est pas une question de mauvais chemin, mais de droits.
@Jean Claude : ouvrez un ticket de support, depuis l’administration alwaysdata, pour qu’on investigue.
C’est bon, j’ai résolu le problème, au lieu de taper la commande git init –bare, qui fait fi des droits, il faut faire une commande git init –shared=« droitsqu’onveut » –bare (exemple : git init –shared=0777 –bare).
Sinon dans le fichier post-receive, la partie :
HOME/www/mon-projet , c’est le chemin de notre projet sur notre pc?, ou bien c’est HOME/www/mon-projet, qu’il faut écrire littéralement ?
C’est le chemin de votre site, sur votre compte alwaysdata. $HOME/www/mon-projet est un exemple, vous pouvez mettre ce que vous voulez, c’est vous qui organisez vos fichiers comme vous l’entendez.
error : le spécificateur de référence source production ne correspond à aucune référence
Ah donc, le $HOME/WWW/Monprojet c’est pas l’adresse du projet sur l’ordinateur, ni l’adresse du projet git, mais l’adresse alouées au projet sur le serveur ?
Comment on configure l’adresse allouée sur le serveur Alwaysdata, svp ?
Visiblement, c’est le serveur le plus compliqué à utiliser que je connaisse.
En ajoutant un site.
« Créez donc sur votre serveur un fichier ~/mon-projet.git/hooks/post-receive »
On créé sur le serveur Alwaysdata ?
Comment on créé un fichier sur le serveur Alwaysdata ?
Oui, sur votre compte alwaysdata. Vous créez un fichier par exemple en SSH.
Est-ce que vous pourriez donner un exemple par hasard ?
(pour qu’on voit bien votre façon de faire?)
Visiblement il faudrait créer un fichier appelé post-receive sur le serveur Alwaysdata, en ligne de commande, dans un dossier hook qui n’existe pas, (donc qu’il faut créer à la racine du dossier qu’on a créé, on imagine, vu que rien n’est précisé). Donc ce serait bien d’indiquer qu’il faut créer le dossier hook et comment vous avez fait.
La branche production n’existe pas non plus, donc il faut la créer.
Puis essayer de pousser à partir de la branche production qu’on a créé, par rapport à un dossier hook qu’on a aussi créé sur le serveur directement, enfin d’après ce que j’ai compris de ce que vous avez mentionné.
Mais c’est toujours pas clair.
Comment créer un fichier ou un répertoire sort du cadre de cet article : ce sont des compétences Linux de base qui n’ont rien de spécifique à alwaysdata. Vous pouvez le faire en SSH (ligne de commandes) ou par FTP, SFTP ou WebDAV par exemple.
salut je rencontre un problème de mon côté. lorsque je fais un « git push deploy production » j’obtiens l’erreur
remote : fatal : not a git repository : “/home/metahub”
je suppose que l’erreur vient de l’appel du $HOME dans le fichier post-receive
merci d’avance.
je rencontre un problème lorsque je fais un git push deploy production :
remote : fatal : not a git repository : “/home/metahub”
Cette erreur est effectivement retournée par Git probablement parce qu’il ne trouve pas le bon bare repository dans votre script de déploiement. Essayez de définir la valeur de l’option
--git-dirau chemin complet vers votre répertoire.git.N’hésitez pas à nous contacter par ticket quand vous rencontrez ce genre de problème pour que nous puissions vous aider directement :)
pour ceux qui ont du mal voici les étapes détaillé :
//connexion
$ ssh mon-compte@ssh-mon-compte.alwaysdata.net
//
$ git init --bare ~/mon-projet.git
// créer une branche 'production' ou renommer une branche existante
// mettez vous sur la branche 'production'
$ git checkout production
// script à exécuter d'abord puis à copier dans votre fichier post-receive
#!/bin/bash
while read oldrev newrev ref
do
if [[ $ref = refs/heads/production ]];
then
echo "Deploying 'production' branch to production"
git --work-tree=/home/mon-compte/www --git-dir=/home/mon-compte/mon-projet.git checkout --force production
exit 0
fi
done
// connecter le git au serveur
$ git remote add deploy mon-compte@ssh-mon-compte.alwaysdata.net:~/mon-projet.git
// creation de ficher post-receive
$ touch ~/mon-projet.git/hooks/post-receive
//autoriser l'execution
$ chmod +x ~/mon-projet.git/hooks/post-receive
// verif que le fichier soit executable
$ ls -l ~/mon-projet.git/hooks/post-receive
//déployer sur le serveur
$ git push deploy production
> mars 6, 2018 à 09:01 – m4dz says :
> Salut @LM, pas de souci, je comprends aussi la frustration qu’il peut y avoir lors d’une lecture longue. Nous sommes en train de refondre le site, le blog en fera partie, et je mettrai en place à ce moment là de quoi bloquer l’animation des GIF par défaut pour ne pas gêner la lecture :)
Salut @m4dz et @alwaysdata,
dommage que ça n’ait pas été pris en compte.
Je retombe sur cet article pour le citer en réf, et ces GIF sont toujours aussi insupportables.
Merci quand même pour le principal (l’info technique) :)