Ansible Playbooks vs Rollen


97

Laut den Ansible-Dokumenten ist ein Playbook :

... die Basis für ein wirklich einfaches Konfigurationsmanagement- und Multi-Machine-Deployment-System, wie es es noch nicht gibt und das sich sehr gut für die Bereitstellung komplexer Anwendungen eignet.

Und wieder, nach denselben Dokumenten, sind eine Rolle :

... Möglichkeiten zum automatischen Laden bestimmter vars_files, Aufgaben und Handler basierend auf einer bekannten Dateistruktur. Das Gruppieren von Inhalten nach Rollen ermöglicht auch das einfache Teilen von Rollen mit anderen Benutzern.

Die Unterscheidung zwischen diesen und ihren verschiedenen Anwendungsfällen ist mir jedoch nicht sofort klar. Wenn ich meine /etc/ansible/hostsDatei beispielsweise so konfiguriere , dass sie wie folgt aussieht:

[databases]
mydb01.example.org
mydb02.example.org

[mail_servers]
mymail01.example.org
mymail_dr.example.org

... was ist dann dieser " [databases]" Eintrag ... eine Rolle ? Oder irgendwo der Name einer Playbook-YAML-Datei? Oder etwas anderes?!?

Wenn mir jemand die Unterschiede erklären könnte, würde sich mein Verständnis von Ansible erheblich verbessern!

  • Playbook vs Role vs [databases]und ähnliche Einträge in/etc/ansible/hosts
  • Wenn Playbooks in YAML-Dateien definiert sind, wo sind dann Rollen definiert?
  • ansible.cfgWie kann ich Ansible mit den verfügbaren Playbooks / Rollen hinzufügen / konfigurieren, abgesehen davon , dass ich auf dem Ansible-Server lebe? ansible-playbook someplaybook.yamlWoher weiß Ansible beispielsweise beim Ausführen , wo sich das Playbook befindet?

1
Rollen sind eine Möglichkeit, Code in Playbooks wiederverwendbar zu machen, indem die Funktionalität in verallgemeinerte "Bibliotheken" gestellt wird, die dann bei Bedarf in jedem Playbook verwendet werden können.
Juan Jimenez

tasksSachen machen. playbooksAufgaben organisieren und starten. rolesOrganisieren Sie eine Reihe von Aufgaben, Handlern usw., die eine bestimmte Funktion ausführen. Einige playbookwerden benötigt, um die role(s) zu starten . Wie würden Sie eine Sammlung von rolesund nennen playbooks? Sagen Sie zum Beispiel einen, der die Konfiguration aller Hosts an Ihrem Standort verwaltet?
fbicknel

Antworten:


110

Playbook vs Role vs [Datenbanken] und ähnliche Einträge in / etc / ansible / hosts

[databases]ist ein einzelner Name für eine Gruppe von Hosts. Sie können mehrere Hosts mit einem einzigen Namen referenzieren.

Die Rolle besteht aus einer Reihe von Aufgaben und zusätzlichen Dateien, mit denen der Host für eine bestimmte Rolle konfiguriert werden kann .

Playbook ist eine Zuordnung zwischen Hosts und Rollen.

Beispiel aus Dokumentation beschreibt Beispielprojekt. Es enthält zwei Dinge:

  • Spielbücher. site.yml, webservers.yml, fooservers.ymlSind Spielbücher.
  • Rollen: roles/common/und roles/webservers/enthalten Definitionen commonund webserversRollen entsprechend.

In playbook ( webservers.yml) hast du so etwas wie:

---
- hosts: webservers <- this group of hosts defined in /etc/ansible/hosts, databases and mail_servers in example from your question
  roles: <- this is list of roles to assign to these hosts
     - common
     - webservers

Wenn Playbooks in YAML-Dateien definiert sind, wo sind dann Rollen definiert?

Sie werden in roles/*Verzeichnissen definiert . Rollen werden hauptsächlich mithilfe von YAML-Dateien definiert, können jedoch auch Ressourcen eines beliebigen Typs ( files/, templates/) enthalten. Laut Dokumentation ist die Rollendefinition folgendermaßen strukturiert:

  • Wenn die Rollen / x / task / main.yml vorhanden sind, werden die darin aufgeführten Aufgaben zum Spiel hinzugefügt
  • Wenn die Rollen / x / handlers / main.yml vorhanden sind, werden die darin aufgeführten Handler zum Spiel hinzugefügt
  • Wenn die Rollen / x / vars / main.yml vorhanden sind, werden die darin aufgeführten Variablen zum Spiel hinzugefügt
  • Wenn Rollen / x / meta / main.yml vorhanden sind, werden alle darin aufgeführten Rollenabhängigkeiten zur Liste der Rollen hinzugefügt (1.3 und höher).
  • Alle Kopieraufgaben können auf Dateien in den Rollen / x / files / verweisen, ohne sie relativ oder absolut pfaden zu müssen
  • Alle Skriptaufgaben können auf Skripte in den Rollen / x / files / verweisen, ohne sie relativ oder absolut pfaden zu müssen
  • Alle Vorlagenaufgaben können auf Dateien in den Rollen / x / templates / verweisen, ohne sie relativ oder absolut pfaden zu müssen
  • Alle Include-Tasks können auf Dateien in Rollen / x / Tasks / verweisen, ohne sie relativ oder absolut zupfaden zu müssen

Die wichtigste Datei ist roles/x/tasks/main.yml, hier definieren Sie Aufgaben, die ausgeführt werden, wenn die Rolle ausgeführt wird.

Wie füge ich neben der Ansible.cfg auf dem Ansible-Server Ansible mit verfügbaren Playbooks / Rollen hinzu / konfiguriere sie? Wenn ich beispielsweise ansible-playbook someplaybook.yaml ausführe, woher weiß Ansible, wo sich dieses Playbook befindet?

$ ansible-playbook someplaybook.yaml

Sucht nach einem Playbook im aktuellen Verzeichnis.

$ ansible-playbook somedir/somedir/someplaybook.yaml

Sucht nach einem Playbook im somedir/somedir/Verzeichnis.

Es liegt in Ihrer Verantwortung, Ihr Projekt mit allen Playbooks und Rollen auf den Server zu stellen. Ansible hat damit nichts zu tun.


Danke @Yaroslav Admin (+1) - eine kurze Frage: Sie geben an, dass Rollen in Verzeichnissen definiert sind , aber was richtet die Rolle dann tatsächlich ein? Mit anderen Worten, das webservers.ymlPlaybook ordnet die [webservers]Hosts der Rolle commonund webserverszu. Aber was genau ist in der commonRolle enthalten? Es gibt keine Möglichkeit, dies in Verzeichnissen zu definieren. Befinden sich also normalerweise YAML-Dateien in diesen "Rollenverzeichnissen"? Danke noch einmal!
Smeeb

@smeeb Ja, Ihre richtige Rolle wird durch Dateien in diesem Verzeichnis definiert. Sie sind meistens YAML, können aber auch andere Dateitypen enthalten. Weitere Informationen finden Sie in der aktualisierten Antwort.
Jaroslawischer Admin

36

Playbook vs Role vs [Datenbanken] und ähnliche Einträge in / etc / ansible / hosts

Rollen sind eine Möglichkeit, Aufgaben in einem Container zusammenzufassen. Sie könnten eine Rolle für das Einrichten von MySQL haben, eine andere für das Einrichten von Postfix usw.

Ein Spielbuch definiert, was wo passiert . Hier definieren Sie die Hosts (Hostgruppen, siehe unten) und die Rollen, die auf diese Hosts angewendet werden.

[databases]und die anderen Einträge in Ihrem Inventar sind Hostgruppen. Hostgruppen definieren eine Reihe von Hosts, auf denen ein Spiel ausgeführt wird.

Ein Spiel ist eine Reihe von Aufgaben oder Rollen (oder beides) in einem Spielbuch. In den meisten Fällen (und Beispielen) enthält ein Spielbuch nur ein einziges Spiel. Aber Sie können so viele haben, wie Sie möchten. Das heißt, Sie könnten ein Playbook haben, in dem die Rolle postfixin der Hostgruppe mail_serversund die Rolle mysqlin der Hostgruppe ausgeführt werden databases:

- hosts: mail_servers
  roles:
    - postfix

- hosts: databases
  roles:
    - mysql

Wenn Playbooks in YAML-Dateien definiert sind, wo sind dann Rollen definiert?

In Ansible ist so ziemlich alles in YAML definiert, was für Rollen und Playbooks zählt.

Wie füge ich neben der Ansible.cfg auf dem Ansible-Server Ansible mit verfügbaren Playbooks / Rollen hinzu / konfiguriere sie? Wenn ich beispielsweise ansible-playbook someplaybook.yaml ausführe, woher weiß Ansible, wo sich dieses Playbook befindet?

AFAIK Sie müssen beim Aufrufen den Pfad zum Playbook angeben ansible-playbook. So ansible-playbook someplaybook.yamlerwarten würde someplaybook.yamlin Ihnen aktuelle Verzeichnis. Sie können jedoch den vollständigen Pfad angeben:ansible-playbook /path/to/someplaybook.yaml


13

Es ist eine terminologische / semantische Frage. Es kann subjektiv sein, obwohl es eine Basisdefinition gibt.

Meine Ansicht ist wie folgt:

Jedes Konfigurationsmanagement- / Bereitstellungssystem verfügt über:

  1. source data - Daten, die zum Erstellen der Konfiguration des Zielhosts verwendet werden
  2. target data - Daten zur Identifizierung von Zielhosts
  3. config changes- Liste / Satz von Regeln / Aktionen, die wir mit source dataOver-Target-Host basierend auf anwendentarget data

In Ansible Begriffen:

  1. source data- sind die verschiedenen Orte, an denen wir Daten ablegen können - group_vars, playbookvars, rolevars usw. Diese Orte wirken sich auf die Priorität aus (wenn eine gleichnamige Variable an verschiedenen Orten neu definiert wird, gibt es sehr spezifische Regeln für den Wert von Variable während ansible/ ansible-playbookAusführung
  2. target data - ist das Inventar (und es ist auch möglich, Inventar- / Hostgruppenvariablen innerhalb des Inventars zu definieren!)
  3. config changes - ansible hat 4 Abstraktionsebenen:
    1. Aufgabe - Einzelaktion
    2. Aufgabenliste - Liste der Aktionen
    3. Rolle - Liste der Aktionen (oder Liste der Listen), die nach demselben 'Betreff' gruppiert sind. Normalerweise arbeiten alle Ziele auf demselben Host / derselben Hostgruppe
    4. Playbook - Liste der Spiele, die jeweils auf einer möglicherweise anderen Hostgruppe ausgeführt werden und mehrere roleS / taskS / Tasklisten (und spezielle Aufgaben wie handlers) anwenden.

Unter dem Aspekt "Software" sollte die Rolle generisch genug sein, um wiederverwendet zu werden .

Auch in einigen (ziemlich großen) Organisationen werden "Rollen" von Gruppe A ausgeliefert, während sie in Spielbüchern verwendet werden, die von Gruppe B verwaltet werden.

Zusammenfassung

All dies ermöglicht die Gruppierung ähnlicher Konfigurationen - in a role. Gruppieren verwandter Subsysteme / Komponenten in einem playbook. Auch erwähnenswert, 1 YAML Artikel in einem Textbuch (einschließlich hosts:und entweder oder tasks, pre_tasks, post_tasks, roles) heißt eineplay

Nun zu Ihrer Frage:

Ja, es ist zunächst verwirrend.

Normalerweise verbinden Sie source dataIhre mit der Semantik Ihrer Rolle. Wenn Sie also sehen, dass diese Rolle setup_dbin einem Spiel auf eine verwandte Hostgruppe angewendet wird (z. B. db_hosts), playkann a jedoch über eine Vereinigung mehrerer Hostgruppen laufen. Es ist nur eine Frage der Konvention gegen Flexibilität.

PS

Bitte schreiben Sie mir zurück, ob dies zur Verwirrung beigetragen oder geklärt hat. Vielen Dank.


1

Denken Sie auch daran, dass ein Playbook mehr als eine Rolle aufrufen kann, wenn eine Metadatei verwendet wird, die die verschiedenen Rollen beeinflussen soll.

Beispiel Playbook: dual_role-playbook.yml

- name: Some Action for two roles
  hosts: localhost

  vars_files:
    - roles/dual_role/meta/main.yml

  roles:
    - dual_role/container-1
    - dual_role/container-2

Das Schema für Rollenordner und Dateien sieht folgendermaßen aus:

dual_role-playbook.yml
  -- roles
     -- dual_role
        -- meta/main.yml
        -- container-1
           -- tasks/main.yml
           -- templates/template.j2
        -- container-2
           -- tasks/main.yml
           -- templates/template.j2

0

Einfach gesagt:

Ein Playbook ist wie das Hauptprogramm, es enthält vollständige Anweisungen zum Beenden des Jobs. Bei großen Projekten ist es jedoch nicht wünschenswert, tatsächlich jedes Detail darin zu platzieren. Du brauchst also eine Rolle.

Eine Rolle ist eine Unterroutine und erreicht normalerweise ein Ziel, z. B. das Einrichten eines Datenbankservers. Sie können es in ein roles/Verzeichnis stellen oder Rollen von Drittanbietern herunterladen, indem Sie URIs in angebenrolesfile.yml und ansible-galaxy bitten , diese für Sie herunterzuladen.

Dies [database]ist eine in der Inventardatei definierte Hostgruppe, in der Hosts aufgelistet sind, die zur databaseGruppe gehören. Sie können auch eine Gruppe von Webservern angeben, indem Sie Folgendes angeben

[web]
web1.example.com
web2.example.com

Gruppe weboder databasekann dann in Playbooks oder Rollen verwendet werden, um die anzuwendenden Hosts anzugeben.

Die Gruppen können auch im Befehl ansiblezum Ausführen von Ad-hoc-Befehlen verwendet werden.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.