ICM 導入環境の共有

分散管理モードの概要

インフラストラクチャのプロビジョニングに使用する最初の ICM コンテナをプライマリ ICM コンテナ (または単に “プライマリ ICM”) と呼びます。このプロビジョニング・フェーズでは、プライマリ ICM は以下を実行します。

• 1 台、3 台、または 5 台の Consul サーバを CN ノードに導入します。これらのノードは、Consul クライアントと共にクラスタ化されます。

• icm provision コマンドの完了時に以下を実行します。

  • 導入の状態ファイル (指定内容については "状態ファイル" を参照) を Consul クラスタにプッシュします。

  • 導入環境用にさらに ICM コンテナを作成するために docker run コマンドを出力します。

出力された docker run コマンドをユーザが実行すると、セカンダリ ICM コンテナ (“セカンダリ ICM”) が作成され、プロバイダに応じたディレクトリ (例えば、/Samples/GCP) でインタラクティブ・コンテナ・セッションが開始します。セカンダリ ICM では、ICM コマンドが開始するたびに、導入の状態ファイルが Consul クラスタから自動的にプルされるため、セカンダリ ICM では常に最新情報が保持されます。これによって、インフラストラクチャのプロビジョニングもプロビジョニング解除もできないことを除き、プライマリ ICM コンテナのまったくの複製であるコンテナが作成されます。その他の ICM コマンドはすべて有効です。

分散管理モードの構成

プライマリ ICM コンテナおよび Consul クラスタを作成するには、以下の操作を行います。

1. ConsulServers フィールドを defaults.json ファイルに追加して、以下のように Consul サーバの数を指定します。

   “ConsulServers”: “3”
   

   

   指定可能な値は、1、3、および 5 です。単一 Consul サーバは、単一障害点となるため、お勧めしません。5 台のサーバによるクラスタは、3 台のサーバによるクラスタより信頼性が高まりますが、コストも高くなります。

2. definitions.json ファイルに、CN ノード定義を追加します。このとき、ConsulServers フィールドの値以上の数の CN ノードを指定します。以下に例を示します。

   {
        "Role": "CN",
        "Count": "3",
        "StartCount": "7",
        "InstanceType": "t2.small"
   }
   

   

3. ICM コンテナで、プライマリ ICM の docker run コマンドに consul.sh スクリプトを追加します。

   docker run --name primary-icm --init -d -it --cap-add SYS_TIME 
     intersystems/icm:2022.2.0.221.0 consul.sh
   

   

プライマリ ICM コマンド行で、icm provision コマンドを発行すると、各 CN ノードがプロビジョニングされる際に、それらの各 CN ノードに Consul サーバが、指定したサーバ台数に達するまで導入されます。このコマンドが正常に完了すると、プライマリ ICM は状態ファイルを Consul クラスタにプッシュします。その出力にはセカンダリ ICM の作成コマンドが含まれます。プライマリ ICM で、インスタンス・ファイルを変更する可能性のあるコマンド (icm run や icm upgrade など) を次に発行すると、プライマリ ICM は新しいファイルを Consul クラスタにプッシュします。プライマリ ICM で icm unprovision コマンドを使用して導入のプロビジョニング解除を行うと、その状態ファイルは Consul クラスタから削除されます。

icm provision コマンドによる出力で提供されるセカンダリ ICM の icm run コマンドには暗号化キー (16 バイト、Base64 でエンコードされたもの) が含まれ、新しい ICM コンテナは Consul クラスタに参加することができます。以下に例を示します。

docker run --name icm --init -d -it --cap-add SYS_TIME intersystems/icm:2022.2.0.221.0 
  consul.sh qQ6MPKCH1YzTb0j9Yst33w==

セカンダリ ICM 作成コマンドは、必要なだけ何回でも、導入へのネットワーク・アクセスがある任意の場所で使用できます。

プライマリ ICM コンテナとセカンダリ ICM コンテナの両方で、consul members コマンドを使用して、Consul クラスタに関する情報を表示できます。以下に例を示します。

/Samples/GCP # consul members
Node                                  Address               Status  Type    Build  Protocol DC  Segment
consul-Acme-CN-TEST-0002.weave.local  104.196.151.243:8301  failed  server  1.1.0  2        dc1 <all>
consul-Acme-CN-TEST-0003.weave.local  35.196.254.13:8301    alive   server  1.1.0  2        dc1 <all>
consul-Acme-CN-TEST-0004.weave.local  35.196.128.118:8301   alive   server  1.1.0  2        dc1 <all>
3be7366b4495                          172.17.0.4:8301       alive   client  1.1.0  2        dc1 <default>
e0e87449a610                          172.17.0.3:8301       alive   client  1.1.0  2        dc1 <default>

以下に示したように、Consul コンテナは、icm ps コマンドの出力にも含まれます。

Samples/GCP # icm ps
Pulling from consul cluster...
CurrentWorkingDirectory: /Samples/GCP
...pulled from consul cluster
Machine            IP Address       Container           Status   Health   Image
-------            ----------       ---------           ------   ------   -----
Acme-DM-TEST-0001  35.227.32.29     weave               Up                weaveworks/weave:2.3.0
Acme-DM-TEST-0001  35.227.32.29     weavevolumes-2.3.0  Created           weaveworks/weaveexec:2.3.0
Acme-DM-TEST-0001  35.227.32.29     weavedb             Created           weaveworks/weavedb:2.3.0
Acme-CN-TEST-0004  35.196.128.118   consul              Up                consul:1.1.0
Acme-CN-TEST-0004  35.196.128.118   weave               Up                weaveworks/weave:2.3.0
Acme-CN-TEST-0004  35.196.128.118   weavevolumes-2.3.0  Created           weaveworks/weaveexec:2.3.0
Acme-CN-TEST-0004  35.196.128.118   weavedb             Created           weaveworks/weavedb:2.3.0
Acme-CN-TEST-0002  104.196.151.243  consul              Up                consul:1.1.0
Acme-CN-TEST-0002  104.196.151.243  weave               Up                weaveworks/weave:2.3.0
Acme-CN-TEST-0002  104.196.151.243  weavevolumes-2.3.0  Created           weaveworks/weaveexec:2.3.0
Acme-CN-TEST-0002  104.196.151.243  weavedb             Created           weaveworks/weavedb:2.3.0
Acme-CN-TEST-0003  35.196.254.13    consul              Up                consul:1.1.0
Acme-CN-TEST-0003  35.196.254.13    weave               Up                weaveworks/weave:2.3.0
Acme-CN-TEST-0003  35.196.254.13    weavevolumes-2.3.0  Created           weaveworks/weaveexec:2.3.0
Acme-CN-TEST-0003  35.196.254.13    weavedb             Created           weaveworks/weavedb:2.3.0

Note:

ICM コマンドには並行処理の制御が適用されないため、複数の ICM コンテナで競合するコマンドを同時に発行すると、一部のコマンドが失敗します。結果はタイミングに基づき、エラーが含まれる場合があります。例えば、異なるコンテナの 2 人のユーザが同時に icm rm -machine Acme-DM-TEST-0001 コマンドを発行したとします。一方のユーザには、以下が表示されます。

Removing container iris on Acme-DM-TEST-0001...
...removed container iris on Acme-DM-TEST-0001

他方のユーザには、以下が表示されます。

Removing container iris on Acme-DM-TEST-0001...
Error: No such container: iris

ただし、競合が存在しない場合、同じコマンドを同時にエラーなしに実行することができます。例えば、icm rm -machine Acme-DM-TEST-0001 コマンドや icm rm -container customsensors -machine Acme-DM-TEST-0001 コマンドです。

分散管理モードを使用した ICM のアップグレード

"分散管理モードの概要" で説明したように、分散管理モードでは導入の状態ファイルが Consul クラスタに保存されるので、これらのファイルを失うことなく、ICM コンテナを簡単にアップグレードできます。

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

分散管理モードで ICM コンテナをアップグレードするには、以下の手順を使用します。

1. プライマリ ICM コンテナによるプロビジョニングの終了時に提供されるセカンダリ ICM の icm run コマンドを使用して ("分散管理モードの構成" を参照)、アップグレード先の ICM イメージからセカンダリ ICM コンテナを作成します (異なる ICM イメージから作成されたプライマリ ICM コンテナとセカンダリ ICM コンテナは互換性があります)。

2. プライマリ ICM コンテナで、コマンド consul.sh show-master-token を発行して Consul トークンの値を取得します。

3. アップグレードされたセカンダリ ICM コンテナで、コマンド consul.sh convert-to-thick Consul_token を発行して、それをプライマリ ICM コンテナに変換します。

4. docker stop と docker rm を使用して、古いプライマリ ICM コンテナを停止して削除します。

現在の導入環境を管理している ICM コンテナをアップグレードする際にはこの方法が推奨されるので、分散管理を使用するかどうかに関係なく、このオプションを使用できるように、ICM を使用するたびにプライマリ ICM コンテナを作成することをお勧めします。

状態ファイル

状態ファイルは現在の作業ディレクトリから読み書きされますが、カスタムの名前と場所を使用するようにこれらのファイルすべてをオーバーライドできます。入力ファイルは、以下のとおりです。

• defaults.json

• definitions.json

これらの構成ファイル内で参照されるセキュリティ・キー、InterSystems IRIS ライセンス、またはその他のファイルも、入力と見なす必要があります。

出力ファイルは、以下のとおりです。

• instances.json

• state/ ディレクトリ (-stateDir path でオーバーライドできます)

state/ の下にあるファイルのレイアウトは、以下のとおりです。

definition 0/
definition 1/
...
definition N/

それぞれの定義ディレクトリの下には、以下のファイルがあります。

• terraform.tfvars — Terraform 入力

• terraform.tfstate — Terraform 状態

さまざまなログ・ファイル、一時ファイル、およびその他のファイルもこの階層内に存在しますが、これらは導入環境の共有には必要ありません。

不変性の維持

以下の理由から、ICM コンテナのローカル側では状態ファイルを生成しないことをお勧めします。

• 不変性が損なわれます。

• コンテナが削除/更新/置換されると、データが失われる可能性があります。

• ICM コンテナ内で構成ファイルを編集できる範囲は制限されています。

• コンテナの外部に状態ファイルをコピーする必要があり、この作業は面倒でエラーの原因になります。

より良い方法は、作業ディレクトリとして使用するディレクトリを ICM コンテナ内でホストからマウントすることです。このようにすれば、コンテナ内でのすべての変更を常にホスト上で取得できます。このためには、以下のように、ICM コンテナを初めて作成するときに Docker --volume オプションを使用します。

$ docker run --name icm --init -d -it -cap-add SYS_TIME --volume <host_path>:<container_path> <image>

全体としては、以下の手順を実行します。

1. ホスト上の入力ファイルを host_path 内でステージングします。

2. ICM コンテナを作成し、起動して、コンテナにアタッチします。

3. container_path に移動します。

4. ICM コマンドを発行します。

5. ICM コンテナを終了するか、アタッチを解除します。

これで、状態ファイル (入力と出力の両方) が host_path に格納されます。この方法の例については、"ICM の起動" のサンプル・スクリプトを参照してください。

状態ファイルの維持

状態ファイルを維持し、他のユーザと共有するには、以下のような方法があります。

• tar/gzip を作成する

  作成したアーカイブを電子メールで送信したり、FTP サイトに配置したり、USB メモリに書き込むことができます。

• 他のユーザがリストアできる場所にバックアップを作成する

  ホスト上の状態ファイルのパスをバックアップ・サービスに登録します。

• 組織内の他のユーザがアクセスできるディスク・ボリュームをマウントする

  例えば、状態ファイルのパスを Samba マウントにできます。

• クラウドにバックアップされるディスクの場所を指定する

  Dropbox、Google Drive、OneDrive などのサービスを使用できます。

• ドキュメント・データベースに保管する

  クラウド・ベースまたはオンプレミスのデータベースを使用できます。

後に挙げた 3 つの方法の利点は、他のユーザが導入環境を変更できることです。ただし、複数の ICM コンテナから一度に発行される同時操作は ICM によるサポート対象外なので、排他的な読み取り/書き込みアクセスを保証するポリシーを施行する必要があります。