メイン コンテンツをスキップする

Qlik Sense Enterprise on Kubernetes での NFS connector の構成

[NFS connector] を使用して持続ボリュームにアクセスし、データを NFS ネットワーク ドライブ プロビジョナーから Qlik Sense Enterprise on Kubernetes に移動できます。

既定では、Qlik Sense Enterprise on Kubernetes (QSEoK) のインストール時に事前構成済みの NFS connector が追加されます。

チャートにより、Helm パッケージ マネージャーを使用して Kubernetes クラスターに NFS サービス データ コネクターが展開されます。

Kubernetes」を参照してください。

Helm」を参照してください。

注: コード例の多くはプレースホルダー値を含み、ユーザーの設定値で置き換える必要があります。

クラスターへの構成の適用

Helm を使用して、values.yml ファイルの構成を自身の Kubernetes クラスターに適用します。

$ helm upgrade \
  --install \
  qliksense qlik/qliksense \
  -f values.yml

構成が適用されたことを確認するには、get values コマンドを実行し、解決された構成を表示します。

$ helm get values qliksense

devMode:
  enabled: true
engine:
  acceptEULA: "yes"
identity-providers:
  secrets:
    idpConfigs:
      - discoveryUrl: "https://adfs-host/adfs/.well-known/openid-configuration"
        clientId: "https://adfs.elastic.example/1234567890"
        clientSecret: "<client secret>"
        realm: "ADFS"
        hostname: "adfs.elastic.example"
        useClaimsFromIdToken: true
        claimsMapping:
          sub: ["sub", "appid"]
          client_id: "appid"
          name: "display_name"
      - issuerConfig:
          issuer: https://the-issuer
        primary: false
        realm: "ADFS"
        hostname: "adfs.elastic.example"
        staticKeys:
        - kid: "thekid"
          pem: |-
            -----BEGIN PUBLIC KEY-----
            MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEsMSxQjXxrvqoKSAREQXsr5Q7+/aetjEb
            OUHt8/Cf73WD56cb4QbHthALl5Ej4MUFOAL9imDmVQe58o9b1j5Zo16Rt1gjLDvd
            nqstc+PX4tyxqGadItJAOU3jka7jYghA
            -----END PUBLIC KEY-----

コネクターの有効化

Qlik Sense Enterprise on Kubernetes のインストール時に事前構成済みの NFS connector が追加されます。構成の初期設定では、コネクターが無効になっています。values.yml ファイルを使用して有効にできます。

次の手順を実行します。

  1. Helm を使用して、values.yml ファイルの構成を自身の Kubernetes クラスターに適用します。

  2. 次のパラメーターを enabled: false から enabled: true に変更します。

    
    data-connector-nfs:
    	enabled: true

NFS 接続を指定します。

QSEoK のインストール時には、使用する NFS 接続を次のようにして指定できます。

  • helm install コマンドのパラメータ。
  • values.yaml の接続設定を参照し、その情報を helm install コマンドで使用する。

参照 values.yaml

values.yml ファイルを作成し、参照したい設定を helm install コマンドに含めます。

  • devMode.enabled 値を false に設定して開発モードを無効にします。
  • 接続文字列を含む NFS.uri 値を NFS に設定します。

Example: values.yaml

engine:
  acceptEULA: "yes"

devMode:
  enabled: false
data-connector-nfs:
  enabled: true

identity-providers:
  secrets:
    idpConfigs:
      - <your IdP configuration here>

これで、values.yml ファイルが helm install コマンドで参照されます。

helm upgrade \
  --install qliksense qlik/qliksense \
  -f values.yaml

パラメーターの構成

次に、data-connector-nfs チャートとその規定値の一覧表を記します。

プロパティ 説明 初期設定
global.imageRegistry グローバル イメージ レジストリ (image.registry の初期設定を上書き) です。 nil
image.registry リポジトリをプルする既定のレジストリです。 qliktech-docker.jfrog.io
image.repository レジストリがないイメージ名です。 data-connector-nfs
image.tag イメージ バージョン 0.0.12
image.pullPolicy イメージ プル ポリシー 常時image.tag最新の場合。それ以外はIfNotPresentです。
imagePullSecrets プライベート イメージ レジストリにアクセスするためのシークレット名の一覧です。 [{name: "artifactory-docker-secret"}]
replicaCount レプリカの数です。 1
service.type サービスの種類です。 ClusterIP
service.port data-connector-nfs のリッスン ポート 8080
resources.requests.cpu CPU の予約 0.1
resources.requests.memory メモリの予約です。 128Mi
resources.limits.cpu CPU 制限 0.5
resources.limits.memory メモリの制限です。 512Mi
metrics.prometheus.enabled Prometheus の収集用注釈を有効にします。 true
configs.data.keysUri JWKS が JWT のある場所を検証する URI です。 http://{{ .Release.Name }}-keys:8080/v1/keys/qlik.api.internal
secrets.stringData.tokenAuthPrivateKey 認証サービスで JWKS に対応するプライベート キーです。 値を参照
secrets.stringData.tokenAuthPrivateKeyId 認証サービスで JWKS に対応するキー ID です。 zpiZ-klS65lfcq1K0-o29Sa0AAZYYr4ON_1VCtAbMEA
configs.data.tokenAuthUri 認証サービスが内部トークンを取得する URI です。 http://{{ .Release.Name }}-edge-auth:8080
persistence.enabled NFS 接続用の持続ボリュームを構成します。 false
configs.data.spacesUri スペース サービスがある場所の URI です。 http://{.Release.Name}-spaces:6080
configs.data.pdsUri ポリシー決定サービスがある場所の URI です。 http://{.Release.Name}-policy-decisions:5080
hpa.enabled Horizontal Pod Autoscaler のトグルです。 false
hpa.minReplicas Pod Autoscaler 用の最小レプリカです。 3
hpa.maxReplicas Pod Autoscaler 用の最大レプリカです。 6
hpa.targetAverageUtilizationCpu Pod Autoscaler 用 CPU 稼働率の目標です。 80

helm install に対する --set key=value[,key=value] 引数を使用して各パラメーターを指定します。代わりに、チャートをインストールする際に、パラメーターのボリュームを指定する YAML ファイルを提供することもできます。

例:

helm install --name my-release -f values.yaml qlik/data-connector-nfs

ボリューム マウントの構成と NFS 接続の宣言

持続ボリューム

持続ボリュームは、標準の Kubernetes マニフェストを使用して作成します。使用できるストレージ プロビジョナーの種類は、各環境において独自の対応プロビジョナーが存在するため、Qlik Sense Enterprise を展開する Kubernetes の環境に依存します。Kubernetes 環境の多くには、NFS または類似のネットワーク ドライブ、プロビジョナーが備えられています。NFS コネクタ側からの要件は、持続ボリュームが ReadWriteMany または ReadOnlyMany のアクセス モードいずれかに対応していることです。

Docker の「hostpath」プロビジョナーを使用した持続ボリュームの宣言例は次のとおりです。


kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
	name: localstorage
provisioner: docker.io/hostpath
---
apiVersion: v1
kind: PersistentVolume
metadata:
	name: data-connector-nfs-test-pv
	labels:
		type: local
spec:
	storageClassName: localstorage
	capacity:
		storage: 5Gi
	accessModes:
		- ReadWriteMany
	hostPath:
        # これは、NFS コネクタにアクセス権を与えたい自身のノート PC にある
        # ディレクトリへのパスです。
		path: "/some/data/directory"
		type: "Directory"

kubectl apply -f manifest.yaml コマンドを使用してマニフェストを展開します。

持続ボリューム クレーム

以前に宣言済みの持続ボリュームにバインドされた持続ボリューム クレームは、data-connector-nfs の Pod を構成するために使用した values.yaml 上書きファイルで定義されます。クレームは、values.yam ファイルの持続性 セクション内で定義されます。

持続ボリューム クレームを 2 つ宣言する例を次に示します。


data-connector-nfs:
	persistence:
		enabled: true
		pvc-1:
			storageClass: localstorage
			accessMode: ReadWriteMany
			size: 5Gi
		pvc-2:
			storageClass: localstorage
			accessMode: ReadOnlyMany
			size: 5Gi

クレーム名 (この例では、pvc-1、pvc-2) には、必要に応じた名前を選択できます。重要な点は、これらの PVC (storageClass、accessMode など) のために宣言したプロパティが、以前に宣言した持続ボリュームのプロパティと一致することです。このプロパティの一致は、Kubernetes が既存の PV に PVC をバインドする際に使用されます。

ボリュームのマウント

次に、前のセクションで宣言した PVC を data-connector-nfs の Pod コンテナにマウントする必要があります。展開 セクションの values.yaml 上書きファイルでマウントすることもできます。

上記の PVC 2 つにマウントしたボリューム 2 つの宣言例を次に示します。


data-connector-nfs:
	deployment: 
		container: 
			volumeMounts: 
				pvc-1:
					mountPath: /tmp/MyReadWriteDir/
				pvc-2:
					readOnly: true
					mountPath: /tmp/MyReadOnlyDir/

ここで、ボリューム マウント名 (pvc-1、pvc-2) は、前のセクションで宣言した PVC 名と一致する必要があります。mountPath は任意のディレクトリを選択できますが、/tmp/ のサブディレクトリを使用することが合理的慣習です。ボリューム マウントを readOnly として宣言するとコネクターは、このディレクトリを読み取り専用として扱うように強制します。

NFS 接続の宣言

NFS 接続は展開時に定義されます。つまり、ユーザーはこれらの接続を作成しません。各接続は、共有スペースに常駐するよう宣言されます。共有スペース上の権限により、該当スペース内の NFS 接続に対するユーザーのアクセスを定義します。さらに NFS 接続は、configs セクションの values.yaml 上書きファイル内でも定義できます。

前のセクションで定義したボリューム マウントへのアクセスを提供する NFS 接続 2 つの宣言例を次に示します。


data-connector-nfs:
	configs:
		data:
			nfsConnections_0_Name: "NfsConnection1"
			nfsConnections_0_Path: "/tmp/MyReadWriteDir"
			nfsConnections_0_SpaceId: "5e5422dcb6dfec00014ffaea"
			nfsConnections_1_Name: "NfsConnection2"
			nfsConnections_1_Path: "/tmp/MyReadOnlyDir/SomeSubDir"
			nfsConnections_1_SpaceId: "5e5422dcb6dfec00014ffaea"

各接続は、3 つのプロパティにより定義されます。名前、パス、そして SpaceId です。スペース ID は、NFS 接続が常駐する共有スペースを定義します。この例では、両方の NFS 接続が同一のスペースにあります。パスは、前のセクションで宣言したボリューム マウントのいずれかの 1 つにあるルート ディレクトリか、これらのルート ディレクトリのいずれかのサブディレクトリでなければなりません。同一のボリューム マウントのルート ディレクトリ内にある複数のサブディレクトリをポイントする、複数の NFS 接続を定義することができます。各 NFS 接続の宣言に対する 3 つのプロパティは、宣言された各接続に対して昇順の数値インデックスを使用してグループにまとめられます (この例では、0 と 1)。

サブ チャートの既定値

既定値すべてを含んだデータ コネクタ NFS のサブ チャート セクションは、次のとおりです。

注: コードのセクションはコメント アウトされています。

## data-connector-nfs には、data-connector-nfs sub-chart data-connector-nfs の構成が含まれています。
data-connector-nfs:
	enabled: false
	deployment:
		replicas: 1
		container:
			## data-connector-nfs resource limits
			##
			resources:
				limits:
					cpu: null
					memory: null
				requests:
					cpu: null
					memory: null
			## ボリューム マウントはここで定義されます。各マウントは、上記にある NFS 接続定義内のベース 
            ## ディレクトリの一部をマッピングする必要があります。複数の 
            ## ボリューム マウントを定義できます。各ボリューム マウントの名前は、次の 
            ## セクションの持続性宣言の名前と一致 
            ## しなければなりません。ボリューム マウントは既定では読み書きができますが、
            ## readOnly プロパティを true に設定して、読み取り専用に 
            ## することができます。
			# volumeMounts:
				# pvc-1:
					# readOnly: false
					# mountPath: /tmp/MountedVolume1Dir/
			## NFS 接続はここで定義します。各接続は、共有スペースに 
            ## 関連付けられる必要があり、ボリューム マウントにも関連付けられる 
            ## 必要があります。複数の接続を定義できます (それぞれは、
            ## プロパティのセットと 0 で始まるインデックスにより) 
	# configs:
		# data:
			# nfsConnections_0_Name: "NfsConnection1"
			# nfsConnections_0_Path: "/tmp/MountedVolume1Dir"
			# nfsConnections_0_SpaceId: [Some shared space ID]

		## 持続ボリューム クレームはここで定義します。これらは、
        ## 他で宣言された持続ボリュームに (プロパティに基づき) 
        ## 一致している必要があります。1 つ以上の持続ボリュームをここで 
        ## 定義できます。
	# persistence:
		# enabled: true
		# persistentVolumeClaim:
			# pvc-1:
				# storageClass: localstorage
				# accessMode: ReadWriteMany
				# size: 5Gi

DCaaS config を更新して、NFS コネクターを確実に認識するようにします。

DCaaS サービスは、既定では NFS サービスのデータ コネクターを認識しない場合があります。そうした場合は、更新済みの env セクションで values.yml 上書きファイルを使用し、構成を更新する必要があります。

Qlik Sense Enterprise for elastic deploymentsDCaaS を更新する env セクションの例は次のとおりです。


dcaas:
	env:
		connector_service: "{{ .Release.Name }}-data-connector-rest-rld:{{ .Release.Name }}-data-connector-rest-cmd:50060 {{ .Release.Name }}-data-connector-qwc-rld:{{ .Release.Name }}-data-connector-qwc-cmd:50060 {{ .Release.Name }}-data-connector-odbc-rld:{{ .Release.Name }}-data-connector-odbc-cmd:50060 {{ .Release.Name }}-data-connector-sap-sql-rld:{{ .Release.Name }}-data-connector-sap-sql-cmd:50060 {{ .Release.Name }}-qix-datafiles:50051 {{ .Release.Name }}-data-connector-nfs:50051"

ポート 5051 で作動するデータ コネクター NFS へのポインターが、connector_service リストの終わりに追加されていることがわかります。

DCaaS では、コネクターを認識するために、データ コネクターNFS 機能フラグを有効にする必要もあります。Qlik Sense Enterprise for elastic deployments では、この機能フラグは次のように有効化します。


feature-flags:
	configmaps:
		create: true
		featureFlagsConfig:
			{
				"globalFeatures": {
					"data-connector-nfs": true,
					...
				}
			}

Helm チャートの再展開

values.yml ファイルへの変更を適用するには、helm upgrade --install コマンドを使用して、データ コネクター NFSDCaaS Helm チャート (Qlik Sense Enterprise on Kubernetes チャート内チャートの一部として) を再展開する必要があります。

リリース名 my-release でチャートをインストールするには:

helm install --name my-release qlik/data-connector-nfs

コマンドは、更新した構成で Kubernetes クラスターの宣言済み NFS 接続を展開します。