B.2 J2EE

J2EEのコンテナをRed Hat OpenShift上で作成するための、Red Hat OpenShiftアプリケーションの設定ファイルのテンプレートの変更内容の例を以下に記載します。

赤字部分が、追加/変更箇所です。

注意

追加する行の場所やインデントは、必ず上の例に合わせてください。追加する箇所のインデントがずれているとコンテナが起動できません。

図中の1～5について以下に説明します。

IPCパラメーターの設定
```
          security.alpha.kubernetes.io/unsafe-sysctls: "kernel.shmmni=4164,kernel.sem=512 37793 50 1302,kernel.msgmax=16384,kernel.msgmnb=32768,kernel.msgmni=4177"
```
- 上記は、IPCパラメーターに"kernel.shmmni=4164,kernel.sem=512 37793 50 1302,kernel.msgmax=16384,kernel.msgmnb=32768,kernel.msgmni=4177"を設定する場合の例です。
  設定する値は"ISAS-IPCtuning.xlsx"を使用して算出してください。
J2EEが動作するDockerコンテナを特権コンテナとして起動する設定
```
          securityContext:
            privileged: true
```
```
        securityContext:
          runAsUser: 0
        serviceAccount: privsvcacct
        serviceAccountName: privsvcacct
```
- serviceAccount、および、serviceAccountNameに設定するサービスアカウント名については、Red Hat OpenShift環境のクラスタ管理者に確認してください。上記は、serviceAccountとserviceAccountNameが"privsvcacct"の場合の例です。
livenessProbeでJ2EEの生存状態を監視する設定
```
#          livenessProbe: 
#            exec:
#              command:
#              - /interstage/probe/probe.sh
#            initialDelaySeconds: 60
#            timeoutSeconds: 1
```
- Podが再起動するとDockerコンテナが削除され、Dockerイメージから新たなDockerコンテナが生成されるため、本書ではlivenessProbeによる監視を推奨していません。
  設定する場合はコメントアウト"#"を解除してください。
- Interstageの起動完了前にlivenessProbeが実行されると、Podが再起動を繰り返すため、initialDelaySecondsに指定する値は、systemdの起動時間(秒)より大きい値(systemdの起動時間の2倍を目安）とし、環境に合わせて調節してください。Podが再起動を繰り返す場合、シスログを参照し、"Started Inspect whether IAPS is alive."のメッセージが出力されておらず、かつ"Received SIGTERM."のメッセージが出力されている場合は、initialDelaySecondsの値を大きくしてください。systemdの起動時間は、J2EEアプリケーションを配備したDockerコンテナを起動した状態、あるいは、livenessProbeを指定せずにRed Hat OpenShift上でPodを起動した環境で、systemd-analyzeコマンドを実行することで確認できます。
永続ボリュームを利用する設定
```
          volumeMounts:
          - mountPath: "/var/log"
            name: pv01
        volumes:
        - name: pv01
          persistentVolumeClaim:
            claimName: pvc01
```
- ユーザーアプリケーションが出力するログやシスログを永続ボリュームへ出力する場合に設定します。本製品が出力するログ（例えば、IJServerのコンテナログやコンテナ情報ログ）は永続ストレージを指定できません。
- PersistentVolume(PV)と紐づいたPersistentVolumeClaim(PVC)をPodに接続することで、Podから外部のボリュームを利用できるようになります。
- 上記は、PVが"pv01"、マウントパスが"/var/log"（シスログの格納先）、PVCが"pvc01"の場合の例です。
  PVCは以下のように、STATUSが"Bound"になっていることを確認します。
```
$ oc get pvc
NAME   STATUS  VOLUME  CAPACITY  ACCESS MODES  STORAGECLASS  AGE
pvc01  Bound   pv01    50Gi       RWX          slow          4h
```
サービス定義の設定
```
- apiVersion: v1
  kind: Service
  metadata:
    annotations:
      openshift.io/generated-by: OpenShiftNewApp
    creationTimestamp: null
    labels:
      app: j2eemyapp
    name: j2eemyapp-isadmin
  spec:
    ports:
    - name: 12000-tcp
      port: 12000
      protocol: TCP
      targetPort: 12000
    selector: 
      app: j2eemyapp
      deploymentconfig: j2eemyapp
  status:
    loadBalancer: {}
```
- サービス名と機能の対応の分かりやすさのためにInterstage管理コンソール用のサービス名をj2eemyappからj2eemyapp-isadminに変更していますが、必須ではありません。
- Red Hat OpenShift上でInterstage管理コンソールを使用しない場合は、Interstage管理コンソール用のサービスの定義を削除しても構いません。