第2章 AMQ Streams の使用

AMQ Streams は、パブリックおよびプライベートクラウドからデプロイメントを目的とするローカルデプロイメントまで、ディストリビューションに関係なくすべてのタイプの OpenShift クラスターで動作するよう設計されています。

AMQ Streams は Strimzi 0.18.x をベースとしています。ここでは、OpenShift 3.11 以降に AMQ Streams をデプロイする方法を説明します。

注記

本ガイドのコマンドを実行するには、クラスターユーザーに RBAC (ロールベースアクセス制御) および CRD を管理する権限を付与する必要があります。

2.1. AMQ Streams デプロイメントの準備

ここでは、AMQ Streams デプロイメントを準備する方法を説明します。

注記

本ガイドのコマンドを実行するには、クラスターユーザーに RBAC (ロールベースアクセス制御) および CRD を管理する権限を付与する必要があります。

2.1.1. デプロイメントの前提条件

AMQ Streams のデプロイする場合、以下を確認してください。

  • OpenShift 3.11 以降のクラスターが利用できること。

    AMQ Streams は AMQ Streams Strimzi 0.18.x をベースとしています。

  • oc コマンドラインツールがインストールされ、稼働中のクラスターに接続するように設定されていること。
注記

AMQ Streams は、OpenShift 固有の一部機能をサポートします。そのようなインテグレーションは OpenShift ユーザーに有用で、標準の OpenShift を使用した同等の実装はありません。

2.1.2. AMQ Streams リリースアーティファクト

AMQ Streams をインストールするには、AMQ Streams のダウンロードページ から amq-streams-<version>-ocp-install-examples.zip ファイルをダウンロードし、リリースアーティファクトを展開します。

AMQ Streams のリリースアーティファクトには、YAML ファイルが含まれています。これらのファイルは、AMQ Streams コンポーネントの OpenShift へのデプロイ、共通の操作の実行、および Kafka クラスターの設定に便利です。

oc コマンドラインツールを使用して、AMQ Streams と OpenShift クラスターにデプロイします。

注記

AMQ Streams コンテナーイメージは、Red Hat Ecosystem Catalog から使用することもできます。しかし、提供される YAML ファイルを使用して AMQ Streams をデプロイすることが推奨されます。

2.1.3. コンテナーイメージを独自のレジストリーにプッシュ

AMQ Streams のコンテナーイメージは Red Hat Ecosystem Catalog にあります。AMQ Streams によって提供されるインストール YAML ファイルは、直接 Red Hat Ecosystem Catalog からイメージをプルします。

Red Hat Ecosystem Catalog にアクセスできない場合や独自のコンテナーリポジトリーを使用する場合は以下を行います。

  1. リストにある すべての コンテナーイメージをプルします。
  2. 独自のレジストリーにプッシュします。
  3. インストール YAML ファイルのイメージ名を更新します。
注記

リリースに対してサポートされる各 Kafka バージョンには別のイメージがあります。

コンテナーイメージnamespace/リポジトリー説明

Kafka

  • registry.redhat.io/amq7/amq-streams-kafka-25-rhel7:1.5.0
  • registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.5.0

次を含む、Kafka を実行するための AMQ Streams イメージ。

  • Kafka Broker
  • Kafka Connect / S2I
  • Kafka Mirror Maker
  • ZooKeeper 3.5.7
  • TLS Sidecars

Operator

  • registry.redhat.io/amq7/amq-streams-rhel7-operator:1.5.0

Operator を実行するための AMQ Streams イメージ。

  • Cluster Operator
  • Topic Operator
  • User Operator
  • Kafka Initializer

Kafka Bridge

  • registry.redhat.io/amq7/amq-streams-bridge-rhel7:1.5.0

AMQ Streams Kafka Bridge を稼働するための AMQ Streams イメージ

2.1.4. AMQ Streams の管理者の指名

AMQ Streams では、デプロイメントの設定にカスタムリソースが提供されます。デフォルトでは、これらのリソースを表示、作成、編集、および削除する権限は OpenShift クラスター管理者に制限されます。AMQ Streams には、このような権限を他のユーザーに割り当てするために使用する 2 つのクラスターロールがあります。

  • strimzi-view ロールを指定すると、ユーザーは AMQ Streams リソースを表示できます。
  • strimzi-admin ロールを指定すると、ユーザーは AMQ Streams リソースを作成、編集、または削除することもできます。

これらのロールをインストールすると、これらの権限が自動的にデフォルトの OpenShift クラスターロールに集約 (追加) されます。strimzi-viewview ロールに集約され、strimzi-adminedit および admin ロールに集約されます。集約により、これらのロールを同様の権限を持つユーザーに割り当てする必要がない可能性があります。

以下の手順では、クラスター管理者でないユーザーが AMQ Streams リソースを管理できるようにする strimzi-admin ロールの割り当て方法を説明します。

システム管理者は、Cluster Operator のデプロイ後に AMQ Streams の管理者を指名できます。

前提条件

手順

  1. OpenShift で strimzi-view および strimzi-admin クラスターロールを作成します。

    oc apply -f install/strimzi-admin
  2. 必要な場合は、ユーザーに必要なアクセス権限を付与するロールを割り当てます。

    oc create clusterrolebinding strimzi-admin --clusterrole=strimzi-admin --user=user1 --user=user2

2.1.5. AMQ Streams のインストール方法

AMQ Streams を OpenShift にインストールする方法は 2 つあります。

インストール方法説明サポート対象バージョン

インストールアーティファクト (YAML ファイル)

AMQ Streams のダウンロードサイト から amq-streams-x.y.z-ocp-install-examples.zip ファイルをダウンロードします。次に、ocを使用して YAML インストールアーティファクトを OpenShift クラスターにデプロイします。最初に、Cluster Operator を install/cluster-operator から単一、複数、またはすべての namespace にデプロイします。

OpenShift 3.11 以上

OperatorHub

OperatorHub で AMQ Streams Operator を使用し、Cluster Operator を単一またはすべての namespace にデプロイします。

OpenShift 4.x のみ

柔軟性が重要な場合は、インストールアーティファクトによる方法を選択します。OpenShift 4 Web コンソールを使用して標準設定で AMQ Streams を OpenShift 4 にインストールする場合は、OperatorHub による方法を選択します。OperatorHub を使用すると、自動更新も利用できます。

どちらの方法でも、Cluster Operator は OpenShift クラスターにデプロイされ、提供される YAML サンプルファイルを使用して、Kafka クラスターから順に AMQ Streams の他のコンポーネントをデプロイする準備が整います。

AMQ Streams インストールアーティファクト

AMQ Streams インストールアーティファクトには、OpenShift にデプロイできるさまざまな YAML ファイルが含まれ、oc 使用して以下を含むカスタムリソースが作成されます。

  • デプロイメント
  • Custom Resource Definition (CRD)
  • ロールおよびロールバインディング
  • サービスアカウント

YAML インストールファイルは、Cluster Operator、Topic Operator、User Operator、および Strimzi Admin ロールに提供されます。

OperatorHub

OpenShift 4 では、Operator Lifecycle Manager (OLM) を使用することにより、クラスター管理者はクラスター全体で実行されるすべての Operator やそれらの関連サービスをインストール、更新、および管理できます。OLM は、Kubernetes のネイティブアプリケーション (Operator) を効率的に自動化された拡張可能な方法で管理するために設計されたオープンソースツールキットの Operator Framework の一部です。

OperatorHub は OpenShift 4 Web コンソールの一部です。クラスター管理者はこれを使用して Operator を検出、インストール、およびアップグレードできます。Operator は OperatorHub からプルでき、単一の (プロジェクト) namespace またはすべての (プロジェクト) namespace への OpenShift クラスターにインストールできます。Operator は OLM で管理できます。エンジニアリングチームは OLM を使用して、独自に開発、テスト、および本番環境でソフトウェアを管理できます。

注記

OperatorHub は、バージョン 4 未満の OpenShift では使用できません。

AMQ Streams Operator

AMQ Streams Operator は OperatorHub からインストールできます。AMQ Streams Operator のインストール後、必要な CRD およびロールベースアクセス制御 (RBAC) リソースと共に Cluster Operator が OpenShift クラスターにデプロイされます。

その他のリソース

インストールアーティファクトを使用した AMQ Streams のインストール:

OperatorHub からの AMQ Streams のインストール:

2.2. Kafka クラスターの作成

Kafka クラスターを作成するには、Cluster Operator をデプロイして Kafka クラスターを管理し、Kafka クラスターをデプロイします。

Kafka リソースを使用して Kafka クラスターをデプロイするときに、Topic Operator および User Operator を同時にデプロイできます。この代わりに、AMQ Streams ではない Kafka クラスターを使用している場合は、Topic Operator および User Operator をスタンドアロンコンポーネントとしてデプロイすることもできます。

Kafka クラスターを Topic Operator および User Operator とデプロイ

AMQ Streams によって管理される Kafka クラスターを Topic Operator および User Operator と使用する場合は、このデプロイメント手順を実行します。

  1. Cluster Operator をデプロイします
  2. Cluster Operator を使用して以下をデプロイします。

スタンドアロン Topic Operator および User Operator のデプロイ

AMQ Streams によって管理されない Kafka クラスターを Topic Operator および User Operator と使用する場合は、このデプロイメント手順を実行します。

2.2.1. Cluster Operator のデプロイ

Cluster Operator は、OpenShift クラスター内で Apache Kafka クラスターのデプロイおよび管理を行います。

本セクションの手順は以下を説明します。

2.2.1.1. Cluster Operator デプロイメントの監視オプション

Cluster Operator の稼働中に、Kafka リソースの更新に対する監視が開始されます。

Cluster Operator をデプロイして、以下からの Kafka リソースの監視を選択できます。

  • 単一の namespace (Cluster Operator が含まれる同じ namespace)
  • 複数の namespace
  • すべての namespace
注記

AMQ Streams では、デプロイメントの処理を簡単にするため、YAML ファイルのサンプルが提供されます。

Cluster Operator では、以下のリソースの変更が監視されます。

  • Kafka クラスターの Kafka
  • KafkaConnect の Kafka Connect クラスター。
  • Source2Image がサポートされる Kafka Connect クラスターの KafkaConnectS2I
  • Kafka Connect クラスターでコネクターを作成および管理するための KafkaConnector
  • Kafka MirrorMaker インスタンスの KafkaMirrorMaker
  • Kafka Bridge インスタンスの KafkaBridge

OpenShift クラスターでこれらのリソースの 1 つが作成されると、Operator によってクラスターの詳細がリソースより取得されます。さらに、StatefulSet、Service、および ConfigMap などの必要な OpenShift リソースが作成され、リソースの新しいクラスターの作成が開始されます。

Kafka リソースが更新されるたびに、リソースのクラスターを構成する OpenShift リソースで該当する更新が Operator によって実行されます。

クラスターの望ましい状態がリソースのクラスターに反映されるようにするため、リソースへのパッチ適用後またはリソースの削除後にリソースが再作成されます。この操作は、サービスの中断を引き起こすローリングアップデートの原因となる可能性があります。

リソースが削除されると、Operator によってクラスターがアンデプロイされ、関連する OpenShift リソースがすべて削除されます。

2.2.1.2. 単一の namespace を監視対象とする Cluster Operator のデプロイメント

この手順では、OpenShift クラスターの単一の namespace で AMQ Streams リソースを監視するように Cluster Operator をデプロイする方法を説明します。

前提条件

  • この手順では、CustomResourceDefinitionsClusterRoles、および ClusterRoleBindings を作成できる OpenShift ユーザーアカウントを使用する必要があります。通常、OpenShift クラスターでロールベースアクセス制御 (RBAC) を使用する場合、これらのリソースを作成、編集、および削除する権限を持つユーザーは system:admin などの OpenShift クラスター管理者に限定されます。

手順

  1. Cluster Operator がインストールされる namespace を使用するように、AMQ Streams のインストールファイルを編集します。

    たとえば、この手順では Cluster Operator は my-cluster-operator-namespace という namespace にインストールされます。

    Linux の場合は、以下を使用します。

    sed -i 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml

    MacOS の場合は、以下を使用します。

    sed -i '' 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml
  2. Cluster Operator をデプロイします。

    oc apply -f install/cluster-operator -n my-cluster-operator-namespace
  3. Cluster Operator が正常にデプロイされたことを確認します。

    oc get deployments

2.2.1.3. 複数の namespace を監視対象とする Cluster Operator のデプロイメント

この手順では、OpenShift クラスターの複数の namespace 全体で AMQ Streams リソースを監視するように Cluster Operator をデプロイする方法を説明します。

前提条件

  • この手順では、CustomResourceDefinitionsClusterRoles、および ClusterRoleBindings を作成できる OpenShift ユーザーアカウントを使用する必要があります。通常、OpenShift クラスターでロールベースアクセス制御 (RBAC) を使用する場合、これらのリソースを作成、編集、および削除する権限を持つユーザーは system:admin などの OpenShift クラスター管理者に限定されます。

手順

  1. Cluster Operator がインストールされる namespace を使用するように、AMQ Streams のインストールファイルを編集します。

    たとえば、この手順では Cluster Operator は my-cluster-operator-namespace という namespace にインストールされます。

    Linux の場合は、以下を使用します。

    sed -i 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml

    MacOS の場合は、以下を使用します。

    sed -i '' 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml
  2. install/cluster-operator/050-Deployment-strimzi-cluster-operator.yaml ファイルを編集し、Cluster Operator によって監視されるすべての namespace のリストを STRIMZI_NAMESPACE 環境変数に追加します。

    たとえば、この手順では Cluster Operator は watched-namespace-1watched-namespace-2、および watched-namespace-3 という namespace を監視します。

    apiVersion: apps/v1
    kind: Deployment
    spec:
      # ...
      template:
        spec:
          serviceAccountName: strimzi-cluster-operator
          containers:
          - name: strimzi-cluster-operator
            image: registry.redhat.io/amq7/amq-streams-rhel7-operator:1.5.0
            imagePullPolicy: IfNotPresent
            env:
            - name: STRIMZI_NAMESPACE
              value: watched-namespace-1,watched-namespace-2,watched-namespace-3
  3. リストした各 namespace に RoleBindings をインストールします。

    この例では、コマンドの watched-namespace を前述のステップでリストした namespace に置き換えます。watched-namespace-1watched-namespace-2、および watched-namespace-3 に対してこれを行います。

    oc apply -f install/cluster-operator/020-RoleBinding-strimzi-cluster-operator.yaml -n watched-namespace
    oc apply -f install/cluster-operator/031-RoleBinding-strimzi-cluster-operator-entity-operator-delegation.yaml -n watched-namespace
    oc apply -f install/cluster-operator/032-RoleBinding-strimzi-cluster-operator-topic-operator-delegation.yaml -n watched-namespace
  4. Cluster Operator をデプロイします。

    oc apply -f install/cluster-operator -n my-cluster-operator-namespace
  5. Cluster Operator が正常にデプロイされたことを確認します。

    oc get deployments

2.2.1.4. すべての namespace を対象とする Cluster Operator のデプロイメント

この手順では、OpenShift クラスターのすべての namespace 全体で AMQ Streams リソースを監視するように Cluster Operator をデプロイする方法を説明します。

このモードで実行している場合、Cluster Operator によって、新規作成された namespace でクラスターが自動的に管理されます。

前提条件

  • この手順では、CustomResourceDefinitionsClusterRoles、および ClusterRoleBindings を作成できる OpenShift ユーザーアカウントを使用する必要があります。通常、OpenShift クラスターでロールベースアクセス制御 (RBAC) を使用する場合、これらのリソースを作成、編集、および削除する権限を持つユーザーは system:admin などの OpenShift クラスター管理者に限定されます。

手順

  1. Cluster Operator がインストールされる namespace を使用するように、AMQ Streams のインストールファイルを編集します。

    たとえば、この手順では Cluster Operator は my-cluster-operator-namespace という namespace にインストールされます。

    Linux の場合は、以下を使用します。

    sed -i 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml

    MacOS の場合は、以下を使用します。

    sed -i '' 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml
  2. install/cluster-operator/050-Deployment-strimzi-cluster-operator.yaml ファイルを編集し、STRIMZI_NAMESPACE 環境変数の値を * に設定します。

    apiVersion: apps/v1
    kind: Deployment
    spec:
      # ...
      template:
        spec:
          # ...
          serviceAccountName: strimzi-cluster-operator
          containers:
          - name: strimzi-cluster-operator
            image: registry.redhat.io/amq7/amq-streams-rhel7-operator:1.5.0
            imagePullPolicy: IfNotPresent
            env:
            - name: STRIMZI_NAMESPACE
              value: "*"
            # ...
  3. クラスター全体ですべての namespace にアクセスできる権限を Cluster Operator に付与する ClusterRoleBindings を作成します。

    oc create clusterrolebinding strimzi-cluster-operator-namespaced --clusterrole=strimzi-cluster-operator-namespaced --serviceaccount my-cluster-operator-namespace:strimzi-cluster-operator
    oc create clusterrolebinding strimzi-cluster-operator-entity-operator-delegation --clusterrole=strimzi-entity-operator --serviceaccount my-cluster-operator-namespace:strimzi-cluster-operator
    oc create clusterrolebinding strimzi-cluster-operator-topic-operator-delegation --clusterrole=strimzi-topic-operator --serviceaccount my-cluster-operator-namespace:strimzi-cluster-operator

    my-cluster-operator-namespace は、Cluster Operator をインストールする namespace に置き換えます。

  4. Cluster Operator を OpenShift クラスターにデプロイします。

    oc apply -f install/cluster-operator -n my-cluster-operator-namespace
  5. Cluster Operator が正常にデプロイされたことを確認します。

    oc get deployments

2.2.1.5. OperatorHub からの Cluster Operator のデプロイ

OperatorHub から AMQ Streams Operator をインストールして、Cluster Operator を OpenShift クラスターにデプロイできます。OperatorHub は OpenShift 4 のみで使用できます

前提条件

  • Red Hat OperatorOperatorSource が OpenShift クラスターで有効になっている必要があります。適切な OperatorSource が有効になっていれば OperatorHub に Red Hat Operator が表示されます。詳細は、『Operator』を参照してください。
  • インストールには、Operator を OperatorHub からインストールするための権限を持つユーザーが必要です

手順

  1. OpenShift 4 Web コンソールで、Operators > OperatorHub をクリックします。
  2. Streaming & Messaging カテゴリーの AMQ Streams Operator を検索または閲覧します。

    Image: The AMQ Streams Operator in the OperatorHub in OpenShift 4
  3. AMQ Streams タイルをクリックし、右側のサイドバーで Install をクリックします。
  4. Create Operator Subscription 画面で、以下のインストールおよび更新オプションから選択します。

    • Installation Mode: AMQ Streams Operator をクラスターのすべての (プロジェクト) namespace にインストール (デフォルト) するか、特定の (プロジェクト) namespace インストールするかを選択します。namespace を使用して関数を分離することが推奨されます。特定の namespace を Kafka クラスターおよびその他の AMQ Streams コンポーネントの専用とすることが推奨されます。
    • Approval Strategy: デフォルトでは、OLM (Operator Lifecycle Manager) によって、AMQ Streams Operator が自動的に最新の AMQ Streams バージョンにアップグレードされます。今後のアップグレードを手動で承認する場合は、Manual を選択します。詳細は、OpenShift ドキュメントの『Operator』を参照してください。
  5. Subscribe をクリックすると、AMQ Streams Operator が OpenShift クラスターにインストールされます。

    AMQ Streams Operator によって、Cluster Operator、CRD、およびロールベースアクセス制御 (RBAC) リソースは選択された namespace またはすべての namespace にデプロイされます。

  6. Installed Operators 画面で、インストールの進捗を確認します。AMQ Streams Operator は、ステータスが InstallSucceeded に変更されると使用できます。

    Installed Operators in OpenShift 4

次に、YAML サンプルファイルを使用して、Kafka クラスターから順に AMQ Streams の他のコンポーネントをデプロイできます。

2.2.2. Kafka のデプロイ

Apache Kafka は、耐障害性のリアルタイムデータフィードを実現する、オープンソースの分散型 publish/subscribe メッセージングシステムです。

本セクションの手順は以下を説明します。

Kafka をインストールする場合、AMQ Streams によって ZooKeeper クラスターもインストールされ、Kafka と ZooKeeper との接続に必要な設定が追加されます。

2.2.2.1. Kafka クラスターのデプロイメント

この手順では、Cluster Operator を使用して Kafka クラスターを OpenShift にデプロイする方法を説明します。

デプロイメントでは、YAML ファイルの仕様を使って Kafka リソースが作成されます。

AMQ Streams では、デプロイメントの YAML ファイルのサンプルは examples/kafka/ にあります。

kafka-persistent.yaml
3 つの Zookeeper ノードと 3 つの Kafka ノードを使用して永続クラスターをデプロイします。
kafka-jbod.yaml
それぞれが複数の永続ボリューを使用する、3 つの ZooKeeper ノードと 3 つの Kafka ノードを使用して、永続クラスターをデプロイします。
kafka-persistent-single.yaml
1 つの ZooKeeper ノードと 1 つの Kafka ノードを使用して、永続クラスターをデプロイします。
kafka-ephemeral.yaml
3 つの ZooKeeper ノードと 3 つの Kafka ノードを使用して、一時クラスターをデプロイします。
kafka-ephemeral-single.yaml
3 つの ZooKeeper ノードと 1 つの Kafka ノードを使用して、一時クラスターをデプロイします。

この手順では、一時 および 永続 Kafka クラスターデプロイメントの例を使用します。

一時クラスター
通常、Kafka の一時クラスターは開発およびテスト環境での使用に適していますが、本番環境での使用には適していません。このデプロイメントでは、ブローカー情報 (ZooKeeper) と、トピックまたはパーティション (Kafka) を格納するための emptyDir ボリュームが使用されます。emptyDir ボリュームを使用すると、その内容は厳密に Pod のライフサイクルと関連し、Pod がダウンすると削除されます。
永続クラスター
Kafka の永続クラスターでは、PersistentVolumes を使用して ZooKeeper および Kafka データを格納します。PersistentVolumeClaim を使用して PersistentVolume が取得され、PersistentVolume の実際のタイプには依存しません。たとえば、YAML ファイルを変更しなくても Amazon AWS デプロイメントで Amazon EBS ボリュームを使用できます。PersistentVolumeClaimStorageClass を使用し、自動ボリュームプロビジョニングをトリガーすることができます。

サンプルクラスターの名前はデフォルトで my-cluster になります。クラスター名はリソースの名前によって定義され、クラスターがデプロイされた後に変更できません。クラスターをデプロイする前にクラスター名を変更するには、関連する YAML ファイルにある Kafka リソースの Kafka.metadata.name プロパティーを編集します。

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
# ...

Kafka リソースの設定に関する詳細は「Kafka クラスターの設定」を参照してください。

手順

  1. 一時 または 永続 クラスターを作成およびデプロイします。

    開発またはテストでは、一時クラスターの使用が適している可能性があります。永続クラスターはどのような状況でも使用することができます。

    • 一時 クラスターを作成およびデプロイするには、以下を実行します。

      oc apply -f examples/kafka/kafka-ephemeral.yaml
    • 永続 クラスターを作成およびデプロイするには、以下を実行します。

      oc apply -f examples/kafka/kafka-persistent.yaml
  2. Kafka クラスターが正常にデプロイされたことを確認します。

    oc get deployments

2.2.2.2. Cluster Operator を使用した Topic Operator のデプロイ

この手順では、Cluster Operator を使用して Topic Operator をデプロイする方法を説明します。

Kafkaリソースの entityOperator プロパティーを設定し、topicOperator が含まれるようにします。

AMQ Streams によって管理されない Kafka クラスターを Topic Operator と使用する場合は、Topic Operator をスタンドアロンコンポーネントとしてデプロイする必要があります。

entityOperator および topicOperator プロパティーの設定に関する詳細は「Entity Operator」を参照してください。

手順

  1. Kafka リソースの entityOperator プロパティーを編集し、topicOperator が含まれるようにします。

    apiVersion: kafka.strimzi.io/v1beta1
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      #...
      entityOperator:
        topicOperator: {}
        userOperator: {}
  2. EntityTopicOperatorSpec スキーマ参照」に記載されているプロパティーを使用して、Topic Operator の spec を設定します。

    すべてのプロパティーにデフォルト値を使用する場合は、空のオブジェクト ({}) を使用します。

  3. リソースを作成または更新します。

    oc apply を使用します。

    oc apply -f <your-file>

2.2.2.3. Cluster Operator を使用した User Operator のデプロイ

この手順では、Cluster Operator を使用して User Operator をデプロイする方法を説明します。

Kafkaリソースの entityOperator プロパティーを設定し、userOperator が含まれるようにします。

AMQ Streams によって管理されない Kafka クラスターを User Operator と使用する場合は、User Operator をスタンドアロンコンポーネントとしてデプロイする必要があります。

entityOperator および userOperator プロパティーの設定に関する詳細は「Entity Operator」を参照してください。

手順

  1. Kafka リソースの entityOperator プロパティーを編集し、userOperator が含まれるようにします。

    apiVersion: kafka.strimzi.io/v1beta1
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      #...
      entityOperator:
        topicOperator: {}
        userOperator: {}
  2. EntityUserOperatorSpec スキーマ参照」に記載されているプロパティーを使用して、User Operator の spec を設定します。

    すべてのプロパティーにデフォルト値を使用する場合は、空のオブジェクト ({}) を使用します。

  3. リソースを作成または更新します。

    oc apply -f <your-file>

2.2.3. AMQ Streams Operator の代替のスタンドアロンデプロイメントオプション

Cluster Operator を使用して Kafka クラスターをデプロイするときに、Topic Operator および User Operator をデプロイすることもできます。この代わりに、スタンドアロンデプロイメントを行うことができます。

スタンドアロンデプロイメントとは、Topic Operator および User Operator が AMQ Streams によって管理されない Kafka クラスターと操作できることを意味します。

2.2.3.1. スタンドアロン Topic Operator のデプロイ

この手順では、Topic Operator をスタンドアロンコンポーネントとしてデプロイする方法を説明します。

スタンドアロンデプロイメントには、環境変数の設定が必要で、Cluster Operator を使用した Topic Operator のデプロイよりも複雑です。しかし、Topic Operator は Cluster Operator によってデプロイされた Kafka クラスターに限らず、あらゆる Kafka クラスターと操作できるため、スタンドアロンデプロイメントの柔軟性は高くなります。

前提条件

  • Topic Operator が接続する既存の Kafka クラスターが必要です。

手順

  1. 以下を設定して、install/topic-operator/05-Deployment-strimzi-topic-operator.yaml ファイルの Deployment.spec.template.spec.containers[0].env プロパティーを編集します。

    1. STRIMZI_KAFKA_BOOTSTRAP_SERVERShostname:‍port ペアのコンマ区切りリストで Kafka クラスターのブートストラップブローカーを指定します。
    2. STRIMZI_ZOOKEEPER_CONNECThostname:‍port ペアのコンマ区切りリストで ZooKeeper ノードを指定します。これは、Kafka クラスターが使用する ZooKeeper クラスターと同じである必要があります。
    3. STRIMZI_NAMESPACE。Operator が KafkaTopic リソースを監視する OpenShift namespace。
    4. STRIMZI_RESOURCE_LABELS。Operator によって管理される KafkaTopic リソースを識別するために使用されるラベルセレクター。
    5. STRIMZI_FULL_RECONCILIATION_INTERVAL_MS。定期的な調整の間隔 (秒単位) を指定します。
    6. STRIMZI_TOPIC_METADATA_MAX_ATTEMPTS。Kafka からトピックメタデータの取得を試行する回数を指定します。各試行の間隔は、指数バックオフとして定義されます。パーティションまたはレプリカの数によって、トピックの作成に時間がかかる可能性がある場合は、この値を増やすことを検討してください。デフォルトは 6 です。
    7. STRIMZI_ZOOKEEPER_SESSION_TIMEOUT_MS。ZooKeeper セッションのタイムアウト (秒単位)。例: 10000デフォルトは 20000 (20 秒) です。
    8. STRIMZI_TOPICS_PATH。Topic Operator がそのメタデータを保存する Zookeeper ノードパス。デフォルトは /strimzi/topics です。
    9. STRIMZI_TLS_ENABLED。Kafka ブローカーとの通信を暗号化するために、TLS サポートを有効にします。デフォルトは true です。
    10. STRIMZI_TRUSTSTORE_LOCATION。TLS ベースの通信を有効にするための証明書が含まれるトラストストアへのパス。TLS が STRIMZI_TLS_ENABLED によって有効化された場合のみ必須です。
    11. STRIMZI_TRUSTSTORE_PASSWORDSTRIMZI_TRUSTSTORE_LOCATION で定義されるトラストストアにアクセスするためのパスワード。TLS が STRIMZI_TLS_ENABLED によって有効化された場合のみ必須です。
    12. STRIMZI_KEYSTORE_LOCATION。TLS ベースの通信を有効にするための秘密鍵が含まれるキーストアへのパス。TLS が STRIMZI_TLS_ENABLED によって有効化された場合のみ必須です。
    13. STRIMZI_KEYSTORE_PASSWORDSTRIMZI_KEYSTORE_LOCATION で定義されるキーストアにアクセスするためのパスワード。TLS が STRIMZI_TLS_ENABLED によって有効化された場合のみ必須です。
    14. STRIMZI_LOG_LEVEL。ロギングメッセージの出力レベル。設定可能な値: ERRORWARNINGINFODEBUG、および TRACEデフォルトは INFO です。
    15. STRIMZI_JAVA_OPTS (任意)。Topic Operator を実行する JVM に使用される Java オプション。例: -Xmx=512M -Xms=256M
    16. STRIMZI_JAVA_SYSTEM_PROPERTIES (任意)。Topic Operator に設定される -D オプションをリストします。例: -Djavax.net.debug=verbose -DpropertyName=value
  2. Topic Operator をデプロイします。

    oc apply -f install/topic-operator
  3. Topic Operator が正常にデプロイされていることを確認します。

    oc describe deployment strimzi-topic-operator

    Replicas: エントリーに 1 available が表示されれば、Topic Operator はデプロイされています。

    注記

    OpenShift への接続が低速な場合やイメージがこれまでダウンロードされたことがない場合は、デプロイメントに遅延が発生することがあります。

2.2.3.2. スタンドアロン User Operator のデプロイ

この手順では、User Operator をスタンドアロンコンポーネントとしてデプロイする方法を説明します。

スタンドアロンデプロイメントには、環境変数の設定が必要で、Cluster Operator を使用した User Operator のデプロイよりも複雑です。しかし、User Operator は Cluster Operator によってデプロイされた Kafka クラスターに限らず、あらゆる Kafka クラスターと操作できるため、スタンドアロンデプロイメントの柔軟性は高くなります。

前提条件

  • User Operator が接続する既存の Kafka クラスターが必要です。

手順

  1. 以下を設定して、install/user-operator/05-Deployment-strimzi-user-operator.yaml ファイルの Deployment.spec.template.spec.containers[0].env プロパティーを編集します。

    1. STRIMZI_KAFKA_BOOTSTRAP_SERVERShostname:‍port ペアのコンマ区切りリストで Kafka ブローカーを指定します。
    2. STRIMZI_ZOOKEEPER_CONNECThostname:‍port ペアのコンマ区切りリストで ZooKeeper ノードを指定します。これは、Kafka クラスターが使用する ZooKeeper クラスターと同じである必要があります。TLS 暗号化で ZooKeeper ノードに接続することはサポートされません。
    3. STRIMZI_NAMESPACE。Operator が KafkaUser リソースを監視する OpenShift namespace。
    4. STRIMZI_LABELS。Operator によって管理される KafkaUser リソースを識別するために使用されるラベルセレクター。
    5. STRIMZI_FULL_RECONCILIATION_INTERVAL_MS。定期的な調整の間隔 (秒単位) を指定します。
    6. STRIMZI_ZOOKEEPER_SESSION_TIMEOUT_MS。ZooKeeper セッションのタイムアウト (秒単位)。例: 10000デフォルトは 20000 (20 秒) です。
    7. STRIMZI_CA_CERT_NAME。TLS クライアント認証に対して新しいユーザー証明書を署名するための認証局の公開鍵が含まれる OpenShift Secret を示します。Secretca.crt キーに、認証局の公開鍵が含まれている必要があります。
    8. STRIMZI_CA_KEY_NAME。TLS クライアント認証に対して新しいユーザー証明書を署名するための認証局の秘密鍵が含まれる OpenShift Secret を示します。Secretca.key キーに、認証局の秘密鍵が含まれている必要があります。
    9. STRIMZI_CLUSTER_CA_CERT_SECRET_NAME。TLS ベースの通信を有効にするために Kafka ブローカーの証明書の署名に使用される認証局の秘密鍵が含まれる OpenShift Secret を示します。Secretca.crt キーに、認証局の公開鍵が含まれている必要があります。この環境変数の設定は任意で、Kafka クラスターとの通信が TLS ベースである場合のみ設定する必要があります。
    10. STRIMZI_EO_KEY_SECRET_NAME。Kafka クラスターに対する TLS クライアント認証の秘密鍵と関連する証明書が含まれる OpenShift Secret を示します。Secretentity-operator.p12 キーに、秘密鍵と証明書が含まれるキーストアが含まれ、entity-operator.password キーに関連するパスワードが含まれる必要があります。この環境変数の設定は任意で、Kafka クラスターとの通信が TLS ベースで、TLS のクライアント認証が必要な場合のみ設定する必要があります。
    11. STRIMZI_CA_VALIDITY。認証局の有効期限。デフォルトは 365 です。
    12. STRIMZI_CA_RENEWAL。認証局の更新期限。
    13. STRIMZI_LOG_LEVEL。ロギングメッセージの出力レベル。設定可能な値: ERRORWARNINGINFODEBUG、および TRACEデフォルトは INFO です。
    14. STRIMZI_GC_LOG_ENABLED。ガベージコレクション (GC) ロギングを有効にします。デフォルトは true です。デフォルトでは、古い証明書が期限切れになる前に証明書が更新される期間は 30 日です。
    15. STRIMZI_JAVA_OPTS (任意)。User Operator を実行する JVM に使用される Java オプション。例: -Xmx=512M -Xms=256M
    16. STRIMZI_JAVA_SYSTEM_PROPERTIES (任意)。User Operator に設定される -D オプションをリストします。例: -Djavax.net.debug=verbose -DpropertyName=value
  2. User Operator をデプロイします。

    oc apply -f install/user-operator
  3. User Operator が正常にデプロイされていることを確認します。

    oc describe deployment strimzi-user-operator

    Replicas: エントリーに 1 available が表示されれば、User Operator はデプロイされています。

    注記

    OpenShift への接続が低速な場合やイメージがこれまでダウンロードされたことがない場合は、デプロイメントに遅延が発生することがあります。

2.3. Kafka Connect のデプロイ

Kafka Connect は、Apache Kafka と外部システムとの間でデータをストリーミングするためのツールです。

AMQ Streams では、Kafka Connect は分散 (distributed) モードでデプロイされます。Kafka Connect はスタンドアロンモードでも動作しますが、AMQ Streams ではサポートされません。

Kafka Connect では、コネクター の概念を使用し、スケーラビリティーと信頼性を維持しながら Kafka クラスターで大量のデータを出し入れするためのフレームワークが提供されます。

Kafka Connect は通常、Kafka を外部データベース、ストレージシステム、およびメッセージングシステムと統合するために使用されます。

本セクションの手順では以下の方法を説明します。

注記

コネクター という用語は、Kafka Connect クラスター内で実行されているコネクターインスタンスや、コネクタークラスと同じ意味で使用されます。本ガイドでは、本文の内容で意味が明確である場合に コネクター という用語を使用します。

2.3.1. Kafka Connect の OpenShift クラスターへのデプロイ

この手順では、Cluster Operator を使用して Kafka Connect クラスターを OpenShift クラスターにデプロイする方法を説明します。

Kafka Connect クラスターは Deployment として実装されます。その Deployment には、コネクターのワークロードを タスク として分布するノード (ワーカー とも呼ばれる) の設定可能な数が含まれるため、メッセージフローのスケーラビリティーや信頼性が高くなります。

デプロイメントでは、YAML ファイルの仕様を使って KafkaConnect リソースが作成されます。

この手順では、AMQ Streams にある以下のサンプルファイルを使用します。

  • examples/connect/kafka-connect.yaml

KafkaConnect リソースの設定に関する詳細は以下を参照してください。

手順

  1. Kafka Connect を OpenShift クラスターにデプロイします。

    oc apply -f examples/connect/kafka-connect.yaml
  2. Kafka Connect が正常にデプロイされたことを確認します。

    oc get deployments

2.3.2. コネクタープラグインでの Kafka Connect の拡張

Kafka Connect の AMQ Streams コンテナーイメージには、ファイルベースのデータを Kafka クラスターで出し入れするために 2 つの組み込みコネクターが含まれています。

ファイルコネクター説明

FileStreamSourceConnector

ファイル (ソース) から Kafka クラスターにデータを転送します。

FileStreamSinkConnector

Kafka クラスターからファイル (シンク) にデータを転送します。

Cluster Operator では、Kafka Connect クラスターを OpenShift クラスターにデプロイするために作成したイメージを使用することもできます。

ここの手順では、以下を行って、独自のコネクタークラスをコネクターイメージに追加する方法を説明します。

重要

Kafka Connect REST API または KafkaConnector カスタムリソースを使用 して直接コネクターの設定を作成します。

2.3.2.1. Kafka Connect ベースイメージからの Docker イメージの作成

この手順では、カスタムイメージを作成し、/opt/kafka/plugins ディレクトリーに追加する方法を説明します。

Red Hat Ecosystem Catalog の Kafka コンテナーイメージを、追加のコネクタープラグインで独自のカスタムイメージを作成するためのベースイメージとして使用できます。

AMQ Stream バージョンの Kafka Connect は起動時に、/opt/kafka/plugins ディレクトリーに含まれるサードパーティーのコネクタープラグインをロードします。

手順

  1. registry.redhat.io/amq7/amq-streams-kafka-25-rhel7:1.5.0 をベースイメージとして使用して、新しい Dockerfile を作成します。

    FROM registry.redhat.io/amq7/amq-streams-kafka-25-rhel7:1.5.0
    USER root:root
    COPY ./my-plugins/ /opt/kafka/plugins/
    USER 1001

    プラグインファイルの例

    $ tree ./my-plugins/
    ./my-plugins/
    ├── debezium-connector-mongodb
    │   ├── bson-3.4.2.jar
    │   ├── CHANGELOG.md
    │   ├── CONTRIBUTE.md
    │   ├── COPYRIGHT.txt
    │   ├── debezium-connector-mongodb-0.7.1.jar
    │   ├── debezium-core-0.7.1.jar
    │   ├── LICENSE.txt
    │   ├── mongodb-driver-3.4.2.jar
    │   ├── mongodb-driver-core-3.4.2.jar
    │   └── README.md
    ├── debezium-connector-mysql
    │   ├── CHANGELOG.md
    │   ├── CONTRIBUTE.md
    │   ├── COPYRIGHT.txt
    │   ├── debezium-connector-mysql-0.7.1.jar
    │   ├── debezium-core-0.7.1.jar
    │   ├── LICENSE.txt
    │   ├── mysql-binlog-connector-java-0.13.0.jar
    │   ├── mysql-connector-java-5.1.40.jar
    │   ├── README.md
    │   └── wkb-1.0.2.jar
    └── debezium-connector-postgres
        ├── CHANGELOG.md
        ├── CONTRIBUTE.md
        ├── COPYRIGHT.txt
        ├── debezium-connector-postgres-0.7.1.jar
        ├── debezium-core-0.7.1.jar
        ├── LICENSE.txt
        ├── postgresql-42.0.0.jar
        ├── protobuf-java-2.6.1.jar
        └── README.md

  2. コンテナーイメージをビルドします。
  3. カスタムイメージをコンテナーレジストリーにプッシュします。
  4. 新しいコンテナーイメージを示します。

    以下のいずれかを行います。

    • KafkaConnect カスタムリソースの KafkaConnect.spec.image プロパティーを編集します。

      設定された場合、このプロパティーによって Cluster Operator の STRIMZI_KAFKA_CONNECT_IMAGES 変数がオーバーライドされます。

      apiVersion: kafka.strimzi.io/v1beta1
      kind: KafkaConnect
      metadata:
        name: my-connect-cluster
      spec: 1
        #...
        image: my-new-container-image 2
        config: 3
          #...
      1
      2
      Pod の Docker イメージ。
      3
      Kafka Connect ワーカー (コネクターではない) の設定。

      または

    • install/cluster-operator/050-Deployment-strimzi-cluster-operator.yaml ファイルの STRIMZI_KAFKA_CONNECT_IMAGES 変数を編集して新しいコンテナーイメージを示すようにした後、Cluster Operator を再インストールします。

その他のリソース

2.3.2.2. OpenShift ビルドおよび S2I (Source-to-Image) を使用したコンテナーイメージの作成

この手順では、OpenShift ビルドS2I (Source-to-Image) フレームワークを使用して、新しいコンテナーイメージを作成する方法を説明します。

OpenShift ビルドは、S2I がサポートされるビルダーイメージとともに、ユーザー提供のソースコードおよびバイナリーを取得し、これらを使用して新しいコンテナーイメージを構築します。構築後、コンテナーイメージは OpenShfit のローカルコンテナーイメージリポジトリーに格納され、デプロイメントで使用可能になります。

S2I がサポートされる Kafka Connect ビルダーイメージは、registry.redhat.io/amq7/amq-streams-kafka-25-rhel7:1.5.0 イメージの一部として、Red Hat Ecosystem Catalog で提供されます。このS2I イメージは、バイナリー (プラグインおよびコネクターとともに) を取得し、/tmp/kafka-plugins/s2i ディレクトリーに格納されます。このディレクトリーから、Kafka Connect デプロイメントとともに使用できる新しい Kafka Connect イメージを作成します。改良されたイメージの使用を開始すると、Kafka Connect は /tmp/kafka-plugins/s2i ディレクトリーからサードパーティープラグインをロードします。

手順

  1. コマンドラインで oc apply コマンドを使用し、Kafka Connect の S2I クラスターを作成およびデプロイします。

    oc apply -f examples/connect/kafka-connect-s2i.yaml
  2. Kafka Connect プラグインでディレクトリーを作成します。

    $ tree ./my-plugins/
    ./my-plugins/
    ├── debezium-connector-mongodb
    │   ├── bson-3.4.2.jar
    │   ├── CHANGELOG.md
    │   ├── CONTRIBUTE.md
    │   ├── COPYRIGHT.txt
    │   ├── debezium-connector-mongodb-0.7.1.jar
    │   ├── debezium-core-0.7.1.jar
    │   ├── LICENSE.txt
    │   ├── mongodb-driver-3.4.2.jar
    │   ├── mongodb-driver-core-3.4.2.jar
    │   └── README.md
    ├── debezium-connector-mysql
    │   ├── CHANGELOG.md
    │   ├── CONTRIBUTE.md
    │   ├── COPYRIGHT.txt
    │   ├── debezium-connector-mysql-0.7.1.jar
    │   ├── debezium-core-0.7.1.jar
    │   ├── LICENSE.txt
    │   ├── mysql-binlog-connector-java-0.13.0.jar
    │   ├── mysql-connector-java-5.1.40.jar
    │   ├── README.md
    │   └── wkb-1.0.2.jar
    └── debezium-connector-postgres
        ├── CHANGELOG.md
        ├── CONTRIBUTE.md
        ├── COPYRIGHT.txt
        ├── debezium-connector-postgres-0.7.1.jar
        ├── debezium-core-0.7.1.jar
        ├── LICENSE.txt
        ├── postgresql-42.0.0.jar
        ├── protobuf-java-2.6.1.jar
        └── README.md
  3. oc start-build コマンドで、準備したディレクトリーを使用してイメージの新しいビルドを開始します。

    oc start-build my-connect-cluster-connect --from-dir ./my-plugins/
    注記

    ビルドの名前は、デプロイされた Kafka Connect クラスターと同じになります。

  4. ビルドが完了したら、Kafka Connect のデプロイメントによって新しいイメージが自動的に使用されます。

2.3.3. コネクターの作成および管理

コネクタープラグインのコンテナーイメージを作成したら、Kafka Connect クラスターにコネクターインスタンスを作成する必要があります。その後、稼働中のコネクターインスタンスを設定、監視、および管理できます。

コネクターは特定の コネクタークラス のインスタンスで、メッセージに関して関連する外部システムとの通信方法を認識しています。コネクターは多くの外部システムで使用でき、独自のコネクターを作成することもできます。

ソース および シンク タイプのコネクターを作成できます。

ファイルコネクター
ソースコネクターは、外部システムからデータを取得し、それをメッセージとして Kafka に提供するランタイムエンティティーです。
シンクコネクター
シンクコネクターは、Kafka トピックからメッセージを取得し、外部システムに提供するランタイムエンティティーです。

AMQ Streams では、コネクターの作成および管理に 2 つの API が提供されます。

  • KafkaConnector リソース (KafkaConnectors と呼ばれます)
  • Kafka Connect REST API

API を使用すると、以下を行うことができます。

  • コネクターインスタンスのステータスの確認。
  • 稼働中のコネクターの再設定。
  • コネクターインスタンスのタスク数の増減。
  • 失敗したタスクの再起動 (KafkaConnector リソースによってサポートされません)。
  • コネクターインスタンスの一時停止。
  • 一時停止したコネクターインスタンスの再開。
  • コネクターインスタンスの削除。

2.3.3.1. KafkaConnector リソース

KafkaConnectors を使用すると、Kafka Connect のコネクターインスタンスを OpenShift ネイティブに作成および管理できるため、cURL などの HTTP クライアントが必要ありません。その他の Kafka リソースと同様に、コネクターの望ましい状態を OpenShift クラスターにデプロイされた KafkaConnector YAML ファイルに宣言し、コネクターインスタンスを作成します。

該当する KafkaConnector を更新して稼働中のコネクターインスタンスを管理した後、更新を適用します。該当する KafkaConnector を削除して、コネクターを削除します。

これまでのバージョンの AMQ Streams との互換性を維持するため、KafkaConnectors はデフォルトで無効になっています。Kafka Connect クラスターのために有効にするには、KafkaConnect リソースでアノテーションを使用する必要があります。手順は「KafkaConnector リソースの有効化」を参照してください。

KafkaConnectors が有効になると、Cluster Operator によって監視が開始されます。KafkaConnectors に定義された設定と一致するよう、稼働中のコネクターインスタンスの設定を更新します。

AMQ Streams には、examples/connect/source-connector.yaml という名前のサンプル KafkaConnector が含まれています。このサンプルを使用して、FileStreamSourceConnector を作成および管理できます。

2.3.3.2. Kafka Connect REST API の可用性

Kafka Connect REST API は、<connect-cluster-name>-connect-api サービスとして 8083 番ポートで使用できます。

KafkaConnectors が有効になっている場合、Kafka Connect REST API に直接手作業で追加された変更は Cluster Operator によって元に戻されます。

REST API でサポートされる操作は、Apache Kafka のドキュメント を参照してください。

2.3.4. KafkaConnector リソースの Kafka Connect へのデプロイ

この手順では、KafkaConnector の例を Kafka Connect クラスターにデプロイする方法を説明します。

YAML の例によって FileStreamSourceConnector が作成され、ライセンスファイルの各行が my-topic という名前のトピックでメッセージとして Kafka に送信されます。

前提条件

手順

  1. examples/connect/source-connector.yaml ファイルを編集します。

    apiVersion: kafka.strimzi.io/v1alpha1
    kind: KafkaConnector
    metadata:
      name: my-source-connector 1
      labels:
        strimzi.io/cluster: my-connect-cluster 2
    spec:
      class: org.apache.kafka.connect.file.FileStreamSourceConnector 3
      tasksMax: 2 4
      config: 5
        file: "/opt/kafka/LICENSE"
        topic: my-topic
        # ...
    1
    KafkaConnector リソースの名前を入力します。これは、Kafka Connect 内のコネクターの名前として使用されます。OpenShift リソースで有効な名前を選択します。
    2
    コネクターを作成する Kafka Connect クラスターの名前を入力します。
    3
    コネクタークラスの名前またはエイリアス。これは、Kafka Connect クラスターによって使用されているイメージに存在するはずです。
    4
    コネクターによる作成が可能なタスクの最大数。
    5
    コネクターの設定。使用できる設定オプションは、コネクタークラスによって異なります。
  2. OpenShift クラスターに KafkaConnector を作成します。

    oc apply -f examples/connect/source-connector.yaml
  3. リソースが作成されたことを確認します。

    oc get kctr --selector strimzi.io/cluster=my-connect-cluster -o name

2.4. Kafka MirrorMaker のデプロイ

Cluster Operator によって、1 つ以上の Kafka MirrorMaker のレプリカがデプロイされ、Kafka クラスターの間でデータが複製されます。このプロセスはミラーリングと言われ、Kafka パーティションのレプリケーションの概念と混同しないようにします。MirrorMaker は、ソースクラスターからメッセージを消費し、これらのメッセージをターゲットクラスターにパブリッシュします。

2.4.1. Kafka MirrorMaker の OpenShift クラスターへのデプロイ

この手順では、Cluster Operator を使用して Kafka MirrorMaker クラスターを OpenShift クラスターにデプロイする方法を説明します。

デプロイメントでは、YAML ファイルの仕様を使って、デプロイされた MirrorMaker のバージョンに応じて KafkaMirrorMaker または KafkaMirrorMaker2 リソースが作成されます。

この手順では、AMQ Streams にある以下のサンプルファイルを使用します。

  • examples/mirror-maker/kafka-mirror-maker.yaml
  • examples/mirror-maker/kafka-mirror-maker-2.yaml

KafkaMirrorMaker または KafkaMirrorMaker2 リソースの設定に関する詳細は「Kafka MirrorMaker の設定」を参照してください。

手順

  1. Kafka MirrorMaker を OpenShift クラスターにデプロイします。

    MirrorMaker の場合

    oc apply -f examples/mirror-maker/kafka-mirror-maker.yaml

    MirrorMaker 2.0 の場合

    oc apply -f examples/mirror-maker/kafka-mirror-maker-2.yaml
  2. MirrorMaker が正常にデプロイされたことを確認します。

    oc get deployments

2.5. Kafka Bridge のデプロイ

Cluster Operator によって、1 つ以上の Kafka Bridge のレプリカがデプロイされ、HTTP API 経由で Kafka クラスターとクライアントの間でデータが送信されます。

2.5.1. Kafka Bridge を OpenShift クラスターへデプロイ

この手順では、Cluster Operator を使用して Kafka Bridge クラスターを OpenShift クラスターにデプロイする方法を説明します。

デプロイメントでは、YAML ファイルの仕様を使って KafkaBridge リソースが作成されます。

この手順では、AMQ Streams にある以下のサンプルファイルを使用します。

  • examples/bridge/kafka-bridge.yaml

KafkaBridge リソースの設定に関する詳細は「Kafka Bridge の設定」を参照してください。

手順

  1. Kafka Bridge を OpenShift クラスターにデプロイします。

    oc apply -f examples/bridge/kafka-bridge.yaml
  2. Kafka Bridge が正常にデプロイされたことを確認します。

    oc get deployments

2.6. サンプルクライアントのデプロイ

この手順では、ユーザーが作成した Kafka クラスターを使用してメッセージを送受信するプロデューサーおよびコンシューマークライアントの例をデプロイする方法を説明します。

前提条件

  • クライアントが Kafka クラスターを使用できる必要があります。

手順

  1. Kafka プロデューサーをデプロイします。

    oc run kafka-producer -ti --image=registry.redhat.io/amq7/amq-streams-kafka-25-rhel7:1.5.0 --rm=true --restart=Never -- bin/kafka-console-producer.sh --broker-list cluster-name-kafka-bootstrap:9092 --topic my-topic
  2. プロデューサーが稼働しているコンソールにメッセージを入力します。
  3. Enter を押してメッセージを送信します。
  4. Kafka コンシューマーをデプロイします。

    oc run kafka-consumer -ti --image=registry.redhat.io/amq7/amq-streams-kafka-25-rhel7:1.5.0 --rm=true --restart=Never -- bin/kafka-console-consumer.sh --bootstrap-server cluster-name-kafka-bootstrap:9092 --topic my-topic --from-beginning
  5. コンシューマーコンソールに受信メッセージが表示されることを確認します。