Cp-ansible: Документируйте использование разных IP / имен хостов для слушателя

да ... эта функция очень полезна при работе с 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

И полагайтесь на слияние хэшей, чтобы объединить dict kafka_broker_custom_listeners ... к сожалению, на мой взгляд, это действительно сбивает с толку документ в файле hosts_example.yml.

Вы читали здесь документы:
https://docs.confluent.io/current/installation/cp-ansible/index.html

Не похоже, что у нас еще есть задокументированные пользовательские слушатели, но это кажется лучшим местом, потому что вы можете включить несколько образцов / описаний.

сено - да, справедливый момент. Наверное, было бы лучше в других документах.

Еще одна вещь, о которой мне было интересно, - когда я использую два разных интерфейса одного и того же хоста для разных слушателей и хочу SSL для обоих:

Мне либо нужны два сертификата 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 для своих собственных сертификатов?

Да, самоподписанный материал отличный, но мне интересно, действительно ли люди используют, если помимо демонстрации

Я предпочитаю подход с одним хранилищем ключей / хранилищем доверенных сертификатов, который, как я понимаю, технически может быть по одному на имя хоста.

Это становится запутанным, потому что внутри одного хранилища ключей вы можете иметь:

• сертификат с несколькими именами хостов в SAN
• или несколько сертификатов, каждый с именами хостов в их DNAME
  Из-за этого я думаю, что лучше всего сделать одно хранилище ключей

Что ты думаешь?

ха - теперь, когда вы поднимаете свертку: мышление:
На самом деле я был готов к нескольким хранилищам ключей. но, возможно, сложность действительно заключается в том, что предпочтительнее проголосовать за SAN и одно хранилище ключей. Но это всего лишь мой спонтанный ответ - я подумаю еще немного.

Увидел сегодня в «дикой природе» очень красивое решение:

Развертывание записи / etc / hosts на брокерах kafka для внутреннего устройства с тем же именем хоста, что и внешнее устройство.

Если kafka-запрос приходит "изнутри", он использует запись etc / hosts
и нацелен на «внутренний» слушатель, однако использует внешнее имя хоста, и, таким образом, разрешение сертификата работает.
Интересно, может ли это быть законным общим решением?

@Fobhep - это то, что я использую в производстве уже много лет. Это практически обязательно, если вы хотите настроить SASL в многодомной среде.

@jrevillard благодарит за отзыв.
Может быть, тогда мы должны заставить эти пьесы делать то же самое

@Fobhep Не уверен, что мы должны это реализовать, мы стараемся свести к минимуму модификацию ОС, если только это не окажет прямого влияния на Kafka (например, ограничения открытых файлов). Я думаю, что имеет смысл задокументировать это как потенциальное решение для многосетевых сред, однако изменение файла hosts от имени пользователя кажется рискованным и не имеет достаточной ценности. Однако счастлив, что ошибся в этом последнем пункте.

Справедливый пункт @JumaX - документирование, вероятно, хорошая идея.
Я согласен с тем, что его реализация зайдет слишком далеко.
Имхо, тогда мы можем закрыть это :)

@Fobhep файл hosts_example.yml теперь обновлен, чтобы показать, как вы можете сопоставить IP-адреса / имена хостов в версии 6.0. Закрытие этого как решенного.