Ansible-role-nginx-config: nginx_main_template。*のデフォルトがありません

@alexseguraに完全に同意します。 単一のパラメーターを定義するオプションは、バックログにあります。 この役割の開発は私が最近望んでいるよりも少し遅いですが、物事は次の数ヶ月で再び回復し始めるはずです。 そうは言っても、ご希望の場合はお気軽にPRを提出してください😄

メッセージありがとうございます。
はい、プルリクエストを投稿できます🙂

この役割であちこちで見られる問題は、デフォルトがハードコーディングされていることです。
したがって、デフォルトが変更された場合は、 defaults/main.ymlとテンプレートの両方で変更することを忘れないでください。

https://github.com/nginxinc/ansible-role-nginx/blob/a92d424bdb5dc51b143c702754bed761e919a576/tasks/conf/upload-config.yml#L8 -L14

デフォルトにdictを使用すると、それらが置き換えられるためだと思います。 hash_behavior設定がありますが、それはグローバルだと思います。

ロールの「変更されていない」デフォルト変数を取得する方法を知っていますか？
role_defaults['var_name']ようなもの？

@alexsegura私はこの振る舞いを達成するための素晴らしい方法を知りません。 理想的には、ロールがdefaults/main.yml値を使用せずに、有用な構成をデプロイできるセットアップが必要です。

頭に浮かぶ主な考えは、 vars/main.ymlを使用してデフォルト値の一部をハードコーディングしてから、 | default(var_main_upload_src)ようなことを行うことですが、それが最善の方法かどうかはわかりません。

おそらくそれを行う唯一の方法は、デフォルトのフィルターを使用してテンプレート自体を使用することです。

そうです、これはテンプレート関連のパラメーターに適したソリューションです（テンプレートファイルを見ると、デフォルトのフィルターがすでにいくつかの場所で使用されています）。 そして確かに、それは元の問題に対処するでしょう。 それはかなり時間のかかる作業ですが、実行可能です。

ただし、テンプレートに関連しない変数の最善のアプローチは何かという疑問が残ります。さらに、最善のアプローチはありますか？

私があちこちで見ていることから、デフォルトの最善のアプローチは、dictの使用を避けることです。

nginx_main_template_user: www-data

それ以外の

nginx_main_template:
  user: www-data

それは部分的に問題に対処するでしょう、そして最初はそれが役割がどのように構成されたかでした。 しかし、より複雑なテンプレートオプション（複数のロケーションブロックなど）を導入し始めたとき、辞書とリストの方が理にかなっています。

または、デフォルトとユーザーの構成に別々の辞書を使用して、それらをcombineフィルターとマージすることもできます。 私はこの方法が使用される場所に気流を展開する役割を使用してきました：
airflow_config: "{{ airflow_defaults_config | combine(airflow_user_config, recursive=True) }}"
これにより、テンプレートにデフォルトをハードコーディングする必要もなくなると思いますか？

私が言及している役割は、ここで確認でき

うーん、それは興味深いアプローチであり、私はそれが機能しているのを見ることができます。 小さな辞書（ mainまたはstreamテンプレートを考えています）の1つを使用して小さなPoCを作成し、実際にどれだけうまく機能するかを確認する価値があるかもしれません。

私はすでにメインテンプレートでこれを試しましたが、期待どおりに機能していました。 ただし、最小限の労力で行ったため、デフォルトの2つの辞書nginx_default_main_templateとユーザープレイブックのnginx_user_main_templateをnginx_main_templateにマージしました。
これにより重大な変更が発生するため、新しい名前でマージされたディクショナリを使用するようにロールをリファクタリングし、PRを送信します。

マージするユーザー辞書が複数ある可能性があるため、httpテンプレートははるかに困難です。 マージ演算子と組み合わせたアンカーとエイリアスは代替手段となる可能性がありますが、その場合はユーザーがマージを行う責任があります。
私もその前線でしばらく過ごします。

ところで：複数のhttpテンプレートを定義するためにリストの代わりに辞書を使用することを選択した理由はありますか？ 私が見つけたものから、キーは実際には使用されていません。

ところで：複数のhttpテンプレートを定義するためにリストの代わりに辞書を使用することを選択した理由はありますか？ 私が見つけたものから、キーは実際には使用されていません。

いいえ、そうではありません。 後から考えると、定義するHTTPテンプレートごとにキーを設定すると読みやすさが向上する可能性があると思いますが、簡単になる場合はリストに変更することに反対していません。

私は同様の問題に遭遇し、その後この問題に遭遇しました。 別の視点を提供したいと思います。

構成のデフォルト値はハードコーディングしないでください。インストールするソフトウェアに任せてください。

@alexseguraがすでに指摘しているように、問題は、値の同期を維持する必要があることです。これは、本質的に常にそうであるとは限りません（人間はエラーが発生しやすい）。

デフォルトの構成を提供する必要があると思われる場合は、サブセクションを別々のディレクトリに保持し、ユーザーが値を指定した場合はそれらを最下位レベルで結合してから、構成にマージすることをお勧めします。

しかし、それでも、imoはロールの範囲内ではありません。構成をターゲットにコピーし、その値に問題がないことを確認しないでください。 構成エラーのためにソフトウェアを起動できなかった場合（または、可能な場合はソフトウェアの検証機能を使用した場合）、せいぜいエラーが発生します。

おかしなことに、私は現在、その役割でテンプレートがどのように機能するかを改善する方法に取り組んでいます。 それは非常に遅いプロセスでした（私は現時点でその役割に専念するためにかなり限られた帯域幅を持っています）が、私はこれらの問題に対処するOKの解決策を思いついたと思います。 最大数か月以内に別のブランチに変更を反映させることを望んでいます😉

この問題の進展はありますか？

いいえ。 「近い」将来にこれに戻る計画はまだありますが、他のいくつかのタスクが優先されています。