1. Home
2. Ansible

Ansible Playbook を使用した Confluent Platform のアップグレード

Ansible Playbooks for Confluent Platform では、Confluent Platform コンポーネントをアップグレードできます。ホストを安全にアップグレードするには、ローリングデプロイ戦略を利用します。この方法では、ホストごとにコンポーネントをシャットダウンし、パッケージのアップグレード、サービスの再起動、サービスの正常性の確認を行ってから、次のホストに進みます。

アップグレードでは、以下の作業を順番どおりに行う必要があります。

1. ZooKeeper をアップグレードします。
2. Kafka ブローカーをアップグレードします。
3. 以下をアップグレードします。順番は任意です。
   • Schema Registry
   • REST Proxy
   • Connect
4. Confluent Control Center をアップグレードします。
5. 外部クライアントをアップグレードします。
6. Kafka のログフォーマットをアップグレードします。この作業により、すべてのアップグレードの終了後、新しいバージョンの Confluent Platform でログが適切なフォーマットで記録されるようになります。

このトピックでは、Confluent Platform のインストール手順について説明します。

• Ansible 2.11 以降を使用してアップグレードする
• Ansible 2.9 または 2.10 を使用してアップグレードする

要件

アップグレード Playbook には以下の要件があります。

• Confluent Platform コンポーネントは、Ansible Playbooks for Confluent Platform を使用してインストールおよび構成されている必要があります。
• インストール中は同じ hosts.yml ファイルを使用する必要があります。
• Upgrade playbooks are supported in Confluent Platform version 6.0.0 and later.

アップグレードに関する注意事項

アップグレードプロセスを開始する前に、以下の変更を確認し、必要なアップデートを行ってください。

• SASL/SCRAM のデフォルトバージョン

  デフォルトの SASL/SCRAM バージョンが 256 から 512 に変更されました。

  server.properties 内で SSL/SCRAM のバージョンが 256 として指定されている場合は、インベントリをアップデートし、sasl_protocol: scram を sasl_protocol: scram256 に変更する必要があります。

• ZooKeeper TLS

  TLS は ZooKeeper に対してデフォルトで有効になっています（ssl_enabled: true が設定されている場合）。

  現在の ZooKeeper デプロイで TLS を使用していない場合は、インベントリで zookeeper_ssl_enabled: false を設定します。

• ZooKeeper サーバー/サーバー TLS

  ZooKeeper サーバー/サーバー認証関連で、改善されたロジックと変数が追加されました。zookeeper.properties に sslQuorum=true が設定されている場合は、インベントリで zookeeper_quorum_authentication_type: mtls を設定します。

• Admin REST APIs の有効化

  5.5.x から 6.2.x にアップグレードするときは、インベントリファイル内で以下のプロパティを設定して Admin REST APIs を有効にする必要があります。Admin REST APIs が有効になっていない場合、コンポーネントのアップグレードは失敗します。

  kafka_broker_rest_proxy_enabled: true
  

• 正規化を無効にする

  Confluent Platform クラスターの作成中に正規化を有効にしなかった場合は、hosts.yml インベントリファイルで次のプロパティを明示的に設定します。シナリオの例としては、ZooKeeper に対する Kafka ブローカーの認証に Kerberos を使用する Confluent Platform クラスターのアップグレードなどがあります。

  kerberos:
    canonicalize: false
  

Ansible 2.11 以降を使用して Confluent Platform をアップグレードする

ステップ 1. Ansible Playbooks for Confluent Platform のダウンロード

Ansible Playbooks for Confluent Platform の現在のバージョンをダウンロードします。

ansible-galaxy collection install \
  --upgrade git+https://github.com/confluentinc/cp-ansible.git,7.0.1-post

ステップ 2: ローリングデプロイ戦略の設定

コンポーネントの停止を回避するには、以下のように デプロイ戦略をローリングに設定 します。

deployment_strategy: rolling

ステップ 3: ZooKeeper のアップグレード

ZooKeeper をアップグレードするには、zookeeper タグを使用してプロビジョニングプレイブックを実行します。

ansible-playbook -i /path/to/hosts.yml confluent.platform.all --tags zookeeper

ステップ 4: Kafka のアップグレード

Kafka のアップグレードには、プロパティ inter.broker.protocol.version および log.message.format.version に特別な注意を払う必要があるため、一連の手順が必要になります。

1. 以下のコマンドを入力します。ホストにインストールされている confluent-kafka または confluent-server の現在のバージョンを確認します。

   Red Hat ホストの場合:

   rpm -qa | grep confluent
   

   出力例:

   confluent-server-6.0.1-1.noarch
   

   Debian ホストの場合:

   apt list --installed confluent-server
   

2. バージョンのプロパティを設定します。

   • 6.0.x Kafka パッケージバージョンの場合は、インベントリで以下のカスタムプロパティを設定します。

     kafka_broker_custom_properties:
       inter.broker.protocol.version: 2.6
       log.message.format.version: 2.6
     

   • 6.1.x Kafka パッケージバージョンの場合は、インベントリで以下のカスタムプロパティを設定します。

     kafka_broker_custom_properties:
       inter.broker.protocol.version: 2.7
       log.message.format.version: 2.7
     

   • 6.2.x Kafka パッケージバージョンの場合は、インベントリで以下のカスタムプロパティを設定します。

     kafka_broker_custom_properties:
       inter.broker.protocol.version: 2.8
       log.message.format.version: 2.8
     

   • 他のバージョンについては、Kafka のアップグレードに関するドキュメント を参照してください。

3. プロパティ inter.broker.protocol.version および log.message.format.version をアップグレードして設定するには、kafka_broker タグを使用してプロビジョニングプレイブックを実行します。

   ansible-playbook -i /path/to/hosts.yml confluent.platform.all --tags kafka_broker
   

4. この時点で、パッケージまたはアーカイブはアップグレードされていますが、上の 2 つのプロパティは元のバージョンに設定されたままです。次のようにして inter.broker.protocol.version をアップデートします。

   kafka_broker_custom_properties:
     inter.broker.protocol.version: 3.0
   

   さらに、もう一度プロビジョニングプレイブックを実行します。

   ansible-playbook -i /path/to/hosts.yml confluent.platform.all --tags kafka_broker \
     --skip-tags package
   

重要

すべての Kafka クライアントがアップグレードされるまで、log.message.format.version をアップデートしないでください。

ステップ 5: 他のコンポーネントのアップグレード

注釈

すべてのホストではなく特定のホストをアップグレードする必要がある場合は、アップグレードを限定 することができます。これは、コンポーネント間で負荷分散が行われている場合に有効です。このような場合、負荷分散プールから対象ホストを削除し、アップグレードしてからプールに戻します。これにより、トラフィックが中断されなくなります。特定の 1 つ以上のホストにアップグレードを限定するには、次のコマンドを入力します。

ansible-playbook -i /path/to/hosts.yml confluent.platform.all \
  --tags <component> \
  --limit "<host1>,<host2>"

他のコンポーネントをアップデートするには、以下の各コマンドを使用します。

• Schema Registry

  ansible-playbook -i /path/to/hosts.yml confluent.platform.all --tags schema_registry
  

• Connect

  ansible-playbook -i /path/to/hosts.yml confluent.platform.all --tags kafka_connect
  

• ksqlDB

  ansible-playbook -i /path/to/hosts.yml confluent.platform.all --tags ksql
  

• REST Proxy

  ansible-playbook -i /path/to/hosts.yml confluent.platform.all --tags kafka_rest
  

• Confluent Control Center

  ansible-playbook -i /path/to/hosts.yml confluent.platform.all --tags control_center
  

ステップ 6: クライアントのアップグレード

Confluent Platform 用の Ansible Playbook では現在のところ、クライアントのアップグレードをサポートしていません。詳しくは、 Confluent Platform のアップグレードの準備 を参照してください。

ステップ 7: Kafka のログフォーマットのアップデート

該当するすべてのクライアントがアップデートされたら、log.message.format.version プロパティのインベントリ変数をアップデートします。

kafka_broker_custom_properties:
  inter.broker.protocol.version: 3.0
  log.message.format.version: 3.0

さらに、もう一度プロビジョニングプレイブックを実行します。

ansible-playbook -i /path/to/hosts.yml confluent.platform.all --tags kafka_broker \
  --skip-tags package

Ansible 2.9 または 2.10 を使用して Confluent Platform をアップグレードする

ステップ 1: アップグレードブランチのチェックアウト

When using Ansible 2.9 or 2.10, you need to use the 6.2 branch of the CP-Ansible GitHub repo to upgrade to Confluent Platform 7.0.

1. Check out the 6.2.1-post branch:

   cd /path/to/cp-ansible
   git fetch
   git checkout 6.2.1-post
   

2. In the hosts.yml file, specify the Confluent Platform package version to install, for example, 7.0.1:

   all:
     vars:
       confluent_package_version: 7.0.1
   

ステップ 2: ローリングデプロイ戦略の設定

コンポーネントの停止を回避するには、以下のように デプロイ戦略をローリングに設定 する必要があります。

deployment_strategy: rolling

ステップ 3: ZooKeeper のアップグレード

ZooKeeper をアップグレードするには、zookeeper タグを使用してプロビジョニングプレイブックを実行します。

ansible-playbook -i /path/to/hosts.yml all.yml --tags zookeeper

ステップ 4: Kafka のアップグレード

Kafka のアップグレードには、プロパティ inter.broker.protocol.version および log.message.format.version に特別な注意を払う必要があるため、一連の手順が必要になります。

1. 以下のコマンドを入力します。ホストにインストールされている confluent-kafka または confluent-server の現在のバージョンを確認します。

   Red Hat ホストの場合:

   rpm -qa | grep confluent
   

   出力例:

   confluent-server-6.0.1-1.noarch
   

   Debian ホストの場合:

   apt list --installed confluent-server
   

2. バージョンのプロパティを設定します。

   • 6.0.x Kafka パッケージバージョンの場合は、インベントリで以下のカスタムプロパティを設定します。

     kafka_broker_custom_properties:
       inter.broker.protocol.version: 2.6
       log.message.format.version: 2.6
     

   • 6.1.x Kafka パッケージバージョンの場合は、インベントリで以下のカスタムプロパティを設定します。

     kafka_broker_custom_properties:
       inter.broker.protocol.version: 2.7
       log.message.format.version: 2.7
     

   • 6.2.x Kafka パッケージバージョンの場合は、インベントリで以下のカスタムプロパティを設定します。

     kafka_broker_custom_properties:
       inter.broker.protocol.version: 2.8
       log.message.format.version: 2.8
     

   • 他のバージョンについては、Kafka のアップグレードに関するドキュメント を参照してください。

3. プロパティ inter.broker.protocol.version および log.message.format.version をアップグレードして設定するには、kafka_broker タグを使用してプロビジョニングプレイブックを実行します。

   ansible-playbook -i /path/to/hosts.yml all.yml --tags kafka_broker
   

4. この時点で、パッケージまたはアーカイブはアップグレードされていますが、上の 2 つのプロパティは元のバージョンに設定されたままです。次のようにして inter.broker.protocol.version をアップデートします。

   kafka_broker_custom_properties:
     inter.broker.protocol.version: 3.0
     log.message.format.version: 2.8
   

   さらに、もう一度プロビジョニングプレイブックを実行します。

   ansible-playbook -i /path/to/hosts.yml all.yml --tags kafka_broker \
     --skip-tags package
   

重要

すべての Kafka クライアントがアップグレードされるまで、log.message.format.version をアップデートしないでください。

ステップ 5: 他のコンポーネントのアップグレード

注釈

すべてのホストではなく特定のホストをアップグレードする必要がある場合は、アップグレードを限定 することができます。これは、コンポーネント間で負荷分散が行われている場合に有効です。このような場合、負荷分散プールから対象ホストを削除し、アップグレードしてからプールに戻します。これにより、トラフィックが中断されなくなります。特定の 1 つ以上のホストにアップグレードを限定するには、次のコマンドを入力します。

ansible-playbook -i /path/to/hosts.yml all.yml \
  --tags <component> \
  --limit "<host1>,<host2>"

他のコンポーネントをアップデートするには、以下の各コマンドを使用します。

• Schema Registry

  ansible-playbook -i /path/to/hosts.yml all.yml --tags schema_registry
  

• Connect

  ansible-playbook -i /path/to/hosts.yml all.yml --tags kafka_connect
  

• ksqlDB

  ansible-playbook -i /path/to/hosts.yml all.yml --tags ksql
  

• REST Proxy

  ansible-playbook -i /path/to/hosts.yml all.yml --tags kafka_rest
  

• Confluent Control Center

  ansible-playbook -i /path/to/hosts.yml all.yml --tags control_center
  

ステップ 6: クライアントのアップグレード

Confluent Platform 用の Ansible Playbook では現在のところ、クライアントのアップグレードをサポートしていません。詳しくは、 Confluent Platform のアップグレードの準備 を参照してください。

ステップ 7: Kafka のログフォーマットのアップデート

該当するすべてのクライアントがアップデートされたら、log.message.format.version プロパティのインベントリ変数をアップデートします。

kafka_broker_custom_properties:
  inter.broker.protocol.version: 3.0
  log.message.format.version: 3.0

さらに、もう一度プロビジョニングプレイブックを実行します。

ansible-playbook -i /path/to/hosts.yml all.yml --tags kafka_broker \
  --skip-tags package

併置されている Confluent Platform コンポーネントのアップグレード

Confluent Platform サービスが併置され、インストール方法がパッケージに設定されている場合は、アップグレードプロセスによってホストの状態が不安定になる可能性があります。これは、すべての Confluent コンポーネントが同じパッケージを共有しているためです。たとえば、ZooKeeper と Kafka が同じホストで実行されている場合に ZooKeeper をアップグレードすると、Kafka が依存するバイナリと JAR（JAR ファイルなど）が、サービスの実行中にアップグレード/置換されます。

このセクションでは、併置された Kafka および ZooKeeper のインストールを手動でアップグレードする方法について説明します。このプロセスは、他の Confluent Platform コンポーネントの併置にも適用できます。

注釈

このアップグレード方法は、同じホスト上で複数の Confluent Platform コンポーネントが実行されている installation_method: package のみに適用されます。

ステップ 1: 各 Kafka ホストでの broker_id 変数の設定

各 kafka_broker ホストに broker_id 変数が設定されていることを確認します。以下に例を示します。

kafka_broker:
  hosts:
    ip-172-31-34-246.us-east-2.compute.internal:
      broker_id: 0
    ip-172-31-34-247.us-east-2.compute.internal:
      broker_id: 1
    ip-172-31-34-248.us-east-2.compute.internal:
      broker_id: 2

各 kafka_broker ホストで broker_id 変数が設定されていない場合は、以下のコマンドを使用して、Kafka ホスト上にある meta.properties ファイルを照会します。ログディレクトリをカスタマイズした場合は、/var/lib/kafka/data/ を log.dirs プロパティ値に置き換えます。

ansible -i /path/to/hosts.yml \
  -m shell \
  -a "grep broker.id /var/lib/kafka/data/meta.properties" \
  kafka_broker

以下のような出力で、該当する broker.id 値を取得します。

ip-172-31-34-247.us-east-2.compute.internal | CHANGED | rc=0 >>
broker.id=2
ip-172-31-34-246.us-east-2.compute.internal | CHANGED | rc=0 >>
broker.id=1
ip-172-31-34-248.us-east-2.compute.internal | CHANGED | rc=0 >>
broker.id=3

ステップ 2: Kafka コントローラーと ZooKeeper リーダーの確認

アップグレードプロセスの最後に、Kafka コントローラーと ZooKeeper リーダーをアップグレードする必要があります。

Kafka コントローラーに対するクエリを実行するには、次のコマンドを実行します。

• Ansible 2.11 以降を使用する場合

  ansible -i /path/to/hosts.yml kafka_broker \
    -m import_role \
    -a "name=confluent.platform.kafka_broker tasks_from=dynamic_groups.yml"
  

• Ansible 2.9 または 2.10 を使用する場合

  ansible -i /path/to/hosts.yml kafka_broker \
    -m import_role \
    -a "name=confluent.kafka_broker tasks_from=dynamic_groups.yml"
  

以下のサンプル出力で、コントローラーは host: ip-172-31-34-246.us-east-2.compute.internal です。

ip-172-31-34-246.us-east-2.compute.internal | SUCCESS => {
    "msg": "Broker ID: 1 and Controller ID: 1"
}
ip-172-31-34-247.us-east-2.compute.internal | SUCCESS => {
    "msg": "Broker ID: 2 and Controller ID: 1"
}
ip-172-31-34-248.us-east-2.compute.internal | SUCCESS => {
    "msg": "Broker ID: 3 and Controller ID: 1"
}

ZooKeeper リーダーに対するクエリを実行するには、次のコマンドを実行します。

• Ansible 2.11 以降を使用する場合

  ansible -i /path/to/hosts.yml zookeeper \
    -m import_role \
    -a "name=confluent.platform.zookeeper tasks_from=dynamic_groups.yml"
  

• Ansible 2.9 または 2.10 を使用する場合

  ansible -i /path/to/hosts.yml zookeeper \
    -m import_role \
    -a "name=confluent.zookeeper tasks_from=dynamic_groups.yml"
  

以下のサンプル出力で、リーダーは host: ip-172-31-34-248.us-east-2.compute.internal です。

ip-172-31-34-247.us-east-2.compute.internal | SUCCESS => {
    "msg": "Mode: follower"
}
ip-172-31-34-246.us-east-2.compute.internal | SUCCESS => {
    "msg": "Mode: follower"
}
ip-172-31-34-248.us-east-2.compute.internal | SUCCESS => {
    "msg": "Mode: leader"
}

ステップ 3: 制限を使用したアップグレード

Ansible の制限 を使用すると、特定のホスト上のすべての Confluent Platform コンポーネントをアップグレードできます。

最初のステップで検出されたホストを使用して、Kafka コントローラーまたは ZooKeeper リーダーではないホストを選択し、以下のステップに従います。

1. 「ステップ 4: Kafka のアップグレード」の説明に従って、inter.broker.protocol.version プロパティおよび log.message.format.version プロパティを設定します。

2. ホスト上のすべての Confluent サービスを停止します。以下に例を示します。

   ansible -i /path/to/hosts.yml \
     -m shell \
     -a "systemctl stop confluent-*" \
     ip-172-31-34-247.us-east-2.compute.internal
   

3. ホスト上のすべての Confluent コンポーネントをアップグレードして起動します。

   Ansible 2.11 以降を使用する場合の例

   ansible-playbook \
     -i /path/to/hosts.yml confluent.platform.all \
     --limit ip-172-31-34-247.us-east-2.compute.internal
   

   Ansible 2.9 または 2.10 を使用する場合の例

   ansible-playbook \
     -i /path/to/hosts.yml \
     all.yml \
     --limit ip-172-31-34-247.us-east-2.compute.internal
   

ステップ 4: 残りのホストで反復

以下について、ステップ 3 のタスクを反復します。

1. 併置されている残りのホスト。
2. ZooKeeper リーダー。
3. Kafka コントローラー。

重要

Kafka コントローラーは最後にアップグレードし、ZooKeeper リーダーを最後から 2 番目にアップグレードする必要があります。