【やってみた】IBM Cloud Pak for Applications導入してみた：OpenShift導入編 (手順詳細)

2020年09月

【やってみた】IBM Cloud Pak for Applications導入してみた：OpenShift導入編 (手順詳細)

ブログ

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

1.本記事について

本記事は「【やってみた】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

2022年06月24日

【早わかり】AIX と IBM i ライセンス情報

こんにちは。エヌアイシー・パートナーズ村上です。 2022年度は新しい試みとして、・理解しているつもりだけど説明はできない・時間があれば調べたいと思っていた・当たり前な知識かもしれなくて質問しにくいという内容を取り上げた「早わかりシリーズ」を掲載していきます。今回は、IBM Power のメインOS、AIX と IBM i のライセンス情報をご紹介します。 AIX とIBM i は、片方のライセンス情報しか知らないという方も意外と多いので、ぜひこの機会に比較しながら読んでみてくださいね。セクション 1) 永続ライセンスのおさらい 2) マンスリーとサブスクリプションをご存じですか？ 3) ライフサイクルとバージョンのポイント 1) 永続ライセンスのおさらい AIX とIBM i のスタンダードなライセンス「永続ライセンス」。有効期限のない永続ライセンスは、SWMA (SoftWare MAintenance) と合わせて所有します。永続ライセンス OSを利用できる権利。1年目に購入。 SWMA 「サブスクリプション（最新バージョンへのアップグレード）」と「テクニカルサポート（対象製品に対するQAサポート）」の権利。 1年～5年で選択し、継続するためには都度オーダーが必要。更改などで新ハードウェアへ移行する場合、 AIX 永続ライセンスはIBM Power本体に紐づくので、新ハードウェアになるタイミングで永続ライセンスが買い直しになります IBM i 既存機のライセンスを新ハードウェア移管することが可能です（移行先の機械レベルが高くなる場合は追加料金が発生） IBM i には、移行中ライセンスとして安価なITL(IBM Temporary License)が提供されたり、DR機専用のライセンスがあったりもします。 2) マンスリーとサブスクリプションをご存じですか？さて、このセクションが今回のブログの本題です。 2022年6月現在、AIX とIBM i には「永続」「マンスリー」「サブスクリプション」と3種類のライセンスがあります。以下は利用ケースのイメージです。利用ケース永続ライセンス・長期間利用マンスリーラインセンス・移行時の短期利用・スパイク(最低限の環境をさっと作って概ねの方向性を確認する）サブスクリプションライセンス・初期投資を抑えたい場合に利用・HWに依存せず臨機応変に利用(中長期間でAIXの場合) サブスクリプションライセンスは、AIX は2021年、IBM i は2022年に提供が開始されました。（表が見えにくいのでクリックして拡大してご覧ください）サブスクリプションライセンスは、今後拡張が予定されています。利用ケースにあったライセンスを選択できるようになってきたので、臨機応変な検討ができるようになりますね。 3) ライフサイクルとバージョンのポイント 2022年6月時点で、IBMは「AIX も IBM i も将来の投資を継続する」という発表をしています。 IBM Power ユーザとしては一安心です。どちらのOSも、サポートライフサイクルは10年間となります。下記にバージョンのポイントを纏めてみました。＜AIX ＞購入できるバージョン v7.2 , v7.3 標準サポートがあるバージョン v7.1, v7.2, v7.3 どうやってもサポートが終わっているバージョン v5.3 実はまだ有償延長サポートがあるバージョン v6.1 TLが出るタイミング（※） 1回/年、成熟してくると1回/2年サポートライフサイクル(10年) 標準(最短6年)+延長保守(3~5年) ＜IBM i ＞購入できるバージョン v7.3 , v7.4, v7.5 標準サポートがあるバージョン v7.3, v7.4, v7.5 どうやってもサポートが終わっているバージョン v6.1 実はまだ有償延長サポートがあるバージョン v7.1, v7.2 TRが出るタイミング（※） 2回/年（最新バージョンと1世代前のバージョンに対して）サポートライフサイクル(10年) 標準(7年)＋延長保守(3年) <※TLとTRの補足> TL：テクノロジー・レベル。AIXにおける問題の修正、新しいハードウェアのサポート、ソフトウェアの機能拡張が含まれたプログラム。 TR：テクノロジー・リフレッシュ。IBM i におけるオファリング、サービス、およびハードウェアの機能拡張を提供するプログラム。かなり前のバージョンも、延長保守のサポートがあるため更改時も安心です。ただ、延長保守サポートは、部品不足による急な保守終了や、新規の問い合わせに対応いただけない、という面があるので要注意です。また、延長保守サポートには細かい前提が設けられており前提にも随時変更が入りますので、ご利用を検討される際はお問い合わせください。さいごについ先日(2022年6月)、IBM i の複数のソフトウェアラインセンスが無償化される発表(IBM PartnerWorld)がありました。 IBM i では更改の検討が始まると、実際に利用している有償ソフトウェアの見直しが入ったりして、見積もりに時間がかかることがありますよね。有償ライセンスが減ったことで、見積もりが少しでも簡単になり助かります。クラウドシフトが進む中で、ライセンス体系、課金、監査方法が複雑化しています。弊社には毎日のようにパートナー様からライセンス関連の相談やお問い合わせが来ています。 OSのみではなく、あらゆるソフトウェアのライセンス情報収集に日々奮闘(?)しているSEが多数おりますので、お困りの際はお気軽にご連絡ください！ ※ 本ブログの情報は時間経過とともに変更が入る可能性があります。お問い合わせこの記事に関する、ご質問は下記までご連絡ください。エヌアイシー・パートナーズ株式会社 E-Mail：voice_partners@niandc.co.jp

2022年06月23日

【動画】Webブラウザで簡単にアプリケーションを開発できるローコードプラットフォーム

HCL Domino Volt は、Webブラウザ上でビジネスユーザーがアプリケーションを開発できる、ローコードプラットフォームです。 (さらに…)

特集

2022年06月15日

デジタルビジネス時代に必須なアプリケーションの安定稼働を実現「IBM Observability by Instana」

企業が自社の価値を高めるために、デジタルビジネスに取り組むケースが増加しています。 (さらに…)

コラム

【やってみた】IBM Cloud Pak for Applications導入してみた：OpenShift導入編 (手順詳細)

1.本記事について