インストール後の Confluent Platform の再構成¶
Ansible Playbooks for Confluent Platform を使用すると、最新のインベントリファイルでプロビジョニングプレイブックを再実行することにより、Confluent Platform コンポーネントの構成をアップデートできます。
デプロイ戦略には、ローリングと並列の 2 種類があります。並列は、実行中のクラスターに対する再デプロイのデフォルトモードです。
並列デプロイ¶
並列デプロイのデプロイ手順は、コンポーネント内のすべてのノードで一度に実行します。この方法では時間を節約できますが、サービス全体で同時に再起動する必要が生じる可能性があります。
ローリングデプロイは、これより影響が少なく、サービスの中断が生じないため、通常はこちらのオプションを選ぶ方が安全ですが、すべてのユースケースに適合するとは限りません。認証を例にとると、最初のノードは認証メカニズムがアップデートされた状態で再起動されますが、これはクラスターの他の部分に対して無効になります。このように、ローリング再デプロイは認証や暗号化の大幅な変更には適合しません。
以下のような再構成のユースケースについては、並列再デプロイによる処理が最も適切です。
- 認証関連の大幅な変更
- 新しい CA または中間 CA によって署名された証明書のアップデート
- RBAC の有効化
ローリングデプロイ¶
ローリングデプロイでは、1 つのノードについて再構成、再デプロイ、正常性の確認を行ってから次のノードに移動します。特定のノードでデプロイに失敗した場合はプレイブックが停止し、残りのすべてのノードについては変更されずに従来の構成が維持されます。
以下のような再構成については、ローリングデプロイによる処理が最も適切です。
- Kafka プロパティ
`log.retention.hours
などの単純なプロパティアップデート - Java 引数のアップデート
- 環境変数のアップデート
- 同じ CA または中間 CA によって署名された証明書のアップデート
ローリングデプロイモードを有効にするには、以下の変数を設定します。
deployment_strategy: rolling
または、ローリングデプロイモードを使用する特定のコンポーネントを選択するには、以下の変数を設定します。
zookeeper_deployment_strategy: rolling
kafka_broker_deployment_strategy: rolling
再構成に使用するその他の変数とタグ¶
各ノードが正常性の確認に合格した後に cp-ansible
を一時停止するには、以下の変数を true
に設定します。Ansible 出力ログが停止され、ユーザー入力が再開するまで待機状態になります。これは、各ノードで手動の検証を追加で実行する場合に役立ちます。
pause_rolling_deployment: true
一時停止するコンポーネントを指定するには、<component>_pause_rolling_deployment
を true
に設定します。以下に例を示します。
zookeeper_pause_rolling_deployment: true
kafka_broker_pause_rolling_deployment: true
Ansible タグ package
がパッケージインストールタスクに追加されています。アップグレードが発生しないように、これらのタスクは省略することを強くお勧めします。これらを省略すると、時間の節約にもなります。省略するには、以下の引数を Ansible コマンドに追加します。
--skip-tags package
Confluent Platform の構成のアップデート¶
アップデートを続行する前に、Git などのバージョン管理システムで既存のインベントリファイルのバックアップを作成します。これにより、再構成が失敗した場合は、以前の構成にロールバックできます。
インベントリファイルをアップデートして、クラスターに必要なプロパティの変更を反映します。
プロビジョニングプレイブックを実行します。
Ansible 2.11 以降を使用している場合
ローリングデプロイの場合は、以下を実行します。
ansible-playbook -i hosts.yml confluent.platform.all \ --skip-tags package \ --extra-vars deployment_strategy=rolling
--extra-vars
引数を指定すると、インベントリファイルの変数が上書きされます。並列デプロイの場合は、以下を実行します。
ansible-playbook -i hosts.yml confluent.platform.all \ --skip-tags package
Ansible 2.9 または 2.10 を使用している場合
ローリングデプロイの場合は、以下を実行します。
ansible-playbook -i hosts.yml all.yml \ --skip-tags package \ --extra-vars deployment_strategy=rolling
--extra-vars
引数を指定すると、インベントリファイルの変数が上書きされます。並列デプロイの場合は、以下を実行します。
ansible-playbook -i hosts.yml all.yml \ --skip-tags package
エラー処理¶
構成のアップデートが失敗した場合に使用できるオプションには、以下のものがあります。
多くの Confluent Platform コンポーネント(特に Kafka)で、単一ノードの停止を処理できることに注意してください。
Ansible 2.11 以降を使用する場合¶
特定のノードでデプロイに失敗した場合に、そのノードをロールバックするには、インベントリファイルを元に戻し、ノードに再デプロイします。
# Revert your inventory file and run the following command. ansible-playbook -i hosts.yml confluent.platform.all \ --skip-tags package \ --limit <broken-node>
問題が発生したノードで新しい構成を試します。インベントリファイルをもう一度アップデートし、そのノードに再デプロイします。
# Update your inventory file and run the following command. ansible-playbook -i hosts.yml confluent.platform.all \ --skip-tags package \ --limit <broken-node> # Now deploy against all nodes. ansible-playbook -i hosts.yml confluent.platform.all \ --skip-tags package
変更を反映するために並列再起動が必要な場合(たとえば、RBAC を有効にする場合)は、以下のコマンドを入力します。
ansible-playbook -i hosts.yml confluent.platform.all \ --skip-tags package \ -e deployment_strategy=parallel
Ansible 2.9 または 2.10 を使用する場合¶
特定のノードでデプロイに失敗した場合に、そのノードをロールバックするには、インベントリファイルを元に戻し、ノードに再デプロイします。
# Revert your inventory file and run the following command. ansible-playbook -i hosts.yml all.yml \ --skip-tags package \ --limit <broken-node>
問題が発生したノードで新しい構成を試します。インベントリファイルをもう一度アップデートし、そのノードに再デプロイします。
# Update your inventory file and run the following command. ansible-playbook -i hosts.yml all.yml \ --skip-tags package \ --limit <broken-node> # Now deploy against all nodes. ansible-playbook -i hosts.yml all.yml \ --skip-tags package
変更を反映するために並列再起動が必要な場合(たとえば、RBAC を有効にする場合)は、以下のコマンドを入力します。
ansible-playbook -i hosts.yml all.yml \ --skip-tags package \ -e deployment_strategy=parallel