Kafka configuration du serveur - écouteurs contre advertised.listeners
Pour que Kafka s'exécute, vous devez définir certaines propriétés dans config/server.properties fichier. Il y a deux paramètres que je ne comprends pas.
Quelqu'un peut-il expliquer la différence entre les auditeurs et la propriété de advertised.listeners?
La documentation dit:
listeners: adresse sur laquelle le serveur de socket écoute.
et
advertised.listeners: nom d’hôte et port du courtier qui annoncera aux producteurs et aux consommateurs.
Quand dois-je utiliser quel réglage?
Etant donné que je ne peux pas encore commenter, je posterai ceci comme "réponse", en ajoutant à la réponse de M.Situations.
Dans le même document, il y a un lien vers ce texte de présentation indiquant quel auditeur est utilisé par un KAFKA client ( https://cwiki.Apache.org/confluence/display/KAFKA/KIP) -103% 3A + séparation + du + trafic interne + et + externe + ):
Comme indiqué précédemment, les clients ne voient jamais les noms des auditeurs et feront les requêtes de métadonnées exactement comme avant. La différence est que la liste des noeuds finaux qu'ils récupèrent est limitée au nom de l'écouteur du noeud final où ils ont fait la demande.
Ceci est important car cela dépend de l'URL que vous utilisez dans votre configuration bootstrap.servers. Ce sera l'URL * que le client récupérera s'il est mappé dans advertised.listeners (ne sait pas quel est le comportement si l'écouteur n'existe pas ).
Notez aussi ceci:
L'exception concerne les consommateurs ZooKeeper. Ces consommateurs récupèrent les informations d'enregistrement du courtier directement à partir de ZooKeeper et choisissent le premier auditeur avec PLAINTEXT comme protocole de sécurité (le seul protocole de sécurité pris en charge).
Comme exemple de configuration de courtier (pour tous les courtiers du cluster):
advertised.listeners = EXTERNAL: //XXXXX.compute-1.amazonaws.com: 9990, INTERNE: //ip-XXXXX.ec2.internal: 9993
inter.broker.listener.name = INTERNAL
listener.security.protocol.map = EXTERNAL: SSL, INTERNAL: PLAINTEXT
Si le client utilise XXXXX.compute-1.amazonaws.com:9990 pour se connecter, la récupération des métadonnées ira à ce courtier. Toutefois, l'URL renvoyée à utiliser avec le coordinateur de groupe ou le chef de groupe pourrait être 123.compute-1.amazonaws.com:9990* (une autre machine!). Cela signifie que la correspondance est faite sur le nom de l'écouteur tel qu'il est annoncé par KIP-103, indépendamment de l'URL réelle (nœud).
Etant donné que la mappe de protocole pour EXTERNAL est SSL, cela vous obligerait à utiliser un fichier de clés SSL pour vous connecter.
Par contre, si vous êtes dans AWS, vous pouvez émettre ip-XXXXX.ec2.internal: 9993 et la connexion correspondante sera en texte clair conformément à la mappe de protocole.
Cela est particulièrement nécessaire dans l'IaaS où, dans mon cas, les courtiers et les consommateurs résident sur AWS, alors que mon producteur réside sur un site client, nécessitant ainsi différents protocoles de sécurité et différents auditeurs.
ÉDITER: L'ajout de règles entrantes est beaucoup plus facile maintenant que vous avez différents ports pour différents clients (courtiers, producteurs, consommateurs).
listeners est ce que le courtier utilisera pour créer des sockets serveur.
advertised.listeners est ce que les clients utiliseront pour se connecter aux courtiers.
Les deux paramètres peuvent être différents si vous avez une configuration réseau "complexe" (avec des éléments tels que des sous-réseaux publics et privés et un routage entre les deux).
A partir de ce lien: https://cwiki.Apache.org/confluence/display/KAFKA/KIP-103%3A+Separation+of+Internal+and+External+traffic
Au cours du cycle de publication de la version 0.9.0.0, la prise en charge de plusieurs écouteurs par courtier a été introduite. Chaque auditeur est associé à un protocole de sécurité, ip/host et port. Lorsqu'il est combiné au mécanisme des écouteurs annoncés, il y a beaucoup de flexibilité avec une limitation: au plus un auditeur par protocole de sécurité dans chacune des deux configurations (écouteurs et annonceurs.écrivés).
Dans certains environnements, il peut être utile de différencier les clients externes, les clients internes et le trafic de réplication indépendamment du protocole de sécurité pour des raisons de coût, de performances et de sécurité. Quelques exemples illustrant ceci:
- Le trafic de réplication est attribué à une interface réseau distincte de sorte qu'il n'interfère pas avec le trafic client.
- Le trafic externe passe par un proxy/équilibreur de charge (sécurité, flexibilité) tandis que le trafic interne frappe directement les courtiers (performances, coût).
- Différents paramètres de sécurité pour le trafic externe par rapport au trafic interne même si le protocole de sécurité est identique (par exemple, un ensemble différent de mécanismes SASL activés, de serveurs d'authentification, de différents magasins de clés, etc.)
En tant que tels, nous proposons que les courtiers Kafka) soient en mesure de définir plusieurs écouteurs pour le même protocole de sécurité pour la liaison (c'est-à-dire les écouteurs) et le partage (c'est-à-dire advertised.listeners), de sorte que les fonctions de réplication interne, externe et le trafic peut être séparé si nécessaire.
Alors,
listeners - Liste d'URI sur lesquels nous allons écouter et leurs protocoles, séparés par des virgules. Spécifiez le nom d'hôte sous la forme 0.0.0.0 pour se connecter à toutes les interfaces. Laissez le nom d'hôte vide pour lier l'interface par défaut. Exemples de listes d'auditeurs légaux:
PLAINTEXT://myhost:9092,TRACE://:9091PLAINTEXT://0.0.0.0:9092, TRACE://localhost:9093
advertised.listeners - Les auditeurs doivent publier sur ZooKeeper pour que les clients puissent les utiliser, s'ils sont différents des auditeurs ci-dessus. Dans les environnements IaaS, il peut être nécessaire que cette interface diffère de l'interface à laquelle le courtier est lié. Si ce n'est pas défini, la valeur pour listeners sera utilisée.