2017-03-28 7 views
2

私たちはsaltstackでWebサイトを管理しています。これらのサイトはPHP-FPM上で動作し、いくつかのfpmプールがあります。各プールはphp-fpm.d/ディレクトリ内の専用ファイルで構成されています。すべてのファイルが有効な場合のみ、複数のファイルをsaltstackで展開する

現時点では、file.managedの状態でcheck_cmd: php-fpm -tyと設定されているかどうかを確認します。間違いがプールファイル(たとえば、fpm-pool-a)に行われたまで

fpm-conf: 
    file.managed: 
    - name: /etc/php-fpm.conf 
    - source: salt://php/template/fpm.jinja 
    - user: someuser 
    - group: somegroup 
    - mode: 644 
    - template: jinja 
    - check_cmd: /usr/sbin/php-fpm -ty 
    - require: 
     - pkg: php-package 

fpm-pool-a: 
    file.managed: 
    - name: /etc/php-fpm.d/a.conf 
    - source: salt://php/template/fpm-a.jinja 
    - user: someuser 
    - group: somegroup 
    - file_mode: 644 
    - template: jinja 
    - require: 
     - pkg: php-package 
    - require_in: 
     - file: fpm-conf 

fpm-pool-b: 
    file.managed: 
    - name: /etc/php-fpm.d/b.conf 
    - source: salt://php/template/fpm-b.jinja 
    - user: someuser 
    - group: somegroup 
    - file_mode: 644 
    - template: jinja 
    - require: 
     - pkg: php-package 
    - require_in: 
     - file: fpm-conf 

それは、正常に動作します。 fpm-conf状態は、メインのfpm設定ファイルへの更新をブロックしますが、a.confは誤った構成で汚染されています。

これを防ぐ方法はありますか?この場合、check_cmdは使用できないようです。

更新する前に一連のファイルがすべて有効であることを保証するにはどうすればよいですか?

答えて

0

1つの回避策は、間違いがあった場合に元のプールファイルを回復することです。 ここでは例を示しますが、この状態がより大きくなるようになると、jinjaを使用して開始することをお勧めします。

fpm-conf: 
    file.managed: 
    - name: /etc/php-fpm.conf 
    - source: salt://php/template/fpm.jinja 
    - user: someuser 
    - group: somegroup 
    - mode: 644 
    - template: jinja 
    - check_cmd: /usr/sbin/php-fpm -ty 
    - require: 
     - pkg: php-package 

fpm-pool-a: 
    file.managed: 
    - name: /etc/php-fpm.d/a.conf 
    - source: salt://php/template/fpm-a.jinja 
    - user: someuser 
    - group: somegroup 
    - file_mode: 644 
    - template: jinja 
    - require: 
     - pkg: php-package 
    - require_in: 
     - file: fpm-conf 
    - backup: minion 

fpm-pool-b: 
    file.managed: 
    - name: /etc/php-fpm.d/b.conf 
    - source: salt://php/template/fpm-b.jinja 
    - user: someuser 
    - group: somegroup 
    - file_mode: 644 
    - template: jinja 
    - require: 
     - pkg: php-package 
    - require_in: 
     - file: fpm-conf 
    - backup: minion 

fpm-pool-a-recover: 
    module.run: 
    - name: file.restore_backup 
    - path: /etc/php-fpm.d/a.conf 
    - backup_id: 0 
    - onfail: 
     - file: fpm-conf 

fpm-pool-a-recover: 
    module.run: 
    - name: file.restore_backup 
    - path: /etc/php-fpm.d/b.conf 
    - backup_id: 0 
    - onfail: 
     - file: fpm-conf 

ローカルお知らせ- backup: minionさらに、この意志のバックアップファイルは/ var /キャッシュ/塩/手先/ file_backupへ/ ...

だから、FPM-プール-A、メイン設定が失敗した場合、 -recoverとfpm-pool-b-recoverは、元のファイルの最新のバックアップを起動して回復します。

関連する問題