Dans cet article on va essayer de créer un petit script de déploiement qui pourra être adapté à n’importe quel projet et qui, si tu l’utilises bien te poussera naturellement à fouiner du coté du DevOps et plus particulièrement de la Livraison continue et du Déploiement continu.
Pour ça, voila de quoi on aura besoin :
- De Git (ou autre tant que ça fait le taff).
- D’un serveur web (spoiler).
- Pouvoir se connecter en SSH sur ce serveur.
Petit disclaimer tout de même, cet article ne s’adresse évidement pas à toute personne ayant déjà une bonne connaissance des enjeux DevOps. Je ne suis qu’un dev junior qui partage son approche légère et progressive de cette méthodologie à d’autres juniors. D’ailleurs tout cela n’est que de la vulgarisation, au yeux d’un avisé, il y aura sans doute beaucoup d’erreurs mais j’essaie simplement de trouver les mots juste pour faire passer un message, ce n’est pas toujours simple 😉
Le Shell ? Kecekecé ?
Avant tout, il faut impérativement essayer de comprendre les outils qu’on va utiliser, et le principal c’est évidement les Scripts Shell 😱. Pour t’expliquer ça je pourrais évidement simplement citer la définition Wikipédia mais d’une ; on comprend rien à ce qu’ils racontent là bas. Et de deux ; on s’en fou un peu de la définition académique.
Donc nous on va faire dans la simplicité 😎
Shell c’est un langage de script, donc un langage de programmation, qui doit être interprété, jusque la on est ok, on connait. Mais la particularité des langages de script c’est qu’ils permettent d’automatiser une succession de commandes simples (entre autres hein).
On peut donc imaginer des scripts pour tout, mais ici on va s’en servir pour coordonner et exécuter différentes commandes qui vont aboutir au déploiement de notre projet.
Git & SSH
Là c’est la début de la fin. C’est quand on commence à entendre parler de connexions SSH, de clés SSH privées ou publiques, de RSA et autre fingerprint qu’on se dit qu’on a surement quelque chose de plus constructif à faire que de lire un article ou un tuto.
Et tu n’as pas tort, mais bon c’est une étape indispensable, évidement j’espère que tes projets sont déjà gérés avec Git (ou un autre gestionnaire de versions). Si non… QU’ATTENDS-TU ?
Outre cela, tu vas aussi devoir configurer ton serveur web pour pouvoir te connecter en SSH :
$ ssh user@000.00.000.000 -p 00
Techniquement, il même possible de ne pas avoir à trifouiller des clés SSH, du moins pour le moment, tu te rendras vite compte que c’est quand même super pratique.
Partons du principe que tu as tout ça, ton projet est sur GitHub, ton serveur te permet de te connecter en SSH et toi tu continues de lire cet article alors qu’il n’y a pas eu une ligne de commande en 5 minutes.
Codons un peu
Mais pas tout de suite.
On va prendre pour exemple un répo GitHub qu’on va appeler “simple_test_repo” .
Commençons par se connecter à notre super serveur.
$ ssh user@000.00.000.000 -p 00
D’ici, allons dans notre répertoire “srv"
$ cd /srv
Maintenant nous allons créer un nouveau répertoire qu’on va appeler “src” pour les “sources”. C’est ici que notre répo git sera cloné. Ça va nous permettre de bien séparer ce qui concerne Git et la version en ligne du projet. On se donne les droits sur ce répertoire et on se rend à l’intérieur.
$ sudo mkdir src
$ sudo chown user:user src
$ cd src
A présent, on peut cloner ici notre projet (on ne configure pas encore les fichiers d’environnement du projet)
$ git clone https://github.com/user/simple_test_repo.git
On fait évidemment un petit “ls” pour vérifier que tout va bien. Et ensuite, on crée de nouveau un répertoire, cette fois-ci nommé “script” et on se rend dedans :
$ sudo mkdir scripts
$ cd scripts
Ok, maintenant on a toute notre infrastructure pour commencer nos scripts et goupiller tout ça.
Prêt pour créer ton script ? Ok let’s go 🚀
$ nano pull_and_deploy_website.sh
Maintenant il faut écrire ton script, voilà ce qu’on va mettre dedans :
!#/bin/bash -eu
cd /srv/src/simple_test_repo
git pull origin master
rsync -r . /var/www/html --exclude .git
Voilà ce que tout ça veut dire :
On commence simplement par dire à Unix qu’on va utiliser Bash, le -eu est en quelque sorte le mode strict de bash (merci à la personne qui m’a dit de le rajouter)
Ensuite on se rend dans le répertoire ou notre projet est cloné
On récupère les différentes modifications qui ont été faites
On copie uniquement les fichiers qui ont été modifiés dans le répertoire www du serveur web en excluant le dossier .git
Il y a plein de façons d’optimiser ces commandes, par exemple il est possible d’utiliser “rsync -aC” pour conserver les liens symboliques et ignorer par défaut certains fichiers. Mais on va rester dans la simplicité pour ce script là.
Pour finir on règle les permissions de ce script :
$ chmod +x pull_and_deploy_website.sh
A présent tu peux configurer les fichiers d’environnement de ton projet.
L’intérêt de tout ça, c’est de séparer proprement les fichiers qui proviennent de ton gestionnaire de versions et tes fichiers qui seront possiblement accessibles par l’utilisateur, ça offre une couche de sécurité en plus et cela t’oblige à prendre en compte ton infrastructure.
De plus pour déployer il ne te suffit plus que d’une seule ligne (après t’être connecté en SSH)
$ srv/src/scripts/pull_and_deploy_website.sh
Tu as maintenant deux copies de ton projet sur ton serveur, une directement reliée à Github avec une remote récupérant les différentes mises à jour, et une, en ligne, que tu peux mettre à jour en une seule ligne de commande, le tout de façon sécurisée.
Tu peux aussi personnaliser ton script, en créer pour plusieurs projets, y rajouter des messages de succès, pourquoi pas essayer d’y intégrer des builds, ou des tests ? Mais, tu te rendra vite compte que tu es limité… (enfin pas toi, le script)
Conclusion
Si tu as bien lu et que tu as essayé ce script en le modifiant à ta sauce, tu as sûrement compris le potentiel de ce genre de méthodes…
Et bien félicitation, tu viens de créer ta première pipeline, simple, basique (vous n'avez pas les bases), archaïque même, mais c'est une pipeline. Et si tu as compris les enjeux et objectifs de ce script, alors tu as compris ceux de la méthodologie DevOps: automatisation, sécurité et performance.
Mais du coup, comment faire pour que cela deviennent une vraie pipeline ? Et bien en fait là, on exécute à proprement parler qu'une seule tache, et pour que cela soit une vraie pipeline il en faudrait plusieurs déjà. Le minimum serait en premier lieu d'ajouter des tests, unitaires par exemple.
Ce qu'il te faut comprendre avec le CI/CD c'est les principes d'automatisation et de non régression. Pour que ton code reste fonctionnel, et que tes nouvelles fonctionnalités n'entrent pas en conflit avec les anciennes, ta pipeline doit avoir un déclencheur, un push ou un merge sur master par exemple. Ensuite et seulement ensuite une série de taches sera effectuées automatiquement à partir de ta pipeline, le plus courant étant :
Build ➡️ Test ➡️ Déploiement
Pour faire simple, une pipeline se comportera comme ton script, mais à grande échelle.
Et c'est ici qu'entre en jeu les différents outils de CI/CD, ils t'offriront un environnement pour tes pipelines, une interface graphique et des documentations indispensables. De plus ils te permettront d'affiner tes possibilités en ajoutant du Coverage, du Code Legacy et plein d'autre joyeusetés 😊
À présent, n'hésites pas à te renseigner sur ces différents outils (Gitlab CI, CircleCI, Jenkins, Travis et GitHub Action), à coder tes premiers tests unitaires, à réfléchir à différentes pipelines pour différents besoins et à te lancer dans le merveilleux monde du DevOps.
Tu peux trouver le code source de cet article ici !
Merci beaucoup à toi d’avoir lu jusqu’ici, je le répète je suis un dev junior et j’essaie de rendre le propos le plus simple possible, je suis loin d’être un grand développeur. Je suis conscient que la méthode présentée dans cet article paraîtra absurde et inutile à beaucoup de personne, mais moi, elle m’a aidé à mieux cerner certains enjeux et il me semblait important de la partager.
J’espère que cet article t'aura tout de même intéressé et je reviendrais très bientôt avec d’autres sujets 😉
Top comments (0)