2021年06月

08

【やってみた】WebSphere Hybrid Edition導入してみた:OpenShift導入編

こんにちは。
てくさぽ BLOG メンバーの岡田です。

今回はIBM WebSphere Hybrid Edition(以下、WSHE)の導入をAzure上で検証してみたので3回シリーズで検証で得られた知見をお伝えします。

当初は前回実施したIBM Cloud Pak for Applications(以下、CP4Apps)導入検証をプラットフォームをAzureに変えて検証する予定で進めていたのですが、CP4Appsが販売終了となり後継としてWSHEが発表されたので内容を変更し、WSHEをAzure上で検証することにしました。

今回は3回シリーズの1回目です。

第一回:【やってみた】WebSphere Hybrid Editionを導入してみた:OpenShift導入編 *本編
第二回:【やってみた】WebSphere Hybrid Editionを導入してみた:WebSphere Liberty導入編
第三回:【やってみた】WebSphere Hybrid Editionを導入してみた:ツール編

 

1.はじめに

前回、CP4Apps導入検証の際にはAWS上にUser Provisioned Infrastructure(以下、UPI)方式でOpenShift4(以下、OCP4)を構築してみましたが、今回はAzure上でもUPI方式で行ってみました。
なお、筆者はAzure未経験だったので何箇所かつまづきましたが、初心者はこんなところでつまずくんだなあ、と思って読んでいただけると幸いです。

手順は以下を参考にしました。
1.7. ARM テンプレートを使用したクラスターの AZURE へのインストール
https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.5/html/installing_on_azure/installing-azure-user-infra

OCP4導入後にWSHEのコンポーネントを導入する予定のため、OCP4のバージョンは4.5を利用しました。(現在はOCP4.5~4.7までサポートされていますが、検証当時はOCP4.5のみサポートでした。)

今回の環境・サーバー構成の概要図は以下となります。Bootstrapを除くと計6ノード構成になります。

 

2. 事前準備

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

OpenShiftのインストール作業に必要なLinux環境を準備します。
今回の作業環境は以下になります。

環境:手元のPC(Windows 10 1909)上にWindows Subsystem for Linux(WSL)+Ubuntu 18.04
実行ユーザー:user01を作成

(1)作業用ディレクトリとして以下2つのディレクトリを作成
/home/user01/os45      ※OpenShift インストールプログラム置き場
/home/user01/os45/conf  ※yamlやjsonなどの設定ファイル置き場
(2)Azure CLIインストール
(3)jqパッケージインストール
(4)cloudctlインストール
(5)ocコマンドインストール
以下の手順でダウンロードします。
Red Hat Custmer Portalにログインします。「ダウンロード」をクリックし、次の画面で”Red Hat OpenShift Container Platform”をクリックします。



・次の画面でバージョン4.5の最新バージョンを選択し、画面下から”OpenShift v4.5 Linux Client”を/home/user01/os45フォルダにダウンロードし、ファイルを解凍し、パスの通っている/user/local/binフォルダに移動します。

 

2-2. ファイルの準備

(1)OCP4.5インストールファイルのダウンロード
・ocコマンドをダウンロードしたのと同じページで”OpenShift v4.5 Linux Installer”を/home/user01/os45フォルダにダウンロードします。

(2)Pull Secretファイル
Red Hat OpenShift Cluster Manager サイトの「Pull Secret」ページから、インストールプルシークレットを/home/user01/os45フォルダにダウンロードします。

 

2-3. パブリックDNSゾーン設定

(1)リソースグループを作成
まずリソースグループを作成します。今回は「ocp-cluster」という名前のリソースグループを作成しました。

次の画面のタグは特に設定せずに進み、確認画面で「作成」ボタンをクリックします。

(2)App Serviceドメインを作成
今回は「azure-cloudpak-nicptest.com」という名前で作成しました。事前にレジストラからドメイン名を購入せずに作成できるかやってみましょう。


【連絡先情報】を入力します。

ドメインのデプロイが完了したら、nslookupやdigコマンドで確認しました。正しく引けたので、無事ドメインが作成できたようです。別途ドメイン名を用意しておかなくてもよかったです。

〈つまづきポイント:その1〉DNSドメインが正しく作成されない

連絡先情報の”州または準州”の箇所に、最初は”Tokyo-to”と入力してドメインを作成たところ、以下のエラー画面となり正常に作成されませんでした。

原因は”Tokyo-to”と入力した箇所でした。一旦既に作成されていたリソースを削除し、再作成の際に”Tokyo”と入力することで無事ドメインが作成できました。以下は再作成で成功した画面です。

〈つまづきポイント:その2〉Azure アカウント制限は拡張する必要がある?

参考にしたマニュアルにはvCPUの「デフォルトの Azure 制限」がリージョン毎に20、説明に”デフォルトのクラスターには 40 の vCPU が必要であるため、アカウントの上限を引き上げる必要があります。”と書いてあったので引き上げないといけないと思い込みサポートに事情を説明しリクエストしました。ところが、サポートからの回答は契約したサブスクリプションではデフォルトの制限は350コアで必要数は最初から超えているとのことでした。
Azure Portal の [サブスクリプション] ページの [使用量 + クォータ] セクションで確認できると教えてもらいましたので、皆さんもAzure上でOpenShift構築を実施する前には一度確認してみてください。

 

2-4. サービスプリンシパルの作成

そもそもサービスプリンシパルとはなんでしょう?Azure初心者の私もよく分からず、調べた結果、「Azureリソースを管理・操作するアプリケーションのためのアカウント」とのことでした。
今回はAzure Resource Managerでリソースが構築されるので、そのための専用アカウントと理解しました。

以下を実施します。
(1)Azureへのログイン(az login)
(2)アクティブなアカウントの詳細を表示して「tenantId」「id」を確認
(3)アカウントのサービスプリンシパルを作成し「appId」「password」を確認
(4)サービスプリンシパルに追加パーミッションを付与
(4-1)User Access Administrator ロールを割り当て
(4-2)Azure Active Directory Graph パーミッションを割り当て
(5)パーミッション要求を承認

 

3.OpenShift 導入

3-1. SSH秘密鍵の作成

クラスタの作成後に、ノードにアクセスするためにSSH秘密鍵を作成します。
(1)作業用Linuxマシン上でgenコマンドを実行しSSHキーを作成
(2)ssh-agent プロセスをバックグラウンドタスクとして開始
(3)SSH プライベートキーを ssh-agent に追加

 

3-2. インストールファイルの作成

(1)install-config.yaml ファイル生成
(2)ARM テンプレートの一般的な変数のエクスポート
(3)クラスターの Kubernetes マニフェストを生成
(4)コントロールプレーン、ワーカーノードを定義する Kubernetes マニフェストファイルを削除
(5)Kubernetes マニフェストファイルを変更
(6)変数のエクスポート
(7)Ignition 設定ファイルを取得
(8)ファイルの確認

 

3-3. Azure リソースグループおよびアイデンティティーの作成

OCPクラスタのインストールに必要なリソースグループとアイデンティティーを作成します。

(1)リソースグループを作成
(2)リソースグループの Azure アイデンティティーを作成
(3)Contributor ロールを Azure アイデンティティーに付与
(3-1)ロール割当に必要な変数をエクスポート
(3-2)Contributor ロールをアイデンティティーに割り当て

 

3-4. RHCOS クラスターイメージおよびブートストラップ Ignition 設定ファイルのアップロード

(1)Azureストレージアカウントの作成
(2)ストレージアカウントキーを環境変数としてエクスポート
(3)VHD の URL を環境変数にエクスポート
(4)選択した VHD を blob にコピー
(5)blob ストレージコンテナーを作成し、生成されたbootstrap.ignファイルをアップロード

 

3-5. DNSゾーンの作成

(1)プライベートDNSゾーンを作成

 

3-6. Azure での VNet の作成

(1)デプロイメントを作成
(2)VNet テンプレートをプライベート DNS ゾーンにリンク

 

3-7. RHCOS クラスターイメージのデプロイ

(1)RHCOS VHD blob URL を変数としてエクスポート
(2)クラスターイメージのデプロイ

 

3-8.ネットワークおよび負荷分散コンポーネントの作成

(1)ネットワークオブジェクトおよびロードバランサーのデプロイ
(2)変数のエクスポートとクラスターを既存のパブリックゾーンに追加

以上で、OCPノードを作成する手前まで完了しました。

 

3-9.ノードの作成

(1)ブートストラップマシンの作成
(2)コントロールプレーンの作成
(3)ワーカーマシンの作成
(4)クラスターへのログイン
(5)マシンの証明書署名要求の承認
(6)ブートストラップリソースを削除
(7)クラスターのインストールを完了する
(8)ログイン

クラスタにログインできたのでインストールは成功です!

長かったですね、最初のディレクトリ作成から数えて計50工程がようやく終わりました。

 

まとめ

いかがでしたでしょうか。やはりUPIは作業工程が多くて大変でした。
記載のとおり、Azureでの確認や設定で何箇所かつまづきましたが、コマンドを実行していくところはマニュアル記載のコマンドでエラーなく進めることができました。
もっと簡単にOCP環境を構築したいのであればIPI(Installer Provisioned Infrastructure)方式もありますが、構成をカスタマイズしたくてUPI方式を選択することもあるかと思いますので、その際にこの記事が参考になればと思います。

ここまでお読みいただきありがとうございました。
次回は構築したこのOpenShift上でのWebSphereをインストールしてみた内容をお伝えいたします。

 

 


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

エヌアイシー・パートナーズ株式会社
技術支援本部
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  

back to top