18.3. 手順
- Data Grid Operator をインストールします。
Data Grid クラスターにアクセスするための認証情報を設定します。
Red Hat build of Keycloak が Data Grid クラスターで認証できるようにするには、この認証情報が必要です。次の
identities.yamlファイルで、管理者権限を持つユーザー名とパスワードを設定します。credentials: - username: developer password: strong-password roles: - admincredentials: - username: developer password: strong-password roles: - adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow identities.yamlは、次のいずれかの方法でシークレットに設定できます。{kubernetes} リソースとして:
認証情報シークレット
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Base64 でエンコードした上記の例の
identities.yaml。
CLI の使用
oc create secret generic connect-secret --from-file=identities.yaml
oc create secret generic connect-secret --from-file=identities.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 詳細は、認証の設定 ドキュメントを参照してください。
これらのコマンドは両方の OpenShift クラスターで実行する必要があります。
サービスアカウントを作成します。
クラスター間の接続を確立するには、サービスアカウントが必要です。Data Grid Operator は、これを使用してリモートサイトからネットワーク設定を検査し、それに応じてローカル Data Grid クラスターを設定します。
詳細は、マネージドのクロスサイトレプリケーション ドキュメントを参照してください。
次のように
service-account-tokenシークレットタイプを作成します。同じ YAML ファイルを両方の OpenShift クラスターで使用できます。xsite-sa-secret-token.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスアカウントを作成し、両方の OpenShift クラスターでアクセストークンを生成します。
Site-Aでサービスアカウントを作成するoc create sa -n keycloak xsite-sa oc policy add-role-to-user view -n keycloak -z xsite-sa oc create -f xsite-sa-secret-token.yaml oc get secrets ispn-xsite-sa-token -o jsonpath="{.data.token}" | base64 -d > Site-A-token.txtoc create sa -n keycloak xsite-sa oc policy add-role-to-user view -n keycloak -z xsite-sa oc create -f xsite-sa-secret-token.yaml oc get secrets ispn-xsite-sa-token -o jsonpath="{.data.token}" | base64 -d > Site-A-token.txtCopy to Clipboard Copied! Toggle word wrap Toggle overflow Site-Bでサービスアカウントを作成するoc create sa -n keycloak xsite-sa oc policy add-role-to-user view -n keycloak -z xsite-sa oc create -f xsite-sa-secret-token.yaml oc get secrets ispn-xsite-sa-token -o jsonpath="{.data.token}" | base64 -d > Site-B-token.txtoc create sa -n keycloak xsite-sa oc policy add-role-to-user view -n keycloak -z xsite-sa oc create -f xsite-sa-secret-token.yaml oc get secrets ispn-xsite-sa-token -o jsonpath="{.data.token}" | base64 -d > Site-B-token.txtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次に、
Site-AからSite-Bにトークンをデプロイしてから、その逆を行います。Site-BのトークンをSite-Aにデプロイするoc create secret generic -n keycloak xsite-token-secret \ --from-literal=token="$(cat Site-B-token.txt)"
oc create secret generic -n keycloak xsite-token-secret \ --from-literal=token="$(cat Site-B-token.txt)"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Site-AのトークンをSite-Bにデプロイするoc create secret generic -n keycloak xsite-token-secret \ --from-literal=token="$(cat Site-A-token.txt)"
oc create secret generic -n keycloak xsite-token-secret \ --from-literal=token="$(cat Site-A-token.txt)"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
TLS シークレットを作成します。
この章では、Data Grid でクロスサイト通信に OpenShift ルートを使用します。この OpenShift ルートは、TLS の SNI 拡張を使用してトラフィックを正しい Pod に送信します。これを実現するために、JGroups は TLS ソケットを使用します。これには、正しい証明書を備えたキーストアとトラストストアが必要です。
詳細は、クロスサイト接続のセキュリティー保護 ドキュメントまたはこちらの Red Hat Developer Guide を参照してください。
キーストアとトラストストアは、OpenShift シークレットでアップロードします。シークレットには、ファイルの内容、ファイルにアクセスするためのパスワード、およびストアのタイプを含めます。証明書とストアを作成する手順は、この章では説明しません。
キーストアをシークレットとしてアップロードするには、次のコマンドを使用します。
キーストアのデプロイ
oc -n keycloak create secret generic xsite-keystore-secret \ --from-file=keystore.p12="./certs/keystore.p12" \ --from-literal=password=secret \ --from-literal=type=pkcs12
oc -n keycloak create secret generic xsite-keystore-secret \ --from-file=keystore.p12="./certs/keystore.p12" \1 --from-literal=password=secret \2 --from-literal=type=pkcs123 Copy to Clipboard Copied! Toggle word wrap Toggle overflow トラストストアをシークレットとしてアップロードするには、次のコマンドを使用します。
トラストストアのデプロイ
oc -n keycloak create secret generic xsite-truststore-secret \ --from-file=truststore.p12="./certs/truststore.p12" \ --from-literal=password=caSecret \ --from-literal=type=pkcs12oc -n keycloak create secret generic xsite-truststore-secret \ --from-file=truststore.p12="./certs/truststore.p12" \1 --from-literal=password=caSecret \2 --from-literal=type=pkcs123 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記キーストアとトラストストアは、両方の OpenShift クラスターにアップロードする必要があります。
クロスサイトを有効にして Data Grid のクラスターを作成する
クロスサイトの設定 ドキュメントに、上記の手順を含め、クロスサイトを有効にして Data Grid クラスターを作成および設定する方法に関するすべての情報が記載されています。
この章では、上記の手順のコマンドによって作成された認証情報、トークン、および TLS キーストア/トラストストアを使用した基本的な例を示します。
Site-AのInfinispanCRCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスター名。
- 2
- Prometheus によるクラスターの監視を許可します。
- 3
- カスタムの認証情報を使用する場合は、ここでシークレット名を設定します。
- 4
- ローカルサイトの名前。この場合は
Site-Aです。 - 5
- OpenShift ルートを使用したクロスサイト接続の公開。
- 6 9
- 前のステップで定義したキーストアが存在するシークレット名。
- 7 10
- キーストア内の証明書のエイリアス。
- 8 11
- 前のステップで定義したキーストアの秘密鍵 (ファイル名)。
- 12
- 前のステップで定義したトラストストアが存在するシークレット名。
- 13
- 前のステップで定義したキーストアのトラストストアキー (ファイル名)。
- 14
- リモートサイトの名前 (この場合は
Site-B)。 - 15
- リモートサイトの Data Grid クラスターの namespace。
- 16
- リモートサイトの OpenShift API URL。
- 17
- リモートサイトで認証するためのアクセストークンを含むシークレット。
Site-BのInfinispanCR も上記と同様です。ポイント 4、11、13 の違いに注意してください。Site-BのInfinispanCRCopy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat build of Keycloak 用のキャッシュを作成します。
Red Hat build of Keycloak では、
actionTokens、authenticationSessions、loginFailures、workのキャッシュが存在している必要があります。Data Grid Cache CR を使用すると、Data Grid クラスターにキャッシュをデプロイできます。クロスサイトのドキュメント に記載されているように、クロスサイトはキャッシュごとに有効にする必要があります。このドキュメントには、この章で使用するオプションの詳細が記載されています。次の例は、
Site-AのCacheCR を示しています。Site-Aで、上記の各キャッシュに対して次の内容のCacheCR を作成します。キャッシュ
actionTokensCopy to Clipboard Copied! Toggle word wrap Toggle overflow キャッシュ
authenticationSessionsCopy to Clipboard Copied! Toggle word wrap Toggle overflow キャッシュ
loginFailuresCopy to Clipboard Copied! Toggle word wrap Toggle overflow キャッシュ
workCopy to Clipboard Copied! Toggle word wrap Toggle overflow
上記の例は、最善のデータ整合性を実現するために推奨される設定です。
背景情報
アクティブ/アクティブ設定では、両方のサイトでエントリーが同時に変更されるため、デッドロックが発生する可能性があります。
transaction.mode: NON_DURABLE_XAでは、そのようになった場合にデータの整合性を保ちながらトランザクションがロールバックされます。この場合、backup.failurePolicy: FAILを設定する必要があります。トランザクションを安全にロールバックするためのエラーが出力されます。この状況が発生すると、Red Hat build of Keycloak は再試行を試みます。transaction.locking: PESSIMISTICは唯一サポートされているロックモードです。OPTIMISTICはネットワークコストが高いため推奨されません。同じ設定により、一方のサイトにアクセスできない間にもう一方のサイトが更新されることも防止されます。backup.strategy: SYNCでは、Red Hat build of Keycloak のリクエストが完了したときに、データが他のサイトで表示および保存されます。注記locking.acquireTimeoutを短くすると、デッドロックシナリオでフェイルファストを実行できます。backup.timeoutは必ずlocking.acquireTimeoutよりも大きくなければなりません。Site-Bの場合、上図のポイント 3 に示されているbackups.<name>を除き、CacheCR は同じようになります。Site-BのactionTokensキャッシュの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow