2014-03-19 13 views
7

In Saltstack, ich habe folgenden Anwendungsfall:Passing Variablen zwischen Salz Staaten

Es ist ein Zustand redis.sls, die von anderen Staaten aufgenommen werden kann. Das Ergebnis von redis.sls sollte unterschiedlich konfiguriert werden, abhängig vom Status, der redis.sls enthielt.

Zum Beispiel:

redis.sls: 
-------- 
{% if x==1 %} 
    #do something 
{% else %} 
    #do something else 
{% endif %} 


state_a.sls 
----------- 
{% set x=1 %} 
include: 
    - redis 

state_b.sls 
----------- 
{% set x=2 %} 
include: 
    - redis 

Aber x nicht in * state_a anerkannt * und * state_b *

Ich habe auch versucht eine Säule Wert mit so etwas wie diese Einstellung:

{{salt['pillar.set']('x', 1)}} 

aber das hat auch nicht funktioniert.

Irgendwelche anderen Ideen?

+0

Es scheint, wie Sie versuchen, Staaten in einer Art und Weise zu parametrieren, dass sie derzeit nicht parametriert werden sollen. Was versuchst du damit zu erreichen? – pcurry

+0

Ich habe fast die gleiche [Frage] (http://stackoverflow.com/questions/38904308/passing-variables-with-include-in-salt-stack). Zum Beispiel haben wir Redis-Master und Redis-Replikation. Diese Zustände sind fast identisch und die Frage ist, wie man Code-Duplizierung vermeidet. – Raz

Antwort

1

Ich würde gerne hören, was die Experten sagen, aber ich habe einen ähnlichen Anwendungsfall. Was ich tat, war die jinja template, um eine Basisvorlage zu erweitern, dann füllte meine Kindvorlagen die Variablen.

{% extends "base.template.sls" %} 
{% block x %}1{% endblock %} 

Das einzige Problem könnte sein, dass Sie jetzt state_a verlangen und state_b getrennt, aber man kann sie immer in eine durch Kommata getrennte Liste setzen, wenn Sie beide genannt werden soll.

0

Es sieht so aus, als ob Sie einen Zustand basierend darauf, was davon abhängt oder wo er verwendet wird, parametrisieren möchten. Das klingt wie alles, was die Parameter, auf denen der redis.sls-Status mutieren soll, setzt, hängt von einer bestimmten Konfiguration von redis ab.

Für mich scheint das so zu sein, als gäbe es mehr als einen bestimmten Zustand, in dem redis sein könnte, und dass einige Ihrer Zustände von einem Zustand der Wiederentdeckung abhängen und andere von Ihren Zuständen von anderen Zuständen von redis abhängen.

Also, geben Sie die Installation von Redis ein Zustand, und die spezifischen Konfigurationen von Redis würde jeder ihren eigenen Zustand bekommen. Ihre state_a könnte, hängt von redis_state_1 und Ihre state_b wiederum würde davon abhängen, redis_state_2. Sowohl redis_state_1 als auch redis_state_2 wären von redis abhängig. Es scheint mir, dass die Parameterübergabe, nach der Sie fragen, weniger explizit wäre.

+0

Könnten Sie bitte erklären, wie man es archiviert? Zum Beispiel möchte ich 2 verschiedene Redis-Instanzen auf einem Server installieren. Ich kann den Status ** redis ** mit der Variablen ** version ** angeben. Aber wie nennt man das mit anderen Werten? – Raz

+0

@Raz Es ist so lange her, dass ich Salz verwendet habe, dass ich die Dokumentation noch einmal besuchen müsste. Ich denke, dass Ansible den Benutzeranteil in diesen Tagen gewinnt. – pcurry

1

Setzen Sie Ihre Redis ein Jinja-Makro.

redis.sls: 
-------- 
{% macro redis(x) %} 
{% if x==1 %} 
    #do something 
{% else %} 
    #do something else 
{% endif %} 
{% endmacro %} 


state_a.sls 
----------- 
{% from 'redis.sls' import redis %} 
{{ redis(1) }} 


state_b.sls 
----------- 
{% from 'redis.sls' import redis %} 
{{ redis(2) }} 

Aus Gründen der Übersichtlichkeit sollte redis.sls hier in redis.jinja umbenannt werden.

Diese und viele andere Möglichkeiten zur Verwaltung der Statusanpassung werden am besten in der Salt Formulas conventions guide erläutert. Speziell der Teil über Jinja Makros

Beachten Sie, dass Ihre if x == 1 Logik wahrscheinlich vollständig vermieden werden kann, werfen Sie einen Blick auf die "bessere" Version von Haproxy Beispiel in der Anleitung.

-1

SALT.STATES.ENVIRON könnte für Sie arbeiten:

set_secret_key: 
    environ.setenv: 
    - name: SECRET_KEY 
    - value: [email protected]#abc 
    - update_minion: True 

[..] 

settings_secret_key: 
    file.replace: 
    - name: {{ salt['pillar.get']('data:source_folder') }}superlists/settings.py 
    - pattern: "SECRET_KEY =.+$" 
    - repl: 'SECRET_KEY = os.environ["SECRET_KEY"]'