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 딕셔너리를 병합하기 위해 해시 병합에 의존합니다... 불행히도 내 의견으로는 hosts_example.yml 파일에 문서화하는 것이 정말 혼란스러워 보입니다.

여기에서 문서를 읽었습니까?
https://docs.confluent.io/current/installation/cp-ansible/index.html

아직 문서화된 사용자 정의 리스너가 없는 것 같지만 여러 샘플/설명을 포함할 수 있기 때문에 더 나은 장소인 것 같습니다.

헤이 - 네 공정한 지적입니다. 아마도 다른 문서에서 더 나을 것입니다.

내가 궁금했던 또 다른 사항 - 다른 수신기에 대해 동일한 호스트의 두 가지 다른 인터페이스를 사용하고 둘 다에 대해 SSL을 원할 때:

두 호스트 이름과 일치하는 두 개의 SSL 인증서(현재 이 역할은 수행하지 않음)가 필요하거나 SSL 호스트 이름 검사(및 IP 사용) 또는 SSL을 모두 함께 끕니다. 이러한 시나리오에서 이 리포지토리를 어떻게 사용하시겠습니까?

다음 릴리스의 문서에 청취자 항목을 추가하고 지금 편집 작업을 하고 있습니다!

좋은 질문! 따라서 호스트에 키 저장소를 두는 세 가지 방법이 있습니다.

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을 정의하도록 하시겠습니까?

Ya 자체 서명한 것은 멋지지만 사람들이 데모를 제외하고 실제로 사용하는지 궁금합니다.

기술적으로 호스트 이름당 하나씩 있을 수 있는 단일 키 저장소/신뢰 저장소 접근 방식을 선호합니다.

하나의 키 저장소 안에 다음을 가질 수 있기 때문에 복잡해집니다.

• SAN에 여러 호스트 이름이 있는 인증서
• 또는 각각 DNAME에 호스트 이름이 있는 여러 인증서
  이 때문에 하나의 키 저장소를 수행하는 것이 가장 좋다고 생각합니다.

당신의 생각은 무엇입니까?

하 - 이제 컨볼루션을 불러오고 있습니다.생각:
나는 실제로 여러 키 저장소를 찾고 있었습니다. 그러나 복잡성은 실제로 SAN과 하나의 키 저장소를 찬성하는 것입니다. 그러나 이것은 내 즉흥적인 대답일 뿐입니다. 나는 이것을 조금 더 생각해 볼 것입니다.

나는 오늘 "야생"에서 아주 좋은 해결책을 보았습니다.

외부 장치와 호스트 이름이 동일한 내부 장치에 대한 kafka-brokers에 /etc/hosts 항목 배포.

kafka 요청이 "내부"에서 오는 경우 etc/hosts 항목을 사용하고 있습니다.
그러나 외부 호스트 이름을 사용하여 "내부" 수신기를 대상으로 하므로 인증서 확인이 작동합니다.
이것이 합법적인 일반적인 해결책이 될 수 있는지 궁금합니다.

@Fobhep 이것은 몇 년 동안 프로덕션에서 사용하는 것입니다. 이것은 멀티홈 환경에서 SASL을 설정하려는 경우에 실질적으로 필수입니다.

@jrevilled 피드백 주셔서 감사합니다.
어쩌면 우리는 그 플레이북도 그렇게 하도록 해야 합니다.

@Fobhep 이것을 구현해야 하는지 확실하지 않습니다. 특히 Kafka에 직접적인 영향을 미치지 않는 한 OS 수정을 최소화하려고 합니다(예: 열린 파일 제한). 이것을 멀티홈 환경에 대한 잠재적 솔루션으로 문서화하는 것이 합리적일 수 있지만 사용자를 대신하여 호스트 파일을 수정하는 것은 위험하고 가치가 충분하지 않은 것 같습니다. 그러나 이 마지막 점에서 잘못된 것으로 판명되어 기쁩니다.

@JumaX 공정한 요점 - 문서화는 아마도 좋은 생각일 것입니다.
그것을 구현하는 것은 너무 멀리 갈 것입니다. 동의합니다.
Imho 우리는 이것을 닫을 수 있습니다 :)

@Fobhep 이제 6.0 릴리스에서 ips/hostname을 매핑하는 방법을 보여주기 위해 hosts_example.yml이 업데이트되었습니다. 해결된 대로 종료합니다.