Natuurlijk! Hieronder vind je een overzichtelijke aanpak voor het ontwikkelen van een Ansible-playbook dat het patchbeheerproces automatiseert, inclusief patchcontroles, planning, rollback-strategieën en meldingsmethoden voor je systemen web-01 en web-02, met een wekelijkse patchfrequentie. ### 1. Patchcontroles - **Detectie van beschikbare updates**: Gebruik Ansible-modules zoals `yum` (voor RHEL/CentOS) of `apt` (voor Debian/Ubuntu) om te controleren op updates zonder ze direct te installeren. - **Voorbeeld**: ```yaml - name: Check for available updates hosts: web-01, web-02 become: yes tasks: - name: Check updates (YUM) yum: list: updates register: yum_updates - name: Check updates (APT) apt: upgrade: dist update_cache: yes register: apt_updates ``` ### 2. Patchplanning - **Automatisering met cron**: Plan een wekelijkse taak via cron of een Ansible-timer om het playbook uit te voeren. - **Gebruik van Ansible Tower/AWX**: voor geautomatiseerde planning en monitoring. - **Voorbeeld van een cron-job** (bijvoorbeeld elke zondagavond): ```bash 0 22 * * 0 /usr/bin/ansible-playbook /pad/naar/patch.yml ``` ### 3. Patchuitrol en rollback-strategieën - **Stapsgewijze patching**: Voer eerst op één systeem een test uit, wacht op feedback, en rol dan uit naar andere systemen. - **Back-ups**: Maak vooraf een volledige back-up of snapshot van de systemen (bijvoorbeeld via `rsync`, `btrfs` snapshots, of VM snapshots). - **Rollback**: - **Rollback scripts**: Bewaar oude versies of snapshots en gebruik Ansible-rollen of taken om deze te herstellen indien nodig. - **Voorbeeld**: ```yaml - name: Rollback naar snapshot bij mislukking hosts: web-01, web-02 become: yes tasks: - name: Restore snapshot (voorbeeld met btrfs) command: btrfs subvolume snapshot /backup/snapshot /root/ when: patch_failed ``` ### 4. Detectie en afhandeling van problemen - **Monitoring**: Controleer services en logs na patching. - **Automatische rollback**: Als een patch misgaat (bijvoorbeeld door foutmeldingen of failed services), trigger dan een rollback. ### 5. Meldingsmethoden - **E-mail**: Gebruik Ansible's `mail` module of externe tools zoals SendGrid. - **Slack/Teams**: Verstuur meldingen via webhook-plugins. - **Voorbeeld van een e-mailmelding na patchen**: ```yaml - name: Verstuur melding mail: host: smtp.example.com port: 587 username: user@example.com password: wachtwoord to: admin@example.com subject: "Patch status voor {{ inventory_hostname }}" body: | De patchupdate op {{ inventory_hostname }} is succesvol voltooid. ``` - **Voor failed patches**: ```yaml - name: Melding bij patch failure mail: host: smtp.example.com port: 587 username: user@example.com password: wachtwoord to: admin@example.com subject: "Foutmelding: Patchupdate op {{ inventory_hostname }}" body: | Er is een probleem opgetreden tijdens het patchen van {{ inventory_hostname }}. Gelieve de logs te controleren en een rollback uit te voeren indien nodig. ``` --- ### Samenvatting - **Patchcontroles**: Controleer op updates zonder direct te installeren. - **Planning**: Automatiseer met cron of Ansible AWX voor wekelijkse uitvoering. - **Rollback**: Maak vooraf back-ups of snapshots, en definieer herstelprocedures. - **Meldingen**: Gebruik e-mail, Slack, of Teams voor statusrapportages en incidentmeldingen. Met deze aanpak zorg je voor een veilig, gestructureerd en geautomatiseerd patchbeheerproces dat snel reageert op problemen en je systeem up-to-date houdt.

Hier is een gedetailleerd Ansible-playbook voor patchbeheer met bijbehorende uitleg: ## Ansible Playbook: Patching Automation ```yaml --- - name: Wekelijks Patchbeheer voor Web Servers hosts: web_servers become: yes vars: patch_frequency: "wekelijks" security_updates_only: true reboot_required: false maintenance_window: "02:00-04:00" pre_tasks: - name: Onderhoudsmode inschakelen voor web servers uri: url: "http://{{ inventory_hostname }}/maintenance" method: POST body: "{"status": "maintenance"}" delegate_to: localhost run_once: true tasks: - name: Beschikbare updates controleren package_facts: manager: auto register: package_facts - name: Security updates identificeren apt: update_cache: yes upgrade: yes autoremove: yes autoclean: yes when: ansible_os_family == "Debian" register: apt_updates - name: YUM security updates yum: name: "*" state: latest security: yes when: ansible_os_family == "RedHat" register: yum_updates - name: Reboot indien vereist reboot: msg: "Reboot vereist na patching" connect_timeout: 5 reboot_timeout: 300 pre_reboot_delay: 0 post_reboot_delay: 30 test_command: uptime when: reboot_required | bool post_tasks: - name: Services status controleren systemd: name: "{{ item }}" state: started enabled: yes loop: - nginx - apache2 - httpd ignore_errors: yes register: services_status - name: Onderhoudsmode uitschakelen uri: url: "http://{{ inventory_hostname }}/maintenance" method: POST body: "{"status": "active"}" delegate_to: localhost run_once: true handlers: - name: herstart services systemd: name: "{{ item }}" state: restarted loop: "{{ services_to_restart }}" - name: send notification debug: msg: "Notificatie verzonden voor {{ inventory_hostname }}" ``` ## Rollback Strategie ```yaml - name: Rollback Playbook hosts: web_servers become: yes vars: rollback_snapshot: true tasks: - name: Vorige package versies herstellen apt: name: "{{ item.name }}" state: "{{ item.version }}" with_items: "{{ previous_versions }}" when: ansible_os_family == "Debian" - name: System restore vanuit snapshot command: /usr/bin/system-restore latest when: rollback_snapshot | bool - name: Configuratie backup terugzetten copy: src: "/backups/{{ inventory_hostname }}/config_backup.tar.gz" dest: "/tmp/restore/" remote_src: yes ``` ## Notificatie Implementatie ```yaml - name: Patch Notificaties hosts: localhost tasks: - name: Succes notificatie - Email mail: host: smtp.gmail.com port: 587 username: "noreply@example.com" password: "{{ smtp_password }}" to: "sysadmin@example.com" subject: "Patching voltooid voor {{ groups['web_servers'] | join(', ') }}" body: | Patching proces succesvol afgerond op {{ ansible_date_time.iso8601 }} Betrokken servers: {{ groups['web_servers'] | join(', ') }} Aantal updates: {{ update_count }} - name: Fout notificatie - Slack slack: token: "{{ slack_token }}" msg: "❌ Patching mislukt voor {{ inventory_hostname }}" channel: "#system-alerts" username: "Ansible Patching Bot" when: patching_failed | bool - name: Kritieke fout - SMS via Twilio twilio: account_sid: "{{ twilio_sid }}" auth_token: "{{ twilio_token }}" from_number: "+1234567890" to_number: "+31612345678" body: "CRITICAL: Patching failure on {{ inventory_hostname }}" when: critical_failure | bool ``` ## Inventory Bestand ```ini [web_servers] web-01 ansible_host=192.168.1.10 ansible_user=admin web-02 ansible_host=192.168.1.11 ansible_user=admin [web_servers:vars] ansible_ssh_private_key_file=~/.ssh/id_rsa ``` ## Implementatie Details ### Patch Planning - **Frequentie**: Wekelijks (elke zondag om 02:00) - **Venster**: 2-uur onderhoudsvenster - **Scope**: Alleen security updates ### Monitoring & Meldingen 1. **Succesvolle patches**: - Email rapport naar sysadmin team - Slack notificatie in #deployments kanaal 2. **Mislukte patches**: - Directe Slack alert in #system-alerts - SMS notificatie voor kritieke failures - Gedetailleerde error logs naar centrale logging ### Rollback Procedures - Automatische package version tracking - Pre-patch configuratie backups - Snapshot-based restore opties - Gedocumenteerde handmatige rollback stappen ### Best Practices - Test patches eerst in staging omgeving - Geleidelijke rollout (canary deployment) - Uitgebreide pre- en post-patch validatie - Gedetailleerde audit logs voor compliance Dit playbook biedt een complete automation oplossing voor wekelijkse patching van je web servers met robuuste error handling en notificaties.