SaltStack：任意の数の構成ファイルを管理

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

この記事は、SaltStackの特定のサービスの任意の数の構成ファイルを管理する方法を理解するのに役立ちます。

SaltStack（床下）：それは何であり、どのように対処しますか？

多くの人はすでに、Saltを含む自動化された構成管理システムでの作業経験があり、それを調理する方法とそれが私にとってはないかもしれないことについて詳細に話します。

SaltStack（ロビー）：簡単な例のある典型的なアプリケーション

したがって、インストール、構成ファイルの実装、およびそれらの変更の監視を自動化し、必要に応じてnginxなどの一般的なサービスを再起動するタスクがあるとします。 システムを簡素化するために、提供されるサーバーはDebian Wheezyに基づいていると想定しています。 （他のすべての人のために- 穀物システムについて読みます-状態を使用するシステムを決定し、それに応じて動作を変更するのに役立ちます）。

だから：

nginx-repo-key-install: cmd.run: - name: 'apt-key adv --keyserver keys.gnupg.net --recv-keys ABF5BD827BD9BF62' - unless: 'apt-key list | grep -q 7BD9BF62' nginx-repo: pkgrepo.managed: - humanname: nginx-repo - name: deb http://nginx.org/packages/mainline/debian/ wheezy nginx - require_in: - pkg: nginx-pkg - required: - cmd: nginx-repo-key-install nginx-pkg: pkg.installed: - name: nginx - refresh: True - require: - pkgrepo: nginx-repo nginx-service: service.running: - name: nginx - full_restart: True - require: - pkg: nginx-pkg - watch: - file: nginx-config-vhost nginx-config-vhost: file.managed: - name: /etc/nginx/conf.d/vhost.conf - source: salt://__CONFIGS/vhost.conf - user: root - group: root - mode: 644
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「本が書いているように」それですべてですが、より詳細に検討してください（後続の計算の背景として非常に重要です）。

• nginx-repo-key-install：公式リポジトリキーをシステムにインポートします
• nginx-repo：aptに公式リポジトリを追加
• nginx-pkg：新しいパッケージを置きます
• nginx-service：サービスを制御し、構成ファイルへの変更を監視するように強制します
• nginx-config-vhost：実際には-設定ファイルとそれを取得する場所

探究心のある人には肉眼で漏れがあります（たとえば、nginx.confの制御は説明されていません）が、それらはすべて、問題領域に関係しない情報負荷を軽減するために作成されています。

SaltStack（2階）：多くの構成ファイル

最初の例では、ある種の仮想nginxサーバーが記述されたファイルが1つあるサービスが示されました。 Saltウィザード（salt：//__CONFIGS/vhost.conf）で変更して状態を再起動すると、ファイルがマシン上で更新され、nginxサービスが自動的に再起動（full_restart：True）されます。

多くの場合、nginxを搭載したマシンには複数の仮想ホストが存在します。 管理を整理する方法を検討してください。

vhostファイル{1,2,3,4,5} .confがあるとします。 この場合、状態の下部は次のようになります。

 ...... nginx-service: service.running: - name: nginx - full_restart: True - require: - pkg: nginx-pkg - watch: {% for cnf in ['vhost1.conf', 'vhost2.conf', 'vhost3.conf', 'vhost4.conf', 'vhost5.conf'] %} - file: nginx-config-{{ cnf }} {% endfor %} {% for cnf in ['vhost1.conf', 'vhost2.conf', 'vhost3.conf', 'vhost4.conf', 'vhost5.conf'] %} nginx-config-{{ cnf }}: file.managed: - name: /etc/nginx/conf.d/{{ cnf }} - source: salt://__CONFIGS/{{ cnf }} - user: root - group: root - mode: 644 {% endfor %}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここから、Saltの魔法が少し始まります。つまり、 JinjaはPythonのテンプレートエンジンです（SaltStackが書かれています）。 ストーリーでは、すべてが明らかです-変更が行われたときに再起動されるように、さまざまな名前のファイルオブジェクトを多数作成し、それらをすべてサービスに結び付けます。 最適化のために、 柱システムを使用して構成ファイル名を保存できます。 しかし、これは宿題です。

SaltStack（1階上）：多くの構成ファイル—しかし、いくつ、どのファイルが不明です。

それでは、なぜこの記事が考えられたのか-状況は、共有ホスティングを使用するほとんどの稼働中のシステムで非常にありふれたものです。 次に、Saltを介したインフラストラクチャの展開をどうしますか？ 解決策があります！ 残念ながら、明らかなことでは十分ではありません（明確にするために開発者に連絡する必要さえありました）が、うまくいきます。

だから：

 ...... nginx-service: service.running: - name: nginx - full_restart: True - require: - pkg: nginx-pkg - watch: {% for cnf in salt['cp.list_master'](prefix='__CONFIGS/') %} - file: nginx-config-{{ cnf }} {% endfor %} {% for cnf in salt['cp.list_master'](prefix='__CONFIGS/') %} {% set items = cnf.split('/') %} nginx-config-{{ cnf }}: file.managed: - name: /etc/nginx/conf.d/{{ items|last }} - source: salt://{{ cnf }} - user: root - group: root - mode: 644 {% endfor %}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際に最も興味深い場所について：

 {% for cnf in salt['cp.list_master'](prefix='__CONFIGS/') %}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プレフィックス '__CONFIGS /'（このサービスのすべての構成ファイルが配置されているSaltウィザード上のフォルダーの名前）を使用して、 cpモジュールからlist_master関数を呼び出します。

 {% set items = cnf.split('/') %}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

cp.list_masterの問題は、ファイルへのフルパス（プレフィックスを含む）を提供し、「-name：」ディレクティブで指定するためにファイル名のみが必要なことです。 この点で、フルパスをスラッシュに沿って分割し、リストの最後の要素のみを使用します。 ファイル名：

 - name: /etc/nginx/conf.d/{{ items|last }}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、改訂されたディレクトリ、流通に含まれる構成ファイル、およびこのディレクトリで利用可能なファイルを取得し、ファイルに変更があった場合にすぐにサービスの自動再起動に関連付けられます。

おわりに

非常に簡単ですが、SaltStackの実装を始めたばかりで、単純なパッケージ管理を使用した例よりも少し先に進みたいHabr読者に役立つことを願っています。 頑張って！