Module hostname Ansible : définir le nom d'hôte

ansible.builtin.hostname: définit le nom d'hôte d'un managed node, opération simple mais critique pour l'identification dans le réseau, la configuration DNS, et l'intégration dans des outils d'automation. Le module modifie /etc/hostname (sur RHEL/AlmaLinux) et applique le changement immédiatement sans reboot.

C'est l'un des premiers modules appliqués dans un playbook de provisioning : avant tout autre rôle, on s'assure que la machine a le bon nom.

Ce que vous allez apprendre

• Définir un nom d'hôte simple ou un FQDN complet.
• Aligner le hostname sur l'inventory_hostname Ansible.
• Distinguer ansible_hostname (nom court) de ansible_fqdn (nom complet).
• Comprendre la persistance (/etc/hostname) vs le runtime (hostnamectl).
• Diagnostiquer un hostname qui revient au défaut au reboot.

Prérequis

• become: true sur le managed node (modification de /etc/hostname).
• Connaître la différence FQDN vs hostname (web1 vs web1.lab.example.com).

Définir un nom d'hôte simple

- name: Definir le nom d hote
  ansible.builtin.hostname:
    name: web01

Le nom court web01 devient le hostname. Le module modifie /etc/hostname ET appelle hostnamectl set-hostname, le changement est immédiat ET persistant au reboot.

Définir un FQDN

- name: Definir un FQDN comme nom d hote
  ansible.builtin.hostname:
    name: app01.lab.example.com

Sur les distributions modernes (RHEL 7+, AlmaLinux, Rocky), le FQDN complet est accepté comme hostname. Pratique pour des environnements DNS internes où chaque machine a son nom complet enregistré.

À surveiller : certains outils legacy (rsyslog, snmpd) lisent uniquement le nom court. Vérifier la conformité avant de pousser un FQDN.

Aligner sur inventory_hostname

Pattern fréquent, utiliser le nom de l'inventaire Ansible comme hostname :

- name: Hostname = nom dans l inventaire
  ansible.builtin.hostname:
    name: "{{ inventory_hostname }}"

Avantages :

• Cohérence entre l'inventaire Ansible et la machine réelle.
• Idempotent : si le hostname est déjà aligné, changed=0.
• Pas de drift : à chaque run, le hostname est ré-aligné si quelqu'un l'a modifié à la main.

Variante avec inventory_hostname_short (sans .lab) :

- name: Définir le nom de machine
  ansible.builtin.hostname:
    name: "{{ inventory_hostname_short }}"

use:, choisir la stratégie

Sur certaines distributions, le module supporte plusieurs stratégies d'application :

- name: Définir le nom de machine web01
  ansible.builtin.hostname:
    name: web01
    use: systemd   # systemd | redhat | debian | freebsd | openrc | ...

use: force l'implémentation. Par défaut, Ansible auto-détecte selon ansible_os_family. À ne forcer que si le défaut pose problème (rare).

Hostname runtime vs persistant

Distinction importante :

Commande Linux	Effet
hostname web01	Runtime uniquement, perdu au reboot.
echo web01 > /etc/hostname	Persistant mais pas appliqué maintenant.
hostnamectl set-hostname web01	Les deux, runtime + /etc/hostname.

Glissez pour voir

Le module Ansible fait l'équivalent de hostnamectl set-hostname sur les systèmes systemd : runtime + persistance en une opération atomique.

Vérifier le résultat

Le module dit ce qu'il a fait, la machine dit ce qu'elle porte : relire la valeur après coup est la seule façon de recouper les deux. La tâche de lecture porte changed_when: false, faute de quoi le compte rendu du play annoncerait une modification à chaque passage alors que rien n'a bougé.

Après application :

Après application :

- name: Hostname
  ansible.builtin.hostname:
    name: "{{ inventory_hostname }}"

- name: Verifier le hostname runtime
  ansible.builtin.command: hostname
  register: current_hostname
  changed_when: false

- name: Afficher
  ansible.builtin.debug:
    msg: "Hostname runtime : {{ current_hostname.stdout }}"

Pour un test plus complet :

ssh ansible@web1.lab 'hostname && hostnamectl status'

Pièges courants

Les deux premières lignes se ressemblent mais n'ont pas la même cause : un nom posé hors du module ne survit pas au redémarrage, un fact collecté trop tôt affiche l'ancien nom alors que la machine porte déjà le nouveau. Les deux dernières touchent aux règles de nommage, qu'aucune distribution ne contourne.

Symptôme	Cause	Fix
Hostname revient au défaut au reboot	hostname CLI utilisé au lieu du module	Toujours utiliser ansible.builtin.hostname:
Hostname appliqué mais ansible_hostname reste l'ancien	Facts mis en cache	meta: clear_facts ou re-gather
FQDN refusé sur RHEL 6 (legacy)	Distribution trop ancienne	Migrer vers RHEL 8+ ou utiliser nom court
Hostname avec underscore _	RFC 952/1123 interdit _	Utiliser tirets - à la place

Glissez pour voir

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• ansible.builtin.hostname: modifie runtime + /etc/hostname en une opération.
• name: "{{ inventory_hostname }}" = pattern standard pour aligner inventaire et machine.
• FQDN accepté sur RHEL 7+ (vérifier les outils legacy avant).
• Pas d'underscore dans un hostname (RFC 952/1123).
• Idempotent : si déjà à la bonne valeur, changed=0.

Pour aller plus loin

• Module getent : vérifier la résolution du nom que vous venez de poser, via la base hosts de NSS.
• debug, setup, add_host, group_by : recollecter les facts pour que ansible_hostname reflète le nouveau nom.
• Écrire ses premiers rôles : regrouper nommage, réseau et paramètres système dans un rôle de socle.

×

📖 Voir la documentation →