編集

次の方法で共有

Apache NiFi の Helm ベースのデプロイ

Azure Kubernetes Service (AKS)

このソリューションでは、Azure Kubernetes Service (AKS) に NiFi をデプロイするときに Helm char を使用する方法を示します。 Helm によって、Kubernetes アプリケーションのインストールと管理のプロセスを効率化します。

Apache®、Apache NiFi®、NiFi® は、Apache Software Foundation の米国およびその他の国における登録商標または商標です。 これらのマークを使用することが、Apache Software Foundation による保証を意味するものではありません。

アーキテクチャ

アプリケーションを Kubernetes にデプロイするようにユーザーが Helm チャートを構成する方法を示す図。コンポーネントとしては、Kubernetes で作成されるポッドとボリュームがあります。

このアーキテクチャの Visio ファイルをダウンロードします。

ワークフロー

  • Helm チャートには values.yaml ファイルが含まれます。 このファイルには、ユーザーが編集できる入力値が一覧表示されています。

  • ユーザーは、次の値を含む、チャートの設定を調整できます。

    • ボリューム サイズ。
    • ポッドの数。
    • ユーザーの認証および承認メカニズム。

  • ユーザーは、Helm の install コマンドを実行してチャートをデプロイします。

  • ユーザーによる入力に、必要な変数の値がすべて含まれているかどうか、Helm で確認されます。

  • Kubernetes にデプロイするオブジェクトを記述するマニフェストが Helm によって作成されます。

  • そのマニフェストが Helm から Kubernetes クラスターに送信されます。 クラスターの調整が Apache ZooKeeper で行われます。

  • 指定されたオブジェクトが Kubernetes によって作成されます。 NiFi のデプロイには次のオブジェクトが必要です。

    • 構成オブジェクト。
    • データ ボリューム。 ポッドのストレージは一時的なものです。
    • ログ ボリューム。
    • イメージを使用してコンテナーで NiFi を実行するポッド。 Kubernetes では、StatefulSet ワークロード リソースを使用してポッドを管理します。
    • ユーザーが NiFi UI を使用できるようにする Kubernetes サービス。
    • イングレス ルート (クラスターでイングレスを使用して UI を外部で使用できるようにする場合)。

Components

Helm チャートは、ツリー構造を持つ、フォルダー内のファイルのコレクションです。 これらのファイルは、Kubernetes リソースを記述します。 Helm チャートでは、次のコンポーネントを構成できます。

ZooKeeper

ZooKeeper には別のチャートを使用します。 Kubernetes でそのインキュベータ チャート リポジトリに用意されている標準の ZooKeeper チャートを使用できます。 ただし、依存関係にパブリック レジストリ コンテンツが含まれている場合は、イメージの開発とデプロイのワークフローにリスクが生じます。 リスクを軽減するには、できるだけパブリック コンテンツのローカル コピーを保持するようにします。 詳細については、「Azure Container Registry を使用してパブリック コンテンツを管理する」を参照してください。

別の方法として、ZooKeeper を独自にデプロイすることもできます。 このオプションを選択した場合は、ZooKeeper サーバーとポート番号を指定して、NiFi を実行するポッドから ZooKeeper サービスにアクセスできるようにします。

Kubernetes StatefulSet

Kubernetes でアプリケーションを実行するには、ポッドを実行します。 この基本単位で、アプリケーションのさまざまなアクティビティを実装するさまざまなコンテナーを実行します。

Kubernetes には、NiFi のようなアプリケーションを実行するポッドを管理するために、2 つのソリューションが用意されています。

  • Replicaset。特定の時点で実行される一定のレプリカ ポッド セットを維持します。 多くの場合、ReplicaSet を使用して、指定した数の同じポッドを確実に使用できるようにします。
  • StatefulSet。ステートフル アプリケーションの管理に使用するワークロード API オブジェクトです。 StatefulSet によって、同じコンテナー仕様に基づくポッドを管理します。 Kubernetes では、これらのポッドを同じ仕様で作成します。 ただし、これらのポッドに互換性はありません。 各ポッドには、再スケジュールされた後も保持される、永続的な識別子があります。

データの管理には NiFi を使用するので、StatefulSet が NiFi のデプロイ用の最適なソリューションになります。

ConfigMaps

Kubernetes には、非機密データを格納するための ConfigMaps が用意されています。 Kubernetes では、これらのオブジェクトを使用して、nifi.properties などのさまざまな構成ファイルを管理します。 アプリケーションを実行するコンテナーから、マウントされたボリュームとファイルを介して構成情報にアクセスします。 ConfigMaps を使用すると、デプロイ後の構成変更の管理が容易になります。

ServiceAccount

セキュリティで保護されたインスタンスの場合、NiFi では認証と承認を使用します。 この情報は、ファイル システム ファイル内で NiFi によって管理されます。 具体的には、各クラスター ノードで authorizations.xml ファイルと users.xml ファイルを維持する必要があります。 すべてのメンバーは、これらのファイルへの書き込みができる必要があります。 また、この情報の同じコピーをクラスター内の各ノードが持っていることも必要です。 そうでないとクラスターは同期されなくなり、停止します。

これらの条件を満たすため、クラスターの最初のメンバーから存在しているすべてのメンバーに、これらのファイルをコピーできます。 その後、それぞれの新しいメンバーは独自のコピーを保持します。 ポッドは通常、別のポッドからコンテンツをコピーすることは承認されません。 ただし、Kubernetes の ServiceAccount を使用すると、承認を取得できます。

[サービス]

Kubernetes サービスは、Kubernetes クラスターのユーザーがアプリケーション サービスを使用できるようにします。 また、サービス オブジェクトを使用すると、NiFi クラスターのメンバー ノードが相互に通信できます。 Helm チャートのデプロイでは、2 種類のサービス (ヘッドレス サービスと IP ベースのサービス) を使用します。

イングレス

イングレスでは、クラスター サービスへの外部アクセスを管理します。 具体的には、事前構成済みのイングレス コントローラーが、クラスターの外部からクラスター内のサービスへの HTTP と HTTPS のルートを公開します。 コントローラーがどのようにトラフィックをルーティングするかを決定するイングレス規則は、ご自身で定義できます。 Helm チャートでは、イングレス ルートが構成に含まれます。

シークレット

セキュリティで保護された NiFi クラスターを構成するには、資格情報を格納する必要があります。 Kubernetes シークレットが、これらの資格情報を安全に格納および取得するための手段になります。

シナリオの詳細

Apache NiFi のユーザーでは多くの場合、NiFi を Kubernetes にデプロイする必要が生じます。 Kubernetes のデプロイには、ポッド、ボリューム、サービスなど、多くのオブジェクトが含まれます。 このような数のオブジェクトがある場合に、Kubernetes で使用される "マニフェスト" (仕様ファイル) を管理するのは困難です。 異なる構成を使用する複数の NiFi クラスターをデプロイする場合は、さらに難しくなります。

マニフェストを管理する解決策を提供するのが Helm "チャート" です。 Helm は、Kubernetes 用のパッケージ マネージャーです。 Helm ツールを使用すると、Kubernetes アプリケーションのインストールと管理のプロセスを効率化できます。

チャートは、Helm で使用されるパッケージ形式です。 チャート ファイルには構成要件を入力します。 Helm では、各チャートの履歴とバージョンが追跡されます。 これで、Helm ではチャートを使用して Kubernetes マニフェスト ファイルが生成されます。

1 つのチャートから、異なる構成を使用するアプリケーションをデプロイできます。 Azure で NiFi を実行する場合、Helm チャートを使用すると複数の異なる NiFi 構成を Kubernetes にデプロイできます。

Apache®、Apache NiFi®、NiFi® は、Apache Software Foundation の米国およびその他の国における登録商標または商標です。 これらのマークを使用することが、Apache Software Foundation による保証を意味するものではありません。

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

データ ディスク

ディスクを使用する場合は、リポジトリ用にストライプ ディスク セットを使用するようにします。 Virtual Machine Scale Sets を使用したテスト デプロイでは、この方法が最適でした。 nifi.properties からの次の抜粋は、ディスク使用の構成を示しています。

nifi.flowfile.repository.directory=/data/partition1/flowfiles
nifi.provenance.repository.directory.stripe1=/data/partition1/provenancenifi.provenance.repository.directory.stripe2=/data/partition2/provenancenifi.provenance.repository.directory.stripe3=/data/partition3/provenancenifi.content.repository.directory.stripe2=/data/partition2/content
nifi.content.repository.directory.stripe3=/data/partition3/content

この構成では、同じサイズの 3 つのボリュームを使用しています。 システム要件に合わせて、値とストライピングを調整できます。

デプロイメント シナリオ

パブリックまたはプライベートのロード バランサーまたはイングレス コントローラーを使用して、NiFi クラスターを公開できます。 この実装に Helm チャートを使用する場合、次の 2 つの構成を使用できます。

  • ユーザー認証または承認なしで HTTP URL を介してアクセスできる、セキュリティで保護されていない NiFi クラスター。
  • HTTPS URL を介してアクセスできる、セキュリティで保護された NiFi クラスター。 この種類のクラスターは TLS で保護されます。 セキュリティで保護されたクラスターを構成する場合、ご自身の証明書を指定できます。 または、チャートで証明書を生成することもできます。 このために、チャートでは自己署名証明書機関 (CA) を提供する NiFi ツールキットを使用します。

TLS 通信を使用してセキュリティで保護されたクラスターとして実行するように NiFi クラスターを構成する場合は、ユーザー認証を有効にする必要があります。 サポートされている次のいずれかのユーザー認証方法を使用します。

  • 証明書ベースのユーザー認証。 ユーザーは、自分が NiFi UI に提示する証明書によって認証されます。 この種類のユーザー認証システムを使用するには、CA の公開証明書を NiFi のデプロイに追加します。
  • LDAP ベースのユーザー認証。 LDAP サーバーによって、ユーザーの資格情報を認証します。 チャートをデプロイするときに、LDAP サーバーと情報ツリーに関する情報を指定します。
  • OpenID ベースのユーザー認証。 ユーザーがデプロイを構成するための情報を OpenID サーバーに指定します。

リソースの構成と使用量

リソースの使用量を最適化するには、次の Helm チャート オプションを使用して CPU とメモリの値を構成します。

  • request オプション。コンテナーに必要なリソースの初期量を指定します。
  • limit オプション。コンテナーで使用できるリソースの最大量を指定します

NiFi を構成するときは、システムのメモリ構成を考慮してください。 NiFi は Java アプリケーションであるため、最小と最大の Java 仮想マシン (JVM) のメモリ値などの設定を調整する必要があります。 次の設定を使用します。

  • jvmMinMemory
  • jvmMaxMemory
  • g1ReservePercent
  • conGcThreads
  • parallelGcThreads
  • initiatingHeapOccupancyPercent

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。

NiFi バイナリを実行する、基になるコンテナーのセキュリティを強化するには、Kubernetes セキュリティ コンテキストを使用します。 セキュリティ コンテキストでは、これらのコンテナーとそれらのポッドへのアクセスを管理します。 セキュリティ コンテキストを通じて、コンテナーを実行するためのアクセス許可を root 以外のユーザーに付与できます。

セキュリティ コンテキストのその他の用途は次のとおりです。

  • コンテナーを実行する OS ベースのユーザーのアクセスを制限する。
  • コンテナーにアクセスできるグループを指定する。
  • ファイル システムへのアクセスを制限する。

コンテナー イメージ

Kubernetes コンテナーは、NiFi バイナリを実行する基本単位です。 NiFi クラスターを構成するには、これらのコンテナーの実行に使用するイメージに重点を置きます。 このイメージには 2 つのオプションがあります。

  • NiFi チャートを実行するには標準の NiFi イメージを使用します。 そのイメージは、Apache NiFi コミュニティで提供されます。 ただし、セキュリティで保護されたクラスターを構成するには、kubectl バイナリをコンテナーに追加する必要があります。
  • カスタム イメージを使用します。 この方法を採用する場合は、ファイル システムの要件を検討してください。 NiFi バイナリの場所が正しいことを確認します。 構成されたファイル システムの詳細については、Apache NiFi ソース コードの Dockerfile を参照してください。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ