Configure ksqlDB with Docker
You can deploy ksqlDB by using Docker containers. Confluent maintains images at Docker Hub for ksqlDB Server and the ksqlDB command-line interface (CLI).
Use the following settings to start containers that run ksqlDB in various configurations.
Assign configuration settings in the Docker run command¶
You can pass configuration settings dynamically into containers by using
environment variables. When you start a container, set up the
configuration with the -e
or --env
flags in the docker run
command.
For a complete list of ksqlDB parameters, see ksqlDB Configuration Parameter Reference.
In most cases, to assign a ksqlDB configuration parameter in a container,
you prepend the parameter name with KSQL_
and substitute the
underscore character for periods. For example, to assign the
ksql.queries.file
setting in your docker run
command, specify:
1 |
|
Also, you can set configuration options by using the KSQL_OPTS
environment variable. For example, to assign the ksql.queries.file
setting in your docker run
command, specify:
1 |
|
Properties set with KSQL_OPTS
take precedence over values specified in
the ksqlDB configuration file. For more information, see
Setting ksqlDB Server Parameters.
ksqlDB Server configurations¶
The following commands show how to run ksqlDB Server in different configurations.
ksqlDB Headless Server Settings (Production)¶
You can deploy ksqlDB Server into production in a non-interactive, or
headless, mode. In headless mode, interactive use of the ksqlDB cluster
is disabled, and you configure ksqlDB Server with a predefined .sql
file
and the KSQL_KSQL_QUERIES_FILE
setting. For more information, see
Non-interactive (Headless) ksqlDB Usage.
Use the following command to run a headless, standalone ksqlDB Server instance in a container:
1 2 3 4 5 6 |
|
KSQL_BOOTSTRAP_SERVERS
-
A list of hosts for establishing the initial connection to the Kafka cluster.
KSQL_KSQL_SERVICE_ID
-
The service ID of the ksqlDB server, which is used as the prefix for the internal topics created by ksqlDB.
KSQL_KSQL_QUERIES_FILE
-
A file that specifies predefined SQL queries.
ksqlDB Interactive Server Settings (Development)¶
Develop your ksqlDB applications by using the ksqlDB command-line interface (CLI), or the graphical interface in Confluent Control Center, or both together.
Run a ksqlDB Server that enables manual interaction by using the ksqlDB CLI:
1 2 3 4 5 6 |
|
KSQL_BOOTSTRAP_SERVERS
-
A list of hosts for establishing the initial connection to the Kafka cluster.
KSQL_KSQL_SERVICE_ID
-
The service ID of the ksqlDB Server, which is used as the prefix for the internal topics created by ksqlDB.
KSQL_LISTENERS
-
A list of URIs, including the protocol, that the broker listens on. If you are using IPv6, set to
http://[::]:8088
.
In interactive mode, a ksqlDB CLI instance running outside of Docker can connect to the ksqlDB server running in Docker.
Connect ksqlDB Server to a secure Kafka Cluster, like Confluent Cloud¶
ksqlDB Server runs outside of your Kafka clusters, so you need to specify in the container environment how ksqlDB Server connects with a Kafka cluster.
Run a ksqlDB Server that uses a secure connection to a Kafka cluster:
1 2 3 4 5 6 7 8 9 10 11 12 |
|
KSQL_BOOTSTRAP_SERVERS
-
A list of hosts for establishing the initial connection to the Kafka cluster.
KSQL_KSQL_SERVICE_ID
-
The service ID of the ksqlDB Server, which is used as the prefix for the internal topics created by ksqlDB.
KSQL_LISTENERS
-
A list of URIs, including the protocol, that the broker listens on. If you are using IPv6, set to
http://[::]:8088
. KSQL_KSQL_SINK_REPLICAS
-
The default number of replicas for the topics created by ksqlDB. The default is one.
KSQL_KSQL_STREAMS_REPLICATION_FACTOR
-
The replication factor for internal topics, the command topic, and output topics.
KSQL_KSQL_INTERNAL_TOPIC_REPLICAS
-
The number of replicas for the internal topics created by ksqlDB Server. The default is 1.
KSQL_SECURITY_PROTOCOL
-
The protocol that your Kafka cluster uses for security.
KSQL_SASL_MECHANISM
-
The SASL mechanism that your Kafka cluster uses for security.
KSQL_SASL_JAAS_CONFIG
-
The Java Authentication and Authorization Service (JAAS) configuration.
Learn how to Configure Security for ksqlDB.
Configure a ksqlDB Server by Using Java System Properties¶
Use the KSQL_OPTS
environment variable to assign configuration
settings by using Java system properties. Prepend the ksqlDB setting name
with -D
. For example, to set the ksqlDB service identifier in the
docker run
command, use:
1 |
|
Run a ksqlDB Server with a configuration that's defined by Java properties:
1 2 3 4 5 |
|
KSQL_BOOTSTRAP_SERVERS
-
A list of hosts for establishing the initial connection to the Kafka cluster.
KSQL_OPTS
-
A space-separated list of Java options.
The previous example assigns two settings, ksql.service.id
and
ksql.queries.file
. Specify more configuration settings by adding them
in the KSQL_OPTS
line. Remember to prepend each setting name with
-D
.
View ksqlDB Server Logs¶
Use the docker logs
command to view ksqlDB logs that are generated from
within the container:
1 |
|
Your output should resemble:
1 2 |
|
Enable the ksqlDB Processing Log¶
ksqlDB emits a log of record processing events, called the processing log, to help you debug SQL queries. For more information, see ksqlDB Processing Log.
Assign the following configuration settings to enable the processing log.
1 2 3 4 5 6 |
|
ksqlDB Command-line Interface (CLI)¶
Develop the SQL queries and statements for your real-time streaming applications by using the ksqlDB CLI, or the graphical interface in Confluent Control Center, or both together. The ksqlDB CLI connects to a running ksqlDB Server instance to enable inspecting Kafka topics and creating ksqlDB streams and tables. For more information, see Configure ksqlDB CLI.
The following commands show how to run the ksqlDB CLI in a container and connect to a ksqlDB Server.
Connect ksqlDB CLI to a Dockerized ksqlDB Server¶
Run a ksqlDB CLI instance in a container and connect to a ksqlDB Server that's running in a different container.
1 2 3 4 5 6 7 8 |
|
KSQL_BOOTSTRAP_SERVERS
-
A list of hosts for establishing the initial connection to the Kafka cluster.
KSQL_OPTS
-
A space-separated list of Java options. If you are using IPv6, set
listeners
tohttp://[::]:8088
.
The Docker network created by ksqlDB Server enables you to connect with a dockerized ksqlDB CLI.
Start ksqlDB CLI With a Provided Configuration File¶
Set up a a ksqlDB CLI instance by using a configuration file, and run it in a container:
1 2 3 4 5 6 7 8 |
|
Connect ksqlDB CLI to a ksqlDB Server Running on Another Host (Cloud)¶
Run a ksqlDB CLI instance in a container and connect to a remote ksqlDB Server host:
1 2 |
|
Your output should resemble:
1 2 3 4 5 6 7 8 |
|
Interact with ksqlDB running in a Docker container¶
You can communicate with ksqlDB Server and the ksqlDB CLI when they run in Docker containers. The following examples show common tasks with ksqlDB processes that run in containers.
- Wait for an HTTP Endpoint to Be Available
- Wait for a Particular Phrase in a Container's Log
- Run Custom Code Before Launching a Container's Program
- Execute a ksqlDB script in the ksqlDB CLI
Wait for an HTTP endpoint to be available¶
Sometimes, a container reports its state as up
before it's actually
running. In this case, the docker-compose depends_on
dependencies
aren't sufficient. For a service that exposes an HTTP endpoint, like
ksqlDB Server, you can force a script to wait before running a client that
requires the service to be ready and available.
Use the following bash commands to wait for ksqlDB Server to be available:
1 2 3 4 5 6 |
|
This script pings the ksqlDB Server at <ksql-server-ip-address>:8088
every five seconds, until it receives an HTTP 200 response.
Note
The previous script doesn't work with "headless" deployments of ksqlDB Server, because headless deployments don't have a REST API server.
To launch the ksqlDB CLI in a container only after ksqlDB Server is available, use the following Docker Compose command:
1 2 |
|
Wait for a particular phrase in a container's log¶
Use the grep
command and
bash process substitution
to wait until the a specific phrase occurs in the Docker Compose log:
1 2 3 |
|
Run custom code before launching a container's program¶
You can run custom code, like downloading a dependency or moving a file, before a ksqlDB process starts in a container. Use Docker Compose to overlay a change on an existing image.
Get the container's default command¶
Discover the default command that the container runs when it launches,
which is either Entrypoint
or Cmd
:
1 2 |
|
Your output should resemble:
1 2 |
|
In this example, the default command is /etc/confluent/docker/run
.
Run custom commands before the ksqlDB process starts¶
In a Docker Compose file, add the commands that you want to run before
the main process starts. Use the command
option to override the
default command. In the following example, the command
option creates
a directory and downloads a tar archive into it.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
After the mkdir
, cd
, curl
, and tar
commands run, the
/etc/confluent/docker/run
command starts the ksqldb-server
image
with the specified settings.
Note
The literal block scalar, - |
, enables passing multiple arguments to
command
, by indicating that the following lines are all part of the
same entry.
Execute a ksqlDB script in the ksqlDB CLI¶
The following Docker Compose YAML runs ksqlDB CLI and passes it a SQL script for execution. The manual EXIT is required. The advantage of this approach, compared with running ksqlDB Server headless with a queries file, is that you can still interact with ksqlDB, and you can pre-build the environment to a desired state.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|