5.3. 流程

安装 Data Grid Operator
配置用于访问 Data Grid 集群的凭证。
红帽构建的 Keycloak 需要此凭证才能与 Data Grid 集群进行身份验证。以下 identity.yaml 文件使用 admin 权限设置用户名和密码
```
credentials:
  - username: developer
    password: strong-password
    roles:
      - admin
```
identity.yaml 可以在 secret 中设置为以下之一：
- 作为 Kubernetes 资源：
  凭证 Secret
```
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: connect-secret
  namespace: keycloak
data:
  identities.yaml: Y3JlZGVudGlhbHM6CiAgLSB1c2VybmFtZTogZGV2ZWxvcGVyCiAgICBwYXNzd29yZDogc3Ryb25nLXBhc3N3b3JkCiAgICByb2xlczoKICAgICAgLSBhZG1pbgo= 1
```
  1
  前面示例 base64 编码中的 identity .yaml。
- 使用 CLI
```
oc create secret generic connect-secret --from-file=identities.yaml
```
  如需了解更多详细信息，请参阅配置身份验证文档。https://docs.redhat.com/en/documentation/red_hat_data_grid/8.5/html-single/data_grid_operator_guide/index#configuring-authentication
  这两个 OpenShift 集群上都必须执行这些命令。

创建一个服务帐户。

在集群间建立连接需要服务帐户。Data Grid Operator 用来检查远程站点的网络配置，并相应地配置本地 Data Grid 集群。

按照如下所示，创建一个 service-account-token 机密类型：同一 YAML 文件可用于两个 OpenShift 集群。
xsite-sa-secret-token.yaml
```
apiVersion: v1
kind: Secret
metadata:
  name: ispn-xsite-sa-token 1
  annotations:
    kubernetes.io/service-account.name: "xsite-sa" 2
type: kubernetes.io/service-account-token
```
1
机密名称。
2
服务帐户名称。

创建服务帐户，并在两个 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.txt

在 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.txt

下一步是将来自 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)"

将 Site-A 令牌部署到 Site-B

oc create secret generic -n keycloak xsite-token-secret \
  --from-literal=token="$(cat Site-A-token.txt)"

创建 TLS secret
在本章中，Data Grid 使用 OpenShift 路由进行跨站点通信。它使用 TLS 的 SNI 扩展将流量定向到正确的 Pod。为达到此目的，JGroups 使用 TLS 套接字，这需要一个含有正确证书的 Keystore 和 Truststore。
如需更多信息，请参阅安全跨站点连接文档或本红帽开发人员指南。
上传 OpenShift Secret 中的 Keystore 和 Truststore。secret 包含文件内容、访问它的密码以及存储的类型。创建证书和存储的说明超出了本章的讨论范围。
要将 Keystore 作为 Secret 上传，请使用以下命令：
部署密钥存储
```
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=pkcs12 3
```
1
文件名和到密钥存储的路径。
2
用于访问密钥存储的密码。
3
Keystore 类型。
要将 Truststore 上传为 Secret，请使用以下命令：
部署 Truststore
```
oc -n keycloak create secret generic xsite-truststore-secret \
        --from-file=truststore.p12="./certs/truststore.p12" \  1
        --from-literal=password=caSecret \  2
        --from-literal=type=pkcs12  3
```
1
文件名和到 Truststore 的路径。
2
访问 Truststore 的密码。
3
Truststore 类型。
注意
keystore 和 Truststore 必须在两个 OpenShift 集群中上传。

为启用了跨站点的 Data Grid 创建一个集群

设置跨站点文档提供了关于如何在启用了跨站点的情况下创建和配置 Data Grid 集群的所有信息，包括前面的步骤。

本章提供了一个基本示例，它使用前面步骤中命令创建的凭据、令牌和 TLS Keystore/Truststore。

Site-A的 Infinispan CR

apiVersion: infinispan.org/v1
kind: Infinispan
metadata:
  name: infinispan 1
  namespace: keycloak
  annotations:
    infinispan.org/monitoring: 'true' 2
spec:
  replicas: 3
  jmx:
    enabled: true
  security:
    endpointSecretName: connect-secret 3
  service:
    type: DataGrid
    sites:
      local:
        name: site-a 4
        expose:
          type: Route 5
        maxRelayNodes: 128
        encryption:
          transportKeyStore:
            secretName: xsite-keystore-secret 6
            alias: xsite 7
            filename: keystore.p12 8
          routerKeyStore:
            secretName: xsite-keystore-secret 9
            alias: xsite 10
            filename: keystore.p12 11
          trustStore:
            secretName: xsite-truststore-secret 12
            filename: truststore.p12 13
      locations:
        - name: site-b 14
          clusterName: infinispan
          namespace: keycloak 15
          url: openshift://api.site-b 16
          secretName: xsite-token-secret 17

1: 集群名称
2: 允许 Prometheus 监控集群。
3: 如果使用自定义凭证，请在此处配置 secret 名称。
4: 本地站点的名称，本例中为 Site-A。
5: 使用 OpenShift Route 公开跨站点连接。
6 9: 上一步中定义的 Keystore 所在的 secret 名称。
7 10: Keystore 中证书的别名。
8 11: 上一步中定义的密钥存储的机密密钥(filename)。
12: Truststore 存在于上一步中定义的 secret 名称。
13: 上一步中定义的密钥存储的 Truststore 密钥(filename)。
14: 远程站点的名称，本例中为 Site-B。
15: 来自远程站点的 Data Grid 集群的命名空间。
16: 远程站点的 OpenShift API URL。
17: 带有访问令牌的 secret，以向远程站点进行身份验证。

对于 Site-B，Infinispan CR 类似于上述内容。请注意点 4、11 和 13 的不同。

Site-B的 Infinispan CR

apiVersion: infinispan.org/v1
kind: Infinispan
metadata:
  name: infinispan 1
  namespace: keycloak
  annotations:
    infinispan.org/monitoring: 'true' 2
spec:
  replicas: 3
  jmx:
    enabled: true
  security:
    endpointSecretName: connect-secret 3
  service:
    type: DataGrid
    sites:
      local:
        name: site-b 4
        expose:
          type: Route 5
        maxRelayNodes: 128
        encryption:
          transportKeyStore:
            secretName: xsite-keystore-secret 6
            alias: xsite 7
            filename: keystore.p12 8
          routerKeyStore:
            secretName: xsite-keystore-secret 9
            alias: xsite 10
            filename: keystore.p12 11
          trustStore:
            secretName: xsite-truststore-secret 12
            filename: truststore.p12 13
      locations:
        - name: site-a 14
          clusterName: infinispan
          namespace: keycloak 15
          url: openshift://api.site-a 16
          secretName: xsite-token-secret 17

为红帽构建的 Keycloak 创建缓存。
Red Hat build of Keycloak 需要存在以下缓存： actionTokens,authenticationSessions,loginFailures, 和 work。
Data Grid Cache CR 允许在 Data Grid 集群中部署缓存。需要为每个缓存启用跨站点文档，如跨站点文档所述。文档包含有关本章使用的选项的更多详细信息。以下示例显示了 Site-A 的 Cache CR。
1. 在 Site-A 中，为上述每个缓存创建一个缓存 CR，其内容如下：这是 authenticationSessions 缓存的示例：
```
apiVersion: infinispan.org/v2alpha1
kind: Cache
metadata:
  name: authenticationsessions
  namespace: keycloak
spec:
  clusterName: infinispan
  name: authenticationSessions
  template: |-
    distributedCache:
      mode: "SYNC"
      owners: "2"
      statistics: "true"
      remoteTimeout: "5000"
      encoding:
        media-type: "application/x-protostream"
      locking:
        acquireTimeout: "4000"
      transaction:
        mode: "NON_XA" 1
        locking: "PESSIMISTIC" 2
      stateTransfer:
        chunkSize: "16"
      backups:
        site-b: 3
          backup:
            strategy: "SYNC" 4
            timeout: "4500" 5
            failurePolicy: "FAIL" 6
            stateTransfer:
              chunkSize: "16"
```
1 1
事务模式。
2 2
事务使用的锁定模式。
3 3
远程站点名称。
4 4
跨站点通信策略，本例中为 SYNC。
5 5
跨站点复制超时。
6 9 6
跨站点复制失败策略。
上面的例子是建议配置来实现最佳数据一致性。
背景信息
当两个站点同时修改条目时，主动设置中可能会出现死锁。
transaction.mode: NON_XA 确保事务在发生这种情况时可以保持一致。本例中需要设置 backup.failurePolicy: FAIL。它将抛出一个错误，允许安全回滚事务。当发生这种情况时，红帽构建的 Keycloak 将尝试重试。
transaction.locking: PESSIMISTIC 是唯一支持的锁定模式；由于网络成本，不建议使用 OPTIMISTIC。相同的设置也会阻止在一个站点更新，而其他站点无法访问。
backup.strategy: SYNC 确保数据在完成红帽构建的 Keycloak 请求时可见并存储在其他站点。
注意
在死锁场景中，可以将 locking.acquireTimeout 减少为快速失败。backup.timeout 必须始终高于 locking.acquireTimeout。
对于 Site-B，缓存 CR 非常相似，但 backup.& lt;name&gt; 在上图的第 3 点概述。
Site-B中的 authenticationSessions Cache CR
```
apiVersion: infinispan.org/v2alpha1
kind: Cache
metadata:
  name: authenticationsessions
  namespace: keycloak
spec:
  clusterName: infinispan
  name: authenticationSessions
  template: |-
    distributedCache:
      mode: "SYNC"
      owners: "2"
      statistics: "true"
      remoteTimeout: "5000"
      encoding:
        media-type: "application/x-protostream"
      locking:
        acquireTimeout: "4000"
      transaction:
        mode: "NON_XA" 1
        locking: "PESSIMISTIC" 2
      stateTransfer:
        chunkSize: "16"
      backups:
        site-a: 3
          backup:
            strategy: "SYNC" 4
            timeout: "4500" 5
            failurePolicy: "FAIL" 6
            stateTransfer:
              chunkSize: "16"
```

5.3. 流程

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links