Comment déployer plusieurs applications PHP à l’aide d’Ansible sur Ubuntu 14.04

Ce tutoriel est le troisième d’une série sur le déploiement d’applications PHP à l’aide de Ansible sur Ubuntu 14.04. Le first tutorial couvre les étapes de base du déploiement une application; Le https://www.digitalocean.com/community/tutorials/how-to-deploy-an-advanced-php-application-using-ansible-on-ubuntu-14-04 [deuxième tutoriel] couvre des sujets plus avancés tels que bases de données, démons de file d’attente et planificateurs de tâches (crons).

Dans ce didacticiel, nous allons construire sur ce que nous avons appris dans les didacticiels précédents en transformant notre playbook Ansible à application unique en un livret de jeu prenant en charge le déploiement de plusieurs applications PHP sur un ou plusieurs serveurs. C’est la dernière pièce du puzzle en matière d’utilisation d’Ansible pour déployer vos applications avec un minimum d’effort.

Nous allons utiliser quelques applications simples Lumen dans le cadre de nos exemples. Cependant, ces instructions peuvent être facilement modifiées pour prendre en charge d’autres frameworks et applications si vous en possédez déjà. Il est recommandé d’utiliser les exemples d’applications jusqu’à ce que vous soyez prêt à modifier le livret.

Pour suivre ce tutoriel, vous aurez besoin de:

Lignes à ajouter n’importe où dans / etc / hosts

Les exemples de sites Web que nous allons utiliser dans ce didacticiel sont + laravel.example.com +, + one.example.com + et + two.example.com +. Si vous souhaitez utiliser votre propre domaine, vous devez mettre à jour votre https://www.digitalocean.com/community/tutorials/how-to-set-up-and-test-dns-subdomains-with-digitalocean- s-dns-panel # final-configuration [enregistrements DNS actifs] à la place.

Dans cette étape, nous allons configurer des variables de playbook pour définir nos nouvelles applications.

Dans les tutoriels précédents, nous avons codé en dur toutes les spécificités de la configuration, ce qui est normal pour de nombreux playbooks exécutant des tâches spécifiques pour une application spécifique. Toutefois, lorsque vous souhaitez prendre en charge plusieurs applications ou élargir la portée de votre playbook, il n’a plus de sens de tout coder en dur.

Comme nous l’avons vu précédemment, Ansible fournit des variables que vous pouvez utiliser à la fois dans vos définitions de tâches et dans vos modèles de fichiers. Ce que nous n’avons pas encore vu, c’est comment définir manuellement des variables. Dans la partie supérieure de votre classeur, vous pouvez définir un paramètre + vars + et définir vos variables à cet endroit.

Si vous ne l’avez pas déjà fait, changez les répertoires en "+ ansible-php +" à partir des tutoriels précédents.

Ouvrez notre livre de jeu existant pour le modifier.

Le haut du fichier devrait ressembler à ceci:

Haut de php.yml original

Pour définir des variables, nous pouvons simplement ajouter une section + vars + dans, à côté de + hôtes +, + sudo + et + tâches +. Pour que les choses restent simples, commençons par une variable très basique pour le nom d’utilisateur + www-data +, comme suit:

Vars mis à jour dans php.yml

Ensuite, parcourez et mettez à jour toutes les occurrences de l’utilisateur + www-data avec la nouvelle variable` + {{www user}} + `. Ce format devrait être familier, car nous l’avons utilisé dans les apparences et pour les recherches.

Pour rechercher et remplacer à l’aide de nano, appuyez sur + CTRL + \ +. Une invite s’affiche: * Rechercher (à remplacer): *. Tapez * www-data *, puis appuyez sur + ENTER. L’invite changera en * Remplacer par: *. Ici, tapez * \ {\ {www user}} * et appuyez à nouveau sur + ENTER. Nano vous guidera à travers chaque instance de + www-data et demandera * Remplacer cette instance? *. Vous pouvez appuyer sur + y + pour remplacer chacun par un ou sur + a + pour tout remplacer.

Avant d’aller plus loin, il convient de faire attention aux variables. Normalement, nous pouvons simplement les ajouter comme ceci, quand ils sont dans une ligne plus longue:

Exemple de tâche dans php.yml

Toutefois, si la variable est la seule valeur de la chaîne, nous devons l’envelopper entre guillemets pour que l’analyseur YAML puisse la comprendre correctement:

Mise à jour de la tâche dans php.yml

Dans votre playbook, cela doit se produire chaque fois que vous avez + sudo_user: {{wwwuser}} +. Vous pouvez utiliser une recherche globale et remplacer de la même manière, en remplaçant * sudo_user: \ {\ {wwwuser}} * par * sudo_user: “\ {\ {wwwuser}}” *. Il devrait y avoir quatre lignes qui ont besoin de ce changement.

Une fois que vous avez changé toutes les occurrences, sauvegardez et lancez le livre de lecture:

Il ne devrait y avoir aucune tâche modifiée, ce qui signifie que notre variable + wwwuser + fonctionne correctement.

Dans cette section, nous examinerons les variables d’imbrication pour les options de configuration complexes.

Dans l’étape précédente, nous avons défini une variable de base. Cependant, il est également possible d’imbriquer des variables et de définir des listes de variables. Ceci fournit la fonctionnalité nécessaire pour définir la liste des sites que nous souhaitons configurer sur notre serveur.

Tout d’abord, considérons le dépôt git existant que nous avons mis en place dans notre playbook:

Tâche git existante dans php.yml

Nous pouvons extraire les informations utiles suivantes: nom (répertoire), référentiel, branche et domaine. Comme nous configurons plusieurs applications, nous aurons également besoin d’un nom de domaine pour pouvoir répondre. Ici, nous utiliserons + laravel.example.com +, mais si vous avez votre propre domaine, vous pouvez le remplacer.

Cela donne les quatre variables suivantes que nous pouvons définir pour cette application:

Variables d’application

Maintenant, ouvrez votre livre de jeu pour l’édition:

Dans la section supérieure + vars, nous pouvons ajouter dans votre application une nouvelle liste d’applications:

Mise à jour des variables d’applications dans php.yml

Si vous lancez votre playbook maintenant (en utilisant + ansible-playbook php.yml --ask-sudo-pass +), rien ne changera car nous n’avons pas encore configuré nos tâches pour utiliser notre nouvelle variable + applications +. Toutefois, si vous accédez à «+ http: // laravel.example.com / +» dans votre navigateur, notre application d’origine devrait s’afficher.

Dans cette section, nous allons apprendre à parcourir des listes de variables dans des tâches.

Comme mentionné précédemment, les listes de variables doivent être bouclées dans chaque tâche pour laquelle nous souhaitons les utiliser. Comme nous l’avons vu avec la tâche + install packages +, nous devons définir une boucle d’éléments, puis appliquer la tâche à chaque élément de la liste.

Ouvrez votre playbook pour le modifier:

Nous allons commencer par quelques tâches faciles. Au milieu de votre livre de jeu, vous devriez trouver ces deux tâches + env +:

Tâches env existantes dans php.yml

Vous remarquerez qu’ils sont actuellement codés en dur avec le répertoire + laravel +. Nous voulons le mettre à jour pour utiliser la propriété + name + pour chaque application. Pour ce faire, nous ajoutons l’option + with_items + pour parcourir notre liste + applications +. Dans la tâche elle-même, nous échangerons la référence + laravel + pour la variable + {{item.name}} +, qui devrait être familière des formats que nous avons utilisés auparavant.

Ça devrait ressembler à ça:

Mise à jour des tâches .env dans php.yml

Ensuite, passez aux deux tâches cron artisanales de Laravel. Elles peuvent être mises à jour exactement comme nous venons de le faire avec les tâches + env +. Nous ajouterons également les éléments + item.name + au paramètre + name + pour les entrées cron, car Ansible utilise ce champ pour identifier chaque entrée cron de manière unique. Si nous les laissions tels quels, nous ne pourrions pas avoir plusieurs sites sur le même serveur, car ils écraseraient constamment chacun d’eux et seul le dernier serait sauvegardé.

Les tâches doivent ressembler à ceci:

Mise à jour des tâches cron dans php.yml

Si vous sauvegardez et lancez le playbook maintenant (en utilisant + ansible-playbook php.yml --ask-sudo-pass +), vous ne devriez voir que les deux tâches + cron + mises à jour. Cela est dû au changement du paramètre + name +. En dehors de cela, il n’y a eu aucun changement, ce qui signifie que notre liste d’applications fonctionne comme prévu et que nous n’avons encore apporté aucune modification à notre serveur à la suite de la refactorisation de notre playbook.

Dans cette section, nous verrons comment utiliser les variables en boucle dans les modèles.

La mise en boucle des variables dans les modèles est très simple. Ils peuvent être utilisés exactement de la même manière que dans les tâches, comme toutes les autres variables. La complexité intervient lorsque vous considérez les chemins d’accès aux fichiers ainsi que les variables, comme dans certaines utilisations, nous devons prendre en compte le nom du fichier et même exécuter d’autres commandes en raison du nouveau fichier.

Dans le cas de Nginx, nous devons créer un nouveau fichier de configuration pour chaque application et indiquer à Nginx qu’il doit être activé. Nous souhaitons également supprimer notre fichier de configuration original + / etc / nginx / sites-available / default + dans le processus.

Commencez par ouvrir votre Playbook pour l’éditer:

Recherchez la tâche + Configure Nginx (au milieu du livre de lecture) et mettez-la à jour comme nous l’avons fait avec les autres tâches:

Mise à jour de la tâche nginx dans php.yml

Pendant que nous sommes ici, nous ajouterons également deux tâches supplémentaires mentionnées ci-dessus. Tout d’abord, nous allons parler à Nginx de notre nouveau fichier de configuration de site. Cela se fait avec un lien symbolique entre les répertoires + sites-available + et + sites-enabled + dans + / var / nginx / +.

Ajoutez cette tâche après la tâche + Configure nginx +:

Nouvelle tâche de lien symbolique dans php.yml

Ensuite, nous voulons supprimer le fichier de configuration de site activé + default + afin qu’il ne pose pas de problème avec nos nouveaux fichiers de configuration de site. Cela se fait facilement avec le module + fichier +:

Nouvelle tâche de fichier php.yml

Notez que nous n’avions pas besoin de boucler + applications +, nous recherchions un fichier unique.

Le bloc Nginx dans votre playbook devrait maintenant ressembler à ceci:

Mise à jour des tâches nginx dans php.yml

Enregistrez votre playbook et ouvrez le fichier + nginx.conf pour le modifier:

Mettez à jour le fichier de configuration pour qu’il utilise nos variables:

Mise à jour de nginx.conf

Cependant, nous n’avons pas encore fini. Notez le + default_server + en haut? Nous voulons uniquement inclure cela pour l’application + laravel, pour en faire la valeur par défaut. Pour ce faire, nous pouvons utiliser une instruction IF de base pour vérifier si + item.name est égal à` + laravel` et, le cas échéant, affiche + default_server.

Il ressemblera à ceci:

Mise à jour de nginx.conf avec les conditions

Mettez à jour votre + nginx.conf + en conséquence et enregistrez-le.

Maintenant il est temps de lancer notre playbook:

Vous devriez remarquer que les tâches Nginx ont été marquées comme modifiées. Une fois l’exécution terminée, actualisez le site dans votre navigateur. Il devrait afficher la même chose qu’à la fin du dernier tutoriel:

http://laravel.example.com/

Dans cette étape, nous allons boucler plusieurs variables ensemble dans des tâches.

Il est maintenant temps de s’attaquer à un exemple de boucle plus complexe, à savoir les variables enregistrées. Afin de prendre en charge différents états et d’empêcher les tâches de s’exécuter inutilement, vous vous souviendrez que nous avons utilisé + register: cloned + dans notre tâche Clone git repository pour enregistrer la variable + cloned + avec l’état de la tâche. Nous avons ensuite utilisé quand: cloné | changé + dans les tâches suivantes pour déclencher des tâches de manière conditionnelle. Nous devons maintenant mettre à jour ces références pour prendre en charge la boucle d’applications.

Commencez par ouvrir votre Playbook pour l’éditer:

Recherchez la tâche Clone git repository:

Tâche git existante dans php.yml

Comme nous enregistrons la variable dans cette tâche, nous n’avons pas besoin de faire ce que nous n’avons pas déjà fait:

Mise à jour de la tâche git dans php.yml

Maintenant, descendez votre playbook jusqu’à trouver la tâche + composer create-project:

Compositeur original dans php.yml

Maintenant, nous devons le mettre à jour pour parcourir * * * + + applications + et + clonées +. Ceci est fait en utilisant l’option + with_together et en passant à la fois` + applications` et + cloné. Comme + with_together parcourent deux variables, l’accès aux éléments se fait avec` + item. # + , Où + # + `est l’index de la variable telle qu’elle est définie. Donc par exemple:

+ item.0 + fera référence à + ​​list_one +, et + item.1 + fera référence à + ​​list_two +.

Ce qui signifie que pour + applications, nous pouvons accéder aux propriétés via:` + item.0.name`. Pour + cloned +, nous devons transmettre les résultats des tâches, accessibles via + cloned.results +, puis nous pourrons vérifier s’ils ont été modifiés via + item.1.changed +.

Cela signifie que la tâche devient:

Mise à jour de la tâche de composition dans php.yml

Maintenant, enregistrez et lancez votre playbook:

Il ne devrait y avoir aucun changement de cette exécution. Cependant, nous avons maintenant une variable enregistrée qui fonctionne bien dans une boucle.

Dans cette section, nous étudierons des variables et des boucles enregistrées plus complexes.

La partie la plus compliquée de la conversion est la gestion de la variable enregistrée que nous utilisons pour la génération de mots de passe pour notre base de données MySQL. Cela dit, nous n’avons pas grand-chose de plus à faire dans cette étape que nous n’avons pas couverte, il nous suffit de mettre à jour plusieurs tâches à la fois.

Ouvrez votre livre de jeu pour le modifier:

Trouvez les tâches MySQL, et dans notre premier passage, nous ajouterons simplement les variables de base, comme nous l’avons fait dans les tâches précédentes:

Mise à jour des tâches MySQL dans php.yml

Ensuite, nous ajouterons + with_together + pour pouvoir utiliser notre mot de passe de base de données. Pour notre génération de mot de passe, nous devons boucler sur + db pwd.results, et nous pourrons accéder au mot de passe à partir de` + item.1.stdout`, puisque + applications sera accessible via` + item.0 + `.

Nous pouvons mettre à jour notre playbook en conséquence:

Mise à jour des tâches MySQL dans php.yml

Une fois que vous avez mis à jour votre playbook, enregistrez-le et exécutez-le:

Malgré tous les changements que nous avons apportés à notre livre de jeu, aucune modification ne devrait être apportée aux tâches de la base de données. Avec les modifications apportées à cette étape, nous aurions dû terminer notre conversion d’un livre de lecture à application unique en un livre de lecture à applications multiples.

Dans cette étape, nous allons configurer deux autres applications dans notre playbook.

Maintenant que nous avons repensé notre playbook pour utiliser des variables pour définir les applications, le processus d’ajout de nouvelles applications sur notre serveur est très simple. Ajoutez-les simplement à la liste de variables + applications +. C’est là que la puissance des variables Ansible va vraiment briller.

Ouvrez votre livre de jeu pour le modifier:

En haut, dans la section + vars +, trouvez le bloc + applications +:

Variable des applications existantes dans php.yml

Ajoutez maintenant deux autres applications:

Mise à jour de la variable d’applications dans php.yml

Enregistrez votre playbook.

Maintenant il est temps de lancer votre playbook:

Cette étape peut prendre un certain temps lorsque le compositeur configure les nouvelles applications. Une fois l’opération terminée, vous remarquerez qu’un certain nombre de tâches ont été modifiées et si vous regardez bien, vous remarquerez que chacun des éléments en boucle sera répertorié. La première, notre application originale devrait dire + ok + ou + sauté +, tandis que les deux nouvelles applications devraient dire + changé +.

Plus important encore, si vous visitez les trois domaines de vos sites configurés dans votre navigateur Web, vous devriez remarquer trois sites Web différents.

Le premier devrait avoir l’air familier. Les deux autres doivent afficher:

http://one.example.com/

and

http://two.example.com/

Avec cela, nous venons de déployer deux nouvelles applications Web en mettant simplement à jour notre liste d’applications.

Dans cette étape, nous allons extraire nos variables pour héberger des variables.

En prenant du recul, les variables de livre de lecture sont bonnes, mais que faire si nous voulons déployer différentes applications sur différents serveurs en utilisant le même livre de lecture? Nous pourrions effectuer des vérifications conditionnelles sur chaque tâche pour déterminer le serveur qui l’exécute, ou nous pouvons utiliser host variables. Les variables hôte ressemblent à ce qu’elles ressemblent: des variables qui s’appliquent à un hôte spécifique, plutôt qu’à tous les hôtes d’un livre de jeu.

Les variables d’hôte peuvent être définies inline, dans le fichier + hosts +, comme nous l’avons fait avec la variable + ansible_ssh_user +, ou elles peuvent être définies dans un fichier dédié pour chaque hôte situé dans le répertoire + host_vars +.

Tout d’abord, créez un nouveau répertoire avec notre fichier + hosts + et notre playbook. Appelez le répertoire + host_vars +:

Ensuite, nous devons créer un fichier pour notre hôte. La convention utilisée par Ansible est que le nom du fichier corresponde à celui de l’hôte dans le fichier + hosts +. Ainsi, par exemple, si votre fichier + hosts + ressemble à ceci:

Fichier d’hôtes Ansible

Ensuite, vous devriez créer un fichier nommé + host_vars / your_first_server_ip +. Créons cela maintenant:

Comme nos playbooks, les fichiers hôtes utilisent YAML pour leur formatage. Cela signifie que nous pouvons copier votre liste + applications dans notre nouveau fichier hôte. Elle ressemble donc à ceci:

Nouveau fichier host_vars / your_first_server_ip

Enregistrez votre nouveau fichier hosts et ouvrez votre playbook pour le modifier:

Mettez à jour le haut pour supprimer toute la section + applications +:

Haut de la page mis à jour php.yml

Enregistrez le livre de lecture et lancez-le:

Même si nous avons déplacé nos variables de notre livre de jeu vers notre fichier hôte, le résultat devrait être exactement le même et aucun changement ne devrait être signalé par Ansible. Comme vous pouvez le constater, + host_vars + fonctionnent exactement de la même manière que + vars + dans les playbooks; ils sont juste spécifiques à l’hôte.

Les variables définies dans les fichiers + host_vars + seront également accessibles dans tous les playbooks gérant le serveur, ce qui est utile pour les options et les paramètres courants. Cependant, veillez à ne pas utiliser un nom commun qui pourrait signifier différentes choses selon les playbooks.

Dans cette étape, nous utiliserons nos nouveaux fichiers hôtes et déploierons des applications sur un second serveur.

Premièrement, nous devons mettre à jour votre fichier + hosts avec notre nouvel hôte. Ouvrez-le pour l’édition:

Et ajoutez dans votre nouvel hôte:

Fichier d’hôtes Ansible

Enregistrez et fermez le fichier.

Ensuite, nous devons créer un nouveau fichier hôtes, comme nous l’avons fait avec le premier.

Vous pouvez choisir une ou plusieurs de nos applications et les ajouter à votre fichier hôte. Par exemple, si vous souhaitez déployer notre exemple d’origine et les exemples deux sur le nouveau serveur, vous pouvez utiliser:

Nouveau fichier host_vars / your_second_server_ip

Enregistrez votre playbook.

Enfin, nous pouvons lancer notre playbook:

Ansible mettra un certain temps à s’exécuter car il configure tout sur votre deuxième serveur. Lorsque cela est terminé, ouvrez les applications de votre choix dans votre navigateur (dans l’exemple, nous avons utilisé + laravel.example2.com + + two.example2.com +) et confirmer qu’elles ont été configurées correctement. Vous devriez voir les applications spécifiques que vous avez choisies pour votre fichier hôte et votre serveur d’origine ne devrait pas être modifié.

Ce tutoriel prenait un livre de jeu entièrement fonctionnel pour une seule application et le convertissait pour prendre en charge plusieurs applications sur plusieurs serveurs. Combiné aux sujets abordés dans les tutoriels précédents, vous devriez avoir tout ce dont vous avez besoin pour écrire un livre de lecture complet pour le déploiement de vos applications. Comme dans les didacticiels précédents, nous ne sommes toujours pas connectés directement aux serveurs à l’aide de SSH.

Vous aurez remarqué à quel point il était simple d’ajouter plus d’applications et un autre serveur, une fois que nous avions défini la structure du livre de jeu. C’est la puissance de Ansible, et c’est ce qui le rend si flexible et facile à utiliser.