コンテナ内でのインターシステムズ製品の実行

インターシステムズのコンテナ・イメージは Open Container Initiative (OCIOpens in a new tab) の仕様に準拠しているため、オンプレミスとパブリック・クラウドの両方において、Linux ベースのオペレーティング・システム上の任意の OCI 準拠ランタイム・エンジンでサポートされます。

インターシステムズのコンテナを導入するコンテナ・ランタイム・エンジン (Docker や Podman など) をサーバにインストールします。

https://containers.intersystems.com/Opens in a new tab にある InterSystems Container Registry (ICR) には、InterSystems IRIS イメージを含む、インターシステムズから入手可能なすべてのイメージのリポジトリが含まれています。"InterSystems Container Registry の使用Opens in a new tab" では、ICR から入手できるイメージを紹介すると共に、WRC 認証情報を使用してレジストリに対して認証し、イメージをダウンロードできるようにする方法について説明しています。

コンテナ化されたシステム内でのバージョンの一貫性を確保するため、組織が InterSystems IRIS イメージを独自のプライベート・イメージ・レジストリに保持することがあります。このような場合は、担当の管理者から、レジストリの場所と認証に必要な認証情報を入手してください。ICR または組織のレジストリのどちらかにログインしたら、docker pull コマンドを使用してイメージをダウンロードできます。以下の例は、ICR からのプルを示しています。

$ docker login containers.intersystems.com
Username: pmartinez
Password: **********
$ docker pull containers.intersystems.com/intersystems/iris:latest-em
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 2023.2.0.299.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

以下の例で示しているように、インターシステムズのコンテナの既定値は、docker inspect コマンドを使用して必要な情報を検出できるように、標準のラベル・メカニズムを通して公開されています。インターシステムズのテクノロジに精通しているユーザは、一般的な既定のポートやその他の有用な情報を認識できるはずです (このコマンドの出力形式については、Docker ドキュメントの "Format command and log outputOpens in a new tab" を参照してください)。

$ docker inspect -f {{json .Config.Labels}} intersystems/iris:latest-em
  "Labels": {
      "com.intersystems.adhoc-info": "",
      "com.intersystems.platform-version": ":2023.2.0.299.0",
      "com.intersystems.ports.default.arbiter": "2188",
      "com.intersystems.ports.default.license-server": "4002",
      "com.intersystems.ports.default.superserver": "1972",
      "com.intersystems.product-name": "IRIS",
      "com.intersystems.product-platform": "dockerubuntux64",
      "com.intersystems.product-timestamp": "Wed May 16 2022 00:37:59 EST",
      "com.intersystems.product-timestamp.iso8601": "2023-08-16T05:37:59Z",
      "maintainer": "InterSystems Worldwide Response Center <support@intersystems.com>",
      "org.opencontainers.image.created": "2023-08-16T07:57:10Z",
      "org.opencontainers.image.documentation": "https://docs.intersystems.com/",
      "org.opencontainers.image.title": "intersystems/iris",
      "org.opencontainers.image.vendor": "InterSystems",
      "org.opencontainers.image.version": "2023.2.0.299.0"
      }

あらゆる InterSystems IRIS インスタンスと同様に、コンテナ内で実行されるインスタンスにもライセンス・キー (通常は iris.key) が必要です。InterSystems IRIS ライセンス・キーに関する一般情報は、"InterSystems IRIS ライセンスの管理" を参照してください。

InterSystems IRIS Community Edition イメージ (前のセクションの説明のとおり) には、特別な無料一時ライセンスが付属しています。ただし、通常、ライセンス・キーは、InterSystems IRIS コンテナ・イメージに含まれていません。代わりに、コンテナにアクセスできるストレージ位置 (通常はマウントされたボリューム) にライセンス・キーを置き、コンテナにライセンス・キーをコピーするメカニズムを設定し、コンテナでライセンス・キーを有効にして InterSystems IRIS インスタンスを実行できるようにします。

InterSystems IRIS コンテナのブロック・エントリ・ポイント・アプリケーションとして実行される iris-main プログラムには、ライセンス・キーを扱うためのオプションが用意されています。このオプションは、InterSystems IRIS コンテナを起動する docker start コマンドまたは docker run コマンドで使用できます。--key オプションは、指定した場所から InterSystems IRIS インスタンスの mgr/ ディレクトリにライセンス・キーをコピーします。つまり、ライセンス・キーはインスタンスの起動時に自動的に有効になります。ライセンス・キーをコンテナ内のローカル・ファイル・システムに配置することはできません。通常は、docker run コマンドの --volume オプションでコンテナによってボリュームとしてマウントされるストレージ場所 (多くの場合、永続的な %SYS ボリューム) に配置します。このオプションの構文は、以下のとおりです。

--key <key_path>

key_path はコンテナ内部からライセンス・キーへのパスです。例えば、ライセンス・キーが license/ というディレクトリに含まれる外部ストレージ場所を /external としてマウントする場合、--key オプションは以下のようになります。

--key /external/license/iris.key

--key オプションでは、コンテナをアップグレードすることなく、インスタンスのライセンスを更新できます。InterSystems IRIS イメージにより、docker run または docker start コマンドでこのオプションを使用すると、iris-main はステージングされるライセンス・キーの変更を継続的に監視し (元の場所に維持されていると想定)、ファイルの変更が検出されると、現在の mgr/ ディレクトリにコピーされ、%SYSTEM.License.Upgrade()Opens in a new tab API 呼び出しが行われます。

iris-main のオプションのリストは、"iris-main プログラム" を参照してください。--key オプションの使用例は、"InterSystems IRIS コンテナの実行" を参照してください。

インターシステムズ提供の InterSystems IRIS イメージを操作する場合、以下に示したような、イメージのセキュリティ関連のメカニズムとオプションを理解することが重要です。

• 所有権とディレクトリ

• 認証とパスワード

• InterSystems IRIS ロック・ダウン・コンテナ

所有権とディレクトリ

インターシステムズ提供のイメージから作成されたコンテナ内の InterSystems IRIS インスタンスは、常に IRIS という名前が付けられ、非 root です。これは、root 特権のないユーザ・アカウント irisowner (UID 51773) によってインストールおよび所有されていることを意味します。インスタンスを構成するすべてのファイル・システム・エンティティは、irisowner によって所有され、root が所有するものはありません。 インスタンスではオペレーティング・システム・ベースの認証が有効になっています。つまり、irisowner プロセスまたは別のシステムで認証されたクライアントは認証なしでインスタンスに接続できます。コンテナ外から docker execOpens in a new tab を使用して発行されたコマンドは、コンテナ内で irisowner として実行されるため、このコマンドを使用することで、認証なしで簡単にインスタンスに接続することができます。例えば、iris273 というコンテナ内のインスタンスの InterSystems ターミナルOpens in a new tabを認証情報を要求されずに開くには、次のコマンドを使用します。

docker exec -it iris273 iris terminal IRIS 

コンテナ内のインストール・ディレクトリ (mgr/ サブディレクトリを含む) は、/usr/irissys/ です。作業ディレクトリ (iris-main.log などのファイルを含む) は /home/irisowner/、レジストリ・ディレクトリは /home/irisowner/irissys/ です。

これらの構成の詳細を指定するために使用されるインストール・パラメータの詳細は、"必須の環境変数" を参照してください。こういったインストール関連の一般的なトピックの詳細は、"UNIX®、Linux、および macOS でのインストール" を参照してください。

インターシステムズには、作成する InterSystems IRIS ベースのイメージのこういった構成の詳細を決定するためのツールが用意されています。これらのツールについては、"InterSystems IRIS のコンテナ化ツール" を参照してください。

Important:

永続的な %SYS 機能を使用してコンテナ化された InterSystems IRIS インスタンスに永続ストレージを提供する場合、このためにマウントおよび指定されるホストのファイル・システムの場所は、ユーザ 51773 によって書き込み可能である必要があります (これを有効にするには、多くの場合、root 特権が必要です)。

Pod Manager ツール (podman) で導入された InterSystems IRIS コンテナで永続的な %SYS を使用する場合は、以下を行う必要があります。

• コンテナを起動する前に、以下のコマンドを発行します。

  podman unshare chown 51773:51773 $INSTANCEDIR
  

  

  $INSTANCEDIR は、永続的な %SYS ディレクトリを含むホスト・ファイル・システムの場所です。

• Red Hat Security-Enhanced Linux (SELinux) がアクティブな場合は、コンテナの作成時に --privileged=true フラグを含めます。

Kubernetes で InterSystems Kubernetes OperatorOpens in a new tab なしで永続的な %SYS を使用する場合、ポッド指定に次のセキュリティ・コンテキストOpens in a new tab設定を含める必要があります。

securityContext:
  fsGroup: 51773

永続的な %SYS を使用して InterSystems IRIS コンテナをバージョン 2021.2 以降にアップグレードする前に、既存の永続ディレクトリをユーザ 51773 によって書き込み可能にする必要があります。

Note:

irisowner ユーザ・アカウントがコンテナをホストするシステムの /etc/passwd ファイルに定義されていない場合、これは、そのシステムの UID (51773) で表されます。

"ミラーリングの構成" で説明している手順に従って、コンテナに導入された InterSystems IRIS インスタンスをキットから導入されたインスタンスと同じ方法でミラーとして構成できます。ただし、以下に挙げるいくつかの点に留意してください。

• (インターシステムズが強く推奨するように) ミラーに対して構成するアービターは、インターシステムズが提供する arbiter イメージから導入できます。arbiter イメージは、InterSystems IRIS イメージについての説明と同じ手順を使用してダウンロードできます ("InterSystems IRIS コンテナのセキュリティ" で説明したとおり、これは非 root イメージであることに注意してください)。コンテナ化されていない InterSystems IRIS インスタンスまたはキットからインストールされたアービターも使用できます。

• InterSystems IRIS コンテナおよびアービター・コンテナを導入する場合、"ミラー・メンバのネットワーク・アドレス" で説明しているように、ミラー・メンバ、それらの ISCAgent、およびアービターが使用するポートを確実に公開する必要があります。

• 各フェイルオーバーおよび DR 非同期ミラー・メンバの ISCAgent は、InterSystems IRIS が起動する前に自動的に起動するように構成される必要があります。これは、InterSystems IRIS イメージの既定の動作です。InterSystems IRIS コンテナの実行時は、次の iris-main ISCAgent オプションを使用できます。

  --ISCAgent true|false
  

  true の場合、コンテナが既定の ISCAgent ポート 2188 で起動されると、ISCAgent が起動します (これが、オプションが省略された場合の既定の動作です)。false の場合、ISCAgent は起動せず、--ISCAgentPort オプションは無視されます。

  --ISCAgentPort NNNN 
  

  ポートを指定して、ISCAgent を起動します (オプションが省略された場合の既定値は 2188 です)。このオプションは、--ISCAgent true と共に使用できます。指定された値が有効なポート番号ではない場合 (整数でない場合など)、または示されたポートが使用されている場合、ISCAgent は開始に失敗します。

• "ミラーリング通信"、"ミラーリング・アーキテクチャとネットワーク構成のサンプル"、および "ミラーの可用性を最適化するためのアービターの配置" を参照して、導入において必要なネットワーキングに関する考慮事項すべてに対処していることを確認してください。

コードとデータの分離は、コンテナ化の主な利点の 1 つです。実行中のコンテナは、適切なデータ・ソースを処理できる "純粋なコード" を表します。ただし、アプリケーションとプログラムはすべて、動作と履歴のデータ (例えば構成と言語の設定、ユーザ・レコード、ログ・ファイルなど) を生成し、維持します。これらは、1 つのコンテナの存続期間を超えて保持され、アップグレードを可能にする必要があります。このため、コンテナ化は一般に、永続的なデータ・ストレージでアプリケーション・データベースを含めプログラム関連データを保持するニーズに対処する必要があります。これには、保持するデータと永続的な場所を特定し、アップグレード後、または前のコンテナで障害が発生した後で、新しいコンテナをこの場所に送信できるメカニズムが必要です。

永続的な %SYS 機能は、必要なインスタンス固有データ (ログ、ジャーナル、WIJ ファイル、および IRISSYS などのシステム・データベースなど) を、コンテナのホストのファイル・システム上で選択した場所に複製し、その新しい (複製された) 場所でデータを使用するためインスタンスをリセットすることにより、InterSystems IRIS コンテナでこれを実現します。永続的な %SYS を使用するには、選択した場所をコンテナ内のボリュームとしてマウントし、コンテナの起動時に指定される環境変数でこれを識別する必要があります。InterSystems IRIS インスタンスはコンテナ化されたままですが、そのインスタンス固有データは、アプリケーション・データが保存されるデータベースと同様にコンテナの外部に存在しており、コンテナとインスタンスの再起動後にも永続し、インスタンスのアップグレードに利用できるようになっています (アップグレードの詳細は、"InterSystems IRIS コンテナのアップグレード" を参照してください)。

永続的な %SYS ディレクトリは、コンテナが最初に起動されるときに作成された状態では、InterSystems IRIS インストール・ツリーのサブセットを含みます。内容は以下のようなものですが、これらに限られるわけではありません。

• iris.cpf という名前の構成パラメータ・ファイル (CPF)。他の InterSystems IRIS インスタンスの場合と同様に、ファイルの追加バージョン (旧バージョンと _LastGood_.cpf) が作成されます。("構成マージを使用した InterSystems IRIS の自動構成"、"構成パラメータ・ファイル・リファレンス")

• Web ゲートウェイ構成ファイルとログ・ファイルを含む /csp ディレクトリ。(Web ゲートウェイ・ガイド)

  Note:

  Web ゲートウェイ・コンテナには同様の永続ストレージ機能があり、その機能を使用した場合 ("Web ゲートウェイ・コンテナの実行オプション" を参照)、このディレクトリは独自の永続ストレージ上に配置されます。

• インスタンスのバージョン (2023.2.0.299.0 など) を含むファイル /dist/install/misc/buildver。

• インスタンスの Web サーバの構成ファイルである /httpd/httpd.conf ファイル。("サポート対象の Web サーバ" を参照)

• 以下の内容を含む /mgr ディレクトリ。

  • IRISSYS システム・データベース (IRIS.DAT ファイルと iris.lck ファイル、およびストリーム・ディレクトリを含む)、および irismetrics、iristemp、irisaudit、iris、および user の各ディレクトリ (IRISMETRICS、IRISTEMP、IRISAUDIT、IRIS、および USER の各システム・データベースを含む)。("システム提供データベース" と "IRISSYS のカスタム項目" を参照)

  • ライト・イメージ・ジャーナリング・ファイル IRIS.WIJ (ファイル・システムの分離を実現するために配置が変更される場合があります)。("ライト・イメージ・ジャーナリングとリカバリ" を参照)

  • ジャーナル・ファイルを含む /journal ディレクトリ (ファイル・システムの分離を実現するために配置が変更される場合があります)。("ジャーナリングの概要" を参照。"コンテナ化された InterSystems IRIS のファイル・システムの分離" も参照)

  • 一時ファイル用の /temp ディレクトリ。

  • messages.log、journal.log、SystemMonitor.log などのログ・ファイル。その他のログが初期に存在する場合があり、いくつかは必要に応じて作成されます (例えば、バックアップおよびミラーのジャーナル・ログ)。("InterSystems IRIS ログの監視" を参照。)

    Note:

    永続的な %SYS のアクティビティは、messages.log ファイルに記録されます。この機能の使用中に問題が生じた場合は、このログを調べると役に立つ情報が得られることがあります。コンテナの外部からこのログを読み取る方法については、"iris-main プログラム" を参照してください。コンテナ化された InterSystems IRIS インスタンスの管理ポータルへのアクセスの詳細は、"Web ゲートウェイ・コンテナを使用した Web アクセス" を参照してください。

  • InterSystems IRIS ライセンス・キー・ファイル iris.key (InterSystems IRIS イメージに含まれている場合はコンテナの起動時、またはコンテナの実行中にライセンスが有効化されたとき)。("ライセンス・キーの有効化" を参照)

  • いくつかの InterSystems IRIS システム・ファイル。

• 上の最初の箇条書きでリストされている標準の InterSystems IRIS データベース以外の、インスタンスで定義された読み取り専用ではないすべてのデータベース。これは、インターシステムズが提供するイメージをベースにしたユーザ作成イメージ ("InterSystems IRIS イメージの作成" を参照) 内のインスタンスに追加されたデータベースが永続的なデータに含まれていることを確認するものです。データベース・ディレクトリがコンテナのインストール・ディレクトリの下にある場合 (/usr/irissys/mgr の下など)、永続的な %SYS ディレクトリ内の対応する場所にコピーされます。データベース・ディレクトリがインストール・ディレクトリの下にない場合は、インストール・ディレクトリに新しいフォルダ db が作成され、ここにこれらがコピーされます。

このシステムに不可欠なインスタンス固有の情報が保管される場所を選択する際には、以下の考慮事項に留意してください。

• 適切なバックアップとリストアの手順が利用可能であること ("バックアップとリストア" を参照)。

• 導入している高可用性メカニズム ("高可用性ガイド")。

• 使用可能なストレージ・スペースと拡張の余地 ("ローカル・データベースの管理" を参照)。

永続的な %SYS ディレクトリを初期化するには、指定されたボリューム上で少なくとも 200 MB の使用可能なスペースが必要です。ただし、ジャーナル・レコードなどの処理用ファイルや、システム・データベースの拡張など、さまざまな理由からディレクトリ内のデータの量が大幅に増える可能性があります。

マウント・ボリュームの最上位ではなく、サブディレクトリを永続的な %SYS の場所として指定することをお勧めします。例えば、外部ファイル・システムの場所がコンテナ内のボリューム /external としてマウントされている場合、/external を永続的な %SYS の場所として指定しないでください。代わりに、/external/durable などの /external 上のディレクトリを指定してください。

Important:

"InterSystems IRIS コンテナのセキュリティ" で説明したとおり、iris および iris-lockeddown イメージ内のインスタンスは、ユーザ irisowner (UID 51773) によってインストールおよび所有されているため、永続的な %SYS に指定するファイル・システムの場所は、最初に irisowner によって書き込み可能な状態にする必要があります。例えば、次のコマンドを使用してこれを行います。

chown 51773:51773 root-of-durable-%SYS-directory

これを有効にするには、多くの場合、root 特権が必要です。

Kubernetes で InterSystems Kubernetes OperatorOpens in a new tab なしで永続的な %SYS を使用する場合、ポッド指定に次のセキュリティ・コンテキストOpens in a new tab設定を含める必要があります。

securityContext:
  fsGroup: 51773

永続的な %SYS を使用するには、以下のオプションを docker run コマンドに組み入れます。

--volume /volume-path-on-host:/volume-name-in-container
--env ISC_DATA_DIRECTORY=/volume-name-in-container/durable-directory

ここで、volume-path-on-host はコンテナによってマウントされる永続的なストレージ場所のパス名、volume-name-in-container はコンテナ内でのマウント・ボリュームの名前、durable_directory はそのマウント・ボリュームに作成する永続的な %SYS ディレクトリの名前です。例えば、以下のように指定します。

docker run --detach 
  --volume /data/dur:/dur 
  --env ISC_DATA_DIRECTORY=/dur/iconfig 
  --name iris21 intersystems/iris:latest-em

この例では、永続的な %SYS ディレクトリはコンテナ外部の /data/dur/iconfig と、コンテナ内部の /dur/iconfig です。

これらのオプションを使用して InterSystems IRIS コンテナを実行する際には、以下の処理が行われます。

• 指定された外部ボリュームがマウントされます。

• コンテナ内部の InterSystems IRIS インストール・ディレクトリが読み取り専用に設定されます。

• 前述の例の ISC_DATA_DIRECTORY 環境変数 iconfig/ によって指定された永続的な %SYS ディレクトリが既に存在し、/mgr サブディレクトリを含んでいる場合は、インスタンスの内部ポインタはすべてそのディレクトリにリセットされ、インスタンスはそのディレクトリに含まれているデータを使用します。データの InterSystems IRIS バージョンがインスタンスのバージョンと一致しない場合は、アップグレードされたものと想定され、データは必要に応じてインスタンスのバージョンにアップグレードされます (アップグレードについては、"InterSystems IRIS コンテナのアップグレード" を参照してください)。

• ISC_DATA_DIRECTORY によって指定されている永続的な %SYS ディレクトリが存在しないか、存在していて空の場合は、以下の処理が行われます。

  • 必要に応じて、指定された永続的な %SYS ディレクトリが作成されます。

  • "永続的な %SYS ディレクトリの内容" に示されているディレクトリとファイルが、インストールされた場所から永続的な %SYS ディレクトリにコピーされます (オリジナルは元の場所に残ります)。

  • インスタンスの内部ポインタはすべて永続的な %SYS ディレクトリにリセットされ、インスタンスはそのディレクトリに含まれているデータを使用します。

  何らかの理由で、永続的な %SYS データのコピーと内部ポインタのリセットのプロセスが失敗した場合、永続的な %SYS ディレクトリは「不完全」としてマークされます。同じディレクトリに対してもう一度操作を実行した場合、そのディレクトリ内のデータは、永続的な %SYS プロセスが開始する前に削除されます。

• ISC_DATA_DIRECTORY 環境変数によって指定されている永続的な %SYS ディレクトリが既に存在していてデータ (ファイルまたはサブディレクトリ) が含まれていても、/mgr サブディレクトリが含まれていない場合、データはコピーされません。コンテナは起動せず、"iris-main プログラム" で説明されているように、iris-main によってその理由 (永続的な %SYS 以外のデータがディレクトリ内に存在する) が標準出力に記録されます。

ここに示した例の場合、コンテナ iris21 内で実行される InterSystems IRIS インスタンスは、"永続的な %SYS ディレクトリの内容" に示されているファイルすべての永続ストレージ用のディレクトリとして、ホスト・パス /data/dur/iconfig (コンテナ内でのパスは /dur/iconfig) を使用するように構成されています。永続的な %SYS がホスト・ディレクトリ /data/dur/iconfig (コンテナ・ディレクトリ /dur/iconfig) にまだ存在しない場合は、インストール・ディレクトリからここにコピーされます。どちらの場合も、インスタンスの内部ポインタはコンテナ・ディレクトリ /dur/iconfig に設定されます。

永続的な %SYS を含む InterSystems IRIS コンテナを起動するさまざまな例については、"InterSystems IRIS コンテナの実行" を参照してください。

次の図は、コンテナ内と永続的な %SYS により複製されたマウントされた外部ストレージ (示したオプションで指定したとおり) の、InterSystems IRIS のインストール・ディレクトリおよびユーザ・データベースの関係を示しています。インストール・ディレクトリ外の 3 つのアプリケーション・データベースは、/data/dur/iconfig/db に複製されている一方、インストール・ディレクトリ内の /mgr の下の LOCALDB データベースは、同じ場所 (/data/dur/iconfig/mgr/localdb) に複製されています。

永続的な %SYS ディレクトリの場所を手動で確認する場合、またはこの場所をプログラムによって受け渡す場合は、以下のように 3 つのオプションがあります。

• コンテナ内でシェルを開き (例えば、docker exec -it container_name bash を使用して)、以下のいずれかを行います。

  echo $ISC_DATA_DIRECTORY
  
  iris list
  

  
  Note:

  iris コマンドについての詳細は、"InterSystems IRIS インスタンスの制御" を参照してください。

• InterSystems IRIS 内で、$SYSTEM.Util.InstallDirectory() または $SYSTEM.Util.GetEnviron(‘ISC_DATA_DIRECTORY’) を呼び出します。

ISC_DATA_DIRECTORY 環境変数を使用してコンテナが実行される場合は、指定されたボリュームが正常にマウントされた場合のみ、ポインタが永続的な %SYS ファイルに設定されます。

• ISC_DATA_DIRECTORY が指定されても、必要な --volume /external_host:/durable_storage オプションが docker run コマンドから省略されている場合、インスタンスは起動に失敗し、エラー・メッセージが生成されます。

• --volume オプションが含まれていても、Docker が指定ボリュームを正常にマウントできない場合、外部ストレージ・ディレクトリとボリュームがコンテナ内に作成されます。この場合、インスタンス・データが永続的な %SYS ディレクトリにコピーされます ("永続的な %SYS を使用した InterSystems IRIS コンテナの実行" の "ISC_DATA_DIRECTORY によって指定されている永続的な %SYS ディレクトリが存在しない場合" で説明されています)。

ISC_DATA_DIRECTORY が指定されていない場合、InterSystems IRIS インスタンスはコンテナ内のインスタンス固有のデータを使用するので、前のインスタンスのアップグレードとしては動作できません。

このため、永続的な %SYS を使用するには、InterSystems IRIS コンテナを実行するために使用するすべてのメソッドに、これら 2 つのオプションが組み込まれていることを確認する必要があります。

パフォーマンスと復元可能性の両方を高めるために、各 InterSystems IRIS インスタンスのプライマリおよびセカンダリのジャーナル・ディレクトリは 2 つの分離したファイル・システムに配置することをお勧めします。これらは、InterSystems IRIS の実行可能プログラム、インスタンスのシステム・データベース、および IRIS.WIJ ファイルをホストするファイル・システムとも別にしてください (オプションで、最後のものは 4 つ目のファイル・システムに配置します)。ただし、InterSystems IRIS のインストール後、プライマリとセカンダリのジャーナル・ディレクトリは同じパス (install-dir/mgr/journal) に設定されるので、永続的な %SYS の使用時は、両方のディレクトリが永続的な %SYS ディレクトリ内の /mgr/journal に設定される可能性があります。

"構成マージを使用した InterSystems IRIS の自動構成" で説明しているように、構成マージ・ファイルを使用して、導入に個別のファイル・システムを構成することもできます。コンテナの起動後、管理ポータル (後続のセクションを参照) を使用するか、CPF (iris.cpf) を編集することにより、プライマリ・ディレクトリとセカンダリ・ディレクトリの外部の場所を再構成できます (InterSystems IRIS インスタンスをアップグレードする新規イメージを実行する際に、再配置先のボリュームを必ず指定する限り)。

InterSystems IRIS のファイル・システムの分離に関する詳細は、"ファイル・システムの分離" を参照してください。

インターシステムズが提供する webgateway イメージは 3 種類あり、それぞれがコンテナ化された導入に Web サーバ・コンポーネントを提供します。

• webgateway イメージには、次のコンポーネントが含まれ、コンテナ内の示された場所に root によってインストールされます。

  • /opt/webgateway 内のインターシステムズの Web ゲートウェイ。

  • /etc/apache2 内の Apache Web サーバ。

• webgateway-nginx イメージには、次のコンポーネントが含まれ、root によってインストールされます。

  • /opt/webgateway 内のインターシステムズの Web ゲートウェイ。

  • /opt/nginx 内の Nginx Web サーバ。

• webgateway-lockeddown イメージは、非常に厳格な要件を満たすように設計されており、irisowner (UID 51773) によってインストール、所有、および実行される、次の非 root コンポーネントが含まれます。

  • /home/irisowner/webgateway にロックダウン・セキュリティでインストールされた、インターシステムズの Web ゲートウェイ。

  • /home/irisowner/apache にインストールされ、標準ポート 80 ではなく、ポート 52773 を使用するように構成された Apache Web サーバ。

  Note:

  非 root インストールとロックダウン・セキュリティの詳細は、"InterSystems IRIS コンテナのセキュリティ" を参照してください。

Web ゲートウェイの構成には Web ゲートウェイ管理ページが使用されますが、構成は CSP.ini ファイルに格納されます (ただし、InterSystems IRIS インスタンスの構成は iris.cpf ファイルに格納されます)。Web ゲートウェイは、いくつかの基本設定を含む既定の最小バージョンの CSP.ini ファイルと共にインストールされます。Web ゲートウェイ・コンテナの場合のみ、Web ゲートウェイとやり取りするように Web サーバを構成する CSP.conf ファイルが、Web サーバの構成に追加されます。CSP.ini ファイルの内容の詳細は、"Web ゲートウェイ構成ファイル (CSP.ini) パラメータ・リファレンス" を参照してください。Web ゲートウェイ・コンテナで提供される CSP.conf ファイルの内容の詳細は、"推奨オプション ： NSD を使用しない Apache API モジュール" および "Nginx での NSD の使用" を参照してください。

3 つのすべての webgateway イメージには、既定の最小バージョンの CSP.ini ファイルと Apache または Nginx 固有の CSP.conf ファイルの両方が (前述のリストで示した該当するディレクトリに) 含まれています。ただし、独自のバージョンのファイルまたは両方のファイルを提供してこれらを上書きすることもできます。初期バージョンの CSP.ini ファイルを準備するにはいくつかの方法があります。例えば、既存または以前の Web ゲートウェイ導入環境のファイルを変更して、それを Web ゲートウェイ・コンテナに使用できます。あるいは、1 つのコンテナで独自のファイルまたは提供されている基本的な既定のバージョンで起動し、管理ページを使用して必要に応じて構成を変更した後、構成ファイルをコピーして追加のコンテナでそれを使用することもできます。"Web ゲートウェイ・ガイド" では、Web ゲートウェイ構成に関する包括的な情報を提供しています。

Web ゲートウェイ・コンテナは、オプションで永続的な %SYS 機能のバージョンで実行することができます。これは、Web ゲートウェイの構成が格納されているコンテナ内の webgateway と呼ばれる永続的なデータ・ディレクトリを作成します ("Web ゲートウェイ・コンテナの実行オプション" を参照)。このオプションを使用すると、CSP.log ログ・ファイルと同様に、CSP.ini ファイルおよび CSP.conf ファイル (既定またはユーザ指定) がそのディレクトリにコピーされます。これによって、既存の構成を失うことなくコンテナをアップグレードできます。また、複数の Web ゲートウェイ構成を同時に更新することもできます。これについては、次のセクションで説明します。

専用の Web ゲートウェイ・コンテナの場合、Web ゲートウェイの構成は比較的シンプルで、InterSystems IRIS インスタンス専用の単一のサーバ・アクセス・プロファイルや、そのインスタンスが処理するアプリケーション専用のアプリケーション・アクセス・プロファイルが含まれます。このため、専用 Web ゲートウェイの再構成も、その管理ページにアクセスして必要な変更を加えるだけで簡単に行うことができます。

ただし、Web サーバ層のように、また共有管理ポータルへのアクセスのために、同じクラスタの一部として複数の Web ゲートウェイ・コンテナを導入する場合、その構成を同時に更新する方法が必要になる可能性もあります (特に、サーバ・アクセス・プロファイルとアプリケーション・アクセス・プロファイルで、InterSystems IRIS ノードを追加する場合やアプリケーション・パスを変更する場合など)。CSP.ini マージ機能は、そのための便利な方法を提供します。コンテナ作成時に独自の CSP.ini ファイルを指定し、"Web ゲートウェイ・コンテナの実行オプション" の説明に従って、マウントされた外部ボリュームでステージングすると、コンテナのファイル・システム、または永続的なデータ・ディレクトリ (存在する場合) のいずれかに一度コピーされます。その後で、ステージングしたファイルが元の場所に残っていて、そのファイルに Web ゲートウェイ・コンテナからアクセスできる場合、ファイルの更新は、[SYSTEM]/RELOAD=1 設定と共に、各 Web ゲートウェイ・インスタンスのアクティブな CSP.ini ファイルに自動的にマージされます (どちらかの場所で)。これにより、構成が 1 分以内に Web ゲートウェイによって再読み込みされます。このため、複数の Web ゲートウェイ・コンテナを導入する際、すべてのコンテナに対して、同じ外部ボリュームで同じステージングされる CSP.ini ファイルをマウントする場合、ステージングされるファイルを更新することで、すべてを同一かつ同時に再構成できます。この方法は、専用の Web ゲートウェイ、つまりアプリケーション接続を複数の InterSystems IRIS コンテナに分散している単一の Web ゲートウェイの再構成、または管理ポータル・アクセス用の共有 Web ゲートウェイの再構成にも同じように適切に機能します。

このマージ更新アプローチを使用する場合、関係する Web ゲートウェイ・コンテナの数に関係なく、他の方法によって (例えば、Web ゲートウェイ管理ページを使用して) インスタンスの CSP.ini ファイルが変更されないようにする措置を講じることが大切です。ファイルに変更を加える場合は、次のいずれかを実行します。

• 更新するフィールド以外のすべてを削除するなどして、他の方法によって変更したステージングされる CSP.ini ファイルからフィールドを削除します。

• 他の方法による更新をステージングされるファイルに適用します。例えば、管理ページを使用してファイルを変更した後、変更したファイルをステージング場所にコピーし、元のステージングされるファイルを上書きできます。ステージングされるファイルを複数のコンテナで使用する場合、これによって、1 つのインスタンスで変更をテストし、マージ更新によってそれらを残りのインスタンスに適用できます。

独自の CSP.conf ファイルを外部でステージングすると、複数の Web ゲートウェイ・コンテナに存在する Web サーバを前述の CSP.ini で説明したのと同じ方法で最新の状態に保つことができます。ファイルが、ステージングした元の場所にあり、Web ゲートウェイ・コンテナからアクセス可能である限り、各 Web ゲートウェイ・コンテナでその変更が監視され、変更が検出されると、適切なディレクトリにファイルが再コピーされて、Web サーバは構成を再読み込みして再起動します。これは、ステージングされた CSP.ini で Web ゲートウェイのサーバ・アクセス・プロファイルを更新したことによって、Web サーバに構成されているアプリケーション・パスも更新する必要がある場合に特に役立ちます。

Web ゲートウェイ・インスタンスの保護には、以下の 2 つの主要なタスクがあります。

• Web ゲートウェイのサーバ・アクセス・プロファイルに構成されている InterSystems IRIS インスタンスへの Web ゲートウェイ接続の保護。これには、少なくとも、ターゲット・インスタンスで既存のユーザ・アカウントを使用して InterSystems IRIS に対する認証を行う必要があります。ただし、TLS 暗号化の追加を強くお勧めします。このトピックの詳細は、"InterSystems IRIS への Web ゲートウェイ接続の保護" および "TLS を使用して InterSystems IRIS に接続するための Web ゲートウェイの構成" を参照してください。

  Note:

  また、Web クライアントと Web サーバ間の接続を TLS で保護することも強くお勧めします。

• Web ゲートウェイの管理ページへのアクセスの保護。これには、Web ゲートウェイに対する認証のほか、管理ページにアクセスできるホストの制限が必要です。このトピックの詳細は、"Web ゲートウェイの既定パラメータの構成" にある "Web ゲートウェイ管理ページの概要" および "セキュリティ" を参照してください。

Web ゲートウェイ・コンテナ (および既定で、ローカルにインストールされている Web ゲートウェイ) の既定の CSP.ini では、事前定義のユーザ・アカウントである CSPSystem がこれら両方の目的で使用されます。ただし、いずれの目的にも任意の認証情報を使用できます。InterSystems IRIS インスタンスへの接続を保護する際に、各サーバ・アクセス・プロファイルに構成した認証情報がその特定のインスタンスで有効である必要があります。そうでなければ、いずれの認証情報セットに対しても制限がない状態になります。また、CSPSystem の代わりに、その特定の目的で作成したアカウントを使用すると、認証情報に関する情報をより厳格に制限できるようになります。

"複数の Web ゲートウェイ・コンテナの同期された再構成" で説明しているように、複数の InterSystems IRIS インスタンスとやり取りする複数の Web ゲートウェイが含まれるクラスタ化された構成を導入する場合、InterSystems IRIS へのすべての接続に 1 つの認証情報セットを使用し、Web ゲートウェイへのすべての管理アクセスに別の認証情報セットを使用すると便利です (ただし、異なるセットを使用することで認証情報の再利用が減り、セキュリティは強化されます)。これを実装するための、かなり便利で、(他の予防策が守られている場合) かなり安全な方法は以下のとおりです。

• 構成マージの [Actions] パラメータ ("構成マージを使用した InterSystems IRIS の自動構成" の "セキュリティ・オブジェクトの作成、変更、削除" を参照) を使用して InterSystems IRIS を導入し、Web ゲートウェイの認証専用のアカウントを作成して、パスワードは PasswordHash パラメータを使用して暗号化します。継続的な監視とマージの必要性に合わせて、マウントされた外部ボリュームでマージ・ファイルをステージングします。

• 以下を指定するカスタムの CSP.ini ファイルで Web ゲートウェイ・コンテナを導入します。

  • サーバ・アクセス・プロファイル内の、InterSystems IRIS の導入時に作成された Web ゲートウェイへのアクセスの認証情報

  • 管理ページへのアクセスのための、別の認証情報セット

  • 管理ページにアクセスできる限定された IP アドレスのセット

  継続的な監視とマージの必要性に合わせて、マウントされた外部ボリュームで CSP.ini ファイルをステージングします。

CPF マージ・ファイルおよび CSP.ini ファイルを継続的に監視およびマージすることで、後で CSP.ini マージ機能を使用して、Web ゲートウェイ・コンテナの同期再構成を行うことができます。これには、両方のサーバ・アクセス認証情報 (InterSystems IRIS コンテナと Web ゲートウェイ・コンテナの両方) および Web ゲートウェイ管理の認証情報の定期的なパスワード変更や、InterSystems IRIS インスタンスでの新規アカウントの定期的な作成、およびそれに応じた CSP.ini の更新といったセキュリティのベスト・プラクティスが含まれます。

以下に、iris-main のオプションを使用して InterSystems IRIS コンテナを起動するための docker run コマンドの例を示します。

• "InterSystems IRIS コンテナのライセンス・キー" で説明しているように、インスタンスが動作できるように、必要な InterSystems IRIS ライセンス・キーをコンテナ内に取り込む必要があります。下に示す例は、以下を実行します。

  • インスタンスの既定のスーパーサーバのポート (1972) をホストのポート 9092 に公開します。

  • 永続的な %SYS の必要なオプションを含めます ("永続的な %SYS が指定され、マウントされていることの確認" を参照)。

  • iris-main -key オプションを使用します。ここで、ライセンス・キーは、永続的な %SYS ディレクトリ用にマウントされたボリューム上の key/ ディレクトリ (つまり、コンテナ内の外部ストレージ /dur/key/ の /data/durable/key/) に置かれ、InterSystems IRIS インスタンスの起動前に、永続的な %SYS ディレクトリ内の mgr/ ディレクトリ (コンテナ内の外部ストレージ /dur/iconfig/mgr/ の /data/durable/iconfig/mgr/) にコピーされます。ライセンス・キーは mgr/ ディレクトリ内にあるため、インスタンスの起動時に自動的に有効になります。

  docker run --name iris11 --detach --publish 9092:1972
    --volume /data/durable:/dur 
    --env ISC_DATA_DIRECTORY=/dur/iris_conf.d
    intersystems/iris:latest-em --key /dur/key/iris.key
  

  

• この例では、永続的なデータ・ボリュームでステージングされ、InterSystems IRIS インスタンスの最初の起動前にそのインスタンスの CPF にマージされる設定が含まれる構成マージ・ファイルを追加しています ("InterSystems IRIS コンテナの自動導入" を参照)。これは例えば、"コンテナ化された InterSystems IRIS のファイル・システムの分離" で説明しているように、既定では永続的な %SYS ツリー内で同一のディレクトリであるインスタンスのプライマリおよび代替ジャーナル・ディレクトリ (CPF 内の [Journal]/CurrentDirectory および AlternateDirectory) が別個のファイル・システム上に配置されるよう再構成するために使用できます。

  docker run --name iris17 --detach --publish 9092:1972 
    --volume /data/durable:/dur 
    --env ISC_DATA_DIRECTORY=/dur/iris_conf.d
    --env ISC_CPF_MERGE_FILE=/dur/merge/merge.cpf intersystems/iris:latest-em 
    --key /dur/key/iris.key 
  

  

  ステージング・ディレクトリは、この場合はどちらも永続的な %SYS に対してマウントされたボリュームに配置されており、これらのディレクトリが同じであるか、同じライセンスを含む必要があります。

以下のスクリプトは、テストを目的として InterSystems IRIS コンテナをすばやく作成して起動するために記述されています。このスクリプトには、"InterSystems IRIS コンテナのライセンス・キー" で説明しているように、ライセンス・キー内でコピーを行うための iris-main --key オプションが組み込まれています。

#!/bin/bash
# script for quick demo and quick InterSystems IRIS image testing

# Definitions to toggle_________________________________________
container_image="intersystems/iris:latest-em"

# the docker run command
docker run -d 
  --name iris 
  --hostname iris 
# expose default superserver port 
  -p 9091:1972 
# mount durable %SYS volume
  -v /data/durable:/dur 
# specify durable %SYS directory and CPF merge file
  --env ISC_DATA_DIRECTORY=/dur/iris_conf.d
  --env ISC_CPF_MERGE_FILE=/dur/merge/merge.cpf
# enable allocation of huge pages
  --cap-add IPC_LOCK 
  $container_image 
  --key /dur/key/iris.key 

Docker Compose は、複数コンテナの Docker アプリケーションを定義および実行するツールであり、Docker とのコマンド行でのやり取りに代わる方法を提供します。Compose を使用するには、作成、起動、および管理するコンテナの仕様が含まれる docker-compose.yml を作成してから、docker-compose コマンドを使用します。詳細は、Docker ドキュメンテーションの "Overview of Docker ComposeOpens in a new tab" をまずは参照してください。

以下は compose.yml ファイルの例です。前述のスクリプトと同様に、このファイルにはこのドキュメントで説明している要素のみが含まれています。

version: '3.2'

services:
  iris:
    image: intersystems/iris:latest-em
    command:  --key /dur/key/iris.key
    hostname: iris
    ports:
    # the default superserver port
    - "9091:1972"
    volumes:
    # the durable %SYS volume
    - /data/durable:/dur
    environment:
    # the durable %SYS directory
    - ISC_DATA_DIRECTORY=/dur/iris_conf.d
    # the CPF merge file
    - ISC_CPF_MERGE_FILE=/dur/merge/merge.cpf

プロダクション内で、複数の Web ゲートウェイ・コンテナを含む複数コンテナの InterSystems IRIS クラスタを導入するには、InterSystems Kubernetes Operator (IKO) を使用する方法をお勧めします ("InterSystems IRIS コンテナの自動導入" を参照)。バージョン 3.6 の IKO では、管理ポータルへのアクセス専用の Web ゲートウェイ・コンテナの導入 (多対多アプローチ) は、各 InterSystems IRIS ポッドにサイドカー・コンテナとして追加することで実行されます。詳細は、"InterSystems Kubernetes Operator の使用Opens in a new tab" を参照してください。

開発とテストを目的とした、InterSystems IRIS コンテナと Web ゲートウェイ・コンテナの導入には、以下のような 3 つの基本的な方法があります。

• Docker Compose およびその他のスクリプト作成ツール

• Kubernetes

• InterSystems IRIS インスタンスの他に、Web ゲートウェイ・インスタンスと Web サーバを含むユーザ作成の InterSystems IRIS イメージ。(ユーザが作成する InterSystems IRIS イメージの一般的な説明は、"InterSystems IRIS イメージの作成" を参照してください。)

これらの方法の例は、https://github.com/intersystems-community/webgateway-examples/tree/masterOpens in a new tab を参照してください。必要なすべてのファイルといくつかの有用なスクリプトも参照できます。このセクションの残りの部分では、コマンド行で Web ゲートウェイ・コンテナを実行する際にのみ使用可能なオプションについて説明します。

Web ゲートウェイ・コンテナの作成および起動時に唯一必要なオプションは、以下のコマンドに示すとおり、ホスト・ポートへのコンテナ・ポート 80 と 443 の公開です。これによって、その他のエンティティが Web ゲートウェイと Web サーバにアクセスできます。

docker run -d --publish 8080:80 --publish 4443:443 
  containers.intersystems.com/intersystems/webgateway:latest-em

以下はオプションです。

• 永続的なデータ・ディレクトリ — Web ゲートウェイの構成ファイルが格納されているコンテナ内に webgateway と呼ばれる永続的なデータ・ディレクトリを作成するには、--volume オプションを使用して永続データ・ボリュームをマウントし、ISC_DATA_DIRECTORY 環境変数を使用してコンテナ内でのそのディレクトリの場所を指定します ("Web ゲートウェイの構成" を参照)。例えば、次のコマンドは、コンテナ内の /dur/webgateway と、ホストのファイル・システム上の /nethome/user21/dur/webgateway に永続的なデータ・ディレクトリを作成します。

  docker run -d --name wg11 --publish 80:80 --publish 443:443
    --volume /nethome/user21/dur:/dur --env ISC_DATA_DIRECTORY=/dur 
     containers.intersystems.com/intersystems/webgateway:latest-em
  

  

  これは、InterSystems IRIS コンテナの永続的な %SYS を有効にする手順と同等です。これらのオプションと永続的な %SYS の全般的な使用法は、"永続インスタンス・データを保存するための永続的な %SYS" を参照してください。

  Important:

  webgateway-lockeddown イメージには、ユーザ irisowner (UID 51773) によってインストールおよび所有されている Web ゲートウェイと Web サーバが含まれているため、ロック・ダウン・コンテナの永続的なデータ・ディレクトリに指定するホストのファイル・システムの場所は、irisowner によって書き込み可能である必要があります (これを有効にするには、多くの場合、root 特権が必要です)。

  永続的なデータのオプションで webgateway コンテナを実行すると、以下の状況が生じます。

  • 指定された外部ボリュームがマウントされます。

  • ISC_DATA_DIRECTORY で指定された場所に webgateway ディレクトリが存在しない場合、Web ゲートウェイで使用できるように、次のようにこれが作成され、そこに構成ファイルがコピーされます。

    • 提供した構成ファイルは、コンテナ内の既定の場所へのリンクと共に、webgateway ディレクトリにコピーされます。

    • 提供していない構成ファイルは、コンテナ内の既定の場所から、それらの場所へのリンクと共にコピーされます。

  • webgateway ディレクトリが既に ISC_DATA_DIRECTORY で指定された場所に存在する場合、これは、前の webgateway コンテナのデータ・ディレクトリと見なされます。

    • これに期待される Web ゲートウェイ構成ファイルが含まれる場合、これらはコンテナ内のそれらの場所にリンクされ、Web ゲートウェイにより使用されます。ユーザが提供する構成ファイルを指定するオプション (以下で説明) は無視されます。

      Important:

      既存の永続的な webgateway ディレクトリを使用して webgateway コンテナを導入する際は、独自の構成ファイル (以下で説明) を提供できないため、同じ操作でコンテナ化された Web ゲートウェイをアップグレードおよび再構成することはできません。代わりに、前のコンテナの永続的な webgateway ディレクトリを使用して新しいバージョンのコンテナを導入することから開始し、必要に応じて Web ゲートウェイを再構成します。

    • 期待される 1 つ以上の Web ゲートウェイ構成ファイルが存在しない場合は、webgateway が破損していると見なされます。エラーがログに記録され、コンテナは起動に失敗します。

    Important:

    webgateway-lockeddown イメージを使用して、永続データ・ディレクトリを使用する webgateway コンテナをバージョン 2021.2 以降にアップグレードする場合、既存の永続ディレクトリを、ユーザ irisowner によって書き込み可能にする必要があります。

  コンテナ内の Web ゲートウェイにアクセスできる書き込み可能な永続ストレージ上の場所を指定するのに ISC_DATA_DIRECTORY 変数を使用しない場合、既定で、永続的なデータ・ディレクトリは作成されず、構成ファイルは既定の場所に維持されます (前述のとおり)。

• ユーザ定義の構成ファイル — 独自の CSP.ini ファイルを提供するには、--volume オプションを使用して永続データ・ボリューム (ISC_DATA_DIRECTORY によって指定された永続的なデータ・ディレクトリ・ボリュームが使用されている場合、それとは別個の) をマウントしてそのボリューム上でファイルをステージングし、ISC_CSP_INI_FILE 環境変数を使用してその場所を示します。前述のとおり、永続的な webgateway ディレクトリも作成する場合は、このファイルがそのディレクトリにコピーされ、コンテナ内の元の場所にリンクされます。このディレクトリを作成しない場合は、このファイルは元の場所にコピーされ、既定のファイルが上書きされます。

  Important:

  マージ更新アプローチを使用する場合 ("Web ゲートウェイの構成" を参照)、ステージングされる CSP.ini ファイルが元の場所に維持され、コンテナからアクセスできる必要があります。

  独自の CSP.conf ファイルを提供するには、同じことを実行し、ISC_CSP_CONF_FILE 環境変数を使用してその場所を指定します。例えば、永続的な webgateway ディレクトリを作成し、独自の CSP.ini および CSP.conf ファイルを Web ゲートウェイの構成に使用するよう指定するには、次のようなコマンドを使用します。

  docker run -d --name wg11 --publish 80:80 --publish 443:443
    --volume /nethome/user21/dur:/dur --env ISC_DATA_DIRECTORY=/dur 
    --volume /nethome/user21/config:/config --env ISC_CSP_INI_FILE=/config/CSP.ini 
    --env ISC_CSP_CONF_FILE=/config/CSP.conf 
    containers.intersystems.com/intersystems/webgateway:latest-em
  

  

  これらの変数のいずれかが指定されていない場合は、既定で、コンテナ内にある基本の既定ファイルを使用します。

• Apache Web サーバの SSL モジュールを有効にするには、(イメージの仕様に従って) --ssl エントリポイント・オプションを追加します。オプションが省略された場合の既定では、Apache SSL モジュールは有効化されません。TLS を有効にする手順の詳細は、"Web ゲートウェイ・コンテナでの Web サーバに対する TLS 構成" を参照してください。

• Web ゲートウェイ・サーバを Apache に特定するには、--server server-name エントリポイント・オプションを使用します。オプションが省略された場合の既定では、コンテナの ID を使用します (Docker の --hostname オプションが含まれていない場合。含まれている場合は指定された値が使用されます)。

以下は、説明したすべてのオプションを使用した docker run コマンドの使用例です。

docker run -d --name wg11 --publish 80:80 --publish 443:443
  --volume /nethome/user21/dur:/dur --env ISC_DATA_DIRECTORY=/dur 
  --env ISC_CSP_INI_FILE=/dur/CSP.ini --env ISC_CSP_CONF_FILE=/dur/CSP.conf 
  containers.intersystems.com/intersystems/webgateway:latest-em
  --ssl --server webgateway11

以下の手順では、Web ゲートウェイ・コンテナ内で Web サーバに TLS を構成する方法を示します。webgateway または webgateway-lockeddown イメージを使用していない場合、特定のセットアップやユース・ケースに応じて調整が必要なことがあります。

• 永続的な Web ゲートウェイ・ディレクトリの準備

  • プロダクションで構成ファイル CSP.ini と CSP.conf を含む永続的なデータ・ディレクトリをセットアップすることをお勧めします。これらのファイルはコンテナの永続的な構成を格納し、機能的な Web ゲートウェイ・コンテナには不可欠です。これらを永続的なデータ・ディレクトリに収容することで、コンテナの存続期間を超えてファイルを維持することができます。

  • 永続的なデータ・ディレクトリが存在しない場合は、構成ファイルを含む永続ボリュームを作成する必要があります。導入時に、コンテナは永続的なデータ・ディレクトリを作成します。これらのセットアップの詳細は、こちらのドキュメントOpens in a new tabを参照してください。

• TLS 証明書とキー・ファイルの追加

  • TLS 証明書とキー・ファイルを永続的なデータ・ディレクトリに配置します。

  • コンテナのファイルシステム内のファイル名と場所を書き留めてください。これらのパスは、CSP.conf 構成ファイルで参照する必要があります。

• TLS のための構成の更新

  • 永続的なデータ・ディレクトリで、 CSP.conf ファイルを開きます。

  • 必要な TLS 構成指示文を含めるようにファイルを更新します。Apache Web サーバを含む Web ゲートウェイ・コンテナ・イメージを使用している場合は、Apache の "SSL/TLS documentationOpens in a new tab" をガイドとして参照してください。

    • 利用できる場合、default-ssl.conf や httpd-ssl.conf などのサンプル構成がガイダンスとして役立つこともあります。ただし、これらのファイルの名前や可用性は、Apache のインストールによって異なります。まずは、Apache の公式ドキュメントを参照してください。

• –ssl ENTRYPOINT オプションの追加

  • Web ゲートウェイ・コンテナを実行する際 (例えば、docker run または docker-compose YAML ファイルを使用して) は、--ssl ENTRYPOINT オプションを含めます。

    • コンテナを起動する前に、コンテナを完全に構成する必要があります。コンテナの起動後に構成を変更した場合は、コンテナを再起動して、変更を有効にする必要があります。

UNIX および Linux への InterSystems IRIS インスタンスの自動インストールを構成する際に使用できる多数のインストール・パラメータがあります。これらの使用法は、"InterSystems IRIS の自動インストール" を参照してください。"InterSystems IRIS イメージの作成" で説明しているように、インターシステムズ提供のイメージを基本として使用するのではなく、Dockerfile でキットから InterSystems IRIS インスタンスをインストールする場合、コンテナの実行時環境で環境変数として必要なインストール・パラメータもイメージに組み込む必要があります。これらの変数がないと、イメージからのコンテナの作成は失敗します。これらの変数は、インターシステムズ提供のすべてのイメージに含まれています。これらの変数を、インターシステムズによって設定されている値と共に、以下のテーブルに示します。

InterSystems IRIS イメージをビルドする際に、インターシステムズでは SYS.Container API を使用して、インストールした InterSystems IRIS インスタンスをコンテナ・イメージに安全にシリアル化できる状態にします。このクラスには、個々に使用できるメソッドがいくつか含まれていますが、それらのうち、SYS.Container.QuiesceForBundling()Opens in a new tab は、1 回の処理で必要なメソッドすべてを呼び出すため、インターシステムズではイメージの作成にこれを使用しています。このアプローチを使用することをベスト・プラクティスとしてお勧めします。Linux シェル/ObjectScript 境界を越えてのエラーチェックは難しいうえ、InterSystems IRIS から通知なしのエラーが生じるリスクがあるためです。呼び出しが少ないほど、このリスクも小さくなります。

SYS.Container コードは、Linux プラットフォームにインストールされたあらゆる InterSystems IRIS インスタンスに含まれており、完全に表示可能です。ドキュメントについては、"クラス・リファレンス" を参照してください。メソッドには以下のようなものがあります。

• SYS.Container.QuiesceForBundling()Opens in a new tab

  InterSystems IRIS をコンテナ・イメージに安全にシリアル化できる状態にするために必要なすべての ObjectScript コードを呼び出します。

• SYS.Container.ChangePassword()Opens in a new tab

  1 つ以上のロールが割り当てられている有効なユーザ・アカウントすべてに対するパスワードを変更します。"認証とパスワード" で説明されているように、iris-main --password-file オプションとパスワード変更スクリプトによって呼び出されます。

• SYS.Container.ChangeGatewayMgrPassword()Opens in a new tab

  Web ゲートウェイ管理パスワードを変更します ("Web ゲートウェイ管理ページの概要" を参照)。"認証とパスワード" で説明されているように、iris-main --password-file オプションとパスワード変更スクリプトによって呼び出されます。

• SYS.Container.ForcePasswordChange()Opens in a new tab

  1 つ以上のロールが割り当てられている有効なユーザ・アカウントで [次回ログイン時にパスワード変更] を設定します ("ユーザ・アカウントのプロパティ" を参照)。

• SYS.Container.KillPassword()Opens in a new tab

  指定したユーザに対してパスワードベースのログインを無効にします。その他の形式の認証 ("認証 ： 身元の確認" を参照) は有効のままになります。

• SYS.Container.EnableOSAuthentication()Opens in a new tab

  インスタンスに対し OS ベースの認証を有効にします ("オペレーティング・システム・ベースの認証について" を参照してください)。

• SYS.Container.SetNeverExpires()Opens in a new tab

  指定したユーザ・アカウントに [アカウントを有効期限切れにしない] を設定します。これを設定しないと、イメージに設定してから 90 日以上経過したユーザ・アカウントは期限切れになります ("ユーザのプロパティ" を参照してください)。

• SYS.Container.PreventFailoverMessage()Opens in a new tab

  新たに起動したコンテナ内のインスタンスからのジャーナル・ロールオーバー・メッセージを阻止します。

• SYS.Container.PreventJournalRolloverMessage()Opens in a new tab

  インスタンスが実行されているホストの名前が前回の実行時に格納されたホスト名と同じではないためにインスタンスが警告を発しないようにします。

• SYS.Container.SetMonitorStateOK()Opens in a new tab

  システム・モニタからのレベル 1 およびレベル 2 のアラートを削除し、レベル 3 のアラートがある場合はエラーを生成します ("システム・モニタ・ツールの概要" を参照してください)。

一般的なのは、インスタンスの起動時に、iris terminal コマンドを介してこれらのメソッドを呼び出すことで、インターシステムズが提供する InterSystems IRIS イメージ ("InterSystems IRIS イメージの作成" を参照) に基づく Dockerfile にこれらを含めるアプローチです。

RUN iris start $ISC_PACKAGE_INSTANCENAME \
    && iris terminal $ISC_PACKAGE_INSTANCENAME -U %SYS "##class(SYS.Container).PreventJournalRolloverMessage()" 
    && iris terminal $ISC_PACKAGE_INSTANCENAME -U %SYS "##class(SYS.Container).SetMonitorStateOK()" 
    && iris terminal $ISC_PACKAGE_INSTANCENAME -U %SYS "##class(SYS.Container).QuiesceForBundling()"
    && iris terminal $ISC_PACKAGE_INSTANCENAME quietly