Cp-ansible: استخدام المستند لـ ip / hostname مختلف للمستمع

تم إنشاؤها على ٩ يونيو ٢٠٢٠  ·  12تعليقات  ·  مصدر: confluentinc/cp-ansible

عند إعداد مستمع يمكن للمرء تغيير ip / hostanme لذلك.
رمز هذه الأدوار قادر على القيام بذلك ، ومع ذلك يمكن للمرء إضافة ذلك إلى مثال ملف المضيفين.

يمكنني إنشاء علاقات عامة إذا كانت هذه إضافة مرغوبة :)
على سبيل المثال

""
الوسيط:
الاسم: BROKER
المنفذ: 9091
ssl_enabled: خطأ
ssl_mutual_auth_enabled: خطأ
sasl_protocol: لا شيء
داخلي:
الاسم: داخلي
المنفذ: 9092
اسم المضيف: ip-172-31-18-160.us-west-2.compute. داخلي: 19091
ssl_enabled: صحيح
ssl_mutual_auth_enabled: خطأ
sasl_protocol: scram

enhancement question

ال 12 كومينتر

نعم ... هذه الميزات مفيدة للغاية عند العمل مع 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 (واستخدم IPs) أو SSL معًا. كيف يمكنك استخدام هذا الريبو لمثل هذا السيناريو؟

سأضيف مواد المستمعين إلى مستنداتنا للإصدار التالي ، وأعمل على تعديل الآن!

سؤال رائع! لذلك هناك 3 طرق لوضع ملفات تخزين المفاتيح على المضيفين:

  1. تمرير الشهادات الخاصة بك
  2. اجتياز keystores الخاصة بك
  3. لديك ansible تفعل ذلك من أجلك

بالنسبة إلى 1 و 2 ، يمكنك تمرير شهادات بامتدادات SAN متعددة.

بالنسبة للرقم 3 ، لقد أضفت بالفعل ميزة صغيرة تمرر قائمة بأسماء المضيف إلى الشهادات التي تم إنشاؤها تلقائيًا:
https://github.com/confluentinc/cp-ansible/blob/5.5.0-post/roles/confluent.kafka_broker/tasks/main.yml#L39

ثم يتم وضع أسماء المضيفين هذه في امتداد SANs:
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's لشهاداته الخاصة؟

يا ، الأشياء الموقعة ذاتيًا رائعة ، لكنني أتساءل عما إذا كان الناس يستخدمون حقًا ما إذا كان يتجاوز العرض التجريبي

أنا أفضل نهج keystore / Truststore الفردي ، والذي أدرك من الناحية الفنية أنه يمكن أن يكون هناك واحد لكل اسم مضيف.

يصبح معقدًا لأنه داخل ملف تخزين مفاتيح واحد يمكن أن يكون لديك:

  • شهادة بأسماء مضيف متعددة في شبكات SAN
  • أو شهادات متعددة لكل منها أسماء مضيف في DNAME
    لهذا السبب أعتقد أنه من الأفضل القيام بمخزن مفاتيح واحد

ما رأيك؟

هكتار - الآن بعد أن تطرح الالتفاف: التفكير:
كنت في الواقع لعدة مفاتيح تخزين. ولكن ربما يكون التعقيد حقًا شيئًا يفضل التصويت لصالح شبكات SAN ومخزن رئيسي واحد. لكن هذه ليست سوى إجابتي التلقائية - سأفكر في هذا قليلاً

رأيت اليوم حلاً لطيفًا جدًا في "البرية":

نشر إدخال / etc / hosts على kafka-brokers للجهاز الداخلي بنفس اسم المضيف مثل الجهاز الخارجي.

إذا كان طلب kafka يأتي بعد ذلك من "الداخل" فإنه يستخدم إدخال etc / hosts
ويستهدف المستمع "الداخلي" ولكن باستخدام اسم المضيف الخارجي وبالتالي تعمل دقة الشهادة.
أتساءل عما إذا كان هذا يمكن أن يكون حلاً عامًا مشروعًا: التفكير:

Fobhep هذا شيء أستخدمه في الإنتاج منذ سنوات. يعد هذا إلزاميًا من الناحية العملية عندما تريد إعداد SASL في بيئة متعددة المنازل.

jrevillard شكرا على ردود الفعل.
ربما يجب أن نجعل كتيبات اللعبة هذه تفعل ذلك أيضًا

Fobhep لست متأكدًا من أننا يجب أن ننفذ هذا ، فنحن نحاول تقليل تعديل نظام التشغيل ما لم يكن له تأثير مباشر على كافكا على وجه التحديد (حدود الملفات المفتوحة على سبيل المثال). أعتقد أنه قد يكون من المنطقي توثيق هذا كحل محتمل للبيئات متعددة البيئات ، ولكن تعديل ملف المضيفين نيابة عن المستخدم يبدو محفوفًا بالمخاطر وليس له قيمة كافية. ومع ذلك ، يسعدني إثبات خطأ هذه النقطة الأخيرة.

JumaX نقطة عادلة - ربما يكون التوثيق فكرة جيدة.
سيذهب تنفيذه بعيدًا - أوافق.
Imho يمكننا إغلاق هذا بعد ذلك :)

Fobhep تم الآن تحديث hosts_example.yml لإظهار كيف يمكنك تعيين ips / hostnames في الإصدار 6.0. إغلاق هذا كما تم حلها.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

LGouellec picture LGouellec  ·  4تعليقات

luizm picture luizm  ·  18تعليقات

chuck-confluent picture chuck-confluent  ·  5تعليقات

OneCricketeer picture OneCricketeer  ·  7تعليقات

Fobhep picture Fobhep  ·  12تعليقات