Kennisbank / Ansible RHEL beheer

Ansible voor RHEL: idempotent beheer met inventory en roles

Auteur: DEWOLF.IT

Betrouwbaar Ansible RHEL beheer beschrijft de gewenste toestand en maakt afwijkingen zichtbaar. Een playbook dat één keer slaagt is een begin; dezelfde uitvoering moet ook herhaalbaar zijn, correct rapporteren en fouten op de juiste plek laten stoppen.

Scope: ansible-core met ansible.builtin-modules op RHEL 8/9; controleer controller-, collection- en Pythoncompatibiliteit.

Toepassing. RHEL 8/9 als managed nodes, met een compatibele ansible-core-controller. Onderstaande voorbeelden gebruiken ansible.builtin; gebruik voor Ansible Automation Platform de ondersteunde execution environment en collectionversies.

Probleem en achtergrond: een groen playbook kan toch slecht beheer zijn

Een playbook kan slagen terwijl het elke keer een configuratie herschrijft, fouten negeert of ongemerkt productie raakt. Idempotency betekent dat dezelfde gewenste toestand bij herhaling geen nieuwe verandering vereist. Dat vraagt meer dan ‘changed_when: false’: die instelling verandert rapportage en maakt een onvoorwaardelijk shellcommando niet vanzelf idempotent.

Begin met de beheerafspraak: welke bestanden en services beheert deze role, wie beheert de overige configuratie en welke afwijkingen zijn toegestaan? Als twee rollen hetzelfde bestand volledig schrijven, ontstaat een conflict dat extra runs niet oplossen. Leg eigenaarschap vast voordat je taken aan het playbook toevoegt.

1. Maak inventory voorspelbaar

Gebruik per omgeving een eigen inventorybron en controleer de samengestelde hostselectie vóór de run. Group- en hostvars zijn krachtig, maar overlappende groepen kunnen variabelen overschrijven. De officiële inventorygids beschrijft de structuur en samenvoeging.

# inventories/test/hosts.yml — uitsluitend voorbeeldhosts
all:
  children:
    rhel_web:
      hosts:
        web01.example.net:
        web02.example.net:
      vars:
        ansible_user: automation

ansible-inventory -i inventories/test/hosts.yml --graph
ansible-inventory -i inventories/test/hosts.yml --host web01.example.net
ansible-playbook -i inventories/test/hosts.yml site.yml --list-hosts

De tweede opdracht kan gevoelige variabelen tonen. Behandel de uitvoer als configuratiegegevens. Bewaar credentials via Vault of het credentialmechanisme van het automationplatform en beperk logtoegang. Een –limit is een extra begrenzing, maar vervangt geen gescheiden omgevingsselectie en rechten.

2. Gebruik roles met een duidelijk contract

Zet herbruikbare taken in tasks/main.yml, handlers in handlers/main.yml en templates in templates/. Geef instelbare waarden defaults; documenteer welke waarden de afnemer mag overschrijven. Roles kunnen dependencies hebben: controleer daarom ook wat een role indirect uitvoert. Zie Roles.

Een role voor webservers kan bijvoorbeeld uitsluitend het pakket, een eigen configuratiesnippet en de servicestatus beheren. Test eerst of de gekozen snippet compatibel is met bestaande virtual hosts, modules en securitybeleid. Het volgende minimale voorbeeld illustreert state- en handlergedrag; het richt geen complete webserver met firewall en TLS in.

# roles/rhel_web/tasks/main.yml
- name: Zorg dat httpd aanwezig is
  ansible.builtin.dnf:
    name: httpd
    state: present

- name: Beheer een eigen configuratiesnippet
  ansible.builtin.copy:
    content: "ServerTokens Prod\nServerSignature Off\n"
    dest: /etc/httpd/conf.d/zz-managed-security.conf
    owner: root
    group: root
    mode: '0644'
  notify: Controleer en herlaad httpd

- name: Zorg dat httpd draait en bij boot start
  ansible.builtin.systemd_service:
    name: httpd
    state: started
    enabled: true

# roles/rhel_web/handlers/main.yml
- name: Controleer en herlaad httpd
  ansible.builtin.command: /usr/sbin/httpd -t
  changed_when: false
  notify: Herlaad httpd

- name: Herlaad httpd
  ansible.builtin.systemd_service:
    name: httpd
    state: reloaded

Bij een gewijzigde snippet controleert de handler de samengevoegde httpd-configuratie en herlaadt alleen na een geslaagde controle. Een afgekeurde snippet staat dan al op disk: het playbook stopt, maar dit is geen automatische rollback. Voor een kritieke configuratie hoort daar staging of een restoreprocedure bij. Een tweede ongewijzigde run hoort de handler niet te activeren.

3. Valideer vóór je gevoelige configuratie vervangt

Een template kan met validate een tijdelijke gerenderde versie controleren vóór plaatsing. De opdracht moet %s bevatten; shellconstructies zoals pipes werken daar niet. Voorbeeld voor een volledige, door jouw role beheerde sshd-configuratie, volgens de template-modulehandleiding:

- name: Plaats een gevalideerde sshd-configuratie
  ansible.builtin.template:
    src: sshd_config.j2
    dest: /etc/ssh/sshd_config
    owner: root
    group: root
    mode: '0600'
    backup: true
    validate: '/usr/sbin/sshd -t -f %s'

sshd_config.j2 en een passend reload-/acceptatieproces moeten daarbij aanwezig zijn. Een syntactisch geldige configuratie kan nog steeds toegang blokkeren. Test authenticatie en behoud een herstelmogelijkheid buiten dezelfde SSH-sessie. Gebruik dit voorbeeld dus niet als vervanging voor een compleet SSH-changeplan.

4. Laat fouten de juiste gevolgen hebben

Gebruik failed_when als een applicatie een afwijkende succes-/foutconventie heeft en changed_when voor juiste wijzigingsrapportage. block/rescue/always kan herstel en opruimen structureren. rescue is geen transactie: eerder uitgevoerde acties worden niet automatisch teruggedraaid. Onbereikbare hosts en ongeldige taakdefinities vallen niet onder gewone rescue-afhandeling. Zie Error handling.

Een genegeerde fout kan leiden tot een half ingerichte host. Gebruik ignore_errors alleen als de vervolgstappen aantoonbaar correct blijven. Werk bij productiepatching met kleine batches, expliciete healthchecks en een stopcriterium. Kies ook bewust wat er met pending handlers gebeurt als een latere taak faalt.

5. Bewijs herhaalbaarheid en functionele werking

ansible-playbook -i inventories/test/hosts.yml site.yml --syntax-check
ansible-playbook -i inventories/test/hosts.yml site.yml --check --diff
ansible-playbook -i inventories/test/hosts.yml site.yml --limit web01.example.net

De laatste run voert echte wijzigingen uit op de geselecteerde testhost. Voer daarna dezelfde run nogmaals uit en onderzoek onverwachte changed-resultaten. Check mode ondersteunt niet iedere taak en is geen bewijs dat runtimegedrag klopt. Diff kan secrets onthullen; zet dat uit of begrens logging voor gevoelige taken.

Enterprise-aandachtspunten en valkuilen

Versiebeheer roles, inventory en execution environments samen met de change. Laat packagekeuzes aansluiten op goedgekeurde Satellite-content. Vermijd state: latest als de afspraak een vaste release is. Meet behalve het play-recap ook de applicatiefunctie: een running service kan nog steeds foutieve antwoorden geven.

Bronnen en versiecontrole

Technische referenties geraadpleegd op 30 september 2026. Controleer bij uitvoering de documentatie en manpages van de geïnstalleerde versie.

Ansible inventory
Ansible roles
Template-validatie
Foutafhandeling en handlers
Check mode en diff mode

Gerelateerde artikelen

Red Hat Satellite: gecontroleerd patchen met content views
SELinux AVC-denials oplossen: contexts, booleans en policy
systemd troubleshooting: services, dependencies en restart-beleid

Ondersteuning bij jouw platform

Wil je deze aanpak vertalen naar jouw omgeving? Bekijk Automation & Ansible of neem contact op met DEWOLF.IT.