ObjectScript は InterSystems IRIS などの InterSystems 製品に使用されている強力な言語で、堅牢なアプリケーションの構築を可能にします。 OwnObjectScriptExtension は Visual Studio Code の拡張機能として、ObjectScript 開発エクスペリエンスを強化する広範なツールと機能を提供しています。 この記事では、OwnObjectScriptExtension によって ObjectScript 開発ワークフローがどのように改善されるかを説明します。

メソッドの説明を包括的に記述することは、コードを明確に維持し、コラボレーションを促進する上で欠かせません。 OwnObjectScriptExtension を使用すると、メソッドの説明を簡単に生成できます。 メソッド内にカーソルを配置し、Add Method Description コマンドを実行するだけで完了です。 拡張機能によってメソッドの説明テンプレートが自動的に生成されるため、意味のあるドキュメントを簡単に提供できます。

IRIS コンテナに VSCode を追加する

繰り返し利用できる開発環境をセットアップするには、環境用のコンテナを起動するのが最も簡単な方法の 1 つです。 素早く繰り返す際には、自分の開発コンテナ内に vscode インスタンスをホストするのが非常に便利なことが分かりました。 そこで、ブラウザベースの vscode を IRIS コンテナに追加するための簡易コンテナスクリプトを作成しました。 これは、ほとんどの 2021.1+ のコンテナで動作するはずです。 私のコードリポジトリはこちらにあります。

vscode を含み事前に接続された InterSystems IRIS コンテナ

概要

このプロジェクトでは、ホストされた（Web ベース）バージョンの vscode を同じコンテナ内で利用できる IRIS コンテナを作成します。 これには、以下が含まれます。

• 同じコンテナコードの編集
• コンテナの IRIS インスタンスへの事前接続
• 管理ポータルからのリンク
• コンテナによる IDE の自動起動

クイックスタート

こんにちは、皆さま。
業務でIRISを用いて開発を行っている者です。

技術文書ライティングコンテストという事で、私からはAWS環境を用いたCI/CDの仕組みについてご紹介します。

CI/CDとは「Continuous Integration（継続的インテグレーション）/ Continuous Delivery（継続的デリバリー）」の略称で、
詳細はネットをググると色々出てくると思いますが、私としてはリポジトリに格納されたものを自動で品質保証して、
問題なければ自動でデプロイしてくれる一連の仕組みだと理解しています。

という事で、その第一歩はIRISのソースコードをgitで管理することです。
pythonで作成したテストプログラムを用意しました。

Docker による Apache Web ゲートウェイ

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

この記事では、以下を使用して、Docker でプログラムによって Apache Web ゲートウェイを構成します。

• HTTPS プロトコル
• Web ゲートウェイと IRIS インスタンス間の安全な通信を確保する TLS/SSL

イメージには、Web ゲートウェイ用と IRIS インスタンス用の 2 つを使用します。

すべての必要なファイルは、こちらの GitHub リポジトリで入手可能です。

では、git clone から始めましょう。

git clone https://github.com/lscalese/docker-webgateway-sample.git
cd docker-webgateway-sample

システムの準備

権限に関する問題を回避するために、システムにユーザーとグループが必要です。

• www-data
• irisowner

コンテナと証明書ファイルの共有に必要です。 これらがシステムに存在しない場合は、以下を実行します。

sudo useradd --uid 51773 --user-group irisowner
sudo groupmod --gid 51773 irisowner
sudo useradd –user-group www-data

証明書の生成

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

この記事では、IRIS Security Package 用 REST API をセットアップする方法を学習します。 簡単な HTTP リクエストによって、ユーザー、役割、アプリケーションの追加などを作成し、ObjectScript でクライアントアプリケーションを生成できるようになります。

必要条件

必要なのは:

1. IRISインスタンス(インストールキットまたはDocker)
2. ObjectScript package manager (ZPM)
3. ObjectScriptクライアントを生成するための2つ目のIRISインスタンス(オプション)

OpenExchangeで既存のアプリケーションとライブラリのセットを使用する予定です。 package manager　(ZPM)を使用すると、それらのインストールが非常に簡単になります。 インスタンスに ZPM がない場合は、IRIS ターミナルにこのラインをコピーすることで簡単にインストールすることができます。

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

今までにミラーリング環境をセットアップされたことはありますか？ プライベートネットワーク、仮想 IP アドレス、および SSL 構成を設定したことはありますか？ この作業を何度か繰り返すと、証明書の生成や各 IRIS インスタンスの構成にはたくさんの手動による作業が必要で、時間がかかる作業であることに気づきました。 頻繁にこの作業を行わなければならない方にとっては、面倒な作業です。

たとえば、品質管理チームでは、新しいバージョンのアプリケーションをテストするたびに、新しい環境を作成しなければならないでしょう。 サポートチームであれば、複雑な問題を再現する環境を作成しなくてはならないかもしれません。

となれば、こういった環境を素早く作成できるツールが絶対に必要です。

この記事では、以下を使用するミラー環境のセットアップ例を紹介します。

• アービター
• プライマリ
• バックアップフェイルオーバーメンバー
• 読み書きレポート非同期メンバー
• ノード間でジャーナルを転送するための SSL 構成
• ミラー用のプライベートネットワーク
• 仮想 IP アドレス
• ミラーリングされたデータベース

一見すると、ちょっと複雑であり、たくさんのコードが必要なように見えますが、ご心配いりません。 OpenExchange には、ほとんどの操作を簡単に実行できるライブラリがあります。

IRIS ベースのアプリケーションを GCP Kubernetes で実行する方法については、すでに「InterSystems IRIS ソリューションを CircleCI を使用して GCP Kubernetes Cluster GKE へデプロイする」で検討しました。 また、IRIS ベースのアプリケーションを AWS Kubernetes で実行する方法については、「Amazon EKS を使用したシンプルな IRIS ベースの Web アプリケーションのデプロイ」で確認しました。 そこで今回は、アプリケーションを Azure Kubernetes Service（AKS）にデプロイする方法を説明することにします。

記事で使用されているすべてのソースコード: 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

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

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

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

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

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

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

この記事では、GitHub Actions を使って InterSystems Package Manager のサーバー部分である ZPM-registry を Google Kubernetes Engine (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」を参照してください。 

この連載記事では、InterSystemsの技術とGitLabを使用したソフトウェア開発に向けていくつかの可能性のあるアプローチをを紹介し、議論したいと思います。 今回は以下のようなトピックを取り上げます。 

• Git 101 
• Gitフロー（開発プロセス） 
• GitLabのインストール 
• GitLabワークフロー 
• 継続的デリバリー 
• GitLabのインストールと構成 
• GitLab CI/CD 
• コンテナを使用する理由 
• コンテナインフラストラクチャ 
• コンテナを使用したCD 
• ICMを使用したCD 

この記事では、InterSystems Cloud Managerを使用して継続的デリバリーを構築ドします。 ICMは、InterSystems IRISをベースとしたアプリケーション用のクラウドプロビジョニングおよびデプロイメントソリューションです。これにより、 必要なデプロイ構成を定義することができ、ICMが自動的にプロビジョニングします。 詳細については、First Look: ICM をご覧ください。

 ワークフロー

継続的デリバリーの構成では、次のようになります。

この連載記事では、InterSystemsの技術とGitLabを使用したソフトウェア開発に向けて実現可能な複数の手法を紹介し、議論したいと思います。 次のようなトピックについて説明します。

• Git 101 
• Gitフロー（開発プロセス） 
• GitLabのインストール 
• GitLabワークフロー 
• 継続的デリバリー 
• GitLabのインストールと構成 
• GitLab CI/CD 
• コンテナを使用する理由 
• コンテナインフラストラクチャ 
• コンテナを使用したCD 

第1回の記事では、Gitの基本、Gitの概念を高度に理解することが現代のソフトウェア開発にとって重要である理由、Gitを使用してソフトウェアを開発する方法について説明しています。

第2回の記事では、ソフトウェアのライフサイクルの完全なプロセスであるGitLabワークフローについて説明しています。

第3回の記事では、GitLabのインストールと構成ならびに利用環境のGitLabへの接続について説明しています。

第4回の記事では、CDの構成を説明しています。

第5回の記事では、コンテナとその使用方法（および使用する理由）について説明しています。

第6回の記事では、コンテナを使用して継続的デリバリーのパイプラインを実行する必要がある主なコンポーネントと、それらすべての連携の仕組みについて説明しています。  

IRIS 2019.4以降の製品には、Prometheus形式でIRISのメトリックを公開する/api/monitorサービス機能が実装されています。 IRISのメトリックを監視・警告ソリューションの一部として使用したい人にとっては大きなニュースです。 このAPIは、IRISの次期バージョンでリリースされる予定の新しいIRIS System Alerting and Monitoring (SAM) ソリューションのコンポーネントです。 

ただし、IRISインスタンスを監視するためにSAMがこのAPIの計画と実証実験を開始するのを待つ必要はありません。 今後の投稿では利用可能なメトリックとその意味についてさらに掘り下げ、対話型ダッシュボードの例を示します。 しかし、まずは背景の説明といくつかの質問と回答から始めましょう。 

1. 初めに

IRISでは、複数ノードでクラスターを構成し、ワークロードのスケールアウト、データボリュームのスケールアウトやトランザクション処理と分析処理を異なるノードで処理するマルチワークロードを実現しています。
しかし、クラスターを構成するための設定は、ノード数が増えるにつれ煩雑になり、それらを人手の作業に全て委ねると設定ミス等を招きやすいといえます。
また、クラスタの構成を処理負荷の増加に基づいて拡張する、または逆に縮小する、あるいは、データ冗長性を追加するためにミラーリングの構成を追加するなど構成変更は、想定するより多いかもしれません。
しかもクラスタ毎に同様の設定を毎回行うとなると、人手による作業では、煩雑性だけでなく俊敏性に欠けると言わざるを得ません。

そこで、IRISには、クラスター構成作業を自動化する新しいツールICM（InterSystems Cloud Manager）が用意されました。

ここでは、ICMを使用したクラウド上でのIRIS構成の自動化の手順について説明します。

2.　事前に準備するもの

以下の作業を行うためには、InterSystemsが用意している２つのDocker Imageを事前に取得する必要があります。

• ICMイメージ
• IRISイメージ