waterdrop 2.6.6 → 2.6.8

data/README.md

@@ -4,80 +4,37 @@
 [![Gem Version](https://badge.fury.io/rb/waterdrop.svg)](http://badge.fury.io/rb/waterdrop)
 [![Join the chat at https://slack.karafka.io](https://raw.githubusercontent.com/karafka/misc/master/slack.svg)](https://slack.karafka.io)
 
-A gem to send messages to Kafka easily with an extra validation layer. It is a part of the [Karafka](https://github.com/karafka/karafka) ecosystem.
+WaterDrop is a standalone gem that sends messages to Kafka easily with an extra validation layer. It is a part of the [Karafka](https://github.com/karafka/karafka) ecosystem.
 
 It:
 
  - Is thread-safe
  - Supports sync producing
  - Supports async producing
+ - Supports transactions
  - Supports buffering
  - Supports producing messages to multiple clusters
  - Supports multiple delivery policies
  - Works with Kafka `1.0+` and Ruby `2.7+`
+ - Works with and without Karafka
 
-## Table of contents
+## Documentation
 
-- [Installation](#installation)
-- [Setup](#setup)
-  * [WaterDrop configuration options](#waterdrop-configuration-options)
-  * [Kafka configuration options](#kafka-configuration-options)
-- [Usage](#usage)
-  * [Basic usage](#basic-usage)
-  * [Using WaterDrop across the application and with Ruby on Rails](#using-waterdrop-across-the-application-and-with-ruby-on-rails)
-  * [Using WaterDrop with a connection-pool](#using-waterdrop-with-a-connection-pool)
-  * [Buffering](#buffering)
-      + [Using WaterDrop to buffer messages based on the application logic](#using-waterdrop-to-buffer-messages-based-on-the-application-logic)
-      + [Using WaterDrop with rdkafka buffers to achieve periodic auto-flushing](#using-waterdrop-with-rdkafka-buffers-to-achieve-periodic-auto-flushing)
-  * [Idempotence](#idempotence)
-  * [Compression](#compression)
-- [Instrumentation](#instrumentation)
-  * [Usage statistics](#usage-statistics)
-  * [Error notifications](#error-notifications)
-  * [Acknowledgment notifications](#acknowledgment-notifications)
-  * [Datadog and StatsD integration](#datadog-and-statsd-integration)
-  * [Forking and potential memory problems](#forking-and-potential-memory-problems)
-- [Middleware](#middleware)
-- [Note on contributions](#note-on-contributions)
+Karafka ecosystem components documentation, including WaterDrop, can be found [here](https://karafka.io/docs/#waterdrop).
 
-## Installation
+## Getting Started
 
-**Note**: If you want to both produce and consume messages, please use [Karafka](https://github.com/karafka/karafka/). It integrates WaterDrop automatically.
+If you want to both produce and consume messages, please use [Karafka](https://github.com/karafka/karafka/). It integrates WaterDrop automatically.
 
-Add this to your Gemfile:
+To get started with WaterDrop:
 
-```ruby
-gem 'waterdrop'
-```
-
-and run
-
-```
-bundle install
-```
-
-## Setup
-
-WaterDrop is a complex tool that contains multiple configuration options. To keep everything organized, all the configuration options were divided into two groups:
+1. Add it to your Gemfile:
 
-- WaterDrop options - options directly related to WaterDrop and its components
-- Kafka driver options - options related to `rdkafka`
-
-To apply all those configuration options, you need to create a producer instance and use the ```#setup``` method:
-
-```ruby
-producer = WaterDrop::Producer.new
-
-producer.setup do |config|
-  config.deliver = true
-  config.kafka = {
-    'bootstrap.servers': 'localhost:9092',
-    'request.required.acks': 1
-  }
-end
+```bash
+bundle add waterdrop
 ```
 
-or you can do the same while initializing the producer:
+2. Create and configure a producer:
 
 ```ruby
 producer = WaterDrop::Producer.new do |config|
@@ -89,46 +46,17 @@ producer = WaterDrop::Producer.new do |config|
 end
 ```
 
-### WaterDrop configuration options
-
-Some of the options are:
-
-| Option                       | Description                                                                |
-|------------------------------|----------------------------------------------------------------------------|
-| `id`                         | id of the producer for instrumentation and logging                         |
-| `logger`                     | Logger that we want to use                                                 |
-| `deliver`                    | Should we send messages to Kafka or just fake the delivery                 |
-| `max_wait_timeout`           | Waits that long for the delivery report or raises an error                 |
-| `wait_timeout`               | Waits that long before re-check of delivery report availability            |
-| `wait_on_queue_full`         | Should be wait on queue full or raise an error when that happens           |
-| `wait_backoff_on_queue_full` | Waits that long before retry when queue is full                            |
-| `wait_timeout_on_queue_full` | If back-offs and attempts that that much time, error won't be retried more |
-
-Full list of the root configuration options is available [here](https://github.com/karafka/waterdrop/blob/master/lib/waterdrop/config.rb#L25).
+3. Use it as follows:
 
-### Kafka configuration options
-
-You can create producers with different `kafka` settings. Documentation of the available configuration options is available on https://github.com/edenhill/librdkafka/blob/master/CONFIGURATION.md.
-
-## Usage
-
-### Basic usage
-
-To send Kafka messages, just create a producer and use it:
 
 ```ruby
-producer = WaterDrop::Producer.new
-
-producer.setup do |config|
-  config.kafka = { 'bootstrap.servers': 'localhost:9092' }
-end
-
+# sync producing
 producer.produce_sync(topic: 'my-topic', payload: 'my message')
 
 # or for async
 producer.produce_async(topic: 'my-topic', payload: 'my message')
 
-# or in batches
+# or in sync batches
 producer.produce_many_sync(
   [
     { topic: 'my-topic', payload: 'my message'},
@@ -136,7 +64,7 @@ producer.produce_many_sync(
   ]
 )
 
-# both sync and async
+# and async batches
 producer.produce_many_async(
   [
     { topic: 'my-topic', payload: 'my message'},
@@ -144,418 +72,9 @@ producer.produce_many_async(
   ]
 )
 
-# Don't forget to close the producer once you're done to flush the internal buffers, etc
-producer.close
-```
-
-Each message that you want to publish, will have its value checked.
-
-Here are all the things you can provide in the message hash:
-
-| Option          | Required | Value type    | Description                                              |
-|-----------------|----------|---------------|----------------------------------------------------------|
-| `topic`         | true     | String        | The Kafka topic that should be written to                |
-| `payload`       | true     | String        | Data you want to send to Kafka                           |
-| `key`           | false    | String        | The key that should be set in the Kafka message          |
-| `partition`     | false    | Integer       | A specific partition number that should be written to    |
-| `partition_key` | false    | String        | Key to indicate the destination partition of the message |
-| `timestamp`     | false    | Time, Integer | The timestamp that should be set on the message          |
-| `headers`       | false    | Hash          | Headers for the message                                  |
-
-Keep in mind, that message you want to send should be either binary or stringified (to_s, to_json, etc).
-
-### Using WaterDrop across the application and with Ruby on Rails
-
-If you plan to both produce and consume messages using Kafka, you should install and use [Karafka](https://github.com/karafka/karafka). It integrates automatically with Ruby on Rails applications and auto-configures WaterDrop producer to make it accessible via `Karafka#producer` method:
-
-```ruby
-event = Events.last
-Karafka.producer.produce_async(topic: 'events', payload: event.to_json)
-```
-
-If you want to only produce messages from within your application without consuming with Karafka, since WaterDrop is thread-safe you can create a single instance in an initializer like so:
-
-```ruby
-KAFKA_PRODUCER = WaterDrop::Producer.new
-
-KAFKA_PRODUCER.setup do |config|
-  config.kafka = { 'bootstrap.servers': 'localhost:9092' }
-end
-
-# And just dispatch messages
-KAFKA_PRODUCER.produce_sync(topic: 'my-topic', payload: 'my message')
-```
-
-### Using WaterDrop with a connection-pool
-
-While WaterDrop is thread-safe, there is no problem in using it with a connection pool inside high-intensity applications. The only thing worth keeping in mind, is that WaterDrop instances should be shutdown before the application is closed.
-
-```ruby
-KAFKA_PRODUCERS_CP = ConnectionPool.new do
-  WaterDrop::Producer.new do |config|
-    config.kafka = { 'bootstrap.servers': 'localhost:9092' }
-  end
-end
-
-KAFKA_PRODUCERS_CP.with do |producer|
+# transactions
+producer.transaction do
+  producer.produce_async(topic: 'my-topic', payload: 'my message')
   producer.produce_async(topic: 'my-topic', payload: 'my message')
 end
-
-KAFKA_PRODUCERS_CP.shutdown { |producer| producer.close }
-```
-
-### Buffering
-
-WaterDrop producers support buffering messages in their internal buffers and on the `rdkafka` level via `queue.buffering.*` set of settings.
-
-This means that depending on your use case, you can achieve both granular buffering and flushing control when needed with context awareness and periodic and size-based flushing functionalities.
-
-### Idempotence
-
-When idempotence is enabled, the producer will ensure that messages are successfully produced exactly once and in the original production order.
-
-To enable idempotence, you need to set the `enable.idempotence` kafka scope setting to `true`:
-
-```ruby
-WaterDrop::Producer.new do |config|
-  config.deliver = true
-  config.kafka = {
-    'bootstrap.servers': 'localhost:9092',
-    'enable.idempotence': true
-  }
-end
-```
-
-The following Kafka configuration properties are adjusted automatically (if not modified by the user) when idempotence is enabled:
-
-- `max.in.flight.requests.per.connection` set to `5`
-- `retries` set to `2147483647`
-- `acks` set to `all`
-
-The idempotent producer ensures that messages are always delivered in the correct order and without duplicates. In other words, when an idempotent producer sends a message, the messaging system ensures that the message is only delivered once to the message broker and subsequently to the consumers, even if the producer tries to send the message multiple times.
-
-### Compression
-
-WaterDrop supports following compression types:
-
-- `gzip`
-- `zstd`
-- `lz4`
-- `snappy`
-
-To use compression, set `kafka` scope `compression.codec` setting. You can also optionally indicate the `compression.level`:
-
-```ruby
-producer = WaterDrop::Producer.new
-
-producer.setup do |config|
-  config.kafka = {
-    'bootstrap.servers': 'localhost:9092',
-    'compression.codec': 'gzip',
-    'compression.level': 6
-  }
-end
-```
-
-**Note**: In order to use `zstd`, you need to install `libzstd-dev`:
-
-```bash
-apt-get install -y libzstd-dev
-```
-
-#### Using WaterDrop to buffer messages based on the application logic
-
-```ruby
-producer = WaterDrop::Producer.new
-
-producer.setup do |config|
-  config.kafka = { 'bootstrap.servers': 'localhost:9092' }
-end
-
-# Simulating some events states of a transaction - notice, that the messages will be flushed to
-# kafka only upon arrival of the `finished` state.
-%w[
-  started
-  processed
-  finished
-].each do |state|
-  producer.buffer(topic: 'events', payload: state)
-
-  puts "The messages buffer size #{producer.messages.size}"
-  producer.flush_sync if state == 'finished'
-  puts "The messages buffer size #{producer.messages.size}"
-end
-
-producer.close
-```
-
-#### Using WaterDrop with rdkafka buffers to achieve periodic auto-flushing
-
-```ruby
-producer = WaterDrop::Producer.new
-
-producer.setup do |config|
-  config.kafka = {
-    'bootstrap.servers': 'localhost:9092',
-    # Accumulate messages for at most 10 seconds
-    'queue.buffering.max.ms': 10_000
-  }
-end
-
-# WaterDrop will flush messages minimum once every 10 seconds
-30.times do |i|
-  producer.produce_async(topic: 'events', payload: i.to_s)
-  sleep(1)
-end
-
-producer.close
-```
-
-## Instrumentation
-
-Each of the producers after the `#setup` is done, has a custom monitor to which you can subscribe.
-
-```ruby
-producer = WaterDrop::Producer.new
-
-producer.setup do |config|
-  config.kafka = { 'bootstrap.servers': 'localhost:9092' }
-end
-
-producer.monitor.subscribe('message.produced_async') do |event|
-  puts "A message was produced to '#{event[:message][:topic]}' topic!"
-end
-
-producer.produce_async(topic: 'events', payload: 'data')
-
-producer.close
-```
-
-See the `WaterDrop::Instrumentation::Notifications::EVENTS` for the list of all the supported events.
-
-### Karafka Web-UI
-
-Karafka [Web UI](https://karafka.io/docs/Web-UI-Getting-Started/) is a user interface for the Karafka framework. The Web UI provides a convenient way for monitor all producers related errors out of the box.
-
-![Example producer errors in Karafka Web-UI](https://raw.githubusercontent.com/karafka/misc/master/printscreens/web-ui/errors-producer.png)
-
-### Logger Listener
-
-WaterDrop comes equipped with a `LoggerListener`, a useful feature designed to facilitate the reporting of WaterDrop's operational details directly into the assigned logger. The `LoggerListener` provides a convenient way of tracking the events and operations that occur during the usage of WaterDrop, enhancing transparency and making debugging and issue tracking easier.
-
-However, it's important to note that this Logger Listener is not subscribed by default. This means that WaterDrop does not automatically send operation data to your logger out of the box. This design choice has been made to give users greater flexibility and control over their logging configuration.
-
-To use this functionality, you need to manually subscribe the `LoggerListener` to WaterDrop instrumentation. Below, you will find an example demonstrating how to perform this subscription.
-
-```ruby
-LOGGER = Logger.new($stdout)
-
-producer = WaterDrop::Producer.new do |config|
-  config.kafka = { 'bootstrap.servers': 'localhost:9092' }
-  config.logger = LOGGER
-end
-
-producer.monitor.subscribe(
-  WaterDrop::Instrumentation::LoggerListener.new(
-    # You can use a different logger than the one assigned to WaterDrop if you want
-    producer.config.logger,
-    # If this is set to false, the produced messages details will not be sent to logs
-    # You may set it to false if you find the level of reporting in the debug too extensive
-    log_messages: true
-  )
-)
-
-producer.produce_sync(topic: 'my.topic', payload: 'my.message')
-```
-
-### Usage statistics
-
-WaterDrop is configured to emit internal `librdkafka` metrics every five seconds. You can change this by setting the `kafka` `statistics.interval.ms` configuration property to a value greater of equal `0`. Emitted statistics are available after subscribing to the `statistics.emitted` publisher event. If set to `0`, metrics will not be published.
-
-The statistics include all of the metrics from `librdkafka` (complete list [here](https://github.com/edenhill/librdkafka/blob/master/STATISTICS.md)) as well as the diff of those against the previously emitted values.
-
-For several attributes like `txmsgs`, `librdkafka` publishes only the totals. In order to make it easier to track the progress (for example number of messages sent between statistics emitted events), WaterDrop diffs all the numeric values against previously available numbers. All of those metrics are available under the same key as the metric but with additional `_d` postfix:
-
-
-```ruby
-producer = WaterDrop::Producer.new do |config|
-  config.kafka = {
-    'bootstrap.servers': 'localhost:9092',
-    'statistics.interval.ms': 2_000 # emit statistics every 2 seconds
-  }
-end
-
-producer.monitor.subscribe('statistics.emitted') do |event|
-  sum = event[:statistics]['txmsgs']
-  diff = event[:statistics]['txmsgs_d']
-
-  p "Sent messages: #{sum}"
-  p "Messages sent from last statistics report: #{diff}"
-end
-
-sleep(2)
-
-# Sent messages: 0
-# Messages sent from last statistics report: 0
-
-20.times { producer.produce_async(topic: 'events', payload: 'data') }
-
-# Sent messages: 20
-# Messages sent from last statistics report: 20
-
-sleep(2)
-
-20.times { producer.produce_async(topic: 'events', payload: 'data') }
-
-# Sent messages: 40
-# Messages sent from last statistics report: 20
-
-sleep(2)
-
-# Sent messages: 40
-# Messages sent from last statistics report: 0
-
-producer.close
-```
-
-Note: The metrics returned may not be completely consistent between brokers, toppars and totals, due to the internal asynchronous nature of librdkafka. E.g., the top level tx total may be less than the sum of the broker tx values which it represents.
-
-### Error notifications
-
-WaterDrop allows you to listen to all errors that occur while producing messages and in its internal background threads. Things like reconnecting to Kafka upon network errors and others unrelated to publishing messages are all available under `error.occurred` notification key. You can subscribe to this event to ensure your setup is healthy and without any problems that would otherwise go unnoticed as long as messages are delivered.
-
-```ruby
-producer = WaterDrop::Producer.new do |config|
-  # Note invalid connection port...
-  config.kafka = { 'bootstrap.servers': 'localhost:9090' }
-end
-
-producer.monitor.subscribe('error.occurred') do |event|
-  error = event[:error]
-
-  p "WaterDrop error occurred: #{error}"
-end
-
-# Run this code without Kafka cluster
-loop do
-  producer.produce_async(topic: 'events', payload: 'data')
-
-  sleep(1)
-end
-
-# After you stop your Kafka cluster, you will see a lot of those:
-#
-# WaterDrop error occurred: Local: Broker transport failure (transport)
-#
-# WaterDrop error occurred: Local: Broker transport failure (transport)
-```
-
-**Note:** `error.occurred` will also include any errors originating from `librdkafka` for synchronous operations, including those that are raised back to the end user.
-
-### Acknowledgment notifications
-
-WaterDrop allows you to listen to Kafka messages' acknowledgment events. This will enable you to monitor deliveries of messages from WaterDrop even when using asynchronous dispatch methods.
-
-That way, you can make sure, that dispatched messages are acknowledged by Kafka.
-
-```ruby
-producer = WaterDrop::Producer.new do |config|
-  config.kafka = { 'bootstrap.servers': 'localhost:9092' }
-end
-
-producer.monitor.subscribe('message.acknowledged') do |event|
-  producer_id = event[:producer_id]
-  offset = event[:offset]
-
-  p "WaterDrop [#{producer_id}] delivered message with offset: #{offset}"
-end
-
-loop do
-  producer.produce_async(topic: 'events', payload: 'data')
-
-  sleep(1)
-end
-
-# WaterDrop [dd8236fff672] delivered message with offset: 32
-# WaterDrop [dd8236fff672] delivered message with offset: 33
-# WaterDrop [dd8236fff672] delivered message with offset: 34
-```
-
-### Datadog and StatsD integration
-
-WaterDrop comes with (optional) full Datadog and StatsD integration that you can use. To use it:
-
-```ruby
-# require datadog/statsd and the listener as it is not loaded by default
-require 'datadog/statsd'
-require 'waterdrop/instrumentation/vendors/datadog/metrics_listener'
-
-# initialize your producer with statistics.interval.ms enabled so the metrics are published
-producer = WaterDrop::Producer.new do |config|
-  config.deliver = true
-  config.kafka = {
-    'bootstrap.servers': 'localhost:9092',
-    'statistics.interval.ms': 1_000
-  }
-end
-
-# initialize the listener with statsd client
-listener = ::WaterDrop::Instrumentation::Vendors::Datadog::MetricsListener.new do |config|
-  config.client = Datadog::Statsd.new('localhost', 8125)
-  # Publish host as a tag alongside the rest of tags
-  config.default_tags = ["host:#{Socket.gethostname}"]
-end
-
-# Subscribe with your listener to your producer and you should be ready to go!
-producer.monitor.subscribe(listener)
-```
-
-You can also find [here](https://github.com/karafka/waterdrop/blob/master/lib/waterdrop/instrumentation/vendors/datadog/dashboard.json) a ready to import DataDog dashboard configuration file that you can use to monitor all of your producers.
-
-![Example WaterDrop DD dashboard](https://raw.githubusercontent.com/karafka/misc/master/printscreens/waterdrop_dd_dashboard_example.png)
-
-### Forking and potential memory problems
-
-If you work with forked processes, make sure you **don't** use the producer before the fork. You can easily configure the producer and then fork and use it.
-
-To tackle this [obstacle](https://github.com/appsignal/rdkafka-ruby/issues/15) related to rdkafka, WaterDrop adds finalizer to each of the producers to close the rdkafka client before the Ruby process is shutdown. Due to the [nature of the finalizers](https://www.mikeperham.com/2010/02/24/the-trouble-with-ruby-finalizers/), this implementation prevents producers from being GCed (except upon VM shutdown) and can cause memory leaks if you don't use persistent/long-lived producers in a long-running process or if you don't use the `#close` method of a producer when it is no longer needed. Creating a producer instance for each message is anyhow a rather bad idea, so we recommend not to.
-
-## Middleware
-
-WaterDrop supports injecting middleware similar to Rack.
-
-Middleware can be used to provide extra functionalities like auto-serialization of data or any other modifications of messages before their validation and dispatch.
-
-Each middleware accepts the message hash as input and expects a message hash as a result.
-
-There are two methods to register middlewares:
-
-- `#prepend` - registers middleware as the first in the order of execution
-- `#append` - registers middleware as the last in the order of execution
-
-Below you can find an example middleware that converts the incoming payload into a JSON string by running `#to_json` automatically:
-
-```ruby
-class AutoMapper
-  def call(message)
-    message[:payload] = message[:payload].to_json
-    message
-  end
-end
-
-# Register middleware
-producer.middleware.append(AutoMapper.new)
-
-# Dispatch without manual casting
-producer.produce_async(topic: 'users', payload: user)
 ```
-
-**Note**: It is up to the end user to decide whether to modify the provided message or deep copy it and update the newly created one.
-
-## Note on contributions
-
-First, thank you for considering contributing to the Karafka ecosystem! It's people like you that make the open source community such a great community!
-
-Each pull request must pass all the RSpec specs, integration tests and meet our quality requirements.
-
-Fork it, update and wait for the Github Actions results.

data/certs/cert_chain.pem

@@ -1,26 +1,26 @@
 -----BEGIN CERTIFICATE-----
 MIIEcDCCAtigAwIBAgIBATANBgkqhkiG9w0BAQsFADA/MRAwDgYDVQQDDAdjb250
 YWN0MRcwFQYKCZImiZPyLGQBGRYHa2FyYWZrYTESMBAGCgmSJomT8ixkARkWAmlv
-MB4XDTIyMDgxOTE3MjEzN1oXDTIzMDgxOTE3MjEzN1owPzEQMA4GA1UEAwwHY29u
+MB4XDTIzMDgyMTA3MjU1NFoXDTI0MDgyMDA3MjU1NFowPzEQMA4GA1UEAwwHY29u
 dGFjdDEXMBUGCgmSJomT8ixkARkWB2thcmFma2ExEjAQBgoJkiaJk/IsZAEZFgJp
-bzCCAaIwDQYJKoZIhvcNAQEBBQADggGPADCCAYoCggGBAODzeO3L6lxdATzMHKNW
-jFA/GGunoPuylO/BMzy8RiQHh7VIvysAKs0tHhTx3g2D0STDpF+hcQcPELFikiT2
-F+1wOHj/SsrK7VKqfA8+gq04hKc5sQoX2Egf9k3V0YJ3eZ6R/koHkQ8A0TVt0w6F
-ZQckoV4MqnEAx0g/FZN3mnHTlJ3VFLSBqJEIe+S6FZMl92mSv+hTrlUG8VaYxSfN
-lTCvnKk284F6QZq5XIENLRmcDd/3aPBLnLwNnyMyhB+6gK8cUO+CFlDO5tjo/aBA
-rUnl++wGG0JooF1ed0v+evOn9KoMBG6rHewcf79qJbVOscbD8qSAmo+sCXtcFryr
-KRMTB8gNbowJkFRJDEe8tfRy11u1fYzFg/qNO82FJd62rKAw2wN0C29yCeQOPRb1
-Cw9Y4ZwK9VFNEcV9L+3pHTHn2XfuZHtDaG198VweiF6raFO4yiEYccodH/USP0L5
-cbcCFtmu/4HDSxL1ByQXO84A0ybJuk3/+aPUSXe9C9U8fwIDAQABo3cwdTAJBgNV
-HRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHQ4EFgQUSlcEakb7gfn/5E2WY6z73BF/
-iZkwHQYDVR0RBBYwFIESY29udGFjdEBrYXJhZmthLmlvMB0GA1UdEgQWMBSBEmNv
-bnRhY3RAa2FyYWZrYS5pbzANBgkqhkiG9w0BAQsFAAOCAYEA1aS+E7RXJ1w9g9mJ
-G0NzFxe64OEuENosNlvYQCbRKGCXAU1qqelYkBQHseRgRKxLICrnypRo9IEobyHa
-vDnJ4r7Tsb34dleqQW2zY/obG+cia3Ym2JsegXWF7dDOzCXJ4FN8MFoT2jHlqLLw
-yrap0YO5zx0GSQ0Dwy8h2n2v2vanMEeCx7iNm3ERgR5WuN5sjzWoz2A/JLEEcK0C
-EnAGKCWAd1fuG8IemDjT1edsd5FyYR4bIX0m+99oDuFZyPiiIbalmyYiSBBp59Yb
-Q0P8zeBi4OfwCZNcxqz0KONmw9JLNv6DgyEAH5xe/4JzhMEgvIRiPj0pHfA7oqQF
-KUNqvD1KlxbEC+bZfE5IZhnqYLdld/Ksqd22FI1RBhiS1Ejfsj99LVIm9cBuZEY2
-Qf04B9ceLUaC4fPVEz10FyobjaFoY4i32xRto3XnrzeAgfEe4swLq8bQsR3w/EF3
-MGU0FeSV2Yj7Xc2x/7BzLK8xQn5l7Yy75iPF+KP3vVmDHnNl
+bzCCAaIwDQYJKoZIhvcNAQEBBQADggGPADCCAYoCggGBAOuZpyQKEwsTG9plLat7
+8bUaNuNBEnouTsNMr6X+XTgvyrAxTuocdsyP1sNCjdS1B8RiiDH1/Nt9qpvlBWon
+sdJ1SYhaWNVfqiYStTDnCx3PRMmHRdD4KqUWKpN6VpZ1O/Zu+9Mw0COmvXgZuuO9
+wMSJkXRo6dTCfMedLAIxjMeBIxtoLR2e6Jm6MR8+8WYYVWrO9kSOOt5eKQLBY7aK
+b/Dc40EcJKPg3Z30Pia1M9ZyRlb6SOj6SKpHRqc7vbVQxjEw6Jjal1lZ49m3YZMd
+ArMAs9lQZNdSw5/UX6HWWURLowg6k10RnhTUtYyzO9BFev0JFJftHnmuk8vtb+SD
+5VPmjFXg2VOcw0B7FtG75Vackk8QKfgVe3nSPhVpew2CSPlbJzH80wChbr19+e3+
+YGr1tOiaJrL6c+PNmb0F31NXMKpj/r+n15HwlTMRxQrzFcgjBlxf2XFGnPQXHhBm
+kp1OFnEq4GG9sON4glRldkwzi/f/fGcZmo5fm3d+0ZdNgwIDAQABo3cwdTAJBgNV
+HRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHQ4EFgQUPVH5+dLA80A1kJ2Uz5iGwfOa
+1+swHQYDVR0RBBYwFIESY29udGFjdEBrYXJhZmthLmlvMB0GA1UdEgQWMBSBEmNv
+bnRhY3RAa2FyYWZrYS5pbzANBgkqhkiG9w0BAQsFAAOCAYEAnpa0jcN7JzREHMTQ
+bfZ+xcvlrzuROMY6A3zIZmQgbnoZZNuX4cMRrT1p1HuwXpxdpHPw7dDjYqWw3+1h
+3mXLeMuk7amjQpYoSWU/OIZMhIsARra22UN8qkkUlUj3AwTaChVKN/bPJOM2DzfU
+kz9vUgLeYYFfQbZqeI6SsM7ltilRV4W8D9yNUQQvOxCFxtLOetJ00fC/E7zMUzbK
+IBwYFQYsbI6XQzgAIPW6nGSYKgRhkfpmquXSNKZRIQ4V6bFrufa+DzD0bt2ZA3ah
+fMmJguyb5L2Gf1zpDXzFSPMG7YQFLzwYz1zZZvOU7/UCpQsHpID/YxqDp4+Dgb+Y
+qma0whX8UG/gXFV2pYWpYOfpatvahwi+A1TwPQsuZwkkhi1OyF1At3RY+hjSXyav
+AnG1dJU+yL2BK7vaVytLTstJME5mepSZ46qqIJXMuWob/YPDmVaBF39TDSG9e34s
+msG3BiCqgOgHAnL23+CN3Rt8MsuRfEtoTKpJVcCfoEoNHOkc
 -----END CERTIFICATE-----

data/docker-compose.yml

@@ -1,18 +1,25 @@
 version: '2'
+
 services:
-  zookeeper:
-    image: wurstmeister/zookeeper
-    ports:
-      - "2181:2181"
   kafka:
-    image: wurstmeister/kafka:2.12-2.5.0
+    container_name: kafka
+    image: confluentinc/cp-kafka:7.5.1
+
     ports:
-      - "9092:9092"
+      - 9092:9092
+
     environment:
-      KAFKA_ADVERTISED_HOST_NAME: localhost
-      KAFKA_ADVERTISED_PORT: 9092
-      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
+      CLUSTER_ID: kafka-docker-cluster-1
+      KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT
+      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
+      KAFKA_PROCESS_ROLES: broker,controller
+      KAFKA_CONTROLLER_LISTENER_NAMES: CONTROLLER
+      KAFKA_LISTENERS: PLAINTEXT://:9092,CONTROLLER://:9093
+      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT
+      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://127.0.0.1:9092
+      KAFKA_BROKER_ID: 1
+      KAFKA_CONTROLLER_QUORUM_VOTERS: 1@127.0.0.1:9093
+      ALLOW_PLAINTEXT_LISTENER: 'yes'
       KAFKA_AUTO_CREATE_TOPICS_ENABLE: 'true'
-      KAFKA_CREATE_TOPICS: 'example_topic:1:1'
-    volumes:
-      - /var/run/docker.sock:/var/run/docker.sock
+      KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1
+      KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1