This is part of the Charmed Kafka Tutorial. Please refer to this page for more information and the overview of the content.
Deploy Charmed Kafka (and Charmed ZooKeeper)
To deploy Charmed Kafka, all you need to do is run the following commands, which will automatically fetch Kafka and ZooKeeper charms from Charmhub and deploy them to your model. For example, to deploy a five ZooKeeper unit and three Kafka unit cluster, you can simply run:
$ juju deploy zookeeper -n 5
$ juju deploy kafka -n 3 --trust
After this, it is necessary to connect them:
$ juju relate kafka zookeeper
Juju will now fetch Charmed Kafka and Zookeeper and begin deploying it to the LXD cloud. This process can take several minutes depending on how provisioned (RAM, CPU, etc) your machine is. You can track the progress by running:
juju status --watch 1s
This command is useful for checking the status of Charmed ZooKeeper and Charmed Kafka and gathering information about the machines hosting the two applications. Some of the helpful information it displays includes IP addresses, ports, state, etc. The command updates the status of the cluster every second and as the application starts you can watch the status and messages of Charmed Kafka and ZooKeeper change.
Wait until the application is ready - when it is ready, juju status --watch 1s will show:
Model Controller Cloud/Region Version SLA Timestamp
tutorial overlord localhost/localhost 3.1.6 unsupported 08:20:12Z
App Version Status Scale Charm Channel Rev Exposed Message
kafka active 3 kafka 3/stable 147 no
zookeeper active 5 zookeeper 3/stable 114 no
Unit Workload Agent Machine Public address Ports Message
kafka/0 active idle 5 10.244.26.43 machine system settings are not optimal - see logs for info
kafka/1* active idle 6 10.244.26.6 machine system settings are not optimal - see logs for info
kafka/2 active idle 7 10.244.26.19 machine system settings are not optimal - see logs for info
zookeeper/0 active idle 0 10.244.26.251
zookeeper/1 active idle 1 10.244.26.129
zookeeper/2 active idle 2 10.244.26.121
zookeeper/3* active idle 3 10.244.26.28
zookeeper/4 active idle 4 10.244.26.174
Machine State Address Inst id Series AZ Message
0 started 10.244.26.251 juju-f1a2cd-0 jammy Running
1 started 10.244.26.129 juju-f1a2cd-1 jammy Running
2 started 10.244.26.121 juju-f1a2cd-2 jammy Running
3 started 10.244.26.28 juju-f1a2cd-3 jammy Running
4 started 10.244.26.174 juju-f1a2cd-4 jammy Running
5 started 10.244.26.43 juju-f1a2cd-5 jammy Running
6 started 10.244.26.6 juju-f1a2cd-6 jammy Running
7 started 10.244.26.19 juju-f1a2cd-7 jammy Running
To exit the screen with juju status --watch 1s, enter Ctrl+c.
Access Kafka cluster
To watch the process, juju status can be used. Once all the units show as active|idle the credentials to access a broker can be queried with:
juju run kafka/leader get-admin-credentials
The output of the previous command is something like this:
client-properties: |-
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required username="admin" password="e2sMfYLQg7sbbBMFTx1qlaZQKTUxr09x";
bootstrap.servers=10.244.26.19:9092,10.244.26.6:9092,10.244.26.43:9092
security.protocol=SASL_PLAINTEXT
sasl.mechanism=SCRAM-SHA-512
password: e2sMfYLQg7sbbBMFTx1qlaZQKTUxr09x
username: admin
Providing you the username and password of the Kafka cluster admin user.
IMPORTANT Note that when no other application is related to Kafka, the cluster is secured-by-default and external listeners (bound to port
9092) are disabled, thus preventing any external incoming connection.
Nevertheless, it is still possible to run a command from within the Kafka cluster using the internal listeners in place of the external ones.
The internal endpoints can be constructed by replacing the 19092 port in the bootstrap.servers returned in the output above, for example:
INTERNAL_LISTENERS=$(juju run kafka/leader get-admin-credentials | grep "bootstrap.servers" | cut -d "=" -f2 | sed -s "s/\:9092/:19092/g")
Once you have fetched the INTERNAL_LISTENERS, log in to one of the Kafka containers in one of the units:
juju ssh kafka/leader sudo -i
When the unit is started, the Charmed Kafka Operator installs the charmed-kafka Snap in the unit that provides a number of entrypoints (that corresponds to the bin commands in the Kafka distribution) for performing various administrative tasks, e.g charmed-kafka.config to update cluster configuration, charmed-kafka.topics for topic management, and many more!
Within the machine, the Charmed Kafka Operator also creates a client.properties file that already provides the relevant settings to connect to the cluster using the CLI
CLIENT_PROPERTIES=/var/snap/charmed-kafka/current/etc/kafka/client.properties
For example, in order to create a topic, you can run:
charmed-kafka.topics \
--create --topic test_topic \
--bootstrap-server $INTERNAL_LISTENERS \
--command-config $CLIENT_PROPERTIES
You can similarly then list the topic, using:
charmed-kafka.topics \
--list \
--bootstrap-server $INTERNAL_LISTENERS \
--command-config $CLIENT_PROPERTIES
making sure the topic was successfully created.
You can finally delete the topic, using:
charmed-kafka.topics \
--delete --topic test_topic \
--bootstrap-server $INTERNAL_LISTENERS \
--command-config $CLIENT_PROPERTIES
Other available Kafka bin commands can also be found with:
snap info charmed-kafka
What’s next?
However, although the commands above can run within the cluster, it is generally recommended during operations to enable external listeners and use these for running the admin commands from outside the cluster. To do so, as we will see in the next section, we will deploy a data-integrator charm and relate it to Kafka.