Einführung
Ein installiertes Paket, eine vorhandene Konfigurationsdatei und ein antwortender Dienst sind unterschiedliche Ergebnisse. Sie verwalten jedes ausdrücklich: ein Hilfsprogramm installieren und entfernen, nginx konfigurieren, dessen laufenden Zustand deklarieren und geänderte Konfiguration über einen Handler neu laden. Tatsächliche HTTP-Antworten beider verwalteter Knoten belegen, dass der Dienst funktioniert.
Installierte und abwesende Paketzustände deklarieren
In diesem Schritt installieren Sie ein kleines Hilfsprogramm, untersuchen es und entfernen es über eine wiederverwendbare Paketdeklaration.
Das apt-Modul verwaltet Ubuntu-Pakete auf dem verwalteten Host. state: present fordert Installation an, state: absent Entfernung. Diese Umgebung enthält vorbereitete Paketlisten und zwischengespeicherte Downloads; behalten Sie daher update_cache: false bei. Das Aktualisieren der Listen oder Anfordern neuester Versionen würde unnötige Netzwerkabhängigkeiten hinzufügen. Aktualisierungsrichtlinien in Produktionsumgebungen können abweichen.
Wechseln Sie ins Controller-Projekt:
cd /home/labex/project
Erstellen Sie ein Playbook, dessen Variable den gewünschten Zustand des Pakets tree auswählt. Paketoperationen erfordern become auf den Zielen. install_recommends: false vermeidet optionale empfohlene Pakete.
cat > packages.yml <<'YAML'
- name: Declare a utility package state
hosts: all
gather_facts: false
become: true
vars:
utility_state: present
tasks:
- name: Converge the tree package
ansible.builtin.apt:
name: tree
state: "{{ utility_state }}"
update_cache: false
install_recommends: false
YAML
Installieren Sie das Hilfsprogramm:
ansible-playbook packages.yml
Der Befehl tree zeigt Verzeichnisbäume an; hier belegt seine Versionsoption, dass die ausführbare Datei tatsächlich auf jedem verwalteten Knoten installiert ist:
ansible all -m ansible.builtin.command -a 'tree --version'
Jedes Ziel sollte eine tree-Version zurückgeben. Wiederholen Sie das Playbook; vorhandene Pakete sollten keine erneute Installation benötigen:
ansible-playbook packages.yml
Fordern Sie nun mit einer zusätzlichen Variable Abwesenheit an, statt die wiederverwendbare Aufgabe zu bearbeiten:
ansible-playbook packages.yml -e utility_state=absent
Wiederholen Sie dieselbe gewünschte Abwesenheit. Beide Zusammenfassungszeilen sollten jetzt changed=0, failed=0 und unreachable=0 zeigen:
ansible-playbook packages.yml -e utility_state=absent
Paketzustand ist eine Deklaration über Installation, kein Nachweis, dass ein Dienst läuft oder antwortet. Lassen Sie tree abwesend, während der nächste Schritt nginx bereitstellt.
Einen tatsächlichen Webdienst konfigurieren und starten
In diesem Schritt installieren Sie nginx, verteilen eine vollständige validierte Konfiguration und halten dessen Dienst ausdrücklich am Laufen.
Die beiden verwalteten Knoten sind Container mit separaten SSH-Endpunkten und Dateisystemen. Sie führen kein systemd aus. Das service-Modul verwendet ihren verfügbaren Dienstmanager; führen Sie auf diesen Zielen kein systemctl aus. Wir verwalten den aktuellen laufenden Zustand, statt eine systemd-Startregel zu versprechen.
Erstellen Sie eine statische Seite auf dem Controller. Sie endet mit einem Zeilenumbruch, damit ihre exakten verwalteten Bytes vorhersagbar sind:
printf 'Ansible service ready\n' > page.txt
Schreiben Sie eine vollständige nginx-Konfiguration. events und http sind nginx-Kontexte auf oberster Ebene, server definiert eine Website, listen wählt Port 8080 aus, root ihr Dokumentverzeichnis und index die Seite für /-Anfragen. Dies sind nginx-Einstellungen, kein Ansible-YAML.
cat > nginx-course.conf <<'NGINX'
events {}
http {
server {
listen 8080;
root /var/www/ansible-site;
index index.html;
}
}
NGINX
Erstellen Sie das Bereitstellungs-Playbook. Die apt-Aufgabe verwendet policy_rc_d: 101, um einen impliziten nginx-Start durch den Paketinstaller zu verhindern; die spätere service-Aufgabe deklariert ausdrücklich den laufenden Zustand. validate der copy-Aufgabe führt den nginx-Konfigurationstest gegen einen temporären Kandidaten (%s) aus, bevor das Ziel ersetzt wird.
Ein Handler ist eine benannte Aktion unter handlers. Eine geänderte Konfigurationsaufgabe benachrichtigt Reload nginx, der einmal am Ende des Plays läuft. Keine Konfigurationsänderung bedeutet keine Benachrichtigung. Die gewöhnliche service-Aufgabe verwendet started, das einen bereits laufenden Dienst ohne bedingungslosen Neustart am Laufen hält.
cat > web.yml <<'YAML'
- name: Deploy a working web service
hosts: all
gather_facts: false
become: true
tasks:
- name: Install nginx without refreshing the prepared package lists
ansible.builtin.apt:
name: nginx
state: present
update_cache: false
install_recommends: false
policy_rc_d: 101
- name: Prepare the site directory
ansible.builtin.file:
path: /var/www/ansible-site
state: directory
owner: root
group: root
mode: "0755"
- name: Deploy the static page
ansible.builtin.copy:
src: /home/labex/project/page.txt
dest: /var/www/ansible-site/index.html
owner: root
group: root
mode: "0644"
- name: Validate and deploy nginx configuration
ansible.builtin.copy:
src: /home/labex/project/nginx-course.conf
dest: /etc/nginx/nginx.conf
owner: root
group: root
mode: "0644"
validate: /usr/sbin/nginx -t -c %s
notify: Reload nginx
- name: Keep nginx running
ansible.builtin.service:
name: nginx
state: started
handlers:
- name: Reload nginx
ansible.builtin.service:
name: nginx
state: reloaded
YAML
Prüfen Sie die Syntax und wenden Sie anschließend die Bereitstellung an:
ansible-playbook web.yml --syntax-check
ansible-playbook web.yml
Beide Knoten sollten nginx installieren, die Dateien erhalten und erfolgreich starten. Eine erste Konfigurationsänderung plant auch den Reload-Handler ein. Die Prüfung einer Paketversion allein würde keines dieser Dienstverhalten belegen.
curl ist ein HTTP-Client. Seine Option --fail behandelt einen erfolglosen HTTP-Status als Befehlsfehler; --silent entfernt Fortschrittsausgaben und --show-error erhält Fehlerdetails. Führen Sie ihn auf jedem verwalteten Host gegen dessen eigene Loopback-Schnittstelle aus:
ansible all -m ansible.builtin.command -a 'curl --fail --silent --show-error http://127.0.0.1:8080/'
Jedes Ergebnis sollte Ansible service ready enthalten. Controller und jedes Ziel haben separate Loopback-Schnittstellen; dieser Befehl prüft beide Zieldienste statt des Controllers.
Eine Konfigurationsänderung über einen Handler anwenden
In diesem Schritt ändern Sie eine aktive nginx-Einstellung, beobachten den Handler und bestätigen die Einstellung durch eine HTTP-Antwort.
Die nginx-Direktive server_tokens steuert, ob Antwortheader die nginx-Version offenlegen. Fügen Sie server_tokens off innerhalb von http hinzu, indem Sie die Controller-Konfiguration durch diese vollständige Version ersetzen:
cat > nginx-course.conf <<'NGINX'
events {}
http {
server_tokens off;
server {
listen 8080;
root /var/www/ansible-site;
index index.html;
}
}
NGINX
Wenden Sie dasselbe Playbook an:
ansible-playbook web.yml
Die Konfigurationskopie sollte changed melden und Reload nginx auf beiden Hosts benachrichtigen. Der Handler lädt den laufenden Dienst neu, nachdem die neue Konfiguration die Validierung bestanden hat. Seine Ausführung macht die Konfiguration wirksam; das bloße Kopieren einer Datei belegt nicht, was der Prozess geladen hat.
-I von curl fordert HTTP-Header an. Untersuchen Sie die tatsächliche Dienstantwort auf beiden Hosts:
ansible all -m ansible.builtin.command -a 'curl --fail --silent --show-error -I http://127.0.0.1:8080/'
Beide Antworten sollten einen erfolgreichen HTTP-Status und einen Server-Header nginx ohne Versionssuffix haben. Andere Headerfelder wie Datumsangaben variieren.
Wiederholen Sie das vollständige Playbook:
ansible-playbook web.yml
Beide Hosts sollten changed=0 ohne fehlgeschlagene oder unerreichbare Aufgaben melden, und kein Reload-Handler sollte eingeplant werden. Die statische Seite bleibt verfügbar, tree bleibt abwesend und nginx bleibt installiert und läuft.
Zusammenfassung
Sie haben Anwesenheit und Abwesenheit von Paketen deklariert, Installation vom laufenden Dienstzustand getrennt und eine vollständige nginx-Konfiguration mit Kandidatenvalidierung verteilt. Eine geänderte Konfiguration benachrichtigte einen Reload-Handler, tatsächliche HTTP-Antworten belegten das aktive Verhalten, und eine unveränderte Wiederholung vermied zusätzliche Änderungen oder erneutes Laden.
