Einführung
Zuverlässige Zeitplanung benötigt mehr Nachweise als eine erfolgreiche Play-Zusammenfassung. Sie verteilen ein geschütztes Berichtsprogramm für einen gewöhnlichen Benutzer, verwalten einen stabil benannten Cron-Eintrag, beobachten reguläre Ausführungen, aktualisieren seine Phase und entfernen einen separaten temporären Eintrag. Die Abschlussprüfung beobachtet einen neuen Scheduler-Lauf und erhält dabei den unabhängigen bestehenden Job.
Einen Bericht für einen gewöhnlichen Benutzer und einen benannten Zeitplan bereitstellen
In diesem Schritt verteilen Sie ein bereitgestelltes Berichtsprogramm und planen es für den Benutzer automation auf beiden verwalteten Hosts ein.
Cron ist installiert und sein Daemon läuft bereits als Voraussetzung. Die Knoten führen kein systemd aus. Jede automation-Crontab enthält außerdem einen unabhängigen Eintrag keep-existing-report; erhalten Sie ihn. Das cron-Modul verwaltet einen stabil benannten Eintrag, statt die gesamte Crontab des Benutzers zu ersetzen.
Wechseln Sie ins Projekt und untersuchen Sie das bereitgestellte Controller-Programm:
cd /home/labex/project
cat files/host-report.sh
Das Programm hängt einen UTC-Epochenzeitstempel, den tatsächlichen Hostnamen und das Phasenargument an ein geschütztes verwaltetes Protokoll an. Umask 027 gibt neuen Protokolldateien Modus 0640. Lassen Sie das Programm unverändert und lassen Sie cron es regulär ausführen; ein manueller Aufruf würde den Zeitplan nicht nachweisen.
Definieren Sie die Phase als wiederverwendbare Eingabe:
cat > group_vars/all.yml <<'YAML'
report_phase: initial
YAML
Erstellen Sie das Playbook. Ein Cronjob hat Felder für Minute, Stunde, Tag des Monats, Monat und Wochentag; ein Stern in jedem Feld führt einmal pro Minute aus. Der Name erstellt eine Ansible-Markierung für spätere Aktualisierungen, und user automation wählt die Crontab dieses Benutzers aus. Become erlaubt die Verwaltung des Zeitplans dieses benannten Benutzers und ausdrücklichen Dateieigentums; es lässt das geplante Programm nicht als root laufen.
cat > reporting.yml <<'YAML'
- name: Manage a scheduled ordinary-user host report
hosts: all
gather_facts: false
become: true
tasks:
- name: Prepare the ordinary user's reporting directory
ansible.builtin.file:
path: /home/automation/reporting
state: directory
owner: automation
group: automation
mode: "0750"
- name: Deploy the supplied report program
ansible.builtin.copy:
src: /home/labex/project/files/host-report.sh
dest: /home/automation/reporting/host-report.sh
owner: automation
group: automation
mode: "0750"
- name: Keep the named report schedule present
ansible.builtin.cron:
name: ansible-host-report
user: automation
minute: "*"
hour: "*"
day: "*"
month: "*"
weekday: "*"
job: "/home/automation/reporting/host-report.sh {{ report_phase }}"
YAML
Validieren Sie und wenden Sie an:
ansible-playbook reporting.yml --syntax-check
ansible-playbook reporting.yml
Untersuchen Sie die tatsächlichen automation-Crontabs. Der Befehl läuft mit become, damit er das abgefragte Konto ausdrücklich benennen kann:
ansible all -b -m ansible.builtin.command -a 'crontab -u automation -l'
Jede sollte eine Markierung ansible-host-report und den minütlichen Befehl sowie den unveränderten Eintrag keep-existing-report enthalten. Eine Crontab-Zeile allein belegt keine Ausführung.
Warten Sie auf den ersten regulären Scheduler-Zeitpunkt. timeout begrenzt die Wartezeit auf 90 Sekunden; die until-Schleife von bash prüft alle zwei Sekunden auf ein nicht leeres Protokoll. Der Befehl liest lediglich Zustand, während cron das Protokoll erstellt:
ansible all -m ansible.builtin.command -a "timeout 90 bash -c 'until test -s /home/automation/reporting/host-report.log; do sleep 2; done'"
ansible all -m ansible.builtin.command -a 'cat /home/automation/reporting/host-report.log'
Jede sollte einen Datensatz wie time= host=web1 phase=initial haben, mit dem entsprechenden tatsächlichen Hostnamen auf web2. Die Zeitstempel variieren und sollten zur regulären minütlichen Planung passen. Falls die begrenzte Wartephase fehlschlägt, untersuchen Sie Zeitplan und laufenden Daemon, statt selbst ein Erfolgsprotokoll zu schreiben.
Einen benannten Eintrag aktualisieren und die neue Phase beobachten
In diesem Schritt ändern Sie die Eingabe des Jobs und erhalten dabei seine stabile Identität und den unabhängigen Zeitplan.
Aktualisieren Sie den gespeicherten Phasenwert. Die cron-Aufgabe erzeugt den neuen Befehl unter Beibehaltung desselben Namens:
cat > group_vars/all.yml <<'YAML'
report_phase: verified
YAML
ansible-playbook reporting.yml
Untersuchen Sie beide Crontabs erneut:
ansible all -b -m ansible.builtin.command -a 'crontab -u automation -l'
Pro Host sollte weiterhin exakt ein Eintrag ansible-host-report existieren, der nun mit verified endet. Die Wiederverwendung seines Namens aktualisiert den bestehenden Eintrag, statt einen zweiten Zeitplan anzusammeln. Keep-existing-report muss unverändert bleiben.
Warten Sie auf eine neue reguläre Ausführung mit der aktualisierten Phase. grep -q prüft ohne Ausgabe auf einen passenden Protokolldatensatz; timeout und die until-Schleife begrenzen die Wartezeit:
ansible all -m ansible.builtin.command -a "timeout 90 bash -c 'until grep -q phase=verified /home/automation/reporting/host-report.log; do sleep 2; done'"
ansible all -m ansible.builtin.command -a 'cat /home/automation/reporting/host-report.log'
Beide sollten nun einen neuen Datensatz phase=verified vom tatsächlichen Scheduler enthalten. Die älteren initial-Datensätze sind nützliche Historie und sollten erhalten bleiben. Das Aktualisieren eines Crontab-Befehls ändert alte Protokollzeilen nicht rückwirkend.
Nur einen benannten temporären Job entfernen und Berichterstellung stabil halten
In diesem Schritt entfernen Sie einen temporären Zeitplan anhand seines stabilen Namens und überprüfen, dass der vorgesehene Bericht des gewöhnlichen Benutzers weiterhin ausgeführt wird.
Erstellen Sie mit einer Ad-hoc-cron-Aufgabe einen harmlosen benannten temporären Eintrag. Er plant /usr/bin/true für Mitternacht ein und stellt einen tatsächlichen zu entfernenden Eintrag bereit:
ansible all -b -m ansible.builtin.cron -a 'name=ansible-temporary-report user=automation minute=0 hour=0 job=/usr/bin/true'
ansible all -b -m ansible.builtin.command -a 'crontab -u automation -l'
Schreiben Sie ein kleines Aufräum-Playbook. State absent und passender name/user entfernen nur diesen verwalteten Eintrag. Leeren oder ersetzen Sie nicht die vollständige Crontab:
cat > cleanup.yml <<'YAML'
- name: Remove only the obsolete named schedule
hosts: all
gather_facts: false
become: true
tasks:
- name: Remove the obsolete report entry by its stable name
ansible.builtin.cron:
name: ansible-temporary-report
user: automation
state: absent
YAML
ansible-playbook cleanup.yml
ansible all -b -m ansible.builtin.command -a 'crontab -u automation -l'
Die temporäre Markierung und der Befehl sollten verschwunden sein. Sowohl ansible-host-report mit Phase verified als auch keep-existing-report sollten erhalten bleiben.
Wiederholen Sie beide Deklarationen:
ansible-playbook reporting.yml
ansible-playbook cleanup.yml
Beide Playbooks sollten für beide Hosts changed=0, unreachable=0 und failed=0 melden. Cron kann unabhängig weiter Protokolldatensätze anhängen; diese regulären Laufzeitdatensätze beeinträchtigen die Idempotenz der deklarativen Bereitstellung nicht.
Die Abschlussprüfung untersucht benannte Jobs des gewöhnlichen Benutzers, das exakte verteilte Programm und geschützte Protokolle und wartet anschließend auf einen weiteren regulären Scheduler-Zeitpunkt auf beiden Hosts. Dies kann ungefähr eine Minute dauern. Lassen Sie Berichtszeitplan und Daemon laufen, damit diese Beobachtung fortlaufende Ausführung statt einer manuell vorbereiteten Erfolgsdatei belegen kann.
Zusammenfassung
Sie haben stabil benannte Cron-Einträge für den vorgesehenen gewöhnlichen Benutzer verwaltet, tatsächliche geplante Ausführung beobachtet, Befehlseingaben ohne Duplizierung des Jobs aktualisiert und ausschließlich einen temporären Eintrag entfernt. Ausdrückliche Programm-/Protokollberechtigungen und erhaltene unabhängige Zeitpläne hielten den Geltungsbereich klar. Die Bereitstellung wiederholte sich ohne Änderungen, während der Bericht regulär weiterlief.
