web-dev-qa-db-ja.com

他の何かが実行されるまでコマンドの実行を遅らせる

Saltを使用してデプロイスクリプトを作成しようとしています。それは主に機能します。それが完全に機能するために、私はハイステートを数回実行する必要があります。私の最大の問題は、特定の最初のコマンドに基づいてコマンドを次々に実行する方法を処理することです。

これが私のdemo.slsソルト状態です：

{% set web_root = "/var/www/demo/" %}

/var/www/venv/demo:
  virtualenv.managed:
    - system_site_packages: False
    - require:
      - pkg: python-virtualenv

demo:
  git.latest:
    - name: git://localhost/demo.git
    - target: {{ web_root }}

demo_pip:
  cmd.wait:
    - name: 'source /var/www/venv/demo/bin/activate && pip install -r requirements.txt'
    - cwd: {{ web_root }}
    - watch:
      - git: demo

run_migrations:
  cmd.wait:
    - name: 'source /var/www/venv/demo/bin/activate && python manage.py syncdb --noinput'
    - cwd: {{ web_root }}
    - watch:
      - cmd: demo_pip

restart_gunicorn:
  cmd.wait:
    - name: supervisorctl restart gunicorn
    - watch:
      - cmd: run_migrations

demo_pipがgit呼び出しの後に実行されるように設定しましたが（これはうまく機能します）、正直なところ、demo_pipは実際には実行されません。 saltからの出力は実行されたというものですが、requirements.txtの要件はどれもインストールされていません。

要件をvirtualenv.managedセクションに入れて実行しようとしましたが、その時点で2つのハイステートを実行する必要があります。 1）gitから最新のものを入手するには、ボットを排他的に実行しているようです2）要件をインストールします。何らかの理由で、demoの後にvirtualenv.managedセクションを配置した後でも、新しい要件ファイルは登録されません。

間違ったcmdを使用していますか？または、注文に問題がありますか？

saltstack
4
Buddy Lindsey

私はついにこれを理解しました。ファイル/フォルダのアクセス許可の問題のようです。 file.managed内のすべてのフォルダーの/var/wwwをグループwww-dataに設定しました。また、すべてがwww-dataとして実行されることを確認し、その後、期待どおりに動作し始めました。

1
Buddy Lindsey