Ansible-role-nginx-config: Fehlende Standardeinstellungen für nginx_main_template.*

Stimme voll und ganz zu @alexsegura. Die Möglichkeit, einzelne Parameter zu definieren, befindet sich im Backlog. Die Entwicklung der Rolle war in letzter Zeit etwas langsamer, als ich es gerne hätte, aber die Dinge sollten in den nächsten Monaten wieder anziehen. Wenn Sie möchten, können Sie jedoch gerne eine PR einreichen 😄

Danke für deine Nachricht.
Ja, ich kann einen Pull Request beisteuern 🙂

Das Problem, das ich hier und da in dieser Rolle sehe, ist, dass die Standardeinstellungen fest codiert sind.
Wenn sich die Standardeinstellungen ändern, müssen Sie daran denken, sie sowohl in defaults/main.yml als auch in Vorlagen zu ändern.

https://github.com/nginxinc/ansible-role-nginx/blob/a92d424bdb5dc51b143c702754bed761e919a576/tasks/conf/upload-config.yml#L8 -L14

Ich vermute, es liegt daran, dass bei der Verwendung von dicts für Standardwerte diese ersetzt werden. Es gibt eine hash_behavior- Einstellung, aber ich denke, sie ist global.

Kennen Sie eine Möglichkeit, die "unberührten" Standardvariablen für eine Rolle abzurufen?
Etwas wie role_defaults['var_name'] ?

@alexsegura Ich kenne keine großartige Möglichkeit, dieses Verhalten zu erreichen. Idealerweise möchten Sie ein Setup, bei dem die Rolle eine nützliche Konfiguration bereitstellen kann, ohne einen der Werte in defaults/main.yml .

Der Hauptgedanke, der mir in den Sinn kommt, wäre, vars/main.yml zu verwenden, um einige der Standardwerte hart zu codieren und dann etwas wie | default(var_main_upload_src) tun, aber ich bin mir nicht sicher, ob dies der beste Weg ist.

Die einzige Möglichkeit, dies zu tun, ist wahrscheinlich in der Vorlage selbst mit dem Standardfilter.

Richtig, das ist eine gute Lösung für vorlagenbezogene Parameter (und wenn Sie sich die Vorlagendateien ansehen, wird der Standardfilter bereits an einigen Stellen verwendet). Und zugegebenermaßen würde das das ursprüngliche Problem lösen. Es wäre eine ziemlich zeitaufwendige Aufgabe, aber es ist machbar.

Es bleibt jedoch die Frage, was der beste Ansatz für nicht vorlagenbezogene Variablen ist, und gibt es darüber hinaus einen besten Ansatz?

Von dem, was ich hier und da sehe, besteht der beste Ansatz für Standardeinstellungen darin, die Verwendung von Diktaten zu vermeiden, z

nginx_main_template_user: www-data

Anstatt von

nginx_main_template:
  user: www-data

Das würde das Problem teilweise lösen, und zunächst war die Rolle so strukturiert. Aber als ich anfing, komplexere Templating-Optionen (zB mehrere Standortblöcke) einzuführen, machten Wörterbücher und Listen mehr Sinn.

Oder Sie könnten separate Wörterbücher für die Standard- und Benutzerkonfiguration verwenden und sie mit dem combine Filter zusammenführen. Ich habe eine Rolle verwendet, um den Luftstrom bereitzustellen, wenn diese Methode verwendet wird:
airflow_config: "{{ airflow_defaults_config | combine(airflow_user_config, recursive=True) }}"
Ich denke, dies würde auch die Notwendigkeit beseitigen, fest codierte Standardwerte in den Vorlagen zu haben?

Die Rolle , die ich mich beziehe , kann ausgecheckt werden hier .

Hm, das ist ein interessanter Ansatz, und ich kann sehen, dass er funktioniert. Vielleicht lohnt es sich, einen kleinen PoC mit einem der kleineren Wörterbücher (ich denke an die Vorlagen main oder stream ) zu erstellen, um zu sehen, wie gut es in der Praxis funktioniert.

Ich habe dies bereits für die Hauptvorlage ausprobiert und es hat wie erwartet funktioniert. Da ich jedoch den Weg mit dem geringsten Aufwand gegangen bin, habe ich zwei Wörterbücher nginx_default_main_template aus den Standardeinstellungen und nginx_user_main_template aus dem Playbook des Benutzers in nginx_main_template .
Dies würde eine grundlegende Änderung einführen, sodass ich die Rolle umgestalten werde, um das zusammengeführte Wörterbuch unter einem neuen Namen zu verwenden und eine PR einzureichen.

Die http-Vorlage ist viel schwieriger, da möglicherweise mehrere Benutzerwörterbücher zusammengeführt werden müssen. Anker und Aliase in Kombination mit dem Zusammenführungsoperator könnten eine Alternative sein, aber dann ist der Benutzer für die Zusammenführung verantwortlich.
Ich werde auch einige Zeit an dieser Front verbringen.

Übrigens: Gibt es einen Grund, warum Sie sich dafür entschieden haben, ein Wörterbuch anstelle einer Liste zu verwenden, um mehrere http-Vorlagen zu definieren? Von dem, was ich gefunden habe, wird der Schlüssel nie wirklich verwendet.

Übrigens: Gibt es einen Grund, warum Sie sich dafür entschieden haben, ein Wörterbuch anstelle einer Liste zu verwenden, um mehrere http-Vorlagen zu definieren? Von dem, was ich gefunden habe, wird der Schlüssel nie wirklich verwendet.

Nein nicht wirklich. Im Nachhinein denke ich, dass es die Lesbarkeit verbessern kann, einen Schlüssel für jede von Ihnen definierte HTTP-Vorlage zu haben, aber ich bin nicht dagegen, ihn in eine Liste zu ändern, wenn dies die Dinge einfacher macht.

Ich bin auf ein ähnliches Problem gestoßen und anschließend auf dieses Problem. Ich möchte eine alternative Perspektive anbieten:

Standardwerte für eine Konfiguration sollten überhaupt nicht fest codiert sein und der zu installierenden Software überlassen werden.

Wie @alexsegura bereits darauf hingewiesen hat, besteht das Problem darin, dass Sie die Werte synchron halten müssen, was von Natur aus nicht immer der Fall sein wird (Menschen sind fehleranfällig).

Wenn Sie das Gefühl haben, eine Standardkonfiguration bereitstellen zu müssen, würde ich vorschlagen, die Unterabschnitte in separaten Verzeichnissen zu speichern und sie auf der untersten Ebene zu kombinieren, wenn der Benutzer einen Wert angibt, und sie dann in die Konfiguration einzufügen.

Aber selbst das ist imo nicht im Rahmen einer Rolle - es sollte die Konfiguration auf das Ziel kopieren und nicht sicherstellen, dass seine Werte in Ordnung sind; Ich würde höchstens einen Fehler ausgeben, wenn die Software aufgrund eines Konfigurationsfehlers nicht gestartet werden konnte (oder die Validierungsfunktion der Software verwenden, falls verfügbar).

Lustigerweise arbeite ich derzeit an Möglichkeiten, die Funktionsweise von Vorlagen in der Rolle zu verbessern. Es war ein sehr langsamer Prozess (ich habe im Moment eine eher begrenzte Bandbreite für die Rolle), aber ich denke, ich habe eine OK-Lösung gefunden, die diese Probleme angeht. In der Hoffnung, die Änderungen in maximal ein paar Monaten in einer separaten Filiale live zu haben 😉

Gibt es Fortschritte bei diesem Problem?

Nö. Es gibt noch Pläne, in "naher" Zukunft darauf zurückzukommen, aber ein paar andere Aufgaben haben Priorität.