web-dev-qa-db-ja.com

Salt top.slsは、gitfsを使用した `salt-runfileserver.update`では更新されません

ソルトマスターに接続されているソルトミニオンが1つあります。最近、大きな.slsの名前を「webserver.sls」から「jetty.sls」に変更しました。私はpygit2とsshでgitfsバックエンドを使用しています。 gitfsバックエンドのみを有効にしました。 /etc/salt/master：

fileserver_backend:
#  - roots
  - git

gitfs_provider: pygit2
gitfs_remotes:
  - [email protected]:Groomblecom/[repo].git:
    - pubkey: /root/salt-credentials/id_rsa.pub
    - privkey: /root/salt-credentials/id_rsa

ただし、salt-run fileserver.update && salt '*' state.highstateを実行すると、エラーが発生します。

Data failed to compile:
----------
    No matching sls found for 'webserver' in env 'base'

salt '*' state.show_sls jettyを実行すると、期待される（長い）出力が得られます。これは、bitbucketリポジトリに表示されるものと一致しています。 salt '*' state.show_topを実行すると、次のようになります。

----------
    base:
        - common
        - ingress
        - webserver

これは、bitbucketリポジトリのtop.slsと矛盾しています。

base:
  '*':
    - common
  '*ingress*':
    - ingress
    - jetty
    - nginx

salt-run fileserver.updateまたはrm -rf /var/cache/salt/* && service salt-master restartを実行しても、出力には影響しません。

この動作に既知のバグ（および回避策）があるかどうか、実際のキャッシュを強制的にクリアする方法があるかどうか、または構成ミスをしたかどうかを知りたいです。

gitconfiguration-managementsaltstack
5
Groomblecom

エラーの理由は、saltがすべてのブランチを考慮し、すべての（！）ブランチをマージして最終的なtop.slsをコンパイルするためです。私はマスターの後ろにいくつかのコミットであった古いブランチを持っていたので、それでもwebserver.slsを参照していました。解決策は非常に簡単です。/etc/salt/masterに以下を追加するだけです。

gitfs_env_whitelist:
  - master

または、プライマリブランチがマスターでない場合は、マスターをブランチ名に置き換えます。

2
Groomblecom

その理由は、saltがすべてのブランチをマージして最終的なtop.slsをコンパイルするためです。これを/etc/salt/masterに追加することで、修正することができました。

gitfs_env_whitelist:
  - base

Saltはmasterブランチをbase環境にマップするため（gitfs_baseのおかげで）、ホワイトリストへの正しいenvはbaseではなくmasterです。

1
Alex Quach