著者の声明
私はちょうどあなたが間違った場所のテキストを持っている場合は、私たちに知らせてください、初心者をSaltStack。
学習プロセスでは、私は間違ったの多くを作った多くの実験を行っているご質問があれば、SaltStackを実行中にいくつかの経験を蓄積しても、一定の理解を持っている、または、歓迎のメッセージ交換を場所を理解していません！
塩の状態
参考リンク：公式ドキュメント
シンプルで簡単な、シンプル
多くの強力かつ強力なデザインは単純な原理に基づいて構築されています。塩SLSシステムは、KISSための努力に沿ったものでもあります。（愚かそれをシンプルに保ちます）
（塩の状態ファイルの代わりに）SLSソルト国家システムの心臓部です。SLSは、単純なデータ形式で構成され、システムの状態を記述します。これは多くの場合、構成管理と呼ばれています。
Note
这篇文章从整体上介绍了Salt States，以后还会增加对各组件的深入介绍。
それはちょうどデータ
研究掘り下げる前に、SLSのファイルは、単にデータを構造化され、それは非常に有用であることを理解。SLSの読み取りおよび書き込みのファイルがこのことを理解する必要はありませんが、あなたは強力なSLSシステムを感じていただけます。
SLSファイルは、本質的にちょうどいくつかありdictionaries、lists、stringsとnumbers。この設計は、SLSの開発者のさまざまなニーズを満たすために非常に柔軟なファイル、および高い可読性を可能にします。より明確に最後に書かれ、書いたものはい。
デフォルトのデータ - YAML
塩は--YAMLがデフォルトでSLSデータを表現するために見つけることができる最も簡単なシリアル化されたデータ形式を使用します。典型的なSLSファイルを次のように
apache:
pkg:
- installed
service:
- running
- require:
- pkg: apache
これらのデータは、指定されたことを確実にapacheインストールされた状態のソフトウェアパッケージ（ない場合は、インストールがapache）、サービスプロセスがapache実行されています。このデータは、シンプルで理解しやすいです。以下の簡単な説明です：
1行目は、このデータのIDは、IDの主張と呼ばれています。このIDは、コマンドの名前が実行されますです。
2行目と4行目は、この2つの状態のPKGやサービスを使用し、開始を宣言状態を表しています。インストールするために管理するシステムのローカル管理者を使用してpkgのソフトウェアパッケージ、サービス管理システムデーモン。
3行目と5行目は、実行される機能です。関数は、目標状態サービスパッケージとIDの名前を定義します。この場合、状態がインストールされたパッケージには、サービスが稼働している必要がありますする必要があります。
最後に、6行目は、キーワードが必要です。これは、必要な書類（必要な）と呼ばれ、それはApacheサービスが唯一の成功したインストールパッケージの後に開始されることを保証します。
プロファイルとユーザーを追加します。
ApacheなどのWebサーバーを展開する場合、また、追加のコンテンツを追加する必要があります。Apacheの設定ファイルを管理する必要がある、あなたは、Apacheサービスを実行するユーザーとグループを追加する必要があります。
apache:
pkg:
- installed
service:
- running
- watch:
- pkg: apache
- file: /etc/httpd/conf/httpd.conf
- user: apache
user.present:
- uid: 87
- gid: 87
- home: /var/www/html
- shell: /bin/nologin
- require:
- group: apache
group.present:
- gid: 87
- require:
- pkg: apache
/etc/httpd/conf/httpd.conf:
file.managed:
- source: salt://apache/httpd.conf
- user: root
- group: root
- mode: 644
時計：SLSが大幅に新しいステートメントが必要である、上記の構成、ユーザー、グループの増加を例を拡大しました。
両方のユーザーおよびグループapacheの状態は、このIDの下で添加し、その結果、ユーザおよびグループ名の増加は、Apacheです。このグループの唯一の確立がApacheのユーザーは、唯一正常にインストールされ、このパッケージapacheのグループの後に確立されたときにのみ存在することを確認するためのステートメントが必要です。
サービスは、時計に声明を必要とし、3つの状態（すなわち、PKG、ファイルおよびユーザー）を監視するために、1つのソフトウェアパッケージから変更する必要があります。非常によく似た文を見て、必要、国家のニーズを確実にするために監視したり、自分の前に行われますが、他の時計の役割がありますすることができます。ときに、監視状態の変化は、状態定義された時計の文はそのウォッチャー機能を実行します。言い換えれば、更新パッケージは、ウォッチャー機能のサービス状態をトリガするApacheのユーザーのUIDを変更し、設定ファイルを変更します。この例では、ウォッチャーのサービス状態は、Apacheサービスを再起動します。
Note
Salt的watcher概念非常有意思。Puppet中功能类似的是notify，也可以触发服务重启。Salt的watcher非常灵活，watcher本质上是在state的代码中定义的名为mod_watch()的函数，在这个函数中想做什么事情完全就看你的需求了。我没有仔细看Puppet的notify如何实现，不知道是否有这么灵活。
SLS複数のファイル
あなたはよりスケーラブルな塩の状態を展開する場合は、複数のSLSを使用する必要があります。上記の例は、2つの以上のファイルがSLS州立ツリーを形成するために組み合わせることができる、唯一のSLSファイルを使用しています。-上記の例では、奇妙なソースファイル使用していますsalt://apache/httpd.conf。このファイルに何位置を？
SLSマスターに分散し、特定のディレクトリ構造にファイルを、SLSと手先上のファイルに発行される普通のファイルです。
ルートディレクトリソルト上記ファイルの例（「参照SaltStackファイルサーバ」）は次のように分布します。
apache/init.sls
apache/httpd.conf
Apacheのディレクトリ内のhttpd.conf普通のファイルを直接参照することができます。SLSは、複数のファイルを例としてSSHへのより柔軟かつ便利にすることができ使用しています。
SSH / init.sls：
openssh-client:
pkg.installed
/etc/ssh/ssh_config:
file.managed:
- user: root
- group: root
- mode: 644
- source: salt://ssh/ssh_config
- require:
- pkg: openssh-client
SSH / server.sls：
include:
- ssh
openssh-server:
pkg.installed
sshd:
service.running:
- require:
- pkg: openssh-client
- pkg: openssh-server
- file: /etc/ssh/banner
- file: /etc/ssh/sshd_config
/etc/ssh/sshd_config:
file.managed:
- user: root
- group: root
- mode: 644
- source: salt://ssh/sshd_config
- require:
- pkg: openssh-server
/etc/ssh/banner:
file:
- managed
- user: root
- group: root
- mode: 644
- source: salt://ssh/banner
- require:
- pkg: openssh-server
Note
在ssh/server.sls中，用了两种不同的方式来表示用Salt管理一个文件。在ID为/etc/ssh/sshd_config段中，直接使用file.managed作为state声明，而在ID为/etc/ssh/banner段中，使用file作为state声明，附加一个managed属性。两种表示方法的含义与结果完全一样，只是写法不同。
次のような状態の木は、（参照されるドキュメントのいくつかは、コンテンツを与えるものではありません、理解に影響を与えることはありません）以下のようになります。
apache/init.sls
apache/httpd.conf
ssh/init.sls
ssh/server.sls
ssh/banner
ssh/ssh_config
ssh/sshd_config
SSH / server.slsには、ステートメントを使用します。あなたがSLSの内容を必要とするか、または定義で参照さ見ることができるので、他の現在のファイルを含めるようにSLSを追加し、それはまた、（すぐに言及した）そのコンテンツを拡張することができます。州内のステートメントの原因は参照を提出することができます。使用自体に参照されたファイルの内容を追加することと同等のものを含んでいます。
拡張SLSは、参照されたデータを拡張します
拡張それは何を意味するのでしょうか？再書き込みヘッドを必要としないの増加Apacheのmod_pythonのモジュールで、今、一般的なサーバーでのssh / server.sls apacheの中で定義されたようなSLS新しい、元の直接server.slsが、その後、その後、mode_pythonインストールされた状態を追加し、含まmod_pythonのは、Apacheサービスの監視リストに増加します。パイソン/ mod_python.slsは、次のとおりです。
include:
- apache
extend:
apache:
service:
- watch:
- pkg: mod_python
mod_python:
pkg.installed
この例で、init.slsはそれを含めるApacheのディレクトリの最初のファイル（ディレクトリを含めるときに、塩が自動的init.slsファイルがあります）、その後、Apacheのサービス状態IDでウォッチリストを展開します。
また、拡張して、ファイルのダウンロード先を変更することができます。SSH /カスタムserver.sls：
include:
- ssh.server
extend:
/etc/ssh/banner:
file:
- source: salt://ssh/custom-banner
拡張SLS塩がより柔軟にできます。なぜそれを行うことSLSができる拡張？最も強調した資料の冒頭、SLSファイルは、SLSに対処する上で、Pythonで辞書に解決されるの内容は（もちろん、これは辞書の辞書やリストをネストされます）のみ構造化データです。Apacheは、リストの要素を追加することと同じであるコンテンツを、見て、変更されたバナーファイルのダウンロードパスが辞書にキーの変更に対応する値に対応します。延長される場合は、追加コンテンツはカバーされていない、/時計を必要とするために追加されます。
レンダリングシステムは、システムをレンダリング理解します
SLSは単なるデータなので、YAMLで表現する必要がないためです。塩デフォルトYAMLは、ちょうど簡単として使用します。限り、対応レンダラがあるとして、SLSファイルは急行どのような方法で使用することができます（あなたのレンダラーが必要なデータ構造を返すようにする限り、最終的に解析されたデータ構造に関わる塩、塩は、なぜあなたは、ソースドキュメントを書く方法を気に？）。
塩はyaml_jinjaのデフォルトのレンダリングを使用しています。yaml_jinjia Jinja2ののSLSテンプレートエンジンとの最初の契約、その後、YAMLパーサーを呼び出します。この設計の利点は、（Jinja2のはどのようにあなたがここにどのように使用できるか、使用することができます。条件文は、ループ、Pythonコード何でもできることを）あなたはSLSファイル内のプログラミング構成のすべてを使用することができるということです。
パイソンに基づいて文法記述言語に設立され、pydsl;、yaml_makoマコテンプレートエンジンを使用して、yaml_wempy、Wempyテンプレートエンジンを使用し、直接PythonのSLSファイルに記述されたPY、：利用できる他にはさらに含むレンダリング。
簡単なデフォルトのレンダリング - yaml_jinja
神社の使用テンプレートエンジンについて、その参照してください公式ドキュメント
塩、穀物やpilla：あなたは、次の3つのコンポーネントから必要なデータを取得することができ、テンプレートベースのレンダラエンジン。テンプレートファイルでは、穀物の穀物のアクセスデータを使用して、塩ソルト機能を持つ任意のオブジェクトを実行することができます。例としては、次のとおりです：
Apacheの/ init.sls：
apache:
pkg.installed:
{% if grains['os'] == 'RedHat'%}
- name: httpd
{% endif %}
service.running:
{% if grains['os'] == 'RedHat'%}
- name: httpd
{% endif %}
- watch:
- pkg: apache
- file: /etc/httpd/conf/httpd.conf
- user: apache
user.present:
- uid: 87
- gid: 87
- home: /var/www/html
- shell: /bin/nologin
- require:
- group: apache
group.present:
- gid: 87
- require:
- pkg: apache
/etc/httpd/conf/httpd.conf:
file.managed:
- source: salt://apache/httpd.conf
- user: root
- group: root
- mode: 644
ショーの手先OSオペレーティング・システムの粒はその後、Apacheソフトウェアパッケージとサービス名は、httpdがしなければならない、Red Hatの場合、この例では、構造の神社の使用のための条件を理解することは非常に簡単です。
再びNB、神社環状構造の使用のさらなる例は、提供MooseFs分散chunkserverモジュール：
MooseFS / chunk.sls。
include:
- moosefs
{% for mnt in salt['cmd.run']('ls /dev/data/moose*').split() %}
/mnt/moose{{ mnt[-1] }}:
mount.mounted:
- device: {{ mnt }}
- fstype: xfs
- mkmnt: True
file.directory:
- user: mfs
- group: mfs
- require:
- user: mfs
- group: mfs
{% endfor %}
'/etc/mfshdd.cfg':
file.managed:
- source: salt://moosefs/mfshdd.cfg
- user: root
- group: root
- mode: 644
- template: jinja
- require:
- pkg: mfs-chunkserver
'/etc/mfschunkserver.cfg':
file.managed:
- source: salt://moosefs/mfschunkserver.cfg
- user: root
- group: root
- mode: 644
- template: jinja
- require:
- pkg: mfs-chunkserver
mfs-chunkserver:
pkg:
- installed
mfschunkserver:
service:
- running
- require:
{% for mnt in salt['cmd.run']('ls /dev/data/moose*') %}
- mount: /mnt/moose{{ mnt[-1] }}
- file: /mnt/moose{{ mnt[-1] }}
{% endfor %}
- file: /etc/mfschunkserver.cfg
- file: /etc/mfshdd.cfg
- file: /var/lib/mfs
この例では、動的に、データを収集する（この実行モジュールcmd.runここで使用される）塩を使用して複数のオブジェクトは、シェルコマンドを実行するためにディスクを検出して取り付けるために使用される複数サイクルのために、神社のパワーを示しています。
簡単なPythonとレンダラのPyDSL
タスクは非常に複雑なロジックがある場合は、デフォルトのyaml_jinjaレンダラは必ずしも要件を満たしていない、あなたはPythonのレンダラを使用することができます。それに国家ツリーにSLSファイルを使用してPYレンダラーを追加する方法？シンプル。非常に単純な基本的なPythonのSLSファイル：
パイソン/ django.sls：
#!py
def run():
'''
Install the django package
'''
return {'include': ['python'],
'django': {'pkg': ['installed']}}
この例でもよく理解され、最初の行は塩がなく、PYと、デフォルトのレンダラを使用しないように指示します。これは、関数の実行、塩の要件を満たす必要があり、この関数の戻り値の定義を、HighStateデータ構造は（私はとにかく、細部を気にしないでください今HighStateについて書こうと思っていることを、辞書、キーと値が定められているのです）を意味します。あなたはpydslレンダラを切り替える場合は、上記の例では、よりシンプルになります：
Pythonの/ django.sls：
#!pydsl
include('python', delayed=True)
state('django').pkg.installed()
YAML場合、これは次のようになります。
include:
- python
django:
pkg.installed
これは、通常の状況下でYAMLの使用が非常に適切であるが、必要に応じて、純粋なPythonのSLSの使用は非常にNBできることが分かります。
ファイル名を指定して実行とデバッグ塩州
手先にそれを適用する方法を記述されたSLS？SaltStackでは、リモート実行がすべての基礎です。コマンドが実行salt '*' state.highstate手先マスターのすべてがSLSの独自の定義を奪うように構成し、その後、説明ローカルSLSの状態を達成するために、対応する状態モジュール（ユーザー、PKG、サービスなど）を呼び出します。「：」SLSファイルが間違っている、そのほとんどが、このコマンドが返すホスト名のみプラス手先の場合。手先がサービスプロセスが開始された場合は、コマンドを実行salt-call state.highstate -l debug、デバッグに簡単にエラーメッセージを、表示されることがあります。手先も直接フォアグラウンドでデバッグモードで実行できますsalt-minion -l debug。