1. Home
2. Platform
3. Kafka 用アプリケーションの構築

Docker Developer Guide

このドキュメントは、読者に Docker と Dockerfile に関する知識があることを前提としています。Dockerfile を作成するためのベストプラクティスについては、Docker のベストプラクティスガイド を参照してください。

プロジェクトへの貢献を検討されている場合は、貢献に関するガイドライン をご確認ください。

Confluent Platform イメージの起動プロセス

Docker の起動時に、エントリポイント /etc/confluent/docker/run は、/etc/confluent/docker にある 3 つの実行可能スクリプトを実行します。これらのスクリプトは以下の順序で実行されます。

1. configure スクリプト

   /etc/confluent/docker/configure スクリプトは、各イメージに必要な構成をすべて行います。これには以下の処理が含まれます。

   • すべての構成ファイルを作成し、適切な場所にコピーする。
   • 必須構成プロパティが存在することを確認する。
   • 必要に応じて、サービス検出を処理する。

2. ensure スクリプト

   /etc/confluent/docker/ensure スクリプトは、サービスを起動するためのすべての前提条件が満たされていることを確認します。これには以下の処理が含まれます。

   • 構成ファイルが存在し、読み取り可能であることを確認する。
   • データディレクトリへの書き込み/読み取りが可能であることを確認する。各ディレクトリに対して、すべてのユーザーが書き込み可能である必要があります。
   • 補助的サービスの準備が完了していることを確認する。たとえば、Kafka ブローカーを起動する前に、ZooKeeper が準備できていることを確認します。
   • 補助的システムが正しく構成されていることを確認する。たとえば、Confluent Control Center に必要なすべてのトピックが、レプリケーション、セキュリティ、およびパーティションに関して適切な設定で作成されていることを確認します。

3. launch

   /etc/confluent/docker/launch スクリプトが実際のプロセスを実行します。このスクリプトにより、以下の処理が確実に実行されます。

   • プロセスがプロセス ID 1 で実行される。プログラムが子プロセスとして実行されるのではなく、シェルプロセスを引き継ぐように、スクリプトで exec を使用する必要があります。これは、SIGTERM のようなシグナルを、親シェルプロセスではなくプログラムが直接受け取るようにするためです。
   • stdout にログを記録する。

前提条件

1. Docker をインストールする。

   • Docker バージョン 1.11 またはそれ以降が インストールされ動作している。
   • Docker Compose が インストール済みである 。Docker Compose は、Docker for Mac ではデフォルトでインストールされます。
   • Docker メモリーに最小でも 8 GB が割り当てられている。Docker Desktop for Mac を使用しているとき、Docker メモリーの割り当てはデフォルトで 2 GB です。Docker でデフォルトの割り当てを 8 GB に変更できます。Preferences、Resources、Advanced の順に移動します。

2. Maven をインストールする。

   brew install maven
   

Confluent Platform イメージのビルド

Confluent Platform コンポーネントの GitHub リポジトリのリストについては、「Docker Image Reference」を参照してください。

ビルドする Confluent Platform イメージごとに、以下の処理を実行します。

1. リポジトリのコピーを作成します。

2. リリースブランチをチェックアウトします。

3. ビルドコマンドの必須の引数およびオプションの引数の値を取得します。

   サポートされる引数のリストについては、こちらの README ファイル を参照してください。

   以下は必須の引数です。

   • CONFLUENT_PACKAGES_REPO : Confluent Platform パッケージリポジトリの場所を指定します。ビルドするイメージの OS のタイプによっては、Debian または RPM リポジトリを提供する必要があります。
   • CONFLUENT_VERSION : 完全な Confluent Platform リリースバージョン（例: 7.1.1 ）を指定します。
   • docker.upstream-registry : ベースイメージの取得元レジストリ。末尾に / が必要です。docker build で DOCKER_UPSTREAM_REGISTRY として使用されます。
   • docker.upstream-tag : ベースイメージを取得するときに指定したタグを使用します。docker build で DOCKER_UPSTREAM_TAG として使用されます。

4. オプションで、Docker イメージのベースとなるオペレーティングシステム（具体的には Debian または RHEL UBI）を選択できます。RHEL UBI イメージをビルドするには、Maven コマンドに次の引数を渡します。

   -Ddocker.os_type=ubi8
   

5. リポジトリのルートフォルダーから、Maven を使用して Confluent Platform イメージをビルドします。

   以下に例を示します。

   mvn clean package \
   -DskipTests -Pdocker \
   -DCONFLUENT_PACKAGES_REPO='https://packages.confluent.io/rpm/7.1' \
   -DCONFLUENT_VERSION=7.1.1 \
   -Ddocker.upstream-registry=docker.io/ \
   -Ddocker.upstream-tag=7.1.1
   

Confluent Platform イメージの拡張

イメージを拡張して、コネクターの追加またはカスタマイズ、新しいソフトウェアの追加、構成管理の変更、および外部サービス検出のセットアップを行うことができます。

以下のセクションで、Confluent Platform イメージを拡張する例を示します。

注釈

自分でビルドしたカスタム Docker イメージの拡張にも同じ手順を適用できます。

ただし、カスタム Docker イメージで問題が発生した場合は、Confluent サポートと協力して問題点を絞り込む必要があります。Confluent サポートでは、Confluent Platform ソフトウェアに関わる問題の支援にのみ対応します。

Docker またはサードパーティのソフトウェアの問題を、Confluent サポートがさらにデバッグすることはできません。

コネクターまたはソフトウェアの追加

Kafka Connect ベースイメージには、Kafka Connect およびそのすべての依存関係が含まれます。このイメージは、起動すると Connect フレームワークを分散モードで実行します。このイメージに新しいコネクターを追加するには、新しいコネクターがインストールされた新しい Docker イメージをビルドする必要があります。以下の例で、コネクターを追加する方法を説明します。

注釈

Confluent Platform バージョン 6.0 リリース以降では、以前 Confluent Platform にバンドルされていた多くのコネクターが Confluent Hub からダウンロードできるようになりました。詳細については、6.0 のコネクターのリリースノート を参照してください。

Confluent Hub コネクターを含む Docker イメージの作成

この例では、Confluent Hub クライアント を使用して、Confluent の Kafka Connect イメージの 1 つから拡張された Docker イメージを作成する方法を示しますが、このイメージにはコネクターのカスタムセットが含まれています。こうすると、cp-kafka-connect イメージに含まれていないコネクターを使用する場合や、カスタムイメージを軽量に保ち、使用する予定のないコネクターを含まないようにする場合に便利です。

1. Confluent Hub からコネクターを追加します。

2. 拡張するイメージを選択します。

3. カスタムイメージに含めるコネクターを Confluent Hub から選択します。以降の手順を通じて、MongoDB コネクター、Microsoft Azure IoT Hub コネクター、Google BigQuery コネクターを含むカスタムイメージが生成されます。

4. Dockerfile を作成します。

   FROM confluentinc/cp-kafka-connect-base:7.1.1
   
   RUN   confluent-hub install --no-prompt hpgrahsl/kafka-connect-mongodb:1.1.0 \
      && confluent-hub install --no-prompt microsoft/kafka-connect-iothub:0.6 \
      && confluent-hub install --no-prompt wepay/kafka-connect-bigquery:1.1.0
   

5. Dockerfile をビルドします。

   docker build . -t my-custom-image:1.0.0
   

   このコマンドの出力は以下のようになります。

   Step 1/2 : FROM confluentinc/cp-kafka-connect-base
   ---> e0d92da57dc3
   ...
   Running in a "--no-prompt" mode
   Implicit acceptance of the license below:
   Apache 2.0
   https://github.com/wepay/kafka-connect-bigquery/blob/master/LICENSE.md
   Implicit confirmation of the question: You are about to install 'kafka-connect-bigquery' from WePay, as published on Confluent Hub.
   Downloading component BigQuery Sink Connector 1.1.0, provided by WePay from Confluent Hub and installing into /usr/share/confluent-hub-components
   Adding installation directory to plugin path in the following files:
     /etc/kafka/connect-distributed.properties
     /etc/kafka/connect-standalone.properties
     /etc/schema-registry/connect-avro-distributed.properties
     /etc/schema-registry/connect-avro-standalone.properties
   
   Completed
   Removing intermediate container 48d4506b8a83
    ---> 496befc3d3f7
   Successfully built 496befc3d3f7
   Successfully tagged my-custom-image:1.0.0
   

   結果的に、my-custom-image という名前のイメージが作成されます。このイメージには、MongoDB、Azure IoT Hub、および BigQuery コネクターが含まれ、Kafka Connect フレームワークを使用してコネクターの一部またはすべてを実行できます。

docker-compose.yml ファイルと Confluent Hub クライアント を使用して Kafka 環境をビルドする場合、以下のプロパティを使用してコネクターを有効にします。（この例は、Datagen の開発およびテストコネクターを示しています）。

connect:
  image: confluentinc/kafka-connect-datagen:latest
  build:
    context: .
    dockerfile: Dockerfile-confluenthub

ローカルコネクターを含む Docker イメージの作成

この例では、cp-kafka-connect-base イメージを拡張して 1 つ以上のローカルコネクターを含む Docker イメージを作成する方法を示します。これは、Confluent Hub からコネクターを取得するのではなく、独自のコネクターを使用する場合に便利です。

1. ローカルコネクターを zip ファイルにパッケージ化します。

2. 以下の例のように Dockerfile をセットアップします。

   FROM confluentinc/cp-kafka-connect-base:7.1.1
   
   COPY target/components/packages/my-connector-7.1.1.zip /tmp/my-connector-7.1.1.zip
   
   RUN confluent-hub install --no-prompt /tmp/my-connector-7.1.1.zip
   

3. Dockerfile をビルドします。

   docker build . -t my-custom-image:1.0.0
   

ソフトウェアの追加

この例では、イメージに新しいソフトウェアを追加する方法を示します。たとえば、Kafka Connect クライアントを拡張して MySQL JDBC ドライバを含めることができます。この方法を使用して新しいコネクターをイメージに追加する場合は、コネクター JAR が Connect フレームワークの plugin.path または CLASSPATH にある必要があります。

1. Dockerfile を作成します。

   FROM confluentinc/cp-kafka-connect
   
   ENV MYSQL_DRIVER_VERSION 5.1.39
   
   RUN curl -k -SL "https://dev.mysql.com/get/Downloads/Connector-J/mysql-connector-java-${MYSQL_DRIVER_VERSION}.tar.gz" \
        | tar -xzf - -C /usr/share/java/kafka/ --strip-components=1 mysql-connector-java-5.1.39/mysql-connector-java-${MYSQL_DRIVER_VERSION}-bin.jar
   

2. イメージをビルドします。

   docker build -t foo/mysql-connect:latest .
   

注釈

この方法は、独自の Kafka Connect プラグインを使用してイメージを作成する場合にも使用できます。

構成管理の変更

この例では、構成管理を変更する方法を説明します。このために、configure スクリプトをオーバーライドして各スクリプトを URL からダウンロードします。

たとえば、ZooKeeper イメージの場合、以下の Dockerfile と configure スクリプトが必要です。この例では、各プロパティファイルに URL があることを前提としています。

Dockerfile:

FROM confluentinc/cp-zookeeper

COPY include/etc/confluent/docker/configure /etc/confluent/docker/configure

configure スクリプトの例:

場所 : include/etc/confluent/docker/configure

. /etc/confluent/docker/bash-config

# Ensure that URL locations are available.
dub ensure ZOOKEEPER_SERVER_CONFIG_URL
dub ensure ZOOKEEPER_SERVER_ID_URL
dub ensure ZOOKEEPER_LOG_CONFIG_URL

# Ensure that the config location is writable.
dub path /etc/kafka/ writable

curl -XGET ZOOKEEPER_SERVER_CONFIG_URL > /etc/kafka/zookeeper.properties
curl -XGET ZOOKEEPER_SERVER_ID_URL > /var/lib/zookeeper/data/myid
curl -XGET ZOOKEEPER_LOG_CONFIG_URL > /etc/kafka/log4j.properties

Build the image:

    docker build -t foo/zookeeper:latest .

コマンドを入力します。

docker run \
     -e ZOOKEEPER_SERVER_CONFIG_URL=http://foo.com/zk1/server.properties \
     -e ZOOKEEPER_SERVER_ID_URL =http://foo.com/zk1/myid \
     -e ZOOKEEPER_LOG_CONFIG_URL =http://foo.com/zk1/log4j.properties \
     foo/zookeeper:latest

外部ボリュームへのログの記録

イメージは、データおよびセキュリティ構成用のボリュームのみを公開します。ただし、ユースケースによっては外部ストレージへの書き込みが必要となる場合もあります。以下の例は、Kafka オーソライザーログを監査用のボリュームに書き込む方法を示しています。

Dockerfile:

FROM confluentinc/cp-kafka

# Make sure the log directory is world-writable
RUN echo "===> Creating authorizer logs dir ..." \\
     && mkdir -p /var/log/kafka-auth-logs \\
     && chmod -R ag+w /var/log/kafka-auth-logs

VOLUME \["/var/lib/$\{COMPONENT}/data", "/etc/$\{COMPONENT}/secrets", "/var/log/kafka-auth-logs"]

COPY include/etc/confluent/log4j.properties.template /etc/confluent/docker/log4j.properties.template

log4j.properties.template:

場所 : include/etc/confluent/log4j.properties.template

log4j.rootLogger={{ env["KAFKA_LOG4J_ROOT_LOGLEVEL"] | default('INFO') }}, stdout

log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=[%d] %p %m (%c)%n

log4j.appender.authorizerAppender=org.apache.log4j.DailyRollingFileAppender
log4j.appender.authorizerAppender.DatePattern='.'yyyy-MM-dd-HH
log4j.appender.authorizerAppender.File=/var/log/kafka-auth-logs/kafka-authorizer.log
log4j.appender.authorizerAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.authorizerAppender.layout.ConversionPattern=[%d] %p %m (%c)%n

log4j.additivity.kafka.authorizer.logger=false

{% set loggers = {
 'kafka': 'INFO',
 'kafka.network.RequestChannel$': 'WARN',
 'kafka.producer.async.DefaultEventHandler': 'DEBUG',
 'kafka.request.logger': 'WARN',
 'kafka.controller': 'TRACE',
 'kafka.log.LogCleaner': 'INFO',
 'state.change.logger': 'TRACE',
 'kafka.authorizer.logger': 'WARN, authorizerAppender'
 } -%}


{% if env['KAFKA_LOG4J_LOGGERS'] %}
{% set loggers = parse_log4j_loggers(env['KAFKA_LOG4J_LOGGERS'], loggers) %}
{% endif %}

{% for logger,loglevel in loggers.iteritems() %}
log4j.logger.\{\{logger}}=\{\{loglevel}}
{% endfor %}

イメージをビルドします。

docker build -t foo/kafka-auditable:latest .

ガーベッジコレクションログの外部ボリュームへの書き込み

以下の例は、ヒープダンプと GC ログを外部ボリュームに記録する方法を示しています。これは、Kafka イメージのデバッグに役立ちます。

Dockerfile:

FROM confluentinc/cp-kafka

# Make sure the jvm log directory is world-writable
RUN echo "===> Creating jvm logs dir ..." \
     && mkdir -p /var/log/jvm-logs
     && chmod -R ag+w /var/log/jvm-logs

VOLUME ["/var/lib/${COMPONENT}/data", "/etc/${COMPONENT}/secrets", "/var/log/jvm-logs"]

1. イメージをビルドします。

   docker build -t foo/kafka-verbose-jvm:latest .
   

2. コマンドを入力します。

   docker run \
       -e KAFKA_HEAP_OPTS="-Xmx256M -Xloggc:/var/log/jvm-logs/verbose-gc.log -verbose:gc -XX:+PrintGCDateStamps -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/jvm-logs" \
       foo/kafka-verbose-jvm:latest
   

外部サービス検出の使用

関連するプロパティをオーバーライドするか、「構成管理の変更」に示すように configure スクリプトをオーバーライドすることで、サービス検出メカニズムをサポートするようにイメージを拡張できます。

Mesos サービス検出に関連するプロパティをオーバーライドすることで、Docker イメージが Mesos をサポートするようになります。たとえば、debian/kafka-connect/includes/etc/confluent/docker/mesos-overrides とします。

Oracle JDK の使用

Confluent Platform イメージには Azul Zulu OpenJDK が付属しています。Oracle のバージョンを使用する必要がある場合は、以下の手順に従って cp-base-new イメージを変更し、Zulu OpenJDK の代わりに Oracle JDK を含めます。

1. ダウンロード URL を Oracle のウェブサイト から入手します。

2. Confluent ベースイメージ リポジトリの base ディレクトリで、正しいバージョンブランチ 7.1.1-post の Dockerfile.ubi8 ファイルを編集します。

3. Zulu OpenJDK に関する以下の行を、

   ENV ZULU_OPENJDK="zulu-11-11.990-1"
   
   RUN microdnf install yum \
       && rpm --import https://www.azul.com/files/0xB1998361219BD9C9.txt \
       && yum -y install https://cdn.azul.com/zulu/bin/zulu-repo-1.0.0-1.noarch.rpm \
       && yum -y install ${ZULU_OPENJDK} \
   

   Oracle JDK に関する以下の行で置き換えます。

   RUN microdnf install yum \
       && curl -L <URL you obtained in Step #1> --output /tmp/jre1.8-latest.rpm \
       && yum -y install /tmp/jre1.8-latest.rpm \
       && rm -f /tmp/jre1.8-latest.rpm \
   

4. cp-base-new イメージを再ビルドします。手順については、「Confluent Platform イメージのビルド」を参照してください。

ユーティリティスクリプト

各種 Confluent Platform コンポーネント間に依存関係（たとえば、Kafka に ZooKeeper が必要、Schema Registry に Kafka および ZooKeeper が必要など）があるため、さまざまなサービスのステータスをチェックできることが必要な場合があります。イメージの起動シーケンスおよびテストフレームワークでは、以下のユーティリティが使用されます。

Docker ユーティリティベルト（dub）

1. template

   usage: dub template [-h] input output
   
   Generate template from env vars.
   
   positional arguments:
     input       Path to template file.
     output      Path of output file.
   

2. ensure

   usage: dub ensure [-h] name
   
   Check if env var exists.
   
   positional arguments:
     name        Name of env var.
   

3. wait

   usage: dub wait [-h] host port timeout
   
   wait for network service to appear.
   
   positional arguments:
     host        Host.
     port        Host.
     timeout     timeout in secs.
   

4. path

   usage: dub path [-h] path {writable,readable,executable,exists}
   
   Check for path permissions and existence.
   
   positional arguments:
     path                  Full path.
     {writable,readable,executable,exists} One of [writable, readable, executable, exists].
   

5. path-wait

   usage: dub path-wait [-h] path timeout
   
   Wait for a path to exist.
   
   positional arguments:
     path        Full path.
     timeout     Time in secs to wait for the path to exist.
   
   optional arguments:
     -h, --help  show this help message and exit
   

Confluent Platform ユーティリティベルト（cub）

1. zk-ready

   ZooKeeper が準備できているかどうかをチェックするために使用します。

   usage: cub zk-ready [-h] connect_string timeout retries wait
   
   Check if ZK is ready.
   
   positional arguments:
     connect_string  ZooKeeper connect string.
     timeout         Time in secs to wait for service to be ready.
     retries         No of retries to check if leader election is complete.
     wait            Time in secs between retries
   

2. kafka-ready

   Kafka が準備できているかどうかをチェックするために使用します。

   usage: cub kafka-ready [-h] (-b BOOTSTRAP_BROKER_LIST | -z ZOOKEEPER_CONNECT)
                    [-c CONFIG] [-s SECURITY_PROTOCOL]
                    expected_brokers timeout
   
   Check if Kafka is ready.
   
   positional arguments:
   expected_brokers      Minimum number of brokers to wait for
   timeout               Time in secs to wait for service to be ready.
   
   optional arguments:
   -h, --help                     show this help message and exit
   -b BOOTSTRAP_BROKER_LIST,      --bootstrap_broker_list BOOTSTRAP_BROKER_LIST
                                  List of bootstrap brokers.
   -z ZOOKEEPER_CONNECT,          This option is deprecated in Confluent Platform 5.5.0 and later.
                                  --zookeeper_connect ZOOKEEPER_CONNECT
                                  ZooKeeper connect string.
   -c CONFIG,                     --config CONFIG
                                  Path to config properties file (required when security
                                  is enabled).
   -s SECURITY_PROTOCOL,          --security-protocol SECURITY_PROTOCOL
                                  Security protocol to use when multiple listeners are
                                  enabled.
   

3. sr-ready

   Schema Registry が準備できているかどうかをチェックするために使用します。複数の Schema Registry ノードがある場合は、それらの可用性を個別にチェックする必要があります。

   usage: cub sr-ready [-h] host port timeout
   
   positional arguments:
     host     Hostname for Schema Registry.
     port     Port for Schema Registry.
     timeout  Time in secs to wait for service to be ready.
   

3. kr-ready

   REST Proxy が準備できているかどうかをチェックするために使用します。複数の REST Proxy ノードがある場合は、それらの可用性を個別にチェックする必要があります。

   usage: cub kr-ready [-h] host port timeout
   
   positional arguments:
     host     Hostname for REST Proxy.
     port     Port for REST Proxy.
     timeout  Time in secs to wait for service to be ready.
   

4. connect-ready

   Kafka Connect が準備できているかどうかをチェックするために使用します。

   usage: cub connect-ready [-h] host port timeout
   
   positional arguments:
     host     Hostname for Connect worker.
     port     Port for Connect worker.
     timeout  Time in secs to wait for service to be ready.
   

5. ksql-server-ready

   ksqlDB が準備できているかどうかをチェックするために使用します。

   usage: cub ksql-server-ready [-h] host port timeout
   
   positional arguments:
     host     Hostname for KSQL server.
     port     Port for KSQL server.
     timeout  Time in secs to wait for service to be ready.
   

6. control-center-ready

   Confluent Control Center が準備できているかどうかをチェックするために使用します。

   usage: cub control-center-ready [-h] host port timeout
   
   positional arguments:
     host     Hostname for Control Center.
     port     Port for Control Center.
     timeout  Time in secs to wait for service to be ready.
   

クライアントのプロパティ

前述の kafka-ready ユーティリティを使用すると、以下のプロパティを構成できます。

bootstrap.servers

Kafka クラスターとの初期接続を確立するために使用するホストとポートのペアのリスト。ここでブートストラップ用にどのサーバーが指定されているかにかかわらず、クライアントはすべてのサーバーを使用します。このリストは、すべてのサーバーを検出するために使用する最初のホストにのみ影響します。このリストは、host1:port1,host2:port2,... という形式にする必要があります。これらのサーバーは、初期接続ですべてのクラスターメンバーシップを検出するためにのみ使用されます。これは動的に変わる可能性があるので、このリストにすべてのサーバーセットを含める必要はありません（ただし、サーバーの障害に備えて、複数指定しておくこともできます）。

• 型: list
• デフォルト:
• 重要度: 高

ssl.key.password

キーストアファイル内のプライベートキーのパスワード。クライアントでは省略可能です。

• 型: password
• 重要度: 高

ssl.keystore.location

キーストアファイルの場所。クライアントでは省略可能です。クライアントの相互認証に使用できます。

• 型: string
• 重要度: 高

ssl.keystore.password

キーストアファイルのストアパスワード。クライアントでは省略可能です。ssl.keystore.location を構成した場合にのみ必要となります。

• 型: password
• 重要度: 高

ssl.truststore.location

トラストストアファイルの場所。

• 型: string
• 重要度: 高

ssl.truststore.password

トラストストアファイルのパスワード。

• 型: password
• 重要度: 高

sasl.kerberos.service.name

Kafka が実行される際の Kerberos プリンシパル名。これは、Kafka の JAAS 構成または Kafka の構成のいずれかで定義できます。

• 型: string
• 重要度: 中

sasl.mechanism

クライアントの接続に使用される SASL メカニズム。セキュリティプロバイダーを利用できるものであれば、どのメカニズムでも構いません。GSSAPI がデフォルトのメカニズムです。

• 型: string
• デフォルト: "GSSAPI"
• 重要度: 中

security.protocol

ブローカーとの通信に使用されるプロトコル。指定可能な値は、PLAINTEXT、SSL、SASL_PLAINTEXT、SASL_SSL です。

• 型: string
• デフォルト: "PLAINTEXT"
• 重要度: 中

ssl.enabled.protocols

SSL 接続で有効なプロトコルのリスト。

• 型: list
• デフォルト: [TLSv1.2, TLSv1.1, TLSv1]
• 重要度: 中

ssl.keystore.type

キーストアファイルのファイルフォーマット。クライアントでは省略可能です。

• 型: string
• デフォルト: "JKS"
• 重要度: 中

ssl.protocol

SSLContext の生成に使用する SSL プロトコルです。デフォルト設定は TLS であり、ほとんどのケースに適しています。最新の Java 仮想マシンで使用できる値は、TLS、TLSv1.1、TLSv1.2 です。古い JVM では SSL、SSLv2、および SSLv3 がサポートされている場合もありますが、セキュリティに関する既知の脆弱性があるため、使用しないことをお勧めします。

• 型: string
• デフォルト: "TLS"
• 重要度: 中

ssl.provider

SSL 接続に使用するセキュリティプロバイダーの名前。デフォルト値は、JVM のデフォルトのセキュリティプロバイダーです。

• 型: string
• 重要度: 中

ssl.truststore.type

トラストストアファイルのファイルフォーマット。

• 型: string
• デフォルト: "JKS"
• 重要度: 中

sasl.kerberos.kinit.cmd

Kerberos の kinit コマンドパス。

• 型: string
• デフォルト: "/usr/bin/kinit"
• 重要度: 低

sasl.kerberos.min.time.before.relogin

更新試行から次の更新試行までの、ログインスレッドのスリープ時間。

• 型: long
• デフォルト: 60000
• 重要度: 低

sasl.kerberos.ticket.renew.jitter

更新時間に追加されたランダムジッターのパーセンテージ。

• 型: double
• デフォルト: 0.05
• 重要度: 低

sasl.kerberos.ticket.renew.window.factor

最後の更新からチケットの有効期限までの時間が指定のウィンドウ係数に達するまでの間、ログインスレッドはスリープ状態になります。この時間の経過後、チケットの更新が試行されます。

• 型: double
• デフォルト: 0.8
• 重要度: 低

ssl.cipher.suites

暗号スイートのリストです。これは、認証、暗号化、MAC、およびキー交換アルゴリズムの名前付き組み合わせで、TLS または SSL ネットワークプロトコルを使用したネットワーク接続のセキュリティ設定をネゴシエートするために使用されます。デフォルトでは、使用可能なすべての暗号スイートがサポートされます。

• 型: list
• 重要度: 低

ssl.endpoint.identification.algorithm

サーバー証明書を使用してサーバーホスト名を検証するエンドポイント識別アルゴリズム。

• 型: string
• 重要度: 低

ssl.keymanager.algorithm

SSL 接続のキーマネージャーファクトリで使用されるアルゴリズム。デフォルト値は、Java 仮想マシン用に構成されているキーマネージャーファクトリアルゴリズムです。

• 型: string
• デフォルト: "SunX509"
• 重要度: 低

ssl.trustmanager.algorithm

SSL 接続のトラストマネージャーファクトリで使用されるアルゴリズム。デフォルト値は、Java 仮想マシン用に構成されているトラストマネージャーファクトリアルゴリズムです。

• 型: string
• デフォルト: "PKIX"
• 重要度: 低

リファレンス

Docker 化された AWS EC2 インスタンスのセットアップ例については、こちらのドキュメント を参照してください。