5 Docker Swarmへのインストール

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

この項の手順に従って、Docker SwarmにMicroTxをインストールし、サンプル・アプリケーションを実行します。同様の構成を作成すると、サポートされている他の環境にMicroTxをインストールできます。KubernetesクラスタにMicroTxをインストールする場合は、この項をスキップして、「Kubernetesクラスタへのインストール」を参照してください。

ノート:

この項で説明する手順は、テスト環境または開発環境専用です。本番環境でマイクロサービス対応トランザクション・マネージャを設定および使用するには、これらの手順を使用しないでください。

• Docker Swarmの設定
  
• レジストリの作成
  swarmは複数のDockerエンジンで構成されているため、それらすべてにイメージを配布するにはレジストリが必要です。
• Dockerレジストリへのイメージのプッシュ
  ローカル・システムにダウンロードしたインストール・バンドルには、MicroTxのDockerイメージが含まれます。このイメージをDockerに作成したレジストリにプッシュします。
• 暗号化キーとキー・ペアの作成
  このタスクを実行するのは、tcs-docker-swarm.yamlファイルのauthTokenPropagationEnabledプロパティとtransactionTokenEnabledプロパティを有効にする場合のみです。このファイルはinstallation_directory/otmm-<version>/samples/dockerフォルダにあります。
• etcdの詳細を使用したYAMLファイルの更新
  トランザクション・コーディネータのYAMLファイルにetcd資格証明およびetcdエンドポイントを指定する必要があります。MicroTxは、この情報を使用して、サービスのインストール後にetcdへの接続を確立します。
• Oracle Database資格証明のDockerシークレットの作成
  MicroTxでは、トランザクション情報を追跡するための永続ストアとしてOracle Databaseの使用がサポートされます。YAMLファイルにOracle Database資格証明を指定する必要があります。MicroTxは、サービスのインストール後に資格証明を使用してデータベースへの接続を確立します。
• セッション・アフィニティの有効化
  セッション・アフィニティを有効にすると、一意のトランザクションまたはセッションに対するすべてのリクエストは、最初のリクエストを処理した参加側サービスの同じエンドポイントまたはレプリカにルーティングされます。
• tcs-docker-swarm.yamlファイルの構成
  インストール・バンドルには、アプリケーションのマニフェスト・ファイルであるtcs-docker-swarm.yamlファイルが含まれ、これにはMicroTxのデプロイメント構成の詳細が含まれます。
• アプリケーションのセキュアな接続の構成
  
• Docker SwarmでのMicroTxへのアクセス
  
• DockerコンテナでのMicroTxの実行
  さらに、別のDockerコンテナでMicroTxを使用できます。この項の手順に従って、HTTPSポートでMicroTxをローカルに実行します。

5.1 Docker Swarmの設定

1. Docker Desktopをダウンロードしてインストールします。https://docs.docker.com/get-started/を参照してください。
2. 次のコマンドをシェル・プロンプトで実行して、DockerエンジンがSwarmモードで実行されていることを確認します。

   docker system info

   レスポンスをスクロールして次のメッセージを探します。

   Swarm: active

   Swarmが有効になっていない場合は、シェル・プロンプトで次のコマンドを実行して有効にします。

   docker swarm init

3. 最新バージョンのDocker Composeをインストールします。https://docs.docker.com/compose/install/を参照してください。

5.2 レジストリの作成

swarmは複数のDockerエンジンで構成されているため、それらすべてにイメージを配布するにはレジストリが必要です。

1. 次のコマンドを実行して、swarm上のサービスとしてレジストリを起動します。

   docker service create --name registry --publish published=5000,target=5000 registry:2

2. 次のコマンドを実行して、レジストリのステータスを確認します。

   docker service ls

   レスポンスでREPLICASの下の1/1を探します。これはレジストリが実行中であることを示します。レスポンスが0/1の場合、まだイメージがプルされている可能性があります。しばらくしてから再度ステータスを確認します。

   
   ID             NAME              MODE         REPLICAS   IMAGE            PORTS
   tjc0u55yavu4   registry          replicated   1/1        registry:2       *:5000->5000/tcp

3. cURLを使用してレジストリにアクセスできることを確認します。

   curl http://localhost:5000/v2/

5.3 Dockerレジストリへのイメージのプッシュ

ローカル・システムにダウンロードしたインストール・バンドルには、MicroTxのDockerイメージが含まれます。このイメージをDockerに作成したレジストリにプッシュします。

次のステップを実行して、MicroTxのDockerイメージをDockerのレジストリにプッシュします:

1. MicroTxイメージをローカルDockerリポジトリにロードします。MicroTxイメージは、installation_directory/otmm-<version>/image/tmm-<version>.tgzにあります。

   cd installation_directory/otmm-<version>/otmm
   docker load < image/tmm-<version>.tgz

   イメージがロードされると、次のメッセージが表示されます。

   Loaded image: tmm:<version>

2. ロードしたイメージのタグを作成します。
3. 次のコマンドを使用して、リモートDockerリポジトリにプッシュするイメージの一意のタグを指定します。

   構文

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

   説明

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

   サンプル・コマンド

   docker tag tmm:<version> 198.51.100.1:5000/tmm

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

4. 新しいタグを付けたDockerイメージをDockerレジストリにプッシュします。

   構文

   docker push remote_image[:tag]

   サンプル・コマンド

   docker push 198.51.100.1:5000/tmm

5.4 暗号化キーとキー・ペアの作成

このタスクを実行するのは、tcs-docker-swarm.yamlファイルのauthTokenPropagationEnabledプロパティとtransactionTokenEnabledプロパティを有効にする場合のみです。このファイルはinstallation_directory/otmm-<version>/samples/dockerフォルダにあります。

tcs-docker-swarm.yamlファイルのauthTokenPropagationEnabledおよびtransactionTokenEnabledプロパティを有効にする必要がない場合は、2つのYAMLファイルで数行をコメント化する必要があります。

tcs-docker-swarm.yamlファイルの次の行をコメント化します。

# secretKeys: '{"secretKeys":[{"secretKeyName":"TMMSECRETKEY", "version":"1"}]}'
# EncryptionSecretKeyVersion: 1
...
# keyPairs: '{"keyPairs":[{"privateKeyName":"TMMPRIKEY", "publicKeyName":"TMMPUBKEY", "version":"1", "privateKeyPasswordName":"TMMPRIKEYPASSWD"}]}'
# transactionTokenKeyPairVersion: 1

tmm-stack-compose.yamlファイルの次の行をコメント化します。このファイルはinstallation_directory/otmm-<version>/samples/dockerフォルダにあります。

# secrets:
# TMMSECRETKEY:
# external: true
# TMMPRIKEY:
# external: true
# TMMPUBKEY:
# external: true
# TMMPRIKEYPASSWD:
# external: true

...
#entrypoint: ['/bin/sh', '-c', 'export TMMSECRETKEY=$$(cat /run/secrets/TMMSECRETKEY); export TMMPRIKEY=$$(cat /run/secrets/TMMPRIKEY); export TMMPUBKEY=$$(cat /run/secrets/TMMPUBKEY); export TMMPRIKEYPASSWD=$$(cat /run/secrets/TMMPRIKEYPASSWD); /app/tcs' ]

# secrets:
    # - TMMSECRETKEY
    # - TMMPRIKEY
    # - TMMPUBKEY
    # - TMMPRIKEYPASSWD

暗号化キーおよびトランザクション・トークンを作成する必要がなく、それらのオプションを無効にした場合は、この項をスキップします。

tcs-docker-swarm.yamlファイルのauthorizationのauthTokenPropagationEnabledプロパティを有効化した場合は、暗号化キーを生成し、そのキーをDockerシークレットに追加する必要があります。生成する暗号化キーには、次の属性が必要です。

• 対称アルゴリズム: AES-256
• 暗号モード: GCMモードのAES
• キーの長さ: 32バイト
• 初期化ベクトルの長さ: 96ビット

tcs-docker-swarm.yamlファイルのtransactionTokenのtransactionTokenEnabledをtrueに設定した場合は、トランザクション・トークンのキー・ペアを生成する必要があります。生成するトランザクション・トークンには、次の属性が必要です:

• 非対称アルゴリズム: RSA 3072
• キーの長さ: 3072ビット
• ハッシュ・アルゴリズム: SHA256

パスフレーズがわかる場合は、既存のRSAキーを再利用できます。それ以外の場合は、新しいRSAキーを作成します。

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

暗号化トークンおよびトランザクション・トークンの使用方法の詳細は、「認証および認可について」を参照してください。

暗号化キーおよびRSAキー・ペアを作成するには:

1. 次のコマンドを実行して、キーの長さが32バイトの暗号化キーを生成し、暗号化キーの使用中にシークレットを作成します。

   openssl rand -hex 16 | docker secret create TMMSECRETKEY

   ここで、TMMSECRETKEYは作成するシークレットの名前です。同じ名前の既存のキーがある場合、そのキーは上書きされます。

2. キーの長さが3072ビットのRSA秘密キーを作成します。以下のコマンドを使用します。

   openssl genrsa -aes256 -out private.pem 3072

3. コマンド・プロンプトでパスフレーズを入力し、[Enter]を押します。後で指定する必要があるため、パスフレーズを覚えておいてください。

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

4. 生成した秘密キーに対するRSA公開キーを作成します。

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

   openssl rsa -in private.pem -outform PEM -pubout -out public.pem

5. Base-64によって、秘密キーと公開キーがエンコードされ、Dockerシークレットに追加されます。

   base64 private.pem | docker secret create TMMPRIKEY -
   base64 public.pem | docker secret create TMMPUBKEY -

   ここで、TMMPRIKEYおよびTMMPUBKEYは作成するDockerシークレットの名前です。

6. RSAキーのパスフレーズをDockerシークレットとして格納します。次のコマンドで、pass_phraseをRSAキーのパスフレーズに置き換えます。

   printf "<pass_phrase>"| docker secret create TMMPRIKEYPASSWD -

7. 作成したDockerシークレットの名前を確認します。

   docker secret ls

   サンプル出力

   ID               NAME              DRIVER    CREATED        UPDATED
   ricw56x6sehy...   TMMPRIKEY                   20 hours ago   20 hours ago
   c0hw2nhu0sh1...   TMMPRIKEYPASSWD             20 hours ago   20 hours ago
   mr91c79nwzne...   TMMPUBKEY                   20 hours ago   20 hours ago
   wp112txjki46...   TMMSECRETKEY                20 hours ago   20 hours ago

   後で指定する必要があるため、キーの名前を書き留めます。

8. installation_directory/otmm-<version>/samples/dockerフォルダにあるtmm-stack-compose.yamlファイルを更新します。作成したシークレットを環境変数としてSwarm内でエクスポートします。これには、次の例のようにconfigsセクションのすぐ下に詳細を指定します。

   version: "3.9"
    
   configs:
      my_tcs_config:
      file: ./tcs-docker-swarm.yaml
    
   secrets:
     TMMPRIKEY:
        external: true
     TMMPRIKEYPASSWD:
        external: true
     TMMPUBKEY:
        external: true
     TMMSECRETKEY:
        external: true

9. tmm-stack-compose.yamlファイルのservices.otmm-tcsセクションに次を追加します:
   • 作成したシークレットの名前。
   • 作成したシークレットを環境変数としてエクスポートするためのentrypointを作成します。わかりやすくするために、次の例ではシークレットと環境変数に同じ名前を使用しています。環境変数には他の任意の名前を指定できます。次のステップで指定する必要があるため、環境変数の名前を書き留めておきます。

   services:
      otmm-tcs:
        image: "127.0.0.1:5000/tmm"
        ports:
           - "9000:9000"
        entrypoint: ['/bin/sh', '-c', 'export TMMPRIKEY=$$(cat /run/secrets/TMMPRIKEY); export TMMPRIKEYPASSWD=$$(cat /run/secrets/TMMPRIKEYPASSWD); export TMMPUBKEY=$$(cat /run/secrets/TMMPUBKEY); export TMMSECRETKEY=$$(cat /run/secrets/TMMSECRETKEY); /app/tcs' ]
         deploy:
            replicas: 1
         configs:
           - source: my_tcs_config
             target: /tcs_config.yaml
         environment:
           - CONFIG_FILE=/tcs_config.yaml
         secrets:
           - TMMPRIKEY
           - TMMPRIKEYPASSWD
           - TMMPUBKEY
           - TMMSECRETKEY

10. 作成した環境変数の名前を含むようにtcs-docker-swarm.yamlファイルを更新します。このYAMLファイルは、installation_directory/otmm-<version>/samples/dockerフォルダにあります。

    encryptionおよびtransactionTokenプロパティのサンプル値

    encryption:
         secretKeys: '{"secretKeys":[{"secretKeyName":"TMMSECRETKEY", "version":"1"}]}'
         #TMMSECRETKEY is the environment variable for the Docker secret that contains the encryption key
         EncryptionSecretKeyVersion: 1
    transactionToken:
         transactionTokenEnabled: true
         keyPairs: '{"keyPairs":[{"privateKeyName":"TMMPRIKEY", "publicKeyName":"TMMPUBKEY", "version":"1", "privateKeyPasswordName":"TMMPRIKEYPASSWD"}]}'
         #TMMPRIKEY is the environment variable for the Docker secret that contains the base64-encoded private key
         #TMMPUBKEY is the environment variable for the Docker secret that contains the base64-encoded public key
         #TMMPRIKEYPASSWD is the environment variable for the Docker secret that contains the private key password
         transactionTokenKeyPairVersion: 1

5.5 etcdの詳細を使用したYAMLファイルの更新

トランザクション・コーディネータのYAMLファイルにetcd資格証明およびetcdエンドポイントを指定する必要があります。MicroTxは、この情報を使用して、サービスのインストール後にetcdへの接続を確立します。

MicroTxのトランザクション・ログを格納するためにetcdを使用しない場合は、このステップをスキップします。

開始する前に、サーバーおよびクライアントのRSA証明書を生成します。生成された証明書の内容を含むJSONファイルを作成します。「etcdのRSA証明書の生成」を参照してください。

etcdにアクセスするための詳細を含むDockerシークレットを作成するには:

1. tcs-docker-swarm.yamlファイルを更新し、etcdエンドポイント、etcdの資格証明へのパス、etcdのRSA証明書へのパスを指定します。次のコード・スニペットは、「etcdのRSA証明書の生成」で使用されているサンプル値を示しています。これらのサンプル値を環境内の実際の値に置き換えます。

   storage:
     type: etcd
     etcd:
       endpoints: https://etcd:2379
       credentialsFilePath: "/app/etcd/etcdecred.json"
       cacertFilePath: "/app/etcd/ca.pem"
       skipHostNameVerification: false

   各フィールドの詳細は、「トランザクション・ストアのプロパティ」を参照してください。

2. tcs-stack-compose.yamlファイルをservicesの下のetcdの詳細で更新します。

   サンプル値

   次のコード・スニペットは、「etcdのRSA証明書の生成」で使用されているサンプル値を示しており、etcdとトランザクション・コーディネータがDocker Swarmの同じネットワークにあるものとしています。

   これらのサンプル値を環境内の実際の値に置き換えます。

   services:
     etcd:
       image: "bitnami/etcd"
       ports:
         - "2379:2379"
         - "2380:2380"
       volumes:
         - <PATH_TO_CFSSL_DIRECTORY>/cfssl:/etcdssl
       environment:
         - ETCD_ROOT_PASSWORD=password
         - ETCD_CERT_FILE=/etcdssl/server.pem
         - ETCD_KEY_FILE=/etcdssl/server-key.pem
         - ETCD_LISTEN_CLIENT_URLS=https://0.0.0.0:2379
         - ETCD_ADVERTISE_CLIENT_URLS=https://127.0.0.1:2379

   説明

   • imageは、etcdイメージ・ファイルへのパスです。
   • portsは、etcdがトランザクション・コーディネータと通信するポートです。
   • volumesは、Docker Swarmのetcdボリュームへの一意のパスです。Docker Swarmの各サービスは、独自のボリュームを使用します。MicroTxは、インストール・プロセス中にこのボリュームを作成し、証明書ファイルをローカル・ディレクトリからボリュームにコピーします。名前を<absolute_path_to_certificate_directory_in_your_local_machine>:/<unique_name_of_etcd_volume>の形式で指定します。たとえば、<PATH_TO_CFSSL_DIRECTORY>/cfssl:/etcdsslです。
   • ETCD_ROOT_PASSWORDは、etcdに必要な環境変数です。etcdにアクセスするためのパスワードです。
   • ETCD_CERT_FILEは、etcdに必要な環境変数です。Docker Swarmのetcdサービス・ボリューム内のサーバー公開キー・ファイルへのパスです。名前を<unique_name_of_etcd_volume>/<name_of_server_certificate>の形式で指定します。たとえば、/etcdssl/server.pemです。
   • ETCD_KEY_FILEは、etcdに必要な環境変数です。Docker Swarmのetcdサービス・ボリューム内のサーバー秘密キー・ファイルへのパスです。名前を<unique_name_of_etcd_volume>/<name_of_server_private_key_file>の形式で指定します。たとえば、/etcdssl/server-key.pemです。
   • ETCD_LISTEN_CLIENT_URLSは、etcdに必要な環境変数です。<etcd_IP_address>/<etcd_port>の形式で値を指定します。たとえば、etcdとトランザクション・コーディネータがDocker Swarmの同じネットワークにある場合は、https://0.0.0.0:2379です。etcdが別のネットワークに設定されている場合は、etcdのIPアドレスを指定します。2379は、etcdとの通信に使用されるポートです。portsにetcdが使用するポートを指定しています。
   • ETCD_ADVERTISE_CLIENT_URLS=は、etcdに必要な環境変数です。<etcd_IP_address>/<etcd_port>の形式で値を指定します。たとえば、https://127.0.0.1:2379です。etcdが別のネットワークに設定されている場合、127.0.0.1のかわりにetcdのIPアドレスを指定します。2379はetcdとの通信に使用されるポートです。portsにetcdが使用するポートを指定しています。
3. tcs-stack-compose.yamlファイルのotmm-tcsにある証明書を含むディレクトリへの絶対パスの詳細を追加します。
   次のサンプル・コードは、otmm-tcs下のエントリのスニペットを示しています。

   otmm-tcs:
      volumes:
        - <PATH_TO_CFSSL_DIRECTORY>/cfssl:/app/etcd

   ここで、/app/etcdは、Docker Swarmのトランザクション・コーディネータ・ボリュームへの一意のパスです。Docker Swarmの各サービスは、独自のボリュームを使用します。MicroTxは、インストール・プロセス中にこのボリュームを作成し、証明書ファイルをローカル・ディレクトリからボリュームにコピーします。名前を<absolute_path_to_certificate_directory_in_your_local_machine>:/<unique_name_of_transaction_coordinator_volume>の形式で指定します。たとえば、<PATH_TO_CFSSL_DIRECTORY>/cfssl:/app/etcdです。

4. 変更内容を保存します。

5.6 Oracle Database資格証明のDockerシークレットの作成

MicroTxでは、トランザクション情報を追跡するための永続ストアとしてOracle Databaseの使用がサポートされます。YAMLファイルにOracle Database資格証明を指定する必要があります。MicroTxは、サービスのインストール後に資格証明を使用してデータベースへの接続を確立します。

Oracle Databaseを使用してMicroTxのトランザクション詳細を格納しない場合は、このステップをスキップします。

Autonomous Databaseインスタンスを使用している場合は、次のステップを開始する前に、必ずウォレットをダウンロードして接続文字列を書き留めてください。「Autonomous Databaseクライアント資格証明の取得」を参照してください。

Oracle Databaseログインの詳細を提供するDockerシークレットを作成するには:

1. メモ帳などの任意のテキスト・エディタで、次の形式でOracle Database資格証明を入力します。サンプル値は、ご使用の環境に固有の値で置き換えてください。

   {
     "password": "enter_your_Database_password",
     "username": "enter_the_username_to_access_the_Database"
   }

2. TXT形式でファイルを保存します。たとえば、database_secret.txtです。次のステップで指定する必要があるため、このファイルのパスと名前を書き留めます。
3. Oracle Databaseのログイン詳細を使用してDockerシークレットを作成します。

   コマンド構文

   docker secret create <name_of_the_secret> </path_to_text_file>/<name_of_text_file

   サンプル・コマンド

   次のコマンドは、STORAGE_DB_CREDENTIALという名前のDockerシークレットを作成します。

   docker secret create STORAGE_DB_CREDENTIAL /database_secret.txt

4. 次のコマンドを実行して、シークレットが作成されたことを確認します。

   docker secret ls

   サンプル・レスポンス

   
   ID         NAME                    DRIVER     CREATED          UPDATED
   ovn1x...   STORAGE_DB_CREDENTIAL              11 seconds ago   11 seconds ago

   読みやすくするために、レスポンスのサンプル値は...を使用して一部を省いています。このコマンドを環境で実行すると、完全な値が表示されます。

   作成したDockerシークレットの名前を書き留めます。この名前は後で入力する必要があります。

5. 任意のテキスト・エディタでtmm-stack-compose.yamlファイルを開きます。このファイルはinstallation_directory/otmm-<version>/samples/dockerフォルダにあります。
6. 作成したDockerシークレットの詳細を使用して、otmm-tcsサービスおよびsecretsセクションを更新します。次のコード・スニペットは、サンプル値を示しています。

   secrets:
     STORAGE_DB_CREDENTIAL:
       external: true
   services:
     otmm-tcs:
       image: "127.0.0.1:5000/tmm"
       ports:
         - "9000:9000"
       deploy:
         replicas: 1
       configs:
         - source: my_tcs_config
           target: /tcs.yaml
       # Create an environment variable that points to the Docker secret that you have created.
       entrypoint: ['/bin/sh', '-c', 'export STORAGE_DB_CREDENTIAL=$$(cat /run/secrets/STORAGE_DB_CREDENTIAL); /app/tcs' ]
       environment:
         - CONFIG_FILE=/tcs.yaml
       secrets:
         - STORAGE_DB_CREDENTIAL

   ここで、STORAGE_DB_CREDENTIALは、作成したDockerシークレットの名前です。entrypointを追加して、作成したDockerシークレットを指す環境変数を作成します。環境変数とDockerシークレットの名前は、サンプル・コード・スニペットでは同じです。

7. データベース接続文字列を入力します。Autonomous Databaseインスタンスを使用している場合のみ、volumesパラメータにウォレットの詳細も指定する必要があります。Autonomous Databaseインスタンスの接続文字列の形式の詳細は、「Autonomous Databaseクライアント資格証明の取得」を参照してください。

   secrets:
     STORAGE_DB_CREDENTIAL:
       external: true
   services:
     otmm-tcs:
       image: "127.0.0.1:5000/tmm"
       ports:
         - "9000:9000"
       deploy:
         replicas: 1
       configs:
         - source: my_tcs_config
           target: /tcs.yaml
       volumes:
         - /<PATH_TO_DOWNLOADED_WALLET>/<WALLET_FOLDER_NAME>:/app/Wallet
       entrypoint: ['/bin/sh', '-c', 'export STORAGE_DB_CREDENTIAL=$$(cat /run/secrets/STORAGE_DB_CREDENTIAL); /app/tcs' ]
       environment:
         - CONFIG_FILE=/tcs.yaml
       secrets:
         - STORAGE_DB_CREDENTIAL
   storage:
       type: db
       #Allowed types - etcd/db/memory
       db:
         connectionString: tcps://adb.us-ashburn-1.oraclecloud.com:1522/bfeldfxbtjvtddi_brijeshadw1_medium.adb.oraclecloud.com?retry_count=20&retry_delay=3&wallet_location=/app/Wallet

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

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

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

5.8 tcs-docker-swarm.yamlファイルの構成

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

tcs-docker-swarm.yamlファイルのサンプル値を置き換えて、環境の詳細、イメージの詳細および構成の詳細を指定します。指定した詳細は、Docker SwarmでMicroTxをデプロイするために使用されます。

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

1. 任意のコード・エディタでtcs-docker-swarm.yamlファイルを開きます。このファイルはinstallation_directory/otmm-<version>/samples/dockerフォルダにあります。このファイルにはサンプル値が含まれています。
2. サンプル値は、ご使用の環境に固有の値で置き換えてください。
   この項の表では、MicroTxのデプロイに必要な環境、ストレージ、認可、認証、およびその他の構成の詳細のプロパティについて説明します。
3. 変更内容を保存します。

• トランザクション・コーディネータのプロパティ
  MicroTxを構成するための情報を指定します。
• トランザクション・ストアのプロパティ
  MicroTxは、トランザクション状態の永続性を確保するためにトランザクション・ストアを使用します。
• TLSのプロパティ
  HTTPまたはHTTPSプロトコルを使用してMicroTxを実行します。
• 認可のプロパティ
  MicroTxは、すべてのリクエストでJWTトークンを伝播することで、参加側サービスおよびコーディネータ間の認可をサポートします。authTokenPropagationEnabledフィールドを使用してこの機能を制御します。アイデンティティ・プロバイダが期限切れアクセス・トークンをコーディネータで自動リフレッシュするように構成します。
• 認証のプロパティ
  認証に使用されるJSON Webトークン(JWT)のissuerパラメータおよびjwksUriパラメータの値を入力します。これらのフィールドの情報を確認するには、検出URLを使用します。
• 暗号化キーのプロパティ
  encryption下に、MicroTxがアクセス・トークンおよびリフレッシュ・トークンの暗号化に使用する暗号化キーを指定します。これらのプロパティの値を指定する必要があるのは、tmmConfiguration.authorizationのauthTokenPropagationEnabledプロパティを有効化した場合です。
• トランザクション・トークンのプロパティ
  transactionTokenに、トランザクション・トークンに使用するキー・ペアを指定します。

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

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

プロパティ	説明
tmmAppName	作成するMicroTxアプリケーションの名前を入力します。MicroTxをインストールすると、MicroTxアプリケーションが指定した名前で作成されます。後で指定する必要があるため、この名前を書き留めておきます。たとえば、tmm-appです。
listenAddr	MicroTxにアクセスするポートを入力します。このポートでインバウンドおよびアウトバウンド・トラフィックを許可するために必要なネットワーク・ルールを作成します。後で指定する必要があるため、この番号を書き留めておきます。たとえば、0.0.0.0:9000です。この例に示すように、リスナー・アドレスを<IP_address>:<port>の形式で指定します。
internalAddr	サービスをインストールするDockerリポジトリ内からMicroTxにアクセスするための内部URLを入力します。「Docker SwarmでのMicroTxへのアクセス」を参照してください。
externalUrl	サービスをインストールするDockerリポジトリの外部からMicroTxにアクセスするための外部URLを入力します。「Docker SwarmでのMicroTxへのアクセス」を参照してください。
httpClientTimeoutInSecs	MicroTxコーディネータから参加側サービスに送信されるHTTPコールバックAPIリクエストをアクティブにしておく最長期間(秒)を指定します。0から900までの整数を入力してください。デフォルト値は180秒、最大値は900秒です。この値を0に設定すると、MicroTxによって制限が適用されません。コーディネータがHTTPコールバックAPIリクエストを参加側サービスに送信したとき、参加側サービスは指定の期間内に応答する必要があります。指定した期間内に参加側サービスが応答しないと、コーディネータによって送信されたHTTPリクエストはタイムアウトします。
xaCoordinator.enabled、lraCoordinator.enabledまたはtccCoordinator.enabled	使用するトランザクション・プロトコルに対してenabled: trueを設定します。MicroTxは、XA、LRA、およびTCCの3つの分散トランザクション・プロトコルをサポートしています。XAトランザクションをLRAトランザクション内にネストする場合は、enabled: trueをxaCoordinatorとlraCoordinatorの両方に対して設定します。
xaCoordinator.txMaxTimeout	XAトランザクション・プロトコルのみ。トランザクションをアクティブにしておく最長期間(ミリ秒)を指定します。トランザクションのコミットまたはロールバックが指定した期間内に行われないと、トランザクションはロールバックされます。デフォルト値は600000 msです。
narayanaLraCompatibilityMode.enabled	LRAトランザクション・プロトコルのみ。Narayana LRAコーディネータと連携するように実装され、MicroTxを使用してLRAトランザクションに参加するLRA参加側アプリケーションを使用する場合は、このプロパティをtrueに設定します。このモードを有効にすると、MicroTx LRA APIがNarayana LRAコーディネータAPIが返すのと同じレスポンス・データを返すことが保証されます。
logging.level	次のいずれかのタイプを入力して、MicroTxのログ・レベルを指定します: info: MicroTxの通常の操作中に発生するイベントを記録します。この設定では、最小限の情報を記録します。これはデフォルトの設定です。 warning: 有害な状況を引き起こす可能性のあるイベントをログに記録します。 error: トラブルシューティングが必要な問題があることを示すためにイベントをログに記録します。 debug: すべてのイベントをログに記録します。この設定は、問題をデバッグする場合に使用します。
logging.httpTraceEnabled	デバッグ時にMicroTx内のすべてのHTTPリクエストおよびレスポンスをログに記録するには、これをTrueに設定します。これをTrueに設定する場合、logging: level:をdebugに設定する必要もあります。
logging.devMode	これは、テスト環境でデバッグのために詳細情報を取得する場合のみ、Trueに設定します。本番環境では、これをFalseに設定する必要があります。
maxRetryCount	障害が発生した場合にトランザクション・コーディネータが同じリクエストの送信を再試行する最大回数。たとえば、10です。
minRetryInterval	障害が発生した後でトランザクション・コーディネータが同じリクエストの送信を再試行するまでの最小間隔(ミリ秒)。デフォルト値は1000ミリ秒です。
maxRetryInterval	障害が発生した後でトランザクション・コーディネータが同じリクエストの送信を再試行するまでの最大再試行間隔(ミリ秒)。たとえば、10000です。
skipVerifyInsecureTLS	この値をfalseに設定し、安全なアクセスのために信頼できる認証局によって署名された有効な証明書を設定することをお薦めします。この値をfalseに設定すると、トランザクション・コーディネータは、信頼できる認証局によって署名された有効な証明書を使用して、HTTPSプロトコルを介して参加側アプリケーションにアクセスします。デフォルト値はfalseです。 この値をtrueに設定すると、トランザクション・コーディネータは、有効なSSL証明書を使用せずに、参加側アプリケーションのコールバックURLに安全でない方法でアクセスします。 注意: 本番環境では、この値をtrueに設定しないでください。

5.8.2 トランザクション・ストアのプロパティ

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を再起動するたびに、すべてのトランザクションの詳細が失われます。内部メモリーをトランザクション・ストアとして使用し、トランザクション・コーディネータの複数のレプリカを使用する場合は、セッション・アフィニティを有効にする必要があります。

トランザクション・ストアとしてのOracle Database

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

必要なDockerシークレットの作成の詳細は、「Oracle Database資格証明のDockerシークレットの作成」を参照してください。

プロパティ	説明
connectionString	Oracle Databaseのトランザクション・ストアへの接続文字列を入力します。 非自律型Oracle Database (資格証明ウォレットを使用しないデータベース)を使用している場合は、次の形式を使用して接続文字列を入力します: <publicIP>:<portNumber>/<database unique name>.<host domain name> たとえば、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 Databaseを使用している場合は、次の例のような接続文字列を入力します: jdbc:oracle:thin:@tcps://adb.us-phoenix-1.oraclecloud.com:7777/unique_connection_string_low.adb.oraclecloud.com&wallet_location=/app/Wallet。
netServiceName	Oracle Databaseに接続するための資格証明を含むDockerシークレットの名前を入力します。たとえば、db-secretです。

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

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

プロパティ	説明
endpoints	Docker SwarmサービスとしてetcdにアクセスするURLを入力します。たとえば、etcdとトランザクション・コーディネータがDocker Swarmの同じネットワークにある場合は、https://etcd:2379です。ここで、2379はetcdとの通信に使用されるポートです。etcdが別のネットワークに設定されている場合は、etcdのIPアドレスを指定します。
skipHostNameVerification	etcdデータベース・サーバーのIPアドレスを確認するには、これをfalseに設定します。これをtrueに設定すると、サーバーのホスト名またはIPアドレスは検証されません。このフィールドをtrueに設定できるのは、テスト環境または開発環境の場合のみです。 注意: 本番環境では、このフィールドをfalseに設定する必要があります。
cacertFilePath	前に作成した証明書であるca.pemファイルへのパスを入力します。たとえば、/app/etcd/ca.pemです。
credentialsFilePath	クライアント資格証明、クライアント・キーおよびクライアント証明書の保護に使用したパスワードを含むJSONファイルの場所を入力します。たとえば、/app/etcd/etcdecred.jsonです。

5.8.3 TLSのプロパティ

HTTPまたはHTTPSプロトコルを使用してMicroTxを実行します。

HTTPSを介してMicroTxにセキュアにアクセスするために、自己署名付き証明書を作成し、証明書および秘密キーの場所を書き留めます。SSL証明書の作成の詳細は、『セキュリティ・ガイド』のOpenSSLを使用した自己署名証明書および秘密キーの生成ガイドラインを参照してください。

tcs-docker-swarm.yamlファイルでTLSを有効にする場合は、サンプル・アプリケーションがMicroTxに安全にアクセスできるように、SSL証明書をサンプル・アプリケーションのトラスト・ストアにインポートする必要があります。

tmmConfiguration.serveTLSに、認可に使用するSSL証明書の詳細を指定します。

プロパティ	説明
enabled	参加側サービスとMicroTxの間のセキュアな通信を保証するためにTLSを有効にするには、これをtrueに設定します。証明書およびキー・ファイルの詳細を、certFileプロパティおよびkeyFileプロパティに指定する必要があります。TLSを有効にすると、HTTPSを介してトランザクション・コーディネータにアクセスできます。 このフィールドをfalseに設定した場合、certFileプロパティおよびkeyFileプロパティに値を指定する必要はありません。TLSを無効にしたときは、HTTPを介してトランザクション・コーディネータにアクセスできます。HTTPプロトコルを使用するinternalAddrおよびexternalUrlを指定する必要があります。たとえば、http://localhost:9000のようになります。 注意: 本番環境では、このフィールドをtrueに設定する必要があります。
certFile	ローカル・マシン上のTLS証明書(PEM形式)のパス。
keyFile	ローカル・マシン上の証明書に関連付けられている秘密キー・ファイル(PEM形式)のパス。

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

tmmConfiguration:
  serveTLS:
    enabled: true
    certFile: /users/john.doe/self-signed/tcs/certificate.pem
    keyFile: /users/john.doe/self-signed/tcs/key.pem

5.8.4 認可のプロパティ

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

プロパティ	説明
enabled	これをtrueに設定すると、MicroTxが受信JWTトークンのサブジェクトをチェックできるようになります。その後、MicroTxは、サブジェクトまたはユーザーにトランザクションIDをタグ付けします。トランザクションをさらに変更できるのは、タグ付けされたサブジェクトまたはユーザーのみになります。このフィールドをfalseに設定した場合、tmmConfiguration.authorizationの他のプロパティに値を指定する必要はありません。 注意: 本番環境では、このフィールドをtrueに設定する必要があります。
authTokenPropagationEnabled	参加側サービスとMicroTxの間のセキュアな通信を確保するためにトークン伝播を有効にするには、これをtrueに設定します。トークン伝播を有効にした場合は、tcs-docker-swarm.yamlファイルのencryptionプロパティに暗号化キーの詳細を指定する必要があります。
IdentityProviderName	使用するアイデンティティ・プロバイダを指定します。指定できる値は、Oracle IDCSおよびOracle IAMのIDCS、KeycloakのKEYCLOAK、Azure Active DirectoryのAZURE_AD、Microsoft Active DirectoryのMICROSOFT_ADです。
IdentityProviderUrl	アイデンティティ・プロバイダのURLを指定します。この情報は、リフレッシュ・トークンを使用して新しいアクセス・トークンを作成するために必要です。この情報を指定しないと、期限切れになったアクセス・トークンが自動リフレッシュされません。
IdentityProviderClientId	アイデンティティ・プロバイダのクライアントIDを指定します。この情報は、リフレッシュ・トークンを使用して新しいアクセス・トークンを作成するために必要です。この情報を指定しないと、期限切れになったアクセス・トークンが自動リフレッシュされません。

5.8.5 認証のプロパティ

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

認証を有効にすると、トランザクション・コーディネータが、JWTベースの認証を強制し、公開キーに対して認証トークンを検証します。authorizationヘッダーでアクセス・トークンを渡す必要があります。

プロパティ	説明
enabled	JWT認証をバイパスするには、falseに設定します。こうすると、JWTトークンのないリクエストが許可されます。すべてのリクエストにJWTトークンを含める場合は、trueを入力します。MicroTxは、リクエストで指定されたトークンを検証し、トークンが無効な場合はアクセスを拒否します。enabledをtrueに設定する場合は、JWTのissuerパラメータおよびjwksUriパラメータに値を指定する必要があります。 注意: 本番環境では、このプロパティをtrueに設定する必要があります。
jwt.issuer	JWTトークン発行元を指定します。
jwt.jwksUri	アイデンティティ・プロバイダのパブリック・ホストjwksUriのURL。JWTの署名の検証に使用されます。JSON Web Key Set (JWKS)には、受信JWTトークンの検証に使用される暗号化キーが含まれます。

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

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

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

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

プロパティ	説明
EncryptionSecretKeyVersion	トランザクション・トークンの暗号化に使用するキーのバージョンを指定します。
secretKeys.secretKeyName	暗号化キーを含むDockerシークレットを指す環境変数の名前を指定します。暗号化キーのローテーションをサポートするために、複数の暗号化キーとそのバージョンを指定できます。
secretKeys.version	使用するDockerシークレットのバージョンを入力します。

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

次のコード・スニペットは、tcs-docker-swarm.yamlファイルのencryptionフィールドのサンプル値を示しています。この例のサンプル値は、暗号化キーとキー・ペアの作成のサンプル・コマンドで使用された値に基づいています。

encryption:
  secretKeys: '{"secretKeys":[{"secretKeyName":"TMMSECRETKEY", "version":"1"}]}'
  #TMMSECRETKEY is the environment variable that points to the Docker secret that contains the encryption key. 
  EncryptionSecretKeyVersion: 1

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

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

tcs-docker-swarm.yamlでtransactionTokenEnabledをtrueに設定する場合は、次の表に示すプロパティの値を指定する必要があります。

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

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

transactionToken:
  transactionTokenEnabled: false
  keyPairs: '{"keyPairs":[{"privateKeyName":"TMMPRIKEY", "publicKeyName":"TMMPUBKEY", "version":"1", "privateKeyPasswordName":"TMMPRIKEYPASSWD"}]}'
     #TMMPRIKEY is the environment variable for the Docker secret that contains the base64-encoded private key
     #TMMPUBKEY is the environment variable for the Docker secret that contains the base64-encoded public key
     #TMMPRIKEYPASSWD is the environment variable for the Docker secret that contains the private key password
  transactionTokenKeyPairVersion: 1

5.9 アプリケーションのセキュアな接続の構成

1. すべての参加側およびイニシエータ・アプリケーションのMicroTxライブラリ・プロパティの構成情報を指定します。

   任意のコード・エディタでtmm.propertiesファイルを開き、次のパラメータの値を入力してMicroTxライブラリを構成します。

   • oracle.tmm.TcsUrl: MicroTxアプリケーションにアクセスするためのURLを入力します。「MicroTxへのアクセス」を参照してください。この値はトランザクション・イニシエータ・アプリケーションの場合に入力する必要があります。トランザクション参加側アプリケーションの場合、この値を指定する必要はありません。

   • oracle.tmm.CallbackUrl: MicroTxがコールバックする参加側サービスのURLを入力します。この値を次の形式で指定します。

     http://HostNameofApp:PortofApp/

     説明

     • HostNameofApp: イニシエータ・サービスまたは参加側サービスのホスト名。たとえば、host.docker.internalです。
     • PortofApp: 参加側サービスにアクセスできるポート番号。たとえば、8080です。

   次の例は、環境変数のサンプル値を示しています。ご自身の環境に基づいて値を指定してください。

   oracle.tmm.TcsUrl = https://localhost:9000/api/v1
   oracle.tmm.CallbackUrl = http://host.docker.internal:8080

2. JavaマイクロサービスがTLSを介してトランザクション・コーディネータにアクセスするためには、keytoolを使用してTLS証明書をJREキーストアにインポートする必要があります。

   export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-11.0.11.jdk/Contents/Homesudo keytool -import -trustcacerts -alias tcs-localhost -file localhost.pem -keystore $JAVA_HOME/lib/security/cacerts

3. Node.jsマイクロサービスがTLSを介してトランザクション・コーディネータにアクセスするためには、NODE_EXTRA_CA_CERTS環境変数をルート証明書(PEM形式)のパスに設定します。

   export NODE_EXTRA_CA_CERTS=./rootCA.crt

   SSL証明書の作成の詳細は、『セキュリティ・ガイド』のOpenSSLを使用した自己署名証明書および秘密キーの生成ガイドラインを参照してください。

5.10 Docker SwarmでのMicroTxへのアクセス

MicroTxにアクセスするには、内部URLまたは外部URLを使用します。MicroTxに、サービスをデプロイしたDockerレジストリ内からアクセスするか、Dockerレジストリ外からアクセスするかに応じて、異なるURLを使用します。

TLSを有効にした場合は、HTTPSプロトコルを使用してサービスにアクセスします。TLSを無効にした場合は、HTTPプロトコルを使用してサービスにアクセスします。

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

内部URLを使用して、サービスをデプロイしたDockerレジストリ内からMicroTxにアクセスします。

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

http://internalHostname:listenAddr/api/v1

説明

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

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

Dockerレジストリ内のすべての通信では、HTTPプロトコルが使用されます。

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

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

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

https://externalHostname:listenAddr/api/v1

説明

• externalHostname: 作成したDockerレジストリのIPアドレス。たとえば、198.51.100.1です。
• listenAddr: MicroTxのtcs-docker-swarm.yamlのlistenAddrプロパティに入力したポート番号。たとえば、5000です。このポートを介したインバウンドおよびアウトバウンドのHTTPSまたはHTTPトラフィックを許可するために必要なネットワーキング・ルールを設定したことを確認します。

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

次のコマンドに示すように、DockerレジストリのIPアドレスをREGISTRY_IPADDRという名前の環境変数に格納します。

export REGISTRY_IPADDR=192.0.2.1

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

5.11 DockerコンテナでのMicroTxの実行

さらに、別のDockerコンテナでMicroTxを使用できます。この項の手順に従って、HTTPSポートでMicroTxをローカルに実行します。

Docker Swarmでサンプル・アプリケーションとともにMicroTxを実行するには、「Docker SwarmでのサンプルLRAアプリケーションの実行」を参照してください。

開始する前に、MicroTx Dockerイメージをロードし、tcs.yamlファイルを更新していることを確認してください。tcs.yamlファイルは、ローカル・マシンのinstallation_directory/otmm-<version>/otmm/imageにあります。このファイルには、MicroTxのデプロイメント構成の詳細が含まれています。tcs.yamlファイルおよびtcs-docker-swarm.yamlファイルのプロパティは類似しています。構成の詳細は、tcs-docker-swarm.yamlファイルの構成を参照してください。

1. tcs.yamlファイルを証明書およびキー・ファイルとともに現在のディレクトリに配置します。tcs.yamlファイルのtmmConfiguration.serveTLS.enabledをtrueに設定してTLSを有効にした場合は証明書およびキー・ファイルを現在のディレクトリにコピーする必要があります。
2. tcs.yamlファイルに指定されている構成詳細を使用して、MicroTxを実行します。

   サンプル・コマンド

   docker container run --name otmm -v "$(pwd)":/app/config \
   -w /app/config -p 9000:9000/tcp --env CONFIG_FILE=tcs.yaml \
   --add-host host.docker.internal:host-gateway -d tmm:<version>

   説明

   • otmmは、作成するコンテナの名前です。
   • tmm:<version>は、ローカルDockerリポジトリにロードしたMicroTx Dockerイメージです。
3. インストールが完了したら、MicroTxにアクセスできます。次のコマンドを実行して、MicroTxにアクセスできることを確認します。

   curl --cacert localhost.pem \
             -v -X POST  \
             -H "Content-Type: application/json" \
             https://localhost:9000/api/v1/xa-transaction

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