Skip to main content

This documentation is for an older version of this product. See the latest version of this content.Opens in a new tab

InterSystems Cloud Manager の使用

この章では、ICM を使用して InterSystems IRIS 構成をパブリック・クラウドに導入する方法について、以下のように説明します。各セクションでは、ICM を使用してサンプル InterSystems IRIS 構成を AWS に導入するために必要な手順について、以下のように説明します。

  • この章全体で例として使用される 2 つのサンプル・ユース・ケースに基づいて、導入について検討します。

  • インターシステムズ提供の ICM イメージに対して docker run コマンドを使用して、ICM コンテナを起動し、コマンド行を開きます。

  • セキュリティ保護された通信を ICM が行うために必要なクラウド・プロバイダと TLS 資格情報を入手します。

  • プロビジョニングする各ノード・タイプのノード数と、その他の必要な選択を行った後、導入に必要な構成ファイル defaults.json および definitions.json を作成します。

  • icm provision コマンドを使用してインフラストラクチャをプロビジョニングし、ICM のインフラストラクチャ管理コマンドを検討します。いつでも再プロビジョニングを行って、既存のインフラストラクチャを変更できます (拡張や縮小を含む)。

  • icm run コマンドを実行してコンテナを導入し、ICM のコンテナおよびサービスの管理コマンドを検討します。インフラストラクチャが再プロビジョニングされた場合や、コンテナを追加、削除、またはアップグレードする場合は、再導入を行うことができます。

  • icm unprovision コマンドを実行して導入を破棄します。

以下のセクションで詳しく説明されている ICM コマンドとコマンド行オプションの総合的なリストについては、"ICM コマンドおよびオプション" を参照してください。

ICM のユース・ケース

この章では、以下の 2 つの InterSystems IRIS 構成を導入する、2 つの代表的な ICM のユース・ケースを中心に説明します。

  • 分散キャッシュ・クラスタ — ミラーリングされたデータ・サーバ、3 つのアプリケーション・サーバ、アービター・ノード、およびロード・バランサ。この導入については、セクション "分散キャッシュ・クラスタの定義ファイル" に図示しています。

  • 基本的なシャード・クラスタ — ミラーリングされた 3 つのデータ・ノード、アービター・ノード、およびロード・バランサ。この導入については、セクション "シャード・クラスタ定義ファイル" に図示しています。

導入プロセスの手順のほとんどは、どちらの構成でも同じです。主な違いは定義ファイルにあります。詳しい内容は、"導入の定義" を参照してください。プロビジョニング・フェーズ中の出力例 ("icm provision コマンド") は、分散キャッシュ・クラスタのものです。導入フェーズ中の出力例 ("サービスの導入と管理") は、シャード・クラスタのものです。

ICM の起動

ICM は、Docker イメージとして提供されています。例えば Terraform、Docker クライアント、構成ファイルのテンプレートなど、プロビジョニング、導入、および管理のタスクを実行するために ICM が必要とするすべてが ICM コンテナに含まれています。このため、ICM を起動する Linux、macOS、または Microsoft Windows システムの要件は、Docker がインストールされていることのみです。

Important:

ICM は、Docker Enterprise Edition および Community Edition バージョン 18.09 以降でサポートされています。実稼働環境でサポートされているのは Enterprise Edition のみです。

Note:

異なるユーザが導入プロセスの異なるフェーズを実行できるようにする場合など、複数の ICM コンテナを使用して 1 つの導入環境を管理できます。詳細は、付録 “ICM 導入環境の共有” を参照してください。

ICM イメージのダウンロード

ICM を使用するには、作業中のシステムに ICM イメージをダウンロードする必要があります。これには、ダウンロード元のレジストリと、アクセスに必要な資格情報を識別することが必要になります。同様に、ICM で InterSystems IRIS およびその他のインターシステムズのコンポーネントを導入するには、関係するイメージのこの情報が必要です。ICM がイメージをダウンロードするレジストリは、使用するクラウド・プロバイダからアクセス可能である (つまり、ファイアウォールの背後にない) ことが必要です。また、セキュリティを確保するために、ICM はユーザから提供された資格情報を使用して認証する必要があります。

containers.intersystems.comOpens in a new tab にある InterSystems Container Registry (ICR) には、ICM イメージや InterSystems IRIS イメージを含め、インターシステムズから入手可能なすべてのイメージのリポジトリが含まれています。入手可能なイメージおよび ICR の使用法の詳細は、"InterSystems Container Registry の使用Opens in a new tab" を参照してください。さらに、組織のプライベート・イメージ・レジストリにインターシステムズのイメージが既に格納されている場合もあります。その場合は、責任のある管理者から、レジストリの場所と認証に必要な資格情報を入手してください。

ICR または組織のレジストリのどちらかにログインしたら、docker pull コマンドを使用してイメージをダウンロードできます。以下の例は、ICR からのプルを示しています。

$ docker login containers.intersystems.com
Username: pmartinez
Password: **********
$ docker pull containers.intersystems.com/intersystems/icm:2022.2.0.221.0
5c939e3a4d10: Pull complete
c63719cdbe7a: Pull complete
19a861ea6baf: Pull complete
651c9d2d6c4f: Pull complete
$ docker images
REPOSITORY                                    TAG            IMAGE ID      CREATED      SIZE
containers.intersystems.com/intersystems/iris 2022.2.0.221.0 15627fb5cb76  1 minute ago 1.39GB
containers.intersystems.com/intersystems/sam  1.0.0.115      15627fb5cb76  3 days ago   1.33GB
acme/centos                                   7.3.1611       262f7381844c  2 weeks ago  192MB
acme/hello-world                              latest         05a3bd381fc2  2 months ag  1.84kB

わかりやすくするために、このドキュメントの手順では、InterSystems リポジトリからの、2022.2.0.221.0 タグの付いたインターシステムズのイメージを使用していると想定しています (例 ： intersystems/icm:2022.2.0.221.0)。

ICM で使用されるイメージが同じレジストリにあるかどうかに関係なく、DockerImage フィールドでレジストリを含むイメージ ID を指定し、イメージごとに DockerUsername フィールドと DockerPassword フィールドで認証に必要な資格情報を指定する必要があります (“InterSystems Cloud Manager の基本的な要素” の章の "Docker リポジトリ" を参照)。

ICM コンテナの実行

Docker がインストールされているシステムでコマンド行から ICM を起動するには、docker run コマンド (実際は 3 つの個別の Docker コマンドの組み合わせ) を使用して、以下の操作を行います。

  • ICM イメージがまだローカルにない場合、リポジトリからダウンロードします。存在する場合、これは必要に応じて更新されます (docker pull コマンドを使用して、別途、この手順を行うこともできます)。

  • ICM イメージからコンテナを作成します (docker create コマンド)。

  • ICM コンテナを起動します (docker start コマンド)。

例 ：

docker run --name icm --init -d -it --cap-add SYS_TIME intersystems/icm:2022.2.0.221.0

-i オプションを指定するとコマンドがインタラクティブになり、-t オプションを指定すると疑似 TTY が開いて、コンテナにコマンド行からアクセスできます。ここからは、疑似 TTY コマンド行で ICM コマンドを呼び出して ICM を操作できます。--cap-add SYS_TIME オプションを指定すると、コンテナがホスト・システム上のクロックを操作できます。これにより、クラウド・サービス・プロバイダが API コマンドを拒否する原因になるクロック・スキューが回避されます。

ICM コンテナには /Samples ディレクトリが含まれており、ICM でプロビジョニング、構成、および導入を行うために必要な要素のサンプルが用意されています。/Samples ディレクトリを使用すれば、ICM をすぐに使用したプロビジョニングと導入が容易になります。最終的に、これらの要素と InterSystems IRIS ライセンスを格納するために、コンテナ外部の場所を使用できます。また、ICM 起動時にその場所を外部ボリュームとしてマウントすることも (Docker ドキュメントの "Manage data in DockerOpens in a new tab" を参照)、docker cp コマンドを使用して ICM コンテナにファイルをコピーすることもできます。

もちろん、カスタムのツールとスクリプトを使用して ICM イメージを実行することもできます。これは、例えば、コンテナ内でこのような外部の場所を使用できるようにしたり、また構成ファイルと state ディレクトリ (プロビジョニングしたインフラストラクチャとサービスを削除するために必要) をコンテナ外部の永続ストレージに保存したりするためにも役立つ場合があります。例えば以下のように、スクリプトによって現在の作業ディレクトリを変数に取り込み、ICM コンテナの実行時にストレージ・ボリュームとしてそのディレクトリをマウントすることによって、永続ストレージへの保存を行うことができます。


#!/bin/bash
clear

# extract the basename of the full pwd path
MOUNT=$(basename $(pwd))
docker run --name icm -d -it --volume $PWD:$MOUNT --cap-add SYS_TIME intersystems/icm:2022.2.0.221.0 
printf "\nExited icm container\n"
printf "\nRemoving icm container...\nContainer removed:  "
docker rm icm

ICM コンテナ (またはその他のもの) を実行する際に、複数の外部ストレージ・ボリュームをマウントできます。InterSystems IRIS コンテナを導入する際、ICM はいくつかのストレージ・ボリュームのフォーマット、パーティション分割、およびマウントを自動的に行います。詳細は、“ICM リファレンス” の章にある "ICM によってマウントされるストレージ・ボリューム" を参照してください。

Note:

Windows ホストでは、Docker の [Settings...] メニューの [Shared Drives] オプションを使用して、ボリュームとしてマウントするディレクトリが配置されているローカル・ドライブを有効にする必要があります。Docker for Windows のその他の要件および一般的な情報については、InterSystems Developer Community の "Using InterSystems IRIS Containers with Docker for WindowsOpens in a new tab" を参照してください。

Important:

ICM の操作中にエラーが発生した場合、ICM はログ・ファイルを示すメッセージを表示します。このログ・ファイルで、エラーに関する情報を確認できます。ICM の導入を開始する前に、"ログ・ファイルとその他の ICM ファイル" で説明されている、ログ・ファイルとその場所をよく理解しておいてください。

ICM コンテナのアップグレード

分散管理モードでは、異なるシステム上の異なるユーザが ICM を使用して同じ導入環境を管理でき、ICM コンテナが管理している導入環境の必要な状態ファイルを保持しながら ("状態ディレクトリと状態ファイル" を参照)、ICM コンテナをアップグレードする手段が提供されます。導入環境を管理している ICM コンテナをアップグレードする際にはこの方法が推奨されるので、分散管理を使用するかどうかに関係なく、このオプションを使用できるように、ICM を使用するたびに分散管理モードを構成することをお勧めします。サービスの検出モードで ICM をアップグレードする方法については、"分散管理モードを使用した ICM のアップグレード" を参照してください。

セキュリティ関連ファイルの入手

ICM は、インフラストラクチャをプロビジョニングする対象のクラウド・プロバイダ、プロビジョニングされた各ノードのオペレーティング・システム、およびコンテナの導入後は Docker および複数の InterSystems IRIS サービスとの間で、セキュリティ保護された通信を行います。導入を定義する前に、セキュリティ保護された通信を有効にするために必要な資格情報とその他のファイルを入手する必要があります。

クラウド・プロバイダの資格情報

パブリック・クラウド・プラットフォームのいずれかと組み合わせて ICM を使用するには、アカウントを作成して管理用の資格情報をダウンロードする必要があります。このためには、クラウド・プロバイダが提供する指示に従ってください。また、アカウントを作成した後で資格情報をダウンロードする方法については、“ICM リファレンス” の章の "プロバイダ固有のパラメータ" のセクションに説明があります。ICM 構成ファイルで、プロバイダに固有のパラメータを使用してこれらの資格情報の場所を指定します。AWS の場合は、Credentials パラメータを使用します。

vSphere プライベート・クラウドと組み合わせて ICM を使用する場合は、必要な特権を持つ既存のアカウントを使用することも、新規アカウントを作成することもできます。これらの情報は、Username フィールドと Password フィールドを使用して指定します。

SSH 鍵と TLS 鍵

ICM は、プロビジョニングされたノードのオペレーティング・システムへのセキュリティ保護されたアクセスを提供するために SSH を使用し、Docker、インターシステムズの Web ゲートウェイ、および JDBC への接続と、InterSystems IRIS のミラー、分散キャッシュ・クラスタ、およびシャード・クラスタ内のノード間のセキュリティ保護された接続を確立するために TLS を使用します。このセキュリティ保護された通信を有効にするために必要なファイルの場所は、以下のようないくつかの ICM パラメータを使用して指定します。

  • SSHPublicKey

    プロビジョニングされたホスト・ノードへのセキュリティ保護された接続を有効にするために使用される SSH 公開/秘密鍵ペアの公開鍵。AWS の場合は SSH2 形式、その他のプロバイダの場合は OpenSSH 形式です。

  • SSHPrivateKey

    SSH 公開/秘密鍵ペアの秘密鍵。

  • TLSKeyDir

    Docker、インターシステムズの Web ゲートウェイ、JDBC、およびミラーリングされた InterSystems IRIS データベースへのセキュリティ保護された接続を確立するために使用される TLS 鍵を含むディレクトリ。

これらのファイルを作成して ICM で使用でき、またこれらのファイルを検討してどれが必要か確認できます。このためには、ICM コンテナ内のディレクトリ /ICM/bin に用意されている 2 つのスクリプトを使用します。keygenSSH.sh スクリプトは、必要な SSH ファイルを作成して、ICM コンテナ内のディレクトリ /Samples/ssh に配置します。keygenTLS.sh スクリプトは必要な TLS ファイルを作成し、/Samples/tls に配置します。導入を定義する際にこれらの場所を指定でき、これらのディレクトリの内容に基づいてユーザが独自にファイルを取得することもできます。

keygen* スクリプトによって生成される、ICM で必要なセキュリティ・ファイルの詳細は、“ICM リファレンス” の章の "ICM セキュリティ" および "セキュリティ関連のパラメータ" を参照してください。

Important:

これらのスクリプトによって生成される鍵、およびクラウド・プロバイダの資格情報により、これらが使用される ICM 導入環境へのフルアクセスが可能になるので、これらの情報は完全にセキュリティ保護する必要があります。

keygen* スクリプトによる鍵は、初期テスト導入でユーザが便利に使用できるように生成されます。(一部は、インターシステムズ社に固有の文字列を含んでいます。)プロダクション環境では、必要な鍵は企業のセキュリティ・ポリシーに準拠して生成または取得する必要があります。

導入の定義

必要なパラメータを ICM に指定するには、目的と状況に応じていくつかのフィールドの値を選択した後、導入に使用する既定値ファイルと定義ファイルにこれらの値を取り込む必要があります。ICM コンテナ内の /Samples ディレクトリ・ツリー (例えば /Samples/AWS) で提供されているテンプレート defaults.json ファイルと definitions.json ファイルから始めることができます。

"構成ファイル、状態ファイル、およびログ・ファイル" に記載されているように、defaults.json は多くの場合、特定のカテゴリに属する複数の導入環境 (同じプラットフォーム上でプロビジョニングされるものなど) の共有設定を提供するために使用されるのに対し、別個の definitions.json ファイルでは、それぞれの導入環境についてプロビジョニングして構成する必要があるノード・タイプを定義します。例えば、ここに示す別個の定義ファイルでは、この章の冒頭で説明した 2 つのターゲット導入環境を定義します。分散キャッシュ・クラスタには、ミラーリングされたデータ・サーバとしての DM ノードが 2 つ、アプリケーション・サーバとしての負荷分散 AM ノードが 3 つ、およびアービター (AR) ノードが 1 つ含まれ、シャード・クラスタには、ミラーリングされた 3 つの負荷分散データ・ノードとして構成される DATA ノードが 6 つとアービター・ノードが 1 つ含まれています。同時に、それぞれの導入環境では多数の特性が共通しているため、defaults.json ファイルを共有できます。例えば、これらの導入環境はどちらも AWS 上にあり、同じ資格情報を使用します。また、同じリージョンおよびアベイラビリティ・ゾーンにプロビジョニングされ、同じ InterSystems IRIS イメージを導入します。

Provider などの一部のフィールドは defaults.json で指定し、Role などの一部のフィールドは definitions.json で指定する必要がありますが、その他のフィールドは、ニーズに応じてどちらでも使用できます。この場合は、例えば、InstanceType フィールドは共有の既定値ファイルと両方の定義ファイルで指定します。DM、AM、DATA、および AR の各ノードはすべて、異なる計算リソースを必要とするので、1 つの defaults.json 設定で既定のインスタンス・タイプを設定するだけでは十分ではありません。

以下のセクションでは、導入する InterSystems IRIS インスタンスの構成をカスタマイズする方法について説明すると共に、共有の既定値ファイルと別個の定義ファイルの両方の内容を検討します。それぞれのフィールド/値のペアは、構成ファイルに指定されるとおりに記載されています。

ICM を使用すると、既存の導入環境の定義ファイルを変更した後、再プロビジョニングや再導入を行ってノードを追加または削除したり、既存のノードを変更したりすることができます。詳細は、"インフラストラクチャの再プロビジョニング" および "サービスの再導入" を参照してください。

Important:

フィールド名と値の両方で大文字と小文字が区別されます。例えば、クラウド・プロバイダとして AWS を選択するには、既定値ファイルで、“provider”:”AWS” や “Provider”:”aws” などではなく “Provider”:”AWS” と指定する必要があります。

Note:

ここに含まれているフィールドは、適用される可能性があるフィールドのサブセットを表します。必須のフィールドとオプションのフィールド (一般的なものとプロバイダ固有のものの両方を含む) すべての包括的なリストについては、"ICM の構成パラメータ" を参照してください。

共有の既定値ファイル

このセクションのテーブルに示すフィールド/値のペアは、分散キャッシュ・クラスタ導入とシャード・クラスタ導入の両方に使用できる defaults.json ファイルの内容を表しています。このセクションの冒頭で説明したように、以下に示す /Samples/AWS/default.json ファイルにいくつかの変更を加えることで、このファイルを作成できます。

{
    "Provider": "AWS",
    "Label": "Sample",
    "Tag": "TEST",
    "DataVolumeSize": "10",
    "SSHUser": "ubuntu",
    "SSHPublicKey": "/Samples/ssh/insecure-ssh2.pub",
    "SSHPrivateKey": "/Samples/ssh/insecure",
    "DockerRegistry": "containers.intersystems.com",
    "DockerImage": "containers.intersytems.com/intersystems/iris:some-tag",
    "DockerUsername": "xxxxxxxxxxxx",
    "DockerPassword": "xxxxxxxxxxxx",
    "TLSKeyDir": "/Samples/tls/",
    "LicenseDir": "/Samples/license/",
    "Region": "us-east-1",
    "Zone": "us-east-1a",
    "AMI": "ami-07267eded9a267f32",
    "DockerVersion": "5:20.10.17~3-0~ubuntu-jammy",
    "InstanceType": "m5.large",
    "Credentials": "/Samples/AWS/sample.credentials",
    "ISCPassword": "",
    "Mirror": "false",
    "UserCPF": "/Samples/cpf/iris.cpf"
}

テーブル内のフィールドの順序は、このサンプル既定値ファイルの順序と一致しています。

別のプロバイダの既定値ファイルでは、プロバイダ固有の異なる値が指定されるフィールドもあれば、プロバイダ固有の異なるフィールドに置き換えられるフィールドもあります。例えば、Tencent の既定値ファイルでは、InstanceType の値は S2.MEDIUM4 です。これは Tencent 固有のインスタンス・タイプであり、AWS では無効です。また、AWS の AMI フィールドは、Tencent の同等のフィールドである ImageId に置き換えられます。/Samples ディレクトリ・ツリー内のさまざまな defaults.json ファイルを調べ、“ICM リファレンス” の章にある "一般パラメータ" と "プロバイダ固有のパラメータ" のテーブルを参照することによって、これらの違いを確認できます。

Note:

このサンプル既定値ファイルでセキュリティ・ファイルを指定するフィールドに示されているパス名は、AWS 資格情報を /Samples/AWS ディレクトリに配置していること、また、"セキュリティ関連ファイルの入手" の説明に従って、keygen*.sh スクリプトを使用して鍵を生成していることを前提としています。独自の鍵を生成または取得した場合、これらのパスは、ICM コンテナの実行時にマウントされる外部ストレージ・ボリュームの内部パスに置き換えることもできます ("ICM の起動" を参照)。これらのファイルに関する追加情報は、“ICM リファレンス” の章にある "ICM セキュリティ" および "セキュリティ関連のパラメータ" を参照してください。

共通の特性 /Samples/AWS/defaults.json カスタマイズの例 カスタマイズの説明
インフラストラクチャをプロビジョニングするプラットフォーム (この場合は Amazon Web Services)。“基本的な ICM の要素” の章にある "プロビジョニング・プラットフォーム" を参照してください。 "Provider": "AWS", N/A 値を GCP、Azure、Tencent、vSphere、または PreExisting に変更した場合は、ここに示されているものとは異なるフィールドと値が必要になります。

プロビジョニングされるノードの命名パターンは Label-Role-Tag-NNNN です。Role は、定義ファイル内の Role フィールドの値です (例 ： ANDY-DATA-TEST-0001)。ノード名が所有権と目的を示すように、これらを変更します。

"Label": "Sample",

"Tag": "TEST",

"Label": "ANDY",

"Tag": "TEST",

所有者を示すように更新します。
InterSystems IRIS コンテナ用に作成する永続データ・ボリュームのサイズ (GB 単位)。“ICM リファレンス” の章にある "ICM によってマウントされるストレージ・ボリューム" を参照してください。定義ファイルで特定のノード・タイプについてオーバーライドできます。 "DataVolumeSize": "10",

"DataVolumeSize": "250",

既定値ファイルを使用するすべての導入環境がシャード・クラスタ (DATA) ノードのみで構成される場合は、データ・ボリュームの既定のサイズを大きくすることをお勧めします。

プロビジョニングされたノードへの SSH アクセスのために ICM によって使用される、sudo アクセス権を持つ非 root アカウント。AWS の場合、必要な値は AMI によって異なりますが、Ubuntu AMI の場合は通常 ubuntu になります。“ICM リファレンス” の章にある "セキュリティ関連のパラメータ" を参照してください。

"SSHUser": "ubuntu",

 N/A 値を GCP、Azure、Tencent、vSphere、または PreExisting に変更した場合は、ここに示されているものとは異なるフィールドと値が必要になります。

必要なセキュリティ・キー・ファイルの場所。"セキュリティ関連ファイルの入手" および "セキュリティ関連のパラメータ" を参照してください。プロバイダが AWS なので、/Samples/ssh/ 内の SSH2 形式の公開鍵が指定されています。

"SSHPublicKey": "/Samples/ssh/secure-ssh2.pub",

"SSHPrivateKey": "/Samples/ssh/secure-ssh2",

"TLSKeyDir": "/Samples/tls/",

"SSHPublicKey": "/mydir/keys/mykey.pub",

"SSHPrivateKey": "/mydir/keys/mykey.ppk",

"TLSKeyDir": "/mydir/keys/tls/",

 マウントされた外部ボリュームで鍵をステージングする場合は、これを反映するようにパスを更新します。
プロビジョニングされるノードにインストールされる Docker バージョン。通常、既定値のままにできます。

"DockerVersion": "5:20.10.5~3-0~ubuntu-bionic",

 "DockerVersion": "18.06.1~ce~3-0~ubuntu", 各 /Samples/.../defaults.json のバージョンは通常、プラットフォームに適合しています。ただし、組織で別のバージョンの Docker を使用している場合は、代わりに、そのバージョンをクラウド・ノードにインストールできます。

プロビジョニングされるノードに導入する Docker イメージ。“InterSystems Cloud Manager の基本的な要素” の章の "Docker リポジトリ"、“ICM リファレンス” の章の "icm run コマンド" と "一般パラメータ" を参照。このフィールドを definitions.json のノード定義に含めて、既定値ファイルの値をオーバーライドすることもできます。("分散キャッシュ・クラスタの定義ファイル" を参照)。

"DockerImage": "intersystems/iris:stable",

“DockerImage”: “acme/iris:2022.2.0.221.0" InterSystems IRIS イメージを組織のレジストリにプッシュした場合は、イメージの指定を更新します。

注意 ： 標準プラットフォームの InterSystems IRIS イメージには、iris という名前が付けられます。ARM プラットフォームの場合は iris-arm64 という名前が付けられます。
前のフィールドで指定したイメージを格納する Docker レジストリにログインするための資格情報。"ICM イメージのダウンロード" を参照。

"DockerUsername": "xxxxxxxxxxxx",

"DockerPassword": "xxxxxxxxxxxx",

"DockerUsername": "AndyB",

"DockerPassword": "password",

 指定したレジストリに独自の Docker 資格情報を使用するように更新します。
ICM コンテナ内でステージングされ、定義ファイルの LicenseKey フィールドによって個々に指定される InterSystems IRIS ライセンス・キーの場所。“ICM リファレンス” の章にある "ICM の InterSystems IRIS ライセンス" を参照してください。 "LicenseDir": "/Samples/Licenses",

"LicenseDir": "/mydir/licenses",

マウントされた外部ボリュームでライセンスをステージングする場合は、これを反映するようにパスを更新します。
インフラストラクチャがプロビジョニングされる、プロバイダの計算リソースの地理的地域。"一般パラメータ" を参照してください。 "Region": "us-west-1", "Region": "us-east-2", リージョンとアベイラビリティ・ゾーンの別の有効な組み合わせでプロビジョニングする場合は、これを反映するように値を更新します。
プロビジョニングされるノードを配置する、指定したリージョン内のアベイラビリティ・ゾーン。"一般パラメータ" を参照してください。 "Zone": "us-west-1c", "Zone": "us-east-2a",  
プロビジョニングされるノードのプラットフォームおよび OS のテンプレートとして使用する AMI。“ICM リファレンス” の章にある "Amazon Web Services (AWS) パラメータ" を参照してください。 "AMI": "ami-0121ef35996ede438", "AMI": "ami-e24b7d9d", AMI とインスタンス・タイプの別の有効な組み合わせからプロビジョニングする場合は、これを反映するように値を更新します。

プロビジョニングされるノードの計算リソースのテンプレートとして使用するインスタンス・タイプ。"Amazon Web Services (AWS) パラメータ" を参照してください。

"InstanceType": "m4.large", "InstanceType": "m5ad.large",  

AWS アカウントの資格情報。"Amazon Web Services (AWS) パラメータ" を参照してください。

"Credentials": "/Samples/AWS/sample.credentials",

 “Credentials”: “/mydir/aws-credentials”, マウントされた外部ボリュームで資格情報をステージングする場合は、これを反映するようにパスを更新します。

導入される InterSystems IRIS インスタンスのパスワード。推奨されるアプローチは、導入用コマンド行で指定して ("サービスの導入と管理" を参照)、構成ファイルにパスワードが表示されないようにすることです。

"ISCPassword": "",

 (削除) 削除して、icm run コマンドの -password オプションを使用してパスワードを指定するようにします。

偶数個で定義された特定のノード・タイプ (DM および DATA を含む) をミラーとして導入するかどうか ("ミラーリングの規則" を参照)。

"Mirror": "true"

 N/A 両方の導入環境がミラーリングされます。
導入される InterSystems IRIS インスタンスの初期 CPF 設定をオーバーライドするために使用される構成マージ・ファイル (“ICM リファレンス” の章にある "カスタマイズされた InterSystems IRIS 構成を使用した導入" を参照)。 "UserCPF": "/Samples/cpf/iris.cpf"   構成マージ機能および CPF 設定に精通している場合を除き、削除します ("構成マージを使用した InterSystems IRIS の自動構成Opens in a new tab" を参照)。
Important:

ICM を起動したイメージと DockerImage フィールドを使用して指定した InterSystems IRIS イメージのメジャー・バージョンが一致している必要があります。例えば、2022.1 バージョンの ICM を使用して 2022.2 バージョンの InterSystems IRIS を導入することはできません。インターシステムズのコンテナをアップグレードする前に ICM をアップグレードする方法については、付録 “分散管理モードでの導入環境の共有” の "分散管理モードを使用した ICM のアップグレード" を参照してください。

分散キャッシュ・クラスタの定義ファイル

分散キャッシュ・クラスタの definitions.json ファイルでは、以下のノードを定義する必要があります。

  • ミラーとして構成される 2 つのデータ・サーバ (ロール DM)

  • 3 つのアプリケーション・サーバ (ロール AM)

  • アプリケーション・サーバ用のロード・バランサ

  • データ・サーバ・ミラー用のアービター・ノード

この構成の図を以下に示します。

ICM によって導入される分散キャッシュ・クラスタ
null

以下の表に、この構成に必要なフィールド/値のペアをリストします。

Important:

スタンドアロン InterSystems IRIS インスタンスは、ミラーリングの有無によらず (すなわち、1 つの DM ノードでもミラーを構成する 2 つの DM ノードでも)、分散キャッシュ・クラスタ (DM ノードまたはミラーリングされた DM ノードと AM ノード) と同様に、標準ライセンスで導入できます。すべてのシャード・クラスタ構成では (ノード・レベルまたはネームスペース・レベル、およびミラーリングなしまたはあり)、InterSystems IRIS コンテナが導入されているすべてのノードに、シャーディング対応 InterSystems IRIS ライセンスが必要です。例えば、標準ライセンスを持つミラーリングなし、またはありのスタンドアロン・インスタンスに、DS ノードを追加した場合、すべてのノードに使用されているライセンスをシャーディング・ライセンスにアップグレードする必要があります。

定義 フィールド: 値

ミラーとして構成される (共有の既定値ファイルで "Mirror": "true" と指定されているため)、標準 InterSystems IRIS ライセンスを使用する 2 つのデータ・サーバ (DM)。

インスタンス・タイプ、OS ボリューム・サイズ、データ・ボリューム・サイズでは、データ・サーバのリソース要件に合わせて既定値ファイルの設定をオーバーライドします。

"Role": "DM",

"Count": "2",

"LicenseKey": "ubuntu-standard-iris.key,”

"InstanceType": "m4.xlarge",

"OSVolumeSize": "32",

"DataVolumeSize": "150",

標準 InterSystems IRIS ライセンスを使用する 3 つのアプリケーション・サーバ (AM)。

ノード名の番号は、DM ノードの 0001 および 0002 に続いて 0003 から始まります。

アプリケーション・サーバ用のロード・バランサが自動的にプロビジョニングされます。

"Role": "AM",

"Count": "3",

"LicenseKey": "ubuntu-standard-iris.key”,

"StartCount": "3",

"LoadBalancer": "true",

データ・サーバ・ミラー用の 1 つのアービター (AR)。ライセンスは不要です。アービター・イメージを使用して、既定値ファイルで指定された InterSystems IRIS イメージをオーバーライドします。

ノードの番号は 0006 です。

アービターでは限られたリソースのみが必要なので、インスタンス・タイプで既定値ファイルをオーバーライドします。

"Role": “AR”,

"Count": "1",

"DockerImage": "intersystems/arbiter:2022.2.0.221.0",

"StartCount": "6",

"InstanceType": "t2.small",

上のテーブルの設定を組み込んだ definitions.json ファイルは以下のようになります。

[
    {
        "Role": "DM",
        "Count": "2",
        "LicenseKey": "ubuntu-standard-iris.key”,
        "InstanceType": "m4.xlarge",
        "OSVolumeSize": "32",
        "DataVolumeSize": "150"
    },
    {
        "Role": "AM",
        "Count": "3",
        "LicenseKey": "ubuntu-standard-iris.key”,
        "StartCount": "3",
        "LoadBalancer": "true"
    },
    {
        "Role": "AR",
        "Count": "1",
        "DockerImage": "intersystems/arbiter:2022.2.0.221.0",
        "StartCount": "6",
        "InstanceType": "t2.small"
    }
]

シャード・クラスタの定義ファイル

シャード・クラスタ構成の definitions.json ファイルでは、ミラーリングされた 3 つの負荷分散 DATA ノードを定義する必要があります。これを以下に示します。

ICM によって導入されるシャード・クラスタ
null

以下の表に、この構成に必要なフィールド/値のペアをリストします。

定義 フィールド: 値

  • 3 つのミラーとして構成される (共有の既定値ファイルで "Mirror": "true" と指定されているため)、シャーディング対応 InterSystems IRIS ライセンスを使用する 6 つのデータ・ノード (DATA)。

  • インスタンス・タイプとデータ・ボリューム・サイズでは、データ・ノードのリソース要件に合わせて既定値ファイルの設定をオーバーライドします。

  • データ・ノード用のロード・バランサが自動的にプロビジョニングされます。

"Role": "DATA"

"Count": "6"

"LicenseKey": "ubuntu-sharding-iris.key”

"InstanceType": "m4.4xlarge"

"DataVolumeSize": "250"

"LoadBalancer": "true"

  • データ・サーバ・ミラー用の 1 つのアービター (AR)。ライセンスは不要です。アービター・イメージを使用して、既定値ファイルで指定された InterSystems IRIS イメージをオーバーライドします。

  • ノードの番号は 0007 です。

  • アービターでは限られたリソースのみが必要なので、インスタンス・タイプで既定値ファイルをオーバーライドします。

"Role": “AR”

"Count": "1"

"DockerImage": "intersystems/arbiter:2022.2.0.221.0"

"StartCount": "7"

"InstanceType": "t2.small"

上のテーブルの設定を組み込んだ definitions.json ファイルは以下のようになります。

[
    {
        "Role": "DATA",
        "Count": "6",
        "LicenseKey": "sharding-iris.key”,
        "InstanceType": "m4.xlarge",
        "DataVolumeSize": "250",
        "LoadBalancer": "true"
    },
    {
        "Role": "AR",
        "Count": "1",
        "DockerImage": "intersystems/arbiter:2022.2.0.221.0",
        "StartCount": "7",
        "InstanceType": "t2.small"
    }
]
Note:

ノード・レベルのシャーディング・アーキテクチャをサポートするために、リリース 2019.3 で DATA ノード・タイプと COMPUTE ノード・タイプが ICM に追加されました。このドキュメントの以前のバージョンでは、より大規模な別のノード・タイプのセットを含むネームスペース・レベルのシャーディング・アーキテクチャOpens in a new tabについて説明していました。ネームスペース・レベルのアーキテクチャは、ノード・レベルのアーキテクチャの透過的な基盤として残っており、ノード・レベルのアーキテクチャと完全な互換性があるため、このアーキテクチャを導入するために使用されるノード・タイプは ICM で引き続き使用可能です。使用可能なすべてのノード・タイプについては、"ICM ノード・タイプ" を参照してください。

データベース・キャッシュ・サイズやデータ・ボリューム・サイズの要件など、シャード・クラスタの具体的な導入の詳細は、"スケーラビリティ・ガイド" の “シャーディングによるデータ量に応じた水平方向の拡張” の章にある "シャード・クラスタの導入Opens in a new tab" を参照してください。

ベスト・プラクティスとして、クラスタ内のすべてのデータ・ノード間でアプリケーション接続を負荷分散することをお勧めします。

InterSystems IRIS 構成のカスタマイズ

ICM によって導入されたコンテナ内で実行されるものも含め、InterSystems IRIS インスタンスはすべて、事前に指定された一連の構成設定を使用してインストールされます。これらの設定は、構成パラメータ・ファイル (CPF) に記録されています。既定値ファイルの UserCPF フィールドを使用して ("共有の既定値ファイル" の /Samples/AWS/defaults.json ファイルを参照)、構成マージ・ファイルを指定できます。これにより、導入するすべての InterSystems IRIS インスタンスについて 1 つ以上の構成設定をオーバーライドできます。また、分散キャッシュ・クラスタ内の DM ノードや AM ノード、シャード・クラスタ内の DATA ノードや COMPUTE ノードなど、それぞれのノード・タイプについて異なる設定を定義ファイルでオーバーライドすることもできます。例えば、"スケーラビリティ・ガイド" の “シャーディングによるデータ量に応じた水平方向の拡張” の章にある "InterSystems IRIS シャード・クラスタの計画Opens in a new tab" に記載されているように、シャード・クラスタ内のデータ・ノードのデータベース・キャッシュのサイズを調整することができます。そのためには、DATA の定義のみについて [config]/globals CPF 設定の値をオーバーライドします。マージ・ファイルを使用して初期 CPF 設定をオーバーライドする方法については、“ICM リファレンス” の章にある "カスタマイズされた InterSystems IRIS 構成を使用した導入" を参照してください。

簡単な構成マージ・ファイルが ICM コンテナの /Samples/cpf ディレクトリに用意されており、すべての /Samples プロバイダ・サブディレクトリ内のサンプル既定値ファイルに、このファイルを指す UserCPF フィールドが含まれています。導入される InterSystems IRIS インスタンスの既定の CPF にその内容をマージすることが確実な場合を除き、既定値ファイルから UserCPF を削除してください。

InterSystems IRIS の構成設定、それらの影響、およびインストールされる既定値については、"インストール・ガイドOpens in a new tab"、"システム管理ガイドOpens in a new tab"、および "構成パラメータ・ファイル・リファレンスOpens in a new tab" を参照してください。

インフラストラクチャのプロビジョニング

ICM は、HashiCorp Terraform ツールを使用してクラウド・インフラストラクチャをプロビジョニングします。

Note:

ICM では、既存のクラウド・インフラストラクチャ、仮想インフラストラクチャ、または物理インフラストラクチャにコンテナを導入できます。詳細は、"既存のクラスタへの導入" を参照してください。

icm provision コマンド

icm provision コマンドは、definitions.json ファイルと defaults.json ファイルに指定されたフィールド値、および該当する場合は指定されていないパラメータの既定値を使用して、ホスト・ノードを割り振り、構成します。現在の作業ディレクトリの入力ファイルが使用され、プロビジョニング時に、同じディレクトリに state ディレクトリ、instances.json ファイル、およびログ・ファイルが作成されます (これらのファイルの詳細は、“基本的な ICM の要素” の章にある "構成ファイル、状態ファイル、およびログ・ファイル" を参照してください)。

state ディレクトリと生成される instances.json ファイル (後続の再プロビジョニング、導入、および管理コマンドへの入力として使用される) は導入環境に固有なので、通常は、導入環境ごとにディレクトリを設定して作業するのが最も簡単で効果的なアプローチです。例えば、ここで説明するシナリオ (2 つの異なる導入環境が既定値ファイルを共有する) における最も簡単なアプローチは、"共有の既定値ファイル" に示されているように、/Samples/AWS などのディレクトリで 1 つの導入環境を設定した後、そのディレクトリ全体を (/Samples/AWS2 などに) コピーし、1 つ目の definitions.json ファイルを 2 つ目の定義ファイルに置き換えることです。

プロビジョニング操作の進行中、ICM は計画フェーズ (目的のインフラストラクチャを検証し、状態ファイルを生成する Terraform のフェーズ)、および適用フェーズ (クラウド・プロバイダにアクセスし、マシンの割り振りを実行し、状態ファイルを更新する Terraform のフェーズ) に関する状態メッセージを出します。ICM は複数のスレッドで Terraform を実行するので、マシンがプロビジョニングされる順序と、これらのマシンに追加のアクションが適用される順序は不定です。この例は、以下のサンプル出力に示されています。

また、完了時に、ICM はプロビジョニングされたホスト・ノードと関連コンポーネントの要約を示し、後でインフラストラクチャをプロビジョニング解除 (削除) するために使用できるコマンド行を出力します。

以下の例は、"導入の定義" に記載されている分散キャッシュ・クラスタのプロビジョニングの出力から抜粋したものです。

$ icm provision 
Starting init of ANDY-TEST...
...completed init of ANDY-TEST
Starting plan of ANDY-DM-TEST...
...
Starting refresh of ANDY-TEST...

...
Starting apply of ANDY-DM-TEST...
...
Copying files to ANDY-DM-TEST-0002...
...
Configuring ANDY-AM-TEST-0003...
...
Mounting volumes on ANDY-AM-TEST-0004...
...
Installing Docker on ANDY-AM-TEST-0003...
...
Installing Weave Net on ANDY-DM-TEST-0001...
...
Collecting Weave info for ANDY-AR-TEST-0006...
...
...collected Weave info for ANDY-AM-TEST-0005
...installed Weave Net on ANDY-AM-TEST-0004

Machine            IP Address     DNS Name                                           Region    Zone
-------            ----------     --------                                           ------    ----
ANDY-DM-TEST-0001+ 00.53.183.209  ec2-00-53-183-209.us-west-1.compute.amazonaws.com  us-west-1 c
ANDY-DM-TEST-0002- 00.53.183.185  ec2-00-53-183-185.us-west-1.compute.amazonaws.com  us-west-1 c
ANDY-AM-TEST-0003  00.56.59.42    ec2-00-56-59-42.us-west-1.compute.amazonaws.com    us-west-1 c
ANDY-AM-TEST-0005  00.67.1.11     ec2-00-67-1-11.us-west-1.compute.amazonaws.com     us-west-1 c
ANDY-AM-TEST-0003  00.193.117.217 ec2-00-193-117-217.us-west-1.compute.amazonaws.com us-west-1 c
ANDY-LB-TEST-0002  (virtual AM)   ANDY-AM-TEST-1546467861.amazonaws.com              us-west-1 c
ANDY-AR-TEST-0006  00.53.201.194  ec2-00-53-201-194.us-west-1.compute.amazonaws.com  us-west-1 c
To destroy: icm unprovision [-cleanUp] [-force]
Important:

適切な時期にパブリック・クラウドのホスト・ノードをプロビジョニング解除することで、不要な出費を防ぐことができます。

クラウド・プロバイダとのやり取りに長い待ち時間がかかって、プロバイダ側でタイムアウトや内部エラーが発生することがあります。また、構成ファイル内のエラーが原因でプロビジョニングに失敗することもあります。icm provision コマンドは完全に再入可能なので、ICM が指定ノードすべてに対してすべての必須タスクをエラーなしで完了するまで複数回発行できます。詳細は、次の "インフラストラクチャの再プロビジョニングOpens in a new tab" のセクションを参照してください。

インフラストラクチャの再プロビジョニング

プロビジョニング・プロセスの柔軟性と回復力を可能な限り高めるために、icm provision コマンドは完全に再入可能であり、同じ導入環境について複数回発行できます。icm provision コマンドを複数回実行してインフラストラクチャを再プロビジョニングする主な理由としては、以下の 2 つがあります。

  • プロビジョニング・エラーの解決

    クラウド・プロバイダとのやり取りに長い待ち時間がかかって、プロバイダ側でタイムアウトや内部エラーが発生することがあります。プロビジョニング中にエラーが発生した場合、ICM が指定ノードすべてに対してすべての必須タスクをエラーなしで完了するまで、コマンドを複数回発行できます。

  • プロビジョニングされたインフラストラクチャの変更

    変更が必要な場合、既存のノードの特性の変更、ノードの追加、またはノードの削除を行うことによって、サービスが導入された構成を含め、既にプロビジョニングされたインフラストラクチャをいつでも変更できます。

エラーが発生した後に icm provision コマンドを繰り返す場合に、作業ディレクトリに構成ファイルが含まれていないときは、場所をオーバーライドするオプションを繰り返す必要があります。このファイルはまだ存在しないため、-stateDir オプションを使用して、プロビジョニングを続行する不完全なインフラストラクチャを指定する必要があります。ただし、正常にプロビジョニングされたインフラストラクチャを変更するためにこのコマンドを繰り返すときには、その必要はありません。instances.json ファイルが含まれているディレクトリで作業している限り、自動的にそれを使用して、再プロビジョニングするインフラストラクチャが特定されます これについては、この後のセクションで示します。

プロビジョニング・エラーの解決

icm provision コマンドを発行したときに、エラーが発生してプロビジョニングが正常に完了しなかった場合、state ディレクトリは作成されますが、instances.json ファイルは作成されません。icm provision コマンドを再度発行する際に、現在の作業ディレクトリに state サブディレクトリがない場合は、-stateDir オプションを使用してサブディレクトリの場所を指定します。これにより、プロビジョニングが不完全であることが示され、完了した操作と完了していない操作に関する必要な情報が提供されます。例えば、以下に示す問題が発生したとします。

$ icm provision
Starting plan of ANDY-DM-TEST...
...completed plan of ANDY-DM-TEST
Starting apply of ANDY-AM-TEST...
Error: Thread exited with value 1
See /Samples/AWS/state/Sample-DS-TEST/terraform.err

示されたエラーを確認し、必要に応じて修正してから、同じディレクトリで icm provision を再度実行します。

$ icm provision 
Starting plan of ANDY-DM-TEST...
...completed plan of ANDY-DM-TEST
Starting apply of ANDY-DM-TEST...
...completed apply of ANDY-DM-TEST
[...]
To destroy: icm unprovision [-cleanUp] [-force]

プロビジョニングされたインフラストラクチャの変更

icm run コマンドを使用してサービスが正常に導入された後など、プロビジョニングが正常に完了した後にいつでも、definitions.json ファイルを変更し、icm provision コマンドを再度実行することによって、プロビジョニングされたインフラストラクチャや構成を変更できます 導入済みの構成を変更する場合は、"サービスの再導入" の説明に従って、icm run コマンドを再度実行します。

既存のインフラストラクチャまたは導入済みの構成を以下のように変更することができます。

  • 1 つ以上のノードの特性を変更するには、定義ファイルのノード定義内の設定を変更します。ノードを垂直方向に拡張するような場合に、この作業を行います。例えば、以下の定義で、DataVolumeSize 設定 ("一般パラメータ" を参照) を変更して、DM ノードのデータ・ボリュームのサイズを大きくすることができます。

    {
    "Role": "DM",
    "Count": "2",
    "LicenseKey": "standard-iris.key”,
    "InstanceType": "m4.xlarge",
    "OSVolumeSize": "32",
    "DataVolumeSize": "25"
 },
    Caution:

    ディスク・サイズを変更したり、CPU を追加したりするなど、既存のノードの属性を変更すると、それらのノード (それらの永続ストレージを含む) が再作成されることがあります。この動作はクラウド・プロバイダごとにきわめて特有であり、データの破損や損失の可能性を避けるために注意して使用する必要があります。

    Important:

    再プロビジョニング時には、definitions.json ファイルの Label フィールドと Tag フィールドの変更はサポートされていません。

  • ノードを追加するには、以下に示す 1 つ以上の方法で definitions.json ファイルを変更します。

    • 定義を追加することによって、新しいノード・タイプを追加します。例えば、データ・ノードのみを含むシャード・クラスタを導入した場合、適切な COMPUTE ノードの定義を定義ファイルに追加することによって、計算ノードを追加できます。

    • 既存のノード・タイプの定義で指定されている Count を増やすことによって、そのノード・タイプをさらに追加します。例えば、アプリケーション・サーバが既に 2 つある分散キャッシュ・クラスタにアプリケーション・サーバをさらに 2 つ追加するには、“Count”: “2” を “Count”: “4” に変更して AM の定義を変更します。既存のインフラストラクチャまたは導入済みの構成にノードを追加した場合、既存のノードが再起動されたり変更されたりすることはありません。また、それらの永続ストレージも変更されません。

      Note:

      導入済みのシャード・クラスタにデータがロードされた後にデータ・ノードを追加する場合は、新しいサーバ間でシャード・データを自動的に再分散できます (ただし、これはクラスタをオフラインにして行う必要があります)。詳細は、"スケーラビリティ・ガイド" の “シャーディングによるデータ量に応じた InterSystems IRIS の水平方向の拡張” の章にある "データ・ノードの追加とデータの再分散Opens in a new tab" を参照してください。

      一般に、ICM では変更できず、ノードを追加した後に手動で変更しなければならないアプリケーション固有の属性が多数あります。

    • DATA、COMPUTE、AM、または WS の各ノードの定義に “LoadBalancer": "true" を追加することによって、ロード・バランサを追加します。

  • ノードを削除するには、ノード・タイプの定義で指定されている Count を減らします。指定されたタイプのノードをすべて削除するには、カウントを 0 に減らします。

    Caution:

    定義を完全に削除しないでください。Terraform で変更が検出されず、ICM が追跡しなくなった孤立したノードがインフラストラクチャまたは導入済みの構成に含まれるようになります。

    Important:

    1 つ以上のノードを削除する際に、削除するノードを選択することはできません。ノードは、後入れ先出し法に基づいてプロビジョニング解除されるため、最後に作成されたノードが最初に削除されます。これは特に、前回の再プロビジョニング操作で 1 つ以上のノードを追加した場合に重要です。最初にプロビジョニングされたノードよりも先にそれらのノードが削除されるためです。

    “LoadBalancer": "true" をノード定義から削除するか、値を false に変更することによって、ロード・バランサを削除することもできます。

再プロビジョニングによる既存の構成の変更には、以下のようないくつかの制限があります。

  • データを格納するノード (DATA、DM、または DS) を削除することはできません。

  • ミラーリングされないものからミラーリングされるもの (またはその逆) へ構成を変更することはできません。

  • DATA、DS、または DM ノードは、関連する MirrorMap の設定と一致する個数でのみ、ミラー構成に追加できます ("ミラーリングの規則" を参照)。例えば、MirrorMap の既定値 primary,backup が有効な場合、DATA および DS ノードは、追加のフェイルオーバー・ペアとして構成されるよう、偶数個 (2 の倍数) でのみ追加できます。MirrorMap が primary,backup,async の場合、DATA または DS ノードは、追加の 3 メンバ・ミラーとして構成されるよう、3 の倍数の個数で追加するか、非同期なしの追加のミラーとして構成されるペアとして追加でき、DM ノードは既存の DM ミラーに現在非同期が含まれない場合のみ追加できます。

  • アービター (AR ノード) をミラー構成に追加できますが、構成内のそれぞれのミラーについて、管理ポータルまたは ^MIRROR ルーチンを使用して、手動でアービターとして構成する必要があります。

既定では、icm provision コマンドを発行して既存のインフラストラクチャを変更する際に、ICM は確認のプロンプトを出します。-force オプションを使用して、スクリプトの使用時などにこのプロンプトを回避できます。

導入済みの構成を再プロビジョニングしたら、icm run コマンドを再度発行して再導入する必要があることに留意してください。

インフラストラクチャ管理コマンド

このセクションに示すコマンドは、ICM を使用してプロビジョニングしたインフラストラクチャの管理に使用されます。

多くの ICM コマンド・オプションは、複数のコマンドで使用できます。例えば、-role オプションは、コマンドを実行するノードのタイプを指定するために、さまざまなコマンドで使用できます。例えば、icm inventory -role AM は、導入環境内のノードのうち、タイプが AM であるもののみをリストします。また、コンテナの導入元のイメージを指定する -image オプションは、icm run コマンドと icm upgrade コマンドの両方で使用できます。ICM コマンドとオプションの完全なリストについては、“ICM リファレンス” の章にある "ICM コマンドとオプション" を参照してください。

icm inventory

icm inventory コマンドは、プロビジョニング出力の最後に、instances.json ファイルの情報に基づいて、プロビジョニングされたノードをリストします (“基本的な ICM の要素” の章の "インスタンス・ファイル" を参照)。次に、例を示します。

$ icm inventory
Machine            IP Address     DNS Name                                           Region    Zone
-------            ----------     --------                                           ------    ----
ANDY-DM-TEST-0001+ 00.53.183.209  ec2-00-53-183-209.us-west-1.compute.amazonaws.com  us-west-1 c
ANDY-DM-TEST-0002- 00.53.183.185  ec2-00-53-183-185.us-west-1.compute.amazonaws.com  us-west-1 c
ANDY-AM-TEST-0003  00.56.59.42    ec2-00-56-59-42.us-west-1.compute.amazonaws.com    us-west-1 c
ANDY-AM-TEST-0005  00.67.1.11     ec2-00-67-1-11.us-west-1.compute.amazonaws.com     us-west-1 c
ANDY-AM-TEST-0003  00.193.117.217 ec2-00-193-117-217.us-west-1.compute.amazonaws.com us-west-1 c
ANDY-LB-TEST-0002  (virtual AM)   ANDY-AM-TEST-1546467861.amazonaws.com              us-west-1 c
ANDY-AR-TEST-0006  00.53.201.194  ec2-00-53-201-194.us-west-1.compute.amazonaws.com  us-west-1 c
Note:

ミラーリングされたノードが構成に含まれている場合、初期のミラー・フェイルオーバーの割り当ては、上の例のように、対象の各プライマリのマシン名の後ろにある + (プラス) と、対象の各バックアップのマシン名の後ろにある - (マイナス) で示されます。ただし、これらの割り当ては変更されることがあります。導入後に、icm ps コマンドを使用して、導入されたノードのミラー・メンバ・ステータスを表示します。

-machine オプションまたは -role オプションを使用して、ノード名別またはロール別にフィルタすることもできます。例えば、前の例で同じクラスタでフィルタした場合、以下のようになります。

$ icm inventory -role AM
Machine           IP Address     DNS Name                                           Region    Zone
-------           ----------     --------                                           ------    ----
ANDY-AM-TEST-0003 00.56.59.42    ec2-00-56-59-42.us-west-1.compute.amazonaws.com    us-west-1 c
ANDY-AM-TEST-0005 00.67.1.11     ec2-00-67-1-11.us-west-1.compute.amazonaws.com     us-west-1 c
ANDY-AM-TEST-0003 00.193.117.217 ec2-00-193-117-217.us-west-1.compute.amazonaws.com us-west-1 c

クラウド・プロバイダから提供された完全修飾 DNS 名の幅が広すぎて読みにくい場合は、Docker の wide 引数を指定して -options オプションを使用すると、出力の幅を広げることができます。以下に例を示します。

icm inventory -options wide

-options オプションの詳細は、"カスタム・コンテナおよびサードパーティ・コンテナでの ICM の使用" を参照してください。

icm ssh

icm ssh コマンドは、指定されたホスト・ノード上で任意のコマンドを実行します。複数のコマンドからの出力を混合すると解釈が難しくなるため、出力はファイルに書き込まれ、出力ファイルのリストが提供されます。例を以下に示します。

$ icm ssh -command "ping -c 5 intersystems.com" -role DM
Executing command 'ping -c 5 intersystems.com' on ANDY-DM-TEST-0001...
Executing command 'ping -c 5 intersystems.com' on ANDY-DM-TEST-0002...
...output in ./state/ANDY-DM-TEST/ANDY-DM-TEST-0001/ssh.out
...output in ./state/ANDY-DM-TEST/ANDY-DM-TEST-0002/ssh.out

ただし、以下に示すように、-machine オプションや -role オプションを使用してノードを 1 つだけ指定した場合、またはノードが 1 つしかない場合は、出力はコンソールにも書き込まれます。

$ icm ssh -command "df -k" -machine ANDY-DM-TEST-0001
Executing command 'df -k' on ANDY-DM-TEST-0001...
...output in ./state/ANDY-DM-TEST/ANDY-DM-TEST-0001/ssh.out 

Filesystem     1K-blocks    Used Available Use% Mounted on
rootfs          10474496 2205468   8269028  22% /
tmpfs            3874116       0   3874116   0% /dev
tmpfs            3874116       0   3874116   0% /sys/fs/cgroup
/dev/xvda2      33542124 3766604  29775520  12% /host
/dev/xvdb       10190100   36888   9612540   1% /irissys/data
/dev/xvdc       10190100   36888   9612540   1% /irissys/wij
/dev/xvdd       10190100   36888   9612540   1% /irissys/journal1
/dev/xvde       10190100   36888   9612540   1% /irissys/journal2
shm                65536     492     65044   1% /dev/shm

また、インタラクティブ・モードで icm ssh コマンドを使用して、長時間実行されるコマンドや、ブロック・コマンド、またはインタラクティブ・コマンドをホスト・ノード上で実行することもできます。単一ノードの導入環境でコマンドを実行する場合を除き、-interactive フラグと一緒に、コマンドを単一のノードに限定する -role オプションまたは -machine オプションを指定する必要があります。-command オプションを使用しない場合は、宛先ユーザの既定シェル (例えば bash) が起動されます。

コマンドをインタラクティブに実行する例については、"icm exec" を参照してください。

Note:

"サービス管理コマンド" で説明されている 2 つのコマンド icm exec (指定されたコンテナに対して任意のコマンドを実行する) と icm session (指定されたノード上で InterSystems IRIS インスタンスのインタラクティブ・セッションを開く) は、icm ssh と組み合わせて、ICM の導入を操作するための強力なツールのセットとして使用できます。ローカル ICM コンテナから指定ノードのホスト OS にファイルまたはディレクトリを安全にコピーする icm scp コマンドは、多くの場合、icm ssh と共に使用します。

icm scp

icm scp コマンドは、ローカル ICM コンテナから指定ノードのローカル・ファイル・システムに、ファイルまたはディレクトリを安全にコピーします。コマンドの構文は以下のとおりです。

icm scp -localPath local-path [-remotePath remote-path]

localPath と remotePath の両方とも、ファイルまたはディレクトリのどちらも指定できます。remotePath がディレクトリの場合は、末尾にスラッシュ (/) を付ける必要があり、そうでなければファイルと見なされます。両方がディレクトリの場合は、ローカル・ディレクトリの内容が再帰的にコピーされます。ディレクトリ自体をコピーする場合は、localPath から先頭のスラッシュ (/) を削除してください。

SSHUser フィールドで指定するユーザは、オプションの remote-path 引数で指定するホスト・ファイル・システムの場所に対して必要な権限を持っている必要があります。remote-path の既定値は、ホスト OS で定義されている $HOME です。

Note:

icm cp コマンドも参照してください。このコマンドは、指定のノードから指定のコンテナに、またはコンテナからローカル・ファイル・システムに、ローカル・ファイルまたはディレクトリをコピーします。

サービスの導入と管理

ICM は、Docker イメージを使用してソフトウェア・サービスの導入を行い、Docker を呼び出すことによってイメージをコンテナとして実行します。イメージを使用してコンテナ化された導入により、操作の容易性と DevOps への適合がサポートされ、手動アップグレードのリスクを回避できます。Docker のほかに、ICM は JDBC 上で InterSystems IRIS 固有の構成も行います。

さまざまなコンテナ管理および調整ツールが利用でき、これらのツールを使用して ICM の導入機能と管理機能を拡張できます。

icm run コマンド

icm run コマンドは、プロビジョニングされたそれぞれのノード上で、指定されたイメージからコンテナをプル、作成、および起動します。既定では、構成ファイルの DockerImage フィールドで指定されたイメージが使用され、導入されるコンテナの名前は iris です。この名前は、以下のインターシステムズのイメージ (またはこれらのイメージに基づくイメージ) から作成されたコンテナ向けに予約済みで、そのコンテナでのみ使用する必要があります。これらのイメージは、"InterSystems Container Registry の使用Opens in a new tab" で説明されているように、InterSystems Container Registry から利用できます。

  • iris — InterSystems IRIS のインスタンスを含みます。

    インターシステムズが配布している InterSystems IRIS イメージと、InterSystems IRIS ベースのアプリケーションを含むカスタム・イメージのベースとしてそれらのイメージを使用する方法については、"InterSystems IRIS コンテナの実行Opens in a new tab" で詳しく説明しています。

    InterSystems IRIS イメージは、ICM によって DATA、COMPUTE、DM、AM、DS、および QS の各ノードとして導入されます。iris イメージを導入する場合、導入する iris コンテナすべてについて 1 つ以上の InterSystems IRIS 構成設定をオーバーライドすることも、それぞれのノード・タイプに導入されるコンテナについて異なる設定をオーバーライドすることもできます。詳細は、"カスタマイズされた InterSystems IRIS 構成を使用した導入" を参照してください。

  • Iris-lockeddown — ロック・ダウン・セキュリティを使用してインストールされた InterSystems IRIS のインスタンスを含みます。このイメージを使用すると、きわめて安全な InterSystems IRIS コンテナを導入することによって最も厳格なセキュリティ要件をサポートできます。このイメージのコンテナと標準の iris イメージのコンテナとの違いは、"InterSystems IRIS ロック・ダウン・コンテナOpens in a new tab" を参照してください。

    Important:

    iris-lockeddown イメージを使用して InterSystems IRIS コンテナを導入する前に、必ずこのイメージのドキュメントを確認してください。

    iris-lockeddown イメージから導入した InterSystems IRIS コンテナでは、プライベート Web サーバが無効になるため、管理ポータルも無効になります。このようなコンテナで管理ポータルを有効にし、このセクションの最後で説明しているように管理ポータルを使用して導入環境に接続できるようにするには、値 1 を指定した webserverOpens in a new tab プロパティ (webserver=1) を、UserCPF プロパティで指定した構成マージ・ファイルに追加します ("カスタマイズされた InterSystems IRIS 構成を使用した導入" を参照してください)。

    Note:

    追加のセキュリティ対策として、コンテナレス・モードでは、InterSystems IRIS の非 root インスタンス、つまり root 特権のないユーザがインストールして所有するインスタンスを ICM からインストールできます。

  • iris-ml — IntergratedML 機能Opens in a new tabを備えた InterSystems IRIS のインスタンスを含みます。IntegratedML は、自動機械学習機能を SQL から直接使用して予測モデルを作成および使用できる InterSystems IRIS の機能です。

  • irishealth、irishealth-lockeddown、irishealth-ml — InterSystems IRIS for HealthOpens in a new tab® のインスタンスを含みます。InterSystems IRIS for Health は、InterSystems IRIS を中心として構築した機能完備の医療向けプラットフォームであり、豊富なデータを扱うミッション・クリティカルな医療向けアプリケーションの迅速な開発および導入を可能にします。ロック・ダウンおよび IntegratedML は、前述のように InterSystems IRIS のオプションです。InterSystems IRIS for Health イメージは、InterSystems IRIS イメージと同様の方法で ICM によって導入されます。

  • webgateway, webgateway-lockeddown, webgateway-nginx — Apache Web サーバまたは Nginx Web サーバと共にインターシステムズの Web ゲートウェイ・インスタンスを含みます。webgateway-lockeddown イメージは、ロック・ダウン InterSystems IRIS イメージに似ています。これらのイメージの詳細は、"コンテナ内でのインターシステムズ製品の実行" の "InterSystems Web ゲートウェイ・コンテナの使用法Opens in a new tab" を参照してください。webgateway イメージは ICM により WS ノードとして導入されます。このノードは、ノードレベルのシャード・クラスタでは DATA ノードの Web サーバまたは DATA ノードと COMPUTE ノードの Web サーバとして構成され、その他の構成では AM ノードまたは DM ノードの Web サーバとして構成されます。

  • arbiter — ミラー・アービターとして動作する ISCAgent インスタンスを含みます。このイメージの使用の詳細は、"InterSystems IRIS コンテナを使用したミラーリングOpens in a new tab" を参照してください。arbiter イメージは AR ノードに導入されます。このノードは、ミラーリングされた導入のアービター・ホストとして構成されます。ミラーリングされた導入とトポロジの詳細は、"ICM クラスタのトポロジ" を参照してください。

  • iam — ICM が CN ノードとして導入する InterSystems API Manager を含みます。詳細は、“ICM リファレンス” の章の "InterSystems API Manager の導入" を参照してください。

  • sam — ICM が SAM ノードとして導入する System Alerting and Monitoring (SAM) クラスタ・モニタリング・ソリューションの SAM マネージャ・コンポーネントを含みます。詳細は、“ICM リファレンス” の章の "ICM でのモニタリング" を参照してください。

Note:

上記リストのイメージのうち、sam を除くすべてのイメージを ARM プラットフォームで利用できます (iris-arm64 など)。

definitions.json ファイルの各ノードの定義に DockerImage フィールドを追加すると、それぞれのノード・タイプで異なる InterSystems IRIS イメージを実行できます。例えば、AR ノードで arbiter イメージを、WS ノードで webgateway イメージを、その他のノードで iris イメージを実行するためにはこれを実行する必要があります。ノード・タイプおよび対応するインターシステムズのイメージのリストについては、“ICM リファレンス” の章にある "ICM ノード・タイプ" を参照してください。

Important:

DockerImage フィールドまたは icm run コマンドの -image オプションでノードについて誤ったインターシステムズのイメージが指定された場合 (例えば、iris イメージが AR (アービター) ノードについて指定された場合や、インターシステムズのいずれかのイメージが CN ノードについて指定された場合)、導入は失敗し、ICM から該当するメッセージが返されます。したがって、defaults.json ファイルの DockerImage フィールドで iris イメージを指定して、definitions.json ファイルに AR 定義または WS 定義を含める場合は、AR 定義または WS 定義に DockerImage フィールドを含めて既定値をオーバーライドし、適切なイメージ (それぞれ arbiter または webgateway) を指定する必要があります。

ICM を起動したイメージと DockerImage フィールドを使用して指定したインターシステムズのイメージのメジャー・バージョンが一致している必要があります。例えば、2022.1 バージョンの ICM イメージを使用して 2022.2 バージョンの InterSystems IRIS イメージを導入することはできません。インターシステムズのコンテナをアップグレードする前に ICM をアップグレードする方法については、付録 “分散管理モードでの導入環境の共有” の "分散管理モードを使用した ICM のアップグレード" を参照してください。

Note:

インターシステムズのコンテナ・イメージは Open Container Initiative (OCIOpens in a new tab) の仕様に準拠しており、Docker Enterprise Edition エンジンを使用して構築されます。このエンジンは、OCI 標準を全面的にサポートしており、これによってイメージは認定Opens in a new tabされ、Docker Hub レジストリで公開することができます。

インターシステムズのイメージは、広く知られたコンテナ向け Ubuntu オペレーティング・システムを使用して構築およびテストされているため、オンプレミスとパブリック・クラウドの両方において、Linux ベースのオペレーティング・システム上の OCI に準拠するすべてのランタイム・エンジンでサポートされます。

コマンド行で InterSystems IRIS コンテナをすばやく実行する方法は、"InterSystems IRIS の基礎 ： InterSystems IRIS コンテナの実行" を参照してください。ICM 以外の方法を使用してコンテナに InterSystems IRIS および InterSystems IRIS ベースのアプリケーションを導入する方法は、"コンテナ内でのインターシステムズ製品の実行Opens in a new tab" を参照してください。

また、icm run で -image と -container のコマンド行オプションを使用して、別のイメージとコンテナ名を指定することもできます。これにより、icm run コマンドを複数回使用して、複数のイメージから作成された複数のコンテナをプロビジョニングされた各ノードに導入することができます。最初は、前の段落で説明したように、ノード定義の DockerImage フィールドで指定されたイメージを実行し、各ノードに iris コンテナ (1 つのみ) を導入します。それ以降は、-image オプションと -container オプションを使用して、すべてまたは一部のノードでカスタム・イメージを実行します。特定のノードで実行されるコンテナには、それぞれ一意の名前が必要です。また、-machine オプションと -role オプションを使用して、コンテナ導入を特定ノードまたは特定タイプのノードに制限することもできます (例えば、プロビジョニングされた特定ノードにユーザ独自カスタム・コンテナを導入する場合)。

もう 1 つのよく使用されるオプション -iscPassword は、導入されるすべての InterSystems IRIS コンテナに対して設定する InterSystems IRIS パスワードを指定します。この値は構成ファイルに含めることもできますが、コマンド行オプションを使用すれば、パスワードを平文のレコードに保管せずに済みます。InterSystems IRIS パスワードがどちらの方法でも指定されない場合は、ICM からパスワードの入力が求められます (入力内容はマスクされます)。

Note:

セキュリティ上の理由から、ICM では InterSystems IRIS パスワード (何らかの方法で指定されたもの) をプレーン・テキストで送信する代わりに、暗号化ハッシュ関数を使用して、ハッシュ化されたパスワードとソルトをローカルで生成し、ホスト・ノードに導入されている InterSystems IRIS コンテナに SSH を使用して送信します。

前述の内容すべてを前提として、icm run コマンドを使用したコンテナの導入について、以下の 3 つの例を考えてみましょう。(これらは完全な手順を示すものではなく、特定のノードに特定のコンテナを導入する作業に関連する手順の要素に限って説明します。)

  • 1 つの DM ノードといくつかの AM ノードを含む分散キャッシュ・クラスタを導入するには、以下の手順で行います。

    1. defaults.json ファイルを作成する際に、"構成ファイル、状態ファイル、およびログ・ファイル" と "導入の定義" で説明されているように、以下の項目を組み込んで iris コンテナの作成に使用する既定のイメージを指定します。

      "DockerImage": "intersystems/iris:2022.2.0.221.0"

    2. ICM コマンド行で以下のコマンドを実行します。

      icm run -iscPassword "<password>"

      指定の初期パスワードが設定された InterSystems IRIS インスタンスを含む iris という名前のコンテナが、それぞれのノードに導入されます。コンテナの導入後、ICM は必要な ECP 構成を実行します。

  • ミラーリングされた DATA ノードと AR (アービター) ノードを含む基本シャード・クラスタを導入するには、以下の手順で行います。

    1. defaults.json ファイルを作成する際に、"構成ファイル、状態ファイル、およびログ・ファイル" と "導入の定義" で説明されているように、以下の項目を組み込んで iris コンテナの作成に使用する既定のイメージを指定し、ミラーリングを有効にします ("ミラーリングの規則" を参照)。

      "DockerImage": "intersystems/iris:2022.2.0.221.0",
"Mirror": "true"

    2. definitions.json ファイルを作成する際に、AR ノード定義で arbiter イメージを指定することによって、AR ノードのみを対象に既定値ファイル内の DockerImage フィールドをオーバーライドします。例を以下に示します。

        {
       "Role": "AR",
       "Count": "1",
       "DockerImage": "intersystems/arbiter:2022.2.0.221.0"
   }

    3. ICM コマンド行で以下のコマンドを実行します。

      icm run -iscPassword "<password>"

      指定の初期パスワードが設定された InterSystems IRIS インスタンスを含む、iris という名前のコンテナがそれぞれの DATA ノードに導入されます。ミラー・アービターとして動作する ISCAgent を含む、iris という名前のコンテナが AR ノードに導入されます。ICM は、必要なシャーディングおよびミラーリング構成をコンテナの導入後に実行します。

  • iris コンテナのスタンドアロン InterSystems Iris インスタンスと追加コンテナ (カスタム・イメージから作成されます) を含む DM ノードといくつかの DM 接続 WS ノードを導入するには、以下の手順で行います。

    1. definitions.json ファイルを作成する際に、"構成ファイル、状態ファイル、およびログ・ファイル" および "導入の定義" で説明されているように、DM ノードに対して iris イメージを指定し、WS ノードに対して webgateway イメージを指定します。以下に例を示します。

        {
       "Role": "DM",
       "Count": "1",
       "DockerImage": "intersystems/iris-arm64:2022.2.0.221.0"
   },
   {
       "Role": "WS",
       "Count": "3",
       "DockerImage": "intersystems/webgateway:2022.2.0.221.0"
   }

    2. ICM コマンド行で以下のコマンドを実行します。

      icm run

      ICM から InterSystems IRIS の初期パスワードの入力が求められ (入力内容はマスクされます)、InterSystems IRIS インスタンスを含む、iris という名前のコンテナが DM ノードに導入されます。また、インターシステムズの Web ゲートウェイのインストールと Apache Web サーバを含む、iris という名前のコンテナが各 WS ノードに導入され、コンテナの導入後に ICM によって必要な Web サーバの構成が実行されます。

    3. 別の icm run コマンドを実行して、カスタム・コンテナを DM ノードに導入します。例えば、以下のいずれかを実行します。

      icm run -container customsensors -image myrepo/sensors:1.0 -role DM

icm run -container customsensors -image myrepo/sensors:1.0 -machine ANDY-DM-TEST-0001

      リポジトリ内のイメージ sensors から作成された customsensors という名前のコンテナが DM ノードに導入されます。

以下の詳細な考慮事項に注意してください。

  • コンテナ名 iris は、すべての ICM コンテナおよびサービス管理コマンドの既定値です (以降のセクションで説明するとおり)。このため、別の名前を使用して導入した追加のコンテナに関連するコマンドを実行する場合は、-container オプションを使用してその名前を明示的に参照する必要があります。例えば、最後に示した例のカスタム・コンテナを DM ノードから削除するには、以下のコマンドを発行します。

    icm rm -container customsensors -machine ANDY-DM-TEST-0001

    -container customsensors を指定しなければ、このコマンドは既定で iris コンテナを削除します。

  • DockerRegistry、DockerUsername、および DockerPassword の各フィールドは、指定したイメージが配置されている Docker レジストリを指定し、ログインする (プライベートの場合) ために必要です。詳細は、"Docker リポジトリ" を参照してください。

  • icm run コマンドで -namespace コマンド行オプションを使用して、既定値ファイルで指定されたネームスペース (既定値ファイルで指定されていない場合は既定値の IRISCLUSTER) をオーバーライドした場合、instances.json ファイル (“基本的な ICM の要素” の章にある "インスタンス・ファイル" を参照) 内の Namespace フィールドの値が、指定した名前で更新され、これが、icm session コマンドおよび icm sql コマンドを使用する際の既定のネームスペースになります。

-options オプションを使用して、--volume など、追加の Docker オプションを icm run コマンド行に指定できます。例を以下に示します。

icm run -options "--volume /shared:/host" image intersystems/iris:2022.2.0.221.0

-options オプションの詳細は、"カスタム・コンテナおよびサードパーティ・コンテナでの ICM の使用" を参照してください。

-command オプションを icm run で使用して、Docker エントリ・ポイントの引数 (またはエントリ・ポイントの代わり) を指定できます。詳細は、"既定のコマンドのオーバーライド" を参照してください。

ICM は複数のスレッドで Docker コマンドを実行するので、コンテナが各ノードに導入される順序は不定です。これを以下の例に示します。この例は、"導入の定義" で説明されているシャード・クラスタ構成の導入からの出力を表しています。繰り返しの行は簡略化のために省いています。

$ icm run
Executing command 'docker login' on ANDY-DATA-TEST-0001...
...output in /Samples/AWS/state/ANDY-DATA-TEST/ANDY-DATA-TEST-0001/docker.out
...
Pulling image intersystems/iris:2022.2.0.221.0 on ANDY-DATA-TEST-0001...
...pulled ANDY-DATA-TEST-0001 image intersystems/iris:2022.2.0.221.0
...
Creating container iris on ANDY-DATA-TEST-0002...
...
Copying license directory /Samples/license/ to ANDY-DATA-TEST-0003...
...
Starting container iris on ANDY-DATA-TEST-0004...
...
Waiting for InterSystems IRIS to start on ANDY-DATA-TEST-0002...
...
Configuring SSL on ANDY-DATA-TEST-0001...
...
Enabling ECP on ANDY-DATA-TEST-0003...
...
Setting System Mode on ANDY-DATA-TEST-0002...
...
Acquiring license on ANDY-DATA-TEST-0002...
...
Enabling shard service on ANDY-DATA-TEST-0001...
...
Assigning shards on ANDY-DATA-TEST-0001...
...
Configuring application server on ANDY-DATA-TEST-0003...
...
Management Portal available at: http://ec2-00-56-140-23.us-west-1.compute.amazonaws.com:52773/csp/sys/UtilHome.csp

実行を完了した ICM は、DM ノード上の iris コンテナで実行中の InterSystems IRIS インスタンスの管理ポータルへのリンクを出力します。また、シャード・クラスタが導入されている場合は、データ・ノード 1Opens in a new tab 上のインスタンスの管理ポータルへのリンクを出力します。このノード 1 は番号が最も小さいノードであり、この場合は ANDY-DATA-TEST-001 になります。この DM ノードまたはシャード・クラスタをミラーリングしている場合、上記のリンクは初期プライマリに対するリンクとなります。ただし、ミラーリングした DM ノードまたは DATA ノードにロード・バランサ (ロール LB) を定義している場合、このリンクはミラー認識ロード・バランサを参照し、必ず現在のプライマリへのリンクとなります。

サービスの再導入

導入プロセスの柔軟性と回復力を可能な限り高めるために、icm run コマンドは完全に再入可能であり、同じ導入環境について複数回発行できます。icm run コマンドが繰り返されると、ICM は、影響を受けるコンテナを停止して削除し (icm stop コマンドと icm rm コマンドに相当)、その後、初期導入パスの一環として作成してマウントした InterSystems IRIS インスタンス固有のデータのストレージ・ボリュームを保持したまま (“ICM リファレンス” の章にある "ICM によってマウントされるストレージ・ボリューム" を参照)、該当するイメージからコンテナを再度作成して起動します。

icm run コマンドを複数回実行してサービスを再導入する主な理由としては、以下の 4 つがあります。

  • 既存のコンテナを既存のストレージ・ボリュームと共に再導入する。

    影響を受ける InterSystems IRIS コンテナのインスタンス固有のストレージ・ボリュームを保持したまま、導入済みのコンテナを新しいバージョンに置き換え、それによって既存のインスタンスを再導入するには、最初にコンテナを導入した元の icm run コマンドを繰り返します。LicenseDir フィールドで指定されたディレクトリ内のライセンスを更新した場合など、再導入を必要とする変更を定義ファイル内で行った場合に、この作業を行うことがあります。

  • InterSystems IRIS コンテナを既存のストレージ・ボリュームなしで再導入する。

    インスタンス固有のストレージ・ボリュームを保持せずに、導入環境内の InterSystems IRIS コンテナを置き換える場合、以下のコマンドを使用して、再導入の前にそれらのインスタンスについてそのデータを削除することができます。

    icm ssh -command "sudo rm -rf /<mount_dir>/*/*"

    mount_dir は、InterSystems IRIS データ・ディレクトリ、WIJ ディレクトリ、およびジャーナル・ディレクトリがマウントされているディレクトリです (既定では /irissys/ です。または DataMountPoint、WIJMountPoint、Journal1MountPoint、および Journal2MountPoint の各フィールドで構成されたディレクトリです。詳細は、“ICM リファレンス” の章にある "ICM によってマウントされるストレージ・ボリューム" を参照してください)。必要に応じて、-role オプションまたは -machine オプションを使用して、このコマンドを特定のノードに限定することもできます。その後、最初に InterSystems IRIS コンテナを導入した icm run コマンドを繰り返すと、インスタンス固有のボリュームを引き続き保持しているものは同じインスタンスとして再導入され、ボリュームを削除したものは新しいインスタンスとして再導入されます。

  • "インフラストラクチャの再プロビジョニング" の説明に従ってインフラストラクチャに追加したノードにサービスを導入する。

    インフラストラクチャにノードを追加した後に icm run コマンドを繰り返すと、既存のノード上のコンテナは前述のように再導入され (ストレージ・ボリュームと共に再導入されるか、削除した場合はストレージ・ボリュームなしで再導入される)、新しいノードには新しいコンテナが導入されます。これにより、必要に応じて、既存のノードを新しい導入トポロジに合わせて再構成することができます。

  • 導入エラーを解決する。

    ネットワークの遅延や切断、クラウド・プロバイダ・サービスの中断など (エラー・ログ・メッセージによって示される)、ICM の制御下にない要因によって 1 つ以上のノードで icm run コマンドが失敗した場合、コマンドを再度発行できます。ほとんどの場合、繰り返し試行することで導入が正常に完了します。どうしてもエラーが解決されず、手動による操作が必要な場合は (いずれかの構成ファイル内のエラーが原因である場合など)、問題を修正した後、icm run を再発行する前に、前述の説明に従って、影響を受けるノードのストレージ・ボリュームを削除しなければならないことがあります。ICM は、インスタンス固有のデータがないノードを新しいノードとして認識し、すべての構成が正常に完了した場合にのみ、InterSystems IRIS コンテナのストレージ・ボリュームを完全に導入されたものとしてマークするためです。構成が開始されたものの正常に完了しておらず、ボリュームがマークされていない場合、ICM はそのノードで再導入を行うことはできません。新しい導入では、-role や -machine の制約を指定せずにコマンド icm ssh -command "sudo rm -rf /irissys/*/*" を発行して、InterSystems IRIS を再導入するノードをすべてロールバックするのが最も簡単な方法である場合があります。

コンテナ管理コマンド

このセクションに示すコマンドは、プロビジョニングしたインフラストラクチャ上で導入したコンテナの管理に使用されます。

多くの ICM コマンド・オプションは、複数のコマンドで使用できます。例えば、-role オプションは、コマンドを実行するノードのタイプを指定するために、さまざまなコマンドで使用できます。例えば、icm inventory -role AM は、導入環境内のノードのうち、タイプが AM であるもののみをリストします。また、コンテナの導入元のイメージを指定する -image オプションは、icm run コマンドと icm upgrade コマンドの両方で使用できます。ICM コマンドとオプションの完全なリストについては、“ICM リファレンス” の章にある "ICM コマンドとオプション" を参照してください。

icm ps

導入の完了時に、icm ps コマンドはノード上で実行されているコンテナの実行状態を表示します。例を以下に示します。

$ icm ps -container iris
Machine             IP Address    Container Status Health  Image
-------             ----------    --------- ------ ------  -----
ANDY-DATA-TEST-0001 00.56.140.23  iris      Up     healthy intersystems/iris:2022.2.0.221.0
ANDY-DATA-TEST-0002 00.53.190.37  iris      Up     healthy intersystems/iris:2022.2.0.221.0
ANDY-DATA-TEST-0003 00.67.116.202 iris      Up     healthy intersystems/iris:2022.2.0.221.0
ANDY-DATA-TEST-0004 00.153.49.109 iris      Up     healthy intersystems/iris:2022.2.0.221.0

-container の制約を省略すると、ノード上で実行中のすべてのコンテナがリストされます。これには、ICM によって導入された他のコンテナ (例えば、Weave ネットワーク・コンテナや、icm run コマンドを使用して導入したカスタム・コンテナまたはサードパーティ・コンテナなど) と、ICM の導入完了後にその他の方法で導入したあらゆるコンテナの両方が含まれます。

ノード名、IP アドレス、コンテナ名、およびコンテナの作成元のイメージのほか、icm ps コマンドには、以下の列が含まれています。

  • Status — Docker によって生成されるステータス値の 1 つ ： created、restarting、running、removing (または up)、paused、exited、または dead。

  • Health — iris コンテナ、arbiter コンテナ、および webgateway コンテナの場合、starting、healthy、または unhealthy のいずれかの値。その他のコンテナの場合は none (または空白)。 Status が exited の場合、Health にその終了値が表示される場合があります (0 は成功を意味します)。

    iris コンテナの場合、Health の値にはコンテナ内の InterSystems IRIS インスタンスのヘルス状態が反映されます(InterSystems IRIS のヘルス状態の詳細は、"監視ガイド" の "システム・モニタの使用" の章にある "システム・モニタのヘルス状態Opens in a new tab" を参照してください)。arbiter コンテナの場合は、ISCAgent のステータスが、webgateway コンテナの場合は、インターシステムズの Web ゲートウェイの Web サーバのステータスが反映されます。unhealthy は一時的な可能性があることに留意してください。これはその後クリアされる警告に起因している場合があるからです。

  • Mirror — ミラーリングが有効になっている場合 ("ミラーリングの規則" を参照)、ミラー・メンバのステータス (PRIMARY、BACKUP、SYNCHRONIZING など) が、%SYSTEM.Mirror.GetMemberStatus()Opens in a new tab ミラーリング API 呼び出しによって返されます。次に、例を示します。

    $ icm ps -container iris
Machine             IP Address    Container Status Health  Mirror  Image
-------             ----------    --------- ------ ------  ------  -----
ANDY-DATA-TEST-0001 00.56.140.23  iris      Up     healthy PRIMARY intersystems/iris:2022.2.0.221.0
ANDY-DATA-TEST-0002 00.53.190.37  iris      Up     healthy BACKUP  intersystems/iris:2022.2.0.221.0
ANDY-DATA-TEST-0003 00.67.116.202 iris      Up     healthy PRIMARY intersystems/iris:2022.2.0.221.0
ANDY-DATA-TEST-0004 00.153.49.109 iris      Up     healthy BACKUP  intersystems/iris:2022.2.0.221.0

    各ステータスが意味することの説明は、"高可用性ガイド" の “ミラーリング” の章の "ミラー・メンバのジャーナル転送およびデジャーナリングのステータスOpens in a new tab" を参照してください。

以下には、その他の導入および管理フェーズのコマンドがリストされています。これらのコマンドの詳細は、"ICM リファレンス" を参照してください。

icm stop

icm stop コマンドは、指定コンテナ (または、既定値の iris) を指定ノード (また、マシンまたはロールの制約が指定されない場合、すべてのノード) で停止します。例えば、分散キャッシュ・クラスタ構成内のアプリケーション・サーバ上で InterSystems IRIS コンテナを停止するには、以下のように入力します。


$ icm stop -container iris -role DS

Stopping container iris on ANDY-DATA-TEST-0001...
Stopping container iris on ANDY-DATA-TEST-0002...
Stopping container iris on ANDY-DATA-TEST-0004...
Stopping container iris on ANDY-DATA-TEST-0003...
...completed stop of container iris on ANDY-DATA-TEST-0004
...completed stop of container iris on ANDY-DATA-TEST-0001
...completed stop of container iris on ANDY-DATA-TEST-0002
...completed stop of container iris on ANDY-DATA-TEST-0003

icm start

icm start コマンドは、指定コンテナ (または、既定値の iris) を指定ノード (また、マシンまたはロールの制約が指定されない場合、すべてのノード) で起動します。例えば、停止したアプリケーション・サーバ InterSystems IRIS コンテナの 1 つを再起動するには、以下のように入力します。

$ icm start -container iris -machine ANDY-DATA-TEST-0002...
Starting container iris on ANDY-DATA-TEST-0002...
...completed start of container iris on ANDY-DATA-0002

icm pull

icm pull コマンドは、指定イメージを指定マシンにダウンロードします。例えば、シャード・クラスタ内のデータ・ノード 1 にイメージを追加するには、以下のように入力します。

$ icm pull -image intersystems/webgateway:2022.2.0.221.0 -role DATA
Pulling ANDY-DATA-TEST-0001 image intersystems/webgateway:2022.2.0.221.0...
...pulled ANDY-DATA-TEST-0001 image intersystems/webgateway:2022.2.0.221.0

プルするイメージが、定義ファイルの DockerImage フィールドで指定されたものであれば、-image オプションは必要ないことに注意してください。例を以下に示します。

"DockerImage": "intersystems/iris-arm64:2022.2.0.221.0",

icm run コマンドは、ホストにまだ存在しないイメージを自動的にプルしますが、テストやステージングなどの目的には明示的に icm pull を指定する必要が生じることがあります。

icm rm

icm rm コマンドは、指定されたノードから、またはすべてのノードから (マシンまたはロールが指定されていない場合)、指定されたコンテナ (または既定値の iris) を削除します。ただし、起動された元のイメージは削除しません。停止しているコンテナのみを削除できます。

icm upgrade

icm upgrade コマンドは、指定マシンで指定コンテナを置き換えます。ICM は、以下のイベントのシーケンスを調整して、アップグレードを実行します。

  1. 新規イメージをプルする

  2. 新規コンテナを作成する

  3. 既存のコンテナを停止する

  4. 既存のコンテナを削除する

  5. 新規コンテナを起動する

ステップ 1 と 2 で新規イメージのステージングを行うことにより、ステップ 3 から 5 の間に必要なダウンタイムが比較的短時間に抑えられます。

例えば、アプリケーション・サーバ上の InterSystems IRIS コンテナをアップグレードするには、以下のように入力します。

$ icm upgrade -image intersystems/iris:2022.2.0.221.0 -machine ANDY-AM-TEST-0003
Pulling ANDY-AM-TEST-0003 image intersystems/iris:2022.2.0.221.0...
...pulled ANDY-AM-TEST-0003 image intersystems/iris:2022.2.0.221.0
Stopping container ANDY-AM-TEST-0003...
...completed stop of container ANDY-AM-TEST-0003
Removing container ANDY-AM-TEST-0003...
...removed container ANDY-AM-TEST-0003
Running image intersystems/iris:2022.2.0.221.0 in container ANDY-AM-TEST-0003...
...running image intersystems/iris:2022.2.0.221.0 in container ANDY-AM-TEST-0003

icm upgrade コマンドには -image オプションは任意です。イメージを指定しないと、ICM では instances.json ファイルの DockerImage フィールドの値が使用されます ("“基本的な ICM の要素”" の "インスタンス・ファイル" の章を参照してください)。イメージを指定すると、アップグレードの完了時に、その値が指定のイメージで更新されます。

Note:

ICM の起動元のイメージと導入するインターシステムズのイメージのメジャー・バージョンが一致している必要があります。例えば、2022.1 バージョンの ICM を使用して 2022.2 バージョンの InterSystems IRIS を導入することはできません。そのため、インターシステムズのコンテナをアップグレードする前に ICM をアップグレードする必要があります。

iris 以外のコンテナをアップグレードする場合は、-container オプションを使用してコンテナ名を指定する必要があります。

InterSystems IRIS コンテナのアップグレードに関する重要な情報については、"コンテナ内でのインターシステムズ製品の実行" の "InterSystems IRIS コンテナのアップグレードOpens in a new tab" を参照してください。

ICM 全体に言えることですが、icm upgrade コマンドはスクリプト作成に使用されることを意図しているので、さまざまなアップグレードのタイプに応じてスクリプト化した異なる手順を作成できます。スクリプト化しておけば、その手順を毎回手動で繰り返す必要がありません。例えば、インストール・ガイドの "ミラーのアップグレードOpens in a new tab" にあるように、ミラーのメンバのアップグレードは、固有の手順を使用して固有の順序で実行する必要があります。icm upgrade コマンドによるスクリプト作成は、この作業に効果的です。例えば、以下のような基本的手順のいくつかを組み込んだプロシージャを作成できます。

  1. icm ps コマンドを使用して、ミラーリングしたシャード・クラスタで現在のプライマリ・フェイルオーバー・メンバを特定します。

    $ icm ps -container iris
Machine IP Address Container Status Health Mirror Image
------- ---------- --------- ------ ------ ------ -----
Andy-DATA-TEST-0001  35.229.124.197 iris Up healthy PRIMARY intersystems/iris:2022.1.0.205.0
Andy-DATA-TEST-0002  34.138.234.124 iris Up healthy BACKUP  intersystems/iris:2022.1.0.205.0
Andy-DATA-TEST-0003  34.139.3.48    iris Up healthy PRIMARY intersystems/iris:2022.1.0.205.0
Andy-DATA-TEST-0004  34.73.107.58   iris Up healthy BACKUP  intersystems/iris:2022.1.0.205.0

  2. icm upgrade で -machine オプションを使用して、最初にアップグレードするバックアップを選択してアップグレードします。

    icm upgrade -machine ".*(2|4)" -image intersystems/iris:2022.1.0.223.0

  3. icm upgrade -machine を使用してプライマリをアップグレードし、以前にアップグレードしたバックアップにミラーがフェイルオーバーされるようにして、ミラーのアップグレードを完了します。

    icm upgrade -machine ".*(1|3)" -image intersystems/iris:2022.1.0.223.0

サービス管理コマンド

これらのコマンドを使用して、導入されたコンテナ内で実行されている InterSystems IRIS などのサービスとやり取りできます。

多くの ICM コマンド・オプションは、複数のコマンドで使用できます。例えば、-role オプションをさまざまなコマンドで使用して、コマンドを実行するノードのタイプを指定できます。例えば、icm exec -role AM では、導入環境にあるノードのうち、タイプが AM であるもののみで指定のコマンドを実行します。また、コンテナの導入元のイメージを指定する -image オプションは、icm run コマンドと icm upgrade コマンドの両方で使用できます。ICM コマンドとオプションの完全なリストについては、“ICM リファレンス” の章にある "ICM コマンドとオプション" を参照してください。

ICM の重要な機能は、導入環境のノードと複数のレベルでやり取りできることです (ノード自体、ノードに導入されたコンテナ、およびコンテナ内で実行中の InterSystems IRIS インスタンス)。icm ssh ("インフラストラクチャ管理コマンド" を参照) を使用して、指定されたホスト・ノード上でコマンドを実行できます。このコマンドを、このセクションで先に説明した 2 つのコマンド icm exec (指定されたコンテナ内でコマンドを実行する) および icm session (指定されたノード上で InterSystems IRIS インスタンスのインタラクティブ・セッションを開く) と組み合わせて、ICM の導入を操作するための強力なツールのセットとして使用できます。以下の図に、この複数レベルでのやり取りを示します。

インタラクティブ ICM コマンド
null

icm exec

icm exec コマンドは、指定されたコンテナ内で任意のコマンドを実行します。例を以下に示します。


$ icm exec -command "df -k" -machine ANDY-DM-TEST-0001
Executing command in container iris on ANDY-DM-TEST-0001
...output in ./state/ANDY-DM-TEST/ANDY-DM-TEST-0001/docker.out

Filesystem     1K-blocks    Used Available Use% Mounted on
rootfs          10474496 2205468   8269028  22% /
tmpfs            3874116       0   3874116   0% /dev
tmpfs            3874116       0   3874116   0% /sys/fs/cgroup
/dev/xvda2      33542124 3766604  29775520  12% /host
/dev/xvdb       10190100   36888   9612540   1% /irissys/data
/dev/xvdc       10190100   36888   9612540   1% /irissys/wij
/dev/xvdd       10190100   36888   9612540   1% /irissys/journal1
/dev/xvde       10190100   36888   9612540   1% /irissys/journal2
shm                65536     492     65044   1% /dev/shm

複数のコマンドからの出力を混合すると解釈が難しくなるため、複数のノード上でコマンドが実行される場合、出力はファイルに書き込まれ、出力ファイルのリストが提供されます。

--env など、その他の Docker オプションは、-options オプションを使用して icm exec コマンド行に指定できます。詳細は、"カスタム・コンテナおよびサードパーティ・コンテナでの ICM の使用" を参照してください。

長時間実行されるコマンド、ブロック・コマンド、またはインタラクティブ・コマンドをコンテナ内で実行することで、ICM がコマンドの完了またはユーザ入力の待機中にタイムアウトする場合があるため、icm exec コマンドをインタラクティブ・モードで使用することもできます。単一ノードの導入環境でコマンドを実行する場合を除き、-interactive フラグと一緒に、コマンドを単一のノードに限定する -role オプションまたは -machine オプションを指定する必要があります。分かりやすい例として、コンテナ内でシェルを実行する場合を以下に示します。

$ icm exec -command bash -machine ANDY-AM-TEST-0004 -interactive
Executing command 'bash' in container iris on ANDY-AM-TEST-0004...
[root@localhost /] $ whoami
root
[root@localhost /] $ hostname
iris-ANDY-AM-TEST-0004
[root@localhost /] $ exit

コンテナ内でインタラクティブに実行されるコマンドのもう 1 つの例が、iris stop などの、ユーザ入力を求める InterSystems IRIS コマンドです。このコマンドは、InterSystems IRIS インスタンスをシャットダウンする前に、メッセージを送信するかどうかを尋ねます。

icm cp コマンドは、指定されたノード上のローカル・ファイルまたはディレクトリを指定されたコンテナにコピーするもので、icm exec で役立ちます。

icm session

-interactive オプションと共に使用すると、icm session コマンドは、指定されたノード上で InterSystems IRIS インスタンスのインタラクティブ・セッションを開きます。-namespace オプションを使用すると、セッションを開始するネームスペースを指定できます。既定値は、ICM によって作成されるネームスペース (既定では IRISCLUSTER) です。以下に例を示します。

$ icm session -interactive -machine ANDY-AM-TEST-0003 -namespace %SYS

Node: iris-ANDY-AM-TEST-0003, Instance: IRIS

%SYS>

-command オプションを使用して、InterSystems IRIS セッションで実行するルーチンを指定することもできます。以下に例を示します。

icm session -interactive -machine ANDY-AM-TEST-0003 -namespace %SYS -command ^MIRROR

--env など、その他の Docker オプションは、-options オプションを使用して icm exec コマンド行に指定できます。詳細は、"カスタム・コンテナおよびサードパーティ・コンテナでの ICM の使用" を参照してください。

-interactive オプションを使用しない場合、icm session コマンドは、指定されたノード上で、-command オプションで指定された InterSystems IRIS ObjectScriptScript スニペットを実行します。-namespace オプションを使用して、スニペットを実行するネームスペースを指定できます。複数のコマンドからの出力を混合すると解釈が難しくなるため、複数のノード上でコマンドが実行される場合、出力はファイルに書き込まれ、出力ファイルのリストが提供されます。以下に例を示します。

$ icm session -command 'Write ##class(%File).Exists("test.txt")' -role AM
Executing command in container iris on ANDY-AM-TEST-0003...
Executing command in container iris on ANDY-AM-TEST-0004...
Executing command in container iris on ANDY-AM-TEST-0005...
...output in ./state/ANDY-AM-TEST/ANDY-AM-TEST-0003/ssh.out
...output in ./state/ANDY-AM-TEST/ANDY-AM-TEST-0004/ssh.out
...output in ./state/ANDY-AM-TEST/ANDY-AM-TEST-0005/ssh.out

指定された -machine オプションまたは -role オプションによってコマンドが 1 つのノードに限定される場合、出力はコンソールにも書き込まれます。以下に例を示します。

$ icm session -command 'Write ##class(%File).Exists("test.txt")' -role DM
Executing command in container iris on ANDY-DM-TEST-0001
...output in ./state/ANDY-DM-TEST/ANDY-DM-TEST-0001/docker.out

0

icm sql コマンドは、指定されたノード (またはすべてのノード) 上のコンテナ化された InterSystems IRIS インスタンスに対して任意の SQL コマンドを実行するもので、icm session と似ています。

icm cp

icm cp コマンドは、指定されたノード上のローカル・ファイル・システムから指定されたコンテナにファイルまたはディレクトリをコピーします。また、-options --retrieve が指定されている場合は、コンテナからローカル・ファイル・システムにファイルまたはディレクトリをコピーします。

既定では、このコンテナは iris コンテナで、コピーはすべてのノードで実行されます。-container オプションを使用して別のコンテナを指定できます。また、-role オプションまたは -machine オプションを使用して、コピーの実行場所とするノードを指定できます。例えば、分散キャッシュ・クラスタにあるデータ・サーバ上でのみコピーを実行するには -role DM を指定します。iris コンテナではなく、導入したカスタム・コンテナとの間でコピーを実行するには -container container-name を指定します。

コマンドの基本的な構文は以下のとおりです。

icm cp -localPath local-path [-remotePath remote-path] [-options --retrieve]

-options --retrieve を指定すると、remote-path (コンテナでの絶対パス) から local-path (ローカル・ファイル・システム上の絶対パス) にファイルやディレクトリがコピーされます。省略すると、local-path から remote-path にコピーされます。localPath と remotePath の両方とも、ファイルまたはディレクトリのどちらも指定できます。両方がディレクトリの場合は、コピー元ディレクトリの内容が再帰的にコピーされます。ディレクトリ自体をコピーする場合は、それをコピー先のパスで指定します。remotePath 引数はオプションで、省略した場合は既定値の /tmp に設定されます。remotePath がディレクトリの場合は、末尾にスラッシュ (/) を付ける必要があり、そうでなければファイルと見なされます。

Note:

icm scp コマンドも参照してください。このコマンドは、ローカル ICM コンテナから指定ホスト OS にファイルまたはディレクトリを安全にコピーします。

ICM コマンド行に Docker 引数を指定できるようにする -options オプションの詳細は、"カスタム・コンテナおよびサードパーティ・コンテナでの ICM の使用" を参照してください。

icm sql

icm sql コマンドは、指定されたノード (またはすべてのノード) 上のコンテナ化された InterSystems IRIS インスタンスに対して、任意の SQL コマンドを実行します。例を以下に示します。

$ icm sql -command "SELECT Name,SMSGateway FROM %SYS.PhoneProviders" -role DM
Executing command in container iris on ANDY-DM-TEST-0001...
...output in ./state/ANDY-DM-TEST/ANDY-DM-TEST-0001/jdbc.out

Name,SMSGateway
AT&amp;T Wireless,txt.att.net
Alltel,message.alltel.com
Cellular One,mobile.celloneusa.com
Nextel,messaging.nextel.com
Sprint PCS,messaging.sprintpcs.com
T-Mobile,tmomail.net
Verizon,vtext.com

-namespace オプションを使用すると、SQL コマンドを実行するネームスペースを指定できます。既定値は、ICM によって作成されるネームスペース (既定では IRISCLUSTER) です。

複数のコマンドからの出力を混合すると解釈が難しくなるため、複数のノード上でコマンドが実行される場合、出力はファイルに書き込まれ、出力ファイルのリストが提供されます。

icm sql コマンドを単一のノード上でインタラクティブに実行して、InterSystems IRIS SQL シェルを開くこともできます ("InterSystems SQL の使用法" の “SQL シェル・インタフェースの使用法Opens in a new tab” の章を参照してください)。単一ノードの導入環境でコマンドを実行する場合を除き、-interactive フラグと一緒に、コマンドを単一のノードに限定する -role オプションまたは -machine オプションを指定する必要があります。次に、例を示します。

$ icm sql -interactive -machine ANDY-QS-TEST-0002
SQL Command Line Shell
----------------------------------------------------
The command prefix is currently set to: <<nothing>>.
Enter <command>, 'q' to quit, '?' for help.

非インタラクティブ・コマンドと同様に、-namespace オプションをインタラクティブに使用して、SQL シェルを実行するネームスペースを指定できます。既定値は、ICM によって作成されるネームスペース (既定では IRISCLUSTER) です。

LB ノード (ロード・バランサ) のターゲット・プールが InterSystems IRIS ノード (DATA、COMPUTE、DM、または AM) で構成されている場合、-role オプションを使用して、SQL 呼び出しをその LB ノードに転送できます。以下に例を示します。

$ icm sql -role LB -command "SELECT * FROM TABLE1"

icm docker

icm docker コマンドは、指定されたノード (またはすべてのノード) 上で Docker コマンドを実行します。例を以下に示します。

$ icm docker -command "status --no-stream" -machine ANDY-DM-TEST-0002
Executing command 'status --no-stream' on ANDY-DM-TEST-0002...
...output in ./state/ANDY-DM-TEST/ANDY-DM-TEST-0002/docker.out

CONTAINER     CPU %  MEM USAGE / LIMIT  MEM %  NET I/O     BLOCK I/O        PIDS
3e94c3b20340  0.01%  606.9MiB/7.389GiB  8.02%  5.6B/3.5kB  464.5MB/21.79MB  0
1952342e3b6b  0.10%  22.17MiB/7.389GiB  0.29%  0B/0B       13.72MB/0B       0
d3bb3f9a756c  0.10%  40.54MiB/7.389GiB  0.54%  0B/0B       38.43MB/0B       0
46b263cb3799  0.14%  56.61MiB/7.389GiB  0.75%  0B/0B       19.32MB/231.9kB  0

Docker コマンドは長時間実行 (またはブロック) するものであってはなりません。これに従わなければ、ICM に制御が返されません。例えば、例の中で ---no-stream オプションを削除すると、タイムアウト期限が切れるまで呼び出しは戻りません。

インフラストラクチャのプロビジョニング解除

パブリック・クラウド・プラットフォームのインスタンスは継続的に課金され、プライベート・クラウド内で使用されていないインスタンスはリソースを無駄に消費するので、適切な時期にインフラストラクチャのプロビジョニングを解除することは重要です。

icm unprovision コマンドは、プロビジョニング時に作成された状態ファイルに基づいて、プロビジョニングされたインフラストラクチャの割り振りを解除します。state サブディレクトリが現在の作業ディレクトリ内にない場合は、その場所を指定するために -stateDir オプションが必要です。"インフラストラクチャのプロビジョニング" で説明されているように、destroy は、インフラストラクチャの割り振りを解除する Terraform のフェーズを指します。そのタイプのノードがいくつプロビジョニングされたかに関係なく、定義ファイル内のエントリごとに 1 行が作成されます。ICM は複数のスレッドで Terraform を実行するので、マシンのプロビジョニングが解除される順序は不定です。

$ icm unprovision -cleanUp
Type "yes" to confirm: yes
Starting destroy of ANDY-DM-TEST...
Starting destroy of ANDY-AM-TEST...
Starting destroy of ANDY-AR-TEST...
...completed destroy of ANDY-AR-TEST
...completed destroy of ANDY-AM-TEST
...completed destroy of ANDY-DM-TEST
Starting destroy of ANDY-TEST...
...completed destroy of ANDY-TEST

-cleanUp オプションは、プロビジョニング解除の後に状態ディレクトリを削除します。既定では、状態ディレクトリは保存されます。既定では、icm unprovision コマンドは、プロビジョニング解除を確認するプロンプトを出します。-force オプションを使用して、スクリプトの使用時などにこのプロンプトを回避できます。

Next sectionICM リファレンス
Previous section基本的な ICM の要素
FeedbackOpens in a new tab