Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

3.3. Keycloak CR の移行

Keycloak CR は、すべてのサーバー設定オプションをサポートするようになりました。関連するすべてのオプションを、CR 仕様で、直接ファーストクラスシチズンフィールドとして使用できます。CR のすべてのオプションは、サーバーオプションと同じ命名規則に準拠しています。これにより、ベアメタルデプロイメントと Operator デプロイメント間のエクスペリエンスがシームレスになります。

さらに、SPI プロバイダー設定など、CR に不足しているオプションを additionalOptions フィールドで定義できます。また、サポートされる代替フィールドが CR のファーストクラスシチズンフィールドとして存在しない場合は、podTemplate (テクノロジープレビューのフィールド) を使用して、Kubernetes デプロイメントの RAW Pod テンプレートを変更することもできます。

以下は、Operator を通じて Red Hat build of Keycloak をデプロイするための Keycloak CR の例を示しています。 

apiVersion: k8s.keycloak.org/v2alpha1
kind: Keycloak
metadata:
  name: example-kc
spec:
  instances: 1
  db:
    vendor: postgres
    host: postgres-db
    usernameSecret:
      name: keycloak-db-secret
      key: username
    passwordSecret:
      name: keycloak-db-secret
      key: password
  http:
    tlsSecret: example-tls-secret
  hostname:
    hostname: test.keycloak.org
  additionalOptions:
    - name: spi-connections-http-client-default-connection-pool-size
      value: 20
Copy to Clipboard Toggle word wrap

CLI 設定との類似点に注目してください。 

./kc.sh start --db=postgres --db-url-host=postgres-db --db-username=user --db-password=pass --https-certificate-file=mycertfile --https-certificate-key-file=myprivatekey --hostname=test.keycloak.org --spi-connections-http-client-default-connection-pool-size=20
Copy to Clipboard Toggle word wrap

3.3.1. データベース設定の移行
リンクのコピー

Red Hat build of Keycloak は、以前に Red Hat Single Sign-On 7.6 で使用されていたのと同じデータベースインスタンスを使用できます。データベーススキーマは、Red Hat build of Keycloak が初めてデータベースに接続するときに自動的に移行されます。

警告

Red Hat Single Sign-On 7.6 Operator によって管理される組み込みデータベースの移行は、サポートされていません。

Red Hat Single Sign-On 7.6 Operator では、外部データベース接続はシークレットを使用して設定していました。次に例を示します。 

apiVersion: v1
kind: Secret
metadata:
  name: keycloak-db-secret
  namespace: keycloak
  labels:
    app: sso
stringData:
  POSTGRES_DATABASE:  kc-db-name
  POSTGRES_EXTERNAL_ADDRESS: my-postgres-hostname
  POSTGRES_EXTERNAL_PORT: 5432
  POSTGRES_USERNAME: user
  POSTGRES_PASSWORD: pass
type: Opaque
Copy to Clipboard Toggle word wrap

Red Hat build of Keycloak では、データベースは、シークレットとして参照される認証情報を使用して Keycloak CR に直接設定されます。次に例を示します。 

apiVersion: k8s.keycloak.org/v2alpha1
kind: Keycloak
metadata:
  name: example-kc
spec:
  db:
    vendor: postgres
    host: my-postgres-hostname
    port: 5432
    usernameSecret:
      name: keycloak-db-secret
      key: username
    passwordSecret:
      name: keycloak-db-secret
      key: password
  ...

apiVersion: v1
kind: Secret
metadata:
  name: keycloak-db-secret
stringData:
  username: "user"
  password: "pass"
type: Opaque
Copy to Clipboard Toggle word wrap

3.3.1.1. サポートされているデータベースベンダー
リンクのコピー

Red Hat Single Sign-On 7.6 Operator は PostgreSQL データベースのみをサポートしていました。一方、Red Hat build of Keycloak Operator はサーバーでサポートされているすべてのデータベースベンダーをサポートしています。

3.3.2. TLS 設定の移行
リンクのコピー

Red Hat Single Sign-On 7.6 Operator では、デフォルトで、OpenShift CA によって生成された TLS シークレットを使用するようにサーバーが設定されていました。Red Hat build of Keycloak Operator では、実稼働環境のベストプラクティスを実現するために、TLS については何も前提を設けておらず、ユーザーが独自の TLS 証明書とキーペアを提供する必要があります。次に例を示します。 

apiVersion: k8s.keycloak.org/v2alpha1
kind: Keycloak
metadata:
  name: example-kc
spec:
  http:
    tlsSecret: example-tls-secret
  ...
Copy to Clipboard Toggle word wrap

tlsSecret で参照されるシークレットの形式には、標準の Kubernetes TLS シークレット (kubernetes.io/tls) タイプを使用する必要があります。

Red Hat Single Sign-On 7.6 Operator は、デフォルトで、ルートで再暗号化 TLS Termination ストラテジーを使用していました。Red Hat build of Keycloak Operator は、デフォルトでパススルーストラテジーを使用します。また、Red Hat Single Sign-On 7.6 Operator は、TLS Termination の設定をサポートしていました。Red Hat build of Keycloak Operator は、現在のリリースでは TLS Termination をサポートしていません。

デフォルトの Operator 管理のルートが必要な TLS 設定を満たさない場合は、ユーザーがカスタムルートを作成し、デフォルトのルートを次のようにして無効にする必要があります。 

apiVersion: k8s.keycloak.org/v2alpha1
kind: Keycloak
metadata:
  name: example-kc
spec:
  ingress:
    enabled: false
  ...
Copy to Clipboard Toggle word wrap

3.3.3. エクステンションのためのカスタムイメージの使用
リンクのコピー

Red Hat build of Keycloak Operator では、ベストプラクティスを反映し、イミュータブルコンテナーをサポートするために、Keycloak CR でのエクステンションの指定がサポートされていません。エクステンションをデプロイするには、最適化されたカスタムイメージをビルドする必要があります。Keycloak CR には、Red Hat build of Keycloak イメージを指定するための専用フィールドが含まれるようになりました。次に例を示します。 

apiVersion: k8s.keycloak.org/v2alpha1
kind: Keycloak
metadata:
  name: example-kc
spec:
  image: quay.io/my-company/my-keycloak:latest
  ...
Copy to Clipboard Toggle word wrap
注記

カスタムイメージを指定した場合、Operator はそれがすでに最適化されていると想定し、サーバーを起動するたびにコストのかかる最適化を実行しません。

3.3.4. アップグレードストラテジーオプションの削除
リンクのコピー

Red Hat Single Sign-On 7.6 Operator は、サーバーのアップグレード実行時の再作成およびローリングストラテジーをサポートしていました。このアプローチは現実的ではありませんでした。Red Hat Single Sign-On 7.6 Operator がアップグレードとデータベース移行を実行する前にデプロイメントをスケールダウンするかどうかは、ユーザーが選択する必要がありました。ローリングストラテジーがいつ安全に使用できるかは、ユーザーには明らかではありませんでした。

したがって、このオプションは Red Hat build of Keycloak Operator では削除され、再作成ストラテジーは常に暗黙的に実行されるようになりました。これにより、新しいサーバーコンテナーイメージで Pod を作成する前にデプロイメント全体がスケールダウンされ、単一のサーバーバージョンのみがデータベースにアクセスできるようになります。

3.3.5. デフォルトで公開されるヘルスエンドポイント
リンクのコピー

Red Hat build of Keycloak は、OpenShift プローブによって使用される単純なヘルスエンドポイントをデフォルトで公開するようにサーバーを設定します。エンドポイントはデプロイメントに関するセキュリティー上の機密データを公開しませんが、エンドポイントには認証なしでアクセスできます。代替策として、<your-server-context-root>/health エンドポイントをカスタムルートでブロックできます。

以下に例を示します。

  1. TLS edge termination 用に設定された Keycloak を作成します。

    tlsSecret フィールドは必ず省略してください。 

    apiVersion: k8s.keycloak.org/v2alpha1
kind: Keycloak
metadata:
  name: example-kc
spec:
  additionalOptions:
    - name: proxy
      value: edge
  hostname:
    hostname: example.com
  ...
    Copy to Clipboard Toggle word wrap

  2. ヘルスエンドポイントへのアクセスを禁止するブロッキングルートを作成します。 

    kind: Route
apiVersion: route.openshift.io/v1
metadata:
  name: example-kc-block-health
  annotations:
    haproxy.router.openshift.io/rewrite-target: /404
spec:
  host: example.com
  path: /health
  to:
    kind: Service
    name: example-kc-service
  port:
    targetPort: http
  tls:
    termination: edge
    Copy to Clipboard Toggle word wrap
注記

パスベースのルートでは、エッジまたは再暗号化のいずれかに対して TLS Termination を設定する必要があります。デフォルトでは、Operator はパススルーを使用します。

3.3.6. Pod テンプレートを使用した高度なデプロイメントオプションの移行
リンクのコピー

Red Hat Single Sign-On 7.6 Operator は、ボリュームなどのデプロイメント設定用の複数の低レベルフィールドを公開していました。Red Hat build of Keycloak Operator は事前設定される部分が多く、これらのフィールドのほとんどは公開されません。ただし、podTemplate として指定されたデプロイメントフィールドを設定することは可能です。次に例を示します。 

apiVersion: k8s.keycloak.org/v2alpha1
kind: Keycloak
metadata:
  name: example-kc
spec:
  unsupported:
    podTemplate:
      metadata:
        labels:
          foo: "bar"
      spec:
        containers:
          - volumeMounts:
              - name: test-volume
                mountPath: /mnt/test
        volumes:
          - name: test-volume
            secret:
              secretName: test-secret
  ...
Copy to Clipboard Toggle word wrap
注記

spec.unsupported.podTemplate フィールドは、すべての条件下で機能が十分にテストされていない低レベルの設定を公開するため、サポートが限定的になります。可能な限り、CR 仕様の最上位で、完全にサポートされているファーストクラスシチズンフィールドを使用してください。

たとえば、spec.unsupported.podTemplate.spec.imagePullSecrets の代わりに、spec.imagePullSecrets を直接使用します。

3.3.7. 外部インスタンスへの接続はサポート対象外
リンクのコピー

Red Hat Single Sign-On 7.6 Operator では、Red Hat Single Sign-On 7.6 の外部インスタンスへの接続がサポートされていました。Red Hat build of Keycloak Operator では、たとえば、クライアント CR を使用して既存のレルム内にクライアントを作成することは、サポートされなくなりました。

3.3.8. Horizontal Pod Autoscaler 対応デプロイメントの移行
リンクのコピー

Red Hat Single Sign-On 7.6 で Horizontal Pod Autoscaler (HPA) を使用するには、Keycloak CR の disableReplicasSyncing: true フィールドを設定し、サーバーの StatefulSet をスケーリングする必要がありました。これは不要になりました。Red Hat build of Keycloak Operator の Keycloak CR は、HPA によって直接スケーリングできるためです。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat