Rôles et Collections Ansible sur RHEL

AnsibleBeginner
Pratiquer maintenant

Introduction

Dans ce laboratoire, vous apprendrez à automatiser la configuration d'un serveur web Red Hat Enterprise Linux (RHEL) en exploitant la puissance et la réutilisabilité des Rôles et Collections Ansible. Vous construirez un flux d'automatisation complet en créant un rôle personnalisé pour déployer des configurations spécifiques, en intégrant un rôle externe à partir d'un dépôt Git comme dépendance, et en utilisant un Rôle Système RHEL pré-construit à partir d'une Collection Ansible pour gérer les services système tels que SELinux.

Le processus commence par la création d'une structure de rôle standardisée à l'aide de ansible-galaxy init. Vous définirez ensuite et installerez une dépendance de rôle à partir d'un dépôt Git en utilisant un fichier requirements.yml. Après avoir intégré un Rôle Système RHEL, vous assemblerez les trois types de rôles – personnalisé, basé sur Git et basé sur Collection – en un seul playbook maître. Enfin, vous exécuterez le playbook et vérifierez que le serveur web Apache et les paramètres SELinux ont été correctement appliqués au serveur RHEL cible, démontrant ainsi une solution d'automatisation complète et modulaire.

Créer un rôle Ansible personnalisé avec ansible-galaxy init

Dans cette étape, vous commencerez par créer une structure de répertoire standardisée pour un nouveau rôle Ansible à l'aide de la commande ansible-galaxy init. Les rôles Ansible sont un concept fondamental pour la création de contenu d'automatisation réutilisable et organisé. Ils vous permettent d'empaqueter des tâches, des gestionnaires (handlers), des variables et d'autres composants dans une unité autonome et portable. L'utilisation d'une structure standard est une bonne pratique qui rend votre automatisation plus facile à comprendre, à gérer et à partager.

Tout d'abord, assurez-vous d'être dans le bon répertoire de travail. Tout le travail pour ce laboratoire sera effectué dans le répertoire ~/project.

cd ~/project

Avant de créer un rôle, vous devez vous assurer que les outils en ligne de commande Ansible sont installés. Le paquet ansible-core fournit les outils essentiels, y compris ansible-galaxy.

Installez ansible-core en utilisant le gestionnaire de paquets dnf. Le drapeau -y répond automatiquement "oui" à toute invite de confirmation.

sudo dnf install -y ansible-core

Vous devriez voir une sortie indiquant que le paquet est en cours d'installation et que les dépendances sont résolues.

...
Installed:
  ansible-core-2.16.x-1.el9.x86_64
  ...
Complete!

Il est courant d'organiser tous les rôles du projet dans un répertoire dédié roles. Créez ce répertoire maintenant.

mkdir roles

Maintenant, naviguez dans le répertoire roles nouvellement créé. C'est ici que vous initialiserez votre nouveau rôle personnalisé.

cd roles

Vous allez maintenant utiliser la commande ansible-galaxy init pour créer un squelette pour un rôle nommé apache.developer_configs. Cette commande génère automatiquement un ensemble de répertoires et de fichiers standard, fournissant un point de départ propre pour le développement de votre rôle.

ansible-galaxy init apache.developer_configs

Après avoir exécuté la commande, vous verrez un message de confirmation.

- Role apache.developer_configs was created successfully

Pour voir la structure qui vient d'être créée, vous pouvez utiliser la commande ls -R, qui liste le contenu d'un répertoire et de tous ses sous-répertoires de manière récursive.

ls -R apache.developer_configs

La sortie montre la structure de répertoire standard pour un rôle Ansible :

apache.developer_configs:
defaults  files  handlers  meta  README.md  tasks  templates  tests  vars

apache.developer_configs/defaults:
main.yml

apache.developer_configs/files:

apache.developer_configs/handlers:
main.yml

apache.developer_configs/meta:
main.yml

apache.developer_configs/tasks:
main.yml

apache.developer_configs/templates:

apache.developer_configs/tests:
inventory  test.yml

apache.developer_configs/vars:
main.yml

Voici un bref aperçu des répertoires les plus importants :

  • tasks: Contient la liste principale des tâches à exécuter par le rôle.
  • handlers: Contient les gestionnaires (handlers), qui sont des tâches qui ne s'exécutent que lorsqu'elles sont notifiées par une autre tâche.
  • vars: Contient les variables pour le rôle.
  • templates: Contient des modèles de fichiers qui utilisent le moteur de templating Jinja2.
  • meta: Contient les métadonnées du rôle, y compris les dépendances sur d'autres rôles.

Vous avez maintenant créé avec succès la structure de base de votre rôle Ansible personnalisé. Dans les étapes suivantes, vous remplirez ces répertoires avec du contenu pour configurer un serveur web.

Installer une dépendance de rôle à partir d'un dépôt Git en utilisant requirements.yml

Dans cette étape, vous apprendrez à gérer les dépendances de rôles provenant de sources externes, telles qu'un dépôt Git. C'est une pratique courante dans les projets Ansible plus importants où vous réutilisez des rôles développés par la communauté ou d'autres équipes. Ansible utilise un fichier, généralement nommé requirements.yml, pour définir une liste de rôles à installer.

Votre rôle personnalisé, apache.developer_configs, dépendra d'un rôle Apache fondamental pour garantir que le serveur web est installé et en cours d'exécution. Vous définirez cette dépendance et l'installerez.

Tout d'abord, assurez-vous d'être dans le répertoire principal du projet. Si vous êtes toujours dans le sous-répertoire roles de l'étape précédente, revenez à ~/project.

cd ~/project

Maintenant, vous allez créer le fichier requirements.yml dans votre répertoire roles. Ce fichier listera tous les rôles externes dont votre projet a besoin. Utilisez l'éditeur nano pour créer et éditer le fichier.

nano roles/requirements.yml

Ajoutez le contenu suivant au fichier. Cette entrée indique à ansible-galaxy de télécharger une version spécifique d'un rôle Apache à partir d'un dépôt Git public et de le nommer localement infra.apache.

- name: infra.apache
  src: https://github.com/geerlingguy/ansible-role-apache.git
  scm: git
  version: 3.2.0

Analysons cette définition :

  • name: C'est le nom local du rôle. Même si le dépôt source a un nom différent, il sera installé dans un répertoire appelé infra.apache.
  • src: L'URL source du dépôt Git.
  • scm: Spécifie l'outil de gestion de contrôle source, qui est git dans ce cas.
  • version: La branche Git, le tag ou le hash de commit spécifique à utiliser. L'épinglage d'une version est crucial pour garantir que votre automatisation est stable et prévisible.

Enregistrez le fichier et quittez nano en appuyant sur Ctrl+X, puis Y, et enfin Entrée.

Avec le fichier requirements.yml en place, vous pouvez maintenant utiliser la commande ansible-galaxy install pour télécharger et installer le rôle.

  • Le drapeau -r pointe vers votre fichier de requirements.
  • Le drapeau -p spécifie le chemin où les rôles doivent être installés.
ansible-galaxy install -r roles/requirements.yml -p roles

Vous verrez une sortie confirmant le processus de téléchargement et d'installation.

Starting galaxy role install process
- downloading role 'ansible-role-apache', owned by geerlingguy
- downloading role from https://github.com/geerlingguy/ansible-role-apache/archive/3.2.0.tar.gz
- extracting infra.apache to /home/labex/project/roles/infra.apache
- infra.apache (3.2.0) was installed successfully

Pour confirmer que le rôle a été installé correctement, listez le contenu du répertoire roles.

ls -l roles

Vous devriez maintenant voir le répertoire infra.apache à côté du rôle apache.developer_configs que vous avez créé précédemment.

total 12
drwxr-xr-x. 9 labex labex 4096 Nov 10 10:10 apache.developer_configs
drwxr-xr-x. 9 labex labex 4096 Nov 10 10:15 infra.apache
-rw-r--r--. 1 labex labex  118 Nov 10 10:12 requirements.yml

Vous avez maintenant déclaré avec succès un dépôt Git externe comme dépendance et l'avez installé dans votre projet. L'étape suivante consiste à intégrer cette dépendance dans les métadonnées de votre rôle personnalisé.

Intégrer un rôle système RHEL à partir d'une collection Ansible

Dans cette étape, vous travaillerez avec les collections Ansible, qui sont la manière standard de distribuer le contenu Ansible, y compris les rôles, les modules et les plugins. Vous installerez la collection community.general, qui fournit un ensemble de modules utiles pour automatiser les tâches administratives courantes, y compris la gestion de SELinux.

Pour notre scénario de serveur web, nous devons configurer correctement SELinux pour permettre au service Apache d'écouter sur des ports non standard. La collection community.general inclut des modules SELinux parfaits pour cette tâche.

Tout d'abord, assurez-vous d'être dans le répertoire principal du projet.

cd ~/project

Il est recommandé de garder les collections installées dans le répertoire du projet pour que votre projet soit autonome. Créez un répertoire nommé collections pour les stocker.

mkdir collections

Maintenant, utilisez la commande ansible-galaxy collection install pour installer les collections requises. L'indicateur -p indique à la commande d'installer les collections dans le répertoire collections que vous venez de créer.

ansible-galaxy collection install community.general:7.5.0 ansible.posix:1.5.4 -p collections

La commande téléchargera les collections et leurs dépendances. Vous verrez une sortie similaire à la suivante :

Starting galaxy collection install process
Process install dependency map
Starting collection install process
Installing 'community.general:7.5.0' to '/home/labex/project/collections/ansible_collections/community/general'
Installing 'ansible.posix:1.5.4' to '/home/labex/project/collections/ansible_collections/ansible/posix'
...
community.general:7.5.0 was installed successfully
ansible.posix:1.5.4 was installed successfully

Pour vérifier que la collection est maintenant disponible pour votre projet, vous pouvez lister toutes les collections installées en spécifiant le chemin des collections.

ansible-galaxy collection list -p collections

La sortie affichera les collections installées et leurs chemins d'installation dans votre projet.

## /home/labex/project/collections/ansible_collections
Collection              Version
----------------------- -------
ansible.posix           1.5.4
community.general       7.5.0

Lorsque vous utilisez un module d'une collection dans un playbook, vous devez y faire référence par son nom de collection entièrement qualifié (FQCN - Fully Qualified Collection Name). Pour la gestion de SELinux, vous utiliserez ansible.posix.selinux pour la gestion de l'état SELinux et community.general.seport pour la gestion des ports SELinux.

Vous avez maintenant installé avec succès des collections puissantes qui incluent des modules de gestion SELinux. Dans la prochaine étape, vous assemblerez un playbook qui utilise votre rôle personnalisé, le rôle provenant de Git et les modules SELinux de ces collections pour configurer entièrement le serveur web de développement.

Assembler et exécuter un playbook avec des rôles personnalisés, Git et système

Dans cette étape, vous allez rassembler tous les composants que vous avez préparés : votre rôle personnalisé, la dépendance depuis Git et le rôle système RHEL. Vous allez créer un playbook principal qui orchestrera ces rôles pour configurer entièrement le serveur web de développement.

Considérez cette étape comme l'assemblage d'une machine complexe à partir de différentes pièces : chaque rôle remplit un objectif spécifique, et ils travaillent ensemble pour créer un environnement de serveur web complet. Décomposons cela en morceaux gérables :

Tout d'abord, assurez-vous d'être dans le répertoire principal du projet.

cd ~/project

Avant de plonger dans la configuration, comprenons ce que nous créons :

  • Configuration Ansible : Définit le comportement d'Ansible et où il trouve les fichiers.
  • Inventaire : Définit quels serveurs gérer (dans notre cas, localhost).
  • Variables : Stockent les données que nos rôles utiliseront (informations développeur, paramètres SELinux).
  • Contenu du rôle personnalisé : Les tâches réelles qui configureront les environnements de développement.
  • Playbook principal : L'orchestrateur qui exécute tout dans le bon ordre.

1. Créer la configuration et l'inventaire Ansible

Le fichier ansible.cfg est comme un fichier de configuration qui indique à Ansible comment se comporter. Sans lui, vous devriez spécifier les chemins et les options dans chaque commande. Avec lui, Ansible sait automatiquement où trouver vos rôles, collections et inventaire.

Créez le fichier ansible.cfg en utilisant nano. Ce fichier indique à Ansible où trouver vos rôles, collections et inventaire.

nano ansible.cfg

Ajoutez le contenu suivant. Comprenons chaque ligne :

[defaults]
inventory = inventory
roles_path = roles
collections_paths = collections
host_key_checking = False

[privilege_escalation]
become = True

Ce que fait chaque paramètre :

  • inventory = inventory : Au lieu de taper -i inventory à chaque fois, Ansible utilisera automatiquement ce fichier.
  • roles_path = roles : Ansible recherchera les rôles dans le répertoire roles.
  • collections_paths = collections : Ansible trouvera vos collections installées ici.
  • host_key_checking = False : Empêche les erreurs de vérification de clé SSH dans les environnements de laboratoire.
  • become = True : Exécute automatiquement les tâches avec des privilèges élevés lorsque nécessaire.

Enregistrez et quittez nano (Appuyez sur Ctrl+X, puis Y, puis Entrée).

Le fichier d'inventaire indique à Ansible quelles machines gérer. Dans notre cas, nous configurons la machine locale.

nano inventory

Ajoutez la ligne suivante :

localhost ansible_connection=local

Ce que cela signifie :

  • localhost : Le nom de notre hôte cible.
  • ansible_connection=local : Au lieu de SSH, utilisez des connexions locales (puisque nous gérons la même machine sur laquelle nous exécutons Ansible).

Enregistrez et quittez nano.

2. Définir les variables de rôle

Les variables dans Ansible sont comme des paramètres que vos rôles peuvent utiliser. Au lieu de coder en dur des valeurs comme les noms d'utilisateur ou les numéros de port dans vos tâches, vous les définissez dans des fichiers de variables. Cela rend votre automatisation flexible et réutilisable.

Le répertoire group_vars/all est un emplacement spécial où Ansible charge automatiquement les variables pour tous les hôtes. Tout fichier YAML dans ce répertoire devient disponible pour vos playbooks et rôles.

Créez la structure de répertoires pour les variables qui s'appliquent à tous les hôtes :

mkdir -p group_vars/all

Maintenant, créez un fichier pour définir les informations du développeur. Ces données seront utilisées par votre rôle personnalisé pour créer des comptes utilisateur et des configurations web.

nano group_vars/all/developers.yml

Ajoutez le contenu suivant :

---
web_developers:
  - username: jdoe ## Premier développeur
    port: 9081 ## Port personnalisé pour le site web de ce développeur
  - username: jdoe2 ## Deuxième développeur
    port: 9082 ## Port personnalisé pour le site web de ce développeur

Ce que signifie cette structure de données :

  • web_developers : Une liste contenant les informations des développeurs.
  • Chaque développeur a un username et un port.
  • Votre rôle personnalisé parcourra cette liste pour créer des configurations pour chaque développeur.

Enregistrez et quittez.

Ensuite, créez un fichier de variables pour la configuration SELinux. SELinux (Security-Enhanced Linux) est un module de sécurité qui contrôle ce que les applications peuvent faire.

nano group_vars/all/selinux.yml

Ajoutez le contenu suivant :

---
selinux_state: enforcing ## Définit SELinux en mode enforcing (sécurité maximale)
selinux_ports: ## Liste des ports à autoriser pour Apache
  - ports: "9081" ## Autoriser le port 9081
    proto: "tcp" ## Protocole : TCP
    setype: "http_port_t" ## Type SELinux : port HTTP
    state: "present" ## Ajouter cette règle
  - ports: "9082" ## Autoriser le port 9082
    proto: "tcp" ## Protocole : TCP
    setype: "http_port_t" ## Type SELinux : port HTTP
    state: "present" ## Ajouter cette règle

Comprendre les paramètres SELinux :

  • selinux_state: enforcing : SELinux bloquera activement les actions non autorisées.
  • selinux_ports : Une liste de configurations de ports.
  • http_port_t : Le type SELinux qui permet à Apache de se lier aux ports.
  • Par défaut, Apache ne peut utiliser que les ports 80 et 443 ; nous devons explicitement autoriser les ports 9081 et 9082.

Enregistrez et quittez.

3. Remplir le rôle personnalisé

Votre rôle apache.developer_configs a actuellement la structure de répertoire mais aucun contenu réel. Nous devons ajouter :

  • Templates : Fichiers qui peuvent inclure des variables (en utilisant la syntaxe Jinja2).
  • Tâches : Le travail réel qu'Ansible effectuera.
  • Handlers : Tâches spéciales qui ne s'exécutent que lorsqu'elles sont notifiées (comme le redémarrage des services).
  • Métadonnées : Informations sur les dépendances du rôle.

Les templates vous permettent de créer des fichiers de configuration qui s'adaptent en fonction de vos variables. L'extension .j2 indique qu'il s'agit d'un template Jinja2.

nano roles/apache.developer_configs/templates/developer.conf.j2

Ajoutez le contenu suivant :

{% for dev in web_developers %}
Listen {{ dev.port }}
<VirtualHost *:{{ dev.port }}>
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/{{ dev.username }}

    <Directory /var/www/{{ dev.username }}>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>
</VirtualHost>
{% endfor %}

Comprendre la syntaxe du template :

  • {% for dev in web_developers %} : Commence une boucle à travers la liste des développeurs.
  • {{ dev.port }} : Insère le numéro de port pour ce développeur.
  • {{ dev.username }} : Insère le nom d'utilisateur pour ce développeur.
  • {% endfor %} : Termine la boucle.
  • Le résultat sera des configurations de virtual host séparées pour chaque développeur.

Ce que cela crée : Pour nos deux développeurs, ce template générera une configuration Apache qui :

  1. Fait écouter Apache sur les ports 9081 et 9082.
  2. Crée des virtual hosts qui servent du contenu depuis /var/www/jdoe et /var/www/jdoe2.
  3. Définit les permissions appropriées pour chaque répertoire.

Enregistrez et quittez.

Les tâches sont le travail réel qu'Ansible effectue. Chaque tâche utilise un module Ansible pour accomplir quelque chose de spécifique.

nano roles/apache.developer_configs/tasks/main.yml

Ajoutez le contenu suivant et comprenons chaque tâche :

---
## Tâche 1 : Créer des comptes utilisateur pour chaque développeur
- name: Create developer user accounts
  ansible.builtin.user: ## Utilise le module 'user'
    name: "{{ item.username }}" ## Crée l'utilisateur avec ce nom
    state: present ## Assure que l'utilisateur existe
  loop: "{{ web_developers }}" ## Fait cela pour chaque développeur dans la liste

## Tâche 2 : Créer des répertoires web pour chaque développeur
- name: Create developer web root directories
  ansible.builtin.file: ## Utilise le module 'file'
    path: "/var/www/{{ item.username }}" ## Crée ce répertoire
    state: directory ## Assure que c'est un répertoire
    owner: "{{ item.username }}" ## Définit le propriétaire
    group: "{{ item.username }}" ## Définit le groupe
    mode: "0755" ## Définit les permissions (rwxr-xr-x)
  loop: "{{ web_developers }}"

## Tâche 3 : Créer une page web d'exemple pour chaque développeur
- name: Create a sample index.html for each developer
  ansible.builtin.copy: ## Utilise le module 'copy'
    content: "Welcome to {{ item.username }}'s dev space\n" ## Contenu du fichier
    dest: "/var/www/{{ item.username }}/index.html" ## Où placer le fichier
    owner: "{{ item.username }}" ## Propriétaire du fichier
    group: "{{ item.username }}" ## Groupe du fichier
    mode: "0644" ## Permissions du fichier (rw-r--r--)
  loop: "{{ web_developers }}"

## Tâche 4 : Déployer le fichier de configuration Apache
- name: Deploy developer apache configs
  ansible.builtin.template: ## Utilise le module 'template'
    src: developer.conf.j2 ## Fichier template source
    dest: /etc/httpd/conf.d/developer.conf ## Destination sur le serveur
    mode: "0644" ## Permissions du fichier
  notify: restart apache ## Déclenche le handler de redémarrage lorsqu'il y a un changement

Comprendre les concepts clés :

  • loop : Répète la tâche pour chaque élément de la liste.
  • {{ item.username }} : Fait référence au nom d'utilisateur de l'élément actuel dans la boucle.
  • notify: restart apache : Lorsque cette tâche apporte des modifications, elle déclenchera un handler nommé "restart apache".
  • Permissions de fichier : 0755 signifie que le propriétaire peut lire/écrire/exécuter, les autres peuvent lire/exécuter ; 0644 signifie que le propriétaire peut lire/écrire, les autres peuvent seulement lire.

Enregistrez et quittez.

Les handlers sont des tâches spéciales qui ne s'exécutent que lorsqu'elles sont notifiées par d'autres tâches. Ils sont généralement utilisés pour des actions comme le redémarrage des services.

nano roles/apache.developer_configs/handlers/main.yml

Ajoutez le contenu suivant :

---
- name: restart apache ## Ce nom doit correspondre à l'instruction notify:
  ansible.builtin.service: ## Utilise le module 'service'
    name: httpd ## Le nom du service (Apache est appelé 'httpd' sur RHEL)
    state: restarted ## Redémarre le service

Pourquoi utiliser des handlers ?

  • Efficacité : Le service ne redémarre que si la configuration a réellement changé.
  • Ordre : Toutes les tâches s'exécutent d'abord, puis tous les handlers s'exécutent à la fin.
  • Idempotence : Plusieurs tâches peuvent notifier le même handler, mais il ne s'exécute qu'une seule fois.

Enregistrez et quittez.

Enfin, nous devons indiquer à Ansible que notre rôle personnalisé dépend du rôle infra.apache que nous avons installé précédemment.

nano roles/apache.developer_configs/meta/main.yml

Remplacez le contenu du fichier par :

---
dependencies:
  - role: infra.apache ## Ce rôle doit s'exécuter avant notre rôle personnalisé

Ce que cela fait :

  • Lorsque Ansible exécute apache.developer_configs, il exécutera automatiquement infra.apache en premier.
  • Cela garantit qu'Apache est installé et configuré avant que nous ajoutions nos configurations personnalisées.
  • Les dépendances s'exécutent dans l'ordre où elles sont listées.

Enregistrez et quittez.

4. Assembler et exécuter le playbook principal

Un playbook est comme une recette qui indique à Ansible quoi faire et dans quel ordre. Notre playbook va :

  1. Configurer les paramètres SELinux (pre_tasks).
  2. Exécuter nos rôles (qui incluent la chaîne de dépendances).

Créez le fichier du playbook principal :

nano web_dev_server.yml

Ajoutez le contenu suivant avec des explications détaillées :

---
- name: Configure Dev Web Server ## Nom du playbook
  hosts: localhost ## Exécuter sur localhost
  pre_tasks: ## Tâches qui s'exécutent avant les rôles
    ## Tâche 1 : Configurer le mode SELinux
    - name: Set SELinux to enforcing mode
      ansible.posix.selinux: ## Module de la collection ansible.posix
        policy: targeted ## Utiliser la politique SELinux 'targeted'
        state: "{{ selinux_state }}" ## Utiliser la variable que nous avons définie
      when: selinux_state is defined ## S'exécuter uniquement si la variable existe

    ## Tâche 2 : Configurer les ports SELinux
    - name: Configure SELinux ports for Apache
      community.general.seport: ## Module de la collection community.general
        ports: "{{ item.ports }}" ## Numéro de port
        proto: "{{ item.proto }}" ## Protocole (tcp)
        setype: "{{ item.setype }}" ## Type SELinux (http_port_t)
        state: "{{ item.state }}" ## present ou absent
      loop: "{{ selinux_ports }}" ## Boucler à travers notre liste de ports
      when: selinux_ports is defined ## S'exécuter uniquement si la variable existe

  roles: ## Rôles à exécuter
    - apache.developer_configs ## Notre rôle personnalisé (qui déclenchera infra.apache)

Comprendre l'ordre d'exécution :

  1. pre_tasks : La configuration SELinux s'exécute en premier.
  2. roles : Les dépendances des rôles s'exécutent (infra.apache), puis notre rôle personnalisé.
  3. handlers : Tous les handlers notifiés s'exécutent en dernier.

Pourquoi cet ordre est important :

  • SELinux doit être configuré avant qu'Apache n'essaie de se lier à des ports personnalisés.
  • Apache doit être installé avant que nous puissions configurer des virtual hosts.
  • Les redémarrages de service se produisent après la fin de toute la configuration.

Enregistrez et quittez.

Vous êtes maintenant prêt à exécuter votre automatisation complète :

ansible-playbook web_dev_server.yml

Le playbook s'exécutera et vous verrez une sortie détaillée. Voici ce à quoi vous attendre (par exemple) :

PLAY [Configure Dev Web Server] *************************************************

TASK [Gathering Facts] **********************************************************
ok: [localhost]                     ## Ansible collecte des informations système

TASK [Set SELinux to enforcing mode] *******************************************
changed: [localhost]                ## Le mode SELinux a été modifié

TASK [Configure SELinux ports for Apache] **************************************
changed: [localhost] => (item={'ports': '9081', 'proto': 'tcp', 'setype': 'http_port_t', 'state': 'present'})
changed: [localhost] => (item={'ports': '9082', 'proto': 'tcp', 'setype': 'http_port_t', 'state': 'present'})

TASK [infra.apache : Ensure Apache is installed.] *******************************
changed: [localhost]                ## Le paquet Apache a été installé

TASK [apache.developer_configs : Create developer user accounts] ****************
changed: [localhost] => (item={'username': 'jdoe', 'port': 9081})
changed: [localhost] => (item={'username': 'jdoe2', 'port': 9082})

TASK [apache.developer_configs : Create developer web root directories] *********
changed: [localhost] => (item={'username': 'jdoe', 'port': 9081})
changed: [localhost] => (item={'username': 'jdoe2', 'port': 9082})

TASK [apache.developer_configs : Create a sample index.html for each developer] *
changed: [localhost] => (item={'username': 'jdoe', 'port': 9081})
changed: [localhost] => (item={'username': 'jdoe2', 'port': 9082})

TASK [apache.developer_configs : Deploy developer apache configs] ***************
changed: [localhost]                ## Le fichier de configuration a été créé

RUNNING HANDLER [apache.developer_configs : restart apache] *********************
changed: [localhost]                ## Apache a été redémarré

PLAY RECAP **********************************************************************
localhost                  : ok=17   changed=12   unreachable=0    failed=0    skipped=3    rescued=0    ignored=0

Vous avez assemblé et exécuté avec succès un playbook complexe qui combine plusieurs rôles provenant de différentes sources pour créer un environnement de développement web complet !

Vérifier la configuration SELinux et Apache sur le serveur RHEL

Dans cette dernière étape, vous vérifierez que votre automatisation Ansible a correctement configuré le système. Il est crucial de confirmer que les services fonctionnent comme prévu et que les politiques de sécurité (SELinux) ont été appliquées correctement. Vous utiliserez les outils standard en ligne de commande de RHEL pour inspecter l'état du système.

Tout d'abord, assurez-vous d'être dans le répertoire principal du projet.

cd ~/project

1. Vérifier la configuration SELinux

Les modules SELinux des collections ont eu pour tâche de définir le mode SELinux sur enforcing et d'autoriser de nouveaux ports pour le type http_port_t.

Vérifiez l'état actuel de SELinux à l'aide de la commande sestatus.

sestatus

La sortie devrait indiquer que SELinux est activé et en mode enforcing.

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      33

Ensuite, utilisez la commande semanage port pour vérifier que les ports 9081 et 9082 ont été ajoutés au contexte http_port_t. Vous pouvez rediriger la sortie vers grep pour trouver les lignes pertinentes.

sudo semanage port -l | grep http_port_t

Vous devriez voir vos ports personnalisés listés parmi les ports HTTP par défaut. La sortie exacte peut varier, mais elle inclura les ports que vous avez définis.

http_port_t                    tcp      9082, 9081, 80, 81, 443, 488, 8008, 8009, 8443, 9000
pegasus_http_port_t            tcp      5988

Cela confirme que les modules SELinux ont mis à jour la politique avec succès.

2. Vérifier le service Apache et la configuration

Le rôle infra.apache a installé et démarré le service httpd. Comme systemctl n'est pas disponible dans cet environnement conteneurisé, vous pouvez vérifier le processus en cours à l'aide de ps.

ps aux | grep httpd

Vous devriez voir plusieurs processus httpd en cours d'exécution, indiquant que le service est actif.

root        8851  0.2  0.4  25652 16228 ?        Ss   09:31   0:00 /usr/sbin/httpd -DFOREGROUND
apache      8852  0.0  0.1  25308  6044 ?        S    09:31   0:00 /usr/sbin/httpd -DFOREGROUND
apache      8853  0.0  0.3 1443348 11364 ?       Sl   09:31   0:00 /usr/sbin/httpd -DFOREGROUND
apache      8854  0.0  0.3 1443348 11480 ?       Sl   09:31   0:00 /usr/sbin/httpd -DFOREGROUND
apache      8855  0.0  0.4 1574484 15848 ?       Sl   09:31   0:00 /usr/sbin/httpd -DFOREGROUND
labex       9298  0.0  0.0   6408  2176 pts/3    S+   09:31   0:00 grep --color=auto httpd

3. Vérifier l'accessibilité du contenu web

Enfin, le test le plus important est de voir si les sites web des développeurs sont accessibles. Votre rôle apache.developer_configs a configuré des virtual hosts sur les ports 9081 et 9082. Utilisez la commande curl pour demander le contenu de chaque point d'accès.

Testez d'abord le site pour l'utilisateur jdoe sur le port 9081.

curl http://localhost:9081

La sortie attendue est le contenu du fichier index.html que vous avez créé pour cet utilisateur.

Welcome to jdoe's dev space

Ensuite, testez le site pour l'utilisateur jdoe2 sur le port 9082.

curl http://localhost:9082

Vous devriez voir le message de bienvenue correspondant.

Welcome to jdoe2's dev space

Ces commandes curl réussies confirment qu'Apache est correctement configuré, que les virtual hosts fonctionnent et que la politique SELinux autorise le trafic sur les ports personnalisés.

Félicitations ! Vous avez réussi à construire un projet d'automatisation Ansible complet qui combine un rôle personnalisé, un rôle provenant d'un dépôt Git et des modules SELinux issus de collections Ansible pour configurer un serveur web de développement sécurisé et multi-tenant.

Résumé

Dans ce laboratoire, vous apprendrez à automatiser la configuration d'un serveur web RHEL en tirant parti de la puissance et de la structure des rôles et collections Ansible. Vous commencerez par créer un rôle personnalisé à partir de zéro en utilisant la commande ansible-galaxy init, qui établit une structure de répertoire standardisée pour un contenu d'automatisation réutilisable. Cette étape fondamentale prépare le terrain pour des tâches d'automatisation plus complexes.

En vous appuyant sur le rôle personnalisé, vous intégrerez ensuite des dépendances externes, notamment un rôle provenant d'un dépôt Git via un fichier requirements.yml et un rôle système RHEL officiel d'une collection Ansible. Enfin, vous assemblerez ces différents types de rôles – personnalisés, basés sur Git et système – en un seul playbook, l'exécuterez pour configurer le serveur, et vérifierez les paramètres Apache et SELinux résultants pour confirmer le succès de l'automatisation.