【てくさぽ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年08月04日

【てくさぽBLOG】IBM watsonx OrchestrateのADKを使ってみた

こんにちは。てくさぽBLOGメンバーの高村です。早速ですが、今年5月に開催されたIBMの年次イベント「Think2025」で、watsonx Orchestrateの新機能が発表されました！その中の一つとして、開発者向けの「Agent Development Kit（以下、ADK）」があります。今回はこのADKを活用し、watsonx Orchestrate環境への接続やエージェントの追加といった操作を行い、その使用感をご紹介します。なお、watsonx Orchestrateについては、今年2月、3月に公開した「watsonx OrchestrateやってみたBLOG」でご紹介しておりますので、是非こちらもご一読ください。【てくさぽBLOG】IBM watsonx Orchestrateを使ってみた（Part1）【てくさぽBLOG】IBM watsonx Orchestrateを使ってみた（Part2）目次はじめに ADKとは? ADK使ってみたさいごにお問い合わせはじめに Think2025で発表された新機能は、6月に環境へ追加されました。それ以前の環境とは、メニュー構成や操作方法、機能名称に変更があります。例えばこれまで「Skill」と呼ばれていたものが「Tool」へと名称変更されています。アップデート後の環境につきましては、別ブログにて改めて詳しくご紹介させていただく予定ですので、ぜひご期待ください！ ADKとは? まずはADKについてご紹介します。ADKとは開発者向けにwatsonx OrchestrateのAgentやToolをスクラッチ開発するための開発キットになります。ローカル端末などに導入し、pythonベースで開発を行うことができます。また、ADKとは別に、watsonx Orchestrate Developer Editionをローカル端末に導入することで、ADKで開発したAgentやToolのテストが可能になります。なお、watsonx Orchestrate Developer EditionはDockerコンテナ上で動作し、現時点のハードウェア要件はCPUは最小8コア、メモリは最小16GBが必要です。詳細はInstalling the watsonx Orchestrate Developer Editionをご確認ください。 ADKとwatsonx Orchestrate Developer Editionを利用することで、コードの迅速な作成・修正や柔軟なカスタマイズに加え、環境へのデプロイ前にローカルでテスト・修正が可能となり、作業効率の向上が期待できます。 ADK使ってみた前述ではADKでAgent開発し、watsonx Orchestrate Developer Editionで動作確認、SaaS watsonx Orchestrateへインポートする構築の流れをお話しましたが、今回の検証における動作確認は検証環境として利用しているIBM Cloud 上のwatsonx Orchestrate利用します。よって前述したwatsonx Orchestrate Developer Editionは利用せず、ADKからwatsonx Orchestrate検証環境へAgentとToolを直接インポートし、動作確認を行いたいと思います。また、ADKのインストール先は自分の端末ではなく、IBM Cloud上に構築したUbuntuのVirtual Server Instance（以下、VSI）を使用します。検証環境の構成イメージは下記の図の通りです。尚、ADKのインストール要件はPython 3.11以上、Pip、そして仮想環境（以下venv）が必要です。詳細については、Getting started with the ADKをご確認ください。それでは早速使ってみましょう！ VSIのプロビジョニングまずはADKをインストールするVSIをプロビジョニングします。本ブログではプロビジョニング方法について詳しく記載いたしませんが、手順は「【てくさぽBLOG】IBM Power Virtual ServerのAIX環境とIBM Cloud Object Storageを接続してみた（Part1）」のVSI for VPCの作成をご参考ください。 OSはUbuntu 22.04 LTS Jammy Jellyfish Minimal Install、リソースは2vCPU,4GB RAMで作成しました。VSI作成時にSSH鍵が必要なるので作成を忘れないようにしてください。作成すると数分で起動します。端末からSSHログインするため浮動IPが必要になります。赤枠で囲った浮動IPを作成しインスタンスに紐づけします。以上でVSIの作成は完了です。 Ubuntuの設定ターミナルを開きsshでUbuntuにログインします。私はWindowsのコマンドプロンプトを使用しました。Ubuntuユーザでログイン後、rootパスワードを設定し、スイッチできるようにします。 ubuntu@nicptestvsi:~$ sudo passwd root New password: Retype new password: passwd: password updated successfully ubuntu@nicptestvsi:~$ su - pythonのバージョンを確認したところ3.10.12でした。ADKの要件は3.11以上ですので、バージョンアップが必要になります。最初は3.13にバージョンアップしてみたのですが、後続作業と最新バージョンではパッケージが合わなかったのかうまく動かず…仕切り直して3.11を利用することにしました！ root@nicptestvsi:~# apt install python3.11 バージョンアップ後、デフォルトバージョンとして3.11を指定します。 root@nicptestvsi:~# sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.10 1 sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.11 2 sudo update-alternatives --config python3 update-alternatives: using /usr/bin/python3.10 to provide /usr/bin/python3 (python3) in auto mode update-alternatives: using /usr/bin/python3.11 to provide /usr/bin/python3 (python3) in auto mode There are 2 choices for the alternative python3 (providing /usr/bin/python3).Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/bin/python3.11 2 auto mode 1 /usr/bin/python3.10 1 manual mode 2 /usr/bin/python3.11 2 manual modePress <enter> to keep the current choice[*], or type selection number: 2 root@nicptestvsi:~# root@nicptestvsi:~# python3 --version Python 3.11.13 次に下記コマンドを実行して任意のvenvを作成します。 python3 -m venv /path/to/nicpse/project/your-venv-adktest ＜環境のパスを指定 venvを活性化してログインします。下記コマンド結果のようにvenvに入れましたらUbuntuの設定は完了です。 root@nicptestvsi:~# source /path/to/nicpse/project/your-venv-adktest/bin/activate (your-venv-adktest) root@nicptestvsi:~# ADKのインストール以下コマンドを実行してADKをインストールします。ADKは6月時点で1.5.1が最新バージョンです。 (your-venv-adktest) root@nicptestvsi:~# pip install ibm-watsonx-orchestrate Collecting ibm-watsonx-orchestrate Downloading ibm_watsonx_orchestrate-1.5.1-py3-none-any.whl.metadata (1.4 kB) Collecting certifi>=2024.8.30 (from ibm-watsonx-orchestrate) Downloading certifi-2025.6.15-py3-none-any.whl.metadata (2.4 kB) Collecting click<8.2.0,>=8.0.0 (from ibm-watsonx-orchestrate) Downloading click-8.1.8-py3-none-any.whl.metadata (2.3 kB) Collecting docstring-parser<1.0,>=0.16 (from ibm-watsonx-orchestrate) Downloading docstring_parser-0.16-py3-none-any.whl.metadata (3.0 kB) Collecting httpx<1.0.0,>=0.28.1 (from ibm-watsonx-orchestrate) Downloading httpx-0.28.1-py3-none-any.whl.metadata (7.1 kB) ----中略---- (your-venv-adktest) root@nicptestvsi:~# orchestrate --version ADK Version: 1.5.1 ADKの環境設定次にADKの環境設定を行います。watsonx OrchestrateのインスタンスIDが必要になるため、watsonx OrchestrateのSetting画面に入り確認します。下記画面をご参考にしてください。環境設定コマンドはこちらになります。-nの後はvenv名を指定し、-uの後はインスタンスIDを指定します。 (your-venv-adktest) root@nicptestvsi:~# orchestrate env add -n ＜仮想環境名＞ -u ＜環境のインスタンスID＞ [INFO] - Environment 'my-name' has been created [INFO] - Existing environment with name 'nicpse' found. Would you like to update the environment 'nicpse'? (Y/n)y [INFO] - Environment 'nicpse' has been created 以下コマンドを実行して、IBM Cloud上のwatsonx Orchestrateと認証設定をします。APIキーの取得方法は「【てくさぽBLOG】IBM watsonx.aiを使ってみた（Part2）」のAPIキーの取得をご確認ください。尚、リモート環境に対する認証は2時間ごとに期限切れになります。期限が切れた場合は再度認証する必要があります。 (your-venv-adktest) root@nicptestvsi:~# orchestrate env activate nicpse --apikey ＜APIキー＞ [INFO] - Environment 'my-ibmcloud-saas-account' is now active [INFO] - Environment 'nicpse' is now active 下記コマンドを実行してCLIから利用できる環境のリストを表示します。IBM Cloud上のwatsonx Orchestrateがactiveとなっていました！ (your-venv-adktest) root@nicptestvsi:~# orchestrate env list nicpse https://api.us-south.watson-orchestrate.cloud.ibm.com/instances/XXXXXXXX (active) local http://localhost:XXXX Toolとagentのインポート次にToolとAgentのインポートを行います。ToolとはAgentがタスクを実行する際に利用する機能です。今回は、IBM様より共有いただいたyfinanceを活用したToolおよびAgentのコードを、ADKを用いてインポートします。なお、yfinanceはヤフーファイナンスから株価などの金融データを取得するためのPythonライブラリです。最初にToolのインポートを行います。下記の様に、scpなどでToolファイルとrequirements.txtをディレクトリにアップロードしておきます。requirementsファイルは他のモジュールと依存関係がある場合使用します。 (your-venv-adktest) root@nicptestvsi:~/orchestrate_tool/py/source_02# ls -l total 12 -rw-r--r-- 1 root root 0 Jun 24 04:42 __init__.py drwxr-xr-x 2 root root 4096 Jun 24 04:38 __pycache__ -rw-rw-r-- 1 ubuntu ubuntu 8 Jun 24 03:02 requirements.txt -rw-rw-r-- 1 ubuntu ubuntu 1778 Jun 24 02:46 yfinance_agent.py 下記コマンドを実行してToolファイルとrequirementsファイルをインポートします。企業情報を取得するstock_infoと株価を取得するstock_quoteの2つのToolがインポートされました。 (your-venv-adktest) root@nicptestvsi:~/orchestrate_tool/py/source_02# orchestrate tools import -k python -f "./yfinance_agent.py" -r "./requirements.txt" [INFO] - Using requirement file: "./requirements.txt" [INFO] - Tool 'stock_info' imported successfully [INFO] - Tool 'stock_quote' imported successfully listコマンドを実行するとインポートされたToolを確認できます。 (your-venv-adktest) root@nicptestvsi:# orchestrate tools list ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━┳ ┃ Name ┃ Description ┃ Permission ┃ Type ┃ Toolkit ┃ App ID ┃ ┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━╇ │───────────┼────────────┼── │ send_mail_brevo │ send a meil using Brevo. │ write_only │ python │ │ │ │ │ │ │ │ │ │ ├─────────────────────────────────┼──── │ stock_quote │ 企業のTickerSymbolを用いて株価… │ read_only │ python │ │ │ ├─────────────────────────────────┼──── │ Untitled_6160RC │ No description │ read_only │ openapi │ │ │ ├─────────────────────────────────┼──── │ stock_info │ 企業のTickerSymbolを用いて企業… │ read_only │ python │ │ │ └─────────────────────────────────┴──── 次にAgentをインポートします。下記コマンドを実行します。 (your-venv-adktest) root@nicptestvsi:~/orchestrate_tool/py/source_02# orchestrate agents import -f ./yfinance_agent.yaml agent listコマンドでインポート済みのAgentを確認できました。Agentが使用するToolも表示されています。 (your-venv-adktest) # orchestrate agents list ┏━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━┳━━━━━━━━ ┃ Name ┃ Description ┃ LLM ┃ Style ┃ Collaborators ┃ Tools ┃ Knowledge Base ┃ ┡━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━╇━━━━━━━━ │ yfinance_age… │ 企業の会社情… │ watsonx/meta- │ react │ │ stock_info, │ │ │ │ │ llama/llama-3 │ │ │ stock_quote │ │ ││ │ │ -2-90b-vision ││ │ -instruct │ │ IBM Cloud上のwatsonx Orchestrateで動作確認インポートしたAgentとToolをIBM Cloud上のwatsonx Orchestrateで確認します。 watsonx Orchestrateへログインし、BuildからAgent Builderを選択します。 yfinanceエージェントが表示されているので、クリックします。クリックすると、Agent作成画面に入ります。UIから基盤モデルを変更したり、Agentの振る舞いなど変更することができます。スクロールして、Toolsetを確認するとADKからインポートしたToolが登録されています。右のPreviewからAgentの動きを確認することができます。今回はDeployせずPreviewで確認します。入力欄には「IBMの株価は?」と質問してみます。しばらくすると本日の株価が回答されました。Show Reasoningを開くと推論過程を確認することができます。株価を取得するTool「stock_quote」を使用し、AIがユーザの入力から自動的にTicker symbolを入力していることがわかります。次に「IBMの企業情報」と質問をします。しばらくするとAIがユーザの入力からTicker symbolを入力し、Tool「stock_info」を利用して企業情報を取得、回答されました。ユーザの入力内容からAgentが使用するToolを選択し、実行していることがわかります。さいごに ADKのご紹介とADKを使ってToolとAgentのインポートを行いました。 ADKのインストールおよび設定について、Pythonバージョンの設定やvenvの作成でつまずく部分はありましたが、venvが作成できればその後の設定はスムーズに進められました。今回はVSI上のUbuntuサーバにADKをインストールしましたが、ご自身の端末に導入することで、より気軽にAgent開発を行えるかと思います。なお、今回は検証対象外でしたが、watsonx Orchestrate Developer Editionを利用する場合は、インストール要件としてやや高めのスペックが必要になる点にご注意ください。検証時のADKのバージョンは1.5.1でしたが、7月末では1.8.0が最新バージョンとなっています。比較的頻繁にアップデートされますので適宜Release Notesをご確認ください。バージョンアップでコマンドオプションも変更される場合があるため、マニュアルを確認するかコマンドに`--help`を付与してパラメータを確認することをおすすめします。お問い合わせこの記事に関するご質問は以下の宛先までご連絡ください。エヌアイシー・パートナーズ株式会社技術企画本部 E-mail：nicp_support@NIandC.co.jp .anchor{ display: block; margin-top:-20px; padding-top:40px; }

ブログ

2025年07月29日

IBM Championになるには？〜今すぐ始められる活動ガイド〜

公開日：2025-07-29 こんにちは！技術企画本部ソリューション企画部西村です。皆さんは、IBMテクノロジーをリードする専門家が集う、世界的なコミュニティ「IBM Champion」をご存知ですか？ IBM Championは、IBMの製品や技術に関する深い知識を持ち、その魅力を積極的に発信する「伝道師」をIBMが公式に認定するプログラムです。この記事では、IBM Championの魅力と、認定されるまでの具体的なステップを、余すところなくお伝えします！ (さらに…)

ブログ

2025年07月11日

【参加レポート】Domino Hub 2025

公開日：2025-07-11 みなさまこんにちは。ソリューション企画部松田です。 2025年6月19日・20日と2日間に渡って開催された「Domino Hub 2025」に参加しました。これは HCL Ambassador有志が企画・実行する Dominoコミュニティイベントです。去年に続き、今回が3回目の開催となります。昨年同様、今回もエヌアイシー・パートナーズはスポンサーとしてご支援させていただき、両日参加いたしました。そのレポートをお送りします。目次イベント概要セッション内容 - Domino 14.5 リリース　特徴的機能とライセンス改定 -ロードマップ -お客様事例：曽根田工業様最後に関連情報お問い合わせイベント概要「Domino Hub」は、HCL Ambassadorが主宰となり、Dominoの利用者、開発者、ソリューションベンダーが一堂に会するコミュニティイベントです。今回は1日目がオンライン、2日目はオンサイトのみの開催でした。特に2日目は参加率が非常に高かったとのことで、会場も大変盛況でした。結婚式場としても使われている今回の会場は、中庭から陽の光が差し込み、解放感があるラグジュアリーな空間で、一般的なビジネスミーティングよりも上質な雰囲気が感じられました。併せて展示ブースも設置され、Dominoアプリケーションがスマートフォンやブラウザで使えるようになる「HCL Nomad」などのHCL製品とともに、様々なビジネスパートナー様の多彩な関連製品が数多く展示・紹介されていました。セッション内容 2日間で全22セッションが行われました。セッションはHCLをはじめ、HCL Ambassadorから、様々な開発ベンダー、製品ベンダー、エンドユーザーからの事例紹介などのセッション、そしてパネルディスカッションがありました。まずHCLからのセッション内でのトピックをお伝えします。機能のみならずライセンスまわりで大きなニュースもありました。 Domino 14.5 リリース　特徴的機能とライセンス改定 Domino Hubの2日前、2025年6月17日にリリースされました。 Domino IQ 特徴的な機能で最も注目すべき、今回もご説明に時間を割かれていたのが「Domino IQ」です。一言で言えば「Domino内にローカルでLLMを持たせ、蓄積されてきたDominoアプリ内の情報も取り込み、セキュアな環境で生成AIを用いた業務を実現する」ものです。企業内業務で生成AIをどのように実装し利用していくかは今、皆様の大きな関心事項であられると思います。自社のDomino環境内で、Dominoアプリケーションを用い、Notesクライアントからそれが実現できることになります。（画像クリックで拡大） Nomad for Web COM対応またNomad for WebがCOMに対応したことにより、これまではNotesクライアントだけでしかできなかったExcelやPowerPointを埋め込んだDiminoアプリもブラウザから利用できるようになりました。ライセンスダッシュボード：DLAUの統合これまでGitHubからダウンロードしてセットアップしていたDomino License Analysis Utility (DLAU)がDomino内にデフォルトで統合され、The Domino License Administration (DLA) となりました。（画像クリックで拡大）ライセンス改定そしてライセンスにも大きなベネフィットが付加されました。CCB Termライセンスにはこれまで「Domino Leapで5アプリケーションまで開発・利用が可能」という権利が含まれていましたが、2025年7月1日からその制限がなくなりました。すなわち「2025年7月1日以後有効なCCB Termライセンスをお持ちのお客様は、Domino Leapのフル機能が利用できる」となります。同時に、Domino Leapライセンスの利用範囲であるHCL Enterprise Integrator(HEI)の利用権利も含まれます。これでCCB Termライセンスのみで、追加費用なく「ブラウザによるノーコード／ローコード開発」「基幹業務とDominoアプリケーションの連携」が可能になります。さらにCCB Termで利用できるSametime Chatで添付ファイルと画像添付も可能になりました。ロードマップ Domino、Notes、Verse、Nomadなど各ソリューションについてのロードマップも紹介されました。先々の計画は出てこないものですが、このようにHCLから明確に提示されることにより、Dominoをお使いのお客様はこれからも安心して利用を継続していただけると思います。 Dominoのロードマップ（画像クリックで拡大） Notesのロードマップ（画像クリックで拡大） Nomad, VerseといったエンドユーザーのUI部分が短期間でバージョンアップされていく。（画像クリックで拡大）お客様事例：曽根田工業様 Dominoユーザーの有限会社曽根田工業代表取締役曽根田直樹様より、Domino事例のご講演がありました。曽根田様は2001年に静岡県磐田市で個人で起業され、切削機械の刃物を製造されています。曽根田様のお話で非常に興味深かった部分を抜粋致します。 "独立・起業するにあたり、前職で使っていたNotes/Dominoを自社でも使うことにした。現在は大手メーカーからの発注依頼や過去に作った品番の再発注など数多く受けており、当時のCAD/CAMのデータや販売管理データなどをDominoに入れて運用している。オンプレミス環境のリスクやセキュリティ、IT技術のトレンドに合わせてクラウド化を検討した場合、Dominoからは離れたほうがいいのではないか？と思い、他社SaaS製品も検討しトライアルで利用登録をした。しばらく触れずにいたところ、アカウント情報に登録していた支払い口座から利用料の引き落としがされていなかったためアカウントが凍結、さらに保存していたデータも突然消去されてしまっていた。支払いが滞っただけで中身まで削除されてしまうようなシステムには会社の大事な資産であるデータを載せられないので、「Dominoを『やめることを止める』判断」をした。" Dominoから他製品への移行を検討され断念されるお客様は多く、その理由は「Dominoの業務アプリケーションを、サービス内容を落とさずに別プラットフォームに移行することがはなはだ困難である」ということをよくお聞きしますが、この点にも意外な理由が潜んでいました。最後に初の2年連続開催となった今年のDominoHubは、コミュニティの力を象徴するかのような盛り上がりを見せました。14.5のリリース、生成AIの実装、ライセンス強化など、今後のDominoの発展を確信させる要素が数多く披露されたほか、実際のユーザー事例も非常に示唆に富むものでした。加えてロードマップの提示による未来への安心感も得られました。 DominoHubは単なる情報共有の場に留まらず、技術、コミュニティ、そしてビジネスの未来を交差させる特別な場となっています。これからもこのような取り組みが継続していき、多くのDominoユーザー、デベロッパー、そして販売パートナーが更なる価値を引き出していけることを楽しみにしています。これからもDominoと私たちの未来を築いていきましょう。関連情報「Domino Hub」大阪開催 Domino Hubは、2025年9月18日に大阪でのオンサイト開催が決定致しました。詳細およびお申し込みについては、こちらのリンクからご確認ください。お問い合わせエヌアイシー・パートナーズ株式会社E-mail：voice_partners@niandc.co.jp .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; } figcaption { color: #7c7f78; font-size: smaller; }

ブログ

2025年07月07日

【イベント参加レポート】「IBM i World 2025」に参加してきた

公開日：2025-07-07 こんにちは。毎年恒例のIBM社主催「IBM i World 2025」が2025年6月24日（火）・25日（水）の2日間に渡り日本IBM本社虎ノ門ヒルズにて開催されました。セミナーではグローバルのCTOによる講演や技術者向けセッション、6社によるお客様事例講演がありました。また、協賛企業による展示ブースも活気あふれる様子でした。毎年大盛況の本イベントに参加した弊社技術企画本部メンバーより、最新情報をお届けいたします。 (さらに…)

ブログ