Automating Server Setup with Ansible: Un kit d'atelier DigitalOcean

Introduction

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.

Conditions préalables

Pour suivre ce tutoriel, vous aurez besoin de :

• Un nœud de contrôle Ansible : une machine Ubuntu 18.04 avec Ansible installé et configuré pour se connecter à vos hôtes ansible en utilisant les clés SSH. Assurez-vous que le nœud de contrôle a un utilisateur régulier avec des permissions sudo et un pare-feu activé, comme expliqué dans notre Guide de configuration initiale du serveur, et un ensemble de Clés SSH. Pour configurer Ansible, veuillez suivre notre guide sur Comment installer et configurer Ansible sur Ubuntu 18.04.
• Un ou plusieurs hôtes Ansible : un ou plusieurs serveurs Ubuntu 18.04 distants. Chaque hôte doit faire ajouter la clé publique du nœud de contrôle à son fichier authorized_keys comme expliqué dans 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.

Étape 1 - Cloner le dépôt de démo

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/.

Étape 2 - Mettre en place le fichier d’inventaire et test de la connexion aux nœuds

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

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 :

Output
203.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.

Étape 3 - Mettre en place les fichiers variables

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.

Créer des fichiers variables supplémentaires pour des environnements multiples

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.

Crypter les fichiers variables avec Ansible Vault

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.

Étape 4 - Exécuter le playbook LEMP

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 :

Output
PLAY [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.

Étape 5 - Déploiement de l’application Laravel

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 :

1. Créez la racine du document d’application sur le serveur distant si elle n’a pas déjà été créée.
2. Synchronisez le dossier d’application local avec le serveur distant à l’aide du module de synchronisation.
3. Utilisez le module acl pour définir les autorisations pour l’utilisateur www-datapour le dossier de stockage.
4. Configurez le fichier d’application .env en se basant sur le modèle laravel-env.j2.
5. Installez des dépendances d’application avec Composer.
6. Générez la clé de sécurité de l’application.
7. Établir un lien public pour le dossier de stockage.
8. Exécutez les migrations de bases de données et les seeders.

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-deploy.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 :

Output
PLAY [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 :

Conclusion

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.