【てくさぽBLOG】IBM Cloud Pak for Applicationsを導入してみた（OpenShift導入編 － 手順詳細）

一覧に戻る

2020年09月

【てくさぽBLOG】IBM Cloud Pak for Applicationsを導入してみた（OpenShift導入編－手順詳細）

ブログ

IBM Cloud Pak for Applicationsの新規販売は終了いたしました。
今後のアプリケーションランタイムソリューションは、2021年1月15日に発表されたWebSphere Hybrid Editionとなります。

1.本記事について

本記事は「IBM Cloud Pak for Applicationsを導入してみた（OpenShift導入編）」の コマンドの詳細を掲載したものです。
本編をご覧頂きながら、詳しいコマンドや実行結果を本記事でご確認ください。

2. 事前準備

2-1. 作業用Linux環境準備

（１）Cent OSインストールとディレクトリ作成

今回はCent OS 7をインストールし、ルート配下に以下の3つのディレクトリを作成します。

/work 　　　※作業用スペース
/os42 　　　※OpenShift インストールプログラム置き場
/os42/conf ※yamlやjsonなどの設定ファイル置き場

（２）AWS CLIインストール

前提ソフトウェアを確認し、AWS CLI をインストール・設定します。

<前提バージョン（2.7または3.4以上）の python が導入されていることを確認します。>

# python –version
Python 3.6.8

<aws cliをインストールし、バージョンを確認します。>
rootユーザーで実行する場合の手順を行いました。

# curl “https://s3.amazonaws.com/aws-cli/awscli-bundle.zip” -o “awscli-bundle.zip”
# unzip awscli-bundle.zip
# export PATH=~/.local/bin:$PATH
# source ~/.bash_profile
# pip3 install awscli –upgrade –users
# aws –version
aws-cli/1.18.31 Python/3.6.8 Linux/4.18.0-147.5.1.el8_1.x86_64 botocore/1.15.31

<aws cli設定>

AWSアカウント情報・利用するリージョンを元にAWS CLIを設定します。

# aws configure
AWS Access Key ID: ※利用するAWSアカウントのAccess Keyを入力
AWS Secret Access Key: ※利用するAWSアカウントのSecret Access Keyを入力
Default region name [None]: ap-northeast-1
Default output format [None]: json

（３）jqパッケージのインストール

# yum -y install epel-release
# yum -y install jq

2-2. インターネットドメインの取得とRoute53への登録

＜インターネット上から OpenShift クラスターにアクセスするためにインターネットドメインを利用できるようにします。＞
今回は AWS Route53で独自ドメインを取得・登録しました。

インターネットドメイン名：example.com（仮称）

2-3. インストールファイルの取得

インストールに利用するファイルを用意します。

<作業用Linuxマシンにて、Red Hat OpenShift Cluster Manager サイトの「Infrastructure Provider」ページから「AWS」－「User-Provisioned Infrastructure」を選択し、（１）OpenShift installer と（２）Pull secret をダウンロードし “oc42ディレクトリ” に配置します。>

以下、配置後の確認結果です。

# ll
drwxr-xr-x. 2 root root 4096 3月 18 09:39 conf
-rw-r–r–. 1 root root 80468756 3月 16 10:18 openshift-install-linux-4.2.23.tar.gz
-rw-r–r–. 1 root root 2763 3月 4 13:15 pull-secret.txt

3. OpenShift 導入手順

3-1.AWS 環境構築

（１）SSH プライベートキーの生成およびエージェントへの追加

<作業用 Linuxマシン上で以下コマンドを実行し SSHキーを作成します。>

# ssh-keygen -t rsa -b 4096 -N ” -f ~/.ssh/id_rsa
Generating public/private rsa key pair.
Created directory ‘/root/.ssh’.
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:jyTeAdzo1xi7bZh7+EK+r6j7y5rVDT5Jus8U9JDX8vs root@rpa-20
The key’s randomart image is:
+—[RSA 4096]—-+
| |
| . o . . |
| + * o . |
| . o O o |
| o S o . |
| . X.& . |
| +o%.= . |
| + =++. . |
| ==*o*Bo E |
+—-[SHA256]—–+

<ssh-agent プロセスをバックグラウンドタスクとして開始します。>

# eval “$(ssh-agent -s)”
Agent pid 13552

<SSH プライベートキー（id_rsaファイル）を ssh-agent に追加します。>

# ssh-add ~/.ssh/id_rsa
Identity added: /root/.ssh/id_rsa (/root/.ssh/id_rsa)

（２）AWS のインストール設定ファイルの作成

<install-config.yaml ファイルを取得します。>
以下を実行すると install-config.yaml ファイルが作成されます。

# ./openshift-install create install-config –dir=/os42

プロンプト上で選択または入力

SSHキー：/root/.ssh/id_rsa ※”（１）SSH プライベートキーの生成およびエージェントへの追加”で作成したSSHキー
ターゲットプラットフォーム：aws
AWSアクセスキーID：　　※利用するAWSアカウントのAccess Keyを入力
AWSシークレットキー：　※利用するAWSアカウントのSecret Keyを入力
AWSリージョン：ap-northeast-1 (tokyo)
Route53のベースドメイン名：example.com　※AWS Route53に登録したドメイン名
クラスター名：nicptestcluster 　※任意の名前
Pull Secret：※”/os42/pull-secret.txt”の内容をコピー＆ペースト

※特に完了のメッセージは表示されませんのでご注意ください。

<install-config.yaml ファイルを編集し、コンピュートレプリカの数を 0 にします。>

#vi install-config.yaml

compute:
– hyperthreading: Enabled
name: worker
platform: {}
replicas: 3　←　ここを0に変更

<install-config.yaml ファイルはインストール実行時に消去されてしまうので、別名でバックアップしておきます。>

#cp install-config.yaml install-config.yaml.org

（３）インフラストラクチャー名の抽出

＊インストールプログラムが生成する Ignition 設定ファイルには、24時間が経過すると期限切れになる証明書が含まれます。

<クラスターの Kubernetes マニフェストを生成します。>

#./openshift-install create manifests –dir=/os42

<openshiftフォルダが作成されるのでフォルダ内を確認します。>

# ll openshift
-rw-r—–. 1 root root 219 3月 18 09:49 99_cloud-creds-secret.yaml
-rw-r—–. 1 root root 181 3月 18 09:49 99_kubeadmin-password-secret.yaml
-rw-r—–. 1 root root 1530 3月 18 09:49 99_openshift-cluster-api_master-machines-0.yaml
-rw-r—–. 1 root root 1530 3月 18 09:49 99_openshift-cluster-api_master-machines-1.yaml
-rw-r—–. 1 root root 1530 3月 18 09:49 99_openshift-cluster-api_master-machines-2.yaml
-rw-r—–. 1 root root 2713 3月 18 09:49 99_openshift-cluster-api_master-user-data-secret.yaml
-rw-r—–. 1 root root 2027 3月 18 09:49 99_openshift-cluster-api_worker-machineset-0.yaml
-rw-r—–. 1 root root 2027 3月 18 09:49 99_openshift-cluster-api_worker-machineset-1.yaml
-rw-r—–. 1 root root 2027 3月 18 09:49 99_openshift-cluster-api_worker-machineset-2.yaml
-rw-r—–. 1 root root 2713 3月 18 09:49 99_openshift-cluster-api_worker-user-data-secret.yaml
-rw-r—–. 1 root root 1207 3月 18 09:49 99_openshift-machineconfig_master.yaml
-rw-r—–. 1 root root 1207 3月 18 09:49 99_openshift-machineconfig_worker.yaml
-rw-r—–. 1 root root 222 3月 18 09:49 99_role-cloud-creds-secret-reader.yaml

<クラスターがコントロールプレーンマシンを自動的に生成するのを防ぐために、コントロールプレーンマシンを定義する Kubernetes マニフェストファイルを削除します。>

#rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml

<同様に、ワーカーマシンを定義する Kubernetes マニフェストファイルを削除します。>

#rm -f openshift/99_openshift-cluster-api_worker-machineset-*.yaml

</oc42/manifests/cluster-scheduler-02-config.yml を変更し、Pod がコントロールプレーンマシンにスケジュールされないようにします。>

# vi /oc42/manifests/cluster-scheduler-02-config.yml
“mastersSchedulable”パラメーターの値を False に設定、保存します。

<Ignition 設定ファイルを取得します。>

#./openshift-install create ignition-configs –dir=/os42

<コマンド実行後、作成されたファイル・ディレクトリを確認します。>

# ll
-rw-r–r–. 1 root root 706 3月 9 20:16 README.md
drwxr-x—. 2 root root 50 3月 18 09:52 auth　　←あることを確認
-rw-r—–. 1 root root 291635 3月 18 09:53 bootstrap.ign　←あることを確認
drwxr-xr-x. 2 root root 4096 3月 18 09:39 conf
-rw-r—–. 1 root root 4045 3月 18 09:49 install-config.yaml.org
-rw-r—–. 1 root root 1837 3月 18 09:52 master.ign　　←あることを確認
-rw-r—–. 1 root root 267 3月 18 09:53 metadata.json　←あることを確認
-rwxr-xr-x. 1 root root 323536416 3月 9 20:16 openshift-install
-rw-r–r–. 1 root root 80468756 3月 16 10:18 openshift-install-linux-4.2.23.tar.gz
-rw-r–r–. 1 root root 2763 3月 4 13:15 pull-secret.txt
-rw-r—–. 1 root root 1837 3月 18 09:52 worker.ign　←あることを確認

# ll auth/
-rw-r—–. 1 root root 23 3月 18 09:52 kubeadmin-password　←あることを確認
-rw-r—–. 1 root root 8972 3月 18 09:52 kubeconfig　←あることを確認

<インフラストラクチャー名を抽出します。>
Ignition 設定ファイルメタデータからインフラストラクチャー名を抽出・表示します。ここで事前に準備したjqコマンドが必要になるのですね。

# jq -r .infraID /os42/metadata.json
nicptestcluster-w8r8h　←インフラストラクチャー名が出力されることを確認

（４）AWS での VPC の作成

</os42/confディレクトリに以下のファイルを作成します。>
なお、これ以降の手順の中で作成した yamlファイル、jsonファイルともファイル名は任意です。

CloudFormation Template：”cf_newvpc.yaml”ファイル
CloudFormation Templateのパラメーター：”cf_newvpc.json”ファイル

＊cf_newvpc.yaml、cf_newvpc.jsonファイルの中身はRed Hatマニュアルページの”1.5.7. AWS での VPC の作成”に書かれている内容をコピー・アンド・ペーストします。今回はマニュアル記載の値のままで作成しました。

ParameterKey	ParameterValue	備考
VpcCidr	10.0.0.0/16	VPC の CIDR ブロック。
AvailabilityZoneCount	1	VPC をデプロイするAZの数
SubnetBits	12	各AZ内の各サブネットのサイズ

<VPC 作成の CloudFormation 展開コマンドを実行します。>
–stack-name の後のスタック名（以下のコマンドでは createvpc）は任意の名前です。
＊ここで本検証で初めて CloudFormation を実行しました。

（５）AWS でのネットワークおよび負荷分散コンポーネントの作成

<VPC作成時と同様に、マニュアルの該当ページの内容を含んだファイルをそれぞれ”/os42/conf”に配置します。>

CloudFormation Template：”cf_network.yaml”ファイル
CloudFormation Templateのパラメーター：”cf_network.json”ファイル

<cf_network.jsonファイルを編集します。>

ここがポイントです。
以下の cf_network.jsonファイル内の7つの ParameterKey に指定する ParameterValue を、これまで実行したコマンドや情報からの値に更新します。

ParameterKey	ParameterValue	備考
ClusterName	nicptestcluster	install-config.yaml ファイルを生成した時に入力したクラスター名
InfrastructureName	nicptestcluster-w8r8h	Ignition 設定ファイルから抽出したインフラストラクチャー名
HostedZoneId	ZMxxxxxxxxxxx	Route53 パブリックゾーン ID（事前にAWSコンソールで確認します）
HostedZoneName	example.com	nstall-config.yaml ファイルを生成した時に使用した Route53 ベースドメイン名
PublicSubnets	subnet-0306b9ca39a3a00bd	VPC の CloudFormation テンプレートの出力より
PrivateSubnets	subnet-0407cf93524961fb4	VPC の CloudFormation テンプレートの出力より
VpcId	vpc-00a56e4c475a50da8	VPC の CloudFormation テンプレートの出力より

<更新した cf_network.jsonファイルを用いて CloudFormation 展開コマンドを実行します。>

# aws cloudformation create-stack –stack-name createnetwork –template-body file:///os42/conf/cf_network.yaml –parameters file:///os42/conf/cf_network.json –capabilities CAPABILITY_NAMED_IAM

<出力を確認します。>

# aws cloudformation describe-stacks –stack-name createnetwork

ParameterKey	ParameterValue	備考
PrivateHostedZoneId	Z0xxxxxxxxxxxxxxxxxxxx	プライベート DNS のホストゾーン ID
ExternalApiLoadBalancerName	net/nicptestcluster-w8r8h-ext/9a604677bb972af0	外部 API ロードバランサーのフルネーム
InternalApiLoadBalancerName	net/nicptestcluster-w8r8h-int/a277ca3a4501369a	内部 API ロードバランサーのフルネーム
ApiServerDnsName	api-int.nicptestcluster. example.com	API サーバーのFQDN
RegisterNlbIpTargetsLambda	arn:aws:lambda:ap-northeast-1:359962000209:function:createnetwork-RegisterNlbIpTargets-1M2PEFJK0J2C3	これらのロードバランサーの登録/登録解除に役立つ Lambda ARN
ExternalApiTargetGroupArn	arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Exter-RH5R6UUT2ULX/80f9d95fe136b5e3	外部 API ターゲットグループの ARN
InternalApiTargetGroupArn	arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-B5IB5RST56XN/4cfdcc5ae595e3f9	内部 API ターゲットグループの ARN
InternalServiceTargetGroupArn	arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-NEZL8AMZ4W1X/5a6cce34822ca9dc	内部サービスターゲットグループの ARN

（６）AWS でのセキュリティーグループおよびロールの作成

<これまでと同様にマニュアルの該当ページの内容を含んだファイルをそれぞれ”/os42/conf”に配置します。>

CloudFormation Templateのパラメーター：”cf_security.json”ファイル
CloudFormation Template：”cf_security.yaml”ファイル

<cf_security.jsonファイルを編集します。>
以下の4箇所のParameterValueに値をセットします。

ParameterKey	ParameterValue	備考
InfrastructureName	nicptestcluster-w8r8h	Ignition 設定ファイルから抽出したインフラストラクチャー名
VpcCidr	10.0.0.0/16	VPCのサブネットアドレス値
PrivateSubnets	subnet-0407cf93524961fb4	VPC の CloudFormation テンプレートの出力より
VpcId	vpc-00a56e4c475a50da8	VPC の CloudFormation テンプレートの出力より

<CloudFormation展開コマンドを実行します。>

# aws cloudformation create-stack –stack-name createsecurity –template-body file:///os42/conf/cf_security.yaml –parameters file:///os42/conf/cf_security.json –capabilities CAPABILITY_NAMED_IAM

<出力を確認します。>

# aws cloudformation describe-stacks –stack-name createsecurity

ParameterKey	ParameterValue	備考
MasterSecurityGroupId	sg-0ca008469442d0702	マスターセキュリティーグループ ID
WorkerSecurityGroupId	sg-0fcaab02eeb63b716	ワーカーセキュリティーグループ ID
MasterInstanceProfile	createsecurity-MasterInstanceProfile-JAFR521FJOOL	マスター IAM インスタンスプロファイル
WorkerInstanceProfile	createsecurity-WorkerInstanceProfile-1320LLA579623	ワーカー IAM インスタンスプロファイル

（７）AWS インフラストラクチャーの RHCOS AMI

<利用するRHCOS AMIのAWSゾーンとAWS AMIをマニュアルページの”1.5.10. AWS インフラストラクチャーの RHCOS AMI”にて確認します。>
今回は aws configure でも指定した ap-northeast-1 ですので、該当ゾーンの AWS AMI を確認します。

AWSゾーン：ap-northeast-1
AWS AMI：ami-0426ca3481a088c7b

3-2. OpenShift導入

（１）Bootstrapノード作成

OpenShiftクラスターの初期化で使用するBootstrapノードをAWS上に作成します。

<Ignition 設定ファイルを S3バケットに配置します。>

まずS3バケットを作成します

# aws s3 mb s3://nicptestcluster-infra

続いてIgnition 設定ファイル（bootstrap.ign ）をS3バケットにアップロードします。

# aws s3 cp bootstrap.ign s3://nicptestcluster-infra/bootstrap.ign

最後にファイルがアップロードされたことを確認します。

# aws s3 ls s3://nicptestcluster-infra/
2020-03-27 10:08:33 291635 bootstrap.ign

</os42/confディレクトリに以下のファイルを作成します。>

CloudFormation Template：”cf_bootstrap.yaml”ファイル
CloudFormation Templateのパラメーター：”cf_bootstrap.json”ファイル

<cf_bootstrap.jsonファイルを編集します。>

ParameterKey	ParameterValue	備考
InfrastructureName	nicptestcluster-w8r8h	Ignition 設定ファイルから抽出したインフラストラクチャー名
RhcosAmi	ami-0426ca3481a088c7b	確認したAWS AMI
AllowedBootstrapSshCidr	0.0.0.0/0	デフォルトのまま
PublicSubnet	subnet-0306b9ca39a3a00bd	VPC の CloudFormation テンプレートの出力より
MasterSecurityGroupId	sg-0ca008469442d0702	セキュリティーグループおよびロールの CloudFormation テンプレートの出力より
VpcId	vpc-00a56e4c475a50da8	VPC の CloudFormation テンプレートの出力より
BootstrapIgnitionLocation	s3://nicptestcluster-infra/bootstrap.ign	ブートストラップファイルの場所
AutoRegisterELB	yes	ネットワークロードバランサー (NLB) を登録するかどうか
RegisterNlbIpTargetsLambdaArn	arn:aws:lambda:ap-northeast-1:359962000209:function:createnetwork-RegisterNlbIpTargets-1M2PEFJK0J2C3	ネットワークのCloudFormationテンプレートの出力より
ExternalApiTargetGroupArn	arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Exter-RH5R6UUT2ULX/80f9d95fe136b5e3	ネットワークのCloudFormationテンプレートの出力より
InternalApiTargetGroupArn	arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-B5IB5RST56XN/4cfdcc5ae595e3f9	ネットワークのCloudFormationテンプレートの出力より
InternalServiceTargetGroupArn	arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-NEZL8AMZ4W1X/5a6cce34822ca9dc	ネットワークのCloudFormationテンプレートの出力より

<CloudFormation 展開コマンドを実行します。>

# aws cloudformation create-stack –stack-name bootstrap –template-body file:///os42/conf/cf_bootstrap.yaml –parameters file:///os42/conf/cf_bootstrap.json –capabilities CAPABILITY_NAMED_IAM

<出力を確認します。>

# aws cloudformation describe-stacks –stack-name bootstrap

ParameterKey	ParameterValue	備考
BootstrapInstanceId	i-0a68a104e8a04ae08	Bootstrapインスタンス ID
BootstrapPublicIp	13.112.188.xxx	Bootstrapノードのパブリック IP アドレス
BootstrapPrivateIp	10.0.0.xxx	Bootstrapのプライベート IP アドレス

（２）コントロールプレーン（Masterノード）の作成

</os42/confディレクトリに以下のファイルを作成します。>

CloudFormation Template：”cf_controlplane.yaml”ファイル
CloudFormation Templateのパラメーター：”cf_controlplane.json”ファイル

<cf_controlplane.jsonファイルを編集します。>

ParameterKey	ParameterValue	備考
InfrastructureName	nicptestcluster-w8r8h	Ignition 設定ファイルから抽出したインフラストラクチャー名
RhcosAmi	ami-0426ca3481a088c7b	確認したAWS AMI
AutoRegisterDNS	yes	yesまたはno
PrivateHostedZoneId	Z0xxxxxxxxxxxxxxxxxxxx	ネットワークのCloudFormationテンプレートの出力より
Master0Subnet	subnet-0407cf93524961fb4	VPC の CloudFormation テンプレートの出力より
Master1Subnet	subnet-0407cf93524961fb4	VPC の CloudFormation テンプレートの出力より
Master2Subnet	subnet-0407cf93524961fb4	VPC の CloudFormation テンプレートの出力より
MasterSecurityGroupId	sg-0ca008469442d0702	セキュリティーグループおよびロールの CloudFormation テンプレートより
IgnitionLocation	https://api-int.nicptestcluster.example.com:22623/ config/master	生成される Ignition 設定ファイルの場所を指定
CertificateAuthorities	data:text/plain;charset=utf-8;base64,LS0tLS1・・・	インストールディレクトリーにあるmasiter.ignファイルから値を指定
MasterInstanceProfileName”	createsecurity-MasterInstanceProfile-JAFR521FJOOL	セキュリティーグループおよびロールの CloudFormation テンプレートより
MasterInstanceType	m5.xlarge	利用するEC2インスタンスタイプを指定
AutoRegisterELB	yes	yesまたはno
RegisterNlbIpTargetsLambdaArn	arn:aws:lambda:ap-northeast-1:359962000209:function:createnetwork-RegisterNlbIpTargets-1M2PEFJK0J2C3	ネットワークのCloudFormationテンプレートの出力より
ExternalApiTargetGroupArn	arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Exter-RH5R6UUT2ULX/80f9d95fe136b5e3	ネットワークのCloudFormationテンプレートの出力より
InternalApiTargetGroupArn	arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-B5IB5RST56XN/4cfdcc5ae595e3f9	ネットワークのCloudFormationテンプレートの出力より
InternalServiceTargetGroupArn	arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-NEZL8AMZ4W1X/5a6cce34822ca9dc	ネットワークのCloudFormationテンプレートの出力より

<今回、”MasterInstanceType” に m5 インスタンスタイプを指定するので、そのインスタンスタイプを cf_controlplane.yaml ファイルの MasterInstanceType.AllowedValues パラメーターに追加します。>

途中、省略

MasterInstanceType:
Default: m4.xlarge
Type: String
AllowedValues:
– “m4.xlarge”
– “m4.2xlarge”
– “m4.4xlarge”
– “m4.8xlarge”
– “m4.10xlarge”
– “m4.16xlarge”
– “m5.xlarge”　←追加
– “m5.2xlarge”　←追加
– “m5.4xlarge”　←追加
– “m5.8xlarge”　←追加

以下、省略

<CloudFormation 展開コマンドを実行します。>

# aws cloudformation create-stack –stack-name controlplane –template-body file:///os42/conf/cf_controlplane.yaml –parameters file:///os42/conf/cf_controlplane.json

<状況を確認します。>

# aws cloudformation describe-stacks –stack-name controlplane

（３）Workerノードの作成

※CloudFormation テンプレートは、1 つのWorkerマシンを表すスタックを作成します。今回はWorkerノードを2台作成するので、それぞれのWorkerマシンにスタックを作成する必要があります。

</os42/confディレクトリに以下のファイルを作成します。>

CloudFormation Template：”cf_worker.yaml”ファイル
CloudFormation Templateのパラメーター：”cf_worker.json”ファイル

<cf_worker.jsonファイルを編集します。>

ParameterKey	ParameterValue	備考
InfrastructureName	nicptestcluster-w8r8h	Ignition 設定ファイルから抽出したインフラストラクチャー名
RhcosAmi	ami-0426ca3481a088c7b	確認したAWS AMI
Subnet	subnet-0407cf93524961fb4	VPC の CloudFormation テンプレートの出力より
WorkerSecurityGroupId	sg-0fcaab02eeb63b716	セキュリティーグループおよびロールの CloudFormation テンプレートより
IgnitionLocation	https://api-int.nicptestcluster.example.com:22623/ config/worker	生成される Ignition 設定ファイルの場所を指定
CertificateAuthorities	data:text/plain;charset=utf-8;base64,LS0tLS1・・・	インストールディレクトリーにあるworker.ignファイルから値を指定
WorkerInstanceProfileName	createsecurity-WorkerInstanceProfile-1320LLA579623	セキュリティーグループおよびロールの CloudFormation テンプレートより
WorkerInstanceType	m5.xlarge	利用するEC2インスタンスタイプを指定

<cf_controlplane.yamlと同様に、”MasterInstanceType” に m5 インスタンスタイプを指定するので、そのインスタンスタイプを cf_worker.yaml ファイルの MasterInstanceType.AllowedValues パラメーターに追加します。>

CloudFormation 展開コマンドを実行。
今回ワーカーノードは2台作成するので、stack-name を「worker1」「worker2 」と分けて2回実行します。

# aws cloudformation create-stack –stack-name worker1 –template-body file:///os42/conf/cf_worker.yaml –parameters file:///os42/conf/cf_worker.json
# aws cloudformation create-stack –stack-name worker2 –template-body file:///os42/conf/cf_worker.yaml –parameters file:///os42/conf/cf_worker.json

<出力を確認します。>

# aws cloudformation describe-stacks –stack-name worker1
# aws cloudformation describe-stacks –stack-name worker2

（４）Bootstrapノードの初期化

<Bootstrapノードの初期化コマンドを実行し、FATAL エラーなどが出ずに終了することを確認します。>

# ./openshift-install wait-for bootstrap-complete –dir=/os442 –log-level=info
INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443…
INFO API v1.14.6-152-g117ba1f up
INFO Waiting up to 30m0s for bootstrapping to complete…
INFO It is now safe to remove the bootstrap resources

（５）CLI のインストール

<CLIツールの展開 – ダウンロードした圧縮ファイルを展開します。>

※OS42ディレクトリにダウンロードしたファイルをコピーし、展開します。
# cp tar xvf openshift-client-linux-4.2.23.tar.gz /os42/tar xvf openshift-client-linux-4.2.23.tar.gz
# tar xvf openshift-client-linux-4.2.23.tar.gz
※パスに/oc42を追加します。
# export PATH=”$PATH:/os42″
※ocコマンドのテスト
# oc help

（６）クラスターへのログイン

※kubeadmin 認証情報をエクスポートします。
# export KUBECONFIG=/os42/auth/kubeconfig
※oc コマンドを正常に実行できることを確認
# oc whoami
system:admin

（７）マシンの CSR の承認

<クラスターがマシンを認識していること（今回Masterノード3台、Workerノード2台が表示されること）を確認します。>

# oc get nodes
NAME 　　　　　　　　　　　　　　　　　　STATUS 　ROLES 　AGE 　　VERSION
ip-10-0-48-xxx.ap-northeast-1.compute.internal Ready 　　worker 　57s 　　v1.14.6+8fc50dea9
ip-10-0-49-xxx.ap-northeast-1.compute.internal Ready 　　　worker 　42m 　v1.14.6+8fc50dea9
ip-10-0-50-xxx.ap-northeast-1.compute.internal Ready 　　　master 　22h 　v1.14.6+8fc50dea9
ip-10-0-58-xxx.ap-northeast-1.compute.internal Ready 　　　master 　22h 　v1.14.6+8fc50dea9
ip-10-0-59-xxx.ap-northeast-1.compute.internal Ready　　　 master 　22h 　v1.14.6+8fc50dea9

（８）Operator の初期設定

5秒ごとに実行される oc get clusteroperators の結果をモニタリングし、クラスターコンポーネントがオンラインになることを確認します。

<”Available” が ”True”、”DEGRADED” 列が ”False” になることを確認します。>

# watch -n5 oc get clusteroperators
NAME 　　　　　VERSION 　AVAILABLE 　PROGRESSING 　DEGRADED 　SINCE
authentication 　　4.2.23 　　True 　　　　　False 　　　　　　False 　　　　44m
cloud-credential 　4.2.23　　 True 　　　　　False 　　　　　　False 　　　　22h
cluster-autoscaler 4.2.23 　　True 　　　　　False 　　　　　　False 　　　　22h
console 　　　　　4.2.23 　　True 　　　　　False 　　　　　　False 　　　　46m
dns 　　　　　　　4.2.23　　 True 　　　　　False 　　　　　　False 　　　　22h
image-registry 　　4.2.23 　　True 　　　　　False 　　　　　　False 　　　　50m
ingress 　　　　　4.2.23 　　True 　　　　　False 　　　　　　False 　　　　50m
・
・
以下、省略

本検証では、（７）マシンの CSR の承認の手順で全ノードが Ready となった後に確認するとすべての Operator コンポーネントがオンライン（AVAILABLE 列が True）になっていましたが、image-registry Operator がオフライン（AVAILABLE 列が False）である場合はマニュアルページの「1.5.17.1. イメージレジストリーストレージの設定」の章をご確認ください。

（９）Bootstrapノードの削除

クラスターの初期 Operator 設定を完了した後に Bootstrapリソースを削除します。

<CloudFormation コマンドで”（１）Bootstrapノード作成”手順で作ったbootstrap という名前の Stack を削除します。>
これにより、ブートストラップノードが削除されます。

# aws cloudformation delete-stack –stack-name bootstrap

（１０）クラスターのインストールを完了

<クラスターのインストール完了を確認します。>
以下のコマンドでインストール状況をモニターします。

#./openshift-install –dir=/os42 wait-for install-complete

（中略）

INFO Install complete!
INFO To access the cluster as the system:admin user when using ‘oc’, run ‘export KUBECONFIG=/os42/auth/kubeconfig’
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.nicptestcluster.example.com
INFO Login to the console with user: kubeadmin, password: XXXXX

上記のように ”Install complete!” となり、「コンソールのURL」「ユーザー名」「パスワード」が表示されればインストール完了で OpenShift 環境が利用可能となります。

！！重要！！

インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになる証明書が含まれます。
Ignition ファイルは 24 時間有効であるため、この時間内に OpenShift デプロイメントを実行する必要があります。作成から24時間過ぎた場合はIgnition ファイルを再生成する必要があります。

<動作確認 – OpenShiftのコンソールにアクセスします。>

Webコンソールの場合：
https://console-openshift-console.apps.nicptestcluster.example.com
CLI の場合：
oc login -u kubeadmin -p XXXXX https://api.nicptestcluster.example.com:6443

以上で OpenShift インストールは完了となります。

お問い合わせ

この記事に関するご質問は下記までご連絡ください。

エヌアイシー・パートナーズ株式会社
技術支援本部
E-Mail：nicp_support@NIandC.co.jp

2025年06月11日

大阪・関西万博の「Better Co-Being」パビリオンを支える IBM Power

公開日：2025-06-11 こんにちは、ソリューション企画部の久田です。 2025年大阪・関西万博のテーマは「いのち輝く未来社会のデザイン」です。技術、デザイン、人間性の調和を通じて、未来の課題を解決するための多彩な展示が展開されています。その中でも特に注目を集めているのが、シグネチャーパビリオン「Better Co-Being」。このパビリオンでは「共鳴」をテーマに、人と人、人と自然がつながる感覚を来場者に提供し、未来社会のビジョンを感じられる展示が行われています。この体験を支えるのが、IBM Powerの高度な技術です。「Better Co-Being」パビリオンの舞台裏を、最先端技術がしっかりと支えています。私は実際にこの「Better Co-Being」パビリオンを訪れ、未来的なデザインや「共鳴」をテーマにした体験に大きな感動を覚えました。このブログでは、私が体験した「Better Co-Being」の仕組みやその意義について、詳しくご紹介します。 (さらに…)

ブログ

2025年06月09日

安定の裏に潜む意外な悩み？HCLに聞く「HCL Domino」のバージョンアップにおける課題と意義（後編）

Domino が誕生してから35年以上が経過し、IBM から HCL に移管されて丸６年が経ちました。 Domino は、高い開発生産性と堅牢性を兼ね備えたアプリケーション基盤で、長きにわたり企業の業務効率化を支えてきた歴史ある製品です。一方、重ねてきた実績の分だけ、バージョンアップに対する課題も垣間見えます。今回は、エイチシーエル・ジャパン株式会社 HCLSoftware のテクニカルリードである松浦光様に HCL Domino のビジネス状況や今後の展開など、多岐にわたり話を伺いました。（本ページは後半です［前半も公開中］）対談者【ゲスト】エイチシーエル・ジャパン株式会社 HCLSoftware テクニカルリード松浦光様【インタビュアー】エヌアイシー・パートナーズ株式会社技術企画本部ソリューション企画部松田秀幸 ※対談者情報は2025年6月9日時点新バージョン V14.5 が刻む新たな一歩生成AI を Domino の中に ── この夏に新バージョンの出荷が予定されていますね。松浦：はい、2025年6月にバージョン V14.5 の出荷が予定されています。 ── V14.5 のポイントは何でしょうか？松浦：目玉の１つとして、Domino の中に AI を持つ「Domino IQ」という機能がリリースされます。なぜ、わざわざ自社で生成AI を持たなければいけないか、と思われる方もいると思いますが、理由の１つはセキュリティです。 Domino と生成AI の統合「Domino IQ」自社のベストプラクティスを得られる ── 「Domino IQ」は、どのようなものでしょうか？松浦：完全にローカルで生成AI を持つことで、機密度が高い自社の情報についても問い合わせできるようになります。加えて、自社の Domino を20～30年使い続けているお客様は結構多く、その積み重ねた情報に注目しています。そこで、今まで溜め込んだナレッジを生成AI に教え込み、ベテランの方が持つナレッジや自社のベストプラクティスを回答する生成AI を作っていく流れですね。このような利用も考えて、Domino IQ を開発しています。 ── 生成AI のモデルは、HCL で作っているのですか。松浦： HCL で開発しているわけではなく、オープンソースの LLM を使っています。今ベータ版で使えるのは、Meta社の Llama3.2 などです。ゼロから HCL で作ったものではなく、もう既に賢く育てられた LLM を使える点が大きな強みの１つだと思います。RAG を使って LLM に足りない情報を学習させられるようになるので、自社のデータベースで蓄えていた情報を AI が活用できるようになります。 Domino による生成AI の活用方法 ── RAG による拡張はキーになりそうですね。松浦： Domino に溜まっている色々な情報やデータを社外や国外の生成AI に出さなくても、Domino IQ で新しい使い方が可能です。 ── Domino と生成AI の組み合わせで業務効率も向上しそうですね。松浦： Domino は、業界用語や社内用語なども扱える『生き字引き』のような人に代わる存在になっていき、皆さんの業務を支えられるのではないかと考えています。 REST API による効率的なシステム間の連携 ── フロントエンドの作り込みはどうでしょうか。例えば、チャットボット以外の入口を作る必要はありますか？松浦：フロントエンドは何でもいいと考えていて、様々な Web やモバイルアプリに組み込むこともできますし、Notesクライアントが好きであれば Notesクライアントでもいいですし、Nomad Web でもいいと思います。Nomad Mobile というスマホやタブレット向けの Notesクライアント相当のものもあるので、それを使ってもいいですね。 ── 他社システムとの連携はどうでしょうか？松浦：前半でも少し触れたディレクトリサービスの連携だけではなく、REST API で他社システムと繋ぐことも想定しています。例えばフロントエンドとしては、チャットボットはもちろん、それ以外にも様々なシステムから入力してもらうこともできます。 Domino IQ 用に設定された Domino Server は、Dbserver プロセスから推論エンジンを起動する。（画像クリックで拡大）（出典：HCL Software｜Configuring / Configuring users and servers / Domino IQ）松浦：オープンソースの LLM を Dominoサーバーのデータディレクトリの下にインストールし、アプリケーションからの参照は、簡単な Lotus Script の読み込み・書き込みという２つのメソッドで問い合わせる仕様です。先程も触れましたが、既存の LLM を使える点は大きな強みだと思います。バージョンアップの鍵は互換性の安心感新旧バージョンの互換性は移行チェックツールで担保する ── 互換性を気にされる方が多いと思いますが、いかがでしょうか？松浦： 12.0.1 については 64bit対応、Open Java への変更があり、10 から 14 のタイミングで足回りをアップデートしました。その対応も含めて確認したところ、アプリケーションの互換性に関しては問題はありませんでした。それでも互換性に懸念をお持ちのお客様には、NotesConsortium（ノーツコンソーシアム）で会員特典として利用できる移行チェックツールの使用も検討していただきたいと思います。 NotesConsortium（ノーツコンソーシアム） Domino に関する様々な知識やノウハウを交換、蓄積して会員同志で共有するユーザーコミュニティ引用以前のバージョンの環境で動作していたプリケーションの互換性（＠関数/LotusScriptのみ）をチェックするツール、アプリケーションコードチェッカー（NDACC）をご提供しています。カンタン移行判定ツールもご利用頂けます。引用元：NotesConsortium「会員の特典」｜移行支援ツールの提供移行チェックツールとその効果 ── 実際に 9、10 から、V14、V14.5 へのバージョンアップは、移行チェックツールで試した場合の非互換はどれぐらいでしょうか。松浦：非互換はほとんどありません。一言で非互換といっても、インパクトの程度は異なります。少し見た目が変わってしまうといった軽微なものから、挙動が変わってしまうという大きなものまであります。移行チェックツールも過去20年以上の歴史があり、インパクトが小さい内容もチェックする仕組みでしたが、今はインパクトが小さい内容はチェックから外せるようになりました。 ── 非互換性の影響が少なく、迅速かつ正確な対応が可能であれば、安心してバージョンアップできますね。松浦：もちろんインパクトの大小に関わらずチェックすることもできるので、気になる方は互換性に関するすべての内容を把握できます。すべてを確認していただいても、大きな影響を及ぼすような非互換はほとんどないと思います。バージョンアップ vs 他社製品への移行バージョンアップはしないが、移行もしない ── 前半にも話があったとおり、Domino の旧バージョンを利用されているお客様は多いようですね。松浦：はい、旧バージョンのまま利用されているお客様も多いです。やはり、「バージョンアップをしなくても現状で満足」というのが理由だと思います。 ── 一方で Domino から別製品への移行を検討されるお客様の声も聞きます。他製品への移行が検討される理由についてはいかがでしょうか。松浦： DX を旗印に企業の形を大きく変えたいと思われた時に、エンドユーザーが日々使う情報系システムを刷新するのは象徴的だと思います。特に社外から新しい CIO が来たという様なケースだと顕著です。引用 DX推進の際の障壁としては、「投資するための予算確保が少ない」が最も多くなっており、今後DXをさらに推進していく上で、約4割が「IT投資にかかる予算の増加」に取り組みたいと回答しました。引用元：一般社団法人中小企業個人情報セキュリティー推進協会「アンケート調査レポート」｜「DX推進に成功している経営者」の実態調査アンケートの結果について ── DX の観点はひとつの肝かもしれませんね。松浦： Web対応やモバイル対応、AI対応への再投資に対して、もっと価値を出していけるのではないかと考えています。 ── ただ、基幹的な情報系システムだと、気軽に移行するわけにはいかないですよね。松浦：他社ツールへのスイッチングコストの中には教育費を含め色々なものが発生するので、それだけお金をかける価値があるのかということに悩みながら検討されていると感じます。やはりコストが大きいということで、移行ではなく共存で落ち着くことがかなり多いですね。 HCL Domino の運用事例内製化で自社の強みを生かしたDXを実践（日経XTECH） 20年で培ったデジタルカイゼンの文化エームサービスの現場とIT部門をつなぐNotes（ZDNET Japan）結論！バージョンアップが最適解 ── 他社製品への移行リスクや未知のコストも考えると、Domino を利用し続けるのがよさそうですね。松浦：異なる基盤でも併用して共存でき、互換性も担保されているので最新バージョンアップでの利用をお勧めします。 ── ここまでの話以外で、他社製品への移行が検討される理由はありますか？松浦：お客様から、Notesクライアントの強力な機能は変わらずご評価いただきながらも、そのインストールやセットアップなどの運用管理はやはり大変だ、という声もいただいております。 ── 最新バージョンでも同様でしょうか？松浦：最新バージョンでは改善されています。具体的には、V14 ではブラウザベースで Notesクライアントとほぼ同じようなことができる「HCL Nomad」という機能があります。特長は、専用Notesクライアントのインストールが必要ない点と、ブラウザベースなので複数の端末から使っていただける点です。 ── 「今までNotesクライアントでしかできなかったことが、Web でもできるようになる」ということでしょうか？松浦：例えば、Excelマクロを使った帳票の集計業務などですね。これまでは、Notesクライアント内でオフィス系のアプリケーションを起動するようなものは、ブラウザのセキュリティ制限によりブラウザからの利用ができませんでした。しかし、2025年6月に出る新バージョン V14.5 は「HCL Nomad Web」が COM をサポートするのが目玉機能の１つで、Nomad Web から Excel や Word や PowerPoint を起動してマクロ実行などができるようになります。 ── V14.5 における進化の１つですね。松浦：はい、バージョンアップの利点ともいえます。すでに、以前から使用されているお客様がトライアルを始めているという状況です。バージョンアップを推奨する理由新旧バージョンの互換性を担保している。コミュニケーション基盤が別製品でも、Domino を併用できる。 Domino IQ の実装／HCL Nomad Web の COMサポート HCL Domino について問い合わせる今後の戦略 V14.5 は描いたロードマップの答え合わせになるバージョン ── 今後の HCL の Domino のロードマップ、戦略はどのようになっているでしょうか。松浦：この夏に出荷予定の V14.5 では実行環境のアップデートやスマホ・Web対応の進化や生成AI連携など、HCL になってから大きく描いたロードマップの答え合わせになるバージョンです。アプリケーションを作り、うまく使ってもらうというのが、Domino の軸になっていると思います。Notesクライアントで動くアプリケーションから Webブラウザやモバイルで動くアプリケーションまで、様々なものがあります。それらを支えていくというのが Domino の DNA です。 ── 確固たる理念と設計思想があるのですね。支えるためには、Web対応や生成AI連携なども見越した拡張性も重要だと。松浦：作成したアプリケーションを拡張していくという方向性として API連携が挙げられます。Domino だけで全ての業務が回るとは考えていないので、周辺の製品サービスとの連携が簡単にできるというのがポイントの1つです。兄弟製品に繋げる二段構えの展開 ── バージョンアップ以外での、ビジネス戦略は何かありますか？松浦：アーキテクチャは異なりますが、開発環境の観点も含めれば兄弟製品といえるものがあります。例えば Volt MX という製品には、モバイルOS を含む様々なプラットフォームのネイティブアプリケーションを作る機能があり、単一の開発環境で作成できます。 ── 開発するアプリケーションによって、戦略の幅が広がりますね。松浦： Volt MX は一例ですが、プラットフォームを問わず使っていただけるような本格的なアプリケーションについては兄弟製品に繋げていく、という二段構えの戦略を考えています。 ── 兄弟製品への横展開…Domino が秘めるビジネスの可能性といえそうですね。松浦：今後のロードマップは、我々が描いた V14.5 の評価をユーザーから得ながらアプリケーションの軸はぶらさずに兄弟製品と補完しながら作っていく予定です。 ── Volt MX 以外に、どのような兄弟製品がありますか？松浦： Nomad Web Designer、Domino Leap という製品があり、どちらもブラウザで動きます。 Domino Leap は、エンドユーザー様が『ITの専門知識を必要とせずに簡単にアプリケーションを作成したい』というローコードの需要を補完できるツールとして位置づけています。 Nomad Web Designer は今まで Windows PC でしか提供されなかった Domino Designer を MacOS でも同じように使えるようにしたイメージです。 ── いくつもの製品があり今後の展開も楽しみですが、まずは V14.5 からですね。松浦：旧バージョンをご利用中のお客様においては、まず他社製品との連携までかと思っています。今は塩漬けの状態で、Domino の中だけで流通している情報があると思うので、それを他のシステムにも流通させてもらいたいですね。１つの製品内だけでは情報の流れが停滞することもあると思います。業務の活性化のためにも、他社製品やAIとうまく連携し Domino を『情報の流れを淀ませないような解決策』という位置づけに持っていきたいという思いもあります。 HCL 様からのメッセージ過去にとらわれない新たな事例でアプローチ ── 長年 Domino を販売されているパートナー様に、特にお伝えしたいことはありますか。松浦： HCL に移ってから使っていただいてるお客様から、「色々なツールを使っているが、やはり Domino は凄く良い製品だよね」という声をいただくことがとても増えている気がします。お客様がやりたいことに耳を傾けると、今までにない新しい使い方もどんどん出てきます。弊社サイトで公開しているお客様事例にも掲載しているので、Domino を長らく販売していただいているパートナー様はもちろん、Domino の販売に興味をお持ちの企業様にも、ぜひご覧いただければ嬉しいです。 Domino はかゆいところに手が届く業務アプリを作るには最適なツールだと思うので、そこを強みとしてどんどんビジネスを仕掛けて欲しいと思っています。インフラの観点においても、堅牢でパフォーマンスのいい製品に仕上がっていますし、他の SaaS製品との連携も充実しているので、「今までの Domino ってこうだよね」という枠の中だけで考えずに販売していただきたいと思います。 V14.x を避けて V12 にする意味はない ── では最後に、Dominoユーザー様、パートナー様へのメッセージをお願いします。松浦： Domino に限らず、バージョンアップの際は『どのバージョンにするか』を迷われるケースがよくあります。今回のバージョンアップは V14.5 と刻まれたバージョンなので、V14 や V12 という実績があるバージョンを検討したいと思われるお客様もいるかと思いますが、この度 V14.0 の非互換検査をしたところ、12.0.1以上であればアップデートされたプラットフォームとして動作が変わらないことが分かりました。つまり、『14.5 もしくは 14 を避けて V12 にする意味はない』ということなので、ぜひ最新バージョンを検討していただきたいと思います。 14.5 も新機能を使わなければ 14 と同じような挙動なので、保守期間が残っている新バージョンを使っていただいて、興味のある新機能にトライしていただくのが良いのかなと考えています。 ── 本日はありがとうございました。 HCL Domino について問い合わせるまとめここまで HCL Domino の新バージョンや今後の展開など、多岐にわたり HCLSoftware 松浦様にお伺いしてきました。最後に、前半の話を含め HCL Domino の特長となる強みとバージョンアップを推奨する理由をまとめます。 HCL Domino の強み高い開発生産性と堅牢性簡潔で迅速なアプリケーションの開発。長期的に使用されることに適した、運用の安定性。優れた互換性と柔軟性チェックツールにより、新旧バージョンの互換性を担保している。古いバージョンのデータやアプリケーションも最新バージョンで動作可能。コミュニケーション基盤が別製品でも、Domino を併用できる。新バージョン V14.5 の新機能「Domino IQ」セキュリティを確保しながら自社データを活用した生成AI の活用が可能。過去のナレッジを活用し、業務改善を支援。 Domino の現状とバージョンアップを推奨する理由 Domino の現状 Domino は35年以上にわたり利用されている製品で、現在も市場は活況。ユーザー数は多く、旧バージョンのまま利用される「塩漬け運用」も多い。バージョンアップを推奨する理由サポートが終了したテクノロジーへの脆弱性対応として必要。新旧バージョンの互換性を担保している。 Domino は他社製品との共存が可能。新バージョンは V14.5で、新たな機能が追加された。（本ページは後半です［前半も公開中］） HCL Domino について問い合わせるこのページを見ている人におすすめのページ安定の裏に潜む意外な悩み？HCLに聞く「HCL Domino」のバージョンアップにおける課題と意義（前編） HCL Domino 製品紹介ページ Com-PASS Cloud｜Domino Notes アプリのお預かりサービス .recommend-list{ margin-top: 0px; } ol.recommend-list li { color: #9b9b9b; } #recommend{ font-family: "Noto Sans Japanese"; font-size: 16px; font-weight: 700; color: #9b9b9b; border: none; padding: 0; margin-bottom: 10px; } .highlighter { background: linear-gradient(transparent 50%, #ffff52 90% 90%, transparent 90%); } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .btn_A{ height:30px; } .btn_A a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; } .interviewee { font-weight: bold; } figcaption { color: #7c7f78; font-size: smaller; } #box03 { position: relative; margin: 4em 0; padding: 0.5em 1em; border: solid 3px #95ccff; border-radius: 8px; } #box03 .box-title { position: absolute; display: inline-block; top: -13px; left: 10px; padding: 0 9px; line-height: 1; font-size: 19px; background: #FFF; color: #95ccff; font-weight: bold; } #box03 p { margin: 5px; padding: 0; font-weight: bold; } #box04 { position: relative; margin: 4em 0 0 0; padding: 0.5em 1em; border: solid 3px #62c1ce; } #box04 .box-title { position: absolute; display: inline-block; top: -27px; left: -3px; padding: 0 9px; height: 25px; line-height: 25px; font-size: 17px; background: #62c1ce; color: #ffffff; font-weight: bold; border-radius: 5px 5px 0 0; } #box04 p { margin: 0; padding: 0; } #box_blockquote { position: relative; margin: 4em 0; padding: 0.5em 1em; border: solid 3px #8d8d8d; } #box_blockquote .box-title { position: absolute; display: inline-block; top: -27px; left: -3px; padding: 0 9px; height: 25px; line-height: 25px; font-size: 17px; background: #8d8d8d; color: #ffffff; font-weight: bold; border-radius: 5px 5px 0 0; } #box_blockquote p { margin: 0; padding: 0; } .memo{ color:#53851b ; background-color: #c8d7b7; font-size:70%; } #blockquote_nicp{ padding:10px; margin-bottom:0px; background-color:#ffffff; } #blockquote_nicp_link{ color:#7c7f78; font-size:70%; } #h5_nicp{ font-size: 12px; padding:4px 10px; border:none; background-color:#afd2f453; }

インタビュー

2025年06月09日

安定の裏に潜む意外な悩み？HCLに聞く「HCL Domino」のバージョンアップにおける課題と意義（前編）

Domino が誕生してから35年以上が経過し、IBM から HCL に移管されて丸６年が経ちました。 Domino は、高い開発生産性と堅牢性を兼ね備えたアプリケーション基盤で、長きにわたり企業の業務効率化を支えてきた歴史ある製品です。一方、重ねてきた実績の分だけ、バージョンアップに対する課題も垣間見えます。今回は、エイチシーエル・ジャパン株式会社 HCLSoftware のテクニカルリードである松浦光様に HCL Domino のビジネス状況や今後の展開など、多岐にわたり話を伺いました。前半では「Domino の現状」を中心に、後半では「新バージョンの登場と互換性」をテーマにバージョンアップについてより具体的に語っていただきました。（本ページは前半です［後半も公開中］）対談者【ゲスト】エイチシーエル・ジャパン株式会社 HCLSoftware テクニカルリード松浦光様【インタビュアー】エヌアイシー・パートナーズ株式会社技術企画本部ソリューション企画部松田秀幸 ※対談者情報は2025年6月9日時点 HCL Domino の現状製品の変遷と現在のビジネス状況 ── Domino が誕生してから35年以上が経過し、IBM から HCL に移管（2019年7月）されてからも丸６年が経ちました。今、HCL としての Domino のビジネス状況はいかがでしょうか。松浦：現在も利用していただいているユーザーも多く、市場としては活況です。見た目や使い勝手も含めた新機能が多く実装されてきた点、バージョンアップのサイクルが非常に良いペースで進んできている点が、ユーザー様、パートナー様から製品投資として評価をいただいてます。一方、Domino のクラウドに対する対応が SaaS としてではなく Amazon や Google などのクラウドキャリアとの協業による提供に主眼をおいているので、その点が他の SaaS型コミュニケーションツールと比べてもう少しなんとかならないかという声は未だにいただいている状況です。 ── Domino のクラウドに対して、SaaS型コミュニケーションツールとしても期待もされているということですね。松浦：運用に関する負荷を下げたいということだと思います。加えて人材確保やノウハウ継承などの課題に対し、生成AI との連携など新しい領域へのチャレンジがトレンドになっています。旧バージョンでの利用も多い ── バージョンアップのサイクルといえば、多く利用されているバージョンは何でしょうか？松浦：お陰様で現時点の最新バージョンである V14 が順調に立ち上がっています。ただ実は、特定のバージョンでいわゆる『塩付け運用』をされているお客様も多くいます。そのような状況の中で１点、昨年末にあったケースについてお話しさせてください。 2024年12月13日に重要障害が発生し、多くのお客様と関係者の皆様にご迷惑をおかけいたしました。大変申し訳なく思っております。この場を借りて、お詫び申し上げます。対応として修正モジュールの適用をお願いしておりますが、実はこの障害は35年前のコードに含まれていたもので、Domino のすべてのバージョンで発生していました。そのような中で、Domino の塩漬け運用をされているお客様、他社移行の事例記事になっており HCL とまったくお取引がないお客様からもお問い合わせをいただいています。 ── 古いバージョンのまま Domino を利用され続けているユーザー様もまだまだ多くいらっしゃる、ということが分かったのですね。松浦：はい、良くも悪くも先ほどお話したような状態で、HCL と最近お付き合いがないお客様からもお問い合わせをいただくケースがありました。古いバージョンを利用する際の注意点 ── 古いバージョンのまま利用することへの懸念は何でしょうか？松浦： Java などサポートが終了したテクノロジーへの脆弱性対応が懸念されます。また、旧バージョンでは DXに対して十分な役割を果たせるとは言い難いです。新バージョンでは Web対応やモバイル対応、AI対応での活用もイメージしています。例えば、新バージョンである V14.5 には、Domino と生成AI を統合した機能もあります。 ──『塩付け運用』をされた場合、サポート面はどうでしょうか。松浦：多くの塩漬け運用されているお客様からの声をお聞きすると、サポートが終了したバージョンで安定運用ができていたというのが Domino に対する今までの理解だったと思いますが、今回のようなことだけでなく、脆弱性対応も必要になるので、やはりサポートを受けられるバージョンの必要性を意識していただけたのではないかと考えています。 Domino が選ばれ続ける理由情報系基幹システムとしての性能と安定性 ── 旧バージョンでの利用も含め、Domino が利用され続ける理由は何でしょうか？松浦：情報系の基幹システムとして必要十分な機能を備えている点が大きいですね。 Domino が誕生した当初から兼ね備えており、「バージョンアップをしなくても現状で満足」というユーザーがいらっしゃる理由になっています。 ── Domino が古いまま使用されるのはなぜか、この点をより詳しくお聞かせください。捨てられないけれどバージョンアップもしない、というのは、なぜでしょうか？松浦：例えば、四半世紀前のデータがそのまま最新バージョンでも読み込めるなど、下位互換、上位互換性が非常に高い。動いてしまうがゆえに、使えてしまう。便利に使っていただけるのはいいことなのですが、やはり15年前、20年前に作ったアプリケーションなので、見た目が古くなってくるというのは当然あります。 Domino でのアプリ開発の優位性 ── 一般的な市場感として Domino はすでに別製品に移行されてしまったという風潮もありますが、いかがでしょうか？松浦： Domino はアプリケーションの開発生産性が非常に高い製品だというのは、市場の評価として強くあります。同じようなアプリケーションを、例えば SaaS型の Webベースの他製品、ノーコードの製品やローコードの製品に切り替えることにチャレンジされているお客様はいらっしゃると思うのですが、なかなかうまくいかないということを伺っております。 ── うまくいかないというのは？松浦：その製品が悪いとか機能が足りないという話ではなく、Domino だと簡単にでき過ぎてしまうということで、エンドユーザーの満足度を得られないというのが１つの原因だとお客様はおっしゃっています。他社製品と共存できるメリット ── メールはもう SaaSメールに移行しているという話はよく聞きますが、アプリケーションについては Domino の利用を続けているということでしょうか？松浦：コミュニケーション基盤に関しては、在宅勤務やリモートワークが一般的になったので、好みの Web会議サービスに付帯したものへ切り替えたというお客様はいらっしゃると思います。ただ、先ほどの話にあったように、アプリケーションはなかなか切り替えるのが難しいというのがあります。アプリケーション利用のために Domino が残っているというケース、共存されているというケースなど、多々あると思います。 ── Domino 以外のコミュニケーション基盤とアプリケーション基盤としての Domino を併用し、いわば一つのシステムとして使えると。松浦：はい、その通りです。コミュニケーション基盤は別の製品を、アプリケーション基盤としては Domino を使っている事例を、弊社ホームページにも事例記事として掲載しています。 ── コミュニケーション基盤とアプリケーション基盤でそれぞれのいいいとこ取りをされているのですね。松浦： Domino と他製品が共存ができることは、バージョンアップの観点でも大きなポイントだと思います。 ──「基盤が２つあると運用管理も２倍になるのか」という疑問も出そうですが、どのような運用が可能でしょうか。松浦：コミュニケーション基盤では、例えば１人に１つメールアドレスを発行するのが一般的だと思います。その場合、そちらのディレクトリシステムをメインにし、Domino は二次ディレクトリとして運用することもできます。また、LDAP（Lightweight Directory Access Protocol）参照で認証委託をさせることもできますし、Dominoディレクトリと他のディレクトリ…例えばAzure AD（Azure Active Directory）のようなディレクトリサービスと連携させて運用している事例も多くあり、各社のやりたいことと運用負荷のバランスを考えて様々な方法がとれます。なぜ Domino のバージョンを上げないのか高い互換性が仇になっている？「動いてしまう」ジレンマ ── 互換性が高いということは、バージョンアップの障壁が低いともいえますね。松浦：互換性の高さは、単に過去のデータが「動く」以上の価値を提供していると考えています。もし他社製品に移行する場合、往々にしてデータ移行が膨大なコストや技術的課題を伴い、互換性の問題が原因で取り残されたデータが発生するケースも見受けられます。Domino の場合、こうした課題を意識することなく過去の資産を活用し続けることが可能であり、移行リスクや未知のコストを回避できる点でも独自の競争力を持っています。 ── 一方で、見た目を新しくすることは、バージョンアップの動機にはならない。松浦：見た目を新しくする機能もリリースはしていますが、そこに手をつけるよりは塩漬けで使ってしまおう、その方がお金がかからずに済む、ということで、古いバージョンのまま使うという決断をするお客様もいるのかなと思っています。 ── 確かに Notesクライアントだけを見たら、そんなに大きく変わらないですよね。松浦：アーキテクチャは変わらないですし、Windows で動いてしまえばクリティカルな障害もなければ、上げる理由も作れなかったというところです（笑）。最新バージョンは、バージョンアップをする理由になるか ── 大きな障害がなく動かせる状況の中で、上げる理由は何かとなると「最新バージョン V14 で何ができるのか」でしょうか。松浦：そうですね。お客様が最新バージョンに上げる理由としては DX が多い印象です。再投資をする際の Web対応やモバイル対応、AI対応があります。そのようなところで、もっと価値を出していけるのではないかと考えています。 ── V14.5 については、後半でさらに詳しくお聞かせください。松浦：最新バージョンには、Domino と生成AI を統合した機能もあります。V14.5 は、大きく進化した面もあるので是非語らせてください（笑）。 ── 楽しみにしています（笑）。後半では、新バージョン V14.5 の新機能やアップデート、互換性についてお聞かせください。 HCL Domino について問い合わせるまとめここまで Domino の現状について、HCLSoftware 松浦様にお伺いしてきました。最後に、前半のまとめと後半のトピックをご紹介します。前半のまとめ Domino の現状 Domino は35年以上にわたり利用されている製品で、現在も市場は活況。ユーザー数は多く、旧バージョンのまま利用されるケースも多い。長期的に利用される理由は、高い開発生産性と安定性。利用され続ける理由 Domino は情報系基幹システムとして必要十分な機能を備えている。高い下位互換性と上位互換性があり、古いデータやアプリケーションが最新バージョンでも問題なく動作する。旧バージョンの課題特定バージョンを使い続ける「塩漬け運用」が多く、安定性を理由にアップグレードしないユーザーが多い。古いままでもシステムが動作するため、アップグレードの動機になりにくい。見た目の改良も費用対効果が低いとして、アップデートしないケースが多い。 Domino のバージョンアップと他社製品への移行 Domino は他社製品との共存が可能。新バージョンは V14.5で、新たな機能が追加された。 DX領域での価値提供が、バージョンアップの理由となる可能性を秘めている。次回予告後半では、より具体的に新バージョン、互換性についてお届けします。新バージョン V14.5 の機能はもちろん、今後のビジネス戦略も語って頂きました。新バージョン V14.5 が刻む新たな一歩生成AI を Domino の中に Domino と生成AI の統合「Domino IQ」自社のベストプラクティスを得られる Domino による生成AI の活用方法 REST API による効率的なシステム間の連携バージョンアップの鍵は互換性の安心感移行チェックツールとその効果新旧バージョンの互換性は移行チェックツールで担保するバージョンアップ vs 他社製品への移行バージョンアップはしないが、移行もしない結論！バージョンアップが最適解今後の戦略 V14.5 は描いたロードマップの答え合わせになるバージョン兄弟製品に繋げる二段構えの展開 HCL 様からのメッセージ過去にとらわれない新たな事例でアプローチ V14.x を避けて V12 にする意味はない（本ページは前半です［後半も公開中］） HCL Domino について問い合わせるこのページを見ている人におすすめのページ安定の裏に潜む意外な悩み？HCLに聞く「HCL Domino」のバージョンアップにおける課題と意義（後編） HCL Domino 製品紹介ページ Com-PASS Cloud｜Domino Notes アプリのお預かりサービス .recommend-list{ margin-top: 0px; } ol.recommend-list li { color: #9b9b9b; } #recommend{ font-family: "Noto Sans Japanese"; font-size: 16px; font-weight: 700; color: #9b9b9b; border: none; padding: 0; margin-bottom: 10px; } .highlighter { background: linear-gradient(transparent 50%, #ffff52 90% 90%, transparent 90%); } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .btn_A{ height:30px; } .btn_A a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; } .interviewee { font-weight: bold; } figcaption { color: #7c7f78; font-size: smaller; } #box03 { position: relative; margin: 4em 0; padding: 0.5em 1em; border: solid 3px #95ccff; border-radius: 8px; } #box03 .box-title { position: absolute; display: inline-block; top: -13px; left: 10px; padding: 0 9px; line-height: 1; font-size: 19px; background: #FFF; color: #95ccff; font-weight: bold; } #box03 p { margin: 5px; padding: 0; font-weight: bold; } #box04 { position: relative; margin: 4em 0 0 0; padding: 0.5em 1em; border: solid 3px #62c1ce; } #box04 .box-title { position: absolute; display: inline-block; top: -27px; left: -3px; padding: 0 9px; height: 25px; line-height: 25px; font-size: 17px; background: #62c1ce; color: #ffffff; font-weight: bold; border-radius: 5px 5px 0 0; } #box04 p { margin: 0; padding: 0; } #box_blockquote { position: relative; margin: 4em 0; padding: 0.5em 1em; border: solid 3px #8d8d8d; } #box_blockquote .box-title { position: absolute; display: inline-block; top: -27px; left: -3px; padding: 0 9px; height: 25px; line-height: 25px; font-size: 17px; background: #8d8d8d; color: #ffffff; font-weight: bold; border-radius: 5px 5px 0 0; } #box_blockquote p { margin: 0; padding: 0; } .memo{ color:#53851b ; background-color: #c8d7b7; font-size:70%; } #blockquote_nicp{ padding:10px; margin-bottom:0px; background-color:#ffffff; } #blockquote_nicp_link{ color:#7c7f78; font-size:70%; } #h5_nicp{ font-size: 12px; padding:4px 10px; border:none; background-color:#afd2f453; }

インタビュー

2025年05月22日

【参加レポート】「Think 2025」に参加した～AIとハイブリッドクラウドで描く未来のビジネス変革～

こんにちは、ソリューション企画部の久田です。毎年恒例の IBM のフラッグシップイベント「Think」が今年は2025年5月6日から9日にかけてアメリカのマサチューセッツ州ボストンにて開催されました。このブログを通して、Think 2025 に参加して得た印象深いハイライトや知見を皆さんと共有できればと思います。 (さらに…)

ブログ