検索

クリアフィルター
お知らせ
Makiko Kokubun · 2021年2月9日

【アーカイブ配信のお知らせ】InterSystems IRIS データプラットフォーム 概要

開発者の皆さん、こんにちは! InterSystems 開発者コミュニティでは、初めてIRIS を使われる方向けに、IRIS の概要をご紹介するウェビナーを開催致しました。そのウェビナーのアーカイブを公開致しました。 インターシステムズのデータプラットフォーム製品をご覧になるソフトウェアエンジニアの方向けに、弊社のエンジニアが 約 30分でその特徴をご紹介します。ぜひご覧ください。 アーカイブ配信はこちらから ウェビナー(アーカイブ配信)「InterSystems IRIS データプラットフォーム 概要」 配信時間:23分 無料でご視聴頂けます。 アーカイブはこちら(ON24を使用しています)https://event.on24.com/wcc/r/2982378/17DE6BE0C44C34513F10A8D7C7B68FB0 以下のような開発者の方におすすめです。 初めてインターシステムズのデータプラットフォーム製品をお使いになる方、ご興味のある方 新しいデータプラットフォームを試してみたい方 Caché から IRIS への移行をご検討中の方 ぜひご視聴ください!
お知らせ
Yoichi Miyashita · 2021年3月30日

InterSystems 製品 2018.1.5, 2019.1.2, 2020.1.1 リリースのご案内

インターシステムズは、以下のメンテナンスバージョンをリリースしました。 Caché, Ensemble, HealthShare Health Connect (HSAP) 2018.1.5 InterSystems IRIS, IRIS for Health, HealthShare Health Connect 2019.1.2 InterSystems IRIS, IRIS for Health, HealthShare Health Connect 2020.1.1 これらのメンテナンスリリースは幅広い分野の多くの修正を含みます。各リリースの修正情報は、それぞれのバージョンのドキュメントに含まれるリリースノートをご確認ください。ドキュメントにはリリースノートの他にアップグレードチェックリスト、リリース変更リスト、クラスリファレンスおよびガイド、リファレンス、チュートリアルやアーティクルの完全なセットを含みます。リリースノートを含む英語ドキュメントは こちら から参照できます。最新情報を除く 日本語ドキュメント もご参照ください。 これらのリリースでは新しくサポートするプラットフォームを追加しました。特に、すべてのリリースで Ubuntu 20.04 LTS をサポートします。2019.1.2 は IBM AIX 7.1, 7.2 for System p-64 を新たにサポートします。(2020.1 ではこのプラットフォームは既にサポートされています)2020.1.1 には ARM64 support for Linux が追加されます。サポートプラットフォームの詳細は各リリースドキュメントの Supported Platforms (英語) をご確認ください。 キットが必要なお客様は、カスタマーサポートセンターまでご連絡いただき、必要なプラットフォームをお知らせください。また、WRC Direct ユーザの方は こちら より入手可能です。各リリースのビルド番号は以下の通りです。 Caché, Ensemble 2018.1.5: 2018.1.5.659.0 HSAP 2018.1.5: 2018.1.5HS.9056.0 InterSystems IRIS, IRIS for Health, HealthShare Health Connect 2019.1.2: 2019.1.2.718.0 InterSystems IRIS, IRIS for Health, HealthShare Health Connect 2020.1.1: 2020.1.1.408.0
お知らせ
Mihoko Iijima · 2021年9月13日

★受賞者発表!★InterSystems Analytics コンテスト2021

開発者の皆さん、こんにちは! InterSystems Analytics コンテスト2021 は終了しました。コーディングコンテストにご参加いただきありがとうございました! この記事では、コンテスト受賞者を発表します! 受賞された開発者の皆さん、👏おめでとうございます!🎊 🏆 Experts Nomination - 特別に選ばれた審査員によって選出されました。 🥇 1位 - $4,000 は、promjet-stats を開発された @Evgeniy.Potapov さんに贈られました! 🥈 2位 - $2,000 は、iris-analytics-datastudio を開発された @Dmitry.Maslennikov さんに贈られました! 🥉 3位 - $1,000 は、pop-song-analytics を開発された @Henry.HamonPereira さんに贈られました! 🏆 Community Nomination - 最も多くの票を獲得したアプリケーションに贈られます。 🥇 1位 - $1,000 は、iris-analytics-datastudio を開発された @Dmitry.Maslennikov さんに贈られました! 🥈 2位 - $500 は、AlertDashboard を開発された @John Pan さんに贈られました! 🥉 3位 - $250 は、promjet-stats を開発された @Evgeniy.Potapov さんに贈られました! 🎊 受賞者の皆様、おめでとうございます!👏 今回も、コンテストにご注目いただきありがとうございました!
お知らせ
Mihoko Iijima · 2021年10月26日

★受賞者発表!★InterSystems Interoperability コンテスト 2021

開発者の皆さん、こんにちは! InterSystems Interoperability コンテスト 2021 の投票結果が発表されました! 今回も、コーディングコンテストにご興味おもちいただきありがとうございました! この記事では、コンテスト受賞者を発表します! 受賞された開発者の皆さん、👏おめでとうございます!🎊 🏆 Experts Nomination - 特別に選ばれた審査員によって選出されました。 🥇 1位 - $4,000 は、Node-RED node for InterSystems IRIS を開発された @Dmitry.Maslennikov さんに贈られました! 🥈 2位 - $2,000 は、IRIS Interoperability Message Viewer を開発された @Henrique.GonçalvesDias さんに贈られました! 🥉 3位 - $1,000 は、IRIS Big Data SQL Adapter を開発された @Yuri.Gomes さんに贈られました! さらに! 🏅 $100 - appmsw-telealerts を開発された @MikhailenkoSergey さんに贈られました! 🏅 $100 - CSV to M$-OFX を開発された @Robert.Cemper1003 さんに贈られました! 🏅 $100 - ESKLP を開発された @Aleksandr.Kalinin6636 さんに贈られました! 🏅 $100 - LabResultsVerification-hl7 を開発された @Muhammad.Waseem さんに贈られました! 🏅 $100 - interoperability-for-money を開発された @Oliver.Wilms さんに贈られました! 🏅 $100 - iris-crypto-tracker を開発された @Evgeniy.Potapov さんに贈られました! 🏆 Community Nomination - 最も多くの票を獲得したアプリケーションに贈られます。 🥇 1位 - $1,000 は、IRIS Interoperability Message Viewer を開発された @Henrique.GonçalvesDias に贈られました! 🥈 2位 - $500 は、Node-RED node for InterSystems IRIS を開発された @Dmitry.Maslennikov に贈られました! 🥉 3rd位 - $250 は、IRIS Big Data SQL Adapter を開発された @Yuri.Gomes に贈られました! 🎊 受賞者の皆様、おめでとうございます!👏 今回も、コンテストにご注目いただきありがとうございました!
お知らせ
Toshihiko Minamoto · 2022年3月3日

Caché、Ensemble、InterSystems IRIS メンテナンスリリースのご案内

注意事項:前回リリースしましたビルド2021.1.1.324.0には問題があります。 2021.1.1 メンテナンスリリースはWRCから削除し、ビルド2021.1.2.336.0 に更新しています。2021.1.2のコンテナ版はまもなくリリースする予定です。 2種類のメンテナンスリリースが利用可能です。 Caché 2018.1.6, Ensemble 2018.1.6, HSAP 2018.1.6 InterSystems IRIS 2020.1.2, IRIS for Health 2020.1.2, HealthShare Health Connect 2020.1.2 インストレーションキットやコンテナはWRC ソフトウェア配布サイト からダウンロードできます。 Container images for the Enterprise Editions of InterSystems IRISや IRIS for Health の Enterprise Editionのコンテナイメージ、すべての関連コンポーネントはInterSystems Container Registry から取得できます。 これらのリリースは、幅広い分野で多くのアップデートが行われたメンテナンスリリースです。リリースノート、アップグレードチェックリスト、クラスリファレンス、ガイド、リファレンス、チュートリアル、記事などが含まれています。 すべてのドキュメントは、docs.intersystems.comからアクセス可能です。 これらのリリースのビルド番号は以下の通りです。 バージョン 製品 ビルド番号 2018.1.6 Caché 、 Ensemble 2018.1.6.717.0 2018.1.6 Caché 評価用 2018.1.6.717.0su 2018.1.6 HealthShare Health Connect (HSAP) 2018.1.6HS.9063.0 2020.1.2 InterSystems IRIS 2020.1.2.517.0 2020.1.2 IRIS for Health 2020.1.2.517.0 2020.1.2 HealthShare Health Connect 2020.1.2.517.0 2020.1.2 IRIS スタジオ 2021.1.2.517.0 2021.1.2 InterSystems IRIS 2021.1.2.336.0 2021.1.2 IRIS for Health 2021.1.2.336.0 2021.1.2 HealthShare Health Connect 2021.1.2.336.0 2021.1.2 IRIS スタジオ 2021.1.2.336.0 InterSystems IRIS、IRIS for Healthのコンテナイメージ、ならびに関連コンポーネントについては InterSystems Container Registry から取得可能です。2020.1.2 を取得するコマンドは以下の通りです。 docker pull containers.intersystems.com/intersystems/iris:2020.1.2.517.0 docker pull containers.intersystems.com/intersystems/irishealth:2020.1.2.517.0 docker pull containers.intersystems.com/intersystems/iris-arm64:2020.1.2.517.0 docker pull containers.intersystems.com/intersystems/irishealth-arm64:2020.1.2.517.0 すべての利用可能なイメージの一覧を取得するには ICR ドキュメント をご参照ください。
記事
Toshihiko Minamoto · 2022年6月24日

Intersystems IRIS と組み込み Python の相互運用性

# 1. interoperability-embedded-python この概念実証では、**embedded Python** で **IRIS 相互運用フレームワーク**をどのように使用できるかについて示すことを目的としています。 ## 1.1. 目次 - [1. interoperability-embedded-python](#1-interoperability-embedded-python) - [1.1. 目次](#11-table-of-contents) - [1.2. 例](#12-example) - [1.3. コンポーネントの登録](#13-regsiter-a-component) - [2. デモ](#2-demo) - [3. 前提条件](#3-prerequisites) - [4. Docker を使用したインストール](#4-installation-with-docker) - [5. Docker を使用しないインストール](#5-installation-without-docker) - [6. サンプルの実行方法](#6-how-to-run-the-sample) - [7. リポジトリの内容](#7-whats-inside-the-repository) - [7.1. Dockerfile](#71-dockerfile) - [7.2. .vscode/settings.json](#72-vscodesettingsjson) - [7.3. .vscode/launch.json](#73-vscodelaunchjson) - [7.4. .vscode/extensions.json](#74-vscodeextensionsjson) - [7.5. src フォルダ](#75-src-folder) - [8. 新しいコンポーネントの追加方法](#8-how-to-add-a-new-component) - [8.1. InboundAdapter](#81-inboundadapter) - [8.2. OutboundAdapter](#82-outboundadapter) - [8.3. BusinessService](#83-businessservice) - [8.4. BusinessProcess](#84-businessprocess) - [8.5. BusinessOperation](#85-businessoperation) - [8.6. コンポーネントの登録](#86-regsiter-a-component) - [8.7. Grongier.PEX の直接利用](#87-direct-use-of-grongierpex) - [9. 今後の取り組み](#9-future-work) - [10. クレジット](#10-credits) ## 1.2. 例 ```python import grongier.pex import iris import MyResponse class MyBusinessOperation(grongier.pex.BusinessOperation): def OnInit(self): print("[Python] ...MyBusinessOperation:OnInit() is called") self.LOGINFO("Operation OnInit") return def OnTeardown(self): print("[Python] ...MyBusinessOperation:OnTeardown() is called") return def OnMessage(self, messageInput): if hasattr(messageInput,"_IsA"): if messageInput._IsA("Ens.StringRequest"): self.LOGINFO(f"[Python] ...This iris class is a Ens.StringRequest with this message {messageInput.StringValue}") self.LOGINFO("Operation OnMessage") response = MyResponse.MyResponse("...MyBusinessOperation:OnMessage() echos") return response ``` ## 1.3. コンポーネントの登録 **ObjectScript は不要です**。 これは、Grongier.PEX.Utils.RegisterComponent() メソッドを使用できるためです。 Embedded Python シェルから始めます。 ```sh /usr/irissys/bin/irispython ``` 次に、このクラスメソッドを使用して、新しい py ファイルを相互運用のためのコンポーネントリストに追加します。 ```python iris.cls("Grongier.PEX.Utils").RegisterComponent(,,,,) ``` 例: ```python iris.cls("Grongier.PEX.Utils").RegisterComponent("MyCombinedBusinessOperation","MyCombinedBusinessOperation","/irisdev/app/src/python/demo/",1,"PEX.MyCombinedBusinessOperation") ``` これはハックであり、本番用ではありません。 # 2. デモ 本番には純粋な Python によるコンポーネントが 4 つあります。 * 2 つのビジネスサービス: * Grongier.PEX.MyCombinedBusinessService: 同期メッセージがビジネスオペレーションに連続して送信されます。 * これらのメッセージは、JSON で作成されて Grongier.PEX.Message に格納される Python オブジェクトです。 * Python コード: src/python/demo/MyCombinedBusinessService.py * Grongier.PEX.MyBusinessService: 基本的に何も行いません。メッセージログを書き込む生のビジネスサービスです。 * Python コード: src/python/demo/MyBusinessService.py * 2 つのビジネスオペレーション: * Grongier.PEX.BusinessOperation: Grongier.PEX.MyCombinedBusinessService からメッセージを受け取ります。 * Python コード: src/python/demo/MyBusinessOperation.py * Grongier.PEX.CombinedBusinessOperation: Ens.StringRequest メッセージを受け取り、Ens.StringResponse で応答します。 * Python コード: src/python/demo/MyCombinedBusinessOperation.py Python ネイティブメッセージの新しい JSON トレース: # 3. 前提条件 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) と [Docker desktop](https://www.docker.com/products/docker-desktop) がインストール済みであることを確認してください。 # 4. Docker を使用したインストール リポジトリを任意のローカルディレクトリに Clone/git pull します。 ```sh git clone https://github.com/grongierisc/interpeorability-embedded-python ``` このディレクトリでターミナルを開き、以下を実行します。 ```sh docker-compose build ``` プロジェクトで IRIS コンテナを実行します。 ```sh docker-compose up -d ``` # 5. Docker を使用しないインストール ローカルの IRIS インスタンスに *grongier_pex-1.0.0-py3-none-any.whl* をインストールします。 ```sh /usr/irissys/bin/irispython -m pip install grongier_pex-1.0.0-py3-none-any.whl ``` 次に、ObjectScript クラスを読み込みます。 ```ObjectScript do $System.OBJ.LoadDir("/opt/irisapp/src","cubk","*.cls",1) ``` # 6. サンプルの実行方法 [Production](http://localhost:52795/csp/irisapp/EnsPortal.ProductionConfig.zen?PRODUCTION=PEX.Production) を開いて起動します。 コードサンプルの実行が開始します。 # 7. リポジトリの内容 ## 7.1. Dockerfile 便宜上、コンテナに Python の依存関係(pip、venv)と sudo をインストールする dockerfile です。 インストールすると、dev ディレクトリを作成して、この git リポジトリをそれにコピーします。 これは、IRIS を起動して Titanics cvs ファイルをインポートし、**Python Shell** 用の **%Service_CallIn** を有効にします。 関連する docker-compose.yml を使用すると、ポート番号やキーのマッピング場所、ホストフォルダなどの追加パラメーターを簡単にセットアップできます。 この dockerfile は、Python モジュールの要件をインストールして終了します。 最後に実行されるのは、Jupyter ノートブックとそのカーネルのインストールです。 .env/ ファイルを使用して、docker-compose で使用される dockerfile を調整してください。 ## 7.2. .vscode/settings.json [VSCode ObjectScript プラグイン](https://marketplace.visualstudio.com/items?itemName=daimor.vscode-objectscript)を使って、VSCode で直ちにコーディングできるようにするための設定ファイルです。 ## 7.3. .vscode/launch.json VSCode ObjectScript でデバッグする場合の構成ファイルです。 [この記事に使用されるすべてのファイルについてお読みください。](https://community.intersystems.com/post/dockerfile-and-friends-or-how-run-and-collaborate-objectscript-projects-intersystems-iris) ## 7.4. .vscode/extensions.json コンテナで VSCode を使って実行する場合に、拡張機能を追加する推奨ファイルです。 [詳細情報はこちらをご覧ください。](https://code.visualstudio.com/docs/remote/containers) ![アーキテクチャ](https://code.visualstudio.com/assets/docs/remote/containers/architecture-containers.png) これは、組み込み Python を使って作業する場合に非常に役立ちます。 ## 7.5. src フォルダ ``` src ├── Grongier │ └── PEX // Python コードをラップする ObjectScript クラス │ ├── BusinessOperation.cls │ ├── BusinessProcess.cls │ ├── BusinessService.cls │ ├── Common.cls │ ├── Director.cls │ ├── InboundAdapter.cls │ ├── Message.cls │ ├── OutboundAdapter.cls │ ├── Python.cls │ ├── Test.cls │ └── Utils.cls ├── PEX // ラップされたクラスの例 │ ├── MyBusinessOperationWithAdapter.cls │ ├── MyBusinessOperationWithIrisAdapter.cls │ ├── MyBusinessOperationWithPythonAdapter.cls │ ├── MyBusinessService.cls │ ├── MyOutboundAdapter.cls │ └── Production.cls └── python ├── demo // このデモを実行するための実際の Python コード │ ├── MyBusinessOperation.py │ ├── MyBusinessOperationWithAdapter.py │ ├── MyBusinessOperationWithIrisAdapter.py │ ├── MyBusinessProcess.py │ ├── MyBusinessService.py │ ├── MyCombinedBusinessOperation.py │ ├── MyCombinedBusinessProcess.py │ ├── MyCombinedBusinessService.py │ ├── MyInboundAdapter.py │ ├── MyLoggingOperation.py │ ├── MyNonPollingStarter.py │ ├── MyOutboundAdapter.py │ ├── MyRequest.py │ ├── MyResponse.py │ ├── MySyncBusinessProcess.py │ └── SimpleObject.py ├── dist // Python の相互運用コンポーネントを実装するために使用する Wheel │ └── grongier_pex-1.0.0-py3-none-any.whl ├── grongier │ └── pex // 相互運用コンポーネントを実装するためのヘルパークラス │ ├── _BusinessHost.py │ ├── _BusinessOperation.py │ ├── _BusinessProcess.py │ ├── _BusinessService.py │ ├── _Common.py │ ├── _Director.py │ ├── _InboundAdapter.py │ ├── _Message.py │ ├── _OutboundAdapter.py │ └── __init__.py └── setup.py // Wheel をビルドするためのセットアップ ``` # 8. 新しいコンポーネントの追加方法 ## 8.1. InboundAdapter Python で InboundAdapter を実装するには、以下を実行します。 Python で grongier.pex.InboundAdapter からサブクラス化します。 OnTask() メソッドをオーバーライドします。 ## 8.2. OutboundAdapter Python で OutboundAdapter を実装するには、以下を実行します。 Python で grongier.pex.OutboundAdapter からサブクラス化します。 必要なアクションメソッドを実装します。 ## 8.3. BusinessService Python で BusinessService を実装するには、以下を実行します。 Python で grongier.pex.BusinessService からサブクラス化します。 OnProcessInput() メソッドをオーバーライドします。 ## 8.4. BusinessProcess Python で BusinessProcess を実装するには、以下を実行します。 Python で grongier.pex.BusinessProcess からサブクラス化します。 OnRequest()、OnResponse()、および OnComplete() メソッドをオーバーライドします。 ## 8.5. BusinessOperation Python で BusinessOperation を実装するには、以下を実行します。 Python で grongier.pex.BusinessOperation からサブクラス化します。 OnMessage() メソッドをオーバーライドします。 ## 8.6. コンポーネントの登録 組み込み Python シェルを起動します。 ```sh /usr/irissys/bin/irispython ``` 次に、このクラスメソッドを使用して、新しい py ファイルを相互運用のためのコンポーネントリストに追加します。 ```python iris.cls("Grongier.PEX.Utils").RegisterComponent(,,,,) ``` 例: ```python iris.cls("Grongier.PEX.Utils").RegisterComponent("MyCombinedBusinessOperation","MyCombinedBusinessOperation","/irisdev/app/src/python/demo/",1,"PEX.MyCombinedBusinessOperation") ``` ## 8.7. Grongier.PEX の直接利用 RegisterComponent ユーティリティを使用しない場合は、 Grongier.PEX.Business* コンポーネントを追加して、そのプロパティを構成できます。 * %module: * Python コードのモジュール名 * %classname: * コンポーネントのクラス名 * %classpaths: * コンポーネントのあるパス * これは、PYTHON_PATH のほかに必要な 1 つまたは複数のクラスパスである場合があります(複数の場合は '|'(パイプ)区切り)。 例: # 9. 今後の取り組み - Service と Operation のみがテスト済みです。 - Adapter は作業中です。 # 10. クレジット このコードの大部分は、Mo Cheng と Summer Gerry による Python 用 PEX を使用しています。 登録部分は、IRIS 2021.3 の未公開機能を使用しています。
お知らせ
Mihoko Iijima · 2022年7月12日

★投票開始!★InterSystems Full Stack コンテスト 2022

開発者の皆さん、こんにちは! InterSystems Full Stack コンテスト 2022 の投票が始まりました! 🔥 ベストアプリケーションだ! 🔥と思う作品に投票をお願いします! 投票方法は以下ご参照ください。 Experts nomination: インターシステムズの経験豊富な審査員がベストアプリを選び、Expert Nominationで賞品をノミネートします。 ⭐️ @Andreas.Dieckow, Principal Product Manager⭐️ @Benjamin.DeBoe, Product Manager⭐️ @Robert.Kuszewski, Product Manager⭐️ @Raj.Singh5479, Product Manager⭐️ @Alexander.Koblov, Support Specialist⭐️ @Daniel.Kutac, Senior Sales Engineer⭐️ @Guillaume.Rongier7183, Sales Engineer⭐️ @Steve.Pisani, Senior Solution Architect⭐️ @Eduard.Lebedyuk, Senior Cloud Engineer⭐️ @Alexander.Woodhead, Technical Specialist⭐️ @Timothy.Leavitt, Development Manager ⭐️ @Jeffrey.Fried, Director of Product Management⭐️ @Evgeny.Shvarov, Developer Ecosystem Manager Community nomination: 開発者コミュニティのメンバーは、お好みのアプリケーションに対して1位~3位を指定しながら投票できます。 開発者コミュニティでのあなたの状態 順位 1位 2位 3位 開発者コミュニティに記事を掲載したり、OpenExchange(OEX)にアプリをアップロードしたことがある方 9点 6点 3点 開発者コミュニティに1つの記事を掲載した、または 1アプリケーションを OEX にアップロードしたことがある方 6点 4点 2点 開発者コミュニティへコメントや質問を投稿したことがある方 3点 2点 1点 エキスパートレベル 順位 1位 2位 3位 グローバルマスターズの VIP レベル または、InterSystems Product Managers 15点 10点 5点 グローバルマスターズの Ambassador レベル 12点 8点 4点 グローバルマスターズの Expert レベル または DC モデレーター 9点 6点 3点 グローバルマスターズの Specialist レベル 6点 4点 2点 グローバルマスターズの Advocate レベル または インターシステムズの従業員 3点 2点 1点 今回も「ブラインド投票」とします。 各応募作品への投票数は、誰にも分らないようになっています。1日1回、この記事のコメント欄に投票数を公開する予定です。 コンテストページ の表示順は、コンテストに応募した時期が早ければ早いほど、上位に表示されます。 メモ:新しいコメントの通知を受けるために、この投稿を購読することをお忘れなく!(記事末尾の ベルのアイコンをクリックするだけ!) 投票に参加するには Open Exchange へのサインインします(開発者コミュニティのアカウントを使用してください)。 投票ボタンは、開発者コミュニティ内で、質問/回答/記事の掲載/投稿に対するコメント など 記載いただいた方に対して有効になります。 ボタンが押せない場合は、コミュニティへのコメントやオリジナルの記事など、書き込みお願いします!詳細は、こちらの記事をご参照ください。 気が変わった場合は? - 選択をキャンセルして別のアプリケーションに投票できます。 ぜひ 🔥これだ🔥 と思う作品に投票お願いします! メモ:コンテストへ応募された作品は、投票週間中にバグを修正したり、アプリケーションを改良したりすることができますので、アプリケーションのリリースを見逃さずに購読してください。
お知らせ
Toshihiko Minamoto · 2023年1月4日

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

InterSystemsコンテナレジストリ Webユーザインターフェースのお知らせ InterSystemsはこの度、InterSystems コンテナレジストリ (ICR) Web ユーザインターフェースをリリースしました。このツールはICR上に多くあるコンテナイメージを見つけやすく、使いやすくできるようデザインされたものです。 InterSystems コンテナレジストリUIは以下のサイトです。 https://containers.intersystems.com/contents コミュニティエディションコンテナ When you visit the ICR ユーザインターフェース,を訪問すると、コミュニティエディションといったパブリックに利用可能なコンテナにアクセスできます。画面左のナビゲーションで必要なプロダクトファミリを選択し、コンテナを選択、最終的に特定のバージョンを指定します。 エンタープライズエディションコンテナ IRISエンタープライズエディションといったプライベートコンテナを観るにはログインボタンをクリックしてください。一度ログインいただくと、画面左のナビゲーションにはアクセスできるすべてのコンテナが表示されます。 ぜひ、ご利用ください!
記事
Mihoko Iijima · 2020年7月6日

%InstallerでInterSystems Cachéにアプリケーションをデプロイする

InterSystemsのテクノロジースタックを使用して独自のアプリを開発し、顧客側で複数のデプロイを実行したいとします。 開発プロセスでは、クラスをインポートするだけでなく、必要に応じて環境を微調整する必要があるため、アプリケーションの詳細なインストールガイドを作成しました。この特定のタスクに対処するために、インターシステムズは、%Installer(Caché/Ensemble)という特別なツールを作成しました 。 続きを読んでその使用方法を学んでください。 %Installer このツールを使用すると、インストール手順ではなく、目的のCaché構成を記述するインストールマニフェストを定義できます。作成したい Caché 構成を記述します。必要な内容を記述するだけで、環境を変更するために必要なコードが自動的に生成されます。したがって、マニフェストのみを配布する必要がありますが、インストール・コードはすべてコンパイル時に特定の Caché サーバ用に生成されます。 マニフェストを定義するには、ターゲット構成の詳細な説明を含む新しいXDataブロックを作成してから、このXDataブロックのCaché ObjectScriptコードを生成するメソッドを実装します(このコードは常に同じです)。 マニフェストの準備ができたら、ターミナルまたはCaché ObjectScriptコードから、またはCachéのインストール中に自動的にアクセスできます。 マニフェストは %SYSネームスペースで実行する必要があります。 マニフェストは、システムパラメータ(スーパーサーバポート、OS、mgrディレクトリなど)とユーザーが提供した任意のパラメータの両方を処理できます。 一般に、各インストールクラスは次の要件を満たしている必要があります。 %occInclude.incへのリンクを含むこと Cachéサーバー構成のXDataブロックを含むこと ブロックには任意の有効な名前を付けること スタジオでブロックの名前の後に[XMLNamespace = INSTALLER]を追加すること ルートアイテム(1つのみである必要があります)は<Manifest>と呼ばれ、他のすべてのアイテムを含むように記述すること また、XDataブロックに必要なプログラムコードを生成するsetup()メソッドを実装すること インストーラーの基本 複数の方法でインストールマニフェストを実行できます。 ターミナルを使用して%SYSネームスペースで、またはCachéObjectScriptコードから以下実行します。 do ##class(MyPackage.MyInstaller).setup() Cachéのインストール中に自動的に実行されます。 これを行うには、インストーラーのクラスを、Cachéインストールパッケージ(すなわち、 setup_cache.exeまたはcinstallが格納されている場所)のフォルダー内に格納されているDefaultInstallerClass.xmlにエクスポートする必要があります。 このクラスは、Cachéのインストール中に%SYSネームスペースにインポートされ、 setup() メソッドを介して実行されます。 例: 簡単な例を考えてみましょう。ユーザー定義の名前で新しいネームスペースを作成し、デフォルトのWebアプリを作成し、作成したネームスペースにコードをインポートするインストーラーを含む App.Installerというクラスを作成します。 /// You can see generated method in zsetup+1^App.Installer.1XData Install [ XMLNamespace = INSTALLER ]{<Manifest> <If Condition='(##class(Config.Namespaces).Exists("${Namespace}")=0)'> <Log Text="Creating namespace ${Namespace}" Level="0"/> <Namespace Name="${Namespace}" Create="yes" Code="${Namespace}" Ensemble="0" Data="${Namespace}"> <Configuration> <Database Name="${Namespace}" Dir="${MGRDIR}${Namespace}" Create="yes"/> </Configuration> </Namespace> <Log Text="End Creating namespace ${Namespace}" Level="0"/> </If> <Role Name="AppRole" Description="Role to access and use the App" Resources="%DB_CACHESYS:RW,%Admin_Secure:U" /> <Namespace Name="${Namespace}" Create="no"> <CSPApplication Url="/csp/${Namespace}" Directory="${CSPDIR}${Namespace}" AuthenticationMethods="64" IsNamespaceDefault="true" Grant="AppRole" /> <IfDef Var="SourceDir"> <Log Text="SourceDir defined - offline install from ${SourceDir}" Level="0"/> <Import File="${SourceDir}"/> </IfDef> </Namespace></Manifest>} ///Entry point method, you need to call/// At class compile time it generate Caché ObjectScript code from the manifest/// After that you can run this installer from a terminal:/// Set pVars("Namespace")="NewNamespace"/// Set pVars("SourceDir")="C:\temp\distr\"/// Do ##class(App.Installer).setup(.pVars)ClassMethod setup(ByRef pVars, pLogLevel As %Integer = 0, pInstaller As %Installer.Installer) As %Status [ CodeMode = objectgenerator, Internal ]{ Quit ##class(%Installer.Manifest).%Generate(%compiledclass, %code, "Install")}} この例では、インストーラーは次のアクションを実行します。 Namespace変数の値と同じ名前のネームスペースが存在するかどうかを確認します(明確にするために、Namespace変数がNewNamespaceに設定されていることを指定しましょう) そうでなければ、NewNamespaceという新しいネームスペースが作成されることをログに記録します。 新しいネームスペースを定義します。 名前はNewNamespaceです 新しいネームスペースを作成します ルーチンデータベースはNewNamespaceです Ensembleを有効にしないでください ルーチンデータベースはNewNamespaceです 新しいデータベースを作成します 名前はNewNamespaceです; それを mgr/NewNamespaceフォルダーに作成します(MGRDIR変数はデフォルトで使用可能であることに注意してください) ネームスペースの作成が完了し、ログに記録されます。 新しいロールを次のように作成します。 AppRole(リソース %DB_CACHESYS:RW および %Admin_Secure:U を設定) デフォルトのWebアプリケーション /csp/NewNamespace が作成されます(Grant 属性により、AppRole が設定されます) SourceDir変数が定義されている場合、そこからすべてのファイルをNewNamespaceにインポートします。 このインストーラーをターミナルで実行するには、次のコマンドを実行します。 Set pVars("Namespace")="NewNamespace" Set pVars("SourceDir")="C:\temp\distr\" Do ##class(App.Installer).setup(.pVars) 実行中、ターミナルは次の関連情報を表示します。 2016-02-17 19:26:17 0 App.Installer: Installation starting at 2016-02-17 19:26:17, LogLevel=02016-02-17 19:26:17 0 : Creating namespace NewNamespace2016-02-17 19:26:17 0 : End Creating namespace NewNamespace2016-02-17 19:26:17 0 : SourceDir defined - offline install from C:\temp\distr\2016-02-17 19:26:18 0 App.Installer: Installation succeeded at 2016-02-17 19:26:182016-02-17 19:26:18 0 %Installer: Elapsed time .545148s 発生していることについて多くの情報を取得するためには、LogLevelを指定します(0(デフォルト)から3(未加工)、数値が大きければ大きいほどより詳細な情報が得られます)。 Do ##class(App.Installer).setup(.pVars, 3) 次に、インストーラマニフェストで実行できることについて説明します。 利用可能なノード マニフェストは次のアイテムで構成されています。 ノード 親ノード 属性(デフォルト値) 説明 Arg Invoke、Error Value – 引数の値 InvokeまたはError経由で呼び出されるたメソッドに引数を渡します ClassMapping Configuration Package –マッピングされるパッケージFrom –マッピングに使用されるソースデータベースの名前 データベースからこの構成項目を含むネームスペースへのクラスマッピングを作成します。 Compile Namespace Class –コンパイルするクラスの名Flags –コンパイルフラグ(ck)IgnoreErrors –エラーを無視(0) コンパイラクラス。 $System.OBJ.Compile(Class, Flags)を呼び出す Configuration Namespace ネームスペースとデータベースの作成に使用されます。 タグを閉じるとマッピングがアクティブになり、CPFファイルを更新します。 CopyClass Namespace Src — ソースクラスTarget — ターゲットクラスReplace —ソースクラスを削除(0) ソースクラス定義をターゲット定義にコピーまたは移動します。 CopyDir Manifest Src —ソースディレクトリTarget —ターゲットディレクトリIgnoreErrors —エラーを無視(0) ディレクトリをコピーします。 CopyFile Manifest Src —ソースファイルTarget —ターゲットファイルIgnoreErrors —エラーを無視(0) ファイルをコピーします。 Credential Production Name–アクセス認証情報の名前Username–ユーザー名Password–ユーザーパスワードOverwrite –アカウントが既に存在する場合は上書き アクセス資格情報を作成または上書きします。 CSPApplication Namespace AuthenticationMethods –有効な認証方法AutoCompile –自動コンパイル(CSP設定)CSPZENEnabled – CSP / ZENフラグChangePasswordPage –パスワードページを変更するパスCookiePath –セッションCookieパスCustomErrorPage – カスタムエラーページへのパスDefaultSuperclass –デフォルトスーパークラスDefaultTimeout –セッションタイムアウトDescription–説明[文字列の折り返しの区切り]Directory – CSPファイルへのパスEventClass –イベントクラス名Grant – システムへのログイン時に割り当てられたロールのリストGroupById – IdプロパティによるグループInboundWebServicesEnabled – 受信WebサービスフラグIsNamespaceDefault – 名前空間デフォルトアプリケーションフラグLockCSPName – CSP名のロックフラグLoginClass –ログインページへのパスPackageName –パッケージ名プロパティPermittedClasses –許可されたクラスプロパティRecurse –再帰フラグ(サブディレクトリを提供)(0)Resource – Webアプリにアクセスするために必要なリソースServeFiles –サービスファイルプロパティServeFilesTimeout – 静的ファイルをキャッシュする時間(秒単位)。TwoFactorEnabled – 2段階認証Url – Webアプリケーションの名前UseSessionCookie –セッションにCookieを使用する Webアプリケーションを作成または変更します。 詳細については、ドキュメントおよび Security.Applications クラスを参照してください Database Configuration BlockSize – データベースのバイト単位のブロックサイズClusterMountMode – データベースをクラスターの一部としてマウントCollation – 並べ替え順序Create – 新しいデータベースを作成するかどうか(yes / no / overwrite) (はい))Dir –ディレクトリEncrypted – 暗号化データベースEncryptionKeyID – 暗号化キーのIDExpansionSize – MB単位のサイズInitialSize – 初期サイズMaximumSize – 最大サイズMountAtStartup –起動時にマウントMountRequired – 起動時にデータベースを正常にマウントする必要があることを指定します。Name – データベース名PublicPermissions – パブリック権限Resource – リソースStreamLocation –このデータベースに関連付けられたストリームが移動するディレクトリ データベースを作成または変更します。 詳細については、ドキュメント 、 Config.Databases および SYS.Database クラスを参照してください Default Manifest Name –変数名Value –変数値Dir –変数値(これがフォルダー/ファイルへのパスの場合) 変数値を設定します(未設定の場合) Else Manifest, Namespace If文がfalseのときに実行されます。 Error Manifest Status – エラーコードSource – エラーのソース 例外をスローします。 ${}および#{}構文は使用できないことに注意してください。       ForEach Manifest Index – 変数名Values – 変数の値のリスト コレクション制御 ループ GlobalMapping Configuration Global – グローバル名From – マッピングするデータベースの名前 Collation – 並べ替えの順序 (Caché 標準) グローバルをマッピングします。 If Manifest, Namespace Condition – 条件付きステートメント 条件付きif文 IfDef Manifest, Namespace Var – 変数名 変数がすでに設定されている場合に使用される条件付きif文 IfNotDef Manifest, Namespace Var – 変数名 変数がすでに設定されていない場合に使用される条件付きif文 Import Namespace File – インポート用のファイル/フォルダーFlags — コンパイルフラグ(ck)IgnoreErrors —エラーを無視(0)Recurse – 再帰的にインポート(0) ファイルをインポートします。 次を呼び出します。[文字列の折り返しの区切り]$System.OBJ.ImportDir(File,,Flags,,Recurse) and $System.OBJ.Load(File, Flags) Invoke Namespace Class – クラス名Method –メソッド名CheckStatus –返されたステータスを確認Return – 結果を変数に書き込む さまざまな引数を指定してクラスのメソッドの呼び出し、実行結果を返します LoadPage Namespace Name – CSPページへのパスDir – CSPページのあるフォルダーFlags — コンパイルフラグ(ck)IgnoreErrors — エラーを無視 (0) $System.CSP.LoadPage(Name, Flags)と$System.CSP.LoadPageDir(Dir, Flags)を使ってCSP fileを読み込みます。 Log Manifest Level – 0(最小)から3(詳細)までのロギングレベルテキスト – 長さ32,000文字までの文字列 ロギングレベルが「level」属性以上の場合、ログにメッセージを追加します Manifest ルートアイテム。 マニフェストで唯一のルートアイテム。他のすべてのアイテムを含みます。 Namespace Manifest Name – ネームスペースの名前Create – 新しい名前空間を作成するかどうか(はい/いいえ/上書き(はい))Code – プログラムコードのデータベースData – データベースEnsemble – ネームスペースに対してEnsembleを有効化他のすべての属性はEnsemble Webアプリケーションに適用可能 インストーラーのスコープを定義します。 Production Namespace Name – プロダクション名[AutoStart –プロダクションの自動起動 Ensembleプロダクションを構成します。 Resource Manifest Name – リソース名Description –リソースの説明Permission – パブリック権限 リソースを作成または変更します。 Role Manifest Name – 役割の名前Description – 役割の説明(カンマを含めることはできません)Resources – 役割に与えられるリソース。「MyResource:RW,MyResource1:RWU」として表されます RolesGranted – 対応するロールを付与するかどうか 新しいロールを作成します。 RoutineMapping Configuration Routines – ルーチン名Type – ルーチンタイプ(MAC、INT、INC、OBJまたはALL)From – ソースデータベース ルーチンの新しいマッピングを作成します。 Setting Production Item – 構成可能な項目[文字列の折り返しの区切り]Target – パラメータタイプ:項目、ホスト、アダプタ[文字列の折り返しの区切り]Setting – パラメータ名[文字列の折り返しの区切り]Value – パラメータ値 Ensembleプロダクションの項目を構成します Ens.Production:ApplySettings メソッドを呼び出します SystemSetting Manifest Name – 構成パッケージのclass.propertyValue – 属性値 Configパッケージの属性値を設定します(Modifyメソッドを使用)。 User Manifest Username – ユーザー名PasswordVar –パスワードを含む変数Roles – ユーザーの役割のリストFullname – フルネームNamespace – 開始ネームスペースRoutine – 開始ルーチンExpirationDate –ユーザーが非アクティブになる日付ChangePassword –システムに次回ログインしたときにパスワードを変更するEnabled – ユーザーがアクティブかどうか ユーザーを作成または変更します。 Var Manifest Name – 変数名Value – 変数値 変数に値を割り当てます。 変数 ユーザー提供の変数 属性によっては、マニフェストの実行時に展開される式(文字列)を含めることができます。 次のように、展開できる式には3つのタイプがあります。 ${<Variable_name>} – マニフェストの実行時に計算される変数(ユーザ定義または環境変数; 下記参照)の値。 ${#<Parameter_name>} –コンパイル時にインストーラーのクラスから指定されたパラメーターの値に置き換えられます。 #{<Cache_ObjectScript_code>} —指定されたCaché ObjectScript文の値は、マニフェストの実行中に処理されます。 必要に応じて引用符を付けてください。 パラメータ値はコンパイル時に定義されるため、変数またはCaché ObjectScript文の一部にすることができます。 変数はCaché ObjectScriptコードの前に解釈されるため、Caché ObjectScript文で使用できます。例:#{$ZCVT("${NAMESPACE}","L")} システム変数 次の変数は常に使用可能です。 変数 説明 サンプル値 SourceDir (インストーラーの実行時にのみ使用可能)インストール(setup_cache.exeまたはcinstall)が実行されるディレクトリ。 /InterSystems/distr/ ISCUpgrade (インストーラーの実行時にのみ使用可能)新規インストールなのか、アップグレードなのかを示します。 この変数は、0(新規インストール)または1(アップグレード)のいずれかです。 0 (インストール)1 (アップグレード) CFGDIR INSTALLDIRを参照。 /InterSystems/Cache/ CFGFILE CPFファイルへのパス /InterSystems/Cache/cache.cpf CFGNAME インスタンスの名前 CACHE CPUCOUNT CPUコアの数 4 CSPDIR CSPディレクトリ /InterSystems/Cache/csp/ HOSTNAME Webサーバーの名前 SCHOOL15 HTTPPORT Webサーバーのポート 80 INSTALLDIR Cachéのインストールディレクトリ /InterSystems/Cache/ MGRDIR マネージャディレクトリ(mgr) /InterSystems/Cache/mgr/ PLATFORM オペレーティングシステム UNIX PORT Cachéスーパーサーバポート 1972 PROCESSOR プラットフォームの名前 x86-64 VERSION Cachéのバージョン 2015.1.1 デバッグ ノード属性の値としてどのような値が割り当てることができるのか理解に苦しむことがあります。これを把握するには、setupメソッドの生成されたintコードを確認してください。 ほとんどの場合、メインコールは %Installer.Installer クラスのオブジェクトである tInstaller<ElementName>に対して行われ、次に、システムメソッドを直接呼び出します。 または、ノード属性がクラスプロパティである %Installer.<ElementName>クラスのコードを確認することもできます。 プログラムコードは、 %OnBeforeGenerateCode、 %OnGenerateCode、 %OnAfterGenerateCode メソッドで生成されます。デバッグのため、インストーラーへの呼び出しをトランザクションにラップすることをお勧めします。 たとえば、 Caché内で行われたすべての変更を簡単に元に戻すためにTSTART/TROLLBACKコマンドを使うこともできます(ただし、新しいデータベースファイルの作成など、外部の変更は元に戻りません)。 最後に、LogLevel を 3 に設定することを忘れないでください。 例: MDX2JSONプロジェクトはインストーラーを提供します 。 プロジェクトをインストールするには、MDX2JSON.Installer クラスを含むinstaller.xmlファイルを任意のネームスペースにインポートします。管理ポータルから、またはファイルをスタジオにドラッグ&ドロップすることによってインポートを実行できます。次に、ターミナルで次のコマンドを実行します。 do ##class(MDX2JSON.Installer).setup() その結果、CachéはGitHubリポジトリからアプリケーションファイルをロードし、デフォルトの MDX2JSON ネームスペース /MDX2JSON データベースにインストールを実行し、MDX2SJONパッケージを %AllとSAMPLESにマップし、MDX2SJONグローバルを %Allにマップし、SAMPLESネームスペースは /MDX2JSON で定義されるRESTアプリケーションを作成します。 これらの手順はすべてターミナルで確認できます。 MDX2JSONインストーラーの詳細については、プロジェクトのreadmeを参照してください 。 追加の例 ドキュメントからの例 Samplesネームスペースの Sample.InstallerクラスCacheGitHubCIプロジェクトは、インストーラーを提供します 。SYSMONダッシュボードプロジェクトは、インストーラーを提供します 。DeepSee監査プロジェクトは、インストーラーを提供します 。 概要 %Installerは、InterSystems Caché および Ensemble に基づいてアプリケーションを配布およびデプロイするための便利なツールです。 参考: ドキュメント
記事
Tomohiro Iwamoto · 2020年8月28日

AWS CloudWatchを使用したInterSystems IRISのモニタリング

本記事について InterSystems IRISをモニタリングする方法はいくつかあります。 SNMP システムモニターとemail通知機能 管理ポータルのシステムダッシュボード Prometheus+Grafanaを使用 InterSystems SAM (System Alerting and Monitoring) 本記事では上記に加えてAWSにIRISをデプロイする場合に自然な選択子となりうる方法として、CloudWatchを使用する方法をご紹介します。 AWSネイティブの各種サービスとIRISを連携させる方法の典型のご紹介を兼ねています。 内容は、Open Exchangeで公開されています。日本語のREADMEがありますのでそちらをご覧ください。README.MDからの引用 InterSystems IRISの各種メトリクスとログをAWS CloudWatchに簡単に公開することができます。これらメトリクスとログがあれば、IRISのデータをダッシュボードやアラートなどに統合することができます。 Prometheus+Grafana,SAM,CloudWatchについては、共通点があります。いずれもIRIS 2019.4から利用可能となった監視APIを使用している点です。下記のREST要求を出すだけで、任意のIRISホストの各種メトリクスの取得が出来ます。これにより多種多様なモニタリングツールやサービスとの連携が容易になりました。 $ curl http://localhost:52773/api/monitor/metrics iris_cpu_pct{id="CSPDMN"} 0 iris_cpu_pct{id="CSPSRV"} 0 iris_cpu_pct{id="ECPWorker"} 0 iris_cpu_pct{id="GARCOL"} 0 iris_cpu_pct{id="JRNDMN"} 0 iris_cpu_pct{id="LICENSESRV"} 0 iris_cpu_pct{id="WDSLAVE"} 0 iris_cpu_pct{id="WRTDMN"} 0 iris_cpu_usage 3 iris_csp_activity{id="127.0.0.1:52773"} 31 iris_csp_actual_connections{id="127.0.0.1:52773"} 8 iris_csp_gateway_latency{id="127.0.0.1:52773"} .551 ・ ・ ・ 詳細はREADME.MDを読んでください、以上です、というのでは拍子抜けしそうですので、以下、追加情報です。 ログインサイトについて message.logの分析は、画像でも確認できますが、ログインサイトを使って、ロググループInterSystems-IRISに対して下記のクエリを実行します。 PARSE @message "* (*) * [*] *" as timestamp,pId,severity,eventType,text | filter severity=3 or severity=2 | sort @timestamp CloudFormationのテンプレート オリジナルで紹介されている手順及びIRISを自動でデプロイするCloudFormationのテンプレートをご用意しました。パラメータの意味はこちらの記事とほぼ同じです。 パラメータIamInstanceProfileParameterで指定するEC2インスタンスロールには、CloudWatchAgentServerPolicyに加えてAmazonS3ReadOnlyAccessも追加してください。 実行すると、ポート22(ssh), 52773をインターネットに解放します。安全を見るなら、パラメータRemoteAccessCIDRParameterには自分のグローバルIPを指定するのが望ましいです。キット及びライセンスキーは、パラメータS3BucketNameParameterで指定したs3バケットから取得しています。事前に用意したキット、ライセンスの保管場所が下記である場合、このパラメータ値はmybucketにします。 s3://mybucket/IRIS-2020.1.0.215.0-lnxrhx64.tar.gz s3://mybucket/iris.key 実行されるシェルコマンド UserDataセクションに一通りのコマンドが記述されています。また、オリジナルの内容に加えて、各種設定(AWS Region, timezone, localeなど)を日本の環境に合わせています。 こんな風に、AWSが持つ様々なサービスとIRISを連携させられるのね、と感じていただければ幸いです。 なお、Amazon Linux2はIRISの正式なサポート対象環境ではありませんが、RedHat7ベースですのでデモ目的で使用しています。
記事
Toshihiko Minamoto · 2021年1月6日

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 つ作成し、それを実行します。そして 職場でボーナスをゲットします。 次第に、[マイクロサービス](https://martinfowler.com/articles/microservices.html)の時代に Docker を使わないのはもったいない、InterSystems がその[ドキュメンテーション](https://docs.intersystems.com/irislatestj/csp/docbook/DocBook.UI.Page.cls?KEY=ADOCK_iris)を提供してくれることを考えるとなおさらだ、という結論に至ります。 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 irisUSER>zpmzpm: USER>install samples-bi   ブラウザーを http://localhost:52773/csp/user/_DeepSee.UserPortal.Home.zen?$NAMESPACE=USER, に変更したら、もう一度上司の所に戻り、良い仕事のご褒美として1 日休みをもらいます。 あなたはその時、“docker run” は単なる第一歩であり、少なくとも docker-compose を使う必要があるでは?と考え始めます。 問題ありません: $ cat docker-compose.ymlversion: "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](https://kompose.io/) を使うという方法があります。 私個人的には、Kubernetes のマニフェストファイルをマニュアルからコピーし、自分で編集する方が好きなのですが、kompose でも小さなタスクを完了させるだけなら問題ありません。 $ kompose convert -f docker-compose.ymlINFO Kubernetes file "irisce-service.yaml" createdINFO Kubernetes file "irisce-deployment.yaml" created   これで、Kubernetes のクラスターに送信できるデプロイファイルとサービスファイルができました。 ここであなたは、minikube をインストールすれば、シングルノードの Kubernetes クラスターを実行できること、そしてこの段階ではまさにそれが必要なことを知ります。 minikube のサンドボックスを 1 日か 2 日使ってみた後、ライブの Kubernetes を実際に AWS クラウドのどこかでデプロイする準備が整いました。   セットアップ それでは、一緒にやりましょう。 この時点で、前提にしておきたい点がいくつかあります。 第一に、あなたが AWS のアカウントを持っていること、[その ID を知っている](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html)こと、そしてルートユーザーの認証情報を使用していないということです。 [管理者権限](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html)とプログラムによるアクセス権だけを持つ IAM ユーザー (「my-user」とでも呼びましょう) を作成し、その認証情報を保管します。 また、「terraform」と名付けた IAM ユーザーも作成し、同じアクセス権を与えます。 ![](/sites/default/files/inline/images/images/iam_user.png) このユーザーの代わりに、Terraform はあなたの AWS アカウントにアクセスし、必要なリソースを作成、削除します。 これはデモなので、これらのユーザーに広範な権限を与えています。 両方の IAM ユーザーの認証情報はローカルに保存します。 $ cat ~/.aws/credentials[terraform]aws_access_key_id = ABCDEFGHIJKLMNOPQRSTaws_secret_access_key = ABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123[my-user]aws_access_key_id = TSRQPONMLKJIHGFEDCBAaws_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 コンソールでお試しください。 ![](/sites/default/files/inline/images/images/eks.png)   飽きてしまったらクリーンアップしましょう。 $ terraform destroy   そして、次のレベルに移動し、Terraform EKS モジュールの使用を開始します。これは、同じ EKS Introduction がベースになっているためでもあります。 その使い方は、「examples/」ディレクトリで確認してください。 そこには、他の例も用意してあります。 例はある程度簡素化してあります。 こちらが、VPC の作成モジュールと EKS の作成モジュールが呼び出されるメインファイルです。 $ cat /terraform/main.tfterraform {  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-bucketAn 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-rememberAn 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-1make_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   ![](/sites/default/files/inline/images/images/dynamodb.png)   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.tfvariable "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.tfoutput "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.ymlversion: "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.yamlapiVersion: extensions/v1beta1kind: Deploymentmetadata:  labels:    io.kompose.service: samples-bi  name: samples-bispec:  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.yamlapiVersion: v1kind: Servicemetadata:  labels:    io.kompose.service: samples-bi  name: samples-bispec:  ports:  - name: "52773"    port: 52773    targetPort: 52773  selector:    io.kompose.service: samples-bi  type: LoadBalancer   そうです、今回は「デフォルト」のネームスペースでデプロイします。デモですからね。 _何_を_どこ_で実行するかが分かったところで、 最後は、_どのように_実行するか、を見ます。   GitHub Actions のワークフロー すべてを一から作るのではなく、[GitHub Actions を使って GKE に InterSystems IRIS Solution をデプロイする](https://jp.community.intersystems.com/node/483556) に記載されているワークフローに似たものを作成します。 今回は、コンテナを構築する必要はありません。 GKE 特有の箇所は EKS 特有の箇所に置き換えられます。 太文字の箇所は、コミットメッセージを受けて条件付きステップで使用することに関する記述です。 $ cat /.github/workflows/workflow.yamlname: 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 がそのシークレットを使用することを許可する必要があります。 ![](/sites/default/files/inline/images/images/secrets.png)   ワークフローの強調表示されている箇所に注目してください。 これらは、“[destroy eks]” というフレーズを持つコミットメッセージをプッシュし、EKS クラスターを破壊することを可能にします。 私たちはそのようなコミットメッセージを持つ “kubernetes apply” は実行しません。 パイプラインを実行します。でも最初に .gitignore ファイルを作成します。 $ cat /.gitignore.DS_Storeterraform/.terraform/terraform/*.planterraform/*.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-contextdev-cluster $ kubectl get nodesNAME                                                                               STATUS   ROLES      AGE          VERSIONip-10-42-1-125.eu-west-1.compute.internal   Ready          6m20s     v1.14.8-eks-b8860f $ kubectl get poNAME                                                       READY        STATUS      RESTARTS   AGEsamples-bi-756dddffdb-zd9nw    1/1               Running    0                      6m16s $ kubectl get svcNAME                   TYPE                        CLUSTER-IP        EXTERNAL-IP                                                                                                                                                         PORT(S)                    AGEkubernetes        ClusterIP               172.20.0.1                                                                                                                                                                                443/TCP                    11msamples-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](http://a2c6f6733557511eab3c302618b2fae2-622862917.eu-west-1.elb.amazonaws.com:52773/csp/user/_DeepSee.UserPortal.Home.zen?%24NAMESPACE=USER) _(リンクを自分の External-IP と入れ替えてください) に移動し、“_system”、“SYS” と順に入力して、デフォルトのパスワードを変更します。 たくさんの BI ダッシュボードが表示されるはずです。 ![](/sites/default/files/inline/images/images/deepsee_ui.png)   細かく確認するには、それぞれの矢印をクリックします。 ![](/sites/default/files/inline/images/images/deepsee_2.png)   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 の有効化については触れていません。 それは、また近いうちに取り上げたいと思います。
記事
Shintaro Kaminaka · 2020年12月10日

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

[以前](https://jp.community.intersystems.com/node/482356)紹介した記事 (お読みいただいたでしょうか) では、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 には[無料のティア](https://cloud.google.com/free/)がありますが、Google クラウドプラットフォームは有料ですのでご注意ください。 [経費の管理](https://cloud.google.com/billing/docs/)にはお気を付けください。   ワークフローの基本 それでは、始めましょう。  以下はシンプルですが使いものにならないワークフローの例です。 $ cd <root_repo_dir>$ mkdir -p .github/workflows$ cat <root_repo_dir>/.github/workflows/workflow.yaml          name: Traditional Hello Worldon: [push]jobs:  courtesy:    name: Greeting    runs-on: ubuntu-latest    steps:    - name: Hello world      run: echo "Hello, world!   リポジトリにプッシュするときは、「Greeting」と名付けたジョブを実行する必要があります。このジョブは唯一のステップとしてウェルカムフレーズを出力します。 このジョブは、GitHub でホストされる仮想マシン「Runner」で実行されます。同マシンには Ubuntu の最新バージョンがインストールされています。 このファイルをリポジトリにプッシュした後に「Code GitHub」タブを開けば、すべて順調に実行されたことを確認できるはずです。 ![](/sites/default/files/inline/images/images/simple_workflow_result.png)   ジョブが失敗したら、緑のチェックマークの代わりに赤の「X」が表示されます。 詳細を見るには、緑のチェックマークと「Details」を順にクリックします。 もしくは、直接「Actions」タブに移動することもできます。 ![](/sites/default/files/inline/images/images/actions_tab.png)   ワークフローの構文に関する完全な詳細は、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’ branchon:  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'   kubernetes-deploy:    name: Kubernetes マニフェストを GKE クラスタにデプロイする    needs:    - gcloud-setup-and-build-and-publish-to-GCR    - gke-provisioner    runs-on: ubuntu-18.04    steps:    - name: チェックアウト      uses: actions/checkout@v2     - 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 nodesNAME                                                                                                   STATUS ROLES   AGE        VERSIONgke-dev-cluster-dev-cluster-node-pool-98cef283-dfq2 Ready    <none> 8m51s   v1.13.11-gke.23 $ kubectl -n iris get poNAME                     READY   STATUS     RESTARTS   AGEzpm-registry-0   1/1         Running    0                      8m25s   他の内容の確認は、Running ステータスになるまで待機することをおすすめします。 $ kubectl -n iris get stsNAME                 READY   AGEzpm-registry   1/1          8m25s   $ kubectl -n iris get svcNAME                 TYPE                      CLUSTER-IP       EXTERNAL-IP    PORT(S)                       AGEzpm-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 irisUSER>write ##class(Math.Math).Factorial(5)<CLASS DOES NOT EXIST> *Math.MathUSER>zpmzpm: USER>listzpm: USER>repo -listregistry    Source:     https://pm.community.intersystems.com    Enabled?    Yes    Available?    Yes    Use for Snapshots?    Yes    Use for Prereleases?    Yeszpm: USER>repo -n registry -r -url http://104.199.6.32:52773/registry/ -user _system -pass SYSzpm: 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 registryobjectscript-math 0.0.4zpm: USER>install objectscript-math[objectscript-math]    Reload START...[objectscript-math]    Activate SUCCESS zpm: USER>quitUSER>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 はどうすれば再実行できるか?) という質問をご覧ください。
お知らせ
Maki Hashizawa · 2023年1月18日

第3回 InterSystems 医療 x IT セミナー ソリューション開発編 II 開催のお知らせ

インタ―システムズでは、医療ITソリューション・サービスを提供される方々向けに、医療DXの推進やデータ活用を支援するシステムの要件、求められる姿について考察するオンラインセミナーをシリーズで開催しております。ソリューション開発編の第2段として、今回は「相互運用性/FHIR®の実装」をテーマに、下記の通り、開催する運びとなりました。 是非、ご参加いただきたくご案内致します。 【開催概要】 日時:2023年2月9日(木)13:00 - 14:30 (予定) 参加:無料(事前登録制) 対象:医療情報ステムベンダー、医療機器メーカー、医療向けサービスプロバイダーの事業企画・開発の皆様 主催:インタ―システムズジャパン株式会社 お申込み・詳細はこちらから 【プログラム】 13:00~13:05 開会挨拶 インターシステムズジャパン株式会社カントリーマネージャー 林 雅音 13:05~13:45「高度な医療DXを実現するための情報基盤とは」 宮崎大学医学部名誉教授 荒木 賢二 様 13:50 - 14:25「HL7® FHIR® × InterSystems IRIS for Health」 インターシステムズジャパン株式会社古薗 知子 13:25 - 14:30 閉会挨拶 ※ プログラムは、変更の場合がございます。最新の情報はWebサイトでご確認ください。 詳細・お申込みはこちらをご覧ください。 第3回 InterSystems 医療 x IT セミナー 詳細サイト 皆様のご参加をお待ちしています。
記事
Toshihiko Minamoto · 2023年7月13日

InterSystems Package Manager と git-source-control で IRIS インターオペラビリティのソース管理を有効にする

開発者の皆さん、こんにちは! ご存知のように、InterSystems IRIS インターオペラビリティソリューションには、プロダクション、ビジネスルール、ビジネスプロセス、データ変換、レコードマッパーなどの様々なエレメントが含まれています。 また、UI ツールを使用してこれらの要素を作成し、変更することもあります。  もちろん、UI ツールで行った変更をソース管理する便利で堅牢な方法も必要です。 長い間、これは手動(クラス、エレメント、グローバルなどのエクスポート)か面倒な設定作業手順によって行われてきました。そのため、ソース管理 UI の自動化で節約された時間は、設定のセットアップとメンテナンスの時間で相殺されていました。 現在では、この問題はなくなりました。 パッケージファースト開発と @Timothy.Leavitt の [git-source-control](https://openexchange.intersystems.com/package/Git-for-Shared-Development-Environments) という IPM パッケージの使用という 2 つのアプローチによる結果です。 詳細は以下のとおりです! _免責事項: これは、インターオペラビリティのプロダクションのエレメントがリポジトリ内のファイルである場合の、クライアント側の開発アプローチに関連しています。_ よって、ソリューションは非常に単純であるため、この記事は長くありません。 Docker で開発しており、IRIS を使って開発環境の Docker イメージをビルドしたら、ソリューションを IPM モジュールとして読み込んでいるとします。 これは、「パッケージファースト」開発と呼ばれ、関連する動画や記事が存在する手法です。 基本的には、開発環境の Docker イメージを IRIS でビルドすると、クライアントのサーバーにデプロイされるときに、ソリューションがパッケージとして読み込まれるという考え方になります。 ソリューションのパッケージファースト開発環境を作るには、module.xml をリポジトリに追加し、そのすべての要素を記述して、Docker イメージのビルドフェーズで「zpm load "repository/folder"」コマンドを呼び出します。 この考え方を、サンプルテンプレートの [IRIS Interoperability template](https://openexchange.intersystems.com/package/iris-interoperability-template) とそれに使用する [module.xml](https://github.com/intersystems-community/iris-interoperability-template/blob/ee85f96376aea5c725970d8b4d55e317ab86d00a/module.xml) を使って示しましょう。 パッケージは、Docker ビルド中に以下のように読み込まれています。 zpm "load /home/irisowner/irisdev/ -v":1:1 [ソース](https://github.com/intersystems-community/iris-interoperability-template/blob/ee85f96376aea5c725970d8b4d55e317ab86d00a/iris.script)  パッケージソース管理を読み込む前に配置された以下の 2 行を見てください。 これにより、ソース管理はパッケージ内のすべての相互運用性要素に対して自動的に動作し始め、適切なフォルダに適切な形式でエクスポートされます。 zpm "install git-source-control" do ##class(%Studio.SourceControl.Interface).SourceControlClassSet("SourceControl.Git.Extension") [ソース](https://github.com/intersystems-community/iris-interoperability-template/blob/ee85f96376aea5c725970d8b4d55e317ab86d00a/iris.script) 仕組み 最近、[git-source-control](https://openexchange.intersystems.com/package/Git-for-Shared-Development-Environments) アプリは、開発モードで読み込まれるソース管理用の IPM パッケージをサポートするようになりました。 エクスポートするフォルダを読み取り、module.xml からソースの構造をインポートします。 詳細は、@Timothy.Leavitt が説明できます。 ターミナルで、環境がビルドされた後の IPM モジュールのリストを確認すると、読み込まれたモジュールが実際に開発モードになっているのが分かります。 USER>zpm ============================================================================= || Welcome to the Package Manager Shell (ZPM). || || Enter q/quit to exit the shell. Enter ?/help to view available commands || ============================================================================= zpm:USER>list git-source-control 2.1.0 interoperability-sample 0.1.2 (DeveloperMode) sslclient 1.0.1 zpm:USER> では試してみましょう。  このリポジトリをクローンし、VSCode で開いてイメージをビルドしました。 以下では、相互運用性 UI とソース管理をテストしています。 UI に変更を加えるとすぐに、ソースと差分に表示されます。 ![](/sites/default/files/inline/images/images/source-control.gif) できました! それだけです!  まとめると、プロジェクトで相互運用性 UI 要素のソース管理を行うには、以下を行います。 1. Docker イメージをビルド中に、iris.script に 2 行を追加します。 zpm "install git-source-control" do ##class(%Studio.SourceControl.Interface).SourceControlClassSet("SourceControl.Git.Extension") その後、以下のようにして、ソリューションをモジュールとして読み込みます。 zpm "load /home/irisowner/irisdev/ -v":1:1 2. または、[Interoperability template](https://openexchange.intersystems.com/package/iris-interoperability-template) からリポジトリを作成して新規に始めることもできます。 お読みいただきありがとうございました! コメントやフィードバックをお待ちしています!
記事
Mihoko Iijima · 2020年6月28日

【はじめての InterSystems IRIS】セルフラーニングビデオ:アクセス編:Python の NativeAPI に挑戦

Python から InterSystems IRIS へ接続する方法の1つである「Native API」(※)の使用方法ご説明します。 ※ Python からのアクセスは、Native API の他に、PyODBC を利用した接続方法もあります。PyODBC の利用については別の記事でご説明します。 もくじ 最初~1:47 前回のビデオの学習(セルフラーニングビデオの索引記事もご参照ください) 1:47~3:18 今回の説明内容解説 3:18~5:14  Python Native APIを利用するための準備 5:14~10:48 IRISに接続する~^employee(1)の作成と参照 10:48~12:49 グローバル変数のサブスクリプトのループ方法(Iteratorの使い方) 12:49~14:19 グローバル変数の削除とコネクションのクローズ 14:19~20:21 国税庁が公開している都道府県別酒類消費量をグローバル変数に登録する (東京のアルコール消費量の登録) 20:21~21:43 大阪のアルコール消費量の追加登録 21:43~24:22 ^Alcoholから東京だけのデータ取得 24:22~27:22 ^Alcohol全件取得 27:22~28:27 特定のサブスクリプトの情報を削除する 28:27~30:53 おまけ(Pythonの便利なパッケージをインポートし、CSVデータのグラフ化) 30:53~最後まで まとめ ※ YouTubeでご覧いただくと、「もくじ」の秒数クリックでビデオをジャンプできます。 サンプルコード(Git) HelloWorldNativeAPI.ipynb 国税庁が公開している都道府県別酒類消費量をグローバル変数に登録する流れ(Sake.ipynb)