DEVOPS Chaîne de déploiement

DEVOPS Chaîne de déploiement

L’utilisateur d’une entreprise veut développer sa propre version d’un logiciel open-source en html/php disponible sur une forge distante (http://gogs.univ-rouen.fr Comme notre développeur n’est pas particulièrement compétent en administration système, il doit faire souvent faire appel à l’équipe du même nom afin de déployer et tester en ligne les dernières modifications qu’il a faites sur le code de son application. Fatigués par les problèmes de compatibilité entre applications sur les serveurs de production, et fatigués aussi par les échanges permanents de codes sources entre les équipes, les responsables décident de mettre en place un nouveau système de déploiement basé sur des containers Docker. Notre développeur est à présent contraint de construire une image capable de servir son application, de la transmettre à un registry privé, pour que les administrateurs système puissent déployer la nouvelle application. Le développeur grogne !#?! de devoir ainsi penser en amont l’architecture nécessaire au fonctionnement de son programme… Mais très vite il s’aperçoit que cet effort vaut la peine ETAPE 2, les dockerfiles En discutant à table avec un de ses collègues, notre développeur se rend compte qu’il existe un moyen d’automatiser à la fois la construction de l’image mais également son inscription dans la registry privé, et cela à chaque fois qu’il change le code ETAPE 3, les webhooks et jenkins Enfin, notre développeur doit encore faire une étape manuelle en rappatriant la nouvelle image envoyée sur la registry sur la vm utilisateur qui présente le service web. Une façon d’automatiser cette étape est de la déléguer à Jenkins, qui se connecte (en ssh) à chaque fin de build réussi à la VM Utilisateur, et passe les commandes de mise à jour et de déploiement de l’image ETAPE 4, automatiser le déploiement de l’image via Jenkins et SSH.

Les jours passent, et l’application de notre développeur se complexifie toujours un peu plus, et nécessite plusieurs services (php, base de données, etc.). ETAPE 5, complexifier le docker-compose. Et enfin, il est possible de solidifier l’infrastructure, en mettant en place des checks de santé (health check), un cluster de nœuds Docker (Swarm), et autres outils notamment de visualisation (Portainer). ETAPE 6, pour aller plus loin Pour ne pas partir de rien, nous allons créer un nouveau projet à partir d’un template que nous avons déposé à l’adresse suivante : http://gogs.univ-rouen.fr/devops2018/moulticolor (http://gogs.univ-rouen.fr/devops2018/moulticolor) Nous allons ensuite cloner ce dépôt sur notre machine virtuelle cliente. Pour cela, à la racine de votre home, nous allons créer un répertoire repository qui contiendra le clone de ce projet. Vous pouvez copier coller l’url qui apparait sur votre page. Maintenant nous allons faire des modifications sur ce dépot local, les valider et les renvoyer sur le serveur distant. À la racine du dépot venant d’être créé, nous allons modifier le fichier README.md pour y ajouter notre nom et notre prénom. Entrer le commentaire du commit, par exemple “Modification du fichier README, ajout du prénom et du nom du propriétaire”. Faites de nouveau un Ctrl+O, Ctrl+X pour valider le commit.

Nous savons à présent comment modifier et mettre à jour le code source sur la forge logicielle distante depuis notre poste en local. Si l’objectif est de déployer cette page web de façon automatique sur un serveur via un container Docker alors la première étape est d’abord de construire une image qui pourra intégrer et présenter ce code. C’est exactement le but du Dockerfile que nous allons mettre enmoulticolor . Pour afficher le contenu des pages en php nous avons besoin d’un serveur web Nginx, de Php 7 avec le module php-FPM (FastCGI Process Manager).(https://docs.docker.com/develop/develop-images/multistage-build/). Cette fonctionalité permet d’enchaîner plusieurs étapes de build dans un Dockerfile en ne gardant que le dernier container construit. Par exemple, un premier stage compile les sources d’un logiciel, puis le deuxième stage copie le binaire de ce logiciel du premier stage avant d’être publié. Le container final sera beaucoup plus léger car il n’aura pas toutes les dépendances/paquets liés à la compilation !