Developer Advocate
Automatiser la mise en place du serveur avec les matériaux du kit de l’atelier
Ce kit d’atelier est conçu pour aider un public technique à se familiariser avec les concepts de gestion de la configuration et à utiliser Ansible pour automatiser la configuration de l’infrastructure des serveurs.
L’objectif est de fournir un ensemble complet de ressources permettant à un conférencier d’organiser un événement et de présenter un exposé introductif sur Ansible. Il comprend :
Ce tutoriel vise à compléter la démo de la conférence par des détails et des explications supplémentaires. Il sert également de référence pour les lecteurs qui cherchent à déployer une application Laravel sur un serveur Ubuntu distant en utilisant Ansible.
L’automatisation des serveurs joue maintenant un rôle essentiel dans l’administration des systèmes, en raison de la nature disponible des environnements d’application modernes. Les outils de gestion de la configuration tels que Ansible sont généralement utilisés pour rationaliser le processus d’automatisation de la configuration des serveurs en établissant des procédures standard pour les nouveaux serveurs. Cela a l’avantage de réduire l’erreur humaine associée aux réglages manuels.
Ansible offre une architecture simplifiée qui ne nécessite pas l’installation de logiciels spéciaux sur les nœuds. Elle fournit également un ensemble robuste de caractéristiques et de modules intégrés qui facilitent l’écriture de scripts d’automatisation.
Ce tutoriel, conçu pour accompagner les diapositives et les notes de l’orateur pour le kit d’atelier Automatisation de la configuration du serveur avec Ansible vous montrera comment créer un fichier d’inventaire et exécuter un ensemble de scripts d’approvisionnement afin d’automatiser entièrement le processus de mise en place d’un serveur LEMP distant (Linux, (E) Nginx, MariaDB et PHP-FPM) sur Ubuntu 18.04 et de déployer une application Laravel de démonstration sur ce système.
Remarque: Ce matériel est destiné à démontrer comment utiliser des playbooks pour automatiser la configuration des serveurs avec Ansible. Bien que notre démo consiste en une application Laravel fonctionnant sur un serveur LEMP, les lecteurs sont encouragés à modifier et à adapter la configuration incluse pour répondre à leurs propres besoins.
Pour suivre ce tutoriel, vous aurez besoin de :
l'Etape 2 de l'installation des clés SSH dans le guide Ubuntu 18.04
. Au cas où vous utiliseriez les Droplets DigitalOcean en tant que nœuds, vous pouvez utiliser le panneau de commande pour ajouter votre clé publique à vos hôtes Ansible.La première chose que nous devons faire est de cloner le dépôt contenant les scripts de provisionnement Ansible et l’application de démonstration Laravel, que nous allons déployer sur les serveurs distants. Tous les fichiers nécessaires se trouvent dans le dépôt Github do-community/ansible-laravel-demo.
Après vous être connecté à votre nœud de contrôle Ansible en tant qu’utilisateur sudo, clonez le dépôt et naviguez jusqu’au répertoire créé par la commande git
:
- git clone https://github.com/do-community/ansible-laravel-demo.git
- cd ansible-laravel-demo
Maintenant, vous pouvez exécuter une commande ls
pour inspecter le contenu du référentiel cloné:
- ls -l --group-directories-first
Vous verrez une sortie de ce type :
drwxrwxr-x 3 sammy sammy 4096 Mar 24 15:24 application
drwxrwxr-x 2 sammy sammy 4096 Mar 24 15:24 group_vars
drwxrwxr-x 7 sammy sammy 4096 Mar 24 15:24 roles
-rw-rw-r-- 1 sammy sammy 102 Mar 24 15:24 inventory-example
-rw-rw-r-- 1 sammy sammy 1987 Mar 24 15:24 laravel-deploy.yml
-rw-rw-r-- 1 sammy sammy 794 Mar 24 15:24 laravel-env.j2
-rw-rw-r-- 1 sammy sammy 920 Mar 24 15:24 readme.md
-rw-rw-r-- 1 sammy sammy 318 Mar 24 15:24 server-setup.yml
Voici un aperçu de chacun de ces dossiers et fichiers et de ce qu’ils sont :
application/
: ce répertoire contient l’application Laravel de démonstration qui va être déployée sur le serveur distant à la fin de l’atelier.group_vars/
: Ce répertoire contient des fichiers variables contenant des options personnalisées pour la configuration de l’application, telles que les informations d’identification de la base de données et l’endroit où stocker les fichiers de l’application sur le serveur distant.roles/
: Ce répertoire contient les différents roles Ansible qui gèrent le provisionnement d’un serveur LEMP Ubuntu.inventory-example
: Ce fichier peut être utilisé comme base pour créer un inventaire personnalisé de votre infrastructure.laravel-deploy.yml
: Ce playbook permettra de déployer l’application Laravel de démonstration sur le serveur distant.laravel-env.j2
: Ce modèle est utilisé par le playbook laravel-deploy.yml
pour mettre en place le fichier d’environnement de l’application.readme.md
: Ce fichier contient des informations générales sur le provisionnement contenu dans ce dépôt.server-setup.yml
: Ce playbook fournira un serveur LEMP en utilisant les rôles définis dans le répertoire roles/
.Nous allons maintenant créer un fichier d’inventaire pour répertorier les hôtes que nous voulons gérer à l’aide d’Ansible. Tout d’abord, copiez le fichier inventory-example
dans un nouveau fichier appelé hosts
:
- cp inventory-example hosts
Maintenant, utilisez l’éditeur de texte de votre choix pour ouvrir le nouveau fichier d’inventaire et le mettre à jour avec vos propres serveurs. Ici, nous utiliserons le nano
:
- nano hosts
L’exemple d’inventaire fourni avec le kit d’atelier contient deux groupes d’Ansible : développement
et production
. Il s’agit de montrer comment utiliser des variables de groupe pour personnaliser le déploiement dans des environnements multiples. Si vous souhaitez tester cette configuration avec un seul nœud, vous pouvez utiliser soit le groupe de développement
, soit le groupe de production
et supprimer l’autre du fichier d’inventaire.
[dev]
203.0.113.0.101
[prod]
203.0.113.0.102
[all:vars]
ansible_python_interpreter=/usr/bin/python3
Remarque : la variable ansible_python_interpreter
définit le chemin vers l’exécutable Python sur l’hôte distant. Ici, nous disons à Ansible de définir cette variable pour tous les hôtes dans ce fichier d’inventaire.
Enregistrez et fermez le fichier lorsque vous avez fini de le modifier. Si vous utilisez nano
, vous pouvez le faire en appuyant sur CTRL+X
, puis Y
et ENTER
(ENTRÉE) pour confirmer.
Une fois que vous avez fini d’ajuster votre fichier d’inventaire, vous pouvez exécuter le module ping
Ansible pour tester si le nœud de contrôle est capable de se connecter aux hôtes :
- ansible all -i hosts -m ping -u root
Décomposons cette commande :
all
: Cette option indique à Ansible d’exécuter la commande suivante sur tous les hôtes du fichier d’inventaire désigné.-i hosts
: Spécifie quel inventaire doit être utilisé. Lorsque cette option n’est pas disponible, Ansible s’efforcera d’utiliser l’inventaire par défaut, qui se trouve généralement à l’adresse /etc/ansible/hosts
.-m ping
: Cela permettra d’exécuter le ping
Ansible qui testera la connectivité aux nœuds et déterminera si l’exécutable Python peut être trouvé ou non sur les systèmes distants.-u root
: Cette option spécifie quel utilisateur distant doit être utilisé pour se connecter aux nœuds. Nous utilisons la root à titre d’exemple, car c’est généralement le seul compte disponible sur les nouveaux serveurs. D’autres options de connexion peuvent être nécessaires en fonction de votre fournisseur d’infrastructure et de la configuration SSH.Si votre connexion SSH aux nœuds est correctement configurée, vous obtiendrez le résultat suivant :
Output203.0.113.0.101 | SUCCESS => {
"changed": false,
"ping": "pong"
}
203.0.113.0.102 | SUCCESS => {
"changed": false,
"ping": "pong"
}
La réponse pong
signifie que votre nœud de contrôle est capable de se connecter à vos nœuds gérés, et qu’Ansible est capable d’exécuter des commandes Python sur les hôtes distants.
Avant de lancer les playbooks inclus dans ce kit d’atelier, vous devrez d’abord modifier le fichier de variables qui contient des paramètres tels que le nom de l’utilisateur distant à créer et les informations d’identification de la base de données à configurer avec MariaDB.
Ouvrez le groupe_vars/all
en utilisant l’éditeur de texte de votre choix :
- nano group_vars/all.yml
---
# Initial Server Setup
remote_user: sammy
# MySQL Setup
mysql_root_password: MYSQL_ROOT_PASSWORD
mysql_app_db: travellist
mysql_app_user: travellist_user
mysql_app_pass: DB_PASSWORD
# Web Server Setup
http_host: "{{ ansible_facts.eth0.ipv4.address }}"
remote_www_root: /var/www
app_root_dir: travellist-demo
document_root: "{{ remote_www_root }}/{{ app_root_dir }}/public"
# Laravel Env Variables
app_name: Travellist
app_env: dev
app_debug: true
app_url: "http://{{ http_host }}"
db_host: localhost
db_port: 3306
db_database: "{{ mysql_app_db }}"
db_user: "{{ mysql_app_user }}"
db_pass: "{{ mysql_app_pass }}"
Les variables qui nécessitent votre attention sont :
remote_user
: L’utilisateur spécifié sera créé sur le serveur distant et se verra accorder des privilèges sudo
.mysql_root_password
: Cette variable définit le mot de passe de la root de la base de données pour le serveur MariaDB. Notez qu’il doit s’agir d’un mot de passe sécurisé que vous aurez choisi vous-même.mysql_app_db
: Le nom de la base de données à créer pour l’application Laravel. Vous n’avez pas besoin de changer cette valeur, mais vous êtes libre de le faire si vous le souhaitez. Cette valeur sera utilisée pour mettre en place le fichier de configuration Laravel .env
.mysql_app_user
: Le nom de l’utilisateur de la base de données pour l’application Laravel. Là encore, vous n’êtes pas obligé de changer cette valeur, mais vous êtes libre de le faire.mysql_app_pass
: Le mot de passe de la base de données pour l’application Laravel. Il doit s’agir d’un mot de passe sécurisé de votre choix.http_host
: Le nom de domaine ou l’adresse IP de l’hôte distant. Ici, nous utilisons un fait Ansible qui contient l’adresse ipv4 pour l’interface réseau eth0
. Si vos noms de domaine pointent vers vos hôtes distants, vous pouvez créer des fichiers variables séparés pour chacun d’eux, en écrasant cette valeur afin que la configuration Nginx contienne le nom d’hôte correct pour chaque serveur.Lorsque vous avez fini de modifier ces valeurs, enregistrez et fermez le fichier.
Si vous avez configuré votre fichier d’inventaire avec plusieurs nœuds, vous pouvez créer des fichiers variables supplémentaires pour configurer chaque nœud en conséquence. Dans notre exemple d’inventaire, nous avons créé deux groupes distincts : le développement
et la production
. Pour éviter d’avoir les mêmes références de base de données et autres paramètres dans les deux environnements, nous devons créer un fichier de variables séparé qui contiendra les valeurs de production.
Vous voudrez peut-être copier le fichier de variables par défaut et l’utiliser comme base pour vos valeurs de production :
- cp group_vars/all.yml group_vars/production.yml
- nano group_vars/production.yml
Comme le fichier all.yml
contient les valeurs par défaut qui devraient être valables pour tous les environnements, vous pouvez supprimer du nouveau fichier production.yml
toutes les variables qui n’auront pas besoin d’être modifiées. Les variables que vous devez mettre à jour pour chaque environnement sont mises en évidence ici :
---
# Initial Server Setup
remote_user: prod_user
# MySQL Setup
mysql_root_password: MYSQL_PROD_ROOT_PASSWORD
mysql_app_pass: MYSQL_PROD_APP_PASSWORD
# Laravel Env Variables
app_env: prod
app_debug: false
Remarquez que nous avons modifié la valeur app_env
à prod
et mis la valeur d’ app_debug
à false
. Il s’agit de paramètres Laravel recommandés pour les environnements de production.
Une fois que vous avez fini de personnaliser vos variables de production, enregistrez et fermez le fichier.
Si vous prévoyez de partager votre installation Ansible avec d’autres utilisateurs, il est important de préserver la sécurité des informations d’identification de la base de données et des autres données sensibles contenues dans vos fichiers variables. Cela est possible grâce à Ansible Vault, une fonctionnalité qui est incluse par défaut dans Ansible. Ansible Vault vous permet de crypter des fichiers variables afin que seuls les utilisateurs ayant accès au mot de passe de la chambre forte puissent voir, modifier ou décrypter ces fichiers. Le mot de passe de la chambre forte est également nécessaire pour exécuter un playbook ou une commande qui utilise des fichiers cryptés.
Pour crypter votre fichier de variables de production, exécutez :
- ansible-vault encrypt group_vars/production.yml
Vous serez invité à fournir un mot de passe pour la chambre forte et à le confirmer. Une fois que vous aurez terminé, si vous vérifiez le contenu de ce fichier, vous verrez que les données sont maintenant cryptées.
Si vous souhaitez visualiser le fichier de variables sans en modifier le contenu, vous pouvez utiliser la commande d'affichage
:
- ansible-vault view group_vars/production.yml
Vous serez invité à fournir le même mot de passe que celui que vous avez défini lors du cryptage de ce fichier avec ansible-vault
. Après avoir fourni le mot de passe, le contenu du fichier apparaîtra dans votre terminal. Pour quitter la vue du fichier, tapez q
.
Pour modifier un fichier qui a été précédemment crypté avec Ansible Vault, utilisez la commande edit
vault :
- ansible-vault edit group_vars/production.yml
Cette commande vous demandera de fournir le mot de passe de la chambre forte pour ce fichier. Votre éditeur de terminal par défaut sera alors utilisé pour ouvrir le fichier en vue de son édition. Après avoir effectué les modifications souhaitées, enregistrez et fermez le fichier, et il sera à nouveau automatiquement crypté par Ansible Vault.
Vous avez maintenant terminé la configuration de vos fichiers variables. La prochaine étape consistera à mettre en place Nginx, PHP-FPM et MariaDB (qui, avec un système d’exploitation basé sur Linux comme Ubuntu, forment la pile LEMP) sur votre ou vos serveurs distants.
Avant de déployer l’application Laravel de démonstration sur le(s) serveur(s) distant(s), nous devons mettre en place un environnement LEMP qui servira l’application. Le playbook serveur-setup.yml
comprend les rôles Ansible nécessaires à la mise en place de ce système. Pour inspecter son contenu, exécutez :
- cat server-setup.yml
---
- hosts: all
become: true
roles:
- { role: setup, tags: ['setup'] }
- { role: mariadb, tags: ['mysql', 'mariadb', 'db', 'lemp'] }
- { role: php, tags: ['php', 'web', 'php-fpm', 'lemp'] }
- { role: nginx, tags: ['nginx', 'web', 'http', 'lemp'] }
- { role: composer, tags: ['composer'] }
Voici un aperçu de tous les rôles inclus dans ce playbook :
Installation
: Contient les tâches nécessaires pour créer un nouvel utilisateur du système et lui accorder des privilèges sudo
, ainsi qu’activer le pare-feu ufw
.mariadb
: Installe le serveur de base de données MariaDB et crée la base de données et l’utilisateur de l’application.php
: Installe les modules php-fpm
et PHP qui sont nécessaires pour faire fonctionner une application Laravel.nginx
: Installe le serveur web Nginx et permet l’accès sur le port 80
.composer
: Installe Composer globalement.Notez que nous avons mis en place quelques balises au sein de chaque rôle. Cette mesure vise à faciliter la réédition de certaines parties de ce manuel, si nécessaire. Si vous apportez des modifications à votre fichier modèle Nginx, par exemple, vous voudrez peut-être n’exécuter que le rôle Nginx.
La commande suivante permet d’exécuter ce playbook sur tous les serveurs à partir de votre fichier d’inventaire. Le passe --ask-vault-pass
n’est nécessaire que si vous avez utilisé ansible-vault
pour crypter les fichiers variables à l’étape précédente :
- ansible-playbook -i hosts server-setup.yml -u root --ask-vault-pass
Vous aurez une sortie similaire à celle-ci :
OutputPLAY [all] **********************************************************************************************
TASK [Gathering Facts] **********************************************************************************
ok: [203.0.113.0.101]
ok: [203.0.113.0.102]
TASK [setup : Install Prerequisites] ********************************************************************
changed: [203.0.113.0.101]
changed: [203.0.113.0.102]
...
RUNNING HANDLER [nginx : Reload Nginx] ******************************************************************
changed: [203.0.113.0.101]
changed: [203.0.113.0.102]
PLAY RECAP **********************************************************************************************
203.0.113.0.101 : ok=31 changed=27 unreachable=0 failed=0 skipped=0 rescued=0 ignored=1
203.0.113.0.102 : ok=31 changed=27 unreachable=0 failed=0 skipped=0 rescued=0 ignored=1
Votre ou vos nœuds sont maintenant prêts à servir des applications PHP en utilisant Nginx+PHP-FPM, avec MariaDB comme serveur de base de données. Dans une prochaine étape, nous déploierons l’application de démonstration Laravel incluse avec le playbook Ansible laravel-deploy.yml
.
Maintenant que vous avez un environnement LEMP fonctionnel sur votre ou vos serveurs distants, vous pouvez exécuter le playbook laravel-deploy.yml
. Ce playbook permettra d’exécuter les tâches suivantes :
sync
hronisation.acl
pour définir les autorisations pour l’utilisateur www-datapour le dossier de stockage..env
en se basant sur le modèle laravel-env.j2
.stockage
.Ce playbook doit être exécuté par un utilisateur non root avec des permissions sudo
. Cet utilisateur doit avoir été créé lorsque vous avez exécuté le server-setup.yml
playbook à l’étape précédente, en utilisant le nom défini par la variable remote_user
.
Lorsque vous êtes prêt, lancez le playbook laravel-d
eploy.yml avec :
- ansible-playbook -i hosts laravel-deploy.yml -u sammy --ask-vault-pass
Le passe --ask-vault-pass
n’est nécessaire que si vous avez utilisé ansible-vault
pour crypter les fichiers variables à l’étape précédente :
Vous aurez une sortie similaire à celle-ci :
OutputPLAY [all] **********************************************************************************************
TASK [Gathering Facts] **********************************************************************************
ok: [203.0.113.0.101]
ok: [203.0.113.0.102]
TASK [Make sure the remote app root exists and has the right permissions] *******************************
ok: [203.0.113.0.101]
ok: [203.0.113.0.102]
TASK [Rsync application files to the remote server] *****************************************************
ok: [203.0.113.0.101]
ok: [203.0.113.0.102]
...
TASK [Run Migrations + Seeders] *************************************************************************
ok: [203.0.113.0.101]
ok: [203.0.113.0.102]
PLAY RECAP **********************************************************************************************
203.0.113.0.101 : ok=10 changed=9 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
203.0.113.0.102 : ok=10 changed=9 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Lorsque l’exécution est terminée, vous pouvez accéder à l’application de démonstration en faisant pointer votre navigateur sur le nom de domaine ou l’adresse IP de votre nœud :
http://node_domain_or_IP
Vous verrez une page comme ceci :
Ce tutoriel montre comment mettre en place un fichier d’inventaire Ansible et se connecter à des nœuds distants, et comment exécuter des playbooks Ansible pour mettre en place un serveur LEMP et y déployer une application de démonstration Laravel.Ce guide complète les diapositives et les notes de l’orateur du kit d’atelier sur l’automatisation de la configuration de serveur, et est accompagné d’une démo Dépôt GitHub contenant tous les fichiers nécessaires au suivi de la composante démo de cet atelier.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Sign up for Infrastructure as a Newsletter.
Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.