Cp-ansible: 记录监听器不同 ip/hostname 的用法

是的...这个功能在使用 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

看起来我们还没有在那里记录自定义侦听器，但这似乎是一个更好的地方，因为您可以包含多个示例/描述

干草 - 是的，公平点。 在其他文档中可能会更好。

我想知道的另一件事 - 当我将同一主机的两个不同接口用于不同的侦听器并希望两者都使用 SSL 时：

我要么需要两个匹配两个主机名的 SSL 证书（这个角色目前不会这样做），要么我关闭 SSL 主机名检查（并使用 IP）或 SSL。 在这种情况下，您将如何使用此 repo？

我将在下一个版本的文档中添加监听器的内容，立即进行编辑！

好问题！ 所以有 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？

雅自签名的东西很漂亮，但我想知道人们是否真的在演示之外使用

我更喜欢单一的密钥库/信任库方法，我意识到从技术上讲，每个主机名可能有一个。

它变得令人费解，因为在一个密钥库中，您可以拥有：

• SAN 中具有多个主机名的证书
• 或多个证书，每个证书在其 DNAME 中都有主机名
  因此，我认为最好只做一个密钥库

你怎么看？

ha - 现在你正在提出卷积：思考：
我实际上想要多个密钥库。 但也许复杂性确实是一种宁愿支持 SAN 和一个密钥库的东西。 但这只是我自发的回答 - 我会再考虑一下

我今天在“狂野”中看到了一个非常好的解决方案：

在 kafka-brokers 上为内部设备部署一个 /etc/hosts 条目，其主机名与外部设备相同。

如果 kafka 请求来自“内部”，则它使用 etc/hosts 条目
并以“内部”侦听器为目标，但是使用外部主机名，因此证书解析有效。
我想知道这是否是一个合法的通用解决方案：思考：

@Fobhep这是我多年来在生产中使用的东西。 当您想在多宿主环境中设置 SASL 时，这实际上是强制性的。

@jrevillard感谢您的反馈。
也许我们应该让那些剧本也这样做

@Fobhep不确定我们是否应该实现这一点，我们尽量减少对操作系统的修改，除非它对 Kafka 有直接影响（例如，打开文件限制）。 我认为将其记录为多宿主环境的潜在解决方案可能是有意义的，但是代表用户修改主机文件似乎有风险并且没有足够的价值。 然而，很高兴在最后一点被证明是错误的。

@JumaX公平点 - 记录可能是个好主意。
实施它会走得太远 - 我同意。
恕我直言，我们可以关闭它：)

@Fobhep hosts_example.yml 现在已更新，以显示如何在 6.0 版本中映射 ips/主机名。 将其关闭为已解决。