Salt Pillar: Wie verwende ich unterschiedliche Werte für Produktion/Entwicklung?

Salt Pillar: Wie verwende ich unterschiedliche Werte für Produktion/Entwicklung?

Ich bin nicht sicher, ob ich richtig darüber nachdenke, aber hier ist mein Problem:

Ich möchte für Produktions-, Entwicklungs- und Testserver denselben Salt-Status und dieselbe Pillar-Konfiguration verwenden. Der einzige Unterschied sollte sein:

  1. Welche Minions werden eingesetzt
  2. Die Werte von Pillar-Schlüsseln, wie Passwörter oder Benutzernamen

Ich könnte verschiedene Pillar-Umgebungen erstellen, aber das würde zu getrennten SLS-Dateien führen, was wiederum bedeutet, dass die Konfigurationen auseinanderdriften könnten. Ein anderer Ansatz wäre, verschiedene Git-Zweige zu verwenden, einen für jede Umgebung. Aber ich kann mir vorstellen, dass das zu vielen Merge-Konflikten führen würde.

Ich denke, das Problem liegt daran, dass meine Pillar-Dateien eine Struktur haben. Meine Pillar-Datei beispielsweise für Server, die Folgendes collectdaktiviert haben:

#!yaml|gpg

collectd:
  host:
    ip: 1.2.3.4
    port: 123
    username: my_username
    password: |
      -----BEGIN PGP MESSAGE-----
      ...
      -----END PGP MESSAGE-----

Ich würde diese Datei gerne für alle meine Umgebungen verwenden können, nur mit unterschiedlichen Werten, etwa so:

#!yaml|gpg

collectd:
  host:
    ip: $HOST_COLLECTD
    port: 123
    username: $USER_COLLECTD
    password: $PASS_COLLECTD

Ist so etwas möglich oder verwende ich Salt falsch?

Danke!

BEARBEITEN, um einige Informationen hinzuzufügen:

Ich verwende, git_pillarum die Dateien direkt von Git abzurufen. Dadurch kann ich mehrere Umgebungen haben, ohne mehrere Verzeichnisse zu erstellen, da jeder Zweig eine Umgebung sein kann. AufLösungIch kann mir vorstellen, Vorlagen zu verwenden, um das zu überprüfen saltenv. Das fühlt sich ein wenig hackig an, würde aber im Moment das tun, was ich will:

#!yaml|gpg

collectd:
  host:
    ip: 1.2.3.4
    port: 123
    username: my_username
    password: |
      {% if saltenv == 'dev' %}
      -----BEGIN PGP MESSAGE-----
      ...
      -----END PGP MESSAGE-----
      {% else %}
      -----BEGIN PGP MESSAGE-----
      ...
      -----END PGP MESSAGE-----
      {% endif %}

Ich suche jedoch immer noch nach besseren Möglichkeiten, mein Problem zu lösen.

Antwort1

Obwohl ich mit dem Ergebnis nicht ganz zufrieden bin, möchte ich für andere, die auf dasselbe Problem stoßen, veröffentlichen, was ich jetzt verwende.

Am Anfang jeder Datei, die je nach Umgebung unterschiedliche Werte benötigt, deklariere ich Jinja-Variablen. Das bedeutet zwar immer noch, dass in jeder Datei eine selbstcodierte Logik vorhanden ist, aber zumindest ist die tatsächliche Struktur der Säulendaten leicht zu verstehen. Es bringt einige Formatierungsherausforderungen mit sich, funktioniert aber für alles, was ich brauche. Hier ist ein Beispiel:

#!jinja|yaml|gpg

{# Set values based on saltenv #}
{% if saltenv == 'test' %}
  {% set ip = 1.2.3.4 %}
  {% set username = 'user_test'%}
  {% set password = '
      -----BEGIN PGP MESSAGE-----
      ...
      -----END PGP MESSAGE-----'%}
{% elif saltenv == 'production' %}
  {% set ip = 5.6.7.8 %}
  {% set username = 'user_prod' %}
  {% set password = '
      -----BEGIN PGP MESSAGE-----
      ...
      -----END PGP MESSAGE-----'%}
{% else %}
  {{ raise('Invalid / Unknown saltenv:' ~ saltenv)}}
{% endif %}

collectd:
  host:
    ip: {{ ip }}
    port: 123
    username: {{ username }}
    password: |- {{ password }}

Bei der Einrückung mehrzeiliger Zeichenfolgen wie der PGP-Nachricht müssen Sie sehr vorsichtig sein!

verwandte Informationen