Ansible: ロールのデフォルトディレクトリにある複数のファイル

tasksにmain.ymlを含めることができます。これには、 tasksサブディレクトリ内であっても、他のファイルが含まれます。たとえば、メインの2つのコンポーネントfooとその大きな役割のbarを構成します。

- include: foo/main.yml
- include: bar/main.yml

デフォルトの役割変数にinclude_varsモジュールを使用すると、デフォルト変数が最初に存在する理由が無効になります。つまり、役割/プレイブックの他の部分で簡単に上書きできる「最後の手段のデフォルト」を提供するために使用されます。

defaults/ディレクトリ内の複数のファイルのアイデアは以前IRCで議論されていましたが、 inventory/group_vars/およびinventory/host_vars/ディレクトリと同様にinventory/group_vars/ defaults/ディレクトリを解析すると結論付けました。あった方がよい。 必要なコードはすでに存在しており、役割のデフォルトに簡単に適合できることを願っています。

+1

+1

それがあればいいのに！

+1

ええ、上記のようにdefaults / *が自動的に検出され、ロードされたと仮定しました。 推奨される回避策（タスク内の追加のデフォルトファイルを含む）は、優先順位が

Ansible2.x変数の優先順位

    role defaults [1] (loading all role defaults here critical)
    inventory vars [2]
    inventory group_vars
    inventory host_vars
    playbook group_vars
    playbook host_vars
    host facts
    registered vars
    set_facts
    play vars
    play vars_prompt
    play vars_files
    role and include vars (hack coming in here will override everything above)
    block vars (only for tasks in block)
    task vars (only for the task)
    extra vars (always win precedence)

これは＃8121に関連している可能性があります

+1

+1

可変の優先順位の制約があるため、必ず機能が必要です。
これにより、変数のクラスごとにデフォルトファイルを定義し、明確な分離を維持することもできます。 たとえば、ネットワーキングでは、これにより、IPv4用に1つ、IPv6用に1つ、SNMP用に1つのデフォルトファイルを定義できます...
最後に、これらのファイルを「デフォルト」の下の別のフォルダに配置できるようにする必要があるようです。

これを自分で叩くだけなので、間違いなく+1

これは本当にPITAです。
解決策を提案できれば、 include_varsに似ていますが、 meta/main.yml 、ロード順序を指定するオプションを追加することです。

- dependencies: []
- default_vars:
  - "main.yml"
  - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"

これにより、オプションをデフォルトで["main.yml"] 、既存のコードを壊さないようにすると同時に、開発者は選択したコンテキストに基づいて詳細な変数を定義できます。

変。 私はこれが箱から出してうまくいくだろうと完全に思った。 数回のansibleの1つは、実際には驚き最小の原則に少し違反しています...

間違いなく+1

vars/も同じですが、＃2958がこれに反対することを決定していたようです

@cornfeedhoboの例は、私のユースケースと

別のインターフェースオプションは次のとおりです。

• include_varsモジュール 'as_default'にオプションを追加します。これにより、インクルードされたファイルがデフォルトであるかのように処理されます。

私にとっては、単一のファイルを含む「デフォルト」ディレクトリがあることは、本当に奇妙で直感に反しているように見えます。
つまり、単一の__main__.pyファイルを含むPythonモジュールを見たことがありますか？

そのため、このチケットで説明されている機能はすでに存在していると直感的に思いました。 「もちろん、複数のデフォルトファイルを持つことができます。そのためのディレクトリがあります」

include_role使用すると、 defaults_fromオプションを使用して「代替」ファイルをhttp://docs.ansible.com/ansible/include_role_module.htmlで指定できます。

defaults/main.yml分割が必要な状況になりました。 私の👍を問題に追加しました。

ここでも同じです、私も必要です
+1

+1

@bcocaは素晴らしい追加であり、柔軟性を追加しますが、ここでは問題に対処せず、適切なデフォルトを簡単に設定する役割を強化することを目的とする場合、プレイブックライターに責任を負わせます。

上記の私のコメントを確認し

はい、これは2k行のファイルを回避するのに非常に役立つ機能です。
+1

+1

+1

👍

+1

+1

+1
ここで同じ問題。 main.ymlが大きすぎます。複数のファイルに分割されています。 これはdirであるため、「正常に機能」し、defaults /の下でファイル内のすべての変数をロードすると想定しました。 ノージョイ。

+1

+1

+1

👍

+1

+1

👍

皆さんは+1コメントごとに親指を立てることができますが、サブスクライバーの数を追跡できるかどうかは非常に疑わしいので、+ 1を追加することは依然として望ましいサポートを示すための適切な方法です。

問題の注意が問題の購読者数に明確に結びつくまで、+ 1のコメントが表示されることを永遠に期待してください。

期待できるのは、代わりにansibleチームが問題のコメントをロックすることです。したがって、スパマーにならないでください。また、それらを防御しないでください。

期待できるのは、代わりにansibleチームが問題のコメントをロックすることです。したがって、スパマーにならないでください。また、それらを防御しないでください。

彼らはそれを行うことができますが、これは、特に古いroles includeメソッドと一緒に2.xにinclude_roleが導入されて以来、役割を適切に開発できるようにするための中心的な問題です。 include_roleと互換性のある役割を設計する場合、これは、開発を古いroles方法だけの場合よりもはるかにモジュール化され、柔軟にするため、望ましい方法です。プレイブックのタスクとしてデフォルトを自分で含めるか、役割が正しく機能するためにこれを行う方法を知っている必要のないエンドユーザーにお金を渡すか、プラットフォーム/ディストリビューション/リリースをネストされたレベルとして追跡します。開発の地獄を複雑にする役割変数（ただし、ここで20の異なるプラットフォームバージョンをサポートできる役割を作成したので機能し

したがって、彼らがこれをロックし、1年前の問題にまったく応答せず、人々が実際の解決策を作成するのを妨げている重大な問題について話し合うことに興味がないことをコミュニティに知らせる場合、彼らは間違いなく人々が固執しないことを期待できます周りにそして製品を使い続けてください。 彼らが返答し、彼らがその問題に同意するかどうかの感覚を与えるならば、多分人々は問題に注意を引くためにそれを+1するのをやめるでしょう。

実際に実際に使用するとデフォルトにどのように影響するかを考えずにinclude_roleをリリースしたため、これは問題にすぎません。 ここでの問題の核心は、役割を適切に機能させるため、または両方を同時に機能させるために追加の作業を追加するために、誰かにrolesとinclude_roleどちらを使用するかを選択させることです。

私の2セント。

PS通知が必要ないために+1を反対票を投じる場合は、右上の購読解除ボタンを押すと、通知を受け取ることができなくなります。

OK、この問題はあなたにとって重要です。 ポイントがわかります。 僕にも。 それが私が購読している理由です、ところで、それが私が購読を解除したくない理由です、そしてそれが私がスパマーに反対票を投じる理由です、そしてそれが私が元のコメントに賛成する理由です、それはそれに対する_怠惰な_サポートを示す文明的な方法です。

この機能のリクエストに自分の声を追加し、ユースケースを詳しく説明したいと思います。 大きなmain.ymlを分割する単純な機能に加えて、次のようなことを行う機能は素晴らしいでしょう：

- name: Some name
  include_default_vars:
  with_first_found:
    - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"
   - main.yml

これで達成したいと思っているのは、[例として]すべてのssh_configおよびsshd_configオプションをサポートし、複数のOSとバージョンをサポートするopensshロールです[つまり、 Debian 8/9、EL6 / 7など]が、ユーザーが変数を設定せずに呼び出すと、OS_majorversionのデフォルト設定に設定を安全に構築しますが、ユーザーが使用可能なオプションをオーバーライドすることができます。

現在のところ、これらのOSのデフォルトをinclude_varsに入れると、優先順位が高すぎて、ユーザーはインベントリ、group_vars / all、group_vars / groupname、host_varsなどでこれらの設定を上書きできません。

今これを行う方法があると確信していますが、私が考えることができるものはすべて、非常に不潔で醜く、維持するのが難しいでしょう。 さらに、少なくともこの時点まで、＃ansibleに出会った人は誰も、これを優雅で保守可能な方法で行う方法について、これ以上のアイデアを持っていません。

この機能を追加すると、これが可能になり、github / galaxyでより高品質のロールを利用できるようになる可能性があります。

@ ralphie02いいえ、それはこのスレッドが何であるかについての解決策に近いところではありません。 これは通常のホストベースの変数であり、マルチプラットフォームの役割のデフォルトを設定する要件とは異なります。

同様のVARS / feature_idea： https://github.com/ansible/ansible/issues/11639

これは本当にPITAです。
解決策を提案できれば、 include_varsに似ていますが、 meta/main.yml 、ロード順序を指定するオプションを追加することです。

- dependencies: []
- default_vars:
  - "main.yml"
  - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"

これにより、オプションをデフォルトで["main.yml"] 、既存のコードを壊さないようにすると同時に、開発者は選択したコンテキストに基づいて詳細な変数を定義できます。

これは本当に良い解決策だと思います。現在、os / version / etcによって異なるデフォルトのセットを設定する簡単な方法はありません。 この実装は下位互換性も維持するため、これも適切な選択です。

@abedwardsw （前のコメント）に沿って：
@cornfeedhobo （15：+1 ：！）からの@ doubletwist13からのもう少し最近の本当に役立ちます。
https://github.com/hortonworks/ansible-hortonworks

彼らのコメントへの直接の参照：

• https://github.com/ansible/ansible/issues/14248#issuecomment -254059046
• https://github.com/ansible/ansible/issues/14248#issuecomment -329027052

@geerlingguyの提案（2016年から！）と、そこにある私のコメント（関連する問題を収集しようとする）も参照してください： //github.com/ansible/proposals/pull/21#issuecomment -470048538