Contactez-nous

Copie le fichier `index.html` dans le répertoire web par défaut de Nginx

Apprenez à utiliser le module copy d'Ansible pour déployer votre fichier index.html dans le répertoire web par défaut de Nginx ou Apache, en gérant les permissions.

Le déploiement du contenu : donner vie à notre site

Après avoir installé Nginx (ou Apache) et s'être assuré que son service est opérationnel, l'étape finale pour rendre notre site web accessible est de déployer le contenu réel. Dans notre cas, il s'agit du fichier index.html que nous avons créé localement sur notre noeud de contrôle Ansible.

Cette tâche consiste à transférer ce fichier depuis le noeud de contrôle vers le noeud géré, et plus précisément dans le répertoire racine des documents (document root) que Nginx (ou Apache) est configuré pour servir. Ansible fournit le module ansible.builtin.copy, qui est idéal pour cette opération. Ce module permet non seulement de copier des fichiers, mais aussi de définir leurs permissions et leur propriétaire sur la machine distante.

La précision est ici essentielle : le fichier doit être placé au bon endroit, avec les bonnes permissions, pour que le serveur web puisse le lire et le servir correctement aux navigateurs des visiteurs.

Utilisation du module `ansible.builtin.copy`

Le module ansible.builtin.copy est l'outil de choix pour transférer des fichiers ou des arborescences de répertoires depuis la machine de contrôle vers les noeuds gérés. Pour notre fichier index.html, la tâche ressemblerait à ceci :

- name: Copier le fichier index.html vers la racine web de Nginx
  ansible.builtin.copy:
    src: files/index.html  # Chemin source sur le noeud de contrôle
    dest: /var/www/html/index.html # Chemin de destination sur le noeud géré
    owner: www-data        # Utilisateur propriétaire sur la destination
    group: www-data        # Groupe propriétaire sur la destination
    mode: '0644'           # Permissions du fichier sur la destination

Décortiquons les paramètres :

  • src: files/index.html : C'est le chemin vers le fichier source sur votre noeud de contrôle. Si vous utilisez un chemin relatif comme ici, Ansible le recherche par rapport à l'emplacement du playbook, souvent dans un sous-répertoire nommé files/. Vous pourriez aussi fournir un chemin absolu.
  • dest: /var/www/html/index.html : C'est le chemin complet où le fichier sera copié sur le noeud géré. /var/www/html/ est un répertoire racine web courant pour Nginx et Apache sur les systèmes Debian/Ubuntu. Pour Nginx sur CentOS/RHEL, ce pourrait être /usr/share/nginx/html/. Pour Apache sur CentOS/RHEL, c'est souvent aussi /var/www/html/. Il est crucial d'adapter ce chemin à la configuration de votre serveur web et à votre distribution.
  • owner: www-data : Spécifie l'utilisateur qui deviendra propriétaire du fichier sur la machine distante. www-data est l'utilisateur sous lequel Nginx et Apache s'exécutent souvent sur Debian/Ubuntu. Sur CentOS/RHEL, ce pourrait être nginx pour Nginx, ou apache pour Apache (httpd).
  • group: www-data : Spécifie le groupe propriétaire du fichier. Mêmes considérations que pour owner.
  • mode: '0644' : Définit les permissions du fichier en notation octale. 0644 (rw-r--r--) signifie que le propriétaire a les droits de lecture et d'écriture, tandis que le groupe et les autres utilisateurs n'ont que le droit de lecture. Ce sont des permissions typiques pour des fichiers web statiques.

Cette tâche nécessite généralement des privilèges administratifs (become: true) pour écrire dans des répertoires système comme /var/www/html et pour changer le propriétaire des fichiers.

Adapter la destination et les propriétaires selon l'OS et le serveur web

Comme mentionné, le chemin de destination (dest) et les informations de propriétaire/groupe (owner/group) peuvent varier. Pour rendre le playbook plus flexible, nous pouvons utiliser des variables basées sur les "facts" d'Ansible, notamment ansible_os_family.

Supposons que nous ayons défini des variables dans la section vars de notre jeu (play) :

vars:
  nginx_doc_root_debian: /var/www/html
  nginx_doc_root_redhat: /usr/share/nginx/html
  nginx_user_debian: www-data
  nginx_user_redhat: nginx
  # Pour Apache
  apache_doc_root_debian: /var/www/html
  apache_doc_root_redhat: /var/www/html
  apache_user_debian: www-data
  apache_user_redhat: apache

Nous pourrions alors avoir une tâche set_fact pour déterminer les bonnes valeurs avant la tâche de copie, ou utiliser des expressions conditionnelles directement, bien que cela puisse alourdir la tâche copy. Une approche avec set_fact pour Nginx :

- name: Déterminer les paramètres Nginx spécifiques à l'OS
  ansible.builtin.set_fact:
    target_doc_root: "{{ nginx_doc_root_debian if ansible_os_family == 'Debian' else nginx_doc_root_redhat }}"
    target_web_user: "{{ nginx_user_debian if ansible_os_family == 'Debian' else nginx_user_redhat }}"
  when: web_server_choice == "nginx" # Supposant une variable 'web_server_choice'

# Puis la tâche de copie utilise {{ target_doc_root }} et {{ target_web_user }}
- name: Copier le fichier index.html pour Nginx
  ansible.builtin.copy:
    src: files/index.html
    dest: "{{ target_doc_root }}/index.html"
    owner: "{{ target_web_user }}"
    group: "{{ target_web_user }}"
    mode: '0644'
  when: web_server_choice == "nginx"
  notify:
    - Restart Nginx # Ou un nom de handler plus générique

L'utilisation de notify est également une bonne pratique. Si le contenu du fichier index.html change (c'est-à-dire si src est différent de dest ou si dest n'existe pas), Ansible copiera le fichier et la tâche sera marquée comme changed. Dans ce cas, elle notifiera un "handler" (par exemple, un handler pour redémarrer Nginx). Cela garantit que si vous mettez à jour votre page d'accueil, le serveur web sera redémarré ou rechargé pour servir la nouvelle version, si nécessaire (bien que pour des fichiers statiques simples, un redémarrage ne soit souvent pas requis, c'est une bonne habitude pour des changements plus complexes).

Intégration dans le Playbook et vérification

Cette tâche de copie est la dernière étape majeure de notre playbook de déploiement. Elle suit l'installation du serveur web et la configuration de son service.

Le playbook complet ressemblerait donc à ceci (version simplifiée pour Nginx sur un système de type Debian) :

- hosts: webservers
  become: true
  tasks:
    - name: Installer Nginx
      ansible.builtin.package:
        name: nginx
        state: present
        update_cache: yes

    - name: S'assurer que Nginx est démarré et activé
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: yes

    - name: Copier le fichier index.html
      ansible.builtin.copy:
        src: files/index.html
        dest: /var/www/html/index.html
        owner: www-data
        group: www-data
        mode: '0644'
      notify:
        - Restart Nginx

handlers:
  - name: Restart Nginx
    ansible.builtin.service:
      name: nginx
      state: restarted

Après l'exécution de ce playbook, vous devriez pouvoir ouvrir un navigateur et accéder à l'adresse IP de votre noeud géré. La page index.html que vous avez créée localement devrait s'afficher. Si ce n'est pas le cas, vérifiez les logs de Nginx sur le serveur (souvent dans /var/log/nginx/) pour des erreurs de permission ou de configuration, et assurez-vous que le chemin dest dans votre tâche copy correspond bien au document root de Nginx.

En maîtrisant le module copy et en comprenant l'importance des chemins et des permissions, vous pouvez déployer n'importe quel site web statique ou les composants statiques d'applications plus complexes avec Ansible.