既存のクラスタへの導入
ICM には、コンテナを導入するクラウドまたは仮想ホスト・ノードまたは物理サーバを独自に割り振るオプションが用意されています。プロビジョニング・フェーズには割り振りと構成のサブフェーズが通常は含まれますが、Provider フィールドが PreExisting に設定されている場合、ICM は割り振りフェーズをバイパスして構成に直接進みます。既存のクラスタに対してプロビジョニング解除のフェーズはありません。
以下のセクションでは、プロバイダ PreExisting を使用して既存のインフラストラクチャに導入する場合の要件について説明します。
ICM は、それが実行されているホストにコンテナを導入することはできません。ICM にはそのホストの IP アドレスを特定する手段がないので、ユーザの責任で PreExisting 導入のホスト・ノードとして ICM ホストを指定しないようにしてください。
SSH
ICM を使用するには、SSH がインストールされていて、SSH デーモンが実行されている必要があります。
また、既定値ファイルの SSHUser フィールドで非 root アカウントを指定する必要があります。このアカウントには以下のような特性が必要です。
-
パスワードを要求せずに sudo アクセスを提供する必要があります。このアクセスを可能にするには、/etc/sudoers.d/ 内でファイルを作成するか、またはファイルを変更して、以下の行を含めます。
<accountname> ALL=(ALL) NOPASSWD:ALL
パスワード・ログインを完全に禁止するには、SSHOnly パラメータを true に設定します。これにより、ICM はパスワードを使用してログインできなくなるので、SSH 公開鍵 (SSHPublicKey フィールドによって指定される) を各ノードでステージングする必要があります。
-
ホーム・ディレクトリが /home 以外の場所にある場合は、既定値ファイルの Home フィールドにその場所を指定する必要があります。例を以下に示します。
"Home": "/users/"
ノード間で共有されるネットワーク・ディレクトリ (例えば、/nethome) をホーム・ディレクトリに指定すると、構成ファイルが別の構成ファイルを上書きするため、このように指定してはなりません。
ICM は、SSH 鍵またはパスワード・ログインを使用して、SSHUser としてログインできます。パスワード・ログインが有効になっている場合でも、ICM はまず SSH を使用したログインを試行します。
SSH 鍵を使用してマシンを構成した場合、SSHPublicKey フィールドと SSHPrivateKey フィールドを使用して、構成ファイルで SSH 公開/秘密鍵ペアを指定する必要があります。
構成フェーズ中に、ICM は SSH ログインを構成し、パスワード・ログインを既定では無効にします。パスワード・ログインを無効にしないようにする場合は、SSHUser アカウントのホーム・ディレクトリ内で以下の標識ファイルの touch を行うことができます。
mkdir -p ICM
touch ICM/disable_password_login.done
パスワードを使用してマシンを構成していた場合は、構成ファイル内の SSHPassword フィールドを使用してパスワードを指定します。ICM は、これらの資格情報が安全でないものと見なします。
パスワード・ログインを有効にして SSHPassword フィールドを指定しても、ICM が SSH 経由で構成後の操作すべてを実行できることは必要であり、この要件がなくなることはありません。
ポート
ローカル・セキュリティ・ポリシーとの競合を避けるため、またオペレーティング・システム間で差異があるために、ICM がポートのオープンを試行することはありません。以下の表に、さまざまな ICM 機能を使用するために開く必要がある既定のポートを示します。"ポートおよびプロトコルのパラメータ" に記載されているように、ポートは構成可能です。以下に例を示します。
"SuperServerPort": "51777"
以下に示すようにこれらの 1 つ以上のフィールドを既定値から変更する場合は、指定するポートが開いていることを確認する必要があります。
ポート | プロトコル | サービス | 留意事項 |
---|---|---|---|
22 | tcp | SSH | 必須項目。 |
2376 | tcp | Docker (TLS モード) | 必須項目。 |
80 | tcp | Web | ロール WS (Web サーバ) のノード上のパブリック Apache Web サーバにアクセスするために必要。 |
53 | tcp
udp |
DNS | Weave DNS に必要。 |
6783
67836784 |
tcp
udp |
Weave Net | Overlay=Weave に必要 (すべてのプロバイダの既定値)。 |
1972 | tcp | InterSystems IRIS スーパーサーバ | 必須項目。SuperServerPort フィールドを使用して、別のポートを指定できます。 |
52773 | tcp | InterSystems IRIS Web サーバ | 必須項目。WebServerPort フィールドを使用して、別のポートを指定できます。 |
2188 | tcp | InterSystems IRIS ISCAgent | ミラーリングに必要。ISCAgentPort フィールドを使用して、別のポートを指定できます。 |
4002 | tcp | InterSystems IRIS ライセンス・サーバ | 必須。注 : LicenseServerPort フィールドを使用して、別のポートを指定できます。 |
ストレージ・ボリューム
"ICM によってマウントされるストレージ・ボリューム" で説明したように、ICM は、InterSystems IRIS および Docker で使用するために提供するストレージ・ボリュームを、"デバイス名パラメータ" に示すフィールドで指定した名前を使用して /dev にマウントします。これらのデバイスの既定のマウント・ポイントを変更するには、対応するマウント・ポイント・パラメータで別の場所を指定します。
InterSystems IRIS で使用するために既存のインフラストラクチャ上に用意したボリュームを ICM でマウントするには、マウント・ポイント・パラメータでディレクトリを指定して、対応するデバイス名パラメータの 2 つの値のいずれかを使用できます。これを以下に示します。
-
existing (既定値) — マウント・ポイント・パラメータで指定したディレクトリが存在する場合、ICM はそのディレクトリを対象のストレージ・ボリュームとして使用します。例えば、DataDeviceName の値が existing であるか、値が指定されておらず、DataMountPoint の値が /mnt/data である場合、ICM は /mnt/data を InterSystems IRIS インスタンスのデータ・ボリュームとしてマウントします。マウント・ポイント・パラメータで指定したディレクトリが存在しない場合、データ・ボリュームはマウントされません。
-
create — existing と同じですが、次の点が異なります。マウント・ポイント・パラメータで指定したディレクトリが存在しない場合、ICM はそのディレクトリの作成を試行し、正常に作成できたら、それを対象のストレージ・ボリュームとしてマウントします。ディレクトリを作成できなかった場合、ストレージ・ボリュームはマウントされません。
PreExisting の定義ファイル
PreExisting とその他のプロバイダとの主な違いは、定義ファイルの内容です。この定義ファイルには、ノードごとに必ず 1 つずつのエントリが含まれます (ロールごとに 1 つのエントリがあってそのロールのノード数を指定する Count フィールドが含まれる定義ファイルとは異なります)。それぞれのノードは、IPAddress フィールドを使用して IP アドレスによって識別されます。