Ansible: Mehrere Dateien im Standardverzeichnis der Rolle

Sie können ein main.yml in tasks haben, das andere Dateien einschließt, sogar in Unterverzeichnissen von tasks , zB um Ihre beiden Hauptkomponenten foo und bar dieser großen Rolle zu konfigurieren:

- include: foo/main.yml
- include: bar/main.yml

Die Verwendung eines include_vars Moduls für Standardrollenvariablen beseitigt den Grund, warum Standardvariablen überhaupt existieren, nämlich dass sie verwendet werden, um "letzte Ausweg-Standardeinstellungen" bereitzustellen, die leicht von anderen Teilen der Rolle/des Spielbuchs überschrieben werden können.

Die Idee mehrerer Dateien im Verzeichnis defaults/ wurde zuvor im IRC diskutiert. Wir kamen zu dem Schluss, dass das Parsen des Verzeichnisses defaults/ ähnlich den Verzeichnissen inventory/group_vars/ und inventory/host_vars/ wäre schön zu haben. Der benötigte Code ist bereits vorhanden und kann hoffentlich leicht für Rollenvoreinstellungen angepasst werden.

+1

+1

Wäre schön es zu haben!

+1

Ja, nur angenommen, dass defaults/* gefunden und automatisch geladen wurden, wie oben erwähnt. Es scheint, dass die vorgeschlagene Problemumgehung (einschließlich zusätzlicher Standarddateien in Aufgaben) Bestandsvariablen aufgrund der Variablenpriorität überschreibt, so dass wir möglicherweise in einer Datei bündeln müssen, um dieses Problem zu vermeiden, bis es behoben ist.

Vorrang von Ansible 2.x-Variablen

    role defaults [1] (loading all role defaults here critical)
    inventory vars [2]
    inventory group_vars
    inventory host_vars
    playbook group_vars
    playbook host_vars
    host facts
    registered vars
    set_facts
    play vars
    play vars_prompt
    play vars_files
    role and include vars (hack coming in here will override everything above)
    block vars (only for tasks in block)
    task vars (only for the task)
    extra vars (always win precedence)

Dies könnte mit #8121 zusammenhängen

+1

+1

Auf jeden Fall ein Must-Have-Feature aufgrund von Einschränkungen der variablen Rangfolge.
Dies ermöglicht es auch, eine Standarddatei pro Variablenklasse zu definieren und eine saubere Trennung zu gewährleisten; Im Netzwerk könnte ich beispielsweise eine Standarddatei für IPv4, eine für IPv6, eine für SNMP usw. definieren...
Endlich scheint es notwendig zu sein, diese Dateien in verschiedenen Ordnern unter "Standardeinstellungen" ablegen zu können.

Einfach selbst getroffen, also definitiv +1

Das ist wirklich ein PITA.
Wenn ich eine Lösung vorschlagen könnte, wäre es, eine Option hinzuzufügen, ähnlich wie include_vars , aber in meta/main.yml , um die Ladereihenfolge anzugeben.

- dependencies: []
- default_vars:
  - "main.yml"
  - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"

Dies würde es der Option ermöglichen, standardmäßig ["main.yml"] und bestehenden Code nicht zu beschädigen, während Entwickler die Möglichkeit haben, granulare Variablen basierend auf Kontexten ihrer Wahl zu definieren.

Seltsam. Ich hatte den Verdacht, dass dies sofort funktionieren würde. Einer der wenigen Ansible verstößt tatsächlich ein wenig gegen das Prinzip der geringsten Überraschung...

Auf jeden Fall +1

Für vars/ dasselbe, aber #2958 scheint sich dagegen entschieden zu haben

Das Beispiel von

Eine andere Schnittstellenoption wäre:

• Fügen Sie dem include_vars-Modul eine Option hinzu, 'as_default', die die eingeschlossene Datei verarbeitet, als ob sie in den Standardeinstellungen wäre.

Für mich sieht es wirklich seltsam / kontraintuitiv aus, dass es ein Verzeichnis "defaults" mit einer einzelnen Datei gibt.
Ich meine, haben Sie jemals ein Python-Modul mit einer einzigen __main__.py Datei darin gesehen?

Genau aus diesem Grund dachte ich intuitiv, dass die auf diesem Ticket angesprochene Funktionalität bereits vorhanden ist. "Natürlich kann ich mehrere Standarddateien haben, dafür gibt es ein Verzeichnis"

include_role können Sie jetzt "alternative" Dateien angeben http://docs.ansible.com/ansible/include_role_module.html über die Option defaults_from

Ich bin gerade in eine Situation geraten, in der eine Aufteilung von defaults/main.yml erwünscht ist. Mein 👍 zum Thema hinzugefügt.

Das gleiche hier, ich brauche es auch
+1

+1

@bcoca das ist eine nette Ergänzung und

Bitte überprüfen Sie meinen Kommentar oben

Ja, dies ist eine sehr hilfreiche Funktion, um Dateien mit 2k-Linien zu vermeiden.
+1

+1

+1

👍

+1

+1

+1
Gleiches Problem hier. main.yml zu groß, in mehrere Dateien aufgeteilt. Wir gingen davon aus, dass es "einfach funktionieren" würde und alle Variablen in den Dateien unter defaults/ laden würde, da es sich um ein Verzeichnis handelt. keine Freude.

+1

+1

+1

👍

+1

+1

👍

Sie können jeden +1-Kommentar mit dem Daumen runterdrücken, aber ich bezweifle stark, dass Sie die Anzahl der Abonnenten verfolgen können, daher ist das Hinzufügen von +1 immer noch eine anständige Möglichkeit, die gewünschte Unterstützung zu zeigen.

Bis die Aufmerksamkeit der Ausgabe eindeutig an die Anzahl der Abonnenten einer Ausgabe gebunden ist, können Sie für immer mit +1-Kommentaren rechnen.

Was Sie erwarten können ist, dass das Ansible-Team stattdessen die Problemkommentare sperrt, seien Sie also kein Spammer und verteidigen Sie sie bitte nicht.

Was Sie erwarten können ist, dass das Ansible-Team stattdessen die Problemkommentare sperrt, seien Sie also kein Spammer und verteidigen Sie sie bitte nicht.

Sie könnten das tun, aber dies ist ein Kernproblem, um Rollen richtig entwickeln zu können, insbesondere seit der Einführung von include_role in 2.x neben der alten Include-Methode roles . Wenn Sie Ihre Rolle so gestalten, dass sie mit include_role kompatibel ist, was vorzuziehen ist, da es die Entwicklung viel modularer und flexibler macht als mit der alten Methode roles allein, dann bleiben Sie mit um entweder selbst Standardeinstellungen als Aufgaben in Ihre Playbooks aufzunehmen, das Geld an den Endbenutzer weiterzugeben, der nicht wissen sollte, wie dies zu tun ist, damit Ihre Rolle richtig funktioniert, oder die Plattform/Distribution/Veröffentlichung als verschachtelte Ebene von Ihnen zu verfolgen Rolle Variablen , die die Hölle aus Entwicklung erschwert (obwohl es funktioniert wie Ive eine Rolle erstellt , die 20 verschiedene Plattform - Versionen unterstützen kann hier ). Haben Sie tatsächlich versucht, eine Rolle zu schreiben, die tatsächlich mehr als nur ein paar Plattformen unterstützt? Es ist keine Überraschung, warum die meisten Rollen auf Ansible Galaxy dies nicht tun. Dieses Problem ist wahrscheinlich die Nummer eins auf dieser Liste IMO.

Wenn sie dies also sperren, überhaupt nicht auf ein Jahr altes Problem reagieren und der Community signalisieren, dass sie nicht daran interessiert sind, kritische Probleme zu diskutieren, die Menschen daran hindern, echte Lösungen zu finden, dann können sie definitiv erwarten, dass die Leute nicht kleben bleiben herum und verwenden Sie das Produkt weiter. Wenn sie antworten und ein Gefühl dafür geben, ob sie damit einverstanden sind, werden die Leute vielleicht aufhören, ihr +1 zu geben, um auf das Problem aufmerksam zu machen.

Dies ist nur ein Problem, weil sie include_role ohne darüber nachzudenken, wie sich die tatsächliche Verwendung in der Praxis auf die Standardeinstellungen auswirken würde. Jemanden zu zwingen, zwischen der Verwendung von roles und include_role zu wählen, damit eine Rolle richtig funktioniert, oder zusätzliche Arbeit hinzuzufügen, damit beide gleichzeitig arbeiten können, ist hier der Kern des Problems.

Meine 2 Cent.

PS Wenn Sie +1 ablehnen, weil Sie die Benachrichtigungen nicht möchten .... klicken Sie auf die Schaltfläche zum Abmelden oben rechts und Sie werden sie nicht mehr erhalten.

Okay, dieses Thema ist wichtig für Sie. Ich verstehe. Für mich auch. Deshalb habe ich mich übrigens abonniert, und deshalb möchte ich mich nicht abmelden, und deshalb stimme ich Spammern ab, und deshalb stimme ich dem ursprünglichen Kommentar zu , der die zivilisierte Art ist , _faul_ Unterstützung dafür zu zeigen.

Ich möchte der Anfrage nach dieser Fähigkeit meine Stimme hinzufügen und meinen Anwendungsfall näher erläutern. Neben der einfachen Möglichkeit, große main.yml aufzuteilen, wäre die Möglichkeit, so etwas zu tun, großartig:

- name: Some name
  include_default_vars:
  with_first_found:
    - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"
   - main.yml

Was ich damit erreichen möchte, ist [als Beispiel] eine openssh-Rolle, die alle ssh_config- und sshd_config-Optionen unterstützt und mehrere Betriebssysteme und Versionen unterstützt [dh. Debian 8/9, EL6/7, etc], die jedoch, wenn sie ohne vom Benutzer gesetzte Vars aufgerufen wird, die Konfiguration sicher auf die Standardeinstellungen von OS_majorversion aufbauen wird, bei der jedoch JEDE verfügbare Option vom Benutzer überschrieben werden kann.

Wenn ich diese Betriebssystem-Standardeinstellungen jetzt in include_vars setze, ist die Priorität zu hoch, und der Benutzer kann diese Einstellungen im Inventar oder in group_vars/all oder in group_vars/groupname oder in host_vars usw.

Ich bin sicher, es gibt jetzt eine Möglichkeit , dies zu tun, aber alles, was mir einfällt, ist äußerst unanständig und hässlich und wäre schwer zu pflegen. Außerdem hat, zumindest bis zu diesem Punkt, niemand, den ich kennengelernt habe, bessere Ideen, wie man dies auf anmutige und wartbare Weise tun kann.

Das Hinzufügen dieser Funktion würde dies ermöglichen und dazu beitragen, dass Rollen in höherer Qualität in github/galaxy verfügbar gemacht werden.

@ralphie02 nein, das ist nicht annähernd eine Lösung für das, worum es in diesem Thread geht. Das sind nur normale hostbasierte Variablen, die sich von der Anforderung unterscheiden, Standardwerte für eine Multiplattformrolle festzulegen.

Ähnliche vars / feature_idea: https://github.com/ansible/ansible/issues/11639

Das ist wirklich ein PITA.
Wenn ich eine Lösung vorschlagen könnte, wäre es, eine Option hinzuzufügen, ähnlich wie include_vars , aber in meta/main.yml , um die Ladereihenfolge anzugeben.

- dependencies: []
- default_vars:
  - "main.yml"
  - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"

Dies würde es der Option ermöglichen, standardmäßig ["main.yml"] und bestehenden Code nicht zu beschädigen, während Entwickler die Möglichkeit haben, granulare Variablen basierend auf Kontexten ihrer Wahl zu definieren.

Ich denke wirklich, dass dies eine gute Lösung ist, es gibt derzeit keine wirklich einfache Möglichkeit, einen anderen Satz von Standardeinstellungen nach Betriebssystem/Version/etc. Diese Implementierung behält auch die Abwärtskompatibilität bei und ist daher auch eine gute Wahl.

Im Einklang mit @abedwardsw (Kommentar vorher):
Der > 2 Jahre alte Vorschlag von @cornfeedhobo (15 :+1: !) (oder etwas neuer von @doubletwist13 ) wäre für viele Rollen, die ich kenne, wirklich nützlich, insbesondere für die Komplexität genug:
https://github.com/hortonworks/ansible-hortonworks

Direkte Verweise auf ihre Kommentare:

• https://github.com/ansible/ansible/issues/14248#issuecomment -254059046
• https://github.com/ansible/ansible/issues/14248#issuecomment -329027052

Siehe auch den Vorschlag von @geerlingguy (von 2016!) und meinen Kommentar dort (der versucht, verwandte Probleme zu sammeln): https://github.com/ansible/proposals/pull/21#issuecomment -470048538