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

Azure

この記事では、Azure の無料サブスクリプションを使用します。 価格の詳細については、Azure の価格表ページをご覧ください。 

登録が完了すると、Microsoft Azure ポータルが表示されます。

便利なポータルではありますが、この記事では使用しません。 代わりに、Azure コマンドラインインターフェースをインストールしましょう。 執筆時点での最新バージョンは 2.30.0 です。

$ az version{  "azure-cli": "2.30.0",  "azure-cli-core": "2.30.0",  "azure-cli-telemetry": "1.0.6",  "extensions": {}}

それでは、Azure にログインしましょう。

$ az login

CircleCI パイプライン

強力な CircleCI の CI/CD を使用して、AKS のセットアップと IRIS アプリケーションのインストールを行います。 つまり、GitHub ベースのプロジェクトを使って、コードとしてのインフラストラクチャと共にいくつかのパイプラインファイルを追加し、GitHub に変更をプッシュし直して、その結果を使いやすい CircleCI UI で確認します。

GitHub アカウントを使えば、簡単に CircleCI との統合を作成できます。 詳細については、「Seamless integration with GitHub」の記事をご覧ください。

では、「Amazon EKS を使用したシンプルな IRIS ベースの Web アプリケーションのデプロイ」で使用したプロジェクトの更新バージョンを使用しましょう。つまり、secured-rest-api です。 それを開き、Use this Template をクリックして、新しいリポジトリ内にバージョンを作成します。 この記事では、そこに含まれるコードサンプルを参照します。

ローカルにリポジトリを Clone し、以下に示すファイルを含む .circleci/ ディレクトリを作成します。

$ tree .circleci/.circleci/├── config.yml└── continue.yml

ダイナミックコンフィグとパスのフィルタリングを使用して、変更のあるファイルに応じて全体または一部を実行するようにパイプラインを設定します。 この例では、Terraform コードに変更がある場合にのみ Terraform ジョブを実行します。 最初の config.yml ファイルは単純です。 2 つ目の .circleci/continue.yml を呼び出し、Terraform コードが最新である場合に特定のブール値パラメーターを渡します。
 

$ cat config.ymlversion: 2.1# Enable CircleCI's dynamic configuration featuresetup: true# Enable path-based pipelineorbs:  path-filtering: circleci/path-filtering@0.1.0workflows:  Generate dynamic configuration:    jobs:      - path-filtering/filter:          name: Check updated files          config-path: .circleci/continue.yml          base-revision: master          mapping: |            terraform/.* terraform-job true

2 つ目の continue.yml ファイルを説明する前に、この secured-rest-app プロジェクトを CircleCI に追加して、.circleci/config.yml の変更を GitHub にプッシュしましょう。

$ git add .circleci/config.yml$ git commit -m "Add circleci config.yml"$ git push

そして、CircleCI Projects ページを開いて、プロジェクトを選択し、Set Up Project をクリックします。

  提示される推奨事項に従って、Setup Workflow を有効にします（詳細は、「CircleCI のダイナミック コンフィグの使用を開始する」をご覧ください。

これで、2 つ目の continue.yml ファイルに進む準備が整いました。 このファイルの構造は次のようになっています。

Jobs セクションには、次のジョブが含まれます。

Terraform

インフラストラクチャの作成には、infrastructure as code アプローチを使用して、Terraform の力を利用します。 Terraform は Azure プラグインを使って AKS と対話します。 ラッパーの役割を果たし、リソース作成を単純化する AKS Terraform モジュール を使用すると便利です。

Terraform を使用して AKS リソースを使用する例は、「Creating a Kubernetes Cluster with AKS and Terraform」にあります。 ここでは、Terraform がデモと単純化の目的でですべてのリソースを管理するように、Owner ロールを割り当てます。 アプリケーションとしての Terraform は Service Principal を使用して Azure に接続します。 厳密には、「Create an Azure service principal with the Azure CLI」に説明されているとおりに、Owner ロールを Service Principal に割り当てます。 

ローカルマシンでコマンドをいくつか実行してみましょう。 Azure サブスクリプション ID を環境変数に保存します。

$ export AZ_SUBSCRIPTION_ID=$(az account show --query id --output tsv)$ az ad sp create-for-rbac -n "Terraform" --role="Owner" --scopes="/subscriptions/${AZ_SUBSCRIPTION_ID}"…{  "appId": "<appId>",  "displayName": "<displayName>",  "name": "<name>",  "password": "<password>",  "tenant": "<tenant>"}

後で、Service Principals をリスト表示して Terraform という表示名を探すと、appId と tenantId を見つけ出すことができます。

$ az ad sp list --display-name "Terraform" | jq '.[] | "AppId: \(.appId), TenantId: \(.appOwnerTenantId)"'

ただし、この方法ではパスワードが表示されません。 パスワードを忘れた場合には、資格情報をリセットするしかありません。

パイプラインでは、AKS の作成には、一般に公開されている Azure Terraform モジュールと Terraform バージョン 1.0.11 を使用します。

取得した、Terraform が Azure への接続に使用する資格情報を使用して、CircleCI project 設定に環境変数を設定します。 また、DOMAIN_NAME 環境変数も設定します。 このチュートリアルは demo-iris.myardyas.club ドメイン名を使用していますが、実際にはユーザーが登録したドメイン名を使用します。 パイプラインでこの変数を使用して、IRIS アプリケーションへの外部アクセスを有効にします。 CircleCI 変数と az create-for-rbac コマンドのマッピングは次のとおりです。

ARM_CLIENT_ID: appIdARM_CLIENT_SECRET: passwordARM_TENANT_ID: tenantARM_SUBSCRIPTION_ID: Value of environment variable AZ_SUBSCRIPTION_IDDOMAIN_NAME: your domain name

Terraform Remote の状態を有効にするには、Azure Storage の Terraform の状態を使用します。 これを実現するために、ローカルマシンで次のコマンドを実行してみましょう。 

$ export RESOURCE_GROUP_NAME=tfstate$ export STORAGE_ACCOUNT_NAME=tfstate14112021 # Must be between 3 and 24 characters in length and use numbers and lower-case letters only$ export CONTAINER_NAME=tfstate
  # Create resource group$ az group create --name ${RESOURCE_GROUP_NAME} --location eastus
  # Create storage account$ az storage account create --resource-group ${RESOURCE_GROUP_NAME} --name ${STORAGE_ACCOUNT_NAME} --sku Standard_LRS --encryption-services blob  
# Enable versioning. Read more at https://docs.microsoft.com/ja-jp/azure/storage/blobs/versioning-overview$ az storage account blob-service-properties update --account-name ${STORAGE_ACCOUNT_NAME} --enable-versioning true  
# Create blob container$ az storage container create --name ${CONTAINER_NAME} --account-name ${STORAGE_ACCOUNT_NAME}

Terraform ディレクトリに配置した Terraform コードです。 これは、次の 3 つのファイルに分割されています。

Azure リソースグループ、パブリック IP、Azure コンテナレジストリなどを作成します。 ネットワーキングと Azure Kubernetes サービスについては、一般に公開されている Terraform モジュールを活用します。

パッケージのセットアップ

新たに作成された AKS クラスタにインストールするものは、helm ディレクトリにあります。 説明的な Helmfile アプローチを使用することで、アプリケーションとその設定を helmfile.yaml ファイルに定義することができます。

セットアップは、単一の helmfile sync コマンドで実行します。 このコマンドによって、IRIS アプリケーションと 2 つの追加アプリケーション、cert-manager、および ingress-nginx がインストールされ、外部からアプリケーションを呼び出せるようになります。 詳細については、GitHub の「releases」セクションをご覧ください。

IRIS アプリケーションは、「CircleCI ビルドで GKE の作成を自動化する」の説明と同じ Helm チャートを使用してインストールします。 単純化するために、deployment を使用します。 つまり、ポッドの再起動時に、データは保持されません。 永続させる場合は、Statefulset またはより優れた Kubernetes IRIS Operator（IKO）を使用することをお勧めします。 IKO デプロイメントの例は、iris-k8s-monitoring リポジトリにあります。

パイプラインの実行

.circleci/、terraform/、および helm/ ディレクトリを追加したら、それらを GitHub にプッシュします。

$ git add .$ git commit -m "Setup everything"$ git push

すべて問題がなければ、以下のような CircleCI UI 画面が表示されます。

ドメインレジストラでの A レコードの設定

後もう一つ残っているのは、Terraform が Azure で作成したパブリック IP とDomain Registrar 近ソースのドメイン名の A レコードでバインディングを作成することです。

クラスタに接続しましょう。

$ az aks get-credentials --resource-group demo --name demo

ingress-nginx で公開されるパブリック IP アドレスを定義します。

$ kubectl -n ingress-nginx get service ingress-nginx-controller -ojsonpath='{.spec.loadBalancerIP}'x.x.x.x

次のようにして、この IP をドメインレジストラ（GoDaddy、Route53、GoogleDomains など）に設定します。

YOUR_DOMAIN_NAME = x.x.x.x

ここで、DNS の変更が世界中に伝搬されるまでしばらく待ってから、結果を確認します。

$ dig +short YOUR_DOMAIN_NAME

応答は x.x.x.x となります。

テスト

ドメイン名を demo-iris.myardyas.club と仮定して、手動テストを実施します。 Let's Encrypt のステージング用証明書を使用しているため、ここでは、証明書の確認は省略しましょう。 本番環境では、lets-encrypt-production（こちら）に置き換える必要があります。 また、メールアドレス（こちら）を example@gmail.com ではないものに設定することもお勧めします。

$ curl -sku Bill:ChangeMe https://demo-iris.myardyas.club/crudall/_spec | jq .…

人（ユーザー）を作成する:

$ curl -ku John:ChangeMe -XPOST -H "Content-Type: application/json"  https://demo-iris.myardyas.club/crud/persons/ -d '{"Name":"John Doe"}'

人が作成されたかどうかを確認する:

$ curl -sku Bill:ChangeMe https://demo-iris.myardyas.club/crud/persons/all | jq .[  {    "Name": "John Doe"  }...

まとめ

これで以上です！ Terraform と CircleCI ワークフローを使用して、Azure クラウドに Kubernetes クラスタを作成する方法を確認しました。 IRIS インストールでは、最も簡単な Helm チャートを使用しました。 本番環境では、このチャートを拡張し、少なくともデプロイを Statefulset に置き換えるか、IKO を使用することをお勧めします。

作成したリソースが不要になったら、忘れずに削除しましょう。 Azure には、無料利用枠が用意されており、AKS は無料ですが、AKS クラスタの実行用に設計されたリソースは有料です。

この記事では、従来のIRISミラーリング構成の代わりに、Kubernetesの Deploymentと分散永続ストレージを使って高可用性IRIS構成を構築します。 このデプロイでは、ノード、ストレージ、アベイラビリティーゾーンといったインフラストラクチャ関連の障害に耐えることが可能です。 以下に説明する方法を使用することで、RTOがわずかに延長されますが、デプロイの複雑さが大幅に軽減されます。

この記事に記載されているすべてのソースコードは、https://github.com/antonum/ha-iris-k8s より入手できます。
要約

3ノードクラスタを実行しており、Kubernetesにいくらか詳しい方は、このまま以下のコードを使用してください。

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

上記の2行の意味がよくわからない方、またはこれらを実行できるシステムがない場合は、「高可用性要件」のセクションにお進みください。 説明しながら進めていきます。

最初の行は、Longhornというオープンソースの分散Kubernetesストレージをインストールしています。 2行目は、DurableSYS用にLonghornベースのボリュームを使って、InterSystems IRISデプロイをインストールしています。

すべてのポッドが実行状態になるまで待ちます。 kubectl get pods -A

上記の手順を済ませると、http://<IRIS Service Public IP>:52773/csp/sys/%25CSP.Portal.Home.zenにあるIRIS管理ポータル（デフォルトのパスワードは「SYS」）にアクセスできるようになります。また、次のようにしてIRISコマンドラインも使用できるようになります。

kubectl exec -it iris-podName-xxxx -- iris session iris

障害をシミュレートする

では、実際に操作してみましょう。 ただし、操作の前に、データベースにデータを追加して、IRISがオンラインになったときに存在することを確認してください。

kubectl exec -it iris-6d8896d584-8lzn5 -- iris session iris
USER>set ^k8stest($i(^k8stest))=$zdt($h)_" running on "_$system.INetInfo.LocalHostName()
USER>zw ^k8stest
^k8stest=1
^k8stest(1)="01/14/2021 14:13:19 running on iris-6d8896d584-8lzn5"

ここからが「カオスエンジニアリング」の始まりです。

# IRISを停止 - コンテナは自動的に再開します
kubectl exec -it iris-6d8896d584-8lzn5 -- iris stop iris quietly
 
# ポッドを削除 - ポッドが再作成されます
kubectl delete pod iris-6d8896d584-8lzn5
 
# irisポッドの配信によりノードを「強制ドレイン」 - ポッドは別のノードで再作成されます
kubectl drain aks-agentpool-29845772-vmss000001 --delete-local-data --ignore-daemonsets --force
 
# ノードを削除 - ポッドは別のノードで再作成されます
# ただし、kubectlでは削除できないので、 そのインスタンスまたはVMを見つけて、強制終了します。
マシンにアクセスできる場合は、電源を切るかネットワークケーブルを外します。 冗談ではありません！

高可用性要件

以下の障害に耐えられるシステムを構築しています。

• コンテナ/VM内のIRISインスタンス。 IRIS - レベル障害
• ポッド/コンテナの障害
• 個々のクラスタノードの一時的な使用不能。 アベイラビリティーゾーンが一時的にオフラインになる場合などが挙げられます。
• 個々のクラスタノードまたはディスクの永久的障害。

基本的に、「障害をシミュレートする」セクションで試したシナリオです。

上記のいずれかの障害が発生すると、システムは人間が手をいれなくてもオンラインになり、データも失われません。 データの永続性が保証する範囲には一応制限がありますが、 ジャーナルサイクルとアプリケーション内のトランザクションの使用状況に応じて、IRISで実現されます（https://docs.intersystems.com/irisforhealthlatestj/csp/docbook/Doc.View.cls?KEY=GCDI_journal#GCDI_journal_writecycle）。いずれにしても、RPO（目標復旧ポイント）は2秒未満です。

システムの他のコンポーネント（Kubernetes APIサービス、etcdデータベース、ロードバランサーサービス、DNSなど）はスコープ外であり、通常、Azure AKSやAWS EKSなどのマネージドKubernetesサービスで管理されます。

別の言い方をすれば、個別の計算コンポーネントやストレージコンポーネントの障害はユーザーが処理するものであり、その他のコンポーネントの障害はインフラストラクチャ/クラウドプロバイダーが対処するものと言えます。

アーキテクチャ

InterSystems IRISの高可用性について言えば、これまでミラーリングの使用が勧められてきました。 ミラーリングでは、データは、常時オンライン状態にある2つのIRISインスタンスが同期的に複製されます。 各ノードにはデータベースの完全なコピーが維持され、プライマリノードがオフラインになると、ユーザーはバックアップノードに接続し直すことができます。 基本的に、ミラーリング手法では、計算とストレージの両方の冗長性は、IRISが管理するものです。

ミラーをさまざまなアベイラビリティーゾーンにデプロイしたミラーリングにより、計算処理とストレージの障害に備えた必要な冗長性を実現し、わずか数秒という優れたRTO（目標復旧時間または障害後にシステムがオンラインに復旧するまでにかかる時間）を達成することができます。 AWSクラウドでミラーリングされたIRISのデプロイテンプレートは、https://jp.community.intersystems.com/node/486206から入手できます。

一方で、ミラーリングには、設定やバックアップ/復旧手順が複雑で、セキュリティ設定とローカルのデータベース以外のファイルの複製機能が不足しているという欠点があります。

コンテナオーケストレータ―にはKubernetesなど（今や2021年。ほかにオーケストレーターってありますか?!）がありますが、これらは、障害時に、Deploymentオブジェクトが障害のあるIRISポッド/コンテナを自動的に再起動することで、計算冗長性を実現しています。 Kubernetesアーキテクチャ図に、実行中のIRISノードが1つしかないのはこのためです。 2つ目のIRISノードを常時実行し続ける代わりに、計算可用性をKubernetesにアウトソースしています。 Kubernetesは、元のIRISポッドが何らかの理由でエラーとなった場合に、IRISポッドの再作成を確保します。

図2 フェイルオーバーのシナリオ

ここまでよろしいでしょうか。 IRISノードに障害が発生すると、Kubernetesは単に新しいノードを作成します。 クラスタによって異なりますが、計算障害が発生してからIRISがオンラインになるまでには、10～90秒かかります。 ミラーリングではわずか2秒で復旧されるわけですから、これはダウングレードとなりますが、万が一サービス停止となった場合に許容できる範囲であれば、複雑さが緩和されることは大きなメリットと言えます。 ミラーリングの構成は不要です。 セキュリティ設定やファイル複製を気にする必要もありません。

率直に言うと、KubernetesでIRISを実行し、コンテナにログインしても、高可用性環境で実行していることには気づくこともないでしょう。 単一インスタンスのIRISデプロイと全く同じように見え、何ら感触にも変化はありません。

では、ストレージはどうでしょうか。 データベースを扱っているわけですから気になります。 どのようなフェイルオーバーのシナリオであっても、システムはデータの永続性も処理する必要があります。 ミラーリングは、IRISノードのローカルである計算ノードに依存しているため、 ノードが停止するか、一時的に使用不可になってしまえば、そのノードのストレージも停止してしまいます。 ミラーリング構成では、IRISがIRISレベルでデータベースを複製するのはこれに対処するためです。

コンテナの再起動時に元の状態を維持したデータベースを使用できるだけでなく、ノードやネットワークのセグメント全体（アベイラビリティーゾーン）が停止するといったイベントに備えて、冗長性を提供できるストレージが必要です。 ほんの数年前、これを解決できる簡単な答えは存在しませんでした。 上の図から推測できるように、今ではその答えを得ています。 分散コンテナストレージです。

分散ストレージは、基盤のホストボリュームを抽象化し、k8sクラスタのすべてのノードが使用できる共同の1つのクラスターとして提示します。 この記事では、インストールが非常に簡単なLonghorn（https://longhorn.io）という無料のオープンソースのストレージを使用しますが、 OpenEBS、Porworx、StorageOSといったほかのストレージも利用できます。同じ機能が提供されています。 CNCF IncubatingプロジェクトであるRook Cephも検討する価値があるでしょう。 この種のハイエンドとしては、NetAppやPureStorageといったエンタープライズ級のストレージソリューションがあります。

手順

「要約」セクションでは、1回にすべてをインストールしました。 インストールと検証の手順の説明は、付録Bをご覧ください。

Kubernetesストレージ

まずは、コンテナとストレージ全般について、またIRISがどこに適合するのかについて説明しましょう。

デフォルトでは、コンテナ内のすべてのデータは揮発性であるため、 コンテナが停止すればデータは消失します。 Dockerでは、ボリュームの概念を使用することができるため、 基本的に、ホストOSのディレクトリをコンテナに公開することができます。

docker run --detach
  --publish 52773:52773
  --volume /data/dur:/dur
  --env ISC_DATA_DIRECTORY=/dur/iconfig
  --name iris21 --init intersystems/iris:2020.3.0.221.0

上記の例では、IRISコンテナを起動し、host-localの「/data/dur」ディレクトリを、「/dur」マウントポイントのコンテナからアクセスできるようにしています。 つまり、コンテナがこのディレクトリに何かを格納している場合、それは保持され、コンテナの次回起動時に使用できるようになります。

IRIS側では、ISC_DATA_DIRECTORYを指定することで、IRISに、コンテナの再起動時に損失してはいけないすべてのデータを特定のディレクトリに格納するように指示することができます。 ドキュメントの「Durable SYS」というIRISの機能をご覧ください（ https://docs.intersystems.com/irisforhealthlatestj/csp/docbook/Doc.View.cls?KEY=ADOCK#ADOCK_iris_durable_running）。

Kubernetesでの構文は異なりますが、概念は同じです。

IRISの基本的なKubernetes Deploymentは以下のようになります。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: iris
spec:
  selector:
    matchLabels:
      app: iris
  strategy:
    type: Recreate
  replicas: 1
  template:
    metadata:
      labels:
        app: iris
    spec:
      containers:
      - image: store/intersystems/iris-community:2020.4.0.524.0
        name: iris
        env:
        - name: ISC_DATA_DIRECTORY
          value: /external/iris
        ports:
        - containerPort: 52773
          name: smp-http
        volumeMounts:
        - name: iris-external-sys
          mountPath: /external
      volumes:
      - name: iris-external-sys
        persistentVolumeClaim:
          claimName: iris-pvc

上記のデプロイ仕様では、「volumes」の部分にストレージボリュームがリストされています。 このボリュームには、「iris-pvc」などのpersistentVolumeClaimを介して、コンテナの外部からアクセスできます。 volumeMountsは、このボリュームをコンテナ内に公開します。 「iris-external-sys」は、ボリュームマウントを特定のボリュームに関連付ける識別子です。 実際には複数のボリュームが存在する可能性があり、ほかのボリュームと区別するためにこの名前が使用されるわけですから、 「steve」と名付けることも可能です。

すでにお馴染みのISC_DATA_DIRECTORYは、IRISが特定のマウントポイントを使用して、コンテナの再起動後も存続する必要のあるすべてのデータを格納するように指示する環境変数です。

では、persistentVolumeClaimのiris-pvcを見てみましょう。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: iris-pvc
spec:
  storageClassName: longhorn
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

かなりわかりやすいと思います。 「longhorn」ストレージクラスを使って、1つのノードでのみ読み取り/書き込みとしてマウント可能な、10ギガバイトを要求しています。

ここで重要なのは、storageClassName: longhornです。

AKSクラスタで利用できるストレージクラスを確認してみましょう。

kubectl get StorageClass
NAME                             PROVISIONER                     RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
azurefile                        kubernetes.io/azure-file        Delete          Immediate           true                   10d
azurefile-premium                kubernetes.io/azure-file        Delete          Immediate           true                   10d
default (default)                kubernetes.io/azure-disk        Delete          Immediate           true                   10d
longhorn                         driver.longhorn.io              Delete          Immediate           true                   10d
managed-premium                  kubernetes.io/azure-disk        Delete          Immediate           true                   10d

Azureのストレージクラスはほとんどありませんが、これらは、デフォルトでインストールされたクラスと、以下の一番最初のコマンドの一部でインストールしたLonghornのクラスです。

kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/master/deploy/longhorn.yaml

永続ボリュームクレームの定義に含まれる#storageClassName: longhornをコメントアウトすると、現在「default」としてマークされているストレージクラスが使用されます。これは、通常のAzureディスクです。

分散ストレージが必要な理由を説明するために、この記事の始めに説明した、longhornストレージを使用しない「カオスエンジニアリング」実験をもう一度行ってみましょう。 最初の2つのシナリオ（IRISの停止とポッドの削除）は正常に完了し、システムは稼働状態に回復します。 ノードをドレインまたは強制終了しようとすると、システムは障害状態になります。

#forcefully drain the node
kubectl drain aks-agentpool-71521505-vmss000001 --delete-local-data --ignore-daemonsets
kubectl describe pods
...
  Type     Reason            Age                  From               Message
  ----     ------            ----                 ----               -------
  Warning  FailedScheduling  57s (x9 over 2m41s)  default-scheduler  0/3 nodes are available: 1 node(s) were unschedulable, 2 node(s) had volume node affinity conflict.

基本的に、KubernetesはクラスタのIRISポッドを再起動しようとしますが、最初に起動されていたノードは利用できないため、ほかの2つのノードに「ボリュームノードアフィニティの競合」が発生しています。 このストレージタイプでは、基本的にボリュームはノードホストで使用可能なディスクに関連付けられているため、最初に作成されたノードでしか使用できないのです。

ストレージクラスにlonghornを使用すると、「強制ドレイン」と「ノードの強制終了」の2つの実験は正常に完了し、間もなくしてIRISポッドの動作が再開します。 これを実現するために、Longhornは3ノードクラスタをで使用可能なストレージを制御し、3つのすべてのノードにデータを複製しています。 ノードの1つが永久的に使用不可になると、Longhornは迅速にクラスタストレージを修復します。 「ノードの強制終了」シナリオでは、IRISポッドはほかの2つのボリュームレプリカを使ってすぐに別のノードで再起動されます。 するとAKSは失われたノードに置き換わる新しいノードをプロビジョニングし、準備ができたら、Longhorn がそのノードに必要なデータを再構築します。 すべては自動的に行われるため、ユーザーが手を入れる必要はありません。

図3 置換されたノードにボリュームレプリカを再構築するLonghorn

k8sデプロイについて

デプロイの他の側面をいくつか見てみましょう。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: iris
spec:
  selector:
    matchLabels:
      app: iris
  strategy:
    type: Recreate
  replicas: 1
  template:
    metadata:
      labels:
        app: iris
    spec:
      containers:
      - image: store/intersystems/iris-community:2020.4.0.524.0
        name: iris
        env:
        - name: ISC_DATA_DIRECTORY
          value: /external/iris
        - name: ISC_CPF_MERGE_FILE
          value: /external/merge/merge.cpf
        ports:
        - containerPort: 52773
          name: smp-http
        volumeMounts:
        - name: iris-external-sys
          mountPath: /external
        - name: cpf-merge
          mountPath: /external/merge
        livenessProbe:
          initialDelaySeconds: 25
          periodSeconds: 10
          exec:
            command:
            - /bin/sh
            - -c
            - "iris qlist iris | grep running"
      volumes:
      - name: iris-external-sys
        persistentVolumeClaim:
          claimName: iris-pvc
      - name: cpf-merge
        configMap:
          name: iris-cpf-merge

strategy: Recreateとreplicas: 1では、Kubernetesに、常にIRISポッドの1つのインスタンスのみを実行し続けることを指示しています。 これが「ポッドの削除」シナリオを処理する部分です。

livenessProbeのセクションでは、IRISが常時、コンテナ内で稼働し、「IRIS停止」シナリオを処理できるようにしています。 initialDelaySecondsは、IRISが起動するまでの猶予期間です。 IRISがデプロイを起動するのにかなりの時間が掛かっている場合は、これを増やすと良いでしょう。

IRISのCPF MERGE機能を使用すると、コンテナの起動時に、iris.cpf構成ファイルのコンテンツを変更することができます。 関連するドキュメントについては、 https://docs.intersystems.com/irisforhealthlatestj/csp/docbook/DocBook.UI.Page.cls?KEY=RACS_cpf#RACS_cpf_edit_mergeをご覧ください。 この例では、Kubernetesの構成図を使って、マージファイルのコンテンツを管理しています（ https://github.com/antonum/ha-iris-k8s/blob/main/iris-cpf-merge.yaml）。ここでは、IRISインスタンスが使用するグローバルバッファとgmheapの値を調整していますが、iris.cpfファイルにあるものはすべて調整できます。 デフォルトのIRISパスワードでさえも、CPFマージファイルの「PasswordHash」フィールドで変更可能です。 詳細については、https://docs.intersystems.com/irisforhealthlatestj/csp/docbook/Doc.View.cls?KEY=ADOCK#ADOCK_iris_images_password_authをご覧ください。

永続ボリュームクレーム（https://github.com/antonum/ha-iris-k8s/blob/main/iris-pvc.yaml）デプロイ（https://github.com/antonum/ha-iris-k8s/blob/main/iris-deployment.yaml）とCPFマージコンテンツを使った構成図（https://github.com/antonum/ha-iris-k8s/blob/main/iris-cpf-merge.yaml）のほかに、デプロイには、IRISデプロイをパブリックインターネットに公開するサービスが必要です（https://github.com/antonum/ha-iris-k8s/blob/main/iris-svc.yaml）。

kubectl get svc
NAME         TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)           AGE
iris-svc     LoadBalancer   10.0.18.169   40.88.123.45   52773:31589/TCP   3d1h
kubernetes   ClusterIP      10.0.0.1      <none>          443/TCP           10d

iris-svcの外部IPは、http://40.88.123.45:52773/csp/sys/%25CSP.Portal.Home.zenを介してIRIS管理ポータルにアクセスするために使用できます。 デフォルトのパスワードは「SYS」です。

ストレージのバックアップ/復元とスケーリング

Longhornには、ボリュームの構成と管理を行えるウェブベースのUIがあります。

kubectlを使用して、ポッドや実行中のlonghorn-uiコンポーネントを特定し、ポート転送を確立できます。

kubectl -n longhorn-system get pods
# longhorn-uiのポッドIDに注意してください。
kubectl port-forward longhorn-ui-df95bdf85-gpnjv 9000:8000 -n longhorn-system

Longhorn UIは、http://localhost:9000で利用できるようになります。

図4 LonghornのUI

Kubernetesコンテナストレージのほとんどのソリューションでは、高可用性のほか、バックアップ、スナップショット、および復元のための便利なオプションが用意されています。 詳細は実装によって異なりますが、一般的には、バックアップをVolumeSnapshotに関連付ける方法です。 この方法はLonghornでも利用できます。 使用しているKubernetesのバージョンとプロバイダーによっては、ボリュームスナップショット機能（ https://github.com/kubernetes-csi/external-snapshotter）もインストールする必要があります。

そのようなボリュームショットの例には、「iris-volume-snapshot.yaml」が挙げられます。 使用する前に、バックアップを、LonghornのS3バケットまたはNFSボリュームに構成する必要があります。 https://longhorn.io/docs/1.0.1/snapshots-and-backups/backup-and-restore/set-backup-target/

# IRISボリュームのクラッシュコンシステントなバックアップを取得する
kubectl apply -f iris-volume-snapshot.yaml

IRISでは、バックアップ/スナップショットを取得する前にExternal Freezeを実行し、後でThawを実行することをお勧めします。 詳細については、https://docs.intersystems.com/irisforhealthlatestj/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=Backup.General#ExternalFreezeをご覧ください。  

IRISボリュームのサイズを増やすには、IRISが使用する、永続ボリュームクレーム（iris-pvc.yamlファイル）のストレージリクエストを調整します。

...
  resources:
    requests:
      storage: 10Gi #change this value to required

そして、pvcの仕様を再適用します。 Longhornは、実行中のポッドにボリュームが接続されている場合、この変更を実際に適用することはできません。 そのため、ボリュームサイズが増えるように、デプロイでレプリカ数を一時的にゼロに変更します。

高可用性 - 概要

この記事の冒頭で、高可用性の基準を設定しました。 このアーキテクチャでは、次のようにそれを実現します。

ゾンビやその他の考慮事項

DockerコンテナでのIRISの実行を理解している方であれば、「--init」フラグを使用したことがあるでしょう。

docker run --rm -p 52773:52773 --init store/intersystems/iris-community:2020.4.0.524.0

このフラグは、「ゾンビプロセス」の形成を防止することを目的としています。 Kubernetesでは、「shareProcessNamespace: true」を使用する（セキュリティの考慮事項が適用されます）か、コンテナで「tini」を使用することができます。 以下に、tiniを使用したDockerfileの例を示します。

FROM iris-community:2020.4.0.524.0
...
# Tiniを追加します
USER root
ENV TINI_VERSION v0.19.0
ADD https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini /tini
RUN chmod +x /tini
USER irisowner
ENTRYPOINT ["/tini", "--", "/iris-main"]

2021年以降、すべてのInterSystemsが提供するコンテナイメージには、デフォルトでtiniが含まれています。

いくつかのパラメーターを調整することで、「ノードの強制ドレイン/ノードの強制終了」シナリオのフェイルオーバー時間をさらに短縮することができます。

Longhornのポッド削除ポリシー（https://longhorn.io/docs/1.1.0/references/settings/#pod-deletion-policy-when-node-is-down）およびkubernetes taintベースのエビクション機能（https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-based-evictions）をご覧ください。

免責事項

InterSystemsに勤務する者として、この内容を記載しておく必要があります。この記事では、分散型Kubernetesブロックストレージの一例としてLonghornを使用しています。 InterSystemsは、個々のストレージソリューションや製品を検証ないしは公式なサポート声明を発行していません。 特定のストレージソリューションがニーズに適合しているかどうかは、ユーザー自身がテストして検証する必要があります。

分散ストレージには、ノードローカルストレージとは大きく異なるパフォーマンス特性も備わっています。 特に書き込み操作の場合、データが永続化された状態とみなされるには、データを複数の場所に書き込む必要があります。 必ずワークロードをテストし、CSIドライバが提供する特定の動作とオプションを理解するようにしてください。

InterSystemsでは基本的に、Longhornなどの特定のストレージjソリューションを検証あるいは承認していません。これは、個々のHDDブランドやサーバーハードウェアメーカーを検証しないのと同じです。 個人的には、Longhornは扱いやすいと感じています。プロジェクトのGitHubページ（https://github.com/longhorn/longhorn）では、その開発チームは積極的に応答し、よく助けていただいています。 

まとめ

Kubernetesエコシステムは、過去数年間で大きな進化を遂げました。今日では、分散ブロックストレージソリューションを使用することで、IRISインスタンスやクラスタノード、さらにはアベイラビリティーゾーンの障害を維持できる高可用性構成を構築できるようにもなっています。

計算とストレージの高可用性をKubernetesコンポーネントにアウトソースできるため、従来のIRISミラーリングに比べ、システムの構成と管理が大幅に単純化しています。 ただしこの構成では、ミラーリング構成ほどのRTOとストレージレベルのパフォーマンスは得られないことがあります。

この記事では、Azure AKSをマネージドKubernetesとLonghorn分散ストレージシステムとして使用し、可用性の高いIRIS構成を構築しました。 ほかにも、AWS EKS、マネージドK8s向けのGoogle Kubernetes Engine、StorageOS、Portworx、OpenEBSなどの様々な分散コンテナストレージを探ってみると良いでしょう。エンタープライズ級のストレージソリューションには、NetApp、PureStorage、Dell EMCなどもあります。

付録A: クラウドでのKubernetesクラスタの作成

パブリッククラウドプロバイダーが提供するマネージドKubernetesサービスを使うと、このセットアップに必要なk8sクラスタを簡単に作成できます。 この記事で説明したデプロイには、AzureのAKSデフォルト構成をそのまますぐに使用することができます。

3ノードで新しいAKSクラスタを作成します。 それ以外はすべてデフォルトのままにします。

図5 AKSクラスタの作成

ローカルコンピュータにkubectlをインストールします。https://kubernetes.io/docs/tasks/tools/install-kubectl/

ローカルkubectlにASKクラスタを登録します。

図6 kubectlにAKSクラスタを登録

登録が済んだら、この記事の最初に戻って、longhornとIRISデプロイをインストールします。

AWS EKSでのインストールは、もう少し複雑です。 ノードグループのすべてのインスタンスにopen-iscsiがインストトールされていることを確認する必要があります。

sudo yum install iscsi-initiator-utils -y

GKEでのLonghornのインストールには追加の手順があります。https://longhorn.io/docs/1.0.1/advanced-resources/os-distro-specific/csi-on-gke/をご覧ください。

付録B: インストール手順

手順1 - Kubernetesクラスタとkubectl

3ノードk8sクラスタが必要です。 Azureでのクラスタの構成方法は付録Aをご覧ください。

$ kubectl get nodes
NAME                                STATUS   ROLES   AGE   VERSION
aks-agentpool-29845772-vmss000000   Ready    agent   10d   v1.18.10
aks-agentpool-29845772-vmss000001   Ready    agent   10d   v1.18.10
aks-agentpool-29845772-vmss000002   Ready    agent   10d   v1.18.10

手順2 - Longhornをインストールする

kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/master/deploy/longhorn.yaml

「longhorn-system」ネームスペースのすべてのポッドが実行状態であることを確認してください。 これには数分かかる場合があります。

$ kubectl get pods -n longhorn-system
NAME                                       READY   STATUS    RESTARTS   AGE
csi-attacher-74db7cf6d9-jgdxq              1/1     Running   0          10d
csi-attacher-74db7cf6d9-l99fs              1/1     Running   1          11d
...
longhorn-manager-flljf                     1/1     Running   2          11d
longhorn-manager-x76n2                     1/1     Running   1          11d
longhorn-ui-df95bdf85-gpnjv                1/1     Running   0          11d

詳細とトラブルシューティングについては、Longhornインストールガイド（https://longhorn.io/docs/1.1.0/deploy/install/install-with-kubectl）をご覧ください。

手順3 - GitHubリポジトリのクローンを作成する

$ git clone https://github.com/antonum/ha-iris-k8s.git
$ cd ha-iris-k8s
$ ls
LICENSE                   iris-deployment.yaml      iris-volume-snapshot.yaml
README.md                 iris-pvc.yaml             longhorn-aws-secret.yaml
iris-cpf-merge.yaml       iris-svc.yaml             tldr.yaml

手順4 - コンポーネントを1つずつデプロイして検証する

tldr.yamlファイルには、デプロイに必要なすべてのコンポーンネントが1つのバンドルとして含まれています。 ここでは、コンポーネントを1つずつインストールし、それぞれのセットアップを個別に検証します。

# 以前にtldr.yamlを適用したことがある場合は、削除します。
$ kubectl delete -f https://github.com/antonum/ha-iris-k8s/raw/main/tldr.yaml
永続ボリュームクレームを作成します
$ kubectl apply -f iris-pvc.yaml
persistentvolumeclaim/iris-pvc created
$ kubectl get pvc
NAME       STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
iris-pvc   Bound    pvc-fbfaf5cf-7a75-4073-862e-09f8fd190e49   10Gi       RWO            longhorn       10s
構成図を作成します
$ kubectl apply -f iris-cpf-merge.yaml
$ kubectl describe cm iris-cpf-merge
Name:         iris-cpf-merge
Namespace:    default
Labels:       <none>
Annotations:  <none>
Data
merge.cpf:
[config]
globals=0,0,800,0,0,0
gmheap=256000
Events:  <none>
irisデプロイを作成します
$  kubectl apply -f iris-deployment.yaml
deployment.apps/iris created
$ kubectl get pods                    
NAME                    READY   STATUS              RESTARTS   AGE
iris-65dcfd9f97-v2rwn   0/1     ContainerCreating   0          11s
ポッド名を書き留めます。 この名前は、次のコマンドでポッドに接続する際に使用します。
$ kubectl exec -it iris-65dcfd9f97-v2rwn   -- bash
irisowner@iris-65dcfd9f97-v2rwn:~$ iris session iris
Node: iris-65dcfd9f97-v2rwn, Instance: IRIS
USER>w $zv
IRIS for UNIX (Ubuntu Server LTS for x86-64 Containers) 2020.4 (Build 524U) Thu Oct 22 2020 13:04:25 EDT
h<enter>でIRISシェルを終了
exit<enter>でポッドを終了
IRISコンテナのログにアクセスします
$ kubectl logs iris-65dcfd9f97-v2rwn
...
[INFO] ...started InterSystems IRIS instance IRIS
01/18/21-23:09:11:312 (1173) 0 [Utility.Event] Private webserver started on 52773
01/18/21-23:09:11:312 (1173) 0 [Utility.Event] Processing Shadows section (this system as shadow)
01/18/21-23:09:11:321 (1173) 0 [Utility.Event] Processing Monitor section
01/18/21-23:09:11:381 (1323) 0 [Utility.Event] Starting TASKMGR
01/18/21-23:09:11:392 (1324) 0 [Utility.Event] [SYSTEM MONITOR] System Monitor started in %SYS
01/18/21-23:09:11:399 (1173) 0 [Utility.Event] Shard license: 0
01/18/21-23:09:11:778 (1162) 0 [Database.SparseDBExpansion] Expanding capacity of sparse database /external/iris/mgr/iristemp/ by 10 MB.
irisサービスを作成します
$ kubectl apply -f iris-svc.yaml   
service/iris-svc created
$ kubectl get svc
NAME         TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)           AGE
iris-svc     LoadBalancer   10.0.214.236   20.62.241.89   52773:30128/TCP   15s

手順5 - 管理ポータルにアクセスする

最後に、サービスの外部IP（http://20.62.241.89:52773/csp/sys/%25CSP.Portal.Home.zen）を使って、IRISの管理ポータルに接続します。ユーザー名は「_SYSTEM」、パスワードは「SYS」です。 初回ログイン時にパスワードの変更が求められます。

データベースシステムには非常に特殊なバックアップ要件があり、企業のデプロイメントでは、事前の検討と計画が必要です。 データベースシステムの場合、バックアップソリューションの運用上の目標は、アプリケーションが正常にシャットダウンされた時と同じ状態で、データのコピーを作成することにあります。 アプリケーションの整合性バックアップはこれらの要件を満たし、Cachéは、このレベルのバックアップ整合性を達成するために、外部ソリューションとの統合を容易にする一連のAPIを提供しています。

これらのAPIは**ExternalFreezeとExternalThaw**です。 _ExternalFreeze_は一時的にディスクへの書き込みを停止し、この期間にCaché はメモリ内の変更をコミットします。 この期間にバックアップ操作を完了させ、_ExternalThaw_の呼び出しを行う必要があります。 この呼び出しによって、書き込みのデーモンがグローバルバッファプール（データべースキャッシュ）で更新されたキャッシュをディスクに書き込むと、通常のCachéデータベースの書き込みデーモン操作が再開します。 このプロセスはCachéのユーザープロセスに対して透過的に行われます。 具体的なAPIクラスメソッドは次のとおりです。

##Class(Backup.General).ExternalFreeze()

##Class(Backup.General).ExternalThaw()

これらのAPIは、スナップショット操作のプリスクリプトとポストスクリプトを実行するAzure Backupの新機能と合わせて、Azure上のCachéのデプロイメントに対する包括的なバックアップソリューションを提供しています。 Azure Backupのプリスクリプトとポストスクリプト機能は現在、Linux VMでのみ利用できます。

前提条件

Azure Backupを使用してVMをバックアップする前に、おおまかに3つのステップを実行する必要があります。

1. Recovery Servicesコンテナーを作成する
2. VM Agentの最新バージョンをインストールする
3. VMからAzureサービスへのネットワークアクセスを確認する

Recovery Servicesコンテナーは、バックアップの目標、ポリシー、および保護する項目を管理します。 Recovery Servicesコンテナーの作成は、Azure PortalまたはPowerShellを使ったスクリプトによって行います。 Azure BackupにはVMで実行する拡張機能が必要であり、Linux VMエージェントによって管理されています。また、最新バージョンのエージェントも必要です。 拡張機能はAzure StorageとRecovery Servicesコンテナーの外向きのHTTPSエンドポイントと対話します。 VMからこれらのサービスへのセキュアアクセスは、Azure Network Security Groupのプロキシとネットワークルールを使用して構成できます。

上記のステップに関する詳細は、「Prepare your environment to back up Resource Manager-deployed virtual machines」を参照してください。

プリスクリプトとポストスクリプトの構成

バックアップ操作の前と後にスクリプトを呼び出す機能は、Azure Backup Extension（Microsoft.Azure.RecoveryServices.VMSnapshotLinux）の最新バージョンに含まれています。 この拡張機能のインストール方法については、機能に関する詳細なドキュメントを確認してください。

デフォルトでは、拡張機能には、Linux VMの次の場所に、サンプルのプリスクリプトとポストスクリプトが含まれます。

/var/lib/waagent/Microsoft.Azure.RecoveryServices.VMSnapshotLinux-1.0.9110.0/main/tempPlugin

そして、スクリプトをそれぞれ次の場所にコピーする必要があります。

/etc/azure/prescript.sh
/etc/azure/postScript.sh

スクリプトテンプレートは、GitHubからもダウンロード可能です。

Cachéでは、ExternalFreeze APIを呼び出すprescript.shスクリプトを実装でき、postScript.shにはExternalThawを実行するコードが含まれている必要があります。

以下は、Cachéのprescript.shの実装例です。

#!/bin/bash
# variables used for returning the status of the script
success=0
error=1
warning=2
status=$success
log_path="/etc/preScript.log"#path of log file
printf  "Logs:\n" > $log_path# TODO: Replace <CACHE INSTANCE> with the name of the running instance
csession <CACHE INSTANCE> -U%SYS "##Class(Backup.General).ExternalFreeze()" >> $log_path
status=$?if [ $status -eq 5 ]; then
echo "SYSTEM IS FROZEN"
printf  "SYSTEM IS FROZEN\n" >> $log_pathelif [ $status -eq 3 ]; then
echo "SYSTEM FREEZE FAILED"
printf  "SYSTEM FREEZE FAILED\n" >> $log_path
status=$error
csession <CACHE INSTANCE> -U%SYS "##Class(Backup.General).ExternalThaw()"
fi

exit $status

以下は、CachéのpostScript.shの実装例です。

#!/bin/bash
# variables used for returning the status of the script
success=0
error=1
warning=2
status=$success
log_path="/etc/postScript.log"#path of log file
printf  "Logs:\n" > $log_path# TODO: Replace <CACHE INSTANCE> with the name of the running instance
csession <CACHE INSTANCE> -U%SYS "##class(Backup.General).ExternalThaw()"
status=$?
if [ $status req 5]; then
echo "SYSTEM IS UNFROZEN"
printf  "SYSTEM IS UNFROZEN\n" >> $log_pathelif [ $status -eq 3 ]; then
echo "SYSTEM UNFREEZE FAILED"
printf  "SYSTEM UNFREEZE FAILED\n" >> $log_path
status=$error
fi
exit $status

バックアップの実行

Azureポータルで、Recoveryサービスに移動して、最初のバックアップをトリガできます。 初回バックアップまたは後続のバックアップに関係なく、VMスナップショットの時間は数秒であることに注意してください。 最初のバックアップのデータ転送には時間がかかりますが、データ転送は、データベースのフリーズを解除するポストスクリプトの実行後に開始されるため、プリスクリプトとポストスクリプト間の時間に影響を与えることはありません。

データ保護操作が有効であることを確認するには、定期的に非本番環境にバックアップを復元してデータベースの整合性チェックを実行することを強くお勧めします。

バックアップのトリガ方法、およびバックアップスケジュールなどの関連トピックについては、「Back up Azure virtual machines to a Recovery Services vault」を参照してください。  

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

今日はAzure上でIRIS for Healthをデプロイし、FHIRリポジトリを構築する方法をご紹介したいと思います。

AzureのMarketPlaceで「InterSystems」をキーワードに検索していただくと、以下のように複数のInterSystems製品がヒットします。

今日はこの製品の中から、InterSystems IRIS for Health Community Editionを選択し、FHIRリポジトリを構築します。

仮想マシンのサイズや、ディスク、ネットワーク等には特に制約や条件はありません。
Azureで提供されている最小の構成でもIRIS for Healthを動かすこともできます。

IRIS for Health Community Editionのデプロイに成功するとこのような画面に遷移します。
私の例では、コンピュータ名をIRIS4HFHIRSERVERとしています。
パブリックIPアドレスはマスクしていますが、このIPアドレスを使ってIRIS管理ポータルにアクセスしてみましょう。
http://<パブリックIPアドレス>:52773/csp/sys/UtilHome.csp

52773は管理ポータルにアクセスするためのポート番号であり、Azure上でデプロイするとこのポート経由でアクセスできるように既に構成が変更されています。

この記事では、InterSystems Technologiesに基づく、堅牢なパフォーマンスと可用性の高いアプリケーションを提供するリファレンスアーキテクチャをサンプルとして提供します。Caché、Ensemble、HealthShare、TrakCare、およびDeepSee、iKnow、Zen、Zen Mojoといった関連する組み込みテクノロジーに適用可能です。 

Azureには、リソースを作成して操作するための、Azure ClassicとAzure Resource Managerという2つのデプロイメントモデルがあります。 この記事で説明する情報は、Azure Resource Managerモデル（ARM）に基づきます。 

要約 

Microsoft Azureクラウドプラットフォームは、InterSystems製品すべてを完全にサポートできるクラウドサービスとして、IaaS（サービスとしてのインフラストラクチャ）向けの機能の豊富な環境を提供しています。 あらゆるプラットフォームやデプロイメントモデルと同様に、パフォーマンス、可用性、運用、管理手順などの環境に関わるすべての側面が正しく機能するように注意を払う必要があります。 この記事では、こういった各分野の詳細について説明しています。 

パフォーマンス 

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

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

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

 ワークフロー

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