はじめに
この記事では、Power Systems Virtual Server(以下PowerVS)上に構築したOpenShift 4.7からIBM Cloudサービス(Block Storage、File Storage、LogDNA)を利用します。事前にIBM CloudのclassicノードとPowerVSのbastionノード間でIPIPトンネリングし、classicノードでIPマスカレードを構成しています。そのため、OpenShiftからIBM Cloudサービスのプライベートエンドポイントへの接続が可能です。また、OpenShiftからの通信の送信元IPアドレスは、classicノードのIPアドレス(10.192.36.132)に変換されるため、Block StorageとFile Storageでは、許可ホストに同IPアドレスを設定することで、これらのサービスの利用が可能になります。
以下はPowerVSからのサービス連携に関連する記事です。
■ OpenShiftイメージレジストリのストレージとしてCloud Object Storageを設定
■ OpenShiftのAlertManagerの通知先としてSlackを設定
1. OpenShiftからBlock Storageを利用
1.1. Block Storage準備
IBM CloudでBlock Storageを2つ注文し、classicノードのIPアドレスからの接続を許可します。以後の設定では、IBM Cloudコンソールに表示される<ターゲット・アドレス>、<ボリュームID>、<ユーザー名>、<パスワード>、<ホストIQN>を使用します。<ホストIQN>とは別に\が必要である点に注意します。
2つのボリュームでは<ターゲット・アドレス>と<ボリュームID>が異なります。
2つのボリュームの<ユーザー名>、<パスワード>、<ホストIQN>は同じでした。
1.2. IQN確認
永続ボリュームのマニフェストに必要な<IQN>とシークレットのマニフェストに必要な<ユーザー名をbase64エンコードした文字列>と<パスワードをbase64エンコードした文字列>を取得します。
※IBM Cloudコンソールでは、Block Storage毎に2つのターゲット・アドレスが表示されています。一方のボリュームのターゲット・アドレスにディスカバリ要求を送信すると(iscsiadm -m discovery〜)注文した2つのボリュームのターゲット・アドレス合計4つが応答されました。
bastionノード
yum -y install iscsi-initiator-utils
echo InitiatorName=<ホストIQN> > /etc/iscsi/initiatorname.iscsi
vi /etc/iscsi/iscsid.conf(5行修正)
node.session.auth.authmethod = CHAP
node.session.auth.username = <ユーザー名>
node.session.auth.password = <パスワード>
discovery.sendtargets.auth.username = <ユーザー名>
discovery.sendtargets.auth.password = <パスワード>
### vi終了
systemctl restart iscsid
iscsiadm -m discovery -t sendtargets -p <ターゲット・アドレス#1-1>
### 標準出力↓
<ターゲット・アドレス#1-1>:3260,1062 <IQN>
<ターゲット・アドレス#1-2>:3260,1058 <IQN>
<ターゲット・アドレス#2-1>:3260,1055 <IQN>
<ターゲット・アドレス#2-2>:3260,1060 <IQN>
echo -n <ユーザー名> | base64
### 標準出力↓
<ユーザー名をbase64エンコードした文字列>
echo -n <パスワード> | base64
### 標準出力↓
<パスワードをbase64エンコードした文字列>
1.3. Open Libertyデプロイ
事前にBlock Storageボリューム毎に1つの永続ボリューム(PV)を作成し、Open Libertyをレプリカ数『2』のステートフルセットとしてデプロイします。ステートフルセットのデプロイ時にworkerノードのiSCSIイニシエータがBlock Storageボリューム(iSCSIターゲット)を認証・ログインします。
bastionノード
ssh core@worker-0 "echo InitiatorName=<ホストIQN> | sudo tee /etc/iscsi/initiatorname.iscsi"
ssh core@worker-1 "echo InitiatorName=<ホストIQN> | sudo tee /etc/iscsi/initiatorname.iscsi"
oc new-project block-storage
oc apply -f secret.yaml
oc apply -f persistent-volume0.yaml
oc apply -f persistent-volume1.yaml
oc apply -f statefulset.yaml
oc get pod
### 標準出力↓
NAME READY STATUS RESTARTS AGE
open-liberty-0 1/1 Running 0 56s
open-liberty-1 1/1 Running 0 38s
oc get pvc
### 標準出力↓
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
logs-open-liberty-0 Bound iscsi-pv-0 1Gi RWO 66s
logs-open-liberty-1 Bound iscsi-pv-1 1Gi RWO 48s
oc get pv
### 標準出力↓
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
iscsi-pv-0 1Gi RWO Retain Bound block-storage/logs-open-liberty-0 81s
iscsi-pv-1 1Gi RWO Retain Bound block-storage/logs-open-liberty-1 80s
secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: chap-secret
type: "kubernetes.io/iscsi-chap"
data:
discovery.sendtargets.auth.username: <ユーザー名をbase64エンコードした文字列>
discovery.sendtargets.auth.password: <パスワードをbase64エンコードした文字列>
node.session.auth.username: <ユーザー名をbase64エンコードした文字列>
node.session.auth.password: <パスワードをbase64エンコードした文字列>
persistent-volume0.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: iscsi-pv-0
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
iscsi:
targetPortal: <ターゲット・アドレス#1-1>:3260
portals: ['<ターゲット・アドレス#1-2:3260>']
iqn: <IQN>
lun: 0
fsType: ext4
chapAuthDiscovery: true
chapAuthSession: true
secretRef:
name: chap-secret
persistent-volume1.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: iscsi-pv-1
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
iscsi:
targetPortal: <ターゲット・アドレス#2-1>:3260
portals: ['<ターゲット・アドレス#2-2:3260>']
iqn: <IQN>
lun: 1
fsType: ext4
chapAuthDiscovery: true
chapAuthSession: true
secretRef:
name: chap-secret
statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: open-liberty
labels:
app: open-liberty
spec:
serviceName: open-liberty
replicas: 2
selector:
matchLabels:
app: open-liberty
template:
metadata:
labels:
app: open-liberty
spec:
containers:
- name: open-liberty
image: docker.io/open-liberty:21.0.0.4-full-java11-openj9
ports:
- containerPort: 9080
volumeMounts:
- name: logs
mountPath: /logs
volumeClaimTemplates:
- metadata:
name: logs
spec:
accessModes:
- ReadWriteOnce
volumeMode: Filesystem
resources:
requests:
storage: 1Gi
bastionノードからBlock Storageをマウントすると、Open Libertyのmessages.logが出力されていることを確認できます。
bastionノード
# ディスカバーしないとログイン不可
iscsiadm -m discovery -t sendtargets -p <ターゲット・アドレス#1-1>
iscsiadm -m node -T <IQN> -p "<ターゲット・アドレス#1-1>:3260" --login
### 標準出力↓
Logging in to [iface: default, target: <IQN>, portal: <ターゲット・アドレス#1-1>,3260]
Login to [iface: default, target: <IQN>, portal: <ターゲット・アドレス#1-1>,3260] successful.
ls -l /dev/mapper/
### 標準出力↓
合計 0
lrwxrwxrwx. 1 root root 7 5月 28 22:32 3600a09803830566b682b5162702d6f47 -> ../dm-3
mount /dev/mapper/3600a09803830566b682b5162702d6f47 /mnt
ls -l /mnt
### 標準出力↓
合計 44
drwxrws---. 2 root 1000620000 16384 5月 28 19:20 lost+found
-rw-r-----. 1 1000620000 1000620000 11804 5月 28 22:33 messages.log
head /mnt/messages.log
### 標準出力↓
********************************************************************************
product = Open Liberty 21.0.0.4 (wlp-1.0.51.cl210420210407-0944)
wlp.install.dir = /opt/ol/wlp/
server.output.dir = /opt/ol/wlp/output/defaultServer/
java.home = /opt/java/openjdk
java.version = 11.0.10
java.runtime = OpenJDK Runtime Environment (11.0.10+9)
os = Linux (4.18.0-240.22.1.el8_3.ppc64le; ppc64le) (en_US)
process = 1@10.131.0.83
********************************************************************************
umount /mnt
iscsiadm -m node -T <IQN> -p "<ターゲット・アドレス#1-1>:3260" --logout
# 自動接続を回避
iscsiadm -m node -T <IQN> -o delete
2. OpenShiftからFile Storageを利用
2.1. File Storage準備
IBM CloudでFile Storageを1つ注文し、classicノードのIPアドレスからの接続を許可します。以後の設定では、IBM Cloudコンソールに表示される<ホスト名>と<マウント・ポイント>を使用します。マウント・ポイントは<ホスト名>:<パス>になっています。
2.2. NFS動的プロビジョナーデプロイ
Red Hatのマニュアルではなく、Redbook「Red Hat OpenShift V4.3 on IBM Power Systems Reference Guide」で紹介されているNFS動的プロビジョナー(nfs-client-provisioner)をデプロイします。この場合、1つのFile Storegeに対して複数の永続ボリューム(PV)を作成することができます。
bastionノード
oc new-project external-storage
oc apply -f rbac.yaml
oc adm policy add-scc-to-user hostmount-anyuid system:serviceaccount:external-storage:nfs-client-provisioner
oc apply -f deployment.yaml
oc apply -f class.yaml
oc get pod
### 標準出力↓
NAME READY STATUS RESTARTS AGE
nfs-client-provisioner-7474565989-5wpnj 1/1 Running 0 6m8s
oc get sc
### 標準出力↓
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
managed-nfs-storage fuseim.pri/ifs Delete Immediate false 45s
rbac.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: nfs-client-provisioner
# replace with namespace where provisioner is deployed
namespace: external-storage
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: nfs-client-provisioner-runner
rules:
- apiGroups: [""]
resources: ["persistentvolumes"]
verbs: ["get", "list", "watch", "create", "delete"]
- apiGroups: [""]
resources: ["persistentvolumeclaims"]
verbs: ["get", "list", "watch", "update"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["events"]
verbs: ["create", "update", "patch"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: run-nfs-client-provisioner
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
# replace with namespace where provisioner is deployed
namespace: external-storage
roleRef:
kind: ClusterRole
name: nfs-client-provisioner-runner
apiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: leader-locking-nfs-client-provisioner
# replace with namespace where provisioner is deployed
namespace: external-storage
rules:
- apiGroups: [""]
resources: ["endpoints"]
verbs: ["get", "list", "watch", "create", "update", "patch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: leader-locking-nfs-client-provisioner
# replace with namespace where provisioner is deployed
namespace: external-storage
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
# replace with namespace where provisioner is deployed
namespace: external-storage
roleRef:
kind: Role
name: leader-locking-nfs-client-provisioner
apiGroup: rbac.authorization.k8s.io
deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nfs-client-provisioner
labels:
app: nfs-client-provisioner
# replace with namespace where provisioner is deployed
namespace: external-storage
spec:
replicas: 1
strategy:
type: Recreate
selector:
matchLabels:
app: nfs-client-provisioner
template:
metadata:
labels:
app: nfs-client-provisioner
spec:
serviceAccountName: nfs-client-provisioner
containers:
- name: nfs-client-provisioner
image: docker.io/ibmcom/nfs-client-provisioner-ppc64le:latest
volumeMounts:
- name: nfs-client-root
mountPath: /persistentvolumes
env:
- name: PROVISIONER_NAME
value: fuseim.pri/ifs
- name: NFS_SERVER
value: <ホスト名>
- name: NFS_PATH
value: <パス>
volumes:
- name: nfs-client-root
nfs:
server: <ホスト名>
path: <パス>
class.yaml
kind: StorageClass
metadata:
name: managed-nfs-storage
provisioner: fuseim.pri/ifs # or choose another name, must match deployment's env PROVISIONER_NAME'
parameters:
archiveOnDelete: "false"
2.3. Open Libertyデプロイ
Open Libertyをレプリカ数『2』のステートフルセットとしてデプロイします。ステートフルセットは永続ボリューム要求(PVC)を作成し、動的NFSプロビジョナーはPod毎に1つの永続ボリューム(PV)を作成します。
bastionノード
oc new-project file-storage
oc apply -f statefulset.yaml
oc get pod
### 標準出力↓
open-liberty-0 1/1 Running 0 112s
open-liberty-1 1/1 Running 0 106s
oc get pvc
### 標準出力↓
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS. AGE
logs-open-liberty-0 Bound pvc-38d33f66-dc97-4b45-b568-e79655a7f616 1Gi RWO managed-nfs-storage 2m2s
logs-open-liberty-1 Bound pvc-01190ede-0394-4143-b098-41c8b0a19df6 1Gi RWO managed-nfs-storage 2m6s
oc get pv
### 標準出力↓
pvc-01190ede-0394-4143-b098-41c8b0a19df6 1Gi RWO Delete Bound file-storage/logs-open-liberty-1 managed-nfs-storage 2m5s
pvc-38d33f66-dc97-4b45-b568-e79655a7f616 1Gi RWO Delete Bound file-storage/logs-open-liberty-0 managed-nfs-storage 2m11s
bastionノードからFile StorageをNFSマウントすると、PV毎にディレクトリが作成されていること、同ディレクトリ以下にOpen Libertyのmessages.logが出力されていることを確認できます。
bastionノード
mount <マウント・ポイント> /mnt
ls -l /mnt
### 標準出力↓
合計 8
drwxrwxrwx. 2 nobody nobody 4096 5月 28 23:05 file-storage-logs-open-liberty-0-pvc-38d33f66-dc97-4b45-b568-e79655a7f616
drwxrwxrwx. 2 nobody nobody 4096 5月 28 23:05 file-storage-logs-open-liberty-1-pvc-01190ede-0394-4143-b098-41c8b0a19df6
find /mnt -type f -exec ls -l {} \;
### 標準出力↓
-rw-r-----. 1 1000640000 nobody 11332 5月 28 23:06 /mnt/file-storage-logs-open-liberty-0-pvc-38d33f66-dc97-4b45-b568-e79655a7f616/messages.log
-rw-r-----. 1 1000640000 nobody 11333 5月 28 23:06 /mnt/file-storage-logs-open-liberty-1-pvc-01190ede-0394-4143-b098-41c8b0a19df6/messages.log
head /mnt/file-storage-logs-open-liberty-0-pvc-38d33f66-dc97-4b45-b568-e79655a7f616/messages.log
### 標準出力↓
********************************************************************************
product = Open Liberty 21.0.0.4 (wlp-1.0.51.cl210420210407-0944)
wlp.install.dir = /opt/ol/wlp/
server.output.dir = /opt/ol/wlp/output/defaultServer/
java.home = /opt/java/openjdk
java.version = 11.0.10
java.runtime = OpenJDK Runtime Environment (11.0.10+9)
os = Linux (4.18.0-240.22.1.el8_3.ppc64le; ppc64le) (en_US)
process = 1@10.131.0.83
********************************************************************************
umount /mnt
statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: open-liberty
labels:
app: open-liberty
spec:
serviceName: open-liberty
replicas: 2
selector:
matchLabels:
app: open-liberty
template:
metadata:
labels:
app: open-liberty
spec:
containers:
- name: open-liberty
image: docker.io/open-liberty:21.0.0.4-full-java11-openj9
ports:
- containerPort: 9080
volumeMounts:
- name: logs
mountPath: /logs
volumeClaimTemplates:
- metadata:
name: logs
spec:
accessModes:
- ReadWriteOnce
storageClassName: managed-nfs-storage
resources:
requests:
storage: 1Gi
3. OpenShiftからLog Analysis with LogDNAを利用
ppc64le用のlogdna-agentバイナリは配布されていないので、GitHubで公開されている「logdna-agent」を使用します。Node.jsで開発されておりビルドすることなく動作しました。「logdna-agent-v2」はRustで開発されていて高速とのことですがビルドできませんでした。
3.1. Log Analysis with LogDNA準備
IBM CloudでLog Analysis with LogDNAインスタンスを作成します。
インスタンス作成後、プラットフォーム・ログを構成します。
ダッシュボードを開き、メニュー > ORGANIZATION > API KeysからIngestion keysを確認します。Ingestion keysはシークレットとして作成し、logdna-agentコンテナで利用します。
3.2. OpenShiftへのlogdna-agentデプロイ
logdna-agentはDaemonSetとしてデプロイし、各ノードの「/var/log/containers」以下に出力されたログをLogDNAサービスに送信します。つまり、すべてのノードのコンテナログを対象にしています。
bastionノード
oc new-project logdna-agent
# Pod起動用Service Acccount作成・権限付与
oc create serviceaccount logdna-agent
oc adm policy add-scc-to-user privileged system:serviceaccount:logdna-agent:logdna-agent
# LogDNA接続用シークレット作成
oc create secret generic logdna-agent-key --from-literal=logdna-agent-key=<Ingestion keys>
# コンテナイメージ作成
oc new-build --name=logdna-agent --strategy=docker --binary
oc start-build logdna-agent --from-dir=. --follow
oc get is
### 標準出力↓
NAME IMAGE REPOSITORY TAGS UPDATED
logdna-agent image-registry.openshift-image-registry.svc:5000/logdna-agent/logdna-agent latest 13 seconds ago
# logdna-agentデプロイ
oc apply -f logdna-agent.yaml
oc get pod -o wide
### 標準出力↓
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
logdna-agent-1-build 0/1 Completed 0 6m21s 10.131.1.89 worker-0 <none> <none>
logdna-agent-44tpb 1/1 Running 0 2m 10.129.2.23 infra-2 <none> <none>
logdna-agent-5s2qn 1/1 Running 0 2m 10.130.2.102 infra-1 <none> <none>
logdna-agent-9sbmj 1/1 Running 0 2m 10.128.2.84 worker-1 <none> <none>
logdna-agent-c7s8t 1/1 Running 0 2m 10.131.1.93 worker-0 <none> <none>
logdna-agent-wptz5 1/1 Running 0 2m 10.131.2.24 infra-0 <none> <none>
Dockerfile
FROM registry.access.redhat.com/ubi8/ubi:latest
RUN dnf install -y nodejs git \
&& git clone https://github.com/logdna/logdna-agent.git
WORKDIR logdna-agent
COPY exec.sh /logdna-agent
RUN npm install \
&& chmod +x /logdna-agent/exec.sh
CMD ["/logdna-agent/exec.sh"]
exec.sh
# !/bin/bash
node index.js -u all
node index.js -k ${LOGDNA_AGENT_KEY}
node index.js -s LOGDNA_APIHOST=${LOGDNA_APIHOST}
node index.js -s LOGDNA_LOGHOST=${LOGDNA_LOGHOST}
LOGDNA_HOSTNAME=`cat /etc/logdna-hostname`
node index.js -n ${LOGDNA_HOSTNAME}
# 今回の例では/var/logをログ収集対象にしない
# /var/log/containersのリンク先=/var/log/podsを対象にするとログが送信されない
cp -p /etc/logdna.conf /etc/logdna.conf.tmp
sed -e 's/var\/log/var\/log\/containers/g' /etc/logdna.conf.tmp > /etc/logdna.conf
node index.js -s
logdna-agent.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: logdna-agent
labels:
app: logdna-agent
spec:
selector:
matchLabels:
app: logdna-agent
template:
metadata:
labels:
app: logdna-agent
spec:
containers:
- name: logdna-agent
image: image-registry.openshift-image-registry.svc:5000/logdna-agent/logdna-agent:latest
imagePullPolicy: Always
env:
- name: LOGDNA_AGENT_KEY
valueFrom:
secretKeyRef:
name: logdna-agent-key
key: logdna-agent-key
- name: LOGDNA_APIHOST
value: api.jp-tok.logging.cloud.ibm.com
- name: LOGDNA_LOGHOST
value: logs.jp-tok.logging.cloud.ibm.com
resources:
requests:
cpu: 20m
limits:
memory: 500Mi
securityContext:
privileged: true
volumeMounts:
- name: varlogcontainers
mountPath: /var/log/containers
readOnly: true
- name: varlogpods
mountPath: /var/log/pods
readOnly: true
- name: logdnahostname
mountPath: /etc/logdna-hostname
serviceAccount: logdna-agent
serviceAccountName: logdna-agent
volumes:
- name: varlogcontainers
hostPath:
path: /var/log/containers
- name: varlogpods
hostPath:
path: /var/log/pods
- name: logdnahostname
hostPath:
path: /etc/hostname
updateStrategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 100%
以下はOpen Libertyデプロイ時にLogDNAダッシュボードに表示されたログです。時刻、Pod名「open-liberty-0」、Project名「open-liberty」が付加されています。
LogDNAダッシュボード
May 28 21:04:36 open-liberty-0 open-liberty Launching defaultServer (Open Liberty 21.0.0.4/wlp-1.0.51.cl210420210407-0944) on Eclipse OpenJ9 VM, version 11.0.10+9 (en_US)
May 28 21:04:36 open-liberty-0 open-liberty [AUDIT ] CWWKE0001I: The server defaultServer has been launched.
May 28 21:04:40 open-liberty-0 open-liberty [AUDIT ] CWWKG0093A: Processing configuration drop-ins resource: /opt/ol/wlp/usr/servers/defaultServer/configDropins/defaults/keystore.xml
May 28 21:04:40 open-liberty-0 open-liberty [AUDIT ] CWWKG0093A: Processing configuration drop-ins resource: /opt/ol/wlp/usr/servers/defaultServer/configDropins/defaults/open-default-port.xml
May 28 21:04:41 open-liberty-0 open-liberty WARNING [WARNING ] CWWKS3103W: There are no users defined for the BasicRegistry configuration of ID com.ibm.ws.security.registry.basic.config[basic].
May 28 21:04:42 open-liberty-0 open-liberty [AUDIT ] CWWKZ0058I: Monitoring dropins for applications.
May 28 21:04:46 open-liberty-0 open-liberty [AUDIT ] CWWKS4104A: LTPA keys created in 3.423 seconds. LTPA key file: /opt/ol/wlp/output/defaultServer/resources/security/ltpa.keys
May 28 21:04:48 open-liberty-0 open-liberty [AUDIT ] CWWKF0012I: The server installed the following features: [appClientSupport-1.0, appSecurity-2.0, appSecurity-3.0, batch-1.0, beanValidation-2.0, cdi-2.0, concurrent-1.0, distributedMap-1.0, ejb-3.2, ejbHome-3.2, ejbLite-3.2, ejbPersistentTimer-3.2, ejbRemote-3.2, el-3.0, j2eeManagement-1.1, jacc-1.5, jaspic-1.1, javaMail-1.6, javaee-8.0, jaxb-2.2, jaxrs-2.1, jaxrsClient-2.1, jaxws-2.2, jca-1.7, jcaInboundSecurity-1.0, jdbc-4.2, jms-2.0, jndi-1.0, jpa-2.2, jpaContainer-2.2, jsf-2.3, jsonb-1.0, jsonp-1.1, jsp-2.3, managedBeans-1.0, mdb-3.2, servlet-4.0, ssl-1.0, wasJmsClient-2.0, wasJmsSecurity-1.0, wasJmsServer-1.0, webProfile-8.0, websocket-1.1].
May 28 21:04:48 open-liberty-0 open-liberty [AUDIT ] CWWKF0011I: The defaultServer server is ready to run a smarter planet. The defaultServer server started in 12.000 seconds.
May 28 21:04:50 open-liberty-0 open-liberty [AUDIT ] CWPKI0803A: SSL certificate created in 7.357 seconds. SSL key file: /opt/ol/wlp/output/defaultServer/resources/security/key.p12
May 28 21:04:51 open-liberty-0 open-liberty [AUDIT ] CWWKI0001I: The CORBA name server is now available at corbaloc:iiop:localhost:2809/NameService.