機能紹介 ： InterSystems Cloud Manager

Docker のインストール

ICM は、必要なものをすべて含むコンテナ・イメージとして提供されます。そのため、ICM を起動する Linux、macOS、または Microsoft Windows システムの要件は、Docker がインストールされ、Docker デーモンが実行されており、システムがインターネットに接続されていることだけです。Docker をプラットフォームにインストールする手順の詳細は、Docker のドキュメントの "Docker のインストールOpens in a new tab" を参照してください。

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

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

ICM の起動

コマンド行で ICM を起動するには、以下の docker run コマンドを使用してレジストリから ICM イメージをプル (ダウンロード) し、そのイメージからコンテナを作成して、そのコンテナを起動します。

docker run --name icm -it --cap-add SYS_TIME 
  containers.intersystems.com/intersystems/icm:2021.1.0.205.0

ICM コンテナ内の /Samples ディレクトリは、プロバイダ (/AWS、/GCP など) ごとに提供されており、ICM をそのまますぐに使用してプロビジョニングと導入を簡単に実行できるようになっています。これらのディレクトリのいずれかにあるサンプル構成ファイルを使用して、そのディレクトリからプロビジョニングおよび導入を実行することもできます。ただし、これらのディレクトリは ICM コンテナ内にあるため、コンテナが削除されるとその中のデータも失われます。こういったデータには、構成ファイルおよび ICM で作成されプロビジョニング済みインフラストラクチャの管理に使用される状態ディレクトリも含まれます。プロダクションでは、ベスト・プラクティスとして、ICM の起動時に外部ボリュームをマウントして、このデータの格納にコンテナ外部の場所を使用することをお勧めします (Docker ドキュメントの "Manage data in DockerOpens in a new tab" を参照してください)。

クラウド・プロバイダのアカウントおよび資格情報の入手

ICM は、Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、および Tencent Cloud (Tencent) の 4 つのパブリック・クラウド・プラットフォームでプロビジョニングおよび導入を行うことができます。

AWS、GCP、Azure、または Tencent のアカウントにログインします。まだアカウントを持っておらず、勤務先にもアカウントがない場合は、AWSOpens in a new tab、GCPOpens in a new tab、AzureOpens in a new tab、または TencentOpens in a new tab のポータル・ページに移動して、すばやく無料アカウントを作成できます。

各クラウド・プロバイダに対する認証で ICM が必要とするアカウント資格情報の取得の詳細は、"InterSystems Cloud Manager ガイド" の “ICM リファレンス” の章にある "セキュリティ関連のパラメータOpens in a new tab" を参照してください。

セキュリティ・キーの生成

ICM は、インフラストラクチャをプロビジョニングする対象のクラウド・プロバイダ、プロビジョニングされたノード上の Docker、およびコンテナの導入後はいくつかの InterSystems IRIS サービスとの間で、セキュリティ保護された通信を行います。既にクラウドの認証情報をダウンロードまたは確認しましたが、セキュリティ保護された SSH および TLS 通信を有効にするには、他のファイルも必要です。

ICM に付属している 2 つのスクリプトを使用して、必要なファイルを作成できます。keygenSSH.sh スクリプトは必要な SSH ファイルを作成し、ICM コンテナ内のディレクトリ /Samples/ssh に配置します。keygenTLS.sh スクリプトは必要な TLS ファイルを作成し、/Samples/tls に配置します。

ICM コマンド行でこれらのスクリプトを実行するには、以下のように入力します。

# keygenSSH.sh
Generating keys for SSH authentication.
...
# keygenTLS.sh
Generating keys for TLS authentication.
...

これらのスクリプトによって生成されるファイルの詳細は、"InterSystems Cloud Manager ガイド" の "セキュリティ関連ファイルの入手Opens in a new tab"、"ICM セキュリティOpens in a new tab"、および "セキュリティ関連のパラメータOpens in a new tab" を参照してください。

サンプル構成ファイルのカスタマイズ

ICM を使用して導入する構成を定義するには、必要な設定を JSON 形式の 2 つの構成ファイル (既定値ファイルと定義ファイル) に追加します。前者 (defaults.json) には、選択したクラウド・プロバイダなど、導入環境全体に適用される設定が含まれます。後者 (definitions.json) では、必要なノードのタイプおよびそれぞれのノードの数を定義し、シャード・クラスタ、単一のスタンドアロン InterSystems IRIS インスタンス、その他の構成のいずれを導入するのかを指定します。

ICM コンテナ内の /Samples ディレクトリには、4 つのクラウド・プロバイダすべてのサンプル構成ファイルが用意されています。例えば、AWS 用のサンプル構成ファイルは、/Samples/AWS ディレクトリにあります。これらのファイルをカスタマイズするには、使用するプロバイダを選択し、以下のテーブルで説明しているように、そのプロバイダ用のサンプルの既定値ファイルおよび定義ファイルを変更します。これを行うには、vi などのエディタを使用してコンテナ内で直接編集するか、以下のように、ローカルのコマンド行で docker cp コマンドを使用してコンテナからローカル・ファイル・システムにそれらをコピーし、編集した後で再びコンテナに戻します。

docker cp icm:/Samples/AWS/defaults.json .
docker cp icm:/Samples/AWS/definitions.json .
...
docker cp defaults.json icm:/Samples/AWS
docker cp definitions.json icm:/Samples/AWS

defaults.json のカスタマイズ

/Samples で提供されている既定値ファイルに必要な最小限のカスタマイズと、オプションの変更に関する推奨事項を以下のテーブルに示します。ここで取り上げられていない設定は、サンプル・ファイルでそのままにしておくことができます。

各設定が、"InterSystems Cloud Manager ガイド" の “ICM リファレンス” の章にある "ICM の構成パラメータOpens in a new tab" のセクションの関連するテーブルにリンクされており、詳細を確認できます。このセクションでは目的のパラメータを検索してください。一番右の列には、各パラメータまたはパラメータ・セットがサンプルの既定値ファイルに出現するとおりに示されています。

すべてのプロバイダに共通の設定をすべて確認するには、そのセクションの "一般パラメータOpens in a new tab" を参照してください。特定のプロバイダに固有の設定をすべて確認するには、"プロバイダ固有のパラメータOpens in a new tab" を参照してください。

設定	説明	サンプルの defaults.json ファイルでのエントリ
ProviderOpens in a new tab	クラウド・インフラストラクチャ・プロバイダを特定します。サンプルの defaults.json の値のままにします。	“Provider”:[”AWS”|"GCP"|"Azure"|"Tencent"],
LabelOpens in a new tab	プロビジョニングされるノードの名前付け方式 Label-Role-Tag-NNNN のフィールド (以下の Role を参照)。導入の所有者および目的を指定するように更新します。例えば、会社名と “TEST” を使用して Acme-DATA-TEST-0001 のようなノード名を作成します。	"Label": "Sample",
TagOpens in a new tab	(上記の Label 参照)	"Tag": "TEST",
DataVolumeSizeOpens in a new tab	各ノードと共にプロビジョニングする永続データ・ボリュームのサイズ。これは、definitions.json ファイル内の個々のノード定義でオーバーライドできます。Tencent でのプロビジョニングを除き、サンプルの defaults.json の値を受け入れます (Tencent を使用する場合は 60 に変更します)。	"DataVolumeSize": "10",
SSHUserOpens in a new tab	プロビジョニングされたノードに対する sudo アクセス権を持つ非 root アカウント。ICM でアクセスのために使用されます。サンプルの defaults.json の既定値のままにできますが、AWS または Tencent でマシン・イメージ (以下を参照) を変更する場合は、このエントリの更新が必要なことがあります。	"SSHUser": "ubuntu", (AWS & Tencent) "SSHUser": "sample", (GCP & Azure)
SSHPublicKeyOpens in a new tab	SSH 公開鍵の場所。"セキュリティ・キーの生成" で説明したキー生成スクリプトを使用した場合、キーはサンプル・ファイルに指定されているディレクトリにあります。このため、変更は不要です。独自のキーを指定している場合は、docker cp を使用して、そのキーをローカル・ファイル・システムからこれらの場所にコピーします。	"SSHPublicKey": "/Samples/ssh/insecure-ssh2.pub",
SSHPrivateKeyOpens in a new tab	SSH 秘密鍵の場所。上記の "SSHPublicKey" を参照してください。	"SSHPrivateKey": "/Samples/ssh/insecure",
TLSKeyDirOpens in a new tab	TILS ファイルの場所。上記の "SSHPublicKey" を参照してください。	"TLSKeyDir": "/Samples/tls/",
DockerVersionOpens in a new tab	プロビジョニングされるノードにインストールされる Docker バージョン。既定値のままにしてください。	"DockerVersion": "5:19.03.8~3-0~ubuntu-bionic",
DockerImageOpens in a new tab	プロビジョニングされるノードに導入されるイメージ。"Docker のリポジトリと資格情報の識別" で識別したリポジトリとイメージの情報を反映するよう更新します。	"DockerImage": "containers.intersystems.con/intersystems/iris:2021.1.0.205.0",
DockerUsernameOpens in a new tab DockerPasswordOpens in a new tab	プライベート・リポジトリにある場合は DockerImage によって指定されるイメージをダウンロードするのに必要な資格情報。"Docker のリポジトリと資格情報の識別" で識別したリポジトリの情報と資格情報を反映するよう更新します。	"DockerUsername": "xxxxxxxxxxxx", "DockerPassword": "xxxxxxxxxxxx",
LicenseDirOpens in a new tab	InterSystems IRIS ライセンスのステージング・ディレクトリ。このディレクトリに、コンテナ固有の InterSystems IRIS シャード・ライセンスを配置します。	"LicenseDir": "/Samples/Licenses",
RegionOpens in a new tab, LocationOpens in a new tab (Azure)	インフラストラクチャのプロビジョニングが行われる、プロバイダの計算リソースの地理的地域。サンプルの defaults.json の既定値を受け入れるか、プロバイダ提供のリージョンとゾーン (以下を参照) の別の組み合わせを選択します。	"Region": "us-west-1", (AWS) "Region": "us-east1", (GCP) "Location": "Central US", (Azure) "Region": "na-siliconvalley", (Tencent)
ZoneOpens in a new tab	選択したリージョン (上記を参照) 内のアベイラビリティ・ゾーン。サンプルの defaults.json の既定値を受け入れるか、プロバイダ提供のリージョンとゾーンの別の組み合わせを選択します。	"Zone": "us-west-1c", (AWS) "Zone": "us-east1-b", (GCP) "Zone": "1", (Azure) "Zone": "na-siliconvalley-1", (Tencent)
マシン・イメージ (プロバイダ固有)	プロビジョニングされたノードのプラットフォームおよび OS のテンプレート。サンプルの defaults.json の既定値を受け入れるか、プロバイダ提供のマシン・イメージとインスタンス・タイプ (以下を参照) の別の組み合わせを選択します。	"AMI": "ami-c509eda6", (AWSOpens in a new tab) "Image": "ubuntu-os-cloud/ubuntu-1804-bionic-v20180617", (GCPOpens in a new tab) "PublisherName": "Canonical", (AzureOpens in a new tab) "Offer": "UbuntuServer",(Azure) "Sku": "18.04-LTS",(Azure) "Version": "18.04.201804262",(Azure) "ImageID": "img-pi0ii46r", (TencentOpens in a new tab)
インスタンス・タイプ (プロバイダ固有)	プロビジョニングされたノードの計算リソースのテンプレート。サンプルの defaults.json の値を受け入れるか、プロバイダ提供のマシン・イメージ (上記を参照) とインスタンス・タイプの別の組み合わせを選択します。	"InstanceType": "m4.large", (AWSOpens in a new tab) "MachineType": "n1-standard-1", (GCPOpens in a new tab) "Size": "Standard_DS2_v2", (AzureOpens in a new tab) "InstanceType": "S2.MEDIUM4", (TencentOpens in a new tab)
資格情報とアカウント設定 (プロバイダ固有)	プロバイダに対する認証で ICM が必要とするファイルまたは ID。プロバイダによって異なります。アカウントの必要なファイルの場所または ID を指定するよう更新します (手順については、プロバイダのリンクをクリックしてください)。	“Credentials”:”/Samples/AWS/credentials”, (AWSOpens in a new tab) "Credentials": "/Samples/GCP/sample.credentials", (GCPOpens in a new tab) "Project": "dp-icmdevelopment", (GCP) "SubscriptionId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", (AzureOpens in a new tab) "ClientId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", (Azure) "ClientSecret": "xxxxxxxxxxxx/xxxxxxxxxxxxxxx/xxxxxxxxxxxxxx=", (Azure) "TenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", (Azure) "SecretID": "xxxxxxxxxxxx", (TencentOpens in a new tab) "SecretKey": "xxxxxxxxxxxx", (Tencent)
ISCPasswordOpens in a new tab	導入される InterSystems IRIS イメージの事前定義アカウントのパスワード。導入フェーズで入力をマスクしてインタラクティブにパスワードを指定するには (セキュリティのために推奨)、このフィールドを削除します。そうでなければ目的のパスワードに変更します。	"ISCPassword": "",
MirrorOpens in a new tab	DATA、DM、および DS ノードに導入した InterSystems IRIS インスタンスをミラーとして構成するかどうかを指定します。既定値のままにします。	“Mirror”: “false”
UserCPF	導入したインスタンスの初期 CPU 設定のオーバーライドに使用する構成マージ・ファイルを指定します (構成マージ機能または CPF に精通していない場合は、このエントリを削除します。構成マージの詳細は、"ICM・ガイド" の “ICM リファレンス” の章にある "カスタマイズされた InterSystems IRIS 構成を使用した導入" を参照してください)。	"UserCPF": "/Samples/cpf/iris.cpf"

以下のタブは、AWS、GCP、Azure、および Tencent のサンプルの defaults.json ファイルのコンテンツを示しています。

AWS GCP Azure Tencent

{
    "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"
}

{
    "Provider": "GCP",
    "Label": "Sample",
    "Tag": "TEST",
    "DataVolumeSize": "10",
    "SSHUser": "sample",
    "SSHPublicKey": "/Samples/ssh/insecure.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/",
    "Credentials": "/Samples/GCP/sample.credentials",
    "Project": "sample-project",
    "MachineType": "n1-standard-1",
    "Region": "us-east1",
    "Zone": "us-east1-b",
    "Image": "ubuntu-os-cloud/ubuntu-2204-jammy-v20220607",
    "DockerVersion": "5:20.10.17~3-0~ubuntu-jammy",
    "ISCPassword": "",
    "Mirror": "false",
    "UserCPF": "/Samples/cpf/iris.cpf"
}

{
    "Provider": "Azure",
    "Label": "Sample",
    "Tag": "TEST",
    "DataVolumeSize": "10",
    "SSHUser": "sample",
    "SSHPublicKey": "/Samples/ssh/insecure.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/",
    "Location": "Central US",
    "Zone": "1",
    "PublisherName": "Canonical",
    "Offer": "0001-com-ubuntu-server-jammy",
    "Sku": "22_04-lts",
    "Version": "22.04.202206040",
    "DockerVersion": "5:20.10.17~3-0~ubuntu-jammy",
    "Size": "Standard_DS2_v2",
    "AccountTier": "Standard",
    "AccountReplicationType": "LRS",
    "SubscriptionId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "ClientId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "ClientSecret": "xxxxxxxxxxxx/xxxxxxxxxxxxxxx/xxxxxxxxxxxxxx=",
    "TenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "ISCPassword": "",
    "Mirror": "false",
    "UserCPF": "/Samples/cpf/iris.cpf"
}

{
    "Provider": "Tencent",
    "Label": "Sample",
    "Tag": "TEST",
    "DataVolumeSize": "60",
    "SSHUser": "ubuntu",
    "SSHPublicKey": "/Samples/ssh/insecure.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/",
    "SecretID": "xxxxxxxxxxxx",
    "SecretKey": "xxxxxxxxxxxx",
    "InstanceType": "S2.MEDIUM4",
    "Region": "na-siliconvalley",
    "Zone": "na-siliconvalley-1",
    "ImageId": "img-22trbn9x",
    "DockerVersion": "5:20.10.10~3-0~ubuntu-focal",
    "ISCPassword": "",
    "Mirror": "false",
    "UserCPF": "/Samples/cpf/iris.cpf"
}

definitions.json のカスタマイズ

/Samples ディレクトリ内のサンプルの definitions.json ファイル (すべてのプロバイダで同一) では、以下に示すように、2 つのデータ・ノードと 2 つの計算ノードが含まれるシャード・クラスタを定義します。

[
   {
    "Role": "DATA",
    "Count": "2",
    "LicenseKey": "ubuntu-sharding-iris.key"
    },
    {
    "Role": "COMPUTE",
    "Count": "2",
    "StartCount": "3",
    "LicenseKey": "ubuntu-sharding-iris.key"
    }
]

Role フィールドは、プロビジョニングするノード・タイプ (ここでは DATA および COMPUTE) を指定します。Count フィールドは、プロビジョニングするそのノード・タイプの数を示します。StartCount は、COMPUTE ノードの番号付けを 0003 から開始します。LicenseKey フィールドは、既定値ファイルの LicenseDir フィールドで指定したディレクトリ内に配置されている InterSystems IRIS ライセンス・ファイルの名前を示します。

この演習では、以下のように、COMPUTE 定義を削除し、DATA 定義のみを残します。

[
   {
    "Role": "DATA",
    "Count": "2",
    "LicenseKey": "ubuntu-sharding-iris.key"
   }
]

シャード・クラスタを導入する場合、すべてのノードにシャード・ライセンスが必要です。docker cp を使用して、LicenseDir で指定したコンテナ内の場所 (/Samples/Licenses など) にシャード・ライセンスをコピーし、使用するライセンス・キーを指定するように DATA ノード定義内の LicenseKey 設定を更新します。

基本的なシャード・クラスタをプロビジョニングするために必要な definitions.json の変更はこれだけです。代わりに、スタンドアロンの InterSystems IRIS インスタンスをプロビジョニングするには、以下の定義を使用します。

[
   {
    "Role": "DM",
    "Count": "1",
    "LicenseKey": "standard-iris.key""
    },
]

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

既定では、ICM は現在のディレクトリ内の構成ファイルに入力された情報を使用します。したがって、インフラストラクチャをプロビジョニングするために必要なのは、選択したプロバイダの /Samples ディレクトリ (例えば、/Samples/AWS) に変更し、以下のコマンドを発行することだけです。

icm provision

icm provision コマンドは、選択したプラットフォームでホスト・ノードの割り当てと構成を行います。プロビジョニング操作時に、ICM は state サブディレクトリ内の状態ファイルとログ・ファイルを作成または更新し、完了時に instances.json ファイルを作成します。このファイルは、後続の導入コマンドと管理コマンドに対する入力となります。

ICM は一度に複数のタスクを実行するため、ステップ (Terraform の計画および適用、ファイルのコピー、ボリュームのマウントなど) が各ノードで同じ順序で開始され、完了するとは限りません。完了時に、ICM はプロビジョニングされたホスト・ノードの要約を表示し、後でインフラストラクチャを削除するために使用できるコマンド行を出力します。以下に例を示します。

Machine             IP Address     DNS Name                                           Region    Zone
-------             ----------     --------                                           ------    ----
Acme-DATA-TEST-0001 00.53.183.209  ec2-00-53-183-209.us-west-1.compute.amazonaws.com  us-west-1 c
Acme-DATA-TEST-0002 00.53.183.185  ec2-00-53-183-185.us-west-1.compute.amazonaws.com  us-west-1 c
To destroy: icm unprovision [-cleanUp] [-force]

プロビジョニングおよび導入フェーズで発生したエラーに関する詳細情報は、状態ディレクトリのサブディレクトリ内の terraform.err ファイルに書き込まれます。エラーが発生した場合、該当するファイルが示され、問題の原因を特定するのに役立ちます。

プロバイダ側のタイムアウトや内部エラー、または構成ファイル内のエラーが原因で icm provision が正常に完了しなかった場合は、指定したすべてのノードについて必要なタスクがすべてエラーなしで完了するまで、必要に応じて何回でもコマンドを発行できます。詳細は、"InterSystems Cloud Manager ガイド" の “ICM の使用” の章にある "インフラストラクチャの再プロビジョニングOpens in a new tab" を参照してください。

icm provision の詳細は、"InterSystems Cloud Manager ガイド" の "icm provision コマンドOpens in a new tab" を参照してください。

InterSystems IRIS の導入

プロビジョニングされたホスト・ノードでイメージをダウンロードし、コンテナとして実行するだけでなく、ICM は InterSystems IRIS 固有の構成やその他のタスクも実行します。プロビジョニングされたノードに InterSystems IRIS を導入するには、構成ファイルをカスタマイズし、インフラストラクチャをプロビジョニングした /Samples ディレクトリのまま、以下のコマンドを発行します。

icm run

既定では、icm run は、構成ファイルの DockerImage フィールドで指定されたイメージ (この場合は、インターシステムズのリポジトリにある InterSystems IRIS イメージ) をダウンロードして実行します。各コンテナの名前は iris です。実際には、(ここに示しているように既定値ファイルですべてのノードに対して 1 回ではなく) 定義ファイル内のノード定義のさまざまな DockerImage フィールドを使用することによって、ノード・タイプが異なれば異なるイメージを実行できます。また、それ以外にも、特定のオプションを指定して icm run コマンドを複数回実行することで、プロビジョニングされたノードごとに、または指定したノードのみに、固有の名前を持つ複数のコンテナを導入できます。

InterSystems IRIS が各ノードで起動すると、ICM は、パスワードのリセット、シャーディングの構成など、インスタンスで必要なすべての構成を行います。ICM は一度に複数のタスクを実行するため、導入プロセスのステップが各ノードで同じ順序で開始され、完了するとは限りません。

完了時に、ICM は該当する InterSystems IRIS インスタンスの管理ポータルへのリンクを出力します。

$ icm run -definitions definitions_cluster.json
Executing command 'docker login' on ACME-DATA-TEST-0001...
...output in /Samples/AWS/state/ACME-DATA-TEST/ACME-DATA-TEST-0001/docker.out
...
Pulling image intersystems/iris:2021.1.0.205.0 on ACME-DATA-TEST-0001...
...pulled ACME-DATA-TEST-0001 image intersystems/iris:2021.1.0.205.0
...
Creating container iris on ACME-DATA-TEST-0002...
...
Management Portal available at: http://ec2-00-53-183-209.us-west-1.compute.amazonaws.com:52773/csp/sys/UtilHome.csp 

ここでは、指定されたリンクは、データ・ノード 1 のリンクか、スタンドアロン・インスタンスのリンク (その構成を選択した場合) です。ブラウザでリンクを開き、管理ポータルを使用して InterSystems IRIS を確認します。

icm provision の場合と同様に、プロバイダ側のタイムアウトや内部エラーが原因で icm run が正常に完了しない場合は、このコマンドを再度発行できます。ほとんどの場合、繰り返し試行することで導入に成功します。どうしてもエラーが解決されず、手動による操作が必要な場合は (いずれかの構成ファイル内のエラーが原因である場合など)、問題を修正した後、icm run コマンドを再発行する前に、"InterSystems Cloud Manager ガイド" の “ICM の使用” の章にある "サービスの再導入Opens in a new tab" の説明に従って、影響を受けるノード上の永続的な %SYS データを削除する必要が生じることがあります。エラーが発生した場合は、ICM から示されたログ・ファイルの情報を参照すると、問題の原因を特定するのに役立ちます。

icm run コマンドとそのオプションの詳細は、"InterSystems Cloud Manager ガイド" の "icm run コマンドOpens in a new tab" を参照してください。

ICM 管理コマンドを体験

ICM には、以下を目的としたさまざまなコマンドが用意されています。

• プロビジョニングされたインフラストラクチャを管理する。

• 導入されたコンテナを管理する。

• InterSystems IRIS を含め、導入されたコンテナ内で実行されているサービスを操作する。

これらのコマンドの詳細は、"InterSystems Cloud Manager ガイド" の "インフラストラクチャ管理コマンドOpens in a new tab"、"コンテナ管理コマンドOpens in a new tab"、および "サービス管理コマンドOpens in a new tab" の各セクションを参照してください。"ICM コマンドとオプションOpens in a new tab" には、すべてのコマンドのリストを掲載しています。導入環境で試せるように、ここではいくつかの例を示します。特に、3 つのコマンド (icm ssh、icm exec、および icm session) を使用すると、以下に示すように、ノード自体、ノードに導入されたコンテナ、コンテナ内で実行されている InterSystems IRIS インスタンスなど、導入環境のノードをさまざまなレベルで操作できます。

新しく導入された InterSystems IRIS 構成で以下のコマンドを試してみましょう。

1. プロビジョニングされたホスト・ノードをリストします。

   icm inventory
   

   

2. それぞれのホスト・ノード上でシェル・コマンドを実行します。

   icm ssh -command "df -k"
   

   

   複数のノード上でコマンドが実行される場合、出力はファイルに書き込まれ、出力ファイルのリストが提供されます。例えば、ここでは、シャード・クラスタを導入した場合、3 つのノードそれぞれに出力ファイルが 1 つずつあります。

3. 特定のホスト・ノード上でインタラクティブ・シェルを開きます。

   icm ssh -role DATA -interactive
   

   

   インタラクティブにするには、コマンドで -interactive オプションを使用し、1 つのノードを指定する必要があります。例えば、icm ssh は、前の例のように、複数のノード上でコマンドを実行できますが、以下の例に示すように、-interactive オプションを指定すると、1 つのノード上でのみインタラクティブ・シェルを開くことができます。-role DM オプションは、コマンドをそのタイプのノード (導入環境に 1 つだけある) に限定します。このオプションの代わりに -machine オプションを使用して、特定のノードの名前を指定することもできます。以下に例を示します。

   icm ssh -machine Acme-DATA-TEST-0001 -interactive
   

   

4. 導入された InterSystems IRIS コンテナのステータスを表示します。

   icm ps
   

   

   複数のコンテナがノードに導入されている場合、このコマンドはそれらをすべてリストします。

5. InterSystems IRIS コンテナ、またはそれらのコンテナのいずれかにローカル・ファイルをコピーします。

   icm cp -localPath /Samples/ssh/ssh_notes -remotePath /home/sshuser
   
   icm cp -localPath /Samples/ssh/ssh_notes -remotePath /home/sshuser -role DM
   

   

6. それぞれの InterSystems IRIS コンテナ内でシェル・コマンドを実行します。

   icm exec -command "ls /irissys/"
   

   

7. 特定の InterSystems IRIS コンテナ内でインタラクティブ・シェルを開きます (またはシェル・コマンドを実行します)。

   icm exec -command "bash" -role DATA -interactive
   
   

   

8. InterSystems IRIS インスタンスに対してターミナル・ウィンドウを開きます (常にインタラクティブで、1 つのインスタンスのみを対象とします)。

   icm session -machine Acme-DATA-TEST-0001 
   

   

9. それぞれの InterSystems IRIS インスタンスに対して、または特定のインスタンスに対して SQL コマンドを実行します。

   icm sql -command "SELECT Name FROM Security.Users"
   
   icm sql -command "SELECT Name FROM Security.Users" -machine Acme-DATA-TEST-0002
   

   

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

AWS およびその他のパブリック・クラウド・プラットフォームのインスタンスは継続的に課金されるので、この体験が完了したらすぐに、インフラストラクチャのプロビジョニングを解除することが重要です。

そのためには、icm provision の出力から保存した icm unprovision コマンドを ICM コマンド行にコピーします。以下に例を示します。

$ icm unprovision -cleanUp

プロビジョニングの出力からコマンドを保存しなかった場合は、作業ディレクトリ内の icm.log ファイル (/Samples/AWS/icm.log など) で確認できます。-cleanUp オプションは、プロビジョニング解除の後に状態ディレクトリを削除します。このオプションを指定しなかった場合、状態ディレクトリは保持されます。