SaltStack：柔軟な構成のためのjinjaテンプレートとピラーストレージの使用

ここで面白いのは何ですか？

この記事は、SaltStackを構成管理ツールとして使用している、または使用を検討している人を対象としています。 Tinyproxyの例を使用して、このシステムを使用してサービス構成を柔軟に管理する経験を簡単に共有しようと思います。
これは、SaltStackシリーズの2番目の記事です 。最初の記事はこちらをご覧ください 。

SaltStack：状態構成を構築するためのイデオロギー

SaltStackでは、管理対象マシンの構成に状態の概念が導入されており、マスターで変更が行われ、その後すべてのスレーブマシンで実行されることに注意してください。 このモデルはマニフェストのある同じPuppetに非常に似ていますが、SaltStackには利点が1つあります。状態の実行は、Puppetに実装されているクライアント自体ではなく、マスターから開始されます。

しかし、ポイントに近い。 サラダでしばらく遊んだ後、状態データ（slsファイル）を整理するさまざまな方法を試した後、私が提供するほとんどのプロジェクトに適した汎用モデルに到達しました。 モデルの本質は、SaltStackに関するサービス/リソース/プロジェクトの関係とその説明の継承と再定義に基づいています。 これは次の記事になります。 ここで、このモデルの方法論を使用して、モデル自体の詳細を実際に説明することなく、TinyProxyサービスの管理を説明します。

プライマリ状態の説明

ですから、TinyProxyが何であるか、なぜそれが必要なのか（知識が豊富で理解しやすい、好奇心-盛-Googleがお手伝いします）、私はクライアントにプロキシサービスを提供するプロジェクトの1つでそれを使用しているとしか言えません。 スキーム：世界中に散らばるTinyProxyを搭載した20〜30台のサーバー。 インストールと設定は非常に簡単です。したがって、詳細な説明は省略し、タスクにとって重要なことだけを説明します。この場合は、次のとおりです。クライアントIPアドレスに基づいてプロキシサービスへのアクセスを制限します。 設定に関しては、TinyProxyはAllowディレクティブです。

実際に、サービスを作成する状態（私のモデルに関して）TinyProxy：
tinyproxy.sls

tinyproxy-config: file.managed: - name: /etc/tinyproxy.conf - source: salt://__DEFAULT-CONFIGS/tinyproxy.conf - template: jinja - require: - pkg: tinyproxy-pkg tinyproxy-pkg: pkg.installed: - name: tinyproxy tinyproxy-service: service.running: - name: tinyproxy - full_restart: True - require: - pkg: tinyproxy-pkg - watch: - file: tinyproxy-config 

重要なポイント：

• /etc/tinyproxy.confファイルを制御します
• プロトタイプ（テンプレート）はソルト上にあります：//__DEFAULT-CONFIGS/tinyproxy.confウィザード
• このファイルはJinja（ -template：jinja ）を使用して処理する必要があり、テンプレートコマンドがあることを状態に通知します（以下で説明します）

この記事の他のすべてはかなり標準的なものです。パッケージをインストールし（ほとんどのLinuxシステムでTinyProxyの利点はそのまま使用できます）、システムサービスを制御し、再起動を構成ファイルの変更にバインドします。 異なるシステムでは、ファイルが/などに対して異なるディレクトリにあるという事実を無視します。

Jinjaテンプレートを含むtinyproxy.confパーツ

 . . . # # Allow: Customization of authorization controls. If there are any # access control keywords then the default action is to DENY. Otherwise, # the default action is ALLOW. # # The order of the controls are important. All incoming connections are # tested against the controls based on order. # {% for allowed_ip in pillar['tinyproxy']['allowed_ips'] -%} Allow {{ allowed_ip }} {% endfor %} . . . 

重要なポイント：テンプレートを正しく作成する方法と、ダッシュが近くにある理由については、 ここで読むことができます 。 テンプレートのデータは、 Pillarシステムから取得されます。

これらの場合の柱自体（私のモデルの観点から-リソース）は次のようになります。
tinyproxy-pillar.sls

 tinyproxy: allowed_ips: - 1.2.3.4 - 2.3.4.5 - 3.4.5.6 

つまり、シーケンス全体は次のようになります：スレーブマシンで状態が開始されるたびに、tinyproxy.confファイルはJinjaテンプレートエンジンを介して実行され、ピラーから必要なデータを取得してクライアントに送信し、その後サービスを再起動します。
最終的なtinyproxy.conf：

 . . . # # Allow: Customization of authorization controls. If there are any # access control keywords then the default action is to DENY. Otherwise, # the default action is ALLOW. # # The order of the controls are important. All incoming connections are # tested against the controls based on order. # Allow 1.2.3.4 Allow 2.3.4.5 Allow 3.4.5.6 . . . 

結果は何ですか？

これらすべての操作は、クライアントのIPアドレスを追加または削除する必要がある場合（アクセスポリシーに従って）に、ピラーファイルのデータを修正（行の追加または削除）し、state.highstateをすべてのプロキシで実行するように設計されています。 「*プロキシ*」。