Подключитесь к Apache Kafka, работающему в Docker

1. Обзор

Apache Kafka — очень популярная платформа потоковой передачи событий, которая часто используется с Docker . Часто у людей возникают проблемы с установлением соединения с Kafka, особенно когда клиент работает не в той же сети Docker или на том же хосте. В первую очередь это связано с неправильной настройкой рекламируемых прослушивателей Kafka.

В этом руководстве мы узнаем, как настроить прослушиватели, чтобы клиенты могли подключаться к брокеру Kafka, работающему в Docker.

2. Настройте Кафку

Прежде чем мы попытаемся установить соединение, нам нужно запустить брокера Kafka с помощью Docker . Вот фрагмент нашего файла docker-compose.yaml :

version: '2'
services:
  zookeeper:
    container_name: zookeeper
    networks: 
      - kafka_network
    ...
  
  kafka:
    container_name: kafka
    networks: 
      - kafka_network
    ports:
      - 29092:29092
    environment:
      KAFKA_LISTENERS: EXTERNAL_SAME_HOST://:29092,INTERNAL://:9092
      KAFKA_ADVERTISED_LISTENERS: INTERNAL://kafka:9092,EXTERNAL_SAME_HOST://localhost:29092
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: INTERNAL:PLAINTEXT,EXTERNAL_SAME_HOST:PLAINTEXT
      KAFKA_INTER_BROKER_LISTENER_NAME: INTERNAL
     ... 

networks:
  kafka_network:
    name: kafka_docker_example_net

Здесь мы определили два обязательных сервиса — Kafka и Zookeeper. Мы также определили пользовательскую сеть — kafka_docker_example_net, которую будут использовать наши сервисы .

Позже мы более подробно рассмотрим свойства KAFKA_LISTENERS , KAFKA_ADVERTISED_LISTENERS и KAFKA_LISTENER_SECURITY_PROTOCOL_MAP .

С помощью вышеуказанного файла docker-compose.yaml мы запускаем службы:

docker-compose up -d
Creating network "kafka_docker_example_net" with the default driver
Creating zookeeper ... done
Creating kafka ... done

Кроме того, мы будем использовать утилиту производителя консоли Kafka в качестве образца клиента для проверки подключения к брокеру Kafka. Чтобы использовать скрипт Kafka-console-producer без Docker, нам нужно загрузить Kafka .

3. Слушатели

Слушатели, объявленные слушатели и протоколы слушателей играют значительную роль при подключении к брокерам Kafka.

Мы управляем слушателями с помощью свойства KAFKA_LISTENERS , где мы объявляем разделенный запятыми список URI, которые указывают сокеты, которые брокер должен прослушивать для входящих TCP-соединений.

Каждый URI состоит из имени протокола, за которым следует адрес интерфейса и порт:

EXTERNAL_SAME_HOST://0.0.0.0:29092,INTERNAL://0.0.0.0:9092

Здесь мы указали метаадрес 0.0.0.0 для привязки сокета ко всем интерфейсам. Кроме того, EXTERNAL_SAME_HOST и INTERNAL — это имена настраиваемых прослушивателей, которые нам нужно указать при определении прослушивателей в формате URI.

3.2. Начальная загрузка

Для начальных подключений клиентам Kafka нужен список загрузочных серверов, где мы указываем адреса брокеров. Список должен содержать хотя бы один действительный адрес случайного брокера в кластере.

Клиент будет использовать этот адрес для подключения к брокеру. Если подключение установлено успешно, посредник вернет метаданные о кластере, включая объявленные списки прослушивателей для всех посредников в кластере. Для последующих подключений клиенты будут использовать этот список для связи с брокерами.

3.3. Рекламируемые слушатели

Простого объявления слушателей недостаточно, потому что это всего лишь конфигурация сокета для брокера. Нам нужен способ сообщить клиентам (потребителям и производителям), как подключиться к Kafka.

Именно здесь на сцену выходят рекламируемые слушатели с помощью свойства KAFKA_ADVERTISED_LISTENERS . Он имеет такой же формат, как и свойство слушателя:

<протокол слушателя>://<объявленное имя хоста>:<объявленный порт>

Клиенты используют адреса, указанные в качестве объявленных слушателей после первоначального процесса начальной загрузки .

3.4. Карта протокола безопасности слушателя

Помимо прослушивателей и объявленных прослушивателей, нам нужно сообщить клиентам о протоколах безопасности, которые следует использовать при подключении к Kafka. В KAFKA_LISTENER_SECURITY_PROTOCOL_MAP мы сопоставляем имена наших пользовательских протоколов с допустимыми протоколами безопасности.

В конфигурации в предыдущем разделе мы объявили два пользовательских имени протокола — INTERNAL и EXTERNAL_SAME_HOST. Мы можем называть их как хотим, но нам нужно сопоставить их с действительными протоколами безопасности.

Один из указанных нами протоколов безопасности — PLAINTEXT , что означает, что клиентам не нужно проходить аутентификацию с помощью брокера Kafka. Кроме того, передаваемые данные не шифруются.

4. Подключение клиента из той же сети Docker

Давайте запустим производителя консоли Kafka из другого контейнера и попробуем отправить сообщения брокеру:

docker run -it --rm --network kafka_docker_example_net confluentinc/cp-kafka /bin/kafka-console-producer --bootstrap-server kafka:9092 --topic test_topic
>hello
>world

Здесь мы подключаем этот контейнер к существующей сети kafka_docker_example_net , чтобы свободно общаться с нашим брокером. Также указываем адрес брокера — kafka:9092 и название темы, которая будет создана автоматически.

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

5. Клиент подключается с того же хоста

Давайте подключимся к брокеру с хост-компьютера, когда клиент не контейнеризован. Для внешнего подключения мы объявили прослушиватель EXTERNAL_SAME_HOST , который мы можем использовать для установления соединения с хоста. Из объявленного свойства слушателя мы знаем, что должны использовать адрес localhost:29092 для доступа к брокеру Kafka.

Чтобы проверить подключение с того же хоста, мы будем использовать производителя консоли Kafka без Dockerized:

kafka-console-producer --bootstrap-server localhost:29092 --topic test_topic_2
>hi
>there

Поскольку нам удалось создать тему, это означает, что как первоначальная загрузка, так и последующее подключение (где рекламируемые слушатели используются клиентом) к брокеру прошли успешно.

Номер порта 29092, который мы ранее настроили в docker-compose.yaml , сделал брокера Kafka доступным за пределами Docker.

6. Подключение клиента с другого хоста

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

KAFKA_LISTENERS: EXTERNAL_SAME_HOST://:29092,EXTERNAL_DIFFERENT_HOST://:29093,INTERNAL://:9092
KAFKA_ADVERTISED_LISTENERS: INTERNAL://kafka:9092,EXTERNAL_SAME_HOST://localhost:29092,EXTERNAL_DIFFERENT_HOST://157.245.80.232:29093
KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: INTERNAL:PLAINTEXT,EXTERNAL_SAME_HOST:PLAINTEXT,EXTERNAL_DIFFERENT_HOST:PLAINTEXT

Мы создали новый прослушиватель с именем EXTERNAL_DIFFERENT_HOST с протоколом безопасности PLAINTEXT и портом 29093 . В KAFKA_ADVERTISED_LISTENERS мы также добавили IP-адрес облачной машины, на которой работает Kafka.

Мы должны помнить, что мы не можем использовать локальный хост , потому что мы подключаемся с другого компьютера (в данном случае с локальной рабочей станции). Кроме того, порт 29093 опубликован в разделе портов, чтобы он был доступен за пределами Docker.

Давайте попробуем создать несколько сообщений:

kafka-console-producer --bootstrap-server 157.245.80.232:29093 --topic test_topic_3
>hello
>REMOTE SERVER

Мы видим, что нам удалось подключиться к брокеру Kafka и успешно создавать сообщения.

7. Заключение

В этой статье мы узнали, как настроить прослушиватели, чтобы клиенты могли подключаться к брокеру Kafka, работающему в Docker. Мы рассмотрели различные сценарии, в которых клиент работал в той же сети Docker, на том же хосте, на другом хосте и т. д. Мы увидели, что конфигурации для прослушивателей, объявленных прослушивателей и карт протоколов безопасности определяют возможность подключения.