#Microsoft Windows

バージョン2024.2 プレビューキット以降、Windows キットにはスタジオが含まれなくなります。つまり、このキットを使用した新規インストールではスタジオがインストールされません。既存のインスタンスをバージョン 2024.2以降にアップグレードした場合は、インスタンスの bin ディレクトリからスタジオが削除されます。

#InterSystems公式 #VSCode #Microsoft Windows #スタジオ #開発環境

0 0

0 253

記事 Mihoko Iijima · 4月 2, 2021 2m read

コンソールログに "Failed to allocate xxxMB shared memory using large pages..." のエラーメッセージが出ているとき

これは InterSystems FAQ サイトの記事です。

MM/DD-hh:mm:ss:938 ( 0) 1 Failed to allocate xxxMB shared memory using large pages. Switching to small pages.
MM/DD-hh:mm:ss:938 ( 0) 0 Allocated xxxMB shared memory: yyyMB global buffers, zzzMB routine buffers

コンソールログ（cconsole.log/messages.log）に上記のようなメッセージがある場合は、Large Page でのメモリ確保に失敗して、Small Page でメモリを確保したことを示しています。

Allocated xxxMB が設定サイズと同じ場合、Small Pageでメモリ確保ができていますので、設定サイズを減らす必要はありません。

このメッセージは、起動時に十分な空きメモリが連続領域で確保されていないために発生しています。

デフォルトの設定では、WindowsOS が管理するメモリ領域の中で Large Page という領域にメモリを連続的に確保します。

#Caché #Ensemble #HealthShare #InterSystems IRIS #InterSystems IRIS for Health #Microsoft Windows #システム管理 #ヒントとコツ

0 0

0 1962

記事 Toshihiko Minamoto · 3月 1, 2021 6m read

IRISのInteroperability機能を使ったWindows共有フォルダでのファイル連携

開発者の皆さん
こんにちは。
Windows共有しているリモートサーバに出力されたファイルでデータ連携する際、セキュリティ上、資格情報が必要となるケースが良くあるかと思います。いままでCachéで連携していた時には%ZSTARTルーチンや常駐プロセスのルーチンにて「net useコマンド」を実行されていたかと思いますが、IRISではInteroperability機能が使用できますので、前回の記事で作成したビジネスサービスクラスを元に、資格情報を使ってWindows共有フォルダにアクセスできる機能を追加したいと思います。

仕組み

ビジネスサービスが起動、停止する際に呼び出されるOnInit()、OnTearDown()メソッドにnet useコマンドを埋め込み、指定されている資格情報を使ってnet useコマンドで共有フォルダへの接続、切断を行います。

認証情報設定パラメータ追加

ビジネスサービスの設定画面で認証情報を選択できるよう、以下のようにCredentialsプロパティ、SETTINGSパラメータをTest.BS.ImportMasterクラスに設定します。

#InterSystems IRIS #Microsoft Windows #ObjectScript #相互運用性

1 0

0 595

記事 Toshihiko Minamoto · 12月 25, 2020 8m read

Docker for Windows で InterSystems IRIS コンテナを使用する

InterSystems は自社が提供する InterSystems IRIS の Dockerイメージについて、Linux 環境での使用のみをサポートしています。 Docker for Windows は Linux プラットフォームのようにコンテナをネイティブプロセスとして実行するのではなく、Windows の仮想化機能である Hyper-V で実行される Linux VM を作成してコンテナをホストします。このような追加レイヤーによって複雑度が増しているため、InterSystems は現時点で Docker for Windows をサポートすることができません。

ただし、テストやその他の特殊な目的のために InterSystems の IRIS ベースのコンテナを Docker for Windows 環境で実行する必要があることは私たちも理解しています。この記事では、InterSystems が提供するコンテナイメージの使用に関して InterSystems が認識している Docker for Windows と Docker for Linux の違いについて説明します。その他にも予期しない問題が発生する可能性はあります。 Windows プラットフォームで InterSystems IRIS のイメージとコンテナを使用する場合は、参考のために Docker ドキュメント（特に「Getting started with Docker for Windows」）にアクセスできることを確認してください。

Docker for Windows 環境のコンテナで外部永続ストレージを操作する場合は、Windows および Linux のファイルシステムとファイル操作の両方が関係してくるため、ここでは主にストレージに関係する違いを説明しています。

InterSystems が提供するイメージを使用して InterSystems IRIS を Docker コンテナで実行する場合の一般的な情報については、「Running InterSystems IRIS in Docker Containers」と「First Look: InterSystems IRIS in Docker Containers」を参照してください。

ディスクドライブを共有する

Windows では Docker が存在するディスクドライブを共有し、Docker に操作対象となるすべてのストレージへのアクセスを許可する必要があります。 1 台以上のドライブを共有するには、次の手順に従ってください（この手順は前の項目の手順と組み合わせることができます）。

システムトレイの Docker アイコンを右クリックし、[Settings ...] を選択します。
[Shared Drives] タブを選択し、ストレージが配置されているドライブを選択してから [Apply] をクリックします。ドライブがすでに選択されている場合は（デフォルトでは C ドライブが選択されています）、チェックボックスをオフにして [Apply] をクリックし、ドライブを選択してから [Apply] をもう一度クリックします。
プロンプトが表示されたら、ログイン資格情報を入力します。
変更を適用すると、Docker が自動的に再起動します。再起動しなかった場合はシステムトレイの Docker アイコンを右クリックし、[Restart] を選択します。

コンテナ内で外部ファイルをコピーする

Docker を使用する場合は、一般的には外部ファイルシステム内のディレクトリをコンテナ内のボリュームとしてマウントし、それをコンテナ内のソフトウェアが必要とするすべての外部ファイル用の場所として使用するのが便利です。例えば、あるボリュームをマウントし、iris-main プログラムの --key オプションとパスワード変更スクリプトがそれぞれアクセスする外部ディレクトリにある InterSystems IRIS のライセンスキー（iris.key）や所定の InterSystems IRIS のパスワードを含むファイルを配置できます（「Running InterSystems IRIS in Containers」の「The iris-main Program」と「Changing the InterSystems IRIS Password」を参照してください）。ただし、Docker for Windowsではファイル操作とアクセス許可の違いにより、マウントされた外部ボリューム上のファイルがコンテナ内のプログラムによって適切に使用されない場合があります。多くの場合はプログラムでコンテナ内のファイルをコピーしてからそのコピーを使用することで、アクセス許可の問題を解決できます。

例えば、**iris-main --before **オプションはコンテナ内の InterSystems IRIS インスタンスのパスワードを変更するためによく使用されます。以下に例を示します。

--before "changePassword.sh /external/password.txt"

この方法を使っても Windows で意図したとおりにパスワードを変更できない場合は、以下を試してください。

--before "cp /external/password.txt /external/password_copied.txt && \
changePassword.sh /external/password_copied.txt"

名前付きボリュームを使用する

動的に変更されるファイルが多数存在する場合、個別にマウントしてすべてのファイルをコピーできたとしても、コンテナ内に Windows ファイルシステムを直接マウントすると問題が発生する可能性があります。 InterSystems IRIS の場合、これは特にインスタンス固有データを永続的に保管するための Durable %SYS 機能（「Running InterSystems IRIS in Containers」の「Durable %SYS for Persistent Instance Data」を参照してください）とジャーナルファイルの保管の両方に当てはまります。この問題は名前付きボリュームをマウントすることで解決できます。名前付きボリュームは、システム上のコンテナをホストしている Linux VM のファイルシステムにマウントポイントを持つストレージボリュームです。 VM はファイルシステムベースであるため、このようなボリュームの内容は Docker やシステムがダウンした場合でも VM の他の部分と一緒に Windows ディスクに保存されます。

例えば InterSystems IRIS コンテナを実行中に Durable %SYS を有効化する場合、一般的には外部ボリュームをマウントし、--env オプションを使用して ISC_DATA_DIRECTORY 環境変数をそのボリュームの場所に設定します。以下に例を示します。

docker run ... \
--volume /nethome/pmartinez/iris_external:/external \
--env ISC_DATA_DIRECTORY=/external/durable/

この方法は Docker for Windows では使えません。代わりに、docker volume create コマンドで名前付きボリュームを作成し、Durable %SYS ディレクトリをそこに配置する必要があります。また、Linux とは異なり、ISC_DATA_DIRECTORY には最上位の Durable %SYS ディレクトリである /irissys を指定する必要があります。したがって、Windows では次のようなオプションになります。

docker volume create durable
docker run ... \
--volume durable:/durable \
--env ISC_DATA_DIRECTORY=/durable/irissys/

インスタンスのジャーナルファイルにこの方法を使用するには、上記の Durable %SYS の例と同じように名前付きボリュームを作成してマウントし、任意の構成方法（^JOURNAL ルーチン、管理ポータルの [Journal Settings] ページ、または iris.cpf ファイル）を使用して現在および代替のジャーナルディレクトリを名前付きボリュームの場所に設定します。現在のジャーナルディレクトリと代替のジャーナルディレクトリを分離するには、それぞれに対応する名前付きボリュームを作成してマウントする必要があります（この方法は_十分に検証されておらず_、ジャーナルファイルが危険にさらされる可能性がありますのでご注意ください）。

VM 内の名前付きボリュームにある Linux ファイルシステムのマウントポイントを検出するには、次のように docker volume inspect コマンドを使用します。

docker volume inspect durable_data
[
{
"CreatedAt": "2018-05-04T12:11:54Z",
"Driver": "local",
"Labels": null,
"Mountpoint": "/var/lib/docker/volumes/durable_data/_data",
"Name": "durable_data",
"Options": null,
"Scope": "local"
}
]

コマンドの比較

上記の内容をすべて考慮し、「First Look: InterSystems IRIS in Docker Containers」の「Run and Investigate the InterSystems IRIS-based Container」に記載されている Linux プラットフォームでの実行を想定した最終的な docker run コマンドと Docker for Windows を使用した同等の docker run コマンドを比較すると次のようになります。

Linux

$ docker run --name iris3 --detach --publish 52773:52773 \
--volume /nethome/pmartinez/iris_external:/external \
--env ISC_DATA_DIRECTORY=/external/durable \
--env ICM_SENTINEL_DIR=/external iris3:test --key /external/iris.key \
--before "changePassword.sh /external/password.txt"

Windows

C:\Users\pmartinez>docker volume create durable
C:\Users\pmartinez>docker volume create journals
C:\Users\pmartinez>docker run --name iris3 --detach --publish 52773:52773 \
--volume durable:/durable\
--volume journals:/journals
--env ISC_DATA_DIRECTORY=/durable/irissys \
--env ICM_SENTINEL_DIR=/durable iris3:test --key /external/iris.key \
--before "cp /external/password.txt /external/password_copied.txt && \
changePassword.sh /durable/password_copied.txt"

Docker for Windows での InterSystems 提供コンテナの使用に関する情報をご提供可能な方は、こちらにコメントを追加するか、記事の投稿をお願いします！

#InterSystems IRIS #Docker #Microsoft Windows #コンテナ化 #デプロイ

0 0

0 647

記事 Toshihiko Minamoto · 12月 16, 2020 17m read

Windows10 ホストで実行される Hyper-V Ubuntu 仮想マシンで Docker を使用できるように環境を設定する

今回は、InterSystems IRIS に特有のことではなく、職場で Windows 10 Pro または Enterprise を搭載した PC またはノートパソコンがサーバーとして使用されている環境で Docker を使用する場合に重要と思われる点について触れたいと思います。

ご存知かと思いますが、コンテナテクノロジーは基本的に Linux の世界で生まれ、最近では Linux のホストで使用されており、その最大のポテンシャルを伺わせています。 Windows を普段から使用するユーザーの間では、Microsoft と Docker 両社によるここ数年の重大な試みにより、Windows のシステムで Linux イメージを基にコンテナを実行することがとても簡単になったと理解されています。しかし、生産システムでの使用がサポートされておらず、それが大きな問題となっています。特に、Windows と Linux のファイルシステムに大きな違いがあるため、安心してホストシステム内でコンテナの外に持続データを保管するということができないのです。ついには、コンテナを実行するために、_Docker for Windows _自体で Linux の小さな仮想マシン (MobiLinux) が使用されるようになり、Windows ユーザーに対しては透過的に実行されます。また、先ほど述べたように、データベースの存続がコンテナよりも短くて構わないのであれば、パーフェクトに動作します。

では、何が言いたいかというと、問題を回避して処理を単純化するには、完全な Linux システムが必要になるが、Windows ベースのサーバーを使用していると、仮想マシンを使用する以外に方法がない場合が多い、ということです。少なくとも、Windows の WSL2 がリリースされるまでの話ですが、それはまた別の機会に触れたいと思います。もちろん、十分堅牢に動作するまでは時間がかかるでしょう。

この記事では、必要に応じて、Windows サーバーの Ubuntu システムで Docker コンテナを使用できる環境をインストールする方法について分かりやすく説明します。それでは、始めましょう。

1. Hyper-V を有効にする

まだ有効にしていない方は、Windows Featuresを追加し、Hyper-V を有効にしてください。そして再起動します (現在の私のロケールにより、テキストはスペイン語になっています。ドン・キホーテの言語をご存知ない方は手順を参照しながら「解明」できることを願っています 😉 )

2. Hyper-V 上で Ubuntu の仮想マシンを作成する

これ以上簡単に仮想マシン (VM) を作成する方法はないと思います。 Hyper-V Manager のウィンドウを開き、 Quick Create... オプション (画面一番上近く) を選択します。そして、画面に表示されている Ubuntu バージョンのいずれかを使って仮想マシンを作成します (どの Linux の場合でも、_iso _file をダウンロードすれば、別のディストリビューションの VM を作成できます)。私は、使用可能な Ubuntu の最新リリース 19.10 を選択しました。ここで表示されるものはすべて 18.04 に対応しています。イメージのダウンロードにかかる時間によりますが、15～20 分ほどで新しい VM が作成され、使用を開始できます。

重要:Default Switch オプションはそのままにしておいてください。. ホストと仮想マシンの両方からインターネットにアクセスできることが保証されます。

3. ローカルサブネットを作成する

仮想マシンを使用するときによく目にする問題の 1 つに、ネットワーク設定に関連して起こるものがあります。動作が不安定であったり、WiFi に接続しているときは動作してもケーブルだと駄目な場合があったり、もしくはその逆の場合もあります。また、Windows ホストで VPN を確立すると、VM のインターネットアクセスを失ったり、VM (Linux) とホスト (Windows) 間のコミュニケーションが遮断されたりすることもあり、はっきり言って大変なんです！ノートパソコンで開発作業を行ったり、簡単なデモやプレゼン資料を作成したりするとき、つまりインターネットにアクセスできることよりも、自分のホストと VM が確実に通信できることの方が重要であるときに、自分の作業環境を信頼できなくなってしまいます。

アドホックのローカルサブネットを Windows ホストと仮想マシン間で共有すれば、それを解決できます。相互に通信し合えるようにするには、そのサブネットを使用します。ホストと VM に特定の IP を割り当てれば準備完了です。

その方法はいたって簡単。まずは、Hyper-V Manager にある Virtual Switch Manager... に移動します。

そこで、_New Virtual Switch __ _オプションを選択します (VM の新しいネットワークカードとして機能します)。

内部ネットワーク として定義し、好きな名前を選び、他のオプションはデフォルトのままにしておきます。

Windows Control Panel --> Network and Sharing Center と移動すれば、作成したばかりのスイッチが既に表示されています。

4. ホストと仮想マシン間で共有されるローカルサブネットを設定する

この時点で、新しいローカルネットワークの設定を完了します。そのためには、Mi Nuevo Conmutador LOCAL にカーソルを合わせて、Properties をクリックし、それから IPv4 protocol へと移動して固定 IP アドレスを割り当てます。

重要: ここで割り当てる IP は、このローカルサブネットのホスト (Windows) IP となります。

5. 新しいローカルネットワークを設定し、仮想マシンにリンクする

ここで、 Hyper-V Manager に戻ります。 VM が実行中であれば、停止してください。停止したら、その設定に移動し、新しい内部仮想スイッチを追加します。

_(注意: 画像には他のスイッチ Hyper-V Conmutador INTERNO が表示されています。これは私のもう 1 つのサブネット用のもので、この設定には必要ありません) _

「Add」をクリックしたら、前回作成したスイッチを選択します。

これが済んだら、「Apply」、「Accept」と順にクリックして準備完了です！仮想マシンを起動し、もう一度ログインしてから内部接続の設定を完了します。そうするには、VM が起動した後に画面右上のネットワークアイコンをクリックします。すると 2 つのネットワーク eth0 y eth1 が表示されます。 eth1 は、この時点では切断された状態で表示されます。

Ethernet (eht1) の設定に移動し、このローカルサブネットに固定 IP を割り当てます (例: IP 155.100.101.1、サブネットマスク _ 255.255.255.0_)。

これで完了です。これで仮想マシンが出来上がり、ホストと同じサブネットを共有する IP 155.100.101.1 として識別されます。

7. 仮想マシンから Windows 10 へのアクセスを許可する

大抵の場合、Windows 10 のデフォルト設定では、他のサーバーからのアクセスが許可されていません。Windows システムについては、たった今作成した VM がまさにそのサーバー (外部の潜在的に危険なサーバー) に該当します。このため、こういった仮想マシンからホストに接続するには、ファイアウォールにルールを追加する必要があります。どうするのかって？いたって簡単です。Windows Control Panel の中から Windows Defender Firewall を見つけて、Advance Configuration に移動し、新規の Entry Rule を作成します。

1 つのポートまたは 1 つ以上の範囲を設定できます... (すべてのポートに対しルールを設定することもできます)...

ここで役に立つのが Allow Connection です。

_ネットワークのすべてのタイプ_オプションを選択し...

ルールに名前を付けます。

ここで重要なことがあります。上記の手順が終わったら、新しく作成したルールのプロパティをもう一度開き、ルールをローカルサブネット内の接続に対してのみ適用できるよう適用範囲を制限しておきます。

8. 準備。 Docker と他に使用するアプリケーションを新しい Ubuntu 仮想マシンにインストールする

インストールプロセスを完了し、新しい VM を最新の状態に整え、インターネットアクセスなども準備ができたら、好きなアプリをインストールできます。少なくとも、元々の目的である Docker、また会社のネットワークへの接続に必要であれば VPN クライアント、さらには VS Code、Eclipse+Atelier などのアプリもインストールできます。

具体的に、VM 内で Docker をインストールする場合は、こちらの手順に従ってください: https://docs.docker.com/install/linux/docker-ce/ubuntu/。

Docker ランタイムの動作確認、テストイメージのダウンロードなどが済んだら、準備完了です。

¡You're all set! が表示されたら、Ubuntu 仮想マシンでコンテナを (ハードウェアのキャパシティ内で) 制限なしに動作させることができます。同仮想マシンには、Windows 10 ホストやブラウザー、アプリなどから接続したり、またはその逆、Ubuntu VM から Windows 10 ホストに接続したりもできます。このすべてに共有ローカルサブネット内で設定した IP アドレスが使用されるため、VPN を確立するしないに関わらず、またインターネットへのアクセスに Wi-Fi アダプターを使用するのか、イーサネットケーブルを使用するのかに関わらず、接続に失敗することはありません。

それから、アドバイスがもう 1 つだけあります。 Windows 10 と仮想マシンの間でファイルを交換する場合は、WinSCP を使用すると簡単で便利です。無料ですし、とても良く機能します。

もちろん、使える設定は他にもありますが、私は一番確実な方法としてこれを使っています。お役に立つことを期待しています。皆さんの悩みの種を取り除くことができれば、この記事を書いた価値があったと言えるでしょう。

¡ハッピーコーディング!