Wiederverwendbare Automatisierung als Rolle bündeln

Einführung

Rollen bündeln eine funktionierende Automatisierungseinheit, sodass Nutzer Daten bereitstellen können, ohne die Implementierung zu duplizieren. Sie erstellen eine Rolle mit öffentlichen Standardwerten, erzeugen hostspezifische Seiten, behalten Konfigurationsvalidierung und Neuladeverhalten innerhalb der Rolle und verwenden sie für zwei Inventargruppen wieder. Tatsächliche verwaltete Dateien und HTTP-Antworten überprüfen, dass die Rolle tatsächlich aufgerufen wird.

Eine Rolle mit Standardwerten erstellen und aufrufen

In diesem Schritt verschieben Sie Websiteautomatisierung in eine Rolle und rufen sie über ein kurzes Playbook mit wiederverwendbaren Standardeingaben auf.

Eine Rolle gruppiert zusammengehörige Aufgaben, Standardvariablen, Vorlagen und Handler in einem Standardverzeichnis. Ihre tasks/main.yml ist der Aufgabeneinstiegspunkt; defaults/main.yml liefert Werte niedriger Priorität, die Nutzer überschreiben können. Vorlagenquellen gehören unter templates, und handlers/main.yml enthält später durch Änderungen ausgelöste Dienstaktionen.

Das vorbereitete Inventar ordnet web1 bereits canary und web2 stable unter der übergeordneten Gruppe sites zu. Nginx ist als Voraussetzung installiert. Untersuchen Sie die Gruppen:

cd /home/labex/project

ansible-inventory --graph

Erstellen Sie die Rollenverzeichnisse mit mkdir -p. Mehrere Pfadargumente erstellen jedes benannte Verzeichnis:

mkdir -p roles/managed_site/tasks roles/managed_site/defaults roles/managed_site/templates roles/managed_site/handlers

Stellen Sie öffentlichen Rollenvariablen site_ voran, um ihren Zweck deutlich zu machen. Beginnen Sie mit gemeinsamen Standardwerten, die jeder Nutzer verwenden kann:

cat > roles/managed_site/defaults/main.yml <<'YAML'
site_environment: training
site_port: 8080
site_maintenance: false
YAML

Die Seitenvorlage verwendet die Rolleneingabe zusammen mit dem Namen jedes Ziels und seiner erfassten Distribution:

cat > roles/managed_site/templates/page.txt.j2 <<'JINJA'
host={{ inventory_hostname }}
environment={{ site_environment }}
distribution={{ ansible_facts.distribution }}
JINJA

Erstellen Sie den Aufgabeneinstiegspunkt der Rolle. Innerhalb einer Rolle wird src: page.txt.j2 unter deren Verzeichnis templates aufgelöst; das Ziel bleibt ein absoluter verwalteter Pfad:

cat > roles/managed_site/tasks/main.yml <<'YAML'
- name: Prepare the role-managed website directory
  ansible.builtin.file:
    path: /var/www/role-site
    state: directory
    owner: root
    group: root
    mode: "0755"

- name: Render the role-managed page
  ansible.builtin.template:
    src: page.txt.j2
    dest: /var/www/role-site/index.html
    owner: root
    group: root
    mode: "0644"
YAML

Rufen Sie die Rolle mit dem Schlüsselwort roles auf. Das umgebende Play wählt Ziele aus, erfasst Facts und fordert become an; die Rolle liefert die wiederverwendbaren Aufgaben:

cat > site.yml <<'YAML'
- name: Apply the managed site role with defaults
  hosts: sites
  gather_facts: true
  become: true
  roles:
    - managed_site
YAML

Validieren Sie die Rolle und führen Sie sie über ihr nutzendes Playbook aus:

ansible-playbook site.yml --syntax-check

ansible-playbook site.yml

Untersuchen Sie die tatsächlich von der Rolle erstellten Seiten:

ansible sites -m ansible.builtin.command -a 'cat /var/www/role-site/index.html'

Beide sollten environment=training aus dem Standardwert sowie ihren eigenen Hostnamen und distribution=Ubuntu zeigen. Das bloße Erstellen von Rollenverzeichnissen würde weder die Rolle ausführen noch diese verwalteten Dateien erstellen.

Vorlagen und Handler innerhalb der wiederverwendbaren Rolle behalten

In diesem Schritt lassen Sie die Rolle die Website konfigurieren und betreiben, einschließlich Kandidatenvalidierung und eigenem Reload-Handler.

Legen Sie die vollständige nginx-Vorlage neben die Seitenquelle. Sie verwendet die site_-Eingaben der Rolle, den zuvor geübten Filter upper und einen booleschen Zweig:

cat > roles/managed_site/templates/nginx.conf.j2 <<'JINJA'
events {}
http {
    server_tokens off;
    server {
        listen {{ site_port }};
        root /var/www/role-site;
        index index.html;
        add_header X-Environment "{{ site_environment | upper }}" always;
{% if site_maintenance %}
        add_header X-Maintenance "enabled" always;
{% else %}
        add_header X-Maintenance "disabled" always;
{% endif %}
    }
}
JINJA

Hängen Sie Rollenaufgaben an, die die erzeugte Konfiguration vor dem Ersetzen validieren und nginx ausdrücklich gestartet halten. Die geänderte Konfiguration benachrichtigt den benannten Handler der Rolle:

cat >> roles/managed_site/tasks/main.yml <<'YAML'

- name: Render and validate the role-managed nginx configuration
  ansible.builtin.template:
    src: nginx.conf.j2
    dest: /etc/nginx/nginx.conf
    owner: root
    group: root
    mode: "0644"
    validate: /usr/sbin/nginx -t -c %s
  notify: Reload managed site

- name: Keep the role-managed service running
  ansible.builtin.service:
    name: nginx
    state: started
YAML

Schreiben Sie den Handler in den Handler-Einstiegspunkt der Rolle, statt ihn in jedem nutzenden Playbook zu duplizieren:

cat > roles/managed_site/handlers/main.yml <<'YAML'
- name: Reload managed site
  ansible.builtin.service:
    name: nginx
    state: reloaded
YAML

Führen Sie das unveränderte nutzende Playbook aus. Die Rolle liefert nun ihr vollständiges Bereitstellungsverhalten:

ansible-playbook site.yml

Beide Hosts sollten ihre eigene Website auf dem Standardport 8080 starten. Untersuchen Sie jedes Ziel über seinen eigenen Loopback-Endpunkt:

ansible sites -m ansible.builtin.command -a 'curl --fail --silent --show-error -i http://127.0.0.1:8080/'

Jeder Antwortinhalt sollte seinen eigenen Host und environment=training identifizieren. Header sollten X-Environment: TRAINING und X-Maintenance: disabled enthalten. Die Ausgabe stammt von laufenden, durch die Rolle konfigurierten Diensten statt einer reinen Controller-Demonstration.

Dieselbe Rolle mit Gruppenvariablenüberschreibungen wiederverwenden

In diesem Schritt wenden Sie dieselbe Rolle auf zwei Gruppenkontexte an, ohne ihre wiederverwendbaren Standardwerte oder Aufgabendateien zu bearbeiten.

Rollenstandardwerte haben bewusst niedrige Priorität. Inventargruppenvariablen können diese öffentlichen Eingaben überschreiben und dieselbe Implementierung behalten. Lassen Sie defaults/main.yml unverändert und erstellen Sie die Nutzerdaten jeder Gruppe:

cat > group_vars/canary.yml <<'YAML'
site_environment: development
site_port: 8081
site_maintenance: true
YAML

cat > group_vars/stable.yml <<'YAML'
site_environment: production
site_port: 8082
site_maintenance: false
YAML

Ersetzen Sie das nutzende Playbook durch zwei Plays, die dieselbe Rolle managed_site aufrufen. Jede Gruppe erhält ihre eigenen aufgelösten Eingaben. Duplizieren Sie das Rollenverzeichnis nicht für jede Umgebung:

cat > site.yml <<'YAML'
- name: Apply the shared role to canary
  hosts: canary
  gather_facts: true
  become: true
  roles:
    - managed_site

- name: Apply the shared role to stable
  hosts: stable
  gather_facts: true
  become: true
  roles:
    - managed_site
YAML

Validieren Sie beide Kontexte und wenden Sie sie an:

ansible-playbook site.yml --syntax-check

ansible-playbook site.yml

Beide Umgebungen sollten ihre geänderte Konfiguration über den rollenlokalen Handler laden. Untersuchen Sie die tatsächlichen Endpunkte an ihren neu konfigurierten Ports:

ansible canary -m ansible.builtin.command -a 'curl --fail --silent --show-error -i http://127.0.0.1:8081/'

ansible stable -m ansible.builtin.command -a 'curl --fail --silent --show-error -i http://127.0.0.1:8082/'

Canary sollte web1 und development mit DEVELOPMENT/enabled-Headern identifizieren. Stable sollte web2 und production mit PRODUCTION/disabled-Headern identifizieren. Diese Unterschiede stammen aus Gruppeneingaben, während eine gemeinsame Rolle weiterhin Standardwerte, Aufgaben, Vorlagen und Handler besitzt.

Wiederholen Sie dasselbe nutzende Playbook:

ansible-playbook site.yml

Beide Zusammenfassungszeilen sollten changed=0, unreachable=0 und failed=0 melden, ohne eingeplanten Handler. Eine wiederverwendbare Rolle muss aufgerufen werden und korrekten konvergierten verwalteten Zustand erzeugen; ein Verzeichnisgerüst allein ist keine Bereitstellung.

Zusammenfassung

Sie haben Standardwerte, Aufgaben, Vorlagen und Handler in einer aufgerufenen Rolle organisiert. Standardwerte niedriger Priorität unterstützten Überschreibungen durch Nutzer, und zwei Inventargruppen verwendeten dieselbe Implementierung wieder, um unterschiedliche tatsächliche Dienste zu erzeugen. Kandidatenvalidierung, durch Änderungen ausgelöstes Neuladen und unveränderte wiederholte Ausführung blieben Teil der wiederverwendbaren Einheit.