別の柱が必要です
柱は、Salt内の安全な(安全な)データストアです。したがって、まず第一に、それらは重要なデータ(証明書、ログイン、パスワード)へのアクセスを区切るために使用されます。
デフォルトのピラーに加えて、Saltにはext_pillarモジュールもあります。このモジュールは 、外部データソースに接続するためのインターフェイスを提供し、これらのソースから1つの共通辞書にピラーを生成します。
たとえば、あなたがからデータを取ることができます mysqlの、postgresの、Redisの、モンゴ、gitの、あるいはスクリプト/コマンドの出力から- cmd_json、 cmd_yaml。
モジュールの完全なリストは、SaltStackの公式Webサイトで公開されてい ます。
非標準の状況があり、利用可能なモジュールが適切でない場合は、独自に作成して / usr / lib / python3 / dist-packages / salt / pillar /に配置できます。、その後、ウィザードを再起動する必要があります。
そのようなモジュールの例:
#/etc/salt/master/conf.d/pillar.conf
ext_pillar:
- dummy: dummy
#/usr/lib/python3/dist-packages/salt/pillar/dummy.py
def ext_pillar(minion_id, pillar, *args, **kwargs):
dummy = {'dummy': 'what u want mann?'}
return dummy
利用可能なすべてのモジュールの中で、 pillarstackが私たちのチームにとって最も興味深く関連性のあるものであることが判明しました。それでは、その理由をお話ししましょう。
PillarStackの概要
スタックまたは ピラースタックは、サイトの公式ドキュメントによると、「ピラーからピラーを読み取ることができるシンプルで柔軟なYAMLピラー」 です。
それはあなたが柱の中で以前に読んだ柱を使うことを可能にします。これは、前の構成の柱を使用できることを意味します。そして、それは非常に便利です!それがどのように機能するかを示しましょう:
, :
#/etc/salt/conf.d/pillarstack.conf
ext_pillar:
- stack:
- /srv/pillar/stack1.cfg
- /srv/pillar/stack2.cfg
- /srv/pillar/stack3.cfg
#/srv/pillar/stack1.cfg
# stack "" ,
# 2 yml ,
core.yml
common/*.yml
osarchs/{{ __grains__['osarch'] }}.yml
oscodenames/{{ __grains__['oscodename'] }}.yml
hosts/{{ minion_id }}/roles.yml
#/srv/pillar/stack2.cfg
# stack stack1.cfg
# , , roles
# stack yml
{% for role in stack.roles %}
roles/{{ role }}/*.yml
{% endfor %}
#/srv/pillar/stack3.cfg
# stack "" stack1.cfg stack2.cfg
#
creds/{{ stack.db.host }}/*.yml
各構成は、レイヤーとして表すことができます。そのような各レイヤーでは、前のレイヤーのデータを使用できます。
柱を構成するときは、次の変数を使用できます。
- 穀物-穀物による構成のターゲティング
- optsの設定のオプションでのconfigsをターゲットに-
- 柱-形成された柱の前に処理する現在のext_pillarを:スタック
# , stack
# stack grains pillar
# stack.cfg , pillar
ext_pillar:
- stack:
grains:cpuarch:
x86_64:
- /srv/pillar/stack1.cfg
- /srv/pillar/stack2.cfg
pillar:environment:
dev: /srv/pillar/dev/stack.cfg
prod: /srv/pillar/prod/stack.cfg
# stack: grains, pillar
# pillar stack1.cfg, stack2.cfg
# 'environment', stack.cfg
ext_pillar:
- stack:
grains:custom:grain:
value:
- /srv/pillar/stack1.cfg
- /srv/pillar/stack2.cfg
- stack:
pillar:environment:
dev: /srv/pillar/dev/stack.cfg
prod: /srv/pillar/prod/stack.cfg
ymlファイルでは、次のものを使用できます。
- __opts__:構成オプション
- __grains__:ミニオングレイン
- pillar:他のext_pillarまたはデフォルトのピラー(top.sls内のもの)からのピラー
- スタック:現在の構成を含む、累積されたピラースタック。
ピラースタックに切り替える場合は、以下の点に注意する必要があります
。1。再帰的包含はピラーでのみ機能します。スタックにはディレクトリは含まれず、ファイルのみが含まれます。
# pillar
# top.sls
base:
'*':
- dir1.* # /dir1/dir2/dir3/*
# stack
# stack.cfg
/dir1/*
/dir1/dir2/*
/dir1/dir2/dir3/*
2.リストをマージするときのデフォルトの動作:
- 柱-リストは上書きされます
- スタック-最後のマージ戦略が使用されます(リストが追加されます)。
ピラーフュージョン戦略により、ピラーを非常に柔軟にカスタマイズできます。
例を含む詳細な説明は、ドキュメントにあります。
各戦略を簡単に説明するには:
- merge-last(デフォルト):再帰的マージ、最後の辞書/リストが優先されます
- merge-first:再帰的マージ、最初の辞書/リストが優先されます
- 削除:指定した要素を削除します
- 上書き:辞書/リストの上書き。
説明:各マージには2つの辞書/リストが含まれます。それらを最初と最後と呼びましょう。
戦略は、適用する辞書/リストの最初の要素として示されます。
主なことは、構成を複雑にするため、戦略の過度の使用に夢中にならないことです。おそらく、この場合、柱の構成を再検討する価値があります。
結論
柱を使用すると、機密データへのアクセスを制限できます。データが大きくなるにつれて、その使用シナリオはより洗練されてきているため、便利なツールを使用してデータを整理することが重要です。私たちのチームにとって、これは柱の山です。将来的には、ボールトを展開する予定です。
pillarstackがデフォルトのpillarに取って代わっていないのは驚くべきことです。これは、はるかに便利で柔軟性があり、スタック変数の動作をポイントごとに変更する必要がある場合に戦略が非常に役立つためです。どう思いますか?仕事でピラースタックを使用していますか?