1. Transaction Manager for Microservices開発者ガイド
  2. Kubernetesクラスタへのインストール
  3. values.yamlファイルの構成

4.2 values.yamlファイルの構成

インストール・バンドルには、アプリケーションのマニフェスト・ファイルであるvalues.yamlファイルが含まれ、これにはMicroTxのデプロイメント構成の詳細が含まれます。

values.yamlファイルのサンプル値を置き換えて、MicroTxをデプロイするための環境の詳細、イメージの詳細および構成の詳細を指定します。

MicroTxをKubernetesクラスタにデプロイするときに、HelmはリモートDockerレジストリからMicroTxイメージをプルします。values.yamlファイルに、プルするイメージと、イメージのプル時に使用する資格証明を指定します。

MicroTxの構成の詳細を指定するには:

  1. MicroTxコンソールをデプロイするかどうかに応じて、任意のコード・エディタで次のYAMLファイルのいずれかを開きます。これらのファイルにはサンプル値が含まれています。
    • MicroTxコーディネータおよびMicroTxコンソールをデプロイするには、installation_directory\otmm-RELEASE\otmm\helmcharts\tmm\eeにあるvalues.yamlファイルを使用します。
    • MicroTxコーディネータのみをデプロイするには、installation_directory\otmm-RELEASE\otmm\helmcharts\tmmにあるvalues.yamlを使用します。このファイルには、MicroTxコンソールに固有のプロパティは含まれていません。
  2. サンプル値は、ご使用の環境に固有の値で置き換えてください。
    この項の表では、MicroTxのインストールに必要な環境、ストレージ、認可、認証、およびその他の構成の詳細のプロパティについて説明します。
  3. 変更内容を保存します。
  • 環境の詳細
    values.yamlファイルで、MicroTxをインストールする環境の詳細に関する情報を指定します。
  • イメージのプロパティ
    tmmImage下に、MicroTx Dockerイメージに関する情報を指定します。これらのプロパティの値の指定は必須です。
  • トランザクション・コーディネータのプロパティ
    tmmConfiguration下に、MicroTxを構成するための情報を指定します。
  • データ・ストアのプロパティ
    MicroTxはデータ・ストアを使用して、トランザクション状態の永続性を確保し、トランザクション・ログを格納します。
  • Istioの詳細
    values.yamlファイルで、設定したIstioイングレス・ゲートウェイの詳細を指定します。
  • キャッシュのプロパティ
    キャッシュを有効にしてパフォーマンスを向上させることができます。etcdまたはOracle Databaseに格納されているトランザクション・ログの読取りおよび書込み操作が最適化されます。
  • ロギングのプロパティ
    logging下に、MicroTxログの詳細を指定します。
  • メトリックのプロパティ
    metricsで、PrometheusがMicroTxコーディネータのメトリック・ログをスクレイプできるようにします。
  • 認可のプロパティ
    MicroTxは、すべてのリクエストでJWTトークンを伝播することで、参加側サービスおよびコーディネータ間の認可をサポートします。
  • 認証のプロパティ
    authentication下で、JSON Webトークン(JWT)認証を有効にします。
  • アイデンティティ・プロバイダのプロパティ
    identityProvider下に、MicroTxコーディネータが認証に使用するJSON Webトークン(JWT)のプロパティ値を入力します。
  • 暗号化キーのプロパティ
    encryption下に、MicroTxがアクセス・トークンおよびリフレッシュ・トークンの暗号化に使用する暗号化キーを指定します。これらのプロパティの値を指定する必要があるのは、tmmConfiguration.authorizationのauthTokenPropagationEnabledプロパティを有効化した場合です。
  • トランザクション・トークンのプロパティ
    transactionTokenに、トランザクション・トークンに使用するキー・ペアを指定します。
  • コンソール構成のプロパティ
    tmmConsoleConfigurationで、MicroTxコンソールのプロパティを指定します。

親トピック: Kubernetesクラスタへのインストール

4.2.1 環境の詳細

values.yamlファイルで、MicroTxをインストールする環境の詳細に関する情報を指定します。

プロパティ 説明
istioSystemNameSpace Istioをインストールしたネームスペース。デフォルトのネームスペースはistio-systemです。別のネームスペースにIstioをインストールした場合は、次のコマンドを実行して、クラスタ内のすべてのネームスペースを確認します。
kubectl get ns
applicationNameSpace MicroTxをデプロイするネームスペースを指定します。たとえば、otmmです。
tmmReplicaCount

作成するMicroTxポッド・レプリカの数を指定します。本番環境に3つ以上のレプリカが推奨されます。開発環境またはテスト環境では、使用できるレプリカがこれより少ない可能性があります。

親トピック: values.yamlファイルの構成

4.2.2 イメージのプロパティ

tmmImage下に、MicroTx Dockerイメージに関する情報を指定します。これらのプロパティの値の指定は必須です。

プロパティ 説明
image リモート・リポジトリにプッシュしたMicroTxイメージのタグを入力します。たとえば、oracle-tmm:RELEASEです。「リモートDockerリポジトリへのイメージのプッシュ」を参照してください。
imagePullPolicy インストール中に確実にイメージがプルされるように、Alwaysを入力します。
imagePullSecret 作成したKubernetesシークレットの名前を指定します。このシークレットは、リモート・リポジトリからDockerイメージをプルするために使用されます。たとえば、regcredです。DockerレジストリにアクセスするためのKubernetesシークレットの作成を参照してください。
下のコード・スニペットは、次のサンプル値を示しています 
tmmImage
。 
tmmImage:
  image: oracle-tmm:RELEASE
  imagePullPolicy: Always
  imagePullSecret: regcred

親トピック: values.yamlファイルの構成

4.2.3 トランザクション・コーディネータのプロパティ

tmmConfiguration下に、MicroTxを構成するための情報を指定します。

プロパティ 説明
tmmAppName 作成するMicroTxアプリケーションの名前を入力します。MicroTxをインストールすると、Helmによって、指定した名前のMicroTxアプリケーションが作成されます。後で指定する必要があるため、この名前を書き留めておきます。たとえば、tmm-appです。
tmmid インストールするMicroTxの各インスタンスを一意に識別する値を入力します。この一意識別子は5文字で指定する必要があり、使用できるのは英数字(a-z、A-Zおよび0-9)のみです。たとえば、TMM01です。

このIDを使用して、複数のインストールがある場合にMicroTxを識別します。すべてのレプリカが同じIDを持つため、このIDを使用して、MicroTxインストールの単一インスタンスのレプリカを区別することはできません。MicroTxをインストールした後は、この値を変更できません。

port このサービスをインストールするKubernetesクラスタ内のMicroTxに内部的にアクセスするポートを入力します。このポートでインバウンドおよびアウトバウンド・トラフィックを許可するために必要なネットワーク・ルールを作成します。後で指定する必要があるため、この番号を書き留めておきます。たとえば、9000です。
tmmExternalURL サービスをデプロイしたKubernetesクラスタの外部からMicroTxにアクセスするために、外部URLの作成に必要な詳細を入力します。Istioイングレス・ゲートウェイにアクセスするためのプロトコル、ホストおよびポート番号を入力します。「MicroTxへのアクセス」を参照してください。
httpClientTimeoutInSecs MicroTxコーディネータから参加側サービスに送信されるHTTPコールバックAPIリクエストをアクティブにしておく最長期間(秒)を指定します。0から900までの整数を入力してください。デフォルト値は180秒、最大値は900秒です。この値を0に設定すると、MicroTxによって制限が適用されません。コーディネータがHTTPコールバックAPIリクエストを参加側サービスに送信したとき、参加側サービスは指定の期間内に応答する必要があります。指定した期間内に参加側サービスが応答しないと、コーディネータによって送信されたHTTPリクエストはタイムアウトします。
xaCoordinator、lraCoordinatorまたはtccCoordinator マイクロサービスで使用するトランザクション・プロトコルに対してenabled: "true"を設定します。MicroTxは、XA、LRA、およびTCCの3つの分散トランザクション・プロトコルをサポートしています。XAトランザクションをLRAトランザクション内にネストする場合は、enabled: "true"をxaCoordinatorとlraCoordinatorの両方に対して設定します。
txMaxTimeout XAトランザクション・プロトコルのみ。トランザクションをアクティブにしておく最長期間(ミリ秒)を指定します。トランザクションのコミットまたはロールバックが指定した期間内に行われないと、トランザクションはロールバックされます。デフォルト値は600000 msです。
narayanaLraCompatibilityMode LRAトランザクション・プロトコルのみ。enabledをtrueに設定するのは、Narayana LRAコーディネータと連携するように実装され、MicroTxを使用してLRAトランザクションに参加するLRA参加側アプリケーションを使用する場合のみです。このモードを有効にすると、MicroTx LRA APIがNarayana LRAコーディネータAPIが返すのと同じレスポンス・データを返すことが保証されます。
maxRetryCount 障害が発生した場合にトランザクション・コーディネータが同じリクエストの送信を再試行する最大回数。たとえば、10です。
minRetryInterval 障害が発生した後でトランザクション・コーディネータが同じリクエストの送信を再試行するまでの最小間隔(ミリ秒)。デフォルト値は1000ミリ秒です。
maxRetryInterval 障害が発生した後でトランザクション・コーディネータが同じリクエストの送信を再試行するまでの最大再試行間隔(ミリ秒)。たとえば、10000です。
skipVerifyInsecureTLS

この値をfalseに設定し、安全なアクセスのために信頼できる認証局によって署名された有効な証明書を設定することをお薦めします。この値をfalseに設定すると、トランザクション・コーディネータは、信頼できる認証局によって署名された有効な証明書を使用して、HTTPSプロトコルを介して参加側アプリケーションにアクセスします。デフォルト値はfalseです。

この値をtrueに設定すると、トランザクション・コーディネータは、有効なSSL証明書を使用せずに、参加側アプリケーションのコールバックURLに安全でない方法でアクセスします。

注意:

本番環境では、この値をtrueに設定しないでください。
countersUpdateInterval データ収集時間間隔、またはMicroTxコンソールで最新のトランザクションに関する情報が更新されるレートを指定するため、120秒から1800秒までの値を入力します。300秒と入力すると、最新のトランザクションに関する情報がコンソールで300秒ごとに更新されます。デフォルト値は120秒です。MicroTxコンソールで「間隔」ボックスの値を変更して、この値を更新することもできます。

親トピック: values.yamlファイルの構成

4.2.4 データ・ストアのプロパティ

MicroTxはデータ・ストアを使用して、トランザクション状態の永続性を確保し、トランザクション・ログを格納します。

トランザクション・ログを格納するには、etcdクラスタ、Oracle Databaseまたは内部メモリーを使用できます。トランザクション・コーディネータの複数のレプリカを使用する場合、etcdクラスタまたはOracleデータベースをトランザクション・ログ・データ・ストアとして設定する必要があります。内部メモリーを使用する場合、トランザクション・コーディネータのレプリカを複数作成することはできません。MicroTxを再起動するたびにすべてのトランザクション詳細が失われるため、開発環境にのみ内部メモリーを使用します。

トランザクション・ログのデータ・ストアのタイプ

tmmConfiguration.storageの下に、MicroTxがトランザクション状態の永続化に使用するデータ・ストアのタイプを指定します。データ・ストアのタイプを指定した後、外部データ・ストアに接続するための追加の詳細を指定できます。

プロパティ 説明
type

次の値のいずれかを入力して、MicroTxがトランザクション情報の追跡に使用する永続データを指定します。

  • etcdをデータ・ストアとして使用する場合は、etcd。etcdデータ・ストアに接続するための詳細をstorage.etcdフィールドに指定する必要があります。
  • Oracle Databaseをデータ・ストアとして使用する場合は、db。Oracleデータ・ストアに接続するための詳細をstorage.dbフィールドに指定する必要があります。
  • etcdまたはOracle Databaseに接続するための詳細の入力をスキップし、かわりに内部メモリーを使用する場合は、memory。内部メモリーを使用すると、MicroTxを再起動するたびに、すべてのトランザクションの詳細が失われます。
completedTransactionTTL 完了トランザクション・レコードのトランザクション・データ・ストアでの存続時間(TTL)(秒単位)。指定できる値の範囲は60から1200秒です。指定した時間が終了すると、完了トランザクション・エントリはデータ・ストアから削除されます。

トランザクション・ログのデータ・ストアとしてのOracle Database

tmmConfiguration.storage.db下に、Oracle Databaseに接続するための詳細を指定します。etcdデータベースに接続している場合、または内部メモリーを使用している場合は、この項をスキップして、これらの値を指定しないでください。

次の表に、MicroTxデータ・ストアであるOracle Databaseに接続するために必要なプロパティを示します。

プロパティ 説明
connectionString

Oracle Databaseのデータ・ストアの接続文字列を入力します。

  • Oracle Autonomous Transaction Processingなどの資格証明ウォレットを使用するデータベースを使用している場合は、次の形式を使用して接続文字列を入力します:
    tcps://<database-host>:<database-portNumber>/<service_name>

    必要な詳細(プロトコル、ホスト、ポート、サービス名など)は、資格証明ウォレットを抽出したフォルダにあるtnsnames.oraファイルで確認できます。共有ExadataインフラストラクチャでのOracle Autonomous Databaseの使用のクライアント資格証明(ウォレット)のダウンロードに関する項を参照してください。

    たとえば:

    tcps://adb.us-phoenix-1.oraclecloud.com:1521/sales.adb.oraclecloud.com
    また、接続文字列に追加することで、retry_countやretry_delayなどのデータベース・タイムアウト・パラメータを渡すことができます。たとえば、 
    <connection-string>?retry_count=20&retry_delay=3
  • 非自律型Oracle Database (資格証明ウォレットを使用しないデータベース)を使用している場合は、次の形式を使用して接続文字列を入力します:
    <database-host-IPaddress>:<database-portNumber>/<databaseUniqueName>.<hostDomainName>
    たとえば:
    123.213.85.123:1521/CustDB_iad1vm.sub05031027070.customervcnwith.oraclevcn.com

    ここで、CustDB_iad1vm.sub05031027070.customervcnwithは、データベースまたはサービス名の一意の名前です。

  • Oracle RACデータベースを使用している場合は、SCANを使用したOracle RACデータベースへの接続についてを参照してください。
credentialSecretName Oracle Databaseに接続するための資格証明を含むKubernetesシークレットの名前を入力します。たとえば、db-secretです。「Oracle Database資格証明のKubernetesシークレットの作成」を参照してください。
connectionParams 接続パラメータのスペース区切りリストを入力します。指定できる接続パラメータの詳細は、https://pkg.go.dev/github.com/godror/godror#section-documentationを参照してください。たとえば、poolMinSessions=1 poolMaxSessions=300です。
walletConfigMap.configMapName このフィールドの値は、Autonomous Databaseなどの資格証明ウォレットを使用するデータベースに接続する場合にのみ指定します。他のデータベースの場合、このフィールドは空のままにできます。Autonomous Databaseインスタンスの資格証明ウォレット用に作成した構成マップの名前を入力します。「Autonomous Databaseクライアント資格証明の取得」を参照してください。たとえば、db-wallet-configmapです。

トランザクション・ログのデータ・ストアとしてのetcdデータベース

tmmConfiguration.storage.etcd下に、etcdデータベースに接続する詳細を指定します。Oracleデータベースに接続している場合、または内部メモリーを使用している場合は、この項をスキップして、これらの値を指定しないでください。

次の表に、MicroTxデータ・ストアであるetcdデータベースに接続するために必要なプロパティを示します。

この情報を入力する前に、次のタスクを完了し、必要な詳細を書き留めておいてください。

  1. etcdのRSA証明書の生成
  2. etcdのKubernetesシークレットの作成
プロパティ 説明
endpoints etcdデータベース・サーバーの外部IPアドレスを入力します。MicroTxをインストールするKubernetesクラスタにetcdクラスタをインストールした場合は、Kubernetesサービス名およびetcdクラスタ(ノード)のポートを値として指定します。それ以外の場合は、198.51.100.1:4002,198.51.100.2:4002,198.51.100.3:4002のように、etcdクラスタ・ノードのホスト名またはIPアドレスとポートのカンマ区切りリストを入力します。
skipHostNameVerification etcdデータベース・サーバーのIPアドレスを確認するには、これをfalseに設定します。これをtrueに設定すると、サーバーのホスト名またはIPアドレスは検証されません。このフィールドをtrueに設定できるのは、テスト環境または開発環境の場合のみです。

注意:

本番環境では、このフィールドをfalseに設定する必要があります。
credentialSecret.secretName コンテナ内のKubernetesシークレットへのパスを入力します。シークレットには、クライアント資格証明、クライアント・キーおよびクライアント証明書の保護に使用したパスワードが含まれます。たとえば、/etc/otmm/etcd-cert-secretです。「etcdのKubernetesシークレットの作成」を参照してください。
credentialSecret.secretFileName クライアント資格証明、クライアント・キーおよびクライアント証明書の保護に使用したパスワードを含むJSONファイルの場所を入力します。たとえば、/etc/otmm/etcdecred.jsonです。「etcdのRSA証明書の生成」を参照してください。
cacertConfigMap.configMapName 認証局の初期化中に作成した構成マップ・ファイルの名前を入力します。たとえば、etcd-ca-cert-mapです。「etcdのKubernetesシークレットの作成」を参照してください。
cacertConfigMap.configMapFileName 認証局の初期化中に作成したPEMファイルの名前を入力します。たとえば、ca.pemです。「etcdのRSA証明書の生成」を参照してください。
次のコード・スニペットは、「etcdのRSA証明書の生成」および「etcdのKubernetesシークレットの作成」のトピックに記載されているサンプル値に基づくサンプル値を示しています。
storage:
    type: etcd
    etcd:
      endpoints: "https://198.51.100.1:4002"
      skipHostNameVerification: "false"
      credentialSecret:
        secretName: "etcd-cert-secret"
        secretFileName: "etcdecred.json"
      cacertConfigMap:
        configMapName: "etcd-ca-cert-map"
        configMapFileName: "ca.pem"

endpointsフィールドに正しいIPアドレスを指定しない場合、MicroTxのインストール時にホスト検証が失敗します。

親トピック: values.yamlファイルの構成

4.2.5 Istioの詳細

values.yamlファイルで、設定したIstioイングレス・ゲートウェイの詳細を指定します。

始める前に、Istioを設定および構成済であることを確認してください。「必要なソフトウェアのインストールおよび構成」を参照してください。

プロパティ 説明
istioIngressGateway 作成したIstioイングレス・ゲートウェイの名前を入力します。たとえば、ingressgatewayです。Istioイングレス・ゲートウェイの名前を確認するには、次のコマンドを実行して、レスポンスのistioラベルの値を書き留めます。
kubectl describe service/istio-ingressgateway -n istio-system
tlsEnabled HTTPSプロトコルを使用したサービスへのアクセスを有効にするには、これをtrueに設定します。これをtrueに設定する場合、HTTPSを使用してIstioにアクセスするためのSSLキーおよび証明書を含むKubernetesシークレットの詳細を指定する必要があります。

ノート:

本番環境では、この値をtrueに設定する必要があります。
credentialName tlsEnabledがtrueに設定されている場合、このプロパティの値を指定する必要があります。HTTPSプロトコルを使用したIstioへのアクセスを有効にするには、作成したKubernetesシークレットの名前を入力します。「Istio用のSSL詳細を含むKubernetesシークレットの作成」を参照してください。たとえば、tls-credentialです。
hosts Istioイングレス・ゲートウェイの外部IPアドレスまたはホストの名前を入力します。ロード・バランサを使用しているか、または複数のホストがある場合は、ホスト名またはIPアドレスのカンマ区切りリストを入力します。Istioイングレス・ゲートウェイのIPアドレスの確認を参照してください。
下のコード・スニペットは、次のサンプル値を示しています 
istioIngressGateway
。 
istioIngressGateway:
  name: ingressgateway
  tlsEnabled: "true"
  credentialName: tls-credential
  hosts: 192.0.2.1

親トピック: values.yamlファイルの構成

4.2.6 キャッシュのプロパティ

キャッシュを有効にしてパフォーマンスを向上させることができます。etcdまたはOracle Databaseに格納されているトランザクション・ログの読取りおよび書込み操作が最適化されます。

プロパティ 説明
enabled コーディネータのローカル・キャッシュを有効にするには、trueと入力します。これをtrueに設定できるのは、etcdクラスタまたはOracle Databaseを使用してトランザクション情報を格納する場合のみです。内部メモリーをトランザクション・ストアとして使用する場合は、キャッシュを有効にできません。
maxCapacity キャッシュの最大記憶域容量として10進数の値をGB単位で入力します。たとえば、1.5です。デフォルト値は1です。入力する最大値をサポートするために必要なメモリーがご使用の環境にあることを確認します。

キャッシュを有効にする場合は、コーディネータのセッション・アフィニティも有効にする必要があります。「セッション・アフィニティの有効化」を参照してください。

次のコード・スニペットは、values.yamlファイルのcachingプロパティのサンプル値を示しています。 

caching:
  enabled: true
  maxCapacity: 1.5

親トピック: values.yamlファイルの構成

4.2.7 ロギングのプロパティ

logging下に、MicroTxログの詳細を指定します。

プロパティ 説明
level 次のいずれかのタイプを入力して、MicroTxのログ・レベルを指定します:
  • info: MicroTxの通常の操作中に発生するイベントを記録します。この設定では、最小限の情報を記録します。これはデフォルトの設定です。
  • warning: 有害な状況を引き起こす可能性のあるイベントをログに記録します。
  • error: トラブルシューティングが必要な問題があることを示すためにイベントをログに記録します。
  • debug: すべてのイベントをログに記録します。この設定は、問題をデバッグする場合に使用します。
httpTraceEnabled デバッグ時にMicroTx内のすべてのHTTPリクエストおよびレスポンスをログに記録するには、これをtrueに設定します。この値をtrueに設定する場合、levelもdebugに設定する必要があります。

次のコード・スニペットは、values.yamlファイルのloggingプロパティのサンプル値を示しています。 

logging:
  level: debug
  httpTraceEnabled: true

親トピック: values.yamlファイルの構成

4.2.8 メトリックのプロパティ

metricsで、PrometheusがMicroTxコーディネータのメトリック・ログをスクレイプできるようにします。

プロパティ 説明
enabled PrometheusがMicroTxコーディネータのメトリック・ログをスクレイプできるように、これをtrueに設定します。デフォルトでは、これはtrueに設定されています。

次のコード・スニペットは、values.yamlファイルのmetricsプロパティのサンプル値を示しています。 

metrics:
  enabled: true

親トピック: values.yamlファイルの構成

4.2.9 認可のプロパティ

MicroTxは、すべてのリクエストでJWTトークンを伝播することで、参加側サービスおよびコーディネータ間の認可をサポートします。

tmmConfiguration.authorizationで、authTokenPropagationEnabledフィールドを使用してこの機能を制御します。アイデンティティ・プロバイダが期限切れアクセス・トークンをコーディネータで自動リフレッシュするように構成します。

プロパティ 説明
enabled これをtrueに設定すると、MicroTxコーディネータのAPIアクセスにRBACルールが適用されます。認可の最初のステップは、MicroTxコーディネータでRBAC制御を適用することです。

注意:

本番環境では、このフィールドをtrueに設定する必要があります。
authTokenPropagationEnabled 参加側サービスとMicroTxの間のセキュアな通信を確保するためにトークン伝播を有効にするには、これをtrueに設定します。MicroTxは次のアクションを実行します:
  • MicroTxライブラリは、すべての送信コールの認可ヘッダーをMicroTxコーディネータに伝播します。コーディネータは、認可チェックで受信リクエストの伝播されたアクセス・トークンを使用します。
  • MicroTxコーディネータは、アクセス・トークンおよびリフレッシュ・トークンの詳細を暗号化してトランザクション・ストアに格納します。これらのトークンは、MicroTxコーディネータからのコールバックAPIコールで、参加側アプリケーションに存在するMicroTxライブラリに追加されます。

トークン伝播を有効にした場合は、values.yamlファイルのencryptionプロパティに暗号化キーの詳細を指定する必要があります。

親トピック: values.yamlファイルの構成

4.2.10 認証のプロパティ

authentication下で、JSON Webトークン(JWT)認証を有効にします。

プロパティ 説明
requestsWithNoJWT DENYと入力すると、ロール・ベースのアクセス制御(RBAC)などの認可チェックがコーディネータで有効になります。これにより、各リクエストにJWTトークンが含まれるようになります。

JWT認証をバイパスするには、ALLOWを入力します。こうすると、JWTトークンのないリクエストが許可されます。

注意:

本番環境では、このフィールドをDENYに設定する必要があります。

DENYに設定する場合は、アイデンティティ・プロバイダのプロパティの値を指定する必要があります。「アイデンティティ・プロバイダのプロパティ」を参照してください。

次のコード・スニペットは、values.yamlファイルのauthenticationフィールドのサンプル値を示しています。 

authentication:
  requestsWithNoJWT: DENY

親トピック: values.yamlファイルの構成

4.2.11 アイデンティティ・プロバイダのプロパティ

identityProvider下に、MicroTxコーディネータが認証に使用するJSON Webトークン(JWT)のプロパティ値を入力します。

authentication.requestsWithNoJWTをDENYに設定する場合は、次の表にリストされているすべてのアイデンティティ・プロバイダのプロパティの値を指定する必要があります。

ただし、audience、adminUserRoles、adminUserRolesPathおよびclientSecretNameプロパティの値は、ユーザーがMicroTxコンソールにアクセスできるようにする場合に指定します。MicroTxコンソールへのアクセスを提供しない場合は、これらのプロパティの値の指定をスキップできます。

プロパティ 説明
serverType アイデンティティ・プロバイダとしてOracle IDCSを使用している場合は、idcsと入力します。そうでない場合は、otherと入力します。デフォルト値はotherです。
scopes serverTypeがidcsの場合は、異なるレベルのアクセス権を付与するスコープを指定する必要があります。Oracle IDCSをアイデンティティ・プロバイダとして使用していない場合は、このプロパティの値を指定しないでください。Oracle IDCSの場合は、スコープのスペース区切りリストを入力します。Oracle IDCSのデフォルトのスコープはopenid groupsです。
issuer JWTトークン発行元を指定します。設定したアイデンティティ・サーバーのURIを入力します。これは、検出URLのissuerフィールドの値です。たとえば、https://identity.oraclecloud.comとなります。「検出URLの実行」を参照してください。
jwksUri アイデンティティ・プロバイダのパブリック・ホストjwksUriのURL。JWTの署名の検証に使用されます。JSON Web Key Set (JWKS)には、受信JWTトークンの検証に使用される暗号化キーが含まれます。「検出URLの実行」を参照してください。
identityProviderUrl JWTアイデンティティ・プロバイダのURLを指定します。この情報は、リフレッシュ・トークンを使用して新しいアクセス・トークンを作成するために必要です。この情報を指定しないと、期限切れになったアクセス・トークンが自動リフレッシュされません。たとえば、アイデンティティ・プロバイダとしてKeycloakを使用する場合、http://192.0.2.1:8080/auth/realms/tmmdevとなります。「検出URLの実行」を参照してください。
audience トークンのオーディエンスを入力します。すべてのJWTはオーディエンスをチェックするために検証されます。MicroTxコンソールにアクセスするには、このパラメータの値を指定する必要があります。JWTアクセス・トークンからこの値をメモします。
adminUserRoles MicroTx管理者APIへのアクセス権を付与するには、アイデンティティ・プロバイダで構成した管理者ロールの名前のカンマ区切りリストを入力します。このロールを付与されているユーザーのみがコンソールへのアクセスを許可されます。たとえば、admin, consoleadminなどです。「YAMLファイルでの管理ロールの指定」を参照してください。
adminUserRolesPath JWTトークンに管理者ロールへのパスを入力します。たとえば、realm_access, rolesなどです。「YAMLファイルでの管理ロールの指定」を参照してください。
clientSecretName ユーザーがMicroTxコンソールにアクセスできるようにするには、作成したKubernetesシークレットの名前を入力します。「アイデンティティ・プロバイダ・クライアント資格証明を含むシークレットの作成」を参照してください。

次のコード・スニペットは、values.yamlファイルのauthenticationフィールドのサンプル値を示しています。この例のサンプル値は、「検出URLの実行」および「YAMLファイルでの管理ロールの指定」に基づいています。 

identityProvider:
    issuer: "https://identity.oraclecloud.com"
    jwksUri: "https://idcs-a83e4...identity.oraclecloud.com:443/admin/v1/SigningCert/jwk"
    identityProviderUrl: "https://idcs-a83e4...identity.oraclecloud.com/oauth2/v1/token"
    audience: "account"
    adminUserRoles: "admin"
    adminUserRolesPath: "userAppRoles"
    clientSecretName: "console-identity-client-secret"

テナント・ベースURLの例https://idcs-a83e4...identity.oraclecloud.comは、読みやすくするために省略記号(...)を使用して一部を省いています。現在の環境の完全な値をコピーしてください。

親トピック: values.yamlファイルの構成

4.2.12 暗号化キーのプロパティ

encryption下に、MicroTxがアクセス・トークンおよびリフレッシュ・トークンの暗号化に使用する暗号化キーを指定します。これらのプロパティの値を指定する必要があるのは、tmmConfiguration.authorizationのauthTokenPropagationEnabledプロパティを有効化した場合です。

プロパティ 説明
encryptionSecretKeyVersion 指定したシークレット・キーのリストから、トランザクション・トークンの暗号化に使用するシークレット・キーのバージョンを指定します。
encryptionSecretKeys.secretKeys.SecretKeyName 値として暗号化キーを含むKubernetesシークレットの名前およびバージョンを指定します。暗号化キーのローテーションをサポートするために、複数の暗号化キーとそのバージョンを指定できます。
encryptionSecretKeys.secretKeys.version Kubernetesシークレットのバージョンとして自然数を入力します。各シークレット・キーのバージョンが一意であることを確認してください。

新しいKubernetesシークレット・キーを作成しても、前のシークレット・キーのエントリを直ちに削除しないでください。古いキーとvalues.yamlファイル内の対応するエントリは数日してから削除できます。既存のトランザクションで古いバージョンのキーが使用されている可能性があるためです。数日後、values.yamlファイルを更新し、MicroTxを更新できます。

次のコード・スニペットは、values.yamlファイルのencryptionフィールドのサンプル値を示しています。この例のサンプル値は、暗号化キーのKubernetesシークレットの生成のサンプル・コマンドで使用された値に基づいています。 

encryption:
  encryptionSecretKeyVersion: "1"
  encryptionSecretKeys:
    secretKeys:
      - secretKeyName: "encryption-secret-key1"
        version: "1"
      - secretKeyName: "encryption-secret-key2"
        version: "2"

親トピック: values.yamlファイルの構成

4.2.13 トランザクション・トークンのプロパティ

transactionTokenに、トランザクション・トークンに使用するキー・ペアを指定します。

transactionTokenEnabledをtrueに設定する場合は、次の表に示す値の指定が必須です。

プロパティ 説明
transactionTokenEnabled MicroTxで署名付きトランザクション・トークンtmm-tx-tokenをリクエスト・ヘッダーに含める場合は、これをtrueに設定します。ユーザーがtmm-tx-tokenトランザクション・トークンを作成したり、リクエスト・ヘッダーで渡したりする必要はありません。MicroTxライブラリは、指定した秘密キーと公開キーのペアに基づいてこのトークンを作成します。キー・ペアの作成の詳細は、トランザクション・トークンのキー・ペアの作成を参照してください。
transactionTokenKeyPairVersion トランザクション・トークンの署名および検証に使用するキー・ペアのバージョンを入力します。複数のキー・ペアがある場合は、使用するキー・ペアのバージョンを指定する必要があります。
transactionTokenKeyPairs.keyPairs.privateKeyName 秘密キーのbase64エンコード値を含むKubernetesシークレットの名前を入力します。
transactionTokenKeyPairs.keyPairs.publicKeyName 公開キーのbase64エンコード値を含むKubernetesシークレットの名前を入力します。
transactionTokenKeyPairs.keyPairs.privateKeyPasswordName 秘密キーの生成時に指定したパスフレーズの値を含むKubernetesシークレットの名前を入力します。
transactionTokenKeyPairs.keyPairs.version 使用する秘密キーと公開キーのペアのバージョンを入力します。

次のコード・スニペットは、transactionTokenフィールドのサンプル値を示しています。 

transactionToken:
  transactionTokenEnabled: "true"
  transactionTokenKeyPairVersion: "1"
  transactionTokenKeyPairs:
    keyPairs:
      - privateKeyName: "TMMPRIVKEY1"
        publicKeyName: "TMMPUBKEY1"
        privateKeyPasswordName: "TMMPRIVKEYPASSWD1"
        version: "1"
      - privateKeyName: "TMMPRIVKEY2"
        publicKeyName: "TMMPUBKEY2"
        privateKeyPasswordName: "TMMPRIVKEYPASSWD2"
        version: "2"

親トピック: values.yamlファイルの構成

4.2.14 コンソール構成のプロパティ

tmmConsoleConfigurationで、MicroTxコンソールのプロパティを指定します。

プロパティ値を指定する前に、必ず次のタスクを完了してください。

次の表で指定されているすべてのプロパティの値を指定する必要があります。

プロパティ 説明
tmmConsoleAppName

作成するMicroTxアプリケーションの名前です。Helmは、指定した名前でコンソール・アプリケーションを作成します。

アプリケーションを識別する一意の名前を指定します。名前の先頭と末尾は英数字で、4文字から63文字とし、小文字のみを含める必要があります。オプションで、特殊文字としてハイフン(-)およびドット(.)を使用できます。たとえば、otmm-consoleとなります。

tmmConsoleImage.image リモート・リポジトリ内のコンソール・イメージのパスを入力します。たとえば、iad.ocir.io/mytenancy/Console:RELEASEとなります。

値を指定しない場合、コンソール・アプリケーションはデプロイされません。
tmmConsoleImage.imagePullPolicy インストール中に確実にイメージがプルされるように、Alwaysを入力します。
tmmConsoleImage.imagePullSecret Dockerイメージのプルに使用するKubernetesシークレットの名前を指定します。DockerレジストリにアクセスするためのKubernetesシークレットの作成を参照してください。たとえば、regcredです。
port ポート番号を指定します。このポートとMicroTxコンソールの間のトラフィックが許可されるように、必要なネットワーキング・ルールが設定されていることを確認します。
cookieEncryptionPasswordSecretName コンソールのCookie暗号化パスワードを格納するために作成したKubernetesシークレットの名前を指定します。「Cookie暗号化パスワードを含むシークレットの作成」を参照してください。たとえば、console-cookie-encryption-password-secretとなります。

次のコード・スニペットは、tmmConsoleConfigurationのサンプル値を示しています。 


tmmConsoleConfiguration:
  tmmConsoleAppName: otmm-console
  # If tmmConsoleImage.image is empty, the console application is not deployed.
  tmmConsoleImage: 
    image: iad.ocir.io/mytenancy/Console:RELEASE
    imagePullPolicy: Always
    imagePullSecret: regcred
  port: 8080
  cookieEncryptionPasswordSecretName: "console-cookie-encryption-password-secret"

親トピック: values.yamlファイルの構成