Cp-ansible: リスナーの異なるIP /ホスト名の使用法を文書化する

ya ...この機能は、awsを使用するときに非常に役立ちます。私が通常行うことは、次のとおりです。

kafka_broker:
  vars:
    kafka_broker_custom_listeners:
      external:
        name: EXTERNAL
        port: 9093
  hosts:
    ip-172-31-43-14.us-west-2.compute.internal:
      ansible_ssh_host: ec2-34-209-19-19.us-west-2.compute.amazonaws.com
      kafka_broker_custom_listeners:
        external:
          hostname: ec2-34-209-19-19.us-west-2.compute.amazonaws.com

そして、ハッシュマージに依存してkafka_broker_custom_listeners dictをマージします...残念ながら、私の意見では、hosts_example.ymlファイルに文書化するのは本当に混乱しているようです。

ここのドキュメントを読んだことがありますか：
https://docs.confluent.io/current/installation/cp-ansible/index.html

まだカスタムリスナーが文書化されているようには見えませんが、複数のサンプル/説明を含めることができるため、より良い場所のようです。

干し草-ええフェアポイント。 おそらくそれは他のドキュメントでより良いでしょう。

私が疑問に思っていたもう1つのことは、同じホストの2つの異なるインターフェイスを異なるリスナーに使用し、両方にSSLが必要な場合です。

両方のホスト名に一致する2つのSSL証明書が必要であるか（この役割では現在実行されないこと）、SSLホスト名チェックをオフにする（そしてIPを使用する）か、SSLをすべて一緒に使用します。 このようなシナリオでこのリポジトリをどのように使用しますか？

次のリリースのドキュメントにリスナーのものを追加し、今すぐ編集に取り組んでいます！

素晴らしい質問です！ したがって、ホストにキーストアを配置する方法は3つあります。

1. あなた自身の証明書を渡す
2. 独自のキーストアを渡す
3. あなたのためにそれをすることができます

1と2の場合、複数のSAN拡張を使用して証明書を渡すことができます。

3番目の場合、自動生成された証明書にホスト名のリストを渡す小さな機能を実際に追加しました。
https://github.com/confluentinc/cp-ansible/blob/5.5.0-post/roles/confluent.kafka_broker/tasks/main.yml#L39

次に、それらのホスト名がSAN拡張機能に配置されます。
https://github.com/confluentinc/cp-ansible/blob/5.5.0-post/roles/confluent.ssl/tasks/self_signed_certs.yml#L36

ここにcert_extensionフィルターがあります（振り返ってみると、結合フィルターはここで機能していました）：
https://github.com/confluentinc/cp-ansible/blob/5.5.0-post/filter_plugins/filters.py#L56

ただし、現時点でcp-ansibleは複数のキーストアを処理できないことに注意してください。

素晴らしい-更新されたドキュメントを楽しみにしています！
そして、詳細な回答に感謝します-あなたの自己署名コードはとても素晴らしいです！
原則として、複数のキーストア機能を持つことに興味がありますか？
とにかくリスナーごとに個別にSSLを設定しているので、実装するのはそれほど難しくないはずです。
それとも、ユーザーが自分の証明書のSANを定義することに依存したいですか？

自己署名のものは気の利いたものですが、デモを超えた場合、人々は本当に使用するのだろうかと思います

私は単一のキーストア/トラストストアアプローチを好みます。これは、技術的にはホスト名ごとに1つ存在する可能性があることを認識しています。

1つのキーストア内に次のようなものがあるため、複雑になります。

• SAN内に複数のホスト名を持つ証明書
• または、それぞれのDNAMEにホスト名が含まれる複数の証明書
  このため、キーストアを1つだけ実行するのが最善だと思います

あなたの考えは何ですか？

ha-畳み込みを引き起こしているので：thinking：
私は実際に複数のキーストアを探していました。 しかし、おそらく複雑さは、SANと1つのキーストアをむしろ支持するものです。 しかし、これは私の自発的な答えにすぎません-私はこれをもう少し考えます

私は今日、「野生」の中で非常に素晴らしい解決策を見ました。

外部デバイスと同じホスト名を持つ内部デバイスのkafka-brokersに/ etc / hostsエントリをデプロイします。

kafka-requestが「内部」から送信されている場合は、etc / hostsエントリを使用しています。
「内部」リスナーをターゲットにしますが、外部ホスト名を使用するため、証明書の解決は機能します。
私はこれが正当な一般的な解決策である可能性があるかどうか疑問に思っています：思考：

@Fobhepこれは私が何年もの間本番環境で使用しているものです。 マルチホーム環境でSASLをセットアップする場合、これは実質的に必須です。

@jrevillardフィードバックをありがとう。
多分私達はそれらのプレイブックにそれをさせるべきです

@Fobhepこれを実装する必要があるかどうかは

@JumaXフェアポイント-文書化はおそらく良い考えです。
それを実装するのは行き過ぎだろう-私は同意する。
私たちはこれを閉じることができます:)

@Fobhep hosts_example.ymlが更新され、6.0リリースでips / hostnamesをマップする方法が示されるようになりました。 解決済みとしてこれを閉じます。