IBM MQ和应用容器之间的进程命名空间共享

1 年 ago
雅, 悟
2 minutes

MQアプリケーションをローカル・キュー・マネージャーに接続(以下、ローカル接続と表記)するときには、アプリケーションとキュー・マネージャーが同一OS上で稼働しプロセス間通信を行います。この接続形態のアプリケーションを、1プロセス1コンテナーを原則とするコンテナー環境にそのまま移行することはできません。そこでKubernetesのプロセス名前空間の共有機能を使い、MQコンテナーとアプリコンテナーを同一Podで起動させる構成への移行を検証してみました。今回はMQを使用していますが、ローカル接続を使用するミドルウェアやアプリケーションでも同様の考え方で検証できます。

在容器环境中使用IBM MQ

在容器环境中，使用IBM MQ有两种方法。（具体详情在《IBM MQ在容器中的规划手册》中有详述。）

    1. IBM MQ Operator の使用

 

    独自のイメージとデプロイメント・コードのビルド

我将简单介绍上述两种类型。

使用IBM MQ运算符

IBM MQ Operator はRed Hat OpenShift Container Platform (以下OpenShiftと表記) にデプロイされている場合のみサポートされるオペレーターです。IBM MQ OperatorをOpenShiftにインストールすると、図1のようにキュー・マネージャーを作成できるようになります。図2のように、yaml ビューで編集してからキュー・マネージャーを作成できるようになっていますが、マニュアル等には明記されていないもののあらゆる構成変更が可能な訳では無いようです。柔軟に構成変更しながら検証するため、今回は後述の「独自のイメージとデプロイメント・コードのビルド」を選択しました。
なお KubernetesでIBM MQコンテナーを使用するには、IBM MQ Sample Helm Chartを使用するか、「独自のイメージとデプロイメント・コードのビルド」を利用することになります。

operator0101.png
operator0102.png

独自のイメージとデプロイメント・コードのビルド

独自のIBM MQキュー・マネージャーのイメージをビルドして利用できます。ビルド方法の詳細については、mq-contaier GitHubレポジトリーにあるコンテナー・イメージのビルドに本番向けと開発向けの手順が掲載されています。基本的にはドキュメント通りにビルドできました。この方法はイメージのビルドや利用時にオペレーターには無い柔軟性を発揮できますが、イメージのビルドや利用方法を自身で管理することになります。
上記に関連して、開発用途に使えるビルド済みの IBM MQ Advanced for Developers コンテナー・イメージがIBM Container Registryのicr.io/ibm-messaging/mqにあります。
この記事では、ビルド済み開発用MQコンテナー・イメージを使ったOpenShift上でのデプロイ検証結果について記述します。ちなみに独自にビルドしたイメージでも同様に動作しました。

启动已构建的镜像

OpenShift上でMQコンテナー・イメージとアプリケーションのイメージを同一Podで起動し、プロセス名前空間の共有によりアプリケーションがキュー・マネージャーにローカル接続でアクセスできるようにします。前提として、MQコンテナー・イメージとアプリコンテナー・イメージは /mnt/mqm を共有します。

ocpcluster.png

パラメーターは以下の表の通りです。

項目値デプロイメントの名前 　mq-01クラスターのネームスペースtest-01ビルド済み開発用MQコンテナー・イメージの名前mq-built-containerアプリコンテナー・イメージの名前mq-agent

deployment.yaml 記述例の抜粋を以下に示します。プロセス名前空間の共有に必須となるフィールドと値はshareProcessNamespace: trueです。このフィールドの意味や有効化によって生じる動作の違いはKubernetesのドキュメントのPod内のコンテナ間でプロセス名前空間を共有するに説明されています。下記に示すように、このフィールドを deployment.yaml のspec > template > spec の下に記述します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mq-01
  namespace: test-01
  labels:
    app.kubernetes.io/instance: mq-01
    app.kubernetes.io/name: mq-built-container
spec:
  selector:
    matchLabels:
      app: mq-01
  replicas: 1
  template:
    metadata:
      labels:
        app: mq-01
        app.kubernetes.io/instance: mq-01
        app.kubernetes.io/name: mq-built-container
    spec:
      shareProcessNamespace: true

この設定をベースにして、今回試したデプロイメントは以下の通りです。デプロイメントの一部、共有ストレージやConfigMapの詳細については省略して示しています。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mq-01
  namespace: test-01
  labels:
    app.kubernetes.io/instance: mq-01
    app.kubernetes.io/name: mq-built-container
spec:
  selector:
    matchLabels:
      app: mq-01
  replicas: 1
  template:
    metadata:
      labels:
        app: mq-01
        app.kubernetes.io/instance: mq-01
        app.kubernetes.io/name: mq-built-container
    spec:
      shareProcessNamespace: true
      securityContext:
        supplementalGroups: [99]
      containers:
      - name: mq-built-container-01
        envFrom:
        - configMapRef:
            name: configmap-mq-01
        image: icr.io/ibm-messaging/mq:latest
        volumeMounts:
        - mountPath: /mnt/mqm
          name: mq-volume
        ports:
          - name: qm
            containerPort: 1414
            protocol: TCP
      - name: mq-agent-01
        envFrom:
        - configMapRef:
            name: configmap-agent-01
        image: image-registry.openshift-image-registry.svc:5000/test-01/mq-agent:latest
        volumeMounts:
        - mountPath: /tmp/mqagent
          name: conf-volume
          readOnly: true
        - mountPath: /mnt/mqm
          name: mq-volume
      volumes:
        - name: mq-volume
          persistentVolumeClaim:
            claimName: pvc-mq-01
        - name: conf-volume
          projected:
            sources:
            - configMap:
                name: mqagent-conf
            - configMap:
                name: mqagent-access-conf

上記のdeploymentをデプロイします。

$ oc apply -f deployment.yaml

不细说应用的运作内容，但是通过这个可以在本地连接运行应用程序。在Kubernetes上通过类似的部署也可以在技术上启动。本次验证是使用开发用镜像进行的。如果考虑应用到生产环境，需要考虑实现高可用性、选择共享存储、维护构建的消息队列容器镜像、以及环境依赖等因素。如果这篇文章对技术验证有所帮助，那就很幸运了。

想要了解更多的信息请查看以下资料:

Kubernetes文档：在Pod内共享容器之间的进程命名空间
https://kubernetes.io/zh/docs/tasks/configure-pod-container/share-process-namespace/

✖
广告
将在 10 秒后关闭
bannerAds