#コンテナ化

0 フォロワー · 36 投稿

コンテナ化は、独自のオペレーティング環境でコンテナにあるアプリケーションをカプセル化することに関係する、フルマシンの仮想化に代わる負荷の軽い代替手段です。

アップデートで

記事 Mihoko Iijima · 1月 25, 2024 6m read

プライベートWebサーバ（PWS）を使用しないバージョンのコンテナ版IRIS利用時のWebサーバ設定例

この記事は、「プライベートWebサーバ（PWS）を使用しないバージョンの新規インストール／アップグレード：概要」の続きの記事で、コンテナ版IRISを利用する場合のWebサーバ設定例をご紹介します。（先に「概要」の記事をお読みいただくことをお勧めします。）

#InterSystems IRIS #InterSystems IRIS for Health #Docker #Web Gateway #コンテナ化 #システム管理 #ヒントとコツ

1 0

0 349

InterSystems公式 Seisuke Nakahashi · 7月 3, 2023

InterSystems コンテナに関する変更点

2023.2がリリースされると同時に、IRIS ならびに IRIS for Health コンテナのタグと配布に関して少し変更を行います。

IRIS コンテナはこれまで、例えば 2023.1.0.235.1 のように、ビルド番号を付与したタグづけを行っていました。しかしお客様から、新製品がリリースされるたびに dockerfiles や Kubernetes ファイルを変更しなくていいよう、より安定的なタグに関するご要望をいただいてきました。それを踏まえ、コンテナ・イメージのタグについて、以下のように変更を行います。

メジャー.マイナータグ: コンテナのタグは、年とリリース番号でのみ記述され、ビルド番号は付きません。例えば、現在以下のように取得されるイメージは

containers.intersystems.com/intersystems/iris:2023.2.0.606.0

今後は以下のフォーマットに変わります。

containers.intersystems.com/intersystems/iris:2023.2

#InterSystems IRIS #InterSystems公式 #Docker #コンテナ化

1 0

0 130

記事 Mihoko Iijima · 3月 28, 2021 4m read

FHIR R4 リソースリポジトリを簡単にお試しいただける開発環境テンプレートのご紹介

皆さんこんにちは！

この記事でご紹介する「開発環境テンプレート」は、最近医療 IT で注目を集めている 医療情報交換標準規格 FHIRを体験できるコンテナです。

一式は、こちら（https://github.com/Intersystems-jp/IRIS-FHIR-Oximeter-Template）で公開しています。

コンテナビルド時、InterSystems IRIS for Health コミュニティエディションを使用した FHIR R4 リソースリポジトリの用意と、REST 用エンドポイントが用意されます。

作成されるエンドポイントに対して、REST クライアントから直接 FHIR R4 リソースリポジトリへアクセスすることもできますし（使用例はこちら／ビデオの解説はこちら）、Patient リソースと Observation リソースの操作体験が行えるサンプル Web アプリケーション（使用例はこちら／ビデオの解説はこちら）もコンテナに含まれていますので、お好みの方法で操作を体験できます。

この開発環境テンプレートでは、さらに！ FHIR サーバーサイドアプリケーション（＝プロダクション）のサンプルも用意しています（図例はこちら）。

プロダクションは、新生児につけたパルスオキシメーターの測定値が定期的に送信されてくることを仮定して作られています。

#InterSystems IRIS for Health #Docker #FHIR #Git #コンテナ化 #初心者

0 2

1 1704

記事 Toshihiko Minamoto · 5月 30, 2023 7m read

InterSystems IRIS 開発リポジトリで Docker を使用する

コミュニティの皆さん、こんにちは！

最近では、誰もが Github、GitLab、bitbucket などのリポジトリにプロジェクトのソースコードを保管していると思います。 InterSystems IRIS プロジェクトについても同様で、Open Exchange にチェックされています。

InterSystems Data Platform で特定のリポジトリの操作を開始または継続するたびに、何をしているでしょうか？

ローカルの InterSystems IRIS マシン、プロジェクト用の環境のセットアップ、ソースコードのインポートが必要です。

つまり、すべての開発者は以下を実行しています。

リポジトリからコードをチェックアウトする。
ローカル IRIS インストールをインストール/実行する。
プロジェクト用の新しいネームスペース/データベースを作成する
コードをこの新しいネームスペースにインポートする。
すべての残りの環境をセットアップする。
プロジェクトのコーディングを開始/継続する。

リポジトリを Docker 化すると、この手順は次の 3 つのステップに短縮できます。

リポジトリからコードをチェックアウトする。
docker-compose build を実行する。
プロジェクトのコーディングを開始/継続する。

メリット: 実行に数分かかる上、頭が痛くなるようなステップ 3、4、5 を行わなくて済みます。

次の数ステップで、（ほぼ）すべての InterSystems リポジトリを Dcoker 化できます。では、やってみましょう！

**リポジトリを Docker 化する方法は？その意味は？ **

基本的に、マシンに Docker をインストールし、コードと環境をコンテナに構築し、そのコンテナを Docker で実行すれば、最初に開発者が導入した方法で動作するようにするという考えです。「OS のバージョンは何？」や「この IRIS インストールには他に何かあった？」といった疑問はありません。

毎回、クリーンなページ（またはクリーンな IRIS コンテナ）を使用して環境（ネームスペース、データベース、ウェブアプリ、ユーザー/ロール）がセットアップされ、作成したばかりのクリーンなデータベースにコードがインポートされます。

この「Docker 化」手順によって、現在のリポジトリに大きな悪影響が及ぶでしょうか？

及びません。リポジトリのルートに独自にセットアップできるいくつかのツールに従った 2～3 個の新しいファイルを追加する必要があります。

前提条件

docker をダウンロードしてインストールします。

IRIS docker イメージをダウンロードしてインストールします。この例では、WRC-preview からダウンロードできる完全な InterSystems IRIS プレビュー（iris:2019.1.0S.111.0）を使用します。詳細をご覧ください。

キーを必要とするインスタンスを操作する場合は、常に使用する場所に iris.key を配置します。私の場合は、Mac の Home ディレクトリに置きました。

リポジトリの Docker 化

リポジトリを Docker 化するには、リポジトリのルートフォルダに 3 つのファイルを追加する必要があります。

こちらは、ISC-DEV プロジェクトの Docker 化されたレポジトリの例です。これは、IRIS データベースからソースコードをインポート/エクスポートするのに役立ちます。このリポジトリには、以下に説明する追加の Dockerfile、docker-compose.yml、および installer.cls が含まれています。

まず、Dockerfile です。これは、docker-compose build コマンドで使用されます。

Dockerfile

FROM intersystems/iris:2019.1.0S.111.0 # インストールされたものと同じイメージである必要があります

<p>
</p>

<p>
  WORKDIR /opt/app
</p>

<p>
  COPY ./Installer.cls ./
</p>

<p>
  COPY ./cls/ ./src/
</p>

<p>
  RUN iris start $ISC_PACKAGE_INSTANCENAME quietly EmergencyId=sys,sys && \
</p>

<p>
      /bin/echo -e "sys\nsys\n" \
</p>

<p>
              # ユーザー管理者に %ALL を付与
</p>

<p>
              " Do ##class(Security.Users).UnExpireUserPasswords(\"*\")\n" \
</p>

<p>
              " Do ##class(Security.Users).AddRoles(\"admin\", \"%ALL\")\n" \
</p>

<p>
              # インストーラのインポートと実行
</p>

<p>
              " Do \$system.OBJ.Load(\"/opt/app/Installer.cls\",\"ck\")\n" \
</p>

<p>
              " Set sc = ##class(App.Installer).setup(, 3)\n" \
</p>

<p>
              " If 'sc do \$zu(4, \$JOB, 1)\n" \
</p>

<p>
              # OS レベルの認証を導入（コンテナのログイン/パス プロンプトを削除するため）
</p>

<p>
              " Do ##class(Security.System).Get(,.p)\n" \
</p>

<p>
              " Set p(\"AutheEnabled\")=p(\"AutheEnabled\")+16\n" \
</p>

<p>
              " Do ##class(Security.System).Modify(,.p)\n" \
</p>

<p>
              " halt" \
</p>

<p>
      | iris session $ISC_PACKAGE_INSTANCENAME && \
</p>

<p>
      /bin/echo -e "sys\nsys\n" \
</p>

<p>
      | iris stop $ISC_PACKAGE_INSTANCENAME quietly
</p>

<p>
  CMD [ "-l", "/usr/irissys/mgr/messages.log" ]
</p>   

<p>
   
</p>

この Dockerfile は installer.cls とソースコードをリポジトリの /cls フォルダから /src フォルダ、そしてコンテナにコピーします。

また、いくつかの構成設定も実行します。これにより、管理者ユーザーに %All ロールと無期限のパスワード「SYS」が付与され、OS レベルの認証が導入され、%Installer が実行されます。

%Installer とは何でしょうか？

Class App.Installer
{
XData MyInstall [ XMLNamespace = INSTALLER ]
{
<Manifest>
  <Default Name="NAMESPACE" Value="ISCDEV"/>
  <Default Name="DBNAME" Value="ISCDEV"/>
  <Default Name="APPPATH" Dir="/opt/app/" />
  <Default Name="SOURCESPATH" Dir="${APPPATH}src" />
  <Default Name="RESOURCE" Value="%DB_${DBNAME}" /> 

  <Namespace Name="${NAMESPACE}" Code="${DBNAME}-CODE" Data="${DBNAME}-DATA" Create="yes" Ensemble="0">
    <Configuration>
      <Database Name="${DBNAME}-CODE" Dir="${APPPATH}${DBNAME}-CODE" Create="yes" Resource="${RESOURCE}"/>
      <Database Name="${DBNAME}-DATA" Dir="${APPPATH}${DBNAME}-DATA" Create="yes" Resource="${RESOURCE}"/>
    </Configuration>
    <Import File="${SOURCESPATH}" Recurse="1"/>
  </Namespace>

</Manifest>
}

ClassMethod setup(ByRef pVars, pLogLevel As %Integer = 3, pInstaller As %Installer.Installer, pLogger As %Installer.AbstractLogger) As %Status [ CodeMode = objectgenerator, Internal ]
{
  Return ##class(%Installer.Manifest).%Generate(%compiledclass, %code, "MyInstall")
}

}

これは、ネームスペース/データベース ISCDEV を作成し、ソースフォルダである -/src からコードをインポートします。

次は、docker-compose.yml ファイルです。これは、docker-compose up コマンドでコンテナを実行するときに使用されます。

version: '2.4'
services:
  iris:
    build: .
    restart: always
    ports:
      - 52773:52773
    volumes:
      - ~/iris.key:/usr/irissys/mgr/iris.key

この構成によって、Docker に対し、ホストのどのポートで IRIS の動作が期待されるかを指示します。最初（52773）はホスト、2 つ目はコンテナのコンテナ内部ポート（52773）です。

volumes セクションでは、docker-compose.yml は、IRIS が検索するコンテナ内でマシン上の iris キーへのアクセスを提供します。

- ~/iris.key:/usr/irissys/mgr/iris.key

このリポジトリでコーディングを始めるには、以下を実行します。

任意のローカルディレクトリにリポジトリを Clone/git pull します。

2. このディレクトリでターミナルを開き、以下を実行します。

user# docker-compose build

これによりコンテナがビルドされます。

プロジェクトで IRIS コンテナを実行します。

user# docker-compose up -d

お好きな IDE を開いて、localhost://52773 のサーバーに接続し、InterSystems IRIS Data Platform で作業を始めましょう！;)

この 3 つのファイルを使用して、リポジトリを Docker 化できます。 Dockerfile のソースコードに適切な名前、Installer.cls に適切なネームスペースを付けて、docker-compose.yml に iris.key を配置するだけで、InterSystems IRIS を使った日常の開発で、Docker コンテナを活用することができます。

#InterSystems IRIS #Docker #コンテナ化 #ベストプラクティス #開発環境

0 0

1 360

InterSystems公式 Toshihiko Minamoto · 1月 4, 2023

InterSystemsコンテナレジストリ Webユーザインターフェースのお知らせ

InterSystemsはこの度、InterSystems コンテナレジストリ (ICR) Web ユーザインターフェースをリリースしました。このツールはICR上に多くあるコンテナイメージを見つけやすく、使いやすくできるようデザインされたものです。

InterSystems コンテナレジストリUIは以下のサイトです。

https://containers.intersystems.com/contents

コミュニティエディションコンテナ

When you visit the ICR ユーザインターフェース,を訪問すると、コミュニティエディションといったパブリックに利用可能なコンテナにアクセスできます。画面左のナビゲーションで必要なプロダクトファミリを選択し、コンテナを選択、最終的に特定のバージョンを指定します。

エンタープライズエディションコンテナ

IRISエンタープライズエディションといったプライベートコンテナを観るにはログインボタンをクリックしてください。一度ログインいただくと、画面左のナビゲーションにはアクセスできるすべてのコンテナが表示されます。

ぜひ、ご利用ください！

#InterSystems公式 #Docker #コンテナ化

0 0

0 140

記事 Toshihiko Minamoto · 6月 28, 2022 5m read

ダッシュボードの IRIS 履歴モニター

皆さん、こんにちは！

職場で持ち上がった単純なリクエストで始めた個人プロジェクトを紹介したいと思います。

使用している Caché ライセンス数を調べることはできますか？

コミュニティに掲載されている他の記事を読んでみたところ、David Loveluck が投稿したぴったりの記事が見つかりました。

APM - Using the Caché History Monitor（APM - Caché 履歴モニターを使用する）
https://community.intersystems.com/post/apm-using-cach%C3%A9-history-monitor

そこで、David の記事を参考に、Caché 履歴モニターを使って、リクエストされた情報を表示して見ました。

「どのテクノロジーを使用するのか」という疑問に対し

私は CSP に決定しました。単純で強力なテクノロジーであるため、私が担当するお客様は Caché が単なる MUMPS/ターミナルではないことに気づくでしょう。

ライセンス、データベース増加状況、CSP セッションの履歴を表示するページを作成した後、「システムダッシュボードとプロセス」ページのデザインを新装することにしました。

私の Caché インスタンスではすべてうまく機能します。

でも、IRIS はどうでしょうか？

Evgeny Shvarov が投稿した以下の記事に従って、

Using Docker with your InterSystems IRIS development repository（InterSystems IRIS 開発リポジトリで Docker を使用する）
https://community.intersystems.com/post/using-docker-your-intersystems-iris-development-repository

コードを Docker 化して GitHub に配置しました。いくつかの手順を踏めば、どなたでも利用できます。

実行方法

このリポジトリでコーディングを始めるには、以下を実行します。

任意のローカルディレクトリにリポジトリを Clone/git pull します。
$ git clone https://github.com/diashenrique/iris-history-monitor.git
このディレクトリでターミナルを開き、以下を実行します。
$ docker-compose build
プロジェクトで IRIS コンテナを実行します。
$ docker-compose up -d

テスト方法

ブラウザを開いて、以下のアドレスに移動します。

例: http://localhost:52773/csp/irismonitor/dashboard.csp

ユーザー名 _SYSTEM を使用して、ダッシュボードとその他の機能を実行できます。

システムダッシュボード

システムダッシュボードには、以下の項目が表示されます。

ライセンス
システム時間
アプリケーションエラー
Cache プロセス
CSP セッション
ロックテーブル
ジャーナル空間
ジャーナルのステータス
ECP AppServer
ECP DataServer
Write デーモン
Cache の効率
重大なアラート

線グラフウィジェットには、5 秒ごとにポイントがプロットされます。

システムメニュー

システムプロセス

プロセスフィルター

さまざまなフィルターを使用して、必要な結果を得ることができます。また、列のヘッダーを Shift + クリックすると、複数の項目で並べ替えることもできます。データグリッドを Excel にエクスポートすることも可能です！

履歴モニター

CSP セッションとライセンスの履歴モニターでは、情報が以下の 3 つのセクションに分かれて表示されます。

5 分毎
毎日
毎時間

データベースの増加が表示できるのは、毎日の情報のみです。

履歴ページでは以下の機能を共通して使用できます。

日付範囲の選択ツール

_デフォルト_値は、「過去 7 日間」です。

グラフ/データテーブル

各セクションの右上に、2 つのボタン（チャート/データテーブル）があります。

データテーブルには、グラフを作成する情報が表示されます。Excel 形式でダウンロード可能です。

Excel には、CSP で定義されたのと同じフォーマット、コンテンツ、およびグループが表示浚えます。

ズーム機能

すべてのグラフにはズームオプションがあるため、情報をより詳細に可視化することができます。

平均と最大

毎時間と毎日のセクションのグラフには、平均値と最大値が表示されます。

平均

最大

どうぞお楽しみください！

#Caché #InterSystems IRIS #Open Exchange #CSP #Docker #コンテナ化 #システム管理 #ダッシュボード #監視

Open Exchange

0 0

0 225

記事 Toshihiko Minamoto · 4月 19, 2022 9m read

Raspberry Pi Raspberry で InterSystems Iris Fhirserver を実行する

Raspberry を FHIRserver として実行する

一年ほど前、
Raspberry Pi での HAPI FHIRserver のインストールに関する記事を書きました。当時、FHIR 標準の基本しか知らず、FHIR サーバーの背後にあるテクノロジーや Raspberry についてほとんど知りませんした。試して、失敗して、諦めて、もう一度試すことで、たくさんのことを学びました。1 年以上が経ち、いまだに「忍耐力に長けるアマチュア」ではありますが、その間、FHIR のフル環境を Raspberry で構築し、HTML/JavaScript/jQuery/Bootstrap によるアプリケーションや PHP アプリケーションを多数作成してきました。 Raspberry の認証サーバーや承認サーバーについてもいくらか経験し、SMART on FHIRを使った実験も行いました。

最後の機能しなかったバージョンと、明らかに私が作成した成功バージョンの違いが判らないまま動作することもありましたが、作業や実験のほとんどは動作しました。今でも驚いています。振り返ると、システム開発について適切に学習しておくべきだったと思います（私は山林学専攻で卒業し、現在はその分野を中心にボランティア活動を行っています。まぁ、本題からは外れてしまいますが）。

Raspberry Pi は実験には十分ですが、本稼働には適していないことに注意してください。したがって、信頼性、継続性、セキュリティ、プライバシーといった要素が必要である、または期待されているヘルスケアなどの分野で、Raspberry を本稼働システムとして使用しないでください。実験目的では完璧で安価なコンピュータであり、幾度も私の期待を超えていますが、「産業耐久性」に欠けています。

InterSystems FHIRserver

入手しやすさと、非常に早い段階で結果を得られたことを理由に、当時 HAPI FHIR を選択しました。以前の同僚で、現在では InterSystems に勤めている人から、InterSystems の FHIRserver でも試用することをすでに提案されていました。

InterSystems については非常によく知っており（というより、「i.know」と言うべきでしょうか 😉）、面白そうに思えましたが、当時、一年以上前は、ARM プロセッサ向けに適したバージョンの Iris は存在していませんでした（Raspberry は ARM で動作します）。それとは別に、Iris の Community バージョンは Docker コンテナとして配布されていましたが、私には Docker に関する知識がまったくありませんでした。

Raspbian から Ubuntu へ

それから 1 年が過ぎました。現在では、さらに強力になった新しい Raspberry Pi が登場しています（在庫のある限り…）。新しい Raspberry 4 は、Raspberry 3 と同様に、64 ビット Unix をサポートしています。 IRIS Community バージョンは ARM にも対応しており、コンテナと Docker についてもいくらかさらに学習しました。

こういった改善すべてを基に、昨年の年末にオランダで施行されたわけのわからない「ロックダウン」が、IRIS Community バージョンを Raspberry Pi で実行させる新しい実験を開始するチャンスとなりました。

振り返ると、これは非常に簡単なことでした。実際、注意すべき点は 3 つしかありません。

64 ビットをサポートする Raspberry が必要です。つまり、Raspberry 3 または 4 が必要となります。
（64 ビット）Raspbian ではうまくいきませんでした（ちなみに非常に新しいものです）。しかし、64 ビット Ubuntu では成功しました。
InterSystems FHIRserver は、HAPI FHIRserver よりも FHIR 呼び出しに関して厳格さが増しているようです。これについては別の機会に説明しますが、これを悪いことだとは思っていません。（ヘルス）ケア環境における中央リポジトリであるため、標準について厳格である必要があるためです。そうでなければ、「ガベージイン・ガベージアウト」になってしまうでしょう。

それでも、HAPI FHIRserver でうまく実行していたアプリケーションが IRIS では失敗することを理解するのには、いくらか時間がかかりました。ネタバレ注意: 問題は私のアプリケーションにありました。

それにしても、Raspberry Pi のような、100 ユーロもかからない小さなコンピュータで、InterSystems IRIS フルプラットフォームが実行し、管理ポータル、Ensemble、Caché、そして FHIRserver が備わっているのを目の当たりにするのは、楽しく本当に価値以上の価値があります。

以降では、そこに至るまでに私が行ったことを、順を追って説明します。 Ubuntu の歴史、Docker の背後の意ある哲学など、長々とした話にはなりません。そちらの方に関心のある方は、インターネットをご覧ください。ここでは「楽しく進められるフロー」に焦点を当て、どこで初めて間違ったのかについて言及する場合にのみ、注釈したいと思います。

InterSystems FHIRserver のインストール

フェーズ 1: Ubuntu 64 ビット

_SD カードをフォーマット_し、そこに ARM プロセッサ用 64 ビット Ubuntu を配置します。私の場合、圧縮バージョンの名前は「ubuntu-20.04.3-preinstalled-server-arm64+raspi.img.xz」でした。これは http://cdimage.ubuntu.com にあります。（もちろん、SD カードに置く前に、.img ファイルを解凍する必要があります！）

RaspberryPi-imager は、誤ったバージョンを提供するため、使用しないでください。私は Win32DiskImager を使用しました。

_新しいイメージで Raspberry を開始_します。 ubuntu-account のパスワードを変更します（そして記憶しましょう！）。あくまでも ubuntu-account のパスワードです。
この時点で Raspberry は Ubuntu で実行していますが、まだ準備はできていません。

以下を見てください。

この Ubuntu-version はまだ 32 ビットになっています！

今すぐこれを直しましょう。

Pi にログインします。
sudo rpi-update
sudo reboot now
sudo copy /boot/config.txt /boot/config-ok.txt（検出したエラーを逃してしまった場合に備えます）
sudo nano /boot/config.txt [pi4] の下に次のテキストを追加します: arm_64bit=1
boot/config.txt を保存します。（nano で: <ctrl>O ）
nano を終了します。（<ctrl>X）
sudo reboot now

これで、64 ビットで実行するようになりました。自分で確認してみましょう:

Pi のIP アドレスをメモし（sudo hostname -I。I は大文字のアイです）、Ubuntu では SSH はデフォルトで有効になっているため、別の場所に保管しておきます。

フェーズ 2: Docker

sudo curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

しばらくすると、これは、「non-priviledged user」として使用することに関する Docker の詳細な通知が得られます。

sudo usermod -aG docker $USER
ログオフしてから、もう一度ログインします。
docker container run hello-world

Docker はシステム上の「hello-world」イメージを探すようになりました。見つからない場合は、Docker リポジトリからダウンロードします。その後、Docker はイメージを Pi 上のコンテナに配置し、「hello-world」イメージを開始します。

Docker の別のテキストブロックで、「Hello from Docker」のウェルカムメッセージと共に確認できます。

フェーズ 3: InterSystems の IRIS FHIRserver の Docker イメージ

1. 以下のコマンドを一度に発行します。

sudo docker run --name my-iris -d --publish 9091:1972 --publish 9092:52773 containers.intersystems.com/intersystems/irishealth-community-arm64

多数のイベントが順に発生します。

Docker は Irishealthから「community edition」を取得し、それをローカルの Docker リポジトリに配置します。
Docker は「my-iris」という Docker コンテナで Community エディションを起動します。
Docker はコンテナで実行している IRIS のポート 1972 を Raspberry のポート 9091 にマッピングします。
同じパターンに従って、IRIS のポート 52773（コンテナ内）は Raspberry のポート 9092 になります。

以下のようにすると、何が起きたのかを確認できます。

sudo docker container ls ただし、これを確認するには別のはるかに印象的な方法があります。

フェーズ 4: InterSystems IRIS for Health Fhirserver の起動

ネットワークで Web ブラウザを起動します。英語版 PC の場合は次の場所に移動してください。

_ <Raspberry の IP アドレス>:9092/csp/sys/UtilHome.csp .

IRIShealth の管理ポータルが表示されます。このポータルは、自動的にPC の言語設定に調整されます。

標準アカウントは _SYSTEM（先頭のアンダースコアを含む）で、初回パスワードは SYS（アンダースコアはありません）です。 IRIS からすぐにパスワードを変更するように求められます。

これで、次に記載されている指示に従って IRIS for Health FHIRserver を構成し、起動できるようになりました。https://docs.intersystems.com/irisforhealthlatest/csp/docbook/DocBook.UI.Page.cls?KEY=HXFHIR_server_install

「Foundation」を構成して「Endpoint」（FHIR 3 または 4）を定義する必要があります。

「Endpoint」は、FHIRserver にアクセスできる URI となります。私の場合は、http://192.168.1.29:9092/csp/healthshare/fhironpi/fhir/r4/Patient にある「Patient」リソースです（外部からはアクセスできません！）。

まとめ

手間を取る価値があったでしょうか？そのとおり！それ以上の価値があります。まず、それほどの手間はありませんでした。 Raspbian ではうまくいきませんでしたが、それは簡単に解決しました。そして、IRIS-for-health プラットフォームを Raspberry Pi のようなデバイスで実行できるのは素晴らしいことです。ダッシュボード（DeepSee）、データ変換ツール、Ensemble（Enterprise Service Bus とその他多数のツール）、CSP ページ、および Caché（多次元データベース）すべてを実験できるようですし、自然言語処理の I.know も管理ポータルに表示されています。 IRIS-for-health プラットフォームには、FHIRserver 単体よりもはるかに多くの機能が備わっており、1 つの記事ではとても説明しきれません。

私個人としては、ほぼリリース直後から Ensemble を使用してきましたし（アーキテクトとして）、それとは別に、IRIS-for-health の起源は 20 世紀後半だったため、思い入れがあります。ヘルスケアアプリケーション向け MUMPS 開発環境（MUMPS/マンプス: マサチューセッツ総合病院ユーティリティマルチプログラミングシステム）は、ほとんどが Digital Corp の Vax コンピュータシステムで実行されていたのですが、私の IT キャリアが始まったのも同時期なのです。

MUMPS、Caché、Ensemble、そして今日には IRIS-for-Health プラットフォームの安定性は非常に高く、必要なサポートとメンテナンスは比較的控え目です。 InterSystems 製品のドキュメントは広範に用意されており、簡単に見つけることができます。

IRIS と FHIRserver での実験をさらに続ていく予定です。最低でも後 1 つ、FHIR 標準への厳格な準拠に対する私の「奮闘」に関する記事を絶対に公開いたします！

健康を大切に、思考を繰り返して、実験し続けましょう！ Bob

#InterSystems IRIS #FHIR #コンテナ化 #初心者

0 0

0 301

InterSystems公式 Toshihiko Minamoto · 3月 21, 2022

InterSystems Kubernetes Operator 3.3 が公開されました

InterSystems Kubernetes Operation (IKO) バージョン 3.3 が WRC ダウンロードページやInterSystems Container Registry よりダウンロード可能となりました。

IKO は、使いやすい irisClusterリソース定義を提供することにより、Kubernetesにおける InterSystems IRIS やInterSystems IRIS for Health との連携を簡素化します。簡単なシャーディング、ミラーリング、ECP構成などの機能一覧はドキュメントをご覧ください。

IKO 3.3の主な修正点:

InterSystems IRIS 、 IRIS for Healthのバージョン 2021.2 、 2022.1 のサポート
Kuberentes 1.21のサポート
irisCluster の一部として共通のSystem Alerting and Monitoring (SAM) コンフィグレーションのデプロイ
irisCluster の一部として InterSystems API Manager (IAM) のデプロイや管理
ミラーリングのアクティブ側の自動タグ付けにより、サービスは常にアクティブなミラーメンバーを指すことができます。

#InterSystems IRIS #InterSystems IRIS for Health #InterSystems公式 #Kubernetes #コンテナ化

0 0

0 122

記事 Toshihiko Minamoto · 2月 14, 2022 19m read

統合AIデモサービススタックにML/DLモデルをデプロイする

キーワード: IRIS、IntegratedML、Flask、FastAPI、Tensorflow Serving、HAProxy、Docker、Covid-19

目的:

過去数か月に渡り、潜在的なICU入室を予測するための単純なCovid-19 Ｘ線画像分類器やCovid-19ラボ結果分類器など、ディープラーニングと機械学習の簡単なデモをいくつか見てきました。また、ICU分類器のIntegratedMLデモ実装についても見てきました。「データサイエンス」の旅路はまだ続いていますが、「データエンジニアリング」の観点から、AIサービスデプロイメントを試す時期が来たかもしれません。これまでに見てきたことすべてを、一式のサービスAPIにまとめることはできるでしょうか。このようなサービススタックを最も単純なアプローチで達成するには、どういった一般的なツール、コンポーネント、およびインフラストラクチャを活用できるでしょうか。

対象範囲

対象:

ジャンプスタートとして、docker-composeを使用して、次のDocker化されたコンポーネントをAWS Ubuntuサーバーにデプロイできます。

**HAProxy ** - ロードバランサー
Gunicorn と **Univorn ** - Webゲートウェイ****サーバー
Flask と FastAPI - WebアプリケーションUI、サービスAPI定義、およびヒートマップ生成などのアプリケーションサーバー
Tensorflow Model Serving と Tensorflow-GPU Model Serving - 画像や分類などのアプリケーションバックエンドサーバー
IRIS IntegratedML - SQL インターフェースを備えたアプリとデータベースを統合した AutoML
ベンチマーキング用クライアントをエミュレートする、JupyterノートブックのPython3
Dockerとdocker-compose
Testla T4 GPU搭載のAWS Ubuntu 16.04

注意: GPUを使用したTensorflow Servingはデモのみを目的としています。GPU関連の画像（dockerfile）と構成（docker-compose.yml）は、単純にオフにできます。

対象外またはウィッシュリスト:

Nginx またはApacheなどのWebサーバーは、今のところこのデモでは省略されています。
RabbitMQとRedis - IRISまたはEnsembleと置き換えられる、信頼性の高いメッセージングキューブローカー。
IAM（Intersystems API Manger）またはKongはウィッシュリストに含まれます。
**SAM **（InterSystemsのシステムアラートと監視）
Kubernetes Operator付きのICM（InterSystems Cloud Manager）- 誕生したときからずっとお気に入りの1つです。
FHIR（IntesyStems IRISベースのFHIR R4サーバーとFHIRアプリのSMART用FHIRサンドボックス）
CI/CD開発ツールまたはGithub Actions

「機械学習エンジニア」は、サービスのライフサイクルに沿って本番環境をプロビジョニングする際に、必然的にこれらのすべてのコンポーネントを操作しなければならないでしょう。今後徐々に、焦点を当てていきたいと思います。

GitHubリポジトリ

全ソースコードの場所: https://github.com/zhongli1990/covid-ai-demo-deployment

また、新しいリポジトリとともに、integratedML-demo-templateリポジトリも再利用します。

デプロイメントのパターン

以下に、この「DockerでのAIデモ」テストフレームワークの論理的なデプロイパターンを示します。

デモの目的により、意図的にディープラーニング分類とWebレンダリング用に個別のスタックを2つ作成し、HAProxyをソフトロードバランサーとして使用して、受信するAPIリクエストをこれらの2つのスタックでステートレスに分散できるようにしました。

Guniorn + Flask + Tensorflow Serving
Univcorn + FaskAPI + Tensorflow Serving GPU

前の記事のICU入室予測と同様に、機械学習デモのサンプルには、IntegratedMLを使用したIRISを使用します。

現在のデモでは、本番サービスでは必要または検討される共通コンポーネントをいくつか省略しました。

Webサーバー: NginxまたはApacheなど。 HAProxyとGunicorn/Uvicornの間で、適切なHTTPセッション処理を行うために必要となります（DoS攻撃を防止するなど）。
キューマネージャーとDB: RabbitMQやRedisなど。Flask/FastAPIとバックエンドサービングの間で、信頼性のある非同期サービングとデータ/構成の永続性などに使用されます。
APIゲートウェイ: IAMまたはKongクラスター。単一障害点を作らないように、HAProxyロードバランサーとAPI管理用Webサーバーの間に使用されます。
監視とアラート: SAMが適切でしょう。
CI/CD開発のプロビジョニング: クラウドニューラルデプロイメントと管理、およびその他の一般的な開発ツールによるCI/CDにはK8を使用したICMが必要です。

実際のところ、IRIS自体は、信頼性の高いメッセージングのためのエンタープライズ級のキューマネージャーとしても、高性能データベースとしても確実に使用することができます。パターン分析では、IRISがRabbitMQ/Redis/MongoDBなどのキューブローカーとデータベースの代わりになることは明らかであるため、レイテンシが大幅に低く、より優れたスループットパフォーマンスとさらに統合する方が良いでしょう。さらに、IRIS Webゲートウェイ（旧CSPゲートウェイ）は、GunicornやUvicornなどの代わりに配置できますよね？

環境トポロジー

上記の論理パターンを全Dockerコンポーネントに実装するには、いくつかの一般的なオプションがあります。頭に思い浮かぶものとしては以下のものがあります。

docker-compose
docker swarmなど
Kubernetesなど
K8演算を使用したICM

このデモは、機能的なPoCといくつかのベンチマーキングを行うために、「docker-compose」から始めます。もちろん、いつかはK8やICMを使いたいとも考えています。

docker-compose.ymlファイルに説明されているように、AWS Ubuntuサーバーでの環境トポロジーの物理的な実装は、以下のようになります。

上図は、全Dockerインスタンスのサービスポートが、デモの目的でどのようにマッピングされており、Ubuntuサーバーで直接公開されているかを示したものです。本番環境では、すべてセキュリティ強化される必要があります。また、純粋なデモの目的により、すべてのコンテナは同じDockerネットワークに接続されています。本番環境では、外部ルーティング可能と内部ルーティング不可能として分離されます。

Docker化コンポーネント

以下は、docker-compose.ymlファイルに示されるとおり、ホストマシン内でこれらのストレージボリュームが各コンテナインスタンスにどのようにマウントされているかを示します。

ubuntu@ip-172-31-35-104:/zhong/flask-xray$ tree ./ -L 2

./├── covid19                             （Flask+GunicornコンテナとTensorflow Servingコンテナがここにマウントされます）│├── app.py                                （Flaskメインアプリ:  WebアプリケーションとAPIサービスインターフェースの両方がここに定義されて実装されます）│├── covid19_models               （CPU使用の画像分類Tensorflow Servingコンテナ用のTensorflowモデルはここに公開されてバージョン管理されます）│├── Dockerfile                          （Flask サーバーとGunicorn:      CMD ["gunicorn", "app:app", "--bind", "0.0.0.0:5000", "--workers", "4", "--threads", "2"]）│├── models                               （.h5形式のFlaskアプリ用モデルとＸ線画像へのGrad-CAMによるヒートマップ生成のAPIデモ）│├── __pycache__│├── README.md│├── requirements.txt             （全Flask+Gunicornアプリに必要なPythonパッケージ） │├── scripts│├── static                                  （Web静的ファイル）│├── templates                         （Webレンダリングテンプレート）│├── tensorflow_serving        （TensorFlow Servingサービスの構成ファイル）│└── test_images├── covid-fastapi                   (FastAPI+UvicornコンテナとGPU使用のTensorflow Servingコンテナはここにマウントされます）│├── covid19_models            （画像分類用のTensorflow Serving GPUモデルは、ここに公開されてバージョン管理されます）│├── Dockerfile                       （Uvicorn+FastAPIサーバーはここから起動されます: CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000", "--workers", "4" ]）│├── main.py                           （FastAPIアプリ: WebアプリケーションとAPIサービスインターフェースの両方がここに定義されて実装されます）│├── models                            （.h5形式のFastAPIアプリ用モデルとＸ線画像へのGrad-CAMによるヒートマップ生成のAPIデモ）│├── __pycache__│├── README.md│├── requirements.txt│├── scripts│├── static│├── templates│├── tensorflow_serving│└── test_images├── docker-compose.yml      （フルスタックDocker定義ファイル。  Docker GPU「nvidia runtime」用にバージョン2.3を使用。そうでない場合はバージョン3.xを使用可）├── haproxy                             (HAProxy dockerサービスはここに定義されます。  注意: バックエンドLBにはスティッキーセッションを定義できます。 )                             │├── Dockerfile│└── haproxy.cfg└── notebooks                       （TensorFlow 2.2とTensorBoardなどを含むJupyterノートブックコンテナサービス）├── Dockerfile├── notebooks                  （機能テスト用に外部APIクライアントアプリをエミュレートするサンプルノートブックファイルとロードバランサーに対してPythonによるAPIベンチマークテストを行うサンプルノートブックファイル）└── requirements.txt

注意: 上記のdocker-compose.ymlはCovid-19 Ｘ線画像のディープラーニングデモ用です。別のintegratedML-demo-templateのdocker-compose.ymlとともに、環境トポロジーに表示されるフルサービススタックを形成するために使用されています。

サービスの起動

すべてのコンテナサービスを起動するには、単純なdocker-compose up -dを使用します。

ubuntu@ip-172-31-35-104:~$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 31b682b6961d iris-aa-server:2020.3AA "/iris-main" 7 weeks ago Up 2 days (healthy) 2188/tcp, 53773/tcp, 54773/tcp, 0.0.0.0:8091->51773/tcp, 0.0.0.0:8092->52773/tcp iml-template-master_irisimlsvr_1 6a0f22ad3ffc haproxy:0.0.1 "/docker-entrypoint.…" 8 weeks ago Up 2 days 0.0.0.0:8088->8088/tcp flask-xray_lb_1 71b5163d8960 ai-service-fastapi:0.2.0 "uvicorn main:app --…" 8 weeks ago Up 2 days 0.0.0.0:8056->8000/tcp flask-xray_fastapi_1 400e1d6c0f69 tensorflow/serving:latest-gpu "/usr/bin/tf_serving…" 8 weeks ago Up 2 days 0.0.0.0:8520->8500/tcp, 0.0.0.0:8521->8501/tcp flask-xray_tf2svg2_1 eaac88e9b1a7 ai-service-flask:0.1.0 "gunicorn app:app --…" 8 weeks ago Up 2 days 0.0.0.0:8051->5000/tcp flask-xray_flask_1 e07ccd30a32b tensorflow/serving "/usr/bin/tf_serving…" 8 weeks ago Up 2 days 0.0.0.0:8510->8500/tcp, 0.0.0.0:8511->8501/tcp flask-xray_tf2svg1_1 390dc13023f2 tf2-jupyter:0.1.0 "/bin/sh -c '/bin/ba…" 8 weeks ago Up 2 days 0.0.0.0:8506->6006/tcp, 0.0.0.0:8586->8888/tcp flask-xray_tf2jpt_1 88e8709404ac tf2-jupyter-jdbc:1.0.0-iml-template "/bin/sh -c '/bin/ba…" 2 months ago Up 2 days 0.0.0.0:6026->6006/tcp, 0.0.0.0:8896->8888/tcp iml-template-master_tf2jupyter_1

docker-compose up --scale fastapi=2 --scale flask=2 -d for example will horizontally scale up to 2x Gunicorn+Flask containers and 2x Univcorn+FastAPI containers:

ubuntu@ip-172-31-35-104:/zhong/flask-xray$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES dbee3c20ea95 ai-service-fastapi:0.2.0 "uvicorn main:app --…" 4 minutes ago Up 4 minutes 0.0.0.0:8057->8000/tcp flask-xray_fastapi_2 95bcd8535aa6 ai-service-flask:0.1.0 "gunicorn app:app --…" 4 minutes ago Up 4 minutes 0.0.0.0:8052->5000/tcp flask-xray_flask_2

... ...

「integrtedML-demo-template」の作業ディレクトリで別の「docker-compose up -d」を実行することで、上記リストのirisimlsvrとtf2jupyterコンテナが起動されています。

テスト

1. 単純なUIを備えたAIデモWebアプリ

上記のdockerサービスを起動したら、一時アドレスhttp://ec2-18-134-16-118.eu-west-2.compute.amazonaws.com:8056/のAWS EC2インスタンスにホストされているCovid-19に感染した胸部Ｘ線画像の検出用デモWebアプリにアクセスできます。

以下は、私の携帯でキャプチャした画面です。デモUIは非常に単純です。基本的に「Choose File」をクリックして「Submit」ボタンを押せば、Ｘ線画像がアップロードされて分類レポートが表示されます。 Covid-19感染のＸ線画像として分類されたら、DLによって「検出された」病変領域をエミュレートするヒートマップが表示されます。そうでない場合は、分類レポートにはアップロードされたＸ線画像のみが表示されます。

このWebアプリはPythonサーバーページです。このロジックは主にFastAPI's main.pyファイルとFlask's app.pyファイルにコーディングされています。

もう少し時間に余裕がある際には、FlaskとFastAPIのコーディングと規則の違いを詳しく説明かもしれません。実は、AIデモホスティングについて、FlaskとFastAPIとIRISの比較を行いたいと思っています。

2. テストデモAPI

FastAPI（ポート8056で公開）には、以下に示すSwagger APIドキュメントが組み込まれています。これは非常に便利です。以下のようにURLに「/docs」を指定するだけで、利用することができます。

いくつかのプレースホルダー（/helloや/itemsなど）と実際のデモAPIインターフェース（/healthcheck、/predict、predict/heatmapなど）を組み込みました。

これらのAPIに簡単なテストを実行してみましょう。私がこのAIデモサービス用に作成したJupyterノートブックサンプルの1つで、Python行を（APIクライアントアプリエミュレーターとして）いくつか実行します。

以下では、例としてこちらのファイルを実行しています。 https://github.com/zhongli1990/covid-ai-demo-deployment/blob/master/notebooks/notebooks/Covid19-3class-Heatmap-Flask-FastAPI-TF-serving-all-in-one-HAProxy2.ipynb

まず、バックエンドのTF-Serving（ポート8511）とTF-Serving-GPU（ポート8521）が稼働していることをテストします。

!curl http://172.17.0.1:8511/v1/models/covid19  # tensorflow serving
!curl http://172.17.0.1:8521/v1/models/covid19  # tensorflow-gpu serving

{
 "model_version_status": [
  {
   "version": "2",
   "state": "AVAILABLE",
   "status": {
    "error_code": "OK",
    "error_message": ""
   }
  }
 ]
}
{
 "model_version_status": [
  {
   "version": "2",
   "state": "AVAILABLE",
   "status": {
    "error_code": "OK",
    "error_message": ""
   }
  }
 ]
}

次に、以下のサービスAPIが稼働していることをテストします。

Gunicorn+Flask+TF-Serving

Unicorn+FastAPI+TF-Serving-GPU

上記の両サービスの手間にあるHAProxyロードバランサー

r = requests.get('http://172.17.0.1:8051/covid19/api/v1/healthcheck')  # tf srving docker with cpu 
print(r.status_code, r.text)
r = requests.get('http://172.17.0.1:8056/covid19/api/v1/healthcheck')  # tf-serving docker with gpu
print(r.status_code, r.text)
r = requests.get('http://172.17.0.1:8088/covid19/api/v1/healthcheck')  # tf-serving docker with HAproxy
print(r.status_code, r.text)

そして、以下のような結果が期待されます。

200 Covid19 detector API is live!
200 "Covid19 detector API is live!\n\n"
200 "Covid19 detector API is live!\n\n"

入力Ｘ線画像の分類とヒートマップ結果を返す、/predict/heatmapなどの機能的なAPIインターフェースをテストします。受信する画像は、API定義に従ってHTTP POST経由で送信される前にbased64にエンコードされています。

%%time# リクエストライブラリをインポート
import argparse
import base64import requests# api-endpointを定義
API_ENDPOINT = "http://172.17.0.1:8051/covid19/api/v1/predict/heatmap"image_path = './Covid_M/all/test/covid/nejmoa2001191_f3-PA.jpeg'
#image_path = './Covid_M/all/test/normal/NORMAL2-IM-1400-0001.jpeg'
#image_path = './Covid_M/all/test/pneumonia_bac/person1940_bacteria_4859.jpeg'
b64_image = ""
# JPGやPNGなどの画像をbase64形式にエンコード
with open(image_path, "rb") as imageFile:
    b64_image = base64.b64encode(imageFile.read())# APIに送信されるデータ
data = {'b64': b64_image}# POSTリクエストを送信しレスポンスをレスポンスオブジェクトとして保存
r = requests.post(url=API_ENDPOINT, data=data)print(r.status_code, r.text)# レスポンスを抽出
print("{}".format(r.text))

このようなすべてのテスト画像もGitHubにアップロード済みです。上記のコードの結果は以下のようになります。

200 {"Input_Image":"http://localhost:8051/static/source/0198f0ae-85a0-470b-bc31-dc1918c15b9620200906-170443.png","Output_Heatmap":"http://localhost:8051/static/result/Covid19_98_0198f0ae-85a0-470b-bc31-dc1918c15b9620200906-170443.png.png","X-Ray_Classfication_Raw_Result":[[0.805902302,0.15601939,0.038078323]],"X-Ray_Classification_Covid19_Probability":0.98,"X-Ray_Classification_Result":"Covid-19 POSITIVE","model_name":"Customised Incpetion V3"}

{"Input_Image":"http://localhost:8051/static/source/0198f0ae-85a0-470b-bc31-dc1918c15b9620200906-170443.png","Output_Heatmap":"http://localhost:8051/static/result/Covid19_98_0198f0ae-85a0-470b-bc31-dc1918c15b9620200906-170443.png.png","X-Ray_Classfication_Raw_Result":[[0.805902302,0.15601939,0.038078323]],"X-Ray_Classification_Covid19_Probability":0.98,"X-Ray_Classification_Result":"Covid-19 POSITIVE","model_name":"Customised Incpetion V3"}

CPU times: user 16 ms, sys: 0 ns, total: 16 ms
Wall time: 946 ms

3. デモサービスAPIをベンチマークテストする

HAProxyロードバランサーインスタンスをセットアップします。また、Flaskサービスを4個のワーカーで開始し、FastAPIサービスも4個のワーカーで開始しました。

ノートブックファイルで直接8個のPythonプロセスを作成し、8個の同時APIクライアントがデモサービスAPIにリクエストを送信する様子をエミュレートしてみてはどうでしょうか。

#from concurrent.futures import ThreadPoolExecutor as PoolExecutor
from concurrent.futures import ProcessPoolExecutor as PoolExecutor
import http.client
import socket
import timestart = time.time()#laodbalancer:
API_ENDPOINT_LB = "http://172.17.0.1:8088/covid19/api/v1/predict/heatmap"
API_ENDPOINT_FLASK = "http://172.17.0.1:8052/covid19/api/v1/predict/heatmap"
API_ENDPOINT_FastAPI = "http://172.17.0.1:8057/covid19/api/v1/predict/heatmap"
def get_it(url):
    try:
        # 画像をループ
        for imagePathTest in imagePathsTest:
            b64_image = ""
            with open(imagePathTest, "rb") as imageFile:
                b64_image = base64.b64encode(imageFile.read())
    
            data = {'b64': b64_image}
            r = requests.post(url, data=data)
            #print(imagePathTest, r.status_code, r.text)
        return r
    except socket.timeout:
        # 実際のケースではおそらく
        # ソケットがタイムアウトする場合に何かを行うでしょう
        passurls = [API_ENDPOINT_LB, API_ENDPOINT_LB, 
        API_ENDPOINT_LB, API_ENDPOINT_LB, 
        API_ENDPOINT_LB, API_ENDPOINT_LB, 
        API_ENDPOINT_LB, API_ENDPOINT_LB]with PoolExecutor(max_workers=16) as executor:
    for _ in executor.map(get_it, urls):
        pass
    
print("--- %s seconds ---" % (time.time() - start))

したがって、8x27 = 216個のテスト画像を処理するのに74秒かかっています。これは負荷分散されたデモスタックが、（分類とヒートマップの結果をクライアントに返すことで）1秒間に3個の画像を処理できています。

--- 74.37691688537598 seconds ---

PuttyセッションのTopコマンドから、上記のベンチマークスクリプトが実行開始されるとすぐに8個のサーバープロセス（4個のGunicornと4個のUvicorn/Python）がランプアップし始めたことがわかります。

今後の内容

この記事は、テストフレームワークとして「全DockerによるAIデモ」のデプロイメントスタックをまとめるための出発点に過ぎません。次は、Covid-19 ICU入室予測インターフェースなどさらに多くのAPIデモインターフェースを理想としてはFHIR R4などによって追加し、サポートDICOM入力形式を追加したいと思います。これは、IRISがホストするML機能とのより緊密な統合を検討するためのテストベンチになる可能性もあります。医用画像、公衆衛生、またはパーソナル化された予測やNLPなど、さまざまなAIフロントを見ていく過程で、徐々に、より多くのMLまたはDL特殊モデルを傍受するためのテストフレームワーク（非常に単純なテストフレーム）として使用していけるでしょう。ウィッシュリストは、前の投稿（「今後の内容」セクション）の最後にも掲載しています。

#開発者コミュニティ公式 #Artificial Intelligence (AI) #IntegratedML #コンテナ化 #Machine Learning (ML) #継続的インテグレーション #継続的デリバリー

Open Exchange

1 0

0 550

記事 Toshihiko Minamoto · 2月 9, 2022 2m read

IRIS-NativeAPI-Nodejs-compact (jp)

これは、前回の「DockerマイクロサーバーとしてのIRIS Native APIを使用するWebSocketクライアントJS」のフォローアップです。

すべてのピースが1つのDockerイメージにまとめられたため、インストールがはるかに簡単になりました。
作業が楽になります。ただしもちろん、マイクロサービスの原則はわかりにくくなくなっています。
オールインワンのバンドルパッケージであるため、コンパクトになっています。

動作には変更がないため、下位互換性のあるマイナーリリースと解釈されてしまう可能性があります。

これには、intersystems/iris-community:2020.2.0.204.0が含まれています。

実行するのは、以下の通りです。

docker pull rcemper/rcc:iris-nodejs-compact（1回）
docker run --rm --init -d \ --name=iris1 -p 52773:52773 -p 51773:51773 \ rcemper/rcc:iris-nodejs-compact （コンテナーを起動）
docker exec -it iris1 bash wsgo.sh （マイクロサービスを起動）
docker exec -it iris1 bash wsdemo.sh （テストデータを作成する制御を開始し、echoServerに送信して受信）
docker exec -it iris1 bash wsstop.sh （制御から実行されない場合は、最終的にサービスを停止）
docker stop iris1 （コンテナーを終了）

それだけです。

2021年7月7日:
正規化されたV2がリリースされました。

git clone https://github.com/rcemper/IRIS-NativeAPI-Nodejs-compact.git
docker-compose up -d
docker-compose exec iris iris session iris %ZSocket
docker-compose exec iris node WsockIris.js

#InterSystems IRIS #Docker #JavaScript #Microservices #Node.js #ObjectScript #コンテスト #コンテナ化

Open Exchange

0 0

0 280

記事 Toshihiko Minamoto · 2月 1, 2022 5m read

DockerマイクロサーバーとしてIRIS Native APIを使用したWebSocketクライアントJS

これはIRIS 2020.2で動作するコーディングの例です 
最新バージョンとは同期していません。
また、InterSystemsのサポートによるサービスはありません

動作中のデモを確認できるデモビデオを以下で公開しています。https://youtu.be/dSV-0RJ5Olg

皆さんこんにちは
完全に新しいIRISイメージと**たった4行**のDockerコマンドを使って実行するイメージを使ってマイクロサービスのデモを行いましょう。
2020年6月1日 - rcc

すべてのパーツを1つのコンテナイメージにまとめたコンパクトなオールインワンバージョンが公開されました。
詳細はこちら: IRIS-NativeAPI-Nodejs-compact
2020年5月24日 - rcc

Dockerを使った簡易インストールを追加しました。コンテキストを参照
2020年5月25日 - rcc

Linux & Windowsに最適な検証済みの強化スクリプトはこちら
https://github.com/rcemper/WSockClientMicroSV/blob/master/READMEwindows.MD
2020年5月26日 - rcc

このデモは、Caché用にすでに存在するNode.jsに基づくWebSocketクライアントを再設計したものです。主に以下のような変更点があります。

新しいIRIS Native API for Node.jsの使用。特にグローバル配列を操作する場合
直接トリガーされたクライアントからサーバー設計への変更
マイクロサービス/マイクロサーバーの例として、結果を別のdockerイメージに配置
マイクロサービスの実行を制御するための単純なインターフェースをIRISに追加

ユーティリティをIRISホストで直接呼び出す代わりに、System Interoperability（別名 ENSEMBLE）で通常行うようにして、work-packagesをMicroServiceに送信します。
もちろん、2つ以上のWebSocketサーバーオプションがあります。
WebSocketクライアントサービスがジョブを完了したら、その結果を取得します。

組み込みのWebSocketクライアントに対するメリットは、すべてのネットワーク、セキュリティ、ファイアウォールの問題を主要なデータサーバーに寄せ付けないことです。 Node.js がこの分野で持っている経験と品質については言うまでもありません。

デモは wss: デフォルトのechoサーバーとして使用します。
次に、テキストを数行入力します。
独自のテキストの任意の場所に「Lorem Ipsum」を追加して、コンテンツを長くすると良いでしょう。
そして、それをサービスに送信して、エコーを待ちます。
また、制御プログラムをExitまたはサービスをStopする前に、
テキストを変更するオプションもあります。

この処理はすべて非同期で実行されます。
完了を待たずに、それまでにechoサーバーから受信した内容を、リスナーが
定期的に表示します。

インストールするには、以下が必要です。

IRISのdocker イメージ（intersystems/iris-community:2020.2.0.199.0）
WebSocketマイクロサーバーのdockerイメージ（docker pull rcemper/rcc:demoJS）
簡略化されたinit: initに次のdockerコマンドを実行してください。 docker run --name ini1 --init -it --rm \ -privileged -v $(pwd):/external \ rcemper/rcc:demoJS bash /rcc/init.sh ### 元のアプローチは有効ではありますが、必須ではありません。 ###
IRIS-Docker-micro-Durabilityを利用するためにOpen Exchangeまたはここから入手したWSockClientMicroSV.tar.gz
demoディレクトリの確認: Dockerイメージはnobodyであるため、保護をrwx (chmod 777) に設定します。###

これを実行するには、まずdemoディレクトリからIRISを起動します（-dまたは-itを実行して動作を観察します）。（！）

docker run --name iris1 --init --rm -d \
-p 52773:52773 -p 51773:51773 \
-v $(pwd):/external \
intersystems/iris-community:2020.2.0.199.0 \
-b /external/pre.copy

次にMicroServerを起動します。

docker run --name rcc1 --init -it --rm \
rcemper/rcc:demoJS /usr/bin/node /rcc/nodejs/WSockIris.js $(hostname -I)

. -itを使って起動したため、以下が表示されます。

platform = linux: ubuntu  

    *****************************  
    Connect to IRIS on: 192.168.0.23  
Successfully connected to InterSystems IRIS.  
    *** wait 3sec for request ***  
    ******* Startup done ********  

    *** wait 3sec for request ***  
    *** wait 3sec for request ***

次に、新しいLinuxターミナルで制御アプリケーションを実行します。

docker exec -it iris1 iris session iris ZSocket

以下が表示されます。

*** Welcome to WebSocket Micoservice demo ***  
Known Hosts (*=Exit) [1]:  
1  wss://echo.websocket.org/  
2  --- server 2 ----  
3  --- server 3 ----  
select (1):  ==> wss://echo.websocket.org/  
#
Enter text to get echoed from WebSocketClient Service
Terminate with * at first position
or get generated text by %
or append new text with @

1    hello socket microServer
2    now you got 2 lines
3    *

Select action for WebClient Service
New EchoServer (E), Send+Listen(S),New Text(N),Exit(X), Exit+Stop Client(Z) [S]s
%%%%%%%%%%%%%%%%%%%%%%%%%%

******* 0 Replies *******

******* 2 Replies *******
1    hello socket microServer
2    now you got 2 lines


Select action for WebClient Service

マイクロサービスでは以下が表示されます。

*** wait 3sec for request ***
echoserver:  wss://echo.websocket.org/
** Lines to process: 1 **
********* next turn *********
* WebSocket Client connected *
****** Client is ready ****** 

Line: 1 text> 'hello socket microServer '
Received: 1 > 'hello socket microServer '

Line: 2 text> 'now you got 2 lines '
Received: 2 > 'now you got 2 lines '

******* lines sent: 2 ******
*** replies received: 2 ****

*** wait 3sec for request ***

事後警告。イメージのバージョンを必ず確認してください！
私はntersystems/iris-community:2020.2.0.204にハマってしまいました。

注意: すべてのスクリプトはLinuxでのみテストされています！

#InterSystems IRIS #Docker #JavaScript #Microservices #Node.js #ObjectScript #グローバル #コンテスト #コンテナ化

Open Exchange

0 0

0 313

記事 Toshihiko Minamoto · 10月 13, 2021 6m read

Dockerのディスクスペースの扱いについて

@Evgeny.Shvarovの記事へのコメントとして書こうとしていましたが、コメントが長すぎたため、別に投稿することにしました。

dockerがすべてのイメージをクリーンアップした結果の画像

dockerがどのようにディスクスペースを使用し、クリーンアップするかについて、少し説明を加えたいと思います。私はmacOSを使用しているため、以下に示すものは主にmacOSを対象としていますが、dockerコマンドはすべてのプラットフォームでも使用できます。

dockerはLinuxに由来しますが、デフォルトで同じファイルシステムで動作します。ただし、WindowsとmacOSでは、Linuxがインストールされた小さな仮想マシンで動作します。また、ディスクのスペースはdocker内の設定で制限されています。私の場合は、最大112GBを使用するように構成されています。

そのため、活発にDockerを使用している場合、スペースが無くなってしまいます。 dockerがスペースをどのように消費しているのかは、次のコマンドで確認できます。

$ docker system df
TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              84                  6                   66.02GB             55.6GB (84%)
Containers          6                   5                   4.914GB             0B (0%)
Local Volumes       19                  4                   1.812GB             342.7MB (18%)
Build Cache         0                   0                   0B                  0B

最新バージョンのDockerを使ったmacOSでは、raw形式のディスクを使用していました（以前はqcow2）。そして、macOSのAPFSファイルシステムと合わせると、このファイルはファイスサイズ自体よりも少ない物理スペースを占める可能性があります。以下の2つのコマンドを見てください。

$ ls -lh ~/Library/Containers/com.docker.docker/Data/vms/0/Docker.raw
-rw-r--r--@ 1 daimor  staff   104G Jul 13 15:49 /Users/daimor/Library/Containers/com.docker.docker/Data/vms/0/Docker.raw

$ du -h ~/Library/Containers/com.docker.docker/Data/vms/0/Docker.raw
 88G    /Users/daimor/Library/Containers/com.docker.docker/Data/vms/0/Docker.raw

lsコマンドは、Docker.rawファイルのサイズを104Gbと示すのに対し、duコマンドはディスク上の実際のサイズである88Gbを示しています。

さて、docker system dfによれば、一部のスペースを取り戻せるようですので、そうしてみましょう。

$ docker system prune -f
Deleted Containers:
79b3d54ae5a881e37771cfdc1d651db9ce036abc297dc55bdd454eb287f0e329

Deleted Images:
deleted: sha256:298d555976effb112428ed3f6bcc2f4d77ab02b4f287a230d9535001184078f5
deleted: sha256:adb2c64ce6e44d837fce8067c7498574822bff90ed599d1671c126539fe652ac
deleted: sha256:9695172139cec16f1071449daf29bd1c424353044088b92b8acbf33f59952e67
deleted: sha256:24d834b252e25e645b8b5d9194360f5ab1a26ffd2b5c03b6593b9a2c468f59fa
deleted: sha256:1b4e3e73fe0b7d88d5ec718bdc6dc6d17d9fe8ba00988eb72690d76f2da3d1a3
deleted: sha256:9f218f6c7aca9c21760ae43590a2d73b35110e10b6575125ed3ccd12c4495d6e
deleted: sha256:b2fa3335d672a0dc60ea7674c45ee3c85b9fc86584a0e21cc7f1900c368ceec3
deleted: sha256:2ecace396ab65fd393dfb2e330bece974cd952e7a41364352f9c867d9ea4c34e
deleted: sha256:16b894351fe53b95dd43d7437bbbcd5104b8613bc1fa8480826e843d65fc92a3
deleted: sha256:b00d9c05035eac62f3ed99a814cd6feea3e4b68797b6d1203e2f41538c78c2aa
deleted: sha256:5a3d0d9f36b356cb47d3838585da6450c60e2860ef143d1406b48d3a5e72b92b
deleted: sha256:998e719368ff74d13b3a8c096ce81f8f2c4bb28bd1ccd169bfa173b4a78d2e74
deleted: sha256:a74d7ff2ca7d623134f9ce1db40da476134a733935a3f322ba34b99653c6273d
deleted: sha256:4d0dcd2bdad2cf0cb91d13313afff29326771bdac27fcb8780545687dbd39ae4
deleted: sha256:29a8989eed3d4002053f98bf562654910ee5f8836940daaa2f2344a8f29a52a2
deleted: sha256:12d34fbf938d19b193199ea6cce5d690fd0d57ec3f4d1630e1d4b3790379c9ec
deleted: sha256:75aba481bb5ccaa52a3aadf311ae22485fb2a82d69be864fe2f45f2834c5e515
deleted: sha256:326efafee9b92e06876878b21a2931ba771bc0e0b2b359f906ef6cca1d297905
deleted: sha256:913937f4ea932fcb00b6c6b3007970296955aa4f488d6fbaa1a575a5aa4ff5ab
deleted: sha256:f3fc0c75858a36ff9d3f4e8eb7a96f511158bbac92d128760b0d3340d828c5da
deleted: sha256:c002dde1ea6a02ae3e3037442a5c556a925e3e4750a6b2aa923c51fa3d11f5ac
deleted: sha256:e763f6e226613c67aaf5984e4c74b9f6e9e28e0490a4f3286885f498a57d3fa0
deleted: sha256:e7daf0a1574376c8602515dc70e44392d16e1b79013d6e81a9b697794432e660
deleted: sha256:ce33670f78109dcacc73a7c6d70f4b5cd4a13bcfe7878b9df5e4e16b812e5df4
deleted: sha256:95bf79e86f83ed16943f9c34035bf8167a4b89466a05d6793c2957d6d46bab2d
deleted: sha256:056d184391613b33303ccf3818a95a17398e9da813d093a6ee5d87952539380c

Total reclaimed space: 5.537GB

このコマンドは、停止したコンテナと、タグ付けされたイメージが使用していないタグ付けされていないイメージをすべて削除します。また、削除は安全です。

docker system dfは55GBと示したのに足し、取り戻せたのはわずか5.5GBであることに気づいたかもしれません。これは、dfはぶら下がったイメージだけでなく、アクティブでないイメージもすべてカウントするためです。それらのイメージもすべて削除する場合は、このコマンドを使用できます。これは、現在実行中のコンテナで使用されていないすべてのイメージを削除します。そのため、実行しているコンテナがない場合は、すべてのローカルイメージが削除されます。

docker system prune -a

ぶら下がったイメージのみを取り戻し、コンテナを停止しました。 dockerはどれくらいのスペースを使用しているでしょうか。

$ docker system df
TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              83                  5                   60.48GB             50.1GB (82%)
Containers          5                   5                   4.914GB             0B (0%)
Local Volumes       19                  3                   1.812GB             342.7MB (18%)
Build Cache         0                   0                   0B                  0B

ご覧のとおり、すでに使用サイズが小さくなりました。 lsも同じ結果となるでしょう。おそらく、このファイルサイズは大きくなります。

$ ls -lh ~/Library/Containers/com.docker.docker/Data/vms/0/Docker.raw
-rw-r--r--@ 1 daimor  staff   104G Jul 13 16:07 /Users/daimor/Library/Containers/com.docker.docker/Data/vms/0/Docker.raw

ただし、macOSの場合、物理ディスクで使用されているスペースが最も重要です。

$ du -h ~/Library/Containers/com.docker.docker/Data/vms/0/Docker.raw
 69G    /Users/daimor/Library/Containers/com.docker.docker/Data/vms/0/Docker.raw

ご覧の通り、現在は69GBとなり、以前よりも約19GB少なくなっています。

したがって、macOSユーザーの場合は、ファイルのサイズはそれほど重要ではなく、APFS最適化を使用すれば、実際には小さくすることができます。

古いイメージを整理するもう一つの方法は、作成日でフィルタすることです。この例のように、10日以上前に作成されたすべてのイメージが削除されますが、コンテナが現在使用しているイメージは保持されます。

$ docker image prune --all --filter until=240h

#Caché #InterSystems IRIS #Docker #クラウド #コンテナ化 #システム管理

2 0

0 7310

記事 Toshihiko Minamoto · 9月 1, 2021 8m read

Amazon EKSとIRIS。高可用性とバックアップ

記事で使用されているすべてのソースコード: https://github.com/antonum/ha-iris-k8s

前の記事では、従来型のミラーリングではなく分散ストレージに基づいて、高可用性のあるk8sでIRISをセットアップする方法について説明しました。その記事では例としてAzure AKSクラスタを使用しました。この記事では引き続き、k8sで可用性の高い構成を詳しく見ていきますが、今回は、Amazon EKS（AWSが管理するKubernetesサービス）に基づき、Kubernetes Snapshotに基づいてデータベースのバックアップと復元を行うためのオプションが含まれます。

インストール

早速作業に取り掛かりましょう。まず、AWSアカウントが必要です。AWS CLI、kubectl、およびeksctlツールがインストールされている必要があります。新しいクラスタを作成するために、次のコマンドを実行します。

eksctl create cluster \
--name my-cluster \
--node-type m5.2xlarge \
--nodes 3 \
--node-volume-size 500 \
--region us-east-1

このコマンドは約15分掛けてEKSクラスタをデプロイし、それをkubectlツールのデフォルトのフォルダに設定します。デプロイを確認するには、次のコードを実行します。

kubectl get nodes
NAME                                             STATUS   ROLES    AGE   VERSION
ip-192-168-19-7.ca-central-1.compute.internal    Ready    &lt;none>   18d   v1.18.9-eks-d1db3c
ip-192-168-37-96.ca-central-1.compute.internal   Ready    &lt;none>   18d   v1.18.9-eks-d1db3c
ip-192-168-76-18.ca-central-1.compute.internal   Ready    &lt;none>   18d   v1.18.9-eks-d1db3c

次に、Longhorn分散ストレージエンジンをインストールします。

kubectl create namespace longhorn-system
kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.1.0/deploy/iscsi/longhorn-iscsi-installation.yaml --namespace longhorn-system
kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/master/deploy/longhorn.yaml --namespace longhorn-system

そして最後に、IRIS自体をインストールします。

kubectl apply -f https://github.com/antonum/ha-iris-k8s/raw/main/tldr.yaml

この時点で、Longhorn分散ストレージとIRISデプロイがインストールされたEKSクラスタが完全に機能できる状態になります。前の記事に戻って、クラスタとIRISデプロイにあらゆるダメージを与えて、システムがどのように修復するのかを確認するとよいでしょう。「障害をシミュレートする」セクションをご覧ください。

特典1 ARM上のIRIS

IRIS EKSとLonghornはARMアーキテクチャをサポートしているため、ARMアーキテクチャに基づき、AWS Gravition 2インスタンスを使用して同じ構成をデプロイできます。

EKSノードのインスタンスタイプを 'm6g' ファミリーに変更し、IRISイメージをARMベースに変更するだけです。

eksctl create cluster \
--name my-cluster-arm \
--node-type m6g.2xlarge \
--nodes 3 \
--node-volume-size 500 \
--region us-east-1

tldr.yaml

containers:
#- image: store/intersystems/iris-community:2020.4.0.524.0
- image: store/intersystems/irishealth-community-arm64:2020.4.0.524.0
name: iris

または、単に以下を使用します。

kubectl apply -f https://github.com/antonum/ha-iris-k8s/raw/main/tldr-iris4h-arm.yaml

以上です！ ARMプラットフォームで実行するIRIS Kubernetesクラスタが出来上がりました。

特典2 - バックアップと復元

本番環境グレードのアーキテクチャでよく見過ごされがちな部分に、データベースのバックアップを作成して必要なときに素早く復元するか複製する機能があります。

Kubernetesでは、一般的にPersistent Volume Snapshots（永続ボリュームスナップショット）を使用してこれを行います。

まず、必要なすべてのk8sコンポーネントをインストールする必要があります。

#Install CSI Snapshotter and CRDs

kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml
kubectl apply -n kube-system -f https://github.com/kubernetes-csi/external-snapshotter/raw/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml
kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml
kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml
kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/rbac-snapshot-controller.yaml

次に、LonghornのS3バケット資格情報を構成します（詳細な手順を参照）。

#Longhorn backup target s3 bucket and credentials longhorn would use to access that bucket
#See https://longhorn.io/docs/1.1.0/snapshots-and-backups/backup-and-restore/set-backup-target/ for manual setup instructions
longhorn_s3_bucket=longhorn-backup-123xx #bucket name should be globally unique, unless you want to reuse existing backups and credentials
longhorn_s3_region=us-east-1
longhorn_aws_key=AKIAVHCUNTEXAMPLE
longhorn_aws_secret=g2q2+5DVXk5p3AHIB5m/Tk6U6dXrEXAMPLE

以下のコマンドは、前の手順から環境変数を拾い、それを使ってLonghorn Backupを構成します。

#configure Longhorn backup target and credentials

cat &lt;&lt;EOF | kubectl apply -f -
apiVersion: longhorn.io/v1beta1
kind: Setting
metadata:
 name: backup-target
 namespace: longhorn-system
value: "s3://$longhorn_s3_bucket@$longhorn_s3_region/" # backup target here
---
apiVersion: v1
kind: Secret
metadata:
 name: "aws-secret"
 namespace: "longhorn-system"
 labels:
data:
 # echo -n '&lt;secret>' | base64
 AWS_ACCESS_KEY_ID: $(echo -n $longhorn_aws_key | base64)
 AWS_SECRET_ACCESS_KEY: $(echo -n $longhorn_aws_secret | base64)
---
apiVersion: longhorn.io/v1beta1
 kind: Setting
metadata:
 name: backup-target-credential-secret
 namespace: longhorn-system
value: "aws-secret" # backup secret name here
EOF

たくさんの作業に見えるかもしれませんが、基本的にLonghornに対し、指定された資格情報で特定のS3バケットを使用し、バックアップのコンテンツを保存するように指示しています。

以上です！ Longhorn UIに移動すると、バックアップを作成して復元などを行えるようになっています。

Longhorn UIに接続する方法を簡単におさらいしましょう。

kubectl get pods -n longhorn-system
# note the full pod name for 'longhorn-ui-...' pod
kubectl port-forward longhorn-ui-df95bdf85-469sz 9000:8000 -n longhorn-system

これによって、Longhorn UIへのトラフィックはhttp://localhost:9000に転送されるようになります。

プログラムによるバックアップ/復元

Longhorn UIを介して行うバックアップと復元は、最初のステップとしては十分かもしれませんが、もう一歩先に進み、k8s Snapshot APIを使用して、プログラムでバックアップと復元を実行してみましょう。

まず、スナップショットそのものが必要です。 iris-volume-snapshot.yaml

apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshot
metadata:
  name: iris-longhorn-snapshot
spec:
  volumeSnapshotClassName: longhorn
  source:
    persistentVolumeClaimName: iris-pvc

このボリュームスナップショットは、IRISデプロイに使用するソースボリュームである 'iris-pvc' を参照しています。そのため、これを適用するだけですぐにバックアッププロセスが開始します。

IRIS書き込みデーモンの凍結と解凍をスナップショットの前後に実行することをお勧めします。

#Freeze Write Daemon
echo "Freezing IRIS Write Daemon"
kubectl exec -it -n $namespace $pod_name -- iris session iris -U%SYS "##Class(Backup.General).ExternalFreeze()"
status=$?
if [[ $status -eq 5 ]]; then
 echo "IRIS WD IS FROZEN, Performing backup"
 kubectl apply -f backup/iris-volume-snapshot.yaml -n $namespace
elif [[ $status -eq 3 ]]; then
 echo "IRIS WD FREEZE FAILED"
fi
#Thaw Write Daemon
kubectl exec -it -n $namespace $pod_name -- iris session iris -U%SYS "##Class(Backup.General).ExternalThaw()"

復元プロセスは非常に簡単です。基本的には、新しいPVCを作成して、スナップショットをソースとして指定しています。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: iris-pvc-restored
spec:
  storageClassName: longhorn
  dataSource:
    name: iris-longhorn-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

次に、このPVCに基づいて新しいデプロイを作成するだけです。これを順に行うこちらのGitHubリポジトリにあるテストスクリプトをご覧ください。

まったく新しいIRISデプロイを作成します。
IRISにデータを追加します。
書き込みデーモンを凍結し、スナップショットを取得して、書き込みデーモンを解凍します。
そのスナップショットをベースに、IRISデプロイのクローンを作成します。
すべてのデータが含まれていることを確認します。

この時点で、同一のIRISデプロイが2つ存在することになります。1つはもう片方のデプロイのclone-via-backupです。

どうぞお楽しみください！

#InterSystems IRIS #InterSystems IRIS for Health #Open Exchange #AWS #DevOps #クラウド #コンテナ化 #デプロイ #バックアップ #高可用性

Open Exchange

0 0

0 764

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

コンテナ - コンテナとは？

コンテナ

InterSystems IRIS Data Platformの公開により、Dockerコンテナでも製品を提供しています。コンテナとは一体何でしょうか。

基本的なコンテナの定義は、プロセスのサンドボックスの定義です。

コンテナは、たとえば実行できるという点において、仮想マシン（VM）に似た部分を持つソフトウェア定義パッケージです。

コンテナは、完全なOSエミュレーションを使わずに分離することができるため、 VMよりもはるかに軽量です。

本質的に、コンテナは、どのようにアプリケーションをシステムから別のシステムに確実に移動し、それが動作することを保証できるのかという問題に対する答えと言えます。アプリケーションのすべての依存関係をコンテナにカプセル化し、プロセス分離領域を作成することにより、アプリケーションソリューションがプラットフォーム間で移動した場合でも動作するという高い保証を得ることができます。

プロセスは、オペレーティングシステムによって実行が可能です。これらのプロセスはアドレス領域、ネームスペース、cgroupなどを共有し、通常、OSの環境全体にアクセスすることができます。それらのスケジュールと管理は、OSが行います。すべて良いことではありますが、特定のプロセスやいくつかのプロセスを分離して、特定のタスクや演算、またはサービスを実行したい場合はどうでしょうか。手短に言えば、プロセスを分離できる機能こそ、コンテナが提供している機能なのです。したがって、コンテナをプロセスのサンドボックスとして定義することができるでしょう。

では、サンドボックスとは何でしょうか。サンドボックスは、コンテナがプロセスを持つ分離レベルです。この機能は、ネットワークインターフェース、マウントポイント、インタープロセス通信（IPC）、ユニバーサルタイムシェアリング（UTS）といったシステムのほかの重要な部分もサンドボックス化することのできるネームスペースと呼ばれるLinuxのカーネル機能により実装されています（https://en.wikipedia.org/wiki/Linux_namespaces）。

コンテナまたはサンドボックスは、制御グループまたはcgroupと呼ばれる別のカーネル機能によっても管理または制御することができます（https://en.wikipedia.org/wiki/Cgroups）。コンテナがほかのコンテナやホストとリソースを共有する上で、ほかのネイバーに害を与えないように、コンテナにルールが適用されます。

コンテナとVMの違いを理解するには、VMを_家_に、そしてコンテナを_マンション_に例えることができます。

VMは、一軒家のように、自己完結型で独立しています。それぞれの家には、配管、暖房、電気といった固有のインフラストラクチャが備わっており、最低要件も与えられています（最低、寝室は1室、屋根は1つなど）。

一方のコンテナは、共有のインフラストラクチャを使用するように作られているため、マンションとして捉えることができます。マンションの建物は、配管、暖房、電機システム、正面玄関、エレベーターなどを共有していますが、これと同様に、コンテナも、Linuxカーネルを通じてホストが提供しているリソースを使用します。また、マンションの各居住戸のサイズや形には様々なものがあることも考えましょう。

コンテナには完全なOSはなく、/binの実行可能ファイルや /etcの構成ファイルと定義ファイルといった、最小限必要なLinux OSしか備わっていないため、サイズが非常に小さくなります。そのため、その場所を移動したり、スピンアップする場合に、一秒きっかりで敏速に行うことができます。コンテナを構築した瞬間から、ソフトウェアファクトリーのプロビジョニングパイプラインを通じ、本番環境での最終実行に至るまで、アジリティを得られることになります。ちなみに、コンテナはCI/CDマイクロサービスアーキテクチャのコンテキストにピッタリと収まりますが、これはまた別の機会にお話ししましょう。

コンテナ内のプロセスは、コンテナのライフサイクルと密接な関係があり、コンテナを_起動_すれば、アプリのすべてのサービスも起動して実行し（たとえば、あるWebサーバーコンテナのポート80と、InterSystems IRISコンテナのポート57772と1972）、コンテナを_停止_すれば、すべてのプロセスも停止します。

この記事では、コンテナのランタイムの基本的な概念について説明しました。コンテナは、プロセスをホストやその他のコンテナから分離するサンドボックスです。

コンテナを理解するには、そのイメージに関する別の側面もあります。これについては、第2部の記事で説明することにします。

#InterSystems IRIS #Docker #クラウド #コンテナ化 #システム管理 #ベストプラクティス

0 0

0 403

記事 Mihoko Iijima · 5月 28, 2021 8m read

キーバリュー形式で Python / Node.js / Java から IRIS にアクセスできるテンプレート（グラフ構造によくある人物相関図を IRIS で表現しています）

開発者の皆さん、こんにちは🌂 今年は早い梅雨入りでした ☔

さて、新しい✨ 実行／開発環境テンプレートを作成しました。 Docker 🐳、docker-compose 、git がインストールされていれば、すぐにお試しいただけます。ぜひご利用ください！

今回は、ご存知の方が多いと思われる（？）某アニメの登場人物を使った人物相関図をテーマに【キーバリュー形式で IRIS に登録してグラフ構造で表示してみた】を体験できるテンプレートです（テンプレートは、Python／Node.js／Java からお試しいただける環境をご用意しています）。

人物相関図のイメージ

以下、今回のテーマについて、ビデオと文字でご紹介しています。最後までお付き合いいただければ幸いです！（ビデオは全体で 7 分 20 秒）

人物相関図と言えば、グラフデータベースをイメージされると思います。

IRIS はグラフデータベースではないのですが、IRIS ネイティブのデータの「グローバル」を利用することで、グラフデータベースと似たような構造を表現することができます。

#InterSystems IRIS #InterSystems IRIS for Health #Java #Node.js #Python #キーバリュー #コンテナ化 #初心者

0 0

0 466

記事 Mihoko Iijima · 5月 7, 2021 10m read

GPS（GPX）データを InterSystems IRIS に高速に取り込む方法を体験できる実行環境テンプレート

開発者の皆さん、こんにちは！

この記事では、Java から IRIS へ接続する方法の中から XEP（ゼップ）を利用して、GPS （GPX）データを高速に取り込むサンプルをご紹介します。

Java の実行環境や IRIS がお手元になくても大丈夫です！コンテナ 🐳 のビルド＋開始で体験できる「実行環境テンプレート」をご用意しました。

ソースコードはコミュニティの Git で公開していますので、docker、docker-compose 、git がインストールされた環境であれば、すぐにお試しいただけます（Javaの実行環境はコンテナでご提供するので準備不要です）。

操作方法は、Gitの README に記載しています。ぜひお試しください。

この記事の中では、コード解説を追加しています。ぜひ、最後までお付き合いください！

1)処理概要

GPX データを IRIS へ渡す迄の流れにリアクティブプログラミングが行える RxJava2 のライブラリを使用しています。

メモ：サンプルコードの中では、GPS データを直接受信するのではなく、Google マイマップやサンプル GPS データから GPX ファイルに変換したデータを入力に使用しています。

#InterSystems IRIS #InterSystems IRIS for Health #Java #オブジェクトデータモデル #コンテナ化

0 0

0 260

InterSystems公式 Toshihiko Minamoto · 4月 24, 2021

InterSystems Container Registryのご紹介

みなさん、こんにちは。
今回はInterSystems Container Registryを発表できることをうれしく思います。これはコンテナベースのリリースやプレビューにアクセスする新たな配布チャンネルです。すべてのコミュニティエディションのイメージはログイン不要の公開リポジトリにあります。すべてのリリースイメージ（IRIS, IRIS for Health, Health Connect, System Alerting and Monitoring, InterSystems Cloud Manager) やユーティリティイメージ(アービター、 Web Gateway、PasswordHash等) にはWRCアカウントの認証情報から生成されるログイントークンが必要です。

#InterSystems IRIS #InterSystems IRIS for Health #InterSystems公式 #DevOps #Docker #Kubernetes #コンテナ化 #リリース #継続的インテグレーション #継続的デリバリー

0 0

0 383

記事 Makiko Kokubun · 4月 20, 2021 1m read

動画：Dockerコンテナ版 InterSystems IRIS data platform の勧め

*この動画は、2021年2月に開催された「InterSystems Japan Virtual Summit 2021」のアーカイブです。

ソフトウェア開発技術において、プロセスの自動化、サイクルの短縮による生産性の向上を目指す考え方が普及してきました（CI/CD）。CI/CDの中核をなす技術の一つが、Dockerに代表されるコンテナです。

InterSystemsでは、Dockerコンテナで動作するIRIS data platformをリリースして、いち早く最新機能を皆様にお届けしています。この動画をご覧になって、DockerコンテナでIRISをスムーズに利用する第一歩としてください。

セッションで紹介しているリリースサイクルについては、こちらの記事をご覧ください。
セッションではデモを行っています。デモをご覧になりたい方は 12:49 からご覧ください。

#InterSystems IRIS #Docker #Webセミナー #コンテナ化

0 0

0 248

記事 Mihoko Iijima · 2月 1, 2021 3m read

開発環境テンプレート（IRIS プログラミングコンテストで使用していたテンプレート）の一覧

開発者のみなさん、こんにちは！

IRIS プログラミングコンテストでは、💨すぐに💨開発を開始いただけるようにコンテナ版 IRIS を利用した「開発環境テンプレート」をご提供してしていました。

終了したコンテストにはご応募いただけませんが、テンプレートは「ちょっと試したい」「加工して自分オリジナル環境を作りたい」の目的にぴったりの内容です。

また、全て Open Exchange で公開されていて、Docker、Git、VSCode をインストールした環境があればすぐにご利用いただけます。

テンプレートの使用方法については、各コンテストの紹介ページでご案内しています（日本語解説ビデオ付きもあります）。

基本は以下 3 行だけで開始できます。（とっても簡単！）

git clone <ここにテンプレートのURL>

cd <作成されたディレクトリ>

docker-compose up -d --build

ご興味ある内容ありましたら、ぜひお手元で試してみてください！

#InterSystems IRIS #InterSystems IRIS for Health #VSCode #Docker #コンテスト #コンテナ化

0 0

0 362

記事 Toshihiko Minamoto · 1月 13, 2021 2m read

Docker コンテナ内で InterSystems IRIS と Package Manager を併用する場合について。

デベロッパーの皆さん、こんにちは！ InterSystems Package Manager (ZPM) は、素晴らしいツールですが、インストールせずにすぐ使用できたら、さらに便利です。

それを実現する方法はいくつかあります。以下に dockerfile を使って ZPM をビルドした IRIS コンテナを用意する方法をご紹介します。

リポジトリを作成し、そのdockerfile に数行のコードを記述しました。これを使えば、最新バージョンの ZPM をダウンロードし、インストールできます。

IRIS コミュニティエディション用のあなたの dockerfile にこれらのコマンドを追加すれば、ZPM がインストールされ、使用できるようになります。

最新の ZPM クライアントをダウンロードするコマンドは以下の通り。

RUN mkdir -p /tmp/deps \
 && cd /tmp/deps \
 && wget -q https://pm.community.intersystems.com/packages/zpm/latest/installer -O zpm.xml

IRIS に ZPM をインストールするコマンドは以下の通り。

" Do \$system.OBJ.Load(\"/tmp/deps/zpm.xml\", \"ck\")" \

これで完了です！

このリポジトリで ZPM を試すには、以下を実行します

$ git clone https://github.com/intersystems-community/objectscript-zpm-template.git

リポジトリをビルドして実行します

$ docker-compose up -d
Open IRIS terminal:
$ docker-compose exec iris iris session iris
USER>

ZPM を読み出します

USER>zpm
zpm: USER>

ウェブターミナルをインストールします

zpm: USER>install webterminal
webterminal]   Reload START
[webterminal]   Reload SUCCESS
[webterminal]   Module object refreshed.
[webterminal]   Validate START
[webterminal]   Validate SUCCESS
[webterminal]   Compile START
[webterminal]   Compile SUCCESS
[webterminal]   Activate START
[webterminal]   Configure START
[webterminal]   Configure SUCCESS
[webterminal]   Activate SUCCESS
zpm: USER>

是非ご活用ください！

全体のプロセスはこちらの GIF をご覧ください。

#InterSystems IRIS #Docker #InterSystems Package Manager (IPM) #コンテナ化 #ターミナル

Open Exchange

0 0

0 238

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

GitHub Actions を使って EKS に InterSystems IRIS Solution をデプロイする

データ分析のためにInterSystemsで何ができるかを確認したいとしましょう。理論を学んだので今度は実践したいと考えた時、InterSystems には、役に立つ実例をいくつか取り入れた Samples BI というプロジェクトが用意されています。まずは、README ファイルを開き、Docker に関する内容はすべてスキップして、手順に従ってインストールしてゆきます。仮想インスタンスを起動し、そこに IRIS をインストールしたら、手順に従って Samples BI をインストールします。そして綺麗なチャートやテーブルを見せて上司に感心してもらいましょう。ここまでは順調ですね。

必然的に、ここで変更を加えることになります。

仮想マシンを自分でメンテすることにはデメリットがいくつかあり、クラウドプロバイダーに保管する方が無難であることが判明します。 Amazon は安定してそうなので、AWS アカウントを作成します (開始は無料)。ルートユーザーの ID を使って日々の業務を行うのは危険であることを読んだあなたは、管理者権限を持つ普通の IAM ユーザーを作成します。

少し先に進んでから、独自の VPC ネットワーク、サブネット、EC2 の仮想インスタンスを作成し、さらには自分用の IRIS ウェブポート (52773) と SSH ポート (22) を開くために、セキュリティグループを追加します。 IRIS と Samples BI のインストールをもう一度実行します。今回は、Bash シェルスクリプトを使います。Python でも OK。また、ここでも上司に好印象を与えておきます。

しかし、DevOps がトレンドとなり、Infrastructure as Code (コードによるインフラの管理)について学び、導入したくなります。そこで、Terraform を選択します。知名度が高く、世界中で多用されている上に、多くのクラウドプロバイダーにとっても調整が簡単なため適切な選択肢です。インフラストラクチャを HCL 言語で定義し、IRIS と Samples BI のインストール手順を Ansible に変換します。そしてTerraform を動かすIAM ユーザーをもう 1 つ作成し、それを実行します。そして職場でボーナスをゲットします。

次第に、マイクロサービスの時代に Docker を使わないのはもったいない、InterSystems がそのドキュメンテーションを提供してくれることを考えるとなおさらだ、という結論に至ります。 Samples BI のインストールガイドに戻り、複雑に思えなくなったDocker について書かれた行を読み通します。

$ docker pull intersystemsdc/iris-community:2019.4.0.383.0-zpm
$ docker run --name irisce -d --publish 52773:52773 intersystemsdc/iris-community:2019.4.0.383.0-zpm
$ docker exec -it irisce iris session iris
USER>zpm
zpm: USER>install samples-bi

ブラウザーを http://localhost:52773/csp/user/_DeepSee.UserPortal.Home.zen?$NAMESPACE=USER, に変更したら、もう一度上司の所に戻り、良い仕事のご褒美として1 日休みをもらいます。

あなたはその時、“docker run” は単なる第一歩であり、少なくとも docker-compose を使う必要があるでは？と考え始めます。問題ありません:

$ cat docker-compose.yml
version: "3.7"
services:
irisce:
container_name: irisce
image: intersystemsdc/iris-community:2019.4.0.383.0-zpm
ports:
- 52773:52773
$ docker rm -f irisce # We don’t need the previous container
$ docker-compose up -d

こうして、Ansible を使ってDocker や docker-compose をインストールし、マシン上にイメージが無ければダウンロードするコンテナを単に実行します。それから、Samples BI をインストールします。

カーネルの様々な機能へのインターフェイスとして活躍する、便利でシンプルな Docker を気に入らないはずがありません。あなたは Docker を他の場所でも使い、頻繁に複数のコンテナを起動するようにもなりました。また、コンテナはしばしばお互いに通信し合う必要があることを知ったあなたは、複数のコンテナを管理する方法について読み始めます。

そして、Kubernetes (クーべネティス) について知ります。

docker-compose から Kubernetes に素早く切り替える方法の 1 つに kompose を使うという方法があります。私個人的には、Kubernetes のマニフェストファイルをマニュアルからコピーし、自分で編集する方が好きなのですが、kompose でも小さなタスクを完了させるだけなら問題ありません。

$ kompose convert -f docker-compose.yml
INFO Kubernetes file "irisce-service.yaml" created
INFO Kubernetes file "irisce-deployment.yaml" created

これで、Kubernetes のクラスターに送信できるデプロイファイルとサービスファイルができました。ここであなたは、minikube をインストールすれば、シングルノードの Kubernetes クラスターを実行できること、そしてこの段階ではまさにそれが必要なことを知ります。 minikube のサンドボックスを 1 日か 2 日使ってみた後、ライブの Kubernetes を実際に AWS クラウドのどこかでデプロイする準備が整いました。

セットアップ

それでは、一緒にやりましょう。この時点で、前提にしておきたい点がいくつかあります。

第一に、あなたが AWS のアカウントを持っていること、その ID を知っていること、そしてルートユーザーの認証情報を使用していないということです。管理者権限とプログラムによるアクセス権だけを持つ IAM ユーザー (「my-user」とでも呼びましょう) を作成し、その認証情報を保管します。また、「terraform」と名付けた IAM ユーザーも作成し、同じアクセス権を与えます。

このユーザーの代わりに、Terraform はあなたの AWS アカウントにアクセスし、必要なリソースを作成、削除します。これはデモなので、これらのユーザーに広範な権限を与えています。両方の IAM ユーザーの認証情報はローカルに保存します。

$ cat ~/.aws/credentials
[terraform]
aws_access_key_id = ABCDEFGHIJKLMNOPQRST
aws_secret_access_key = ABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123
[my-user]
aws_access_key_id = TSRQPONMLKJIHGFEDCBA
aws_secret_access_key = TSRQPONMLKJIHGFEDCBA01234567890123

注意: 上の認証情報はコピー & ペーストしないでください。例として作成したものなので、既に削除しています。 ~/.aws/credentials ファイルを編集し、独自のレコードを導入してください。

第二に、この記事では AWS アカウントのダミー ID に「01234567890」を、AWS の地域には「eu-west-1」を使用します。別の地域を使っても構いません。

第三に、あなたが AWS は有料であること、使用するリソースは支払う必要があることを認識しているという前提で進めて行きます。

次に、あなたはコマンドラインを使って AWS と通信するために、 AWS CLI ユーティリティをインストールしています。 aws2 を使うこともできますが、kube の config ファイルに aws2 の使用範囲を具体的に設定する必要があります。詳しくは、こちらをご覧ください。

また、コマンドラインを使って AWS Kubernetes と通信する目的で、 kubectl ユーティリティもインストールしています。

さらに、Kubernetes のマニフェストファイルを変換するには、docker-compose.yml を使用する必要があり、そのためには kompose ユーティリティをインストールしなくてはいけません。

最後に、空の GitHub レポジトリを作成し、ホストにクローンしました。ルートディレクトリは . として参照します。このリポジトリでは、「.github/workflows/」、「k8s/」、「terraform/」という 3 つのディレクトリを作成し、中身を埋めていきます。

すべての関連するコードは、コピー & ペーストを簡単にできるよう、github-eks-samples-bi というリポジトリ内に複製されています。

それでは続けましょう。

AWS EKS のプロビジョニング

EKS については、Amazon EKS を使ったシンプルな IRIS ベースのウェブアプリケーションをデプロイすると題した記事で既に紹介しています。そのときに、クラスターを半自動的に作成しました。つまり、クラスタをファイル内で定義し、 eksctl ユーティリティを手動でローカルマシンから起動した結果、クラスタが私たちの定義に従って作成されています。

eksctl は EKS クラスタを作成する目的で開発され、概念実証による導入には優れていますが、日々の使用には Terraform など、より広範な機能を提供するツールを採用する方が無難と言えます。 AWS EKS Introduction と題した非常に便利なリソースがあり、EKS クラスタの作成に必要な Terraform の設定が説明されています。 1、2 時間かけて読む価値は十分にあります。

Terraform はローカルで試すことができます。そのためには、バイナリ (この記事の執筆時には Linux の最新バージョン 0.12.20 を使用しました) と Terraform を AWS にアクセスさせるに十分な権限を持つ IAM ユーザー「terraform」が必要です。ディレクトリ「/terraform/」を作成し、次の Terraform のコードを保管します。

$ mkdir /terraform
$ cd /terraform

.tf ファイルは、複数作成できます (起動時にマージされます)。 AWS EKS Introduction に記載されているコードの例をコピー & ペーストし、以下のようなコードを実行します。

$ export AWS_PROFILE=terraform
$ export AWS_REGION=eu-west-1
$ terraform init
$ terraform plan -out eks.plan

何らかのエラーが発生する可能性があります。その場合は、デバッグモードを試してください。終わったら忘れずにオフにしてください。

$ export TF_LOG=debug
$ terraform plan -out eks.plan

$ unset TF_LOG

この体験はお役に立つと思います。また、EKS クラスタも起動できるでしょう (「terraform apply」を使ってください)。 AWS コンソールでお試しください。

飽きてしまったらクリーンアップしましょう。

$ terraform destroy

そして、次のレベルに移動し、Terraform EKS モジュールの使用を開始します。これは、同じ EKS Introduction がベースになっているためでもあります。その使い方は、「examples/」ディレクトリで確認してください。そこには、他の例も用意してあります。

例はある程度簡素化してあります。こちらが、VPC の作成モジュールと EKS の作成モジュールが呼び出されるメインファイルです。

$ cat /terraform/main.tf
terraform {
required_version = ">= 0.12.0"
backend "s3" {
bucket = "eks-github-actions-terraform"
key = "terraform-dev.tfstate"
region = "eu-west-1"
dynamodb_table = "eks-github-actions-terraform-lock"
}
}

provider "kubernetes" {
host = data.aws_eks_cluster.cluster.endpoint
cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority.0.data)
token = data.aws_eks_cluster_auth.cluster.token
load_config_file = false
version = "1.10.0"
}

locals {
vpc_name = "dev-vpc"
vpc_cidr = "10.42.0.0/16"
private_subnets = ["10.42.1.0/24", "10.42.2.0/24"]
public_subnets = ["10.42.11.0/24", "10.42.12.0/24"]
cluster_name = "dev-cluster"
cluster_version = "1.14"
worker_group_name = "worker-group-1"
instance_type = "t2.medium"
asg_desired_capacity = 1
}

data "aws_eks_cluster" "cluster" {
name = module.eks.cluster_id
}

data "aws_eks_cluster_auth" "cluster" {
name = module.eks.cluster_id
}

data "aws_availability_zones" "available" {
}

module "vpc" {
source = "git::https://github.com/terraform-aws-modules/terraform-aws-vpc?ref=master"

name = local.vpc_name
cidr = local.vpc_cidr
azs = data.aws_availability_zones.available.names
private_subnets = local.private_subnets
public_subnets = local.public_subnets
enable_nat_gateway = true
single_nat_gateway = true
enable_dns_hostnames = true

tags = {
"kubernetes.io/cluster/${local.cluster_name}" = "shared"
}

public_subnet_tags = {
"kubernetes.io/cluster/${local.cluster_name}" = "shared"
"kubernetes.io/role/elb" = "1"
}

private_subnet_tags = {
"kubernetes.io/cluster/${local.cluster_name}" = "shared"
"kubernetes.io/role/internal-elb" = "1"
}
}

module "eks" {
source = "git::https://github.com/terraform-aws-modules/terraform-aws-eks?ref=master"
cluster_name = local.cluster_name
cluster_version = local.cluster_version
vpc_id = module.vpc.vpc_id
subnets = module.vpc.private_subnets
write_kubeconfig = false

worker_groups = [
{
name = local.worker_group_name
instance_type = local.instance_type
asg_desired_capacity = local.asg_desired_capacity
}
]

map_accounts = var.map_accounts
map_roles = var.map_roles
map_users = var.map_users
}

それでは、main.tf の「terraform」ブロックをもう少し細かく見てみましょう。

terraform {
required_version = ">= 0.12.0"
backend "s3" {
bucket = "eks-github-actions-terraform"
key = "terraform-dev.tfstate"
region = "eu-west-1"
dynamodb_table = "eks-github-actions-terraform-lock"
}
}

ここでは、Terraform 0.12 以上のバージョン (以前のバージョンに比べると多くの変更が加えられています) の構文に従うこと、また Terraform はその状態をローカルにではなく、むしろリモートの S3 バケットに保管することを指定しています。

Terraform のコードを色々な人が色々な場所から更新できると便利ですが、ユーザーの状態をロックできなければいけないということになるので、dynamodb テーブルを使ってロックを追加しました。ロックの詳細は、State Locking のページをご覧ください。

バケットには AWS 全体で一意の名前が使われている必要があるので「eks-github-actions-terraform」という名前は使えません。独自の名前を考えて、既に使用されていないことを確認してください (すると NoSuchBucket エラーが発生します):

$ aws s3 ls s3://my-bucket
An error occurred (AllAccessDisabled) when calling the ListObjectsV2 operation: All access to this object has been disabled
$ aws s3 ls s3://my-bucket-with-name-that-impossible-to-remember
An error occurred (NoSuchBucket) when calling the ListObjectsV2 operation: The specified bucket does not exist

名前を考えたら、バケットを作成し (ここでは IAM ユーザー「terraform」を使います。管理者権限を持っているのでバケットを作成できます)、そのバージョン管理を有効にします (こうすることで、構成エラーが出ても落ち着いて対応できます)。

$ aws s3 mb s3://eks-github-actions-terraform --region eu-west-1
make_bucket: eks-github-actions-terraform
$ aws s3api put-bucket-versioning --bucket eks-github-actions-terraform --versioning-configuration Status=Enabled
$ aws s3api get-bucket-versioning --bucket eks-github-actions-terraform
{
"Status": "Enabled"
}

DynamoDB では、一意性は必要ありませんが、最初にテーブルを作成する必要があります。

$ aws dynamodb create-table \
--region eu-west-1 \
--table-name eks-github-actions-terraform-lock \
--attribute-definitions AttributeName=LockID,AttributeType=S \
--key-schema AttributeName=LockID,KeyType=HASH \
--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5

Terraform に障害が発生した場合は、ロックを AWS コンソールから手動で解除する必要があるかもしれません。その場合は慎重に対応してください。

main.tf 内にある eks/vpc モジュールのブロックについてですが、GitHub で使用可能なモジュールを参照する方法はいたってシンプルです。

git::https://github.com/terraform-aws-modules/terraform-aws-vpc?ref=master

それでは、他の 2 つの Terraform ファイル (variables.tf と outputs.tf) を見てみましょう。 1 つ目のファイルには Terraform の変数が置かれます。

$ cat /terraform/variables.tf
variable "region" {
default = "eu-west-1"
}

variable "map_accounts" {
description = "aws-auth configmap に追加する他の AWS アカウント番号。フォーマットの例は、examples/basic/variables.tf を参照してください。"
type = list(string)
default = []
}

variable "map_roles" {
description = "aws-auth configmap に追加する他の IAM ロール。"
type = list(object({
rolearn = string
username = string
groups = list(string)
}))
default = []
}

variable "map_users" {
description = "aws-auth configmap に追加する他の IAM ユーザー。"
type = list(object({
userarn = string
username = string
groups = list(string)
}))
default = [
{
userarn = "arn:aws:iam::01234567890:user/my-user"
username = "my-user"
groups = ["system:masters"]
}
]
}

ここで一番大事なのは map_users 変数に IAM ユーザー “my-user” を追加するということですが、01234567890 の代わりに自分のアカウント ID を使ってください。

これで何が起こるのか？ローカルの kubectl クライアントを通じて EKS と通信する場合は、EKS から Kubernetes API サーバーにリクエストが送られます。そして、各リクエストは認証プロセスと承認プロセスを通り、Kubernetes はリクエストの送信者とそのユーザーの権限を理解できるようになります。そして、Kubernetes の EKS バージョンは、AWS の IAM にユーザー認証のサポートを求めます。リクエストを送信したユーザーが AWS IAM (ここではユーザーの ARN をポイントしました) に載っている場合、リクエストは承認ステージに移動し、EKS が私たちの設定に従って直接処理します。ここでは、IAM ユーザー “my-user” は信頼できる人である (group “system: masters”)、ことを示しています。

最後に、Terraform がジョブを完了した後に出力する内容を outputs.tf が説明します。

$ cat /terraform/outputs.tf
output "cluster_endpoint" {
description = "EKS コントロールプレーンのエンドポイント"
value = module.eks.cluster_endpoint
}

output "cluster_security_group_id" {
description = "クラスターのコントロールプレーンに関連付けられたセキュリティグループの ID。"
value = module.eks.cluster_security_group_id
}

output "config_map_aws_auth" {
description = "この EKS クラスターに対して承認する Kubernetes 構成。"
value = module.eks.config_map_aws_auth
}

これで Terraform の部分に関する説明は終了です。これらのファイルを起動する方法はもう少し後で説明します。

Kubernetes のマニフェスト

ここまでは、アプリケーションをどこで起動するのかについて説明しましたが、今度は、何を実行するのか、を見て行きます。

docker-compose.yml (サービス名を変更し、kompose が使用するラベルをいくつか追加しました) が、 /k8s/ ディレクトリにあることを覚えているでしょうか。

$ cat /k8s/docker-compose.yml
version: "3.7"
services:
samples-bi:
container_name: samples-bi
image: intersystemsdc/iris-community:2019.4.0.383.0-zpm
ports:
- 52773:52773
labels:
kompose.service.type: loadbalancer
kompose.image-pull-policy: IfNotPresent

kompose を実行して、下に強調表示されている箇所を追加します。アノテーションは削除します (分かりやすくするためです)。

$ kompose convert -f docker-compose.yml --replicas=1
$ cat /k8s/samples-bi-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
io.kompose.service: samples-bi
name: samples-bi
spec:
replicas: 1
strategy:
type: Recreate
template:
metadata:
labels:
io.kompose.service: samples-bi
spec:
containers:
- image: intersystemsdc/iris-community:2019.4.0.383.0-zpm
imagePullPolicy: IfNotPresent
name: samples-bi
ports:
- containerPort: 52773
resources: {}
lifecycle:
postStart:
exec:
command:
- /bin/bash
- -c
- |
echo -e "write\nhalt" > test
until iris session iris < test; do sleep 1; done
echo -e "zpm\ninstall samples-bi\nquit\nhalt" > samples_bi_install
iris session iris < samples_bi_install
rm test samples_bi_install
restartPolicy: Always

Recreate を使ったアップデート戦略を使用しますが、これはポッドが一旦削除されてから再度作成されることを意味します。今回はデモなので、これでも大丈夫です。また、使用するリソースも少なくて済みます。
さらに、ポッドが起動すると同時にトリガーする postStart フックも追加しました。 IRIS が起動するのを待ち、デフォルトの zpm-repository から samples-bi をインストールします。
ここで、Kubernetes サービスを追加します (ここでもアノテーションは使いません)。

$ cat /k8s/samples-bi-service.yaml
apiVersion: v1
kind: Service
metadata:
labels:
io.kompose.service: samples-bi
name: samples-bi
spec:
ports:
- name: "52773"
port: 52773
targetPort: 52773
selector:
io.kompose.service: samples-bi
type: LoadBalancer

そうです、今回は「デフォルト」のネームスペースでデプロイします。デモですからね。

_何_を_どこ_で実行するかが分かったところで、最後は、_どのように_実行するか、を見ます。

GitHub Actions のワークフロー

すべてを一から作るのではなく、GitHub Actions を使って GKE に InterSystems IRIS Solution をデプロイするに記載されているワークフローに似たものを作成します。今回は、コンテナを構築する必要はありません。 GKE 特有の箇所は EKS 特有の箇所に置き換えられます。太文字の箇所は、コミットメッセージを受けて条件付きステップで使用することに関する記述です。

$ cat /.github/workflows/workflow.yaml
name: EKS クラスタをプロビジョンし、そこに Samples BI をデプロイする
on:
push:
branches:
- master

# 環境変数。
# ${{ secrets }} は GitHub -> Settings -> Secrets より取得されます
# ${{ github.sha }} はコミットハッシュです
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
AWS_REGION: ${{ secrets.AWS_REGION }}
CLUSTER_NAME: dev-cluster
DEPLOYMENT_NAME: samples-bi

jobs:
eks-provisioner:
# Inspired by:
## https://www.terraform.io/docs/github-actions/getting-started.html
## https://github.com/hashicorp/terraform-github-actions
name: EKS クラスタをプロビジョンする
runs-on: ubuntu-18.04
steps:
- name: Checkout
uses: actions/checkout@v2

- name: Get commit message
run: |
echo ::set-env name=commit_msg::$(git log --format=%B -n 1 ${{ github.event.after }})

- name: Show commit message
run: echo $commit_msg

- name: Terraform init
uses: hashicorp/terraform-github-actions@master
with:
tf_actions_version: 0.12.20
tf_actions_subcommand: 'init'
tf_actions_working_dir: 'terraform'

- name: Terraform validate
uses: hashicorp/terraform-github-actions@master
with:
tf_actions_version: 0.12.20
tf_actions_subcommand: 'validate'
tf_actions_working_dir: 'terraform'

- name: Terraform plan
if: "!contains(env.commit_msg, '[destroy eks]')"
uses: hashicorp/terraform-github-actions@master
with:
tf_actions_version: 0.12.20
tf_actions_subcommand: 'plan'
tf_actions_working_dir: 'terraform'

- name: Terraform plan for destroy
if: "contains(env.commit_msg, '[destroy eks]')"
uses: hashicorp/terraform-github-actions@master
with:
tf_actions_version: 0.12.20
tf_actions_subcommand: 'plan'
args: '-destroy -out=./destroy-plan'
tf_actions_working_dir: 'terraform'

- name: Terraform apply
if: "!contains(env.commit_msg, '[destroy eks]')"
uses: hashicorp/terraform-github-actions@master
with:
tf_actions_version: 0.12.20
tf_actions_subcommand: 'apply'
tf_actions_working_dir: 'terraform'

- name: Terraform apply for destroy
if: "contains(env.commit_msg, '[destroy eks]')"
uses: hashicorp/terraform-github-actions@master
with:
tf_actions_version: 0.12.20
tf_actions_subcommand: 'apply'
args: './destroy-plan'
tf_actions_working_dir: 'terraform'

kubernetes-deploy:
name: Deploy Kubernetes manifests to EKS
needs:
- eks-provisioner
runs-on: ubuntu-18.04
steps:
- name: Checkout
uses: actions/checkout@v2

- name: Get commit message
run: |
echo ::set-env name=commit_msg::$(git log --format=%B -n 1 ${{ github.event.after }})

- name: Show commit message
run: echo $commit_msg

- name: Configure AWS Credentials
if: "!contains(env.commit_msg, '[destroy eks]')"
uses: aws-actions/configure-aws-credentials@v1
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: ${{ secrets.AWS_REGION }}

- name: Apply Kubernetes manifests
if: "!contains(env.commit_msg, '[destroy eks]')"
working-directory: ./k8s/
run: |
aws eks update-kubeconfig --name ${CLUSTER_NAME}
kubectl apply -f samples-bi-service.yaml
kubectl apply -f samples-bi-deployment.yaml
kubectl rollout status deployment/${DEPLOYMENT_NAME}

もちろん、“terraform” ユーザーの認証情報を設定 (~/.aws/credentials ファイルから取得) し、Github がそのシークレットを使用することを許可する必要があります。

ワークフローの強調表示されている箇所に注目してください。これらは、“[destroy eks]” というフレーズを持つコミットメッセージをプッシュし、EKS クラスターを破壊することを可能にします。私たちはそのようなコミットメッセージを持つ “kubernetes apply” は実行しません。
パイプラインを実行します。でも最初に .gitignore ファイルを作成します。

$ cat /.gitignore
.DS_Store
terraform/.terraform/
terraform/*.plan
terraform/*.json
$ cd
$ git add .github/ k8s/ terraform/ .gitignore
$ git commit -m "GitHub on EKS"
$ git push

GitHub のリポジトリページにある「Actions」タブでデプロイプロセスをモニタリングします。正常に完了するのを待ってください。

ワークフローを最初に実行するときは、“Terraform apply” のステップにおよそ 15 分かかります (クラスターの作成にかかる時間とほぼ同じ時間です)。次に起動するとき (クラスターを削除していなければ) は、ワークフローの実行速度が大幅にアップします。こちらをチェックしてください。

$ cd
$ git commit -m "Trigger" --allow-empty
$ git push

もちろん、作成したワークフローを確認しておくとよいでしょう。今回は、IAM “my-user” の認証情報をご自分のノートパソコンでお使いください。

$ export AWS_PROFILE=my-user
$ export AWS_REGION=eu-west-1
$ aws sts get-caller-identity
$ aws eks update-kubeconfig --region=eu-west-1 --name=dev-cluster --alias=dev-cluster
$ kubectl config current-context
dev-cluster

$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
ip-10-42-1-125.eu-west-1.compute.internal Ready 6m20s v1.14.8-eks-b8860f

$ kubectl get po
NAME READY STATUS RESTARTS AGE
samples-bi-756dddffdb-zd9nw 1/1 Running 0 6m16s

$ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 172.20.0.1 443/TCP 11m
samples-bi LoadBalancer 172.20.33.235 a2c6f6733557511eab3c302618b2fae2-622862917.eu-west-1.elb.amazonaws.com 52773:31047/TCP 6m33s

_http://a2c6f6733557511eab3c302618b2fae2-622862917.eu-west-1.elb.amazonaws.com:52773/csp/user/_DeepSee.UserPortal.Home.zen?$NAMESPACE=USER _(リンクを自分の External-IP と入れ替えてください) に移動し、“_system”、“SYS” と順に入力して、デフォルトのパスワードを変更します。たくさんの BI ダッシュボードが表示されるはずです。

細かく確認するには、それぞれの矢印をクリックします。

samples-bi ポッドを再起動したら、すべての変更内容が消去されるので覚えておきましょう。これはデモなので、意図的にそうなるようにしています。永続化する必要がある方のために、例を 1 つ github-gke-zpm-registry/k8s/statefulset.tpl リポジトリに作成しておきました。

作業が終わったら、作成したものをすべて削除してください。

$ git commit -m "Mr Proper [destroy eks]" --allow-empty
$ git push

まとめ

この記事では、eksctl ユーティリティの代わりに Terraform を使って EKS クラスターを作成しました。これで、AWS インフラストラクチャのすべてを「体系化」することに一歩近づけたと思います。
Github Actions と Terraform で git push 使い簡単にデモアプリケーションをデプロイする方法をデモンストレーションしました。
また、ツールボックスに kompose とポッドの postStart フックも追加しました。
今回は、TLS の有効化については触れていません。それは、また近いうちに取り上げたいと思います。

#InterSystems IRIS #Open Exchange #AWS #DevOps #Docker #Kubernetes #クラウド #コンテナ化

Open Exchange

0 0

0 428

記事 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

記事 Tomohiro Iwamoto · 12月 10, 2020 17m read

Google Kubernetes Engine にデプロイされた IRIS ベースのサービスに TLS と DNS を追加する

この記事は、GitHub Actions を使って GKE に InterSystems IRIS Solution をデプロイするの継続記事で、そこではGitHub Actions パイプラインを使って、 Terraform で作成された Google Kubernetes クラスタにzpm-registry をデプロイしています。繰り返しにならないよう、次の項目を満たしたものを開始点とします。

訳者注) 上記の記事を読まれてから、本記事に進まれることをお勧めしますが、GKE上のサービスにドメイン名を紐づける方法を解説した単独記事としてもお読みいただけます。

#InterSystems IRIS #Open Exchange #DevOps #GitHub #Kubernetes #クラウド #コンテナ化 #ベストプラクティス

Open Exchange

0 0

0 389

記事 Shintaro Kaminaka · 12月 10, 2020 20m read

GitHub Actions を使って GKE に InterSystems IRIS Solution をデプロイする

以前紹介した記事 (お読みいただいたでしょうか) では、GitHub とパーフェクトに統合する CircleCI のデプロイシステムについてカバーしました。なのにどうしてさらに掘り下げる必要があるのか？それは、GitHub には GitHub Actions という独自の CI/CD プラットフォームがあり、詳しく見ておく価値があるからです。 GitHub Actions を使えば、外部のサービスを使用する必要はありません。

この記事では、GitHub Actions を使って InterSystems Package Manager のサーバー部分である ZPM-registry を Google Kubernetes Engine (GKE) にデプロイする、ということを試したいと思います。

どのシステムもそうですが、ビルド / デプロイのシステムも結局は「これを実行して、そこに移動したら、あれを実行する」といった感じの流れになります。 GitHub Actions では、こうようなアクションはそれぞれが 1 つ以上のステップで構成されるジョブとして扱われ、集合的にはワークフローとして知られています。 GitHub は、ワークフローの説明を探して .github/workflows ディレクトリの YAML ファイル (拡張子が .yml または .yaml のファイル) を検索します。詳細は、GitHub Actions の主要コンセプトをご覧ください。

これから実行するアクションはすべて ZPM-registry リポジトリのフォーク内で実行されます。この記事では、このフォークを "zpm-registry" と呼び、そのルートディレクトリーを "<root_repo_dir>" と呼びます。 ZPM アプリケーションそのものに関する詳細は、Introducing InterSystems ObjectScript Package Manager および The Anatomy of ZPM Module: Packaging Your InterSystems Solution をご覧ください。

すべてのコードサンプルは、簡単にコピー & ペーストできるよう、こちらのリポジトリに保管されています。必須事項は、CircleCI ビルドで GKE の作成を自動化すると題した記事に記載されている内容と同じです。

過去の記事を読まれていること、Google アカウントを既にお持ちであること、そして前回の記事で「Development」と名付けたプロジェクトを作成されているという前提で進めていきます。この記事では、その ID を <PROJECT_ID>として表示しています。下の例を実行する場合は、ご自身のプロジェクトの ID に変更してください。

Google には無料のティアがありますが、Google クラウドプラットフォームは有料ですのでご注意ください。経費の管理にはお気を付けください。

ワークフローの基本

それでは、始めましょう。

以下はシンプルですが使いものにならないワークフローの例です。

$ cd <root_repo_dir>
$ mkdir -p .github/workflows
$ cat <root_repo_dir>/.github/workflows/workflow.yaml
name: Traditional Hello World
on: [push]
jobs:
courtesy:
name: Greeting
runs-on: ubuntu-latest
steps:
- name: Hello world
run: echo "Hello, world!

リポジトリにプッシュするときは、「Greeting」と名付けたジョブを実行する必要があります。このジョブは唯一のステップとしてウェルカムフレーズを出力します。このジョブは、GitHub でホストされる仮想マシン「Runner」で実行されます。同マシンには Ubuntu の最新バージョンがインストールされています。
このファイルをリポジトリにプッシュした後に「Code GitHub」タブを開けば、すべて順調に実行されたことを確認できるはずです。

ジョブが失敗したら、緑のチェックマークの代わりに赤の「X」が表示されます。詳細を見るには、緑のチェックマークと「Details」を順にクリックします。もしくは、直接「Actions」タブに移動することもできます。

ワークフローの構文に関する完全な詳細は、Workflow syntax for GitHub Actions と題したヘルプドキュメントをご覧ください。

リポジトリにイメージビルド用の Dockerfile が含まれている場合は、「Hello world」のステップをもっと役に立つものに置き換えることができます。こちらは starter-workflows から選んだ 1 例です。

steps:
- uses: actions/checkout@v2
- name: Build the Docker image
run: docker build . --file Dockerfile --tag my-image:$(date +%s)

新しいステップ "uses: action/checkout@v2" が追加されていることに注目してください。 "checkout" という名前からも、リポジトリをクローンするステップであるのは分かりますが、詳細はどこを見ればいいのか？

CircleCI については、便利なステップがたくさんありますが、書き直す必要はありません。その代わりに、Marketplace という共有リソースから取り入れることができます。そこで実行したいアクションを探します。「By actions」とマーキングされているアクション (カーソルを合わせると、"Creator verified by Github" と表示されるアクション) をおすすめします。

ワークフローの "uses" 句には、独自のモジュールを記述する代わりに、既成のモジュールを使用する意図が示されています。

アクションの実装そのものは、どの言語でも記述できますが、JavaScript が推奨されます。 JavaScript (または TypeScript) で書かれたアクションは、直接 Runner のマシンで実行されます。他のかたちで実装する場合は、ユーザーが指定する Docker コンテナが希望する内部環境で実行されますが、もちろんその速度は少し遅くなります。アクションの詳細は、そのままのタイトルが付けられた記事 About actions をお読みください。

checkout アクションは TypeScript で書かれています。また、この記事の例で使う Terraform アクションは、Docker Alpine で起動される標準的な Bash シェルスクリプトです。

クローンしたリポジトリに Dockerfile がありますので、修得した知識を応用してみましょう。 ZPM レジストリのイメージをビルドし、Google Container Registry にプッシュします。並行して、このイメージを実行する Kubernetes クラスターを作成します。これには Kubernetes のマニフェストを使用します。

私たちの計画を GitHub が理解できる言語で記述すると以下のようになります (見やすくするために行をたくさん省いて俯瞰したものですので、このコンフィグは使わないでください)。

name: ワークフローの説明
# Trigger condition. In this case, only on push to ‘master’ branch
on:
push:
branches:
- master

# ここではすべての後続のジョブとそれらの各ステップで
# 使用可能な環境変数について説明しています
# これらの変数は GitHub Secrets ページで初期化できます
# それらを参照する目的で “${{ secrets }}” を追加しています
env:
PROJECT_ID: ${{ secrets.PROJECT_ID }}

# ジョブリストの定義ジョブ / ステップの名前はランダムなもので構いませんが
# 有意義なほうがベターです
jobs:
gcloud-setup-and-build-and-publish-to-GCR:
name: gcloud ユーティリティをセットアップし、ZPM イメージをビルドし、Container Registry に公開する
runs-on: ubuntu-18.04
steps:
- name: チェックアウト
- name: gcloud cli をセットアップする
- name: gcloud を認証情報ヘルパーとして使用するよう Docker を設定する
- name: ZPM イメージをビルドする
- name: ZPM イメージを Google Container Registry に公開する

gke-provisioner:
name: Provision GKE cluster
runs-on: ubuntu-18.04
steps:
- name: チェックアウト
- name: Terraform 初期化
- name: Terraform 検証
- name: Terraform プラン
- name: Terraform 適用

kubernetes-deploy:
name: Kubernetes マニフェストを GKE クラスタにデプロイする
needs:
- gcloud-setup-and-build-and-publish-to-GCR
- gke-provisioner
runs-on: ubuntu-18.04
steps:
- name: チェックアウト
- name: プレースホルダーをステートフルセットのテンプレートに記載の値に置換する
- name: gcloud cli をセットアップする
- name: Kubernetes のマニフェストを適用する

これが実用的な config のスケルトン (骨格だけのコード) で、その筋肉、つまり各ステップで実行されるアクションは含まれていません。アクションはシンプルなコンソールコマンドで実行できます ("run"、複数のコマンドがあれば "run |")。

- name: gcloud を認証情報ヘルパーとして使用するよう Docker を設定する
run: |
gcloud auth configure-docker

アクションは "uses" を使ってモジュールとして起動することもできます。

- name: チェックアウト
uses: actions/checkout@v2

デフォルトでは、すべてのジョブが並列して実行され、各ステップが順番に処理されます。しかし、"needs" を使えば、そのジョブを残りのジョブが完了するまで待機するジョブとして指定できます。

needs:
- gcloud-setup-and-build-and-publish-to-GCR
- gke-provisioner

ちなみに、このように待機するジョブが GitHub の Web インターフェイスに表示されるのは、待機される側のジョブが実行されるときだけです。

"gke-provisioner" ジョブには過去の記事の中で検証した Terraform が記述されています。 GCP 環境で操作する場合の事前設定は、便宜上、別の markdown file で繰り返されます。以下のリンクもご利用いただくと便利です。

Terraform Apply Subcommand documentation

Terraform GitHub Actions repository

Terraform GitHub Actions documentation

"kubernetes-deploy" ジョブには、"Apply Kubernetes manifests" と呼ばれるステップがあります。今回は、Deploying InterSystems IRIS Solution into GCP Kubernetes Cluster GKE Using CircleCI という記事に記載されている通りにマニフェストを使用しますが、少しだけ変更を加えます。

過去の記事で使った IRIS アプリケーションは、ステートレスでした。つまり、ポッドを再起動したら、すべてのデータがデフォルトの場所に戻っていたのです。これは良いことで、必要になることも多々あります。しかし、ZPM レジストリでは、ポッドを何回再起動する必要があっても、読み込まれたパッケージを何とかして保存する必要があります。デプロイすれば出来るのですが、もちろんそれには制限があります。

ステートフルなアプリケーションには、StatefulSet のリソースを選択する方が無難です。メリットとデメリットは、Deployments vs. StatefulSets の GKE ドキュメンテーションに関するトピックおよび Kubernetes Persistent Volumes with Deployment and StatefulSet と題したブログ記事に記載しています。

StatefulSet のリソースは、リポジトリの中にあります。注目したいのは、以下の部分です。

volumeClaimTemplates:
- metadata:
name: zpm-registry-volume
namespace: iris
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi

このコードは、単一の Kubernetes ワーカーノードによってマウント可能な 10GB の読み取り / 書き込みディスクを作成します。このディスク (およびその中のデータ) はアプリケーションの再起動後も残ります。 StatefulSet 全体を削除しても残ります。そのためには正しい Reclaim Policy を設定する必要がありますが、この記事ではカバーしていません。

ワークフローを起動させる前に、GitHub Secrets に変数をあといくつか追加しておきましょう。

以下のテーブルはこれらの設定の意味を説明するものです (サービスアカウントキーも含まれています):

名前	意味	例
GCR_LOCATION	グローバル GCR ロケーション	eu.gcr.io
GKE_CLUSTER	GKE クラスタ名	dev-cluster
GKE_ZONE	イメージを格納するゾーン	europe-west1-b
IMAGE_NAME	イメージのレジストリ名	zpm-registry
PROJECT_ID	GCP プロジェクト ID	possible-symbol-254507
SERVICE_ACCOUNT_KEY	GitHub が GCP に接続する際に使用する JSON key。重要: Base64 でエンコードされている必要があります (下の注意点をお読みください)	ewogICJ0eXB...
TF_SERVICE_ACCOUNT_KEY	Terraform が GCP に接続する際に使用する JSON key (下の注意点をお読みください)	{…}

SERVICE_ACCOUNT_KEY において、JSON-key に、例えば、key.json のような名前が付いている場合は、下のコマンドを実行します。

$ base64 key.json | tr -d '\n'

TF_SERVICE_ACCOUNT_KEY について、その権限は CircleCI ビルドで GKE の作成を自動化すると題した記事にて説明してあります。

SERVICE_ACCOUNT_KEY のちょっとした注意点: 私がやってしまったように、base64 フォーマットに変換するのを忘れてしまうと、以下のような画面が表示されます。

ワークフローの主要部分を確認し、必要な変数を追加したところで、ワークフローの完全版を検証する準備が整いました (<root_repo_dir>/.github/workflow/workflow.yaml)。

name: ZPM レジストリのイメージを構築し、GCR にデプロイする。 GKE を実行。 ZPM レジストリを GKE で実行する。
on:
push:
branches:
- master

# 環境変数。
# ${{ secrets }} は GitHub -> Settings -> Secrets より取得されます
# ${{ github.sha }} はコミットハッシュです
env:
PROJECT_ID: ${{ secrets.PROJECT_ID }}
SERVICE_ACCOUNT_KEY: ${{ secrets.SERVICE_ACCOUNT_KEY }}
GOOGLE_CREDENTIALS: ${{ secrets.TF_SERVICE_ACCOUNT_KEY }}
GITHUB_SHA: ${{ github.sha }}
GCR_LOCATION: ${{ secrets.GCR_LOCATION }}
IMAGE_NAME: ${{ secrets.IMAGE_NAME }}
GKE_CLUSTER: ${{ secrets.GKE_CLUSTER }}
GKE_ZONE: ${{ secrets.GKE_ZONE }}
K8S_NAMESPACE: iris
STATEFULSET_NAME: zpm-registry

jobs:
gcloud-setup-and-build-and-publish-to-GCR:
name: gcloud ユーティリティをセットアップ、ZPM イメージを構築、Container Registry に公開する
runs-on: ubuntu-18.04
steps:
- name: チェックアウト
uses: actions/checkout@v2

- name: gcloud cli をセットアップする
uses: GoogleCloudPlatform/github-actions/setup-gcloud@master
with:
version: '275.0.0'
service_account_key: ${{ secrets.SERVICE_ACCOUNT_KEY }}

- name: gcloud を認証情報ヘルパーとして使用するよう Docker を設定する
run: |
gcloud auth configure-docker

- name: ZPM イメージを構築する
run: |
docker build -t ${GCR_LOCATION}/${PROJECT_ID}/${IMAGE_NAME}:${GITHUB_SHA} .

- name: ZPM イメージを Google Container Registry に公開する
run: |
docker push ${GCR_LOCATION}/${PROJECT_ID}/${IMAGE_NAME}:${GITHUB_SHA}

gke-provisioner:
# Inspired by:
## https://www.terraform.io/docs/github-actions/getting-started.html
## https://github.com/hashicorp/terraform-github-actions
name: GKE クラスタをプロビジョンする
runs-on: ubuntu-18.04
steps:
- name: チェックアウト
uses: actions/checkout@v2

- name: Terraform 初期化
uses: hashicorp/terraform-github-actions@master
with:
tf_actions_version: 0.12.17
tf_actions_subcommand: 'init'
tf_actions_working_dir: 'terraform'

- name: Terraform 検証
uses: hashicorp/terraform-github-actions@master
with:
tf_actions_version: 0.12.17
tf_actions_subcommand: 'validate'
tf_actions_working_dir: 'terraform'

- name: Terraform プラン
uses: hashicorp/terraform-github-actions@master
with:
tf_actions_version: 0.12.17
tf_actions_subcommand: 'plan'
tf_actions_working_dir: 'terraform'

- name: Terraform 適用
uses: hashicorp/terraform-github-actions@master
with:
tf_actions_version: 0.12.17
tf_actions_subcommand: 'apply'
tf_actions_working_dir: 'terraform'

- name: プレースホルダーをステートフルセットのテンプレートに記載の値に置換する
working-directory: ./k8s/
run: |
cat statefulset.tpl |\
sed "s|DOCKER_REPO_NAME|${GCR_LOCATION}/${PROJECT_ID}/${IMAGE_NAME}|" |\
sed "s|DOCKER_IMAGE_TAG|${GITHUB_SHA}|" > statefulset.yaml
cat statefulset.yaml

- name: gcloud cli をセットアップする
uses: GoogleCloudPlatform/github-actions/setup-gcloud@master
with:
version: '275.0.0'
service_account_key: ${{ secrets.SERVICE_ACCOUNT_KEY }}

- name: Kubernetes マニフェストを適用する
working-directory: ./k8s/
run: |
gcloud container clusters get-credentials ${GKE_CLUSTER} --zone ${GKE_ZONE} --project ${PROJECT_ID}
kubectl apply -f namespace.yaml
kubectl apply -f service.yaml
kubectl apply -f statefulset.yaml
kubectl -n ${K8S_NAMESPACE} rollout status statefulset/${STATEFULSET_NAME}

リポジトリにプッシュする前には、terraform-code を github-gke-zpm-registry リポジトリの Terraform ディレクトリーから取得し、プレースホルダーを main.tf のコメントに記載されている通りに置換し、terraform/ ディレクトリーに配置する必要があります。 Terraform は、リモートのバケットを使用しますが、このバケットは最初から CircleCI ビルドで GKE の作成を自動化すると題した記事で言及されている通りに作成されている必要があることを覚えておきましょう。

また、Kubernetes-code は github-gke-zpm-registry リポジトリの K8S ディレクトリーから取得され、k8s/ ディレクトリーの中に配置されている必要があります。これらのコードのソースは、スペースを節約するためにこの記事では省いています。

そして、以下のようにすればデプロイをトリガーできます。

$ cd <root_repo_dir>/
$ git add .github/workflow/workflow.yaml k8s/ terraform/
$ git commit -m “Add GitHub Actions deploy”
$ git push

フォークされている ZPM リポジトリに変更内容をプッシュしたら、説明したステップの実装を確認できます。

ここまで、ジョブの数は 2 つしかありませんが、 3 つ目の "kubernetes-deploy" は、その 2 つのジョブに依存しており、それらが完了した後に表示されます。
Docket イメージのビルドと公開には少し時間がかかります。

また、結果は GCR コンソールで確認できます。

"Provision GKE cluster" ジョブは、最初の実行時に GKE クラスターを作成するので、最初だけ完了までの時間が少し長くなります。数分間、待機中の画面が表示されます。

やっと完了したときには、思わず嬉しくなります。

Kubernetes のリソースも喜んでいます。

$ gcloud container clusters get-credentials <CLUSTER_NAME> --zone <GKE_ZONE> --project <PROJECT_ID>

$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
gke-dev-cluster-dev-cluster-node-pool-98cef283-dfq2 Ready <none> 8m51s v1.13.11-gke.23

$ kubectl -n iris get po
NAME READY STATUS RESTARTS AGE
zpm-registry-0 1/1 Running 0 8m25s

他の内容の確認は、Running ステータスになるまで待機することをおすすめします。

$ kubectl -n iris get sts
NAME READY AGE
zpm-registry 1/1 8m25s

$ kubectl -n iris get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
zpm-registry LoadBalancer 10.23.248.234 104.199.6.32 52773:32725/TCP 8m29s

ディスクまでが喜んでいます。

$ kubectl get pv -oyaml | grep pdName
pdName: gke-dev-cluster-5fe434-pvc-5db4f5ed-4055-11ea-a6ab-42010af00286

そして、一番喜んでいるのは ZPM レジストリです ("kubectl -n iris get svc" の External-IP 出力を使用しました):

$ curl -u _system:SYS 104.199.6.32:52773/registry/_ping
{"message":"ping"}

ログイン / パスワードを HTTP で処理しているのは残念ですね。今後の記事の中で何とかしたいと思います。

ちなみにですが、エンドポイントについてはソースコードを見ていただければ、詳細が書かれていますので、XData UrlMap セクションをご覧ください。

このリポジトリは、それ自体にパッケージをプッシュすればテストできます。 GitHub のダイレクトリンクだけをプッシュする便利な機能があります。 InterSystems ObjectScript の数式ライブラリで試してみましょう。これをローカルマシンから実行します。

$ curl -XGET -u _system:SYS 104.199.6.32:52773/registry/packages/-/all
[]
$ curl -i -XPOST -u _system:SYS -H "Content-Type: application/json" -d '{"repository":"https://github.com/psteiwer/ObjectScript-Math"}' 'http://104.199.6.32:52773/registry/package'
HTTP/1.1 200 OK
$ curl -XGET -u _system:SYS 104.199.6.32:52773/registry/packages/-/all
[{"name":"objectscript-math","versions":["0.0.4"]}]

ポッドを再起動して、データがきちんと配置されていることを確認します。

$ kubectl -n iris scale --replicas=0 sts zpm-registry
$ kubectl -n iris scale --replicas=1 sts zpm-registry
$ kubectl -n iris get po -w

実行中のポッドを待ちます。そして、うまく処理されると以下が表示されます。

$ curl -XGET -u _system:SYS 104.199.6.32:52773/registry/packages/-/all
[{"name":"objectscript-math","versions":["0.0.4"]}]

それでは、この数式パッケージをリポジトリからローカルの IRIS インスタンスにインストールしましょう。 ZPM クライアントが既にインストールされているものを選びます。

$ docker exec -it $(docker run -d intersystemsdc/iris-community:2019.4.0.383.0-zpm) bash
$ iris session iris
USER>write ##class(Math.Math).Factorial(5)
<CLASS DOES NOT EXIST> *Math.Math
USER>zpm
zpm: USER>list
zpm: USER>repo -list
registry
   Source:    https://pm.community.intersystems.com
   Enabled?   Yes
   Available?   Yes
   Use for Snapshots?   Yes
   Use for Prereleases?   Yes
zpm: USER>repo -n registry -r -url http://104.199.6.32:52773/registry/ -user _system -pass SYS
zpm: USER>repo -list
registry
   Source:    http://104.199.6.32:52773/registry/
   Enabled?   Yes
   Available?   Yes
   Use for Snapshots?   Yes
   Use for Prereleases?   Yes
   Username:    _system
   Password:    <set>
zpm: USER>repo -list-modules -n registry
objectscript-math 0.0.4
zpm: USER>install objectscript-math
[objectscript-math]   Reload START
...
[objectscript-math]   Activate SUCCESS

zpm: USER>quit
USER>write ##class(Math.Math).Factorial(5)
120

おめでとうございます！
いらなくなった GKE クラスタは、忘れずに削除しておきましょう。

まとめ

InterSystems のコミュニティには GitHub Actions のリファレンスがそれほど多くありません。見つかったのは、エキスパート @mdaimor のメンション 1 つのみです。ですが、GitHub Actions はコードを GitHub に保管するディベロッパーにとって非常に重宝すると思われます。ネイティブアクションは JavaScript でしかサポートされていませんが、これはディベロッパーの多くがコードを使ってステップを説明することに慣れており、そうすることが望ましいということかもしれません。いずれにしても、JavaScript に詳しくない方は Docker アクションを使えばいいと思います。

GitHub Actions の UI に関して、使っているうちに不便に感じたことがいくつかあり、知っておくべきだと思うことを紹介しておきます。

ジョブのステップが完了するまで、その状況を確認できない。 "Terraform apply" のステップのように、クリックすることができない。

失敗したワークフローは再実行できる一方で、成功したワークフローを再実行する方法が見つからなかった。

2 つ目のポイントの次善策として、次のコマンドを使います。

$ git commit --allow-empty -m "trigger GitHub actions"

これに関する詳細は、StackOverflow に投稿されている How do I re-run Github Actions? (Github Actions はどうすれば再実行できるか？) という質問をご覧ください。

#InterSystems IRIS #Open Exchange #DevOps #Docker #GitHub #Kubernetes #クラウド #コンテナ化

Open Exchange

0 0

0 491

お知らせ Mihoko Iijima · 12月 4, 2020

テクノロジーボーナス詳細：第8回 InterSystems IRIS プログラミングコンテスト：Analytics コンテスト

開発者の皆さん、こんにちは！

第8回 Analytics コンテストの続報 📣 の「テクノロジーボーナス」について紹介します。

InterSystems IRIS BI（旧DeepSee）
InterSystems IRIS NLP
IntegratedML
実データの利用
ZPM を利用したパッケージの開発
Docker コンテナの利用

ボーナス詳細は以下ご参照ください。

InterSystems IRIS BI - 1 point

InterSystems IRIS BI（旧DeepSee）は、IRIS の分析機能で、IRIS に格納されたデータに対して BI キューブやピボットを作成し、インタラクティブなダッシュボードを使用してユーザーに情報を提供することができます。

InterSystems IRIS BI のドキュメントはこちらからご参照いただけます。

開発環境のテンプレート（IRIS-Analytics-template）には、IRIS BI のキューブ、ピボット、ダッシュボードの例が含まれています。
使い方の日本語解説ビデオ付き記事もあります。ぜひご活用ください！

InterSystems IRIS NLP (iKnow) - 1 point

#InterSystems IRIS #InterSystems IRIS for Health #Docker #コンテナ化 #ビデオ #分析

0 0

0 127

お知らせ Mihoko Iijima · 11月 26, 2020

開発テンプレート（IRIS Analytics Template）の使い方のご紹介（第8回 InterSystems IRIS Analytics コンテスト）

開発者の皆さん、こんにちは！

この投稿では、第8回 InterSystems IRIS Analytics コンテストの開発テンプレート（IRIS Analytics Template）の使い方をご紹介します。

開発テンプレートは、Gitからソースコードをダウンロードし、コンテナを開始するだけで Johns Hopkins repository で公開されている COVID-19 のデータを使用した InterSystems BI（旧DeepSee）での分析環境が準備できます（サンプルデータが入ったテーブル、モデル定義、ピボットテーブル、ダッシュボードが準備されます）。

コンテストでは、開発テンプレートをベースとし、コードを追加しながらオリジナルアプリケーションを開発いただいたり、新規で作成いただいたり、自由に開発いただけます。

InterSystems BI を使ったアプリケーションでチャンレンジされる場合は、ぜひ、ここで紹介している開発テンプレートをご利用ください！

この他、サンプルアプリケーションの例は、コンテスト告知ページをご参照ください！

メモ：開発テンプレートはコンテスト以外の目的にもご活用いただけます！

以下、事前準備についてご説明します。

開発テンプレートをご利用いただくために、以下 3 つのソフトウェアのインストールが必要です。

#InterSystems IRIS #InterSystems IRIS for Health #コンテスト #コンテナ化 #ビデオ #分析

1 2

0 295

記事 Toshihiko Minamoto · 11月 26, 2020 17m read

CircleCI ビルドで GKE の作成を自動化する

前回は GKE サービスを使用して IRIS アプリケーションを Google Cloud 上で起動しました。

また、クラスターを手動で（または gcloud を介して）作成するのは簡単ですが、最新の Infrastructure-as-Code（IaC）手法では、Kubernetesクラスターの説明もコードとしてリポジトリに格納する必要があります。このコードの記述方法は、IaC に使用されるツールによって決まります。

Google Cloud の場合は複数のオプションが存在し、その中には Deployment Manager と Terraform があります。どちらが優れているかにつては意見が分かれています。詳細を知りたい場合は、この Reddit のスレッド「Opinions on Terraform vs. Deployment Manager?」と Medium の記事「Comparing GCP Deployment Manager and Terraform」を参照してください。

この記事では特定のベンダーとの結びつきが少なく、さまざまなクラウドプロバイダーで IaC を使用できる Terraform を選択します。

ここでは過去の記事を読み、Googleアカウントを作成し、前回の記事と同様に「開発」という名前のプロジェクトを作成しているものと仮定します。この記事ではその ID は <PROJECT_ID> として表示されます。以下の例では、それを自分のプロジェクトの IDに変更してください。

Google には無料枠がありますが、無料ではないことに注意してください。必ず出費をコントロールするようにしてください。

また、ここではすでに元のリポジトリをフォークしていることを前提にしています。この記事全体を通してこのフォークを「my-objectscript-rest-docker-template」と呼び、そのルートディレクトリを「<root_repo_dir>」として参照します。

コピーと貼り付けを簡単にするため、すべてのコードサンプルをこのリポジトリに格納しています。

次の図では、デプロイプロセス全体を 1 つの図で表しています。

では、次のように執筆時点での Terraform の最新バージョンをインストールしましょう。

$ terraform version
Terraform v0.12.17

インターネット上の多くの例では旧バージョンが使用されており、0.12 では多くの変更が加えられているため、ここではバージョンが重要になります。

ここでは GCP アカウントで Terraform に特定のアクションを実行（特定の API を使用）させたいと考えています。これを可能にするには「terraform」という名前のサービスアカウントを作成し、Kubernetes Engine API を有効にしてください。その実施方法についてはご心配なく。この記事を読み進めるだけで、あなたの疑問は解消します。

Web Console を使用することもできますが、ここでは gcloud ユーティリティを使った例を試してみましょう。

次の例では、数種類のコマンドを使用します。これらのコマンドや機能の詳細については、次のドキュメントのトピックを参照指定してください。

gcloud iam service-accounts create

特定のリソースのサービスアカウントへの役割の付与

gcloud iam service-accounts keys create

Google Cloud プロジェクトでの API の有効化

それでは、例を見ていきましょう。

$ gcloud init

前回の記事で gcloud を取り上げましたので、ここではセットアップの詳細は説明しません。この例では、次のコマンドを実行します。

$ cd <root_repo_dir>
$ mkdir terraform; cd terraform
$ gcloud iam service-accounts create terraform --description "Terraform" --display-name "terraform"

次に、「Kubernetes Engine Admin」（container.admin）の他にいくつかのロールを terraform サービスアカウントに追加しましょう。これらのロールは今後役に立つことでしょう。

$ gcloud projects add-iam-policy-binding <PROJECT_ID> \
--member serviceAccount:terraform@<PROJECT_ID>.iam.gserviceaccount.com \
--role roles/container.admin

$ gcloud projects add-iam-policy-binding <PROJECT_ID> \
--member serviceAccount:terraform@<PROJECT_ID>.iam.gserviceaccount.com \
--role roles/iam.serviceAccountUser

$ gcloud projects add-iam-policy-binding <PROJECT_ID> \
--member serviceAccount:terraform@<PROJECT_ID>.iam.gserviceaccount.com \
--role roles/compute.viewer

$ gcloud projects add-iam-policy-binding <PROJECT_ID> \
--member serviceAccount:terraform@<PROJECT_ID>.iam.gserviceaccount.com \
--role roles/storage.admin

$ gcloud iam service-accounts keys create account.json \
--iam-account terraform@<PROJECT_ID>.iam.gserviceaccount.com

最後の入力では、account.json ファイルを作成していることに注意してください。このファイルは必ず秘密にしてください。

$ gcloud projects list
$ gcloud config set project <PROJECT_ID>
$ gcloud services list --available | grep 'Kubernetes Engine'
$ gcloud services enable container.googleapis.com
$ gcloud services list --enabled | grep 'Kubernetes Engine'
container.googleapis.com Kubernetes Engine API

次に、Terraform の HCL 言語で GKE クラスターを記述しましょう。ここではいくつかのプレースホルダーを使用していますが、これらは実際の値に置き換えてください。

<td style="text-align: center;">
  意味
</td>

<td style="text-align: center;">
  例
</td>

<td>
    GCP のプロジェクト ID
</td>

<td>
    possible-symbol-254507
</td>

<td>
    Terraform のステート/ロック用のストレージ（一意である必要があります）
</td>

<td>
    circleci-gke-terraform-demo
</td>

<td>
    リソースが作成されるリージョン
</td>

<td>
    europe-west1
</td>

<td>
    リソースが作成されるゾーン
</td>

<td>
    europe-west1-b
</td>

<td>
    GKE クラスター名
</td>

<td>
    dev-cluster
</td>

<td>
    GKE ワーカーノードのプール名
</td>

<td>
    dev-cluster-node-pool
</td>

プレースホルダー

<PROJECT_ID>

<BUCKET_NAME>

<CLUSTER_NAME>

<NODES_POOL_NAME>

以下に実際のクラスターの HCL 構成を示します。

$ cat main.tf
terraform {
required_version = "~> 0.12"
backend "gcs" {
bucket = "<BUCKET_NAME>"
prefix = "terraform/state"
credentials = "account.json"
}
}

provider "google" {
credentials = file("account.json")
project = "<PROJECT_ID>"
region = "<REGION>"
}

resource "google_container_cluster" "gke-cluster" {
name = "<CLUSTER_NAME>"
location = "<LOCATION>"
remove_default_node_pool = true
# In regional cluster (location is region, not zone)
# this is a number of nodes per zone
initial_node_count = 1
}

resource "google_container_node_pool" "preemptible_node_pool" {
name = "<NODES_POOL_NAME>"
location = "<LOCATION>"
cluster = google_container_cluster.gke-cluster.name
# In regional cluster (location is region, not zone)
# this is a number of nodes per zone
node_count = 1

node_config {
preemptible = true
machine_type = "n1-standard-1"
oauth_scopes = [
"storage-ro",
"logging-write",
"monitoring"
]
}
}

HCL コードを適切に整形できるよう、Terraform には次の便利な整形コマンドが用意されています。

$ terraform fmt

上記のコードスニペットは、作成されたリソースが Google によって提供され、リソース自体は google_container_cluster と google_container_node_pool であることを示しています。また、ここではコスト削減のために preemptible を指定しています。また、デフォルトの代わりに独自のプールを作成しています。

次の設定を簡単に説明します。

terraform {
required_version = "~> 0.12"
backend "gcs" {
Bucket = "<BUCKET_NAME>"
Prefix = "terraform/state"
credentials = "account.json"
}
}

Terraform はすべての実行結果をステータスファイルに書き込み、このファイルを他の作業に使用します。このファイルは共有しやすいように、離れた場所に保存することをお勧めします。一般的にはGoogle バケットに保存されます。

このバケットを作成しましょう。プレースホルダー <BUCKET_NAME> の代わりに自分のバケットの名前を使用してください。バケットを作成する前に、<BUCKET_NAME> が使用できるかどうかを次のコマンドで確認してください。すべての GCP で一意である必要があるためです。

$ gsutil acl get gs://<BUCKET_NAME>

期待する応答:

BucketNotFoundException: 404 gs://<BUCKET_NAME> bucket does not exist

「Busy」という応答があった場合、別の名前を選択する必要があります。

AccessDeniedException: 403 <YOUR_ACCOUNT> does not have storage.buckets.get access to <BUCKET_NAME>

Terraform の推奨どおりにバージョン管理も有効にしましょう。

$ gsutil mb -l EU gs://<BUCKET_NAME>

$ gsutil versioning get gs://<BUCKET_NAME>
gs://<BUCKET_NAME>: Suspended

$ gsutil versioning set on gs://<BUCKET_NAME>

$ gsutil versioning get gs://<BUCKET_NAME>
gs://<BUCKET_NAME>: Enabled

Terraform はモジュール方式であり、GCP で何かを作成するにはGoogle Provider プラグインを追加する必要があります。これを行うには、次のコマンドを使用します。

$ terraform init

Terraform が GKE クラスターを作成する際の実行計画を見てみましょう。

$ terraform plan -out dev-cluster.plan

コマンドの出力には、計画の詳細が含まれています。特に問題なければ、次のコマンドでこの計画を実行しましょう。

$ terraform apply dev-cluster.plan

ちなみに、Terraform によって作成されたリソースを削除するには、このコマンドを <root_repo_dir>/terraform/ ディレクトリから実行してください。

$ terraform destroy -auto-approve

しばらくクラスターから離れて先に進みましょう。ただし、何もかもリポジトリにプッシュされないように、先にいくつかのファイルを例外に追加しましょう。

$ cat <root_repo_dir>/.gitignore
.DS_Store
terraform/.terraform/
terraform/*.plan
terraform/*.json

Helm の使用

前回の記事では、Kubernetes のマニフェストを yaml ファイルとして <root_repo_dir>/k8s/ ディレクトリに保存し、それを「kubectl apply」コマンドを使用してクラスターに送信しました。

今回は別の手法を試してみましょう。最近バージョン 3にアップデートされた Kubernetes のパッケージマネージャーである Helm を使用します。バージョン 2 には Kubernetes 側のセキュリティの問題があったため、バージョン 3 以降を使用してください（詳細については、Running Helm in production: Security best practices を参照してください）。まず、Kubernetes のマニフェストを k8s/ ディレクトリからチャートとして知られる Helm パッケージにまとめます。 Kubernetes にインストールされている Helm チャートはリリースと呼ばれます。最小構成では、チャートは次のような複数のファイルで構成されます。

$ mkdir <root_repo_dir>/helm; cd <root_repo_dir>/helm
$ tree <root_repo_dir>/helm/
helm/
├── Chart.yaml
├── templates
│ ├── deployment.yaml
│ ├── _helpers.tpl
│ └── service.yaml
└── values.yaml

これらのファイルの目的は、公式サイトで詳細に説明されています。独自チャートを作成するためのベストプラクティスは、Helm ドキュメントの The Chart Best Practices Guide に記載されています。

次にファイルの内容を示します。

$ cat Chart.yaml
apiVersion: v2
name: iris-rest
version: 0.1.0
appVersion: 1.0.3
description: Helm for ObjectScript-REST-Docker-template application
sources:
- https://github.com/intersystems-community/objectscript-rest-docker-template
- https://github.com/intersystems-community/gke-terraform-circleci-objectscript-rest-docker-template

$ cat templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ template "iris-rest.name" . }}
labels:
app: {{ template "iris-rest.name" . }}
chart: {{ template "iris-rest.chart" . }}
release: {{ .Release.Name }}
heritage: {{ .Release.Service }}
spec:
replicas: {{ .Values.replicaCount }}
strategy:
{{- .Values.strategy | nindent 4 }}
selector:
matchLabels:
app: {{ template "iris-rest.name" . }}
release: {{ .Release.Name }}
template:
metadata:
labels:
app: {{ template "iris-rest.name" . }}
release: {{ .Release.Name }}
spec:
containers:
- image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
name: {{ template "iris-rest.name" . }}
ports:
- containerPort: {{ .Values.webPort.value }}
name: {{ .Values.webPort.name }}

$ cat templates/service.yaml
{{- if .Values.service.enabled }}
apiVersion: v1
kind: Service
metadata:
name: {{ .Values.service.name }}
labels:
app: {{ template "iris-rest.name" . }}
chart: {{ template "iris-rest.chart" . }}
release: {{ .Release.Name }}
heritage: {{ .Release.Service }}
spec:
selector:
app: {{ template "iris-rest.name" . }}
release: {{ .Release.Name }}
ports:
{{- range $key, $value := .Values.service.ports }}
- name: {{ $key }}
{{ toYaml $value | indent 6 }}
{{- end }}
type: {{ .Values.service.type }}
{{- if ne .Values.service.loadBalancerIP "" }}
loadBalancerIP: {{ .Values.service.loadBalancerIP }}
{{- end }}
{{- end }}

$ cat templates/_helpers.tpl
{{/* vim: set filetype=mustache: */}}
{{/*
Expand the name of the chart.
*/}}

{{- define "iris-rest.name" -}}
{{- default .Chart.Name .Values.nameOverride | trunc 63 | trimSuffix "-" -}}
{{- end -}}

{{/*
Create chart name and version as used by the chart label.
*/}}
{{- define "iris-rest.chart" -}}
{{- printf "%s-%s" .Chart.Name .Chart.Version | replace "+" "_" | trunc 63 | trimSuffix "-" -}}
{{- end -}}

$ cat values.yaml
namespaceOverride: iris-rest

replicaCount: 1

strategy: |
type: Recreate

image:
repository: eu.gcr.io/iris-rest
tag: v1

webPort:
name: web
value: 52773

service:
enabled: true
name: iris-rest
type: LoadBalancer
loadBalancerIP: ""
ports:
web:
port: 52773
targetPort: 52773
protocol: TCP

Helm チャートを作成するには、Helm クライアントと kubectl コマンドラインユーティリティをインストールします。

$ helm version
version.BuildInfo{Version:"v3.0.1", GitCommit:"7c22ef9ce89e0ebeb7125ba2ebf7d421f3e82ffa", GitTreeState:"clean", GoVersion:"go1.13.4"}

iris というネームスペースを作成します。デプロイ中にこれが作成されていれば良かったのですが、現時点ではその動作は実装されていません。

まず、Terraform によって作成されたクラスターの資格情報を kube-config に追加します。

$ gcloud container clusters get-credentials <CLUSTER_NAME> --zone <LOCATION> --project <PROJECT_ID>
$ kubectl create ns iris

Helm が Kubernetes で以下を作成することを（実際にデプロイを開始せずに）確認します。

$ cd <root_repo_dir>/helm
$ helm upgrade iris-rest \
--install \
. \
--namespace iris \
--debug \
--dry-run

ここでは、出力（Kubernetes のマニフェスト）をスペースを確保するために省略しています。特に問題がなければ、デプロイしましょう。

$ helm upgrade iris-rest --install . --namespace iris
$ helm list -n iris --all
Iris-rest iris 1 2019-12-14 15:24:19.292227564 +0200 EET deployed iris-rest-0.1.0 1.0.3

Helm がアプリケーションをデプロイしたことはわかりますが、Docker イメージ eu.gcr.io/iris-rest:v1 をまだ作成していないため、Kubernetes がそのイメージをプルすることはできません（ImagePullBackOff）。

$ kubectl -n iris get po
NAME READY STATUS RESTARTS AGE
iris-rest-59b748c577-6cnrt 0/1 ImagePullBackOff 0 10m

とりあえず、今はここで終わっておきましょう。

$ helm delete iris-rest -n iris

CircleCI 側

Terraform と Helm クライアントを試しましたので、それらを CircleCI 側のデプロイプロセスで使用できるようにしましょう。

$ cat <root_repo_dir>/.circleci/config.yml
version: 2.1

orbs:
gcp-gcr: circleci/gcp-gcr@0.6.1

jobs:
terraform:
docker:
# Terraform image version should be the same as when
# you run terraform before from the local machine
- image: hashicorp/terraform:0.12.17
steps:
- checkout
- run:
name: Create Service Account key file from environment variable
working_directory: terraform
command: echo ${TF_SERVICE_ACCOUNT_KEY} > account.json
- run:
name: Show Terraform version
command: terraform version
- run:
name: Download required Terraform plugins
working_directory: terraform
command: terraform init
- run:
name: Validate Terraform configuration
working_directory: terraform
command: terraform validate
- run:
name: Create Terraform plan
working_directory: terraform
command: terraform plan -out /tmp/tf.plan
- run:
name: Run Terraform plan
working_directory: terraform
command: terraform apply /tmp/tf.plan
k8s_deploy:
docker:
- image: kiwigrid/gcloud-kubectl-helm:3.0.1-272.0.0-218
steps:
- checkout
- run:
name: Authorize gcloud on GKE
working_directory: helm
command: |
echo ${GCLOUD_SERVICE_KEY} > gcloud-service-key.json
gcloud auth activate-service-account --key-file=gcloud-service-key.json
gcloud container clusters get-credentials ${GKE_CLUSTER_NAME} --zone ${GOOGLE_COMPUTE_ZONE} --project ${GOOGLE_PROJECT_ID}
- run:
name: Wait a little until k8s worker nodes up
command: sleep 30 # It’s a place for improvement
- run:
name: Create IRIS namespace if it doesn't exist
command: kubectl get ns iris || kubectl create ns iris
- run:
name: Run Helm release deployment
working_directory: helm
command: |
helm upgrade iris-rest \
--install \
. \
--namespace iris \
--wait \
--timeout 300s \
--atomic \
--set image.repository=eu.gcr.io/${GOOGLE_PROJECT_ID}/iris-rest \
--set image.tag=${CIRCLE_SHA1}
- run:
name: Check Helm release status
command: helm list --all-namespaces --all
- run:
name: Check Kubernetes resources status
command: |
kubectl -n iris get pods
echo
kubectl -n iris get services
workflows:
main:
jobs:
- terraform
- gcp-gcr/build-and-push-image:
dockerfile: Dockerfile
gcloud-service-key: GCLOUD_SERVICE_KEY
google-compute-zone: GOOGLE_COMPUTE_ZONE
google-project-id: GOOGLE_PROJECT_ID
registry-url: eu.gcr.io
image: iris-rest
path: .
tag: ${CIRCLE_SHA1}
- k8s_deploy:
requires:
- terraform
- gcp-gcr/build-and-push-image

CircleCI 側のプロジェクトに次のようないくつかの環境変数を追加する必要があります。

GCLOUD_SERVICE_KEY は CircleCI のサービスアカウントキーであり、TF_SERVICE_ACCOUNT_KEY は Terraform のサービスアカウントキーです。サービスアカウントキーが account.json ファイル全体の内容であることを思い出してください。

次に、変更をリポジトリにプッシュしましょう。

$ cd <root_repo_dir>
$ git add .circleci/ helm/ terraform/ .gitignore
$ git commit -m "Add Terraform and Helm"
$ git push

CircleCI UI ダッシュボードには、次のようにすべてが正常であることが示されているはずです。

Terraform は冪等性のあるツールであり、GKE クラスターが存在する場合、「terraform」ジョブは何も実行しません。クラスターが存在しない場合は、Kubernetes をデプロイする前に作成されます。
最後に、IRIS の可用性を確認しましょう。

$ gcloud container clusters get-credentials <CLUSTER_NAME> --zone <LOCATION> --project <PROJECT_ID>

$ kubectl -n iris get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
Iris-rest LoadBalancer 10.23.249.42 34.76.130.11 52773:31603/TCP 53s

$ curl -XPOST -H "Content-Type: application/json" -u _system:SYS 34.76.130.11:52773/person/ -d '{"Name":"John Dou"}'

$ curl -XGET -u _system:SYS 34.76.130.11:52773/person/all
[{"Name":"John Dou"},]

まとめ

Terraform と Helm は標準の DevOps ツールであり、IRIS のデプロイと緊密に統合する必要があります。

これらはある程度の学習を必要としますが、何度か実践した後は大幅に時間と労力を節約できるようになります。

#InterSystems IRIS #Open Exchange #DevOps #Docker #Google Cloud Platform (GCP) #Kubernetes #クラウド #コンテナ化

Open Exchange

0 0

0 838

お知らせ Mihoko Iijima · 11月 2, 2020

テクノロジーボーナス詳細　InterSystems IRIS プログラミングコンテスト：Interoperability（相互運用性）コンテスト

開発者の皆さん、こんにちは！

Interoperability（相互運用性）コンテストの続報の「テクノロジーボーナス」について紹介します。

対象となる技術は、以下の通りです。

BPL エディタを利用したビジネス・プロセスの開発、または、ビジネスルールとデータ変換（DTL）を使用した開発
カスタムアダプタを使用した開発
プロダクションエクステンション（PEX）Java または .NET を使用した開発
ワークフローエンジンを使用した開発
ZPM パッケージによるデプロイが行える開発環境
Docker コンテナを使用した開発

それぞれの詳細については以下ご参照ください。

BPL エディタを利用したビジネス・プロセスの開発、または、ビジネスルールとデータ変換（DTL）を使用した開発 - 1 point

IRIS の Interoperability（相互運用性）プロダクションの特徴の1つである、BPL エディタで記述できるビジネス・プロセスがあります。また、ビジネス・ルールは、Interoperability プロダクション内で実行したい処理を、ノーコード/ローコードのアプローチで指定できる開発エディタです（ビジネス・ルールを利用するためには、構築済ビジネス・プロセスを使用します）。

以下参考ドキュメントをご参照ください。

#InterSystems IRIS #InterSystems IRIS for Health #コンテスト #コンテナ化 #相互運用性

0 0

0 240

InterSystems公式 Toshihiko Minamoto · 10月 11, 2020

InterSystems IRIS の新しいリリースの流れ

InterSystems は、InterSystemsIRIS を新しいリリース方法を採用しようとしています（訳注：2020年現在、このリリース方法が採用されています）。このブログでは、新しいリリースモデルとお客様が予測しておくべきことを説明しています。この内容は InterSystems IRIS ロードマップセッションの最後に行われた Global Summit で説明し、お客様から多くの肯定的なフィードバックを受け取ったものです。

この新しいモデルでは、次の 2 つのリリースストリームを提供しています。

1）EM と呼ばれる従来と同じ毎年恒例のリリース（拡張メンテナンス）

2）CD（継続的デリバリーを意味する）のタグが付けられ、コンテナ形式でのみ入手可能になる四半期ごとのリリース。

変更の理由はスピードと予測性の向上

この業界では変化のペースが加速していますが、このモデルを採用すれば最新機能を非常に迅速に公開し、市場での応答性と競争力を高めることができます。当社は多くのお客様から次の 2 つを求められています。

新機能をリクエストしてからそれを使用できるようになるまでの時間の短縮

アップデート計画を立てるための予測可能なスケジュール

この継続的デリバリーの原則に基づいた新しいリリースの流れは、多くの主要ソフトウェア会社やエンタープライズ対応のオープンソースプロジェクトの大部分で使用されている 2 ストリームモデルとほぼ同等のものです。この方法の採用に成功した人々は、リリースの品質が向上し、リスクが低下し、応答時間が短縮されたことを明確に報告しています。

従来のリリース方針は変更なし

従来と同じリリース（「EM」リリース）はこれまでと同じように行われます。このリリースは継続的なメンテナンスリリースの対象となり、必要に応じてその場その場で提供され、すべてのプラットフォームでサポートされます。従来通り、全製品のインストールキットは WRC Software Distribution ポータルを通じて入手できます。フィールドテストはこれまでと同様にメジャーリリースで利用できます。メンテナンスリリースは従来と同じ基本ルールが適用され、EMリリースで利用できます。

以前と異なるのは、これらのリリースが毎年予測可能なタイミングで提供されるようになることです。次の図に示すように、InterSystems IRIS のバージョン 2019.1 は 2019 年 3 月に、バージョン 2020.1 は 2020 年 3 月に予定されています。

新しい四半期リリースではコンテナのみが提供

3 カ月ごとに新しい四半期リリースストリームを介して「CD」表記の新機能が提供されるようになります。例えば次の図に示すように、InterSystems IRIS バージョン 2018.2 CD は 2018 年 11 月に、バージョン 2019.1 CD は 2019 年 2 月に、バージョン 2019.2 CD は 2019 年 5 月に予定されています。

CD リリースには次の制限があります。

Open Container Initiative（OCI）フォーマットを使用するコンテナイメージとしてのみ入手できます。このフォーマットは、Docker / Amazon / Microsoft / Google / IBM などの多くの企業で広く使用され、サポートされています。

OCI 互換のインフラストラクチャのみで動作します。 Docker は最も一般的な OCI ランタイムであるため、InterSystems は Ubuntu Linux カーネルで構築された Docker コンテナの提供とサポートを行っています。このコンテナは、すべての主要クラウドプラットフォーム（Amazon AWS / Microsoft Azure / Google GCP/ IBM Cloud）と事実上すべての種類の Linux、Windows Server 2016 / 2019 などのさまざまなプラットフォームで実行されます。 InterSystems は Docker-for-windows と Docker-for-mac をそれぞれ使用する開発専用の Windows 10 と Mac OS へのコンテナのデプロイをサポートしています。（現時点で OCI コンテナをサポートしていない代表的なプラットフォームは AIX です。）

これらはコンテナであるため、インストールやイメージのアップグレードは不要です。 InterSystems が提供するコンテナイメージを使用し、それともとに独自のイメージを作成できます。デプロイする場合は、単純にコンテナを入れ替えるだけです。データのアップグレードが必要な場合、InterSystems はリリースと共にアップグレードを提供します。

CD リリースに関して、InterSystems はメンテナンスリリース、セキュリティ修正、またはAdhoc(パッチ修正)を提供しません。変更を取得したい場合は、単純に次のリリースを取得してください。最新の変更が加えられた新しいリリースが 3 カ月ごとに提供されるため、重要な修正を待つ必要はありません。

InterSystems は開発、テスト、および本番環境を対象に CD リリースを完全にサポートしています。 InterSystems は各 CD リリースに加えてプレビュープログラムも用意し、最終リリースの前にプレビューイメージを提供します。プレビューイメージは、開発およびテストを目的とする場合はサポートされますが、本番環境ではサポートされていません。

コンテナは比較的新しいものですが、現在は広く使用されており、多くのメリットがあります。お客様は CD リリースを使用したり、コンテナを採用したりする必要はありません。ただし、コンテナ内で InterSystems IRIS を使用するのに役立つ多くの InterSystems のリソース（複数のオンライン動画を含む）が存在するほか、業界全体には大規模なコンテナ周辺のエコシステムがあります。

CD リリースは新機能を迅速に提供するほか、従来の（EM）リリースの予測可能性と安定性の向上に役立ちます。今年最初の CD リリースには対応する EM リリースがあります（プラットフォーム固有の機能を除いては同じものです）。また、これらには以前の CD リリースのすべての機能に加えてさらに多くの機能が追加されています。開発者は CD リリースで作業でき、コードが従来のリリースでも機能することを確信できます。CD リリースを試さなかった場合でも、四半期ごとに InterSystems IRIS でリリースされた機能を追跡し、自信を持って計画を立てることができます。

#InterSystems IRIS #InterSystems公式 #コンテナ化 #継続的デリバリー

0 0

1 391

お知らせ Mihoko Iijima · 9月 13, 2020

第6回 InterSystems IRIS プログラミングコンテスト（Full Stackコンテスト）

開発者の皆さんこんにちは！IRIS プログラミングコンテストも 6 回目を迎えました！

今回のコンテストのテーマは

「InterSystems IRIS をバックエンドとし Web またはモバイル・ソリューションをフロントエンドとして使用する⚡️フル・スタック・アプリケーション⚡️」

です。日本からのご応募お待ちしております！

Open Exchange（アプリケーション登録／参考となる開発テンプレート）のページはこちら➡　⚡️ InterSystems Full Stack Contest ⚡️

応募期間は 2020年9月21日～10月4日です！

（投票期間は 2020年10月5日～11日、勝者発表は 10月12日を予定しています）

優勝特典

１、審査員から多く票を集めたアプリケーションには、以下の賞金が贈られます。

🥇 1位 - $2,000

🥈 2位 - $1,000

🥉 3位 - $500

2、Developer Community で多く票を集めたソリューションには、以下の賞金が贈られます。

🥇 1位 - $1,000

🥈 2位 - $500

複数の参加者が同数の票を獲得した場合、全参加者が勝者となり賞金は勝者間で分配されます。

参加資格

どなたでもご参加いただけます！（InterSystems 開発者コミュニティのアカウントを作成するだけでご応募いただけます）

コンテストのスケジュール

#InterSystems IRIS #InterSystems IRIS for Health #IRIS contest #CSP #IntegratedML #JDBC #REST API #イベント #コンテスト #コンテナ化

0 1

0 325

開発者コミュニティのリソース

InterSystems リソース集

ソーシャルネットワーク

#コンテナ化

InterSystemsコンテナレジストリ Webユーザインターフェースのお知らせ

コミュニティエディションコンテナ

エンタープライズエディションコンテナ

実行方法

テスト方法

システムダッシュボード

システムメニュー

システムプロセス

プロセスフィルター

履歴モニター

日付範囲の選択ツール

グラフ/データテーブル

ズーム機能

平均と最大

平均

最大

Raspberry を FHIRserver として実行する

InterSystems FHIRserver

Raspbian から Ubuntu へ

InterSystems FHIRserver のインストール

フェーズ 1: Ubuntu 64 ビット

フェーズ 2: Docker

フェーズ 3: InterSystems の IRIS FHIRserver の Docker イメージ

フェーズ 4: InterSystems IRIS for Health Fhirserver の起動

まとめ

目的:

対象範囲

対象:

対象外またはウィッシュリスト:

GitHubリポジトリ

デプロイメントのパターン

環境トポロジー

Docker化コンポーネント

サービスの起動

テスト

1. 単純なUIを備えたAIデモWebアプリ

2. テストデモAPI

3. デモサービスAPIをベンチマークテストする

今後の内容

事後警告。 イメージのバージョンを必ず確認してください！私はntersystems/iris-community:2020.2.0.204にハマってしまいました。

インストール

特典1 ARM上のIRIS

特典2 - バックアップと復元

プログラムによるバックアップ/復元

コンテナ

1)処理概要

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

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

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

コマンドの比較

Linux

Windows

InterSystems IRIS BI - 1 point

InterSystems IRIS NLP (iKnow) - 1 point

メモ：開発テンプレートはコンテスト以外の目的にもご活用いただけます！

BPL エディタを利用したビジネス・プロセスの開発、または、ビジネスルールとデータ変換（DTL）を使用した開発 - 1 point

応募期間は 2020年9月21日～10月4日 です！

話題のアプリ

数字で見るコミュニティ

事後警告。イメージのバージョンを必ず確認してください！
私はntersystems/iris-community:2020.2.0.204にハマってしまいました。

応募期間は 2020年9月21日～10月4日です！