1. Transaction Manager for Microservices開発者ガイド
  2. Kubernetesクラスタへのインストール

4 Kubernetesクラスタへのインストール

マイクロサービス対応トランザクション・マネージャ(MicroTx)は、DockerまたはKubernetesクラスタにインストールできます。

KubernetesクラスタにMicroTxをインストールする場合は、この項をスキップして、「Docker Swarmへのインストール」を参照してください。

Kubernetesでは、MicroTxをサービス・メッシュ内にインストールすることもサービスなしでインストールすることもできます。インストール・バンドルにはHelmチャートが用意されています。この項では、Istioサービス・メッシュを使用してKubernetesクラスタにMicroTxをインストールする手順を示します。同様の構成を作成すると、サポートされている他の環境にMicroTxをインストールできます。Kubernetesクラスタで別のサービス・メッシュを使用する場合は、独自のHelmチャートを作成します。

次の図は、MicroTxが、他のマイクロサービスとともにKubernetesクラスタのIstioサービス・メッシュ内にインストールされたデプロイメント例を示しています。

MicroTxのコンポーネント

Istioは、サービス間通信を処理するために個別のインフラストラクチャ・レイヤーを提供するサービス・メッシュです。ネットワーク通信がサービスそのものから取り出されて、プロキシによって処理されます。Istioではサイドカー設計が使用されています。つまり、通信プロキシは各サービス・コンテナ外部の独自のコンテナ内で実行されます。Envoyは、マイクロサービス・コンテナ内にサイドカーとしてデプロイされるプロキシです。サービス・メッシュ内のすべての通信は、Envoyプロキシを介して行われます。

開始する前に、前提条件を満たしていることを確認します。準備を参照してください。

MicroTxをインストールするには、次の手順を実行します:

  1. Kubernetesクラスタの作成
  2. 環境の準備
  3. DockerレジストリにアクセスするためのKubernetesシークレットの作成
  4. リモートDockerリポジトリへのイメージのプッシュ
  5. 認証および認可
  6. values.yamlファイルの構成
  7. MicroTxのインストール
  • Kubernetesクラスタの作成
    Kubernetesクラスタを作成するか、既存のクラスタを使用します。このクラスタにMicroTxをインストールします。
  • 環境の準備
    MicroTxをインストールする前に、必要なソフトウェアをローカル・マシンにインストールし、ローカル・マシンに環境を構成する必要があります。
  • DockerレジストリにアクセスするためのKubernetesシークレットの作成
    Helmを使用してアプリケーションをインストールする場合は、Kubernetesシークレットを使用して、リモート・リポジトリからイメージをプルするための認証詳細を指定します。
  • リモートDockerリポジトリへのイメージのプッシュ
    ローカル・システムにダウンロードしたインストール・バンドルには、MicroTxのDockerイメージが含まれます。
  • 認証および認可
    認証によって、権限のある個人のみがシステムおよびデータにアクセスできるようになります。認可によって、システム権限およびデータへのアクセス制御が提供されます。これは認証に基づいて、個人が適切なアクセス権を取得することを保証します。
  • Oracle Database資格証明のKubernetesシークレットの作成
    MicroTxでは、トランザクション情報を追跡するための永続ストアとしてOracle Databaseの使用がサポートされます。
  • etcdのKubernetesシークレットの作成
    values.yamlファイルにetcd資格証明およびetcdエンドポイントを指定する必要があります。MicroTxは、この情報を使用して、サービスのインストール後にetcdへの接続を確立します。
  • セッション・アフィニティの有効化
    セッション・アフィニティを有効にすると、一意のトランザクションまたはセッションに対するすべてのリクエストは、最初のリクエストを処理した参加側サービスの同じエンドポイントまたはレプリカにルーティングされます。
  • values.yamlファイルの構成
    インストール・バンドルには、アプリケーションのマニフェスト・ファイルであるvalues.yamlファイルが含まれ、これにはMicroTxのデプロイメント構成の詳細が含まれます。
  • MicroTxのインストール
    Helmを使用して、MicroTxをKubernetesクラスタにインストールします。
  • Istioイングレス・ゲートウェイのIPアドレスの確認
    トランザクションを開始する前に、Istioイングレス・ゲートウェイの外部IPアドレスを書き留める必要があります。
  • MicroTxへのアクセス
    MicroTxにアクセスするには、アクセスに使用するポート番号、ホスト名およびプロトコルを指定します。HTTPプロトコルはテスト環境または開発環境でのみ使用することをお薦めします。本番環境では、HTTPSプロトコルを使用する必要があります。

4.1 Kubernetesクラスタの作成

Kubernetesクラスタを作成するか、既存のものを使用します。このクラスタにMicroTxをインストールします。

開始する前に、次の方法で環境を計画する必要があります:

  • MicroTxをホストするために単一ノードと複数ノードのどちらのKubernetesクラスタが必要かを決定します。開発環境では1つ以上の単一ノード・クラスタを作成し、本番環境では1つ以上の3ノード・クラスタを作成することをお薦めします。
  • 環境内の様々なコンポーネントを識別します。マイクロサービスがKubernetesクラスタで実行されている場合は、同じクラスタまたは別のクラスタにMicroTxをインストールできます。マイクロサービスが複数のKubernetesクラスタに分散されている場合、またはKubernetesクラスタに含まれないOracle DatabaseやTuxedoなどのコンポーネントとMicroTxが通信できるようにする場合は、MicroTxをホストするKubernetesクラスタを作成します。

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

4.2 環境の準備

MicroTxをインストールする前に、必要なソフトウェアをローカル・マシンにインストールし、ローカル・マシンに環境を構成する必要があります。

次の手順を実行して、必要なソフトウェアをインストールし、ローカル・マシンに環境を構成します:

  1. Kubernetesクラスタを操作するために、Kubernetesコマンドライン・インタフェース(Kubectl)バージョン1.21.x以降をインストールします。https://kubernetes.io/docs/tasks/tools/を参照してください。
    Kubectlを使用して、デプロイメントを作成および管理します。Kubectlは、Kubernetes APIを使用してクラスタとやり取りします。
  2. 最新バージョンのHelm 3.xをローカル・マシンにインストールします。詳細は、https://helm.sh/docs/intro/install/を参照してください。
    Helmを使用するとデプロイメントが容易になります。1つのコマンドを実行してアプリケーションとリソースをKubernetesクラスタにインストールできるためです。HelmはKubernetes APIサーバーとやり取りして、Kubernetesリソースのインストール、アップグレード、問合せおよび削除を行います。
  3. Istioバージョン1.12.1以降をデフォルトのIstioプロファイルを使用してKubernetesクラスタにインストールします。
    1. 次のコマンドを実行してIstioをダウンロードします。
      curl -sL https://istio.io/downloadIstioctl | sh -
    2. Istioパッケージのディレクトリに移動します。たとえば、パッケージがistio-1.12.1の場合:
      cd istio-1.12.1
    3. binフォルダにあるistioctlクライアント・ツールをワークステーションのPATHに追加します。次の例では、サンプル値が指定されています。ご自身の環境に基づいてパスを指定してください。
      export PATH=$PWD/bin:$PATH
    4. 前提条件チェックを実行して、クラスタがIstioのインストール要件を満たしているかどうかを検証します。
      istioctl x precheck

      次のメッセージが表示されます。次の手順に進み、問題がない場合はIstioをインストールできます。

      No issues found when checking the cluster. Istio is safe to install or upgrade!
    5. デフォルトのIstioプロファイルを使用して、KubernetesクラスタにIstioをインストールします。本番環境ではデフォルトのIstioプロファイルを使用することをお薦めします。さらに、次のコマンドを使用して、メッシュ・レベルでのJSON形式のログに対する分散トレースおよびプロキシ・アクセスを有効にします:
      istioctl install --set meshConfig.accessLogFile=/dev/stdout \
    --set meshConfig.accessLogEncoding=JSON \
    --set meshConfig.enableTracing=true \
    --set meshConfig.defaultConfig.tracing.sampling=100.0

    これによって、監査に使用できるアクセス・ログが作成されます。分散トレースを有効にして、マイクロサービスベースの分散システムの監視とトラブルシューティングを行います。たとえば、分散トランザクションの監視、根本原因の分析、サービスの依存関係の分析、パフォーマンスまたはレイテンシの最適化などです。

    Oracle Linux 8環境の場合のみ、次のコマンドを実行して追加のフラグ--set components.cni.enabled=trueを渡します。 

    istioctl install --set meshConfig.accessLogFile=/dev/stdout \
    --set meshConfig.accessLogEncoding=JSON \
    --set meshConfig.enableTracing=true \
    --set meshConfig.defaultConfig.tracing.sampling=100.0 \
    --set components.cni.enabled=true

    詳細は、https://istio.io/latest/docs/setup/additional-setup/config-profiles/を参照してください。

  4. Kubernetesクラスタにマイクロサービス対応トランザクション・マネージャをデプロイするためのネームスペースを作成します。次のコマンドによって、otmmという名前のネームスペースが作成されます(otmmは、作成するネームスペースの名前):

    サンプル・コマンド

    kubectl create ns otmm

    サンプル・レスポンス

    namespace/otmm created
  5. 作成したネームスペースにistio-injection=enabledというラベルを付けて、サイドカーの自動インジェクションを有効にします。次のコマンドによって、otmmネームスペースにラベルが付けられます:

    サンプル・コマンド

    kubectl label namespace otmm istio-injection=enabled

    サンプル・レスポンス

    namespace/otmm labeled

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

4.3 DockerレジストリにアクセスするためのKubernetesシークレットの作成

Helmを使用してアプリケーションをインストールする場合は、Kubernetesシークレットを使用して、リモート・リポジトリからイメージをプルするための認証詳細を指定します。

指定したすべてのログイン詳細がKubernetesシークレットに含まれるのは、資格証明を含むdocker loginコマンドを使用してリモートDockerレジストリに手動でログインした場合です。

  1. 次のコマンドを使用してコマンドラインに資格証明を指定することで、シークレットを作成します。
    kubectl create secret docker-registry NAME --docker-server=SERVER --docker-username=USERNAME --docker-password=PASSWORD --docker-email=EMAIL --namespace=NAMESPACE

    説明

    • NAME: 作成するKubernetesシークレットの名前。この名前を書き留めておきます。後からシークレットを参照するためにマニフェスト・ファイルでこの名前を使用するためです。
    • SERVER: プライベートDockerレジストリの名前。形式は、Kubernetesプラットフォームによって異なります。たとえば、Oracle Cloud Infrastructure環境でのユーザー名の形式は<region-key>.ocir.ioです。
    • USERNAME: リモートDockerレジストリにアクセスするためのユーザー名。形式は、Kubernetesプラットフォームによって異なります。たとえば、Oracle Cloud Infrastructure環境でのユーザー名の形式は<tenancy-namespace>/<oci-username>です。
    • PASSWORD: リモートDockerレジストリにアクセスするためのパスワード。
    • EMAIL: Dockerレジストリの電子メールID。
    • NAMESPACE: MicroTxをデプロイするネームスペース。

    例

    次のコマンドを使用して、otmmネームスペースにregcredという名前のKubernetesシークレットを作成します。 

    kubectl create secret docker-registry regcred --docker-server=iad.ocir.io --docker-username=mytenancy/myuser --docker-password=pwd --docker-email=myuser@example.com --namespace=otmm
  2. 作成したシークレットの名前を書き留めます。この値は後で指定する必要があります。
  3. ターミナルを閉じます。
    コマンドラインにシークレットを入力すると、そのシークレットが保護されていないシェル履歴に格納されることがあります。kubectlの実行中にこのシークレットがPCの他のユーザーにも表示される可能性があります。この問題を解消するには、シークレットを作成した後にターミナルを閉じてください。

既存の資格証明に基づいてシークレットを作成することもできます。https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentialsを参照してください。

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

4.4 リモートDockerリポジトリへのイメージのプッシュ

ローカル・システムにダウンロードしたインストール・バンドルには、MicroTxのDockerイメージが含まれます。

これらのイメージをローカル・リポジトリにロードしてから、イメージをリモートDockerリポジトリにプッシュします。Kubernetesは、これらのイメージをリモート・リポジトリからプルして、MicroTxをインストールします。

Oracle Cloud Infrastructure Registryを使用している場合は、Oracle Cloud Infrastructure Registryへのイメージのプッシュを参照してください。他のKubernetesプラットフォームを使用している場合は、この項で説明する手順を使用します。

開始する前に、次のタスクを完了してください。
  • コンテナ・イメージのアップロード先のリモート・プライベート・リポジトリを指定します。新しいリモートDockerリポジトリを作成することも、既存のリモートDockerリポジトリを使用することもできます。アクセスを制限するにはプライベート・リポジトリを使用します。リモートDockerリポジトリを使用する際、リモートDockerリポジトリにイメージをプッシュする必要があるのは1回のみですが、作成したKubernetesクラスタにイメージを複数回プルできます。
  • リモートDockerリポジトリにアクセスするためのKubernetesシークレットを作成します。DockerレジストリにアクセスするためのKubernetesシークレットの作成を参照してください。
次のステップを実行して、MicroTxのDockerイメージをリモートDockerリポジトリにプッシュします:
  1. イメージのプッシュ先のリモート・プライベート・リポジトリにログインするための資格証明を指定します。
    docker login <repo>

    使用しているKubernetesプラットフォームに基づいてログイン資格証明を指定します。

  2. MicroTxイメージをローカルDockerリポジトリにロードします。MicroTxイメージは、installation_directory/otmm-<version>/otmm/image/tmm-<version>.tgzにあります。
    cd installation_directory/otmm-<version>/otmm
docker load < image/tmm-<version>.tgz
    イメージがロードされると、次のメッセージが表示されます。
    Loaded image: tmm:<version>
  3. 次のコマンドを使用して、リモートDockerリポジトリにプッシュするイメージの一意のタグを指定します。

    構文

    docker tag local_image[:tag] remote_image[:tag]

    説明

    • local_image[:tag]は、イメージがローカル・リポジトリ内で識別されるタグです。
    • remote_image[:tag]は、リモートDockerリポジトリ内でイメージを識別するためのタグです。

    サンプル・コマンド

    docker tag tmm:<version> <region-key>.ocir.io/otmmrepo/tmm:<version>

    ここで、<region-key>.ocir.io/otmmrepoは、イメージ・ファイルtmm:<version>をプッシュするリモートDockerレジストリです。レジストリの詳細はご使用の環境に基づいて指定してください。

  4. ローカル・リポジトリからリモートDockerリポジトリにDockerイメージをプッシュします。

    構文

    docker push remote_image[:tag]
    サンプル・コマンド
    docker push <region-key>.ocir.io/otmmrepo/tmm:<version>

リモートDockerリポジトリのDockerイメージのタグを書き留めます。リモートDockerリポジトリからイメージをプルする際に、このタグを入力する必要があります。

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

4.5 認証および認可

認証によって、権限のある個人のみがシステムおよびデータにアクセスできるようになります。認可によって、システム権限およびデータへのアクセス制御が提供されます。これは認証に基づいて、個人が適切なアクセス権を取得することを保証します。

  • 暗号化キーのKubernetesシークレットの生成
    非同期コールをサポートするために、MicroTxによって、認可トークンおよびリフレッシュ・トークンが格納されます。トークンを格納するには、トークンを暗号化する必要があります。トークンを直接格納することはできないためです。トークンを暗号化するには、暗号化キーを作成します。
  • トランザクション・トークンのキー・ペアの作成
    アプリケーションは、各MicroTxトランザクションに固有のMicroTx署名付きトランザクション・トークンを含めることをサポートしています。

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

4.5.1 暗号化キーのKubernetesシークレットの生成

非同期コールをサポートするために、MicroTxは認可トークンとリフレッシュ・トークンを格納します。トークンを格納するには、トークンを暗号化する必要があります。トークンを直接格納することはできないためです。トークンを暗号化するには、暗号化キーを作成します。

MicroTxは、指定した暗号化キーを使用してトークンを暗号化します。MicroTxから参加側サービスへの非同期コールがある場合、MicroTxは、暗号化されたトークンをフェッチして復号化してから、そのトークンを認可ヘッダーに添付します。
authorizationのauthTokenPropagationEnabledプロパティを有効化した場合は、暗号化キーを生成し、そのキーをDockerシークレットに追加する必要があります。生成する暗号化キーには、次の属性が必要です。
  • 対称アルゴリズム: AES-256
  • 暗号モード: GCMモードのAES
  • キーの長さ: 32バイト
  • 初期化ベクトルの長さ: 96ビット

MicroTxは、アクセス・トークンおよびリフレッシュ・トークンを暗号化し、後で参加側サービスへのコール時に使用します。MicroTxは、トランザクションごとに初期化ベクトルの新しい値を生成します。各トランザクション・レコードには、キー・バージョンや初期化ベクトル値などの暗号化されたメタデータ情報が含まれます。

  1. 次のコマンドを実行して、キーの長さが32バイトの暗号化キーを生成します。
    openssl rand -hex 16
    生成された値を書き留めます。たとえば、e9f0adab17c0180425147166c2ff1cd3です。
  2. 生成した暗号化キーを値として使用して、Kubernetesシークレットを作成します。このシークレットは、MicroTxをインストールするネームスペースに作成する必要があります。

    次のサンプル・コマンドでは、encryption-secret-key1という名前のKubernetesシークレットがotmmネームスペースに作成されます。 

    kubectl create secret generic encryption-secret-key1 \ --from-literal=secret='e9f0adab17c0180425147166c2ff1cd3' -n otmm
  3. Kubernetesシークレットの名前とそのバージョンを書き留めます。これらの値は、values.yamlファイルのsecretKeyNameフィールドおよびversionフィールドに指定します。

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

    encryption:
  encryptionSecretKeyVersion: "1"
  encryptionSecretKeys:
      - secretKeyName: "encryption-secret-key0"
        version: "0"
      - secretKeyName: " encryption-secret-key1"
        version: "1"

親トピック: 認証および認可

4.5.2 トランザクション・トークンのキー・ペアの作成

アプリケーションは、各MicroTxトランザクションに固有のMicroTx署名付きトランザクション・トークンを含めることをサポートしています。

transactionTokenEnabledをtrueに設定すると、MicroTxは、署名付きトランザクション・トークンであるtmm-tx-tokenという新しいトークンを作成します。トランザクション・イニシエータがリクエストを開始すると、MicroTxはtmm-tx-tokenを使用して応答します。参加側サービスからMicroTxへのコールを保護するために、MicroTxライブラリはリクエスト・ヘッダーでtmm-tx-tokenを渡します。ユーザーがtmm-tx-tokenトランザクション・トークンを作成したり、リクエスト・ヘッダーで渡したりする必要はありません。MicroTxライブラリは、指定した秘密キーと公開キーのペアに基づいてこのトークンを作成します。

生成するトランザクション・トークンには、次の属性が必要です:
  • 非対称アルゴリズム: RSA 3072
  • キーの長さ: 3072ビット
  • ハッシュ・アルゴリズム: SHA256

開始する前に、OpenSSLをインストールしたことを確認します。

  1. 次のコマンドを使用して、キーの長さが3072ビットのRSA秘密キーを作成します:
    openssl genrsa -aes256 -out private.pem 3072
  2. コマンド・プロンプトでパスフレーズを入力し、[Enter]を押します。後で指定する必要があるため、パスフレーズを覚えておいてください。

    private.pemという名前の新しいファイルが現在の作業フォルダに作成されます。このファイルにRSA秘密キーの値が含まれています。

  3. 生成した秘密キーに対するRSA公開キーを作成します。以下のコマンドを使用します。

    次のコマンドによって、現在の作業フォルダにpublic.pemという名前の新しいファイルが作成されます。このファイルにRSA公開キーの値が含まれています。 

    openssl rsa -in private.pem -outform PEM -pubout -out public.pem
  4. 次のコマンドを実行して、private.pemファイルをbase64でエンコードします。

    コマンド例

    base64 private.pem

    private.pemファイルのbase64エンコード値が返されます。

    レスポンス例

    LS0tLS...LS0tLQo=

    レスポンス例は、読みやすくするために省略記号(...)を使用して一部を省いています。

    private.pemファイルのbase64エンコード値を書き留めます。

  5. private.pemファイルのbase64エンコード値を含むKubernetesシークレットを作成します。

    次のコマンドは、MicroTxをインストールするotmmネームスペースにTMMPRIVKEY1という名前のKubernetesシークレットを作成します。 

    kubectl create secret generic TMMPRIVKEY1 \ --from-literal=secret='LS0tLS...LS0tLQo=' -n otmm

    Kubernetesシークレットの名前を書き留めます。この値は、後でvalues.yamlファイルに指定する必要があります。

  6. 次のコマンドを実行して、public.pemファイルをbase64でエンコードします。

    コマンド例

    base64 public.pem

    public.pemファイルのbase64エンコード値が返されます。

    レスポンス例

    LS0tLS...LS0tCg==

    レスポンス例は、読みやすくするために省略記号(...)を使用して一部を省いています。

    public.pemファイルのbase64エンコード値を書き留めます。

  7. public.pemファイルのbase64エンコード値を含むKubernetesシークレットを作成します。

    次のコマンドは、otmmネームスペースにTMMPUBKEY1という名前のKubernetesシークレットを作成します。 

    kubectl create secret generic TMMPUBKEY1 \ --from-literal=secret='LS0tLS...LS0tCg==' -n otmm

    Kubernetesシークレットの名前を書き留めます。この値は、後でvalues.yamlファイルに指定する必要があります。

  8. 秘密キー・パスワードを値として含むKubernetesシークレットを作成します。

    次のコマンドは、otmmネームスペースにTMMPRIVKEYPASSWD1という名前とWelcome1というキー・パスワードでKubernetesシークレットを作成します。 

    kubectl create secret generic TMMPRIVKEYPASSWD1 \ --from-literal=secret='Welcome1' -n otmm

    ここで、pwd...は秘密キーのパスワードです。これを環境に固有の値に置き換えます。

    ノート:

    キー・パスワードをプレーン・テキスト形式で入力する必要があるため、キー・パスワードをbase64エンコードしないでください。

    Kubernetesシークレットの名前を書き留めます。この値は、後でvalues.yamlファイルに指定する必要があります。

親トピック: 認証および認可

4.6 Oracle Database資格証明のKubernetesシークレットの作成

MicroTxでは、トランザクション情報を追跡するための永続ストアとしてOracle Databaseの使用がサポートされます。

values.yamlファイルにOracle Database資格証明を指定する必要があります。MicroTxは、サービスのインストール後に資格証明を使用してデータベースへの接続を確立します。
Autonomous Databaseインスタンスを使用している場合は、次のステップを開始する前に、必ずウォレットをダウンロードして構成マップを作成してください。「Autonomous Databaseクライアント資格証明の取得」を参照してください。
Oracle Databaseログインの詳細を提供するKubernetesシークレットを作成するには:
  1. Oracle Databaseログインの詳細を使用してKubernetesシークレットを作成します。MicroTxをデプロイするネームスペースにKubernetesシークレットを作成してください。

    次のコマンドは、ユーザーacmeのパスワードを使用して、otmmネームスペースにdb-secretという名前のKubernetesシークレットを作成します。このコマンドを環境で実行する場合は、これらの値を環境に固有の値に置き換えます。 

    kubectl create secret generic db-secret \
    --from-literal=secret='{"password":"*****", "username":"acme"}' -n otmm
  2. 作成したKubernetesシークレットの名前を書き留めます。この名前は、MicroTxのデプロイ中にvalues.yamlファイルに指定する必要があります。
values.yamlを、Oracle Database資格証明および接続文字列を格納するために作成したKubernetesシークレットの名前で更新します。また、Autonomous Databaseインスタンスを使用している場合は、構成マップの名前を指定します。

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

4.7 etcdのKubernetesシークレットの作成

values.yamlファイルにetcd資格証明およびetcdエンドポイントを指定する必要があります。MicroTxは、この情報を使用して、サービスのインストール後にetcdへの接続を確立します。

開始する前に、etcdのRSA証明書を生成し、生成された証明書の内容を含むJSONファイルを作成します。「etcdのRSA証明書の生成」を参照してください。

同じKubernetesクラスタ内にetcdおよびMicroTxをデプロイする予定の場合は、TLSを使用してetcdを構成することはオプションです。etcdがTLSで構成されている場合は、トランザクション・コーディネータのvalues.yamlファイルに証明書の詳細を指定する必要があります。

KubernetesシークレットおよびKubernetes構成マップを作成するには:
  1. 作成したJSONファイルで使用可能なコンテンツを使用して、Kubernetesシークレットを作成します。MicroTxをデプロイするネームスペースにKubernetesシークレットを作成してください。
    kubectl create secret generic etcd-cert-secret \
    --from-file=location of etcdecred.json -n otmm

    説明

    • etcd-cert-secretは、作成するKubernetesシークレットの名前です。MicroTxをインストールするには、この名前をYAMLファイルに指定する必要があるため、この名前を書き留めます。
    • location of etcdecred.JSONは、前のステップで作成したJSONファイルの場所です。
    • otmmは、MicroTxをデプロイするネームスペースです。
  2. これより前に認証局の初期化中に作成したca.pemファイルの構成マップを作成します。MicroTxをデプロイするネームスペースに構成マップを作成してください。
    kubectl create configmap etcd-ca-cert-map --from-file=location of ca.pem -n otmm

    説明

    • etcd-ca-cert-mapは、作成する構成マップの名前です。MicroTxのvalues.yamlファイルにこの名前を指定するため、この名前を書き留めます。
    • location of ca.pemは、ca.pemファイルの場所です。
    • otmmは、MicroTxをデプロイするネームスペースです。
作成したetcdエンドポイント、証明書、KubernetesシークレットおよびKubernetes構成マップをvalues.yamlファイルに指定する必要があります。次のコード・スニペットでは、このトピックのコマンドで使用した値に基づいてサンプル値を指定しています。
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のインストール時にホスト検証が失敗します。開発環境でホスト検証をバイパスするには、MicroTxのvalues.yamlファイルでskipHostNameVerificationをtrueに設定します。

注意:

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

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

4.8 セッション・アフィニティの有効化

セッション・アフィニティを有効にすると、一意のトランザクションまたはセッションに対するすべてのリクエストは、最初のリクエストを処理した参加側サービスの同じエンドポイントまたはレプリカにルーティングされます。

Istioサービス・メッシュ内に参加側サービスまたはトランザクション・コーディネータをデプロイした場合は、この項で説明する手順を使用して、セッション・アフィニティまたはスティッキー・セッションを有効にします。この項で説明するステップは、参加側サービスのセッション・アフィニティの有効化に固有です。トランザクション・コーディネータのセッション・アフィニティは、同様の方法で有効にできます。トランザクション・コーディネータのセッション・アフィニティを有効にするには、トランザクション・コーディネータに固有のYAMLファイルおよびHelmチャートを更新します。
開始する前に、次のタスクを完了してください。
  1. Istioサービス・メッシュ内にトランザクション参加側サービスをデプロイしたことを確認します。
  2. 参加側サービスまたはトランザクション・コーディネータのセッション・アフィニティを有効にする必要があるかどうかを指定します。「セッション・アフィニティについて」を参照してください。
参加側サービスのセッション・アフィニティを有効にするには:
  1. デプロイ先のネームスペースでアプリケーションのネットワーキング・ルールを作成します。トラフィック・ポリシーでは、HTTPリクエスト・ヘッダーoracle-tmm-txn-idを使用するコンシステント・ハッシュを用いるロード・バランサを使用する必要があります。
  2. 参加側アプリケーションのHelmチャートで、IstioのDestinationRuleリソースにoracle-tmm-txn-id HTTPヘッダーを指定します。コンシステント・ハッシュに基づくロード・バランサを使用して、oracle-tmm-txn-id HTTPヘッダーに基づくセッション・アフィニティを提供します。
    apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
    name: sticky-participant
    namespace: otmm
spec:
    host: sticky-participant.otmm.svc.cluster.local
    trafficPolicy:
      loadBalancer:
        consistentHash:
          httpHeaderName: oracle-tmm-txn-id

    説明

    • sticky-participantは、参加側アプリケーションの名前です。
    • otmmは、参加側アプリケーションをデプロイするネームスペースです。

    • host: Kubernetesクラスタ内のアプリケーションの完全修飾名を指定します。たとえば、dept1.otmm.svc.cluster.localです。

  3. 参加側サービスのvalues.yamlファイルに、次のコード行を追加します:
    sessionAffinity: true
  4. 参加側サービスのnetworking.yamlファイルに、次のコード行を追加します:
    spec:
    host: {{$val.host}}
    trafficPolicy:
      loadBalancer:
        consistentHash:
          httpHeaderName: oracle-tmm-txn-id

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

4.9 values.yamlファイルの構成

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

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

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

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

  1. 任意のコード・エディタでvalues.yamlファイルを開きます。このファイルはinstallation_directory\otmm-RELEASE\otmm\helmchartsフォルダにあります。このファイルにはサンプル値が含まれています。
  2. サンプル値は、ご使用の環境に固有の値で置き換えてください。
    この項の表では、MicroTxのインストールに必要な環境、ストレージ、認可、認証、およびその他の構成の詳細のプロパティについて説明します。
  3. 変更内容を保存します。
  • 環境の詳細
    values.yamlファイルで、MicroTxをインストールする環境の詳細に関する情報を指定します。
  • イメージのプロパティ
    tmmImage下に、MicroTx Dockerイメージに関する情報を指定します。これらのプロパティの値の指定は必須です。
  • トランザクション・コーディネータのプロパティ
    tmmConfiguration下に、MicroTxを構成するための情報を指定します。
  • トランザクション・ストアのプロパティ
    MicroTxは、トランザクション状態の永続性を確保するためにデータ・ストアを使用します。
  • 認可のプロパティ
    MicroTxは、すべてのリクエストでJWTトークンを伝播することで、参加側サービスおよびコーディネータ間の認可をサポートします。authTokenPropagationEnabledフィールドを使用してこの機能を制御します。アイデンティティ・プロバイダが期限切れアクセス・トークンをコーディネータで自動リフレッシュするように構成します。
  • 認証のプロパティ
    authentication下に、認証に使用されるJSON Web Token (JWT)のissuerおよびjwksUriパラメータの値を入力します。これらのフィールドの情報を確認するには、検出URLを使用します。
  • 暗号化キーのプロパティ
    encryption下に、MicroTxがアクセス・トークンおよびリフレッシュ・トークンの暗号化に使用する暗号化キーを指定します。これらのプロパティの値を指定する必要があるのは、tmmConfiguration.authorizationのauthTokenPropagationEnabledプロパティを有効化した場合です。
  • トランザクション・トークンのプロパティ
    transactionTokenに、トランザクション・トークンに使用するキー・ペアを指定します。

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

4.9.1 環境の詳細

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

プロパティ 説明
istioSystemNameSpace Istioをインストールしたネームスペース。デフォルトのネームスペースはistio-systemです。別のネームスペースにIstioをインストールした場合は、次のコマンドを実行して、クラスタ内のすべてのネームスペースを確認します。
kubectl get ns
istioIngressGateway 作成したIstioイングレス・ゲートウェイの名前を入力します。たとえば、ingressgatewayです。Istioイングレス・ゲートウェイの名前を確認するには、次のコマンドを実行して、レスポンスのistioラベルの値を書き留めます。
kubectl describe service/istio-ingressgateway -n istio-system
applicationNameSpace MicroTxをデプロイするネームスペースを指定します。たとえば、otmmです。
tmmReplicaCount

MicroTxポッドのレプリカは1つのみ作成できるため、1と入力します。

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

4.9.2 イメージのプロパティ

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

プロパティ 説明
image リモート・リポジトリにプッシュしたMicroTxイメージのタグを入力します。たとえば、oracle-tmm:RELEASEです。
imagePullPolicy インストール中に確実にイメージがプルされるように、Alwaysを入力します。
imagePullSecret 作成したKubernetesシークレットの名前を指定します。このシークレットは、リモート・リポジトリからDockerイメージをプルするために使用されます。たとえば、regcredです。 
tmmImage:
  image: oracle-tmm:RELEASE
  imagePullPolicy: Always
  imagePullSecret: regcred

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

4.9.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を入力します。「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が返すのと同じレスポンス・データを返すことが保証されます。
logging.level 次のいずれかのタイプを入力して、MicroTxのログ・レベルを指定します:
  • info: MicroTxの通常の操作中に発生するイベントを記録します。この設定では、最小限の情報を記録します。これはデフォルトの設定です。
  • warning: 有害な状況を引き起こす可能性のあるイベントをログに記録します。
  • error: トラブルシューティングが必要な問題があることを示すためにイベントをログに記録します。
  • debug: すべてのイベントをログに記録します。この設定は、問題をデバッグする場合に使用します。
logging.httpTraceEnabled デバッグ時にMicroTx内のすべてのHTTPリクエストおよびレスポンスをログに記録するには、これをTrueに設定します。これをTrueに設定する場合、logging: level:をdebugに設定する必要もあります。
maxRetryCount 障害が発生した場合にトランザクション・コーディネータが同じリクエストの送信を再試行する最大回数。たとえば、10です。
minRetryInterval 障害が発生した後でトランザクション・コーディネータが同じリクエストの送信を再試行するまでの最小間隔(ミリ秒)。デフォルト値は1000ミリ秒です。
maxRetryInterval 障害が発生した後でトランザクション・コーディネータが同じリクエストの送信を再試行するまでの最大再試行間隔(ミリ秒)。たとえば、10000です。
skipVerifyInsecureTLS

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

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

注意:

本番環境では、この値をtrueに設定しないでください。

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

4.9.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データベースに接続している場合、または内部メモリーを使用している場合は、この項をスキップして、これらの値を指定しないでください。

プロパティ 説明
connectionString

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

  • 非自律型Oracle Database (資格証明ウォレットを使用しないデータベース)を使用している場合は、次の形式を使用して接続文字列を入力します:
    jdbc:oracle:thin:@<publicIP>:<portNumber>/<database unique name>.<host domain name>
    たとえば:
    jdbc:oracle:thin:@123.213.85.123:1521/CustDB_iad1vm.sub05031027070.customervcnwith.oraclevcn.com
  • Oracle Database Cloud ServiceとOracle Cloud Infrastructureを一緒に使用している場合は、『Oracle Blockchain Platformの使用』をOracle Database Classic Cloud Service接続文字列の作成を参照してください。
  • Oracle Autonomous Transaction Processingを使用している場合は、次の形式を使用して接続文字列を入力します:
    jdbc:oracle:thin:@tcps://<host>:<port>/<service_name>?wallet_location=<wallet_dir>

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

    たとえば:

    jdbc:oracle:thin:@tcps://adb.us-phoenix-1.oraclecloud.com:7777/unique_connection_string_low.adb.oraclecloud.com?wallet_location=Database_Wallet
credentialSecretName Oracle Databaseに接続するための資格証明を含むKubernetesシークレットの名前を入力します。たとえば、db-secretです。「Oracle Database資格証明のKubernetesシークレットの作成」を参照してください。
walletConfigMap.configMapName Autonomous Databaseインスタンスのウォレット用に作成した構成マップの名前を入力します。たとえば、db-wallet-configmapです。Autonomous Databaseインスタンスを使用している場合のみ、このフィールドに値を指定する必要があります。「Autonomous Databaseクライアント資格証明の取得」を参照してください。

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

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

プロパティ 説明
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です。
credentialSecret.secretFileName クライアント資格証明、クライアント・キーおよびクライアント証明書の保護に使用したパスワードを含むJSONファイルの場所を入力します。たとえば、/etc/otmm/etcdecred.jsonです。
cacertConfigMap.configMapName 認証局の初期化中に作成した構成マップ・ファイルの名前を入力します。たとえば、etcd-ca-cert-mapです。
cacertConfigMap.configMapFileName 認証局の初期化中に作成したPEMファイルの名前を入力します。たとえば、ca.pemです。

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

4.9.5 認可のプロパティ

MicroTxは、すべてのリクエストでJWTトークンを伝播することで、参加側サービスおよびコーディネータ間の認可をサポートします。authTokenPropagationEnabledフィールドを使用してこの機能を制御します。アイデンティティ・プロバイダが期限切れアクセス・トークンをコーディネータで自動リフレッシュするように構成します。

tmmConfiguration.authorizationに、認可に使用するアイデンティティ・プロバイダの詳細を指定します。

プロパティ 説明
enabled これをtrueに設定すると、MicroTxが受信JWTトークンのサブジェクトをチェックできるようになります。その後、MicroTxは、サブジェクトまたはユーザーにトランザクションIDをタグ付けします。トランザクションをさらに変更できるのは、タグ付けされたサブジェクトまたはユーザーのみになります。このフィールドをfalseに設定した場合、tmmConfiguration.authorizationの他のプロパティに値を指定する必要はありません。

注意:

本番環境では、このフィールドをtrueに設定する必要があります。
authTokenPropagationEnabled 参加側サービスとMicroTxの間のセキュアな通信を確保するためにトークン伝播を有効にするには、これをtrueに設定します。トークン伝播を有効にした場合は、values.yamlファイルのencryptionプロパティに暗号化キーの詳細を指定する必要があります。
identityProviderName 使用するアイデンティティ・プロバイダを指定します。指定できる値は、Oracle IDCSおよびOracle IAMのIDCS、KeycloakのKEYCLOAK、Azure Active DirectoryのAZURE_AD、Microsoft Active DirectoryのMICROSOFT_ADです。
identityProviderUrl アイデンティティ・プロバイダのURLを指定します。この情報は、リフレッシュ・トークンを使用して新しいアクセス・トークンを作成するために必要です。この情報を指定しないと、期限切れになったアクセス・トークンが自動リフレッシュされません。
identityProviderClientId アイデンティティ・プロバイダのクライアントIDを指定します。この情報は、リフレッシュ・トークンを使用して新しいアクセス・トークンを作成するために必要です。この情報を指定しないと、期限切れになったアクセス・トークンが自動リフレッシュされません。

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

4.9.6 認証のプロパティ

authenticationに、認証に使用されるJSON Webトークン(JWT)のissuerパラメータおよびjwksUriパラメータの値を入力します。これらのフィールドの情報を確認するには、検出URLを使用します。

プロパティ 説明
requestsWithNoJWT JWT認証をバイパスするには、ALLOWを入力します。こうすると、JWTトークンのないリクエストが許可されます。すべてのリクエストにJWTトークンを含める場合は、DENYを入力します。MicroTxは、リクエストで指定されたトークンを検証し、トークンが無効な場合はアクセスを拒否します。

注意:

本番環境では、このフィールドをDENYに設定する必要があります。
jwt.issuer JWTトークン発行元を指定します。
jwt.jwksUri アイデンティティ・プロバイダのパブリック・ホストjwksUriのURL。JWTの署名の検証に使用されます。JSON Web Key Set (JWKS)には、受信JWTトークンの検証に使用される暗号化キーが含まれます。

次のコード・スニペットは、values.yamlファイルのauthenticationフィールドのサンプル値を示しています。この例のサンプル値は、検出URLの実行のサンプル・コマンドで使用された値に基づいています。 

authentication:
  requestsWithNoJWT: DENY
  jwt:
    issuer: "https://identity.oraclecloud.com"
    jwksUri: "https://idcs-a83e4de370ea4db8c703a0b742ce74.identity.oraclecloud.com:443/admin/v1/SigningCert/jwk"

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

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

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

プロパティ 説明
encryptionSecretKeyVersion トランザクション・トークンの暗号化に使用するキーのバージョンを指定します。
encryptionSecretKeys.SecretKeyName 値として暗号化キーを含むKubernetesシークレットの名前およびバージョンを指定します。暗号化キーのローテーションをサポートするために、複数の暗号化キーとそのバージョンを指定できます。
encryptionSecretKeys.version 使用するKubernetesシークレットのバージョンを入力します。

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

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

encryption:
  encryptionSecretKeyVersion: "1"
  encryptionSecretKeys:
      - secretKeyName: "encryption-secret-key0"
        version: "0"
      - secretKeyName: " encryption-secret-key1"
        version: "1"

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

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

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.10 MicroTxのインストール

Helmを使用して、MicroTxをKubernetesクラスタにインストールします。

  1. MicroTxのhelmchartsフォルダに移動します。
    cd installation_directory/otmm-RELEASE/otmm/helmcharts
  2. values.yamlファイルに指定されている構成詳細を使用して、MicroTxをデプロイします。

    構文

    helm install <release name> --namespace <namespace> <chart directory> --values <values.yaml>

    例

    次のコマンドを使用して、otmmネームスペースにtmm-appという名前のアプリケーションとしてMicroTxをインストールします。 

    helm install tmm-app --namespace otmm tmm --values tmm/values.yaml

    説明

    • tmm-appは、作成するアプリケーションの名前です。

    • otmmは、MicroTxをインストールするKubernetesクラスタ内のネームスペースです。

    • installation_directory/otmm-RELEASE/otmm/helmcharts/tmmは、MicroTxのchart.yamlファイルを含むフォルダです。
    • installation_directory/otmm-RELEASE/otmm/helmcharts/tmm/values.yamlは、ローカル・マシン内のvalues.yamlファイル(アプリケーションのマニフェスト・ファイル)の場所です。このファイルには、MicroTxのデプロイメント構成の詳細が含まれています。
    次のメッセージが表示されます。
    NAME: otmm
LAST DEPLOYED: Tue Apr 19 21:14:25 2022
NAMESPACE: otmm
STATUS: deployed
REVISION: 1
TEST SUITE: None
  3. ポッドやサービスなど、すべてのリソースの準備ができていることを確認します。次のコマンドを使用して、ネームスペースotmm内のリソースのリストとそれらのステータスを取得します。
    kubectl get all -n otmm

    サンプル・レスポンス

    読みやすくするために、値の一部が...を使用して省略される場合があります。ご自身の環境でこのコマンドを実行すると、値全体が表示されます。

    NAME             READY   STATUS    RESTARTS   AGE
pod/otmm-tcs-0   2/2     Running   0          38s

NAME               TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/otmm-tcs   ClusterIP   10.110........   <none>        9000/TCP   38s

NAME                        READY   AGE
statefulset.apps/otmm-tcs   1/1     38s

インストールが完了したら、MicroTxにアクセスできます。

次の章では、環境にサンプル・アプリケーションをインストールして実行する手順について説明します。サンプル・アプリケーションのデプロイを参照してください。

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

4.11 Istioイングレス・ゲートウェイのIPアドレスの確認

トランザクションを開始する前に、Istioイングレス・ゲートウェイの外部IPアドレスを書き留める必要があります。

アプリケーションにアクセスするには、この情報が必要です。
  1. 次のコマンドを実行して、Istioイングレス・ゲートウェイの外部IPアドレスを確認します。

    コマンド

    kubectl get svc istio-ingressgateway -n istio-system

    サンプル出力

    kubectl get svc istio-ingressgateway -n istio-system
NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                                      AGE
istio-ingressgateway   LoadBalancer   10.109........   192.0.2.1     15021:31695/TCP,80:32333/TCP,443:7777/TCP    44h
  2. この出力で、EXTERNAL-IPの値(Istioイングレス・ゲートウェイの外部IPアドレス)と、構成したアクセス・プロトコルに応じてHTTPまたはHTTPSトラフィックに関連付けられたポートを書き留めてください。たとえば、https://192.0.2.1:443です。
  3. 次のコマンドに示すように、Istioイングレス・ゲートウェイのIPアドレスをCLUSTER_IPADDRという名前の環境変数に格納します。
    export CLUSTER_IPADDR=192.0.2.1

    これを行わない場合は、必要なときに、コマンドでIPアドレスを明示的に指定する必要があります。

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

4.12 MicroTxへのアクセス

MicroTxにアクセスするには、アクセスに使用するポート番号、ホスト名およびプロトコルを指定します。HTTPプロトコルはテスト環境または開発環境でのみ使用することをお薦めします。本番環境では、HTTPSプロトコルを使用する必要があります。

MicroTxにアクセスするには、内部URLまたは外部URLを使用します。MicroTxに、サービスをデプロイしたKubernetesクラスタ内からアクセスするか、別のKubernetesクラスタからアクセスするかに応じて、異なるURLを使用します。

MicroTxにアクセスするための内部URL

内部URLを使用して、サービスをデプロイしたKubernetesクラスタ内からMicroTxにアクセスします。たとえば、トランザクション・イニシエータ・アプリケーションとMicroTxを同じKubernetesクラスタにデプロイした場合です。

MicroTxにアクセスするには、次の形式でURLを作成します: 

http://internalHostname:internalPort/api/v1

説明

  • internalHostname: MicroTxのvalues.yamlのtmmAppNameプロパティに入力した名前。たとえば、tmm-appです。
  • internalPort: MicroTxのvalues.yamlのportプロパティに入力したポート番号。たとえば、9090です。このポートでのHTTPSトラフィックを許可するために必要なネットワーキング・ルールを設定したことを確認します。

前述の例の値に基づくと、MicroTx URLの例はhttps://tmm-app:9000/api/v1です。

コンテナ内のすべての通信はHTTPプロトコルを使用します。通信が経由するEnvoyプロキシでmTLSが使用されるためです。

MicroTxにアクセスするための外部URL

外部URLを使用して、サービスをデプロイしたKubernetesクラスタの外部からMicroTxにアクセスします。たとえば、異なるKubernetesクラスタにトランザクション・イニシエータ・アプリケーションおよびMicroTxをデプロイする場合です。このようなシナリオでは、トランザクション・イニシエータ・アプリケーションは外部URLを使用してMicroTxにアクセスします。

外部からMicroTxにアクセスするには、次の形式でURLを作成します: 

https://externalHostname:externalPort/api/v1

説明

  • externalHostname: Istioイングレス・ゲートウェイのロード・バランサのIPアドレス。Istioイングレス・ゲートウェイのIPアドレスの確認を参照してください。たとえば、192.0.2.1です。
  • externalPort: Istioイングレス・ゲートウェイのロード・バランサのポート番号。このポートでインバウンドおよびアウトバウンド・トラフィックを許可するために必要なネットワーク・ルールを作成する必要があります。たとえば、443です。

前述の例の値に基づくと、MicroTx URLの例はhttps://192.0.2.1:443/api/v1です。

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