2018年01月

12

【特集ブログ】IBM Watsonが支援する「働き方改革」第2弾:メール編 ~時間と場所を超えて個人とチームの力を最大化~

カモシーこと、日本IBM 鴨志田です。
前回(IBM Watsonが支援する「働き方改革」第1弾:”会議編”)は、身近な「働き方改革」として、会議の効率化に焦点を当ててご紹介いたしました。今回は、「電子メール コミュニケーション手段」にメスを入れてみたいと思います。と言いますのも、前回も引用いたしましたが、2/3 を超える方から「電子メールの数をもっと減らすべき」という声があがっていますので、この多くの方の声にお応えしない訳にはいかないと思っております。

出典:ガートナー ジャパン「日本における社内コミュニケーションに関する調査」

そこで、電子メールの問題点は何かを改めて考えてみました。下表をご参照ください。

項番 電子メールの問題点 良い点としてとらえると
1. すぐに読んでもらえるかわからない
返事がいつくるかわからない
やり取りの証拠として残る
2. 宛先に入れた人にしか伝わらない 必要な人に一度に伝達できる
3. 各人が情報ややるべきことを管理する必要がある 後からでも確認ができる
4. 転送されてしまう危険性がある 手軽に転送できる

これらは「電子メールのパラドックス」と言われます。パラドックスとは、逆説や矛盾という意味です。本来、生産性を向上させるツールであったものが、反対に生産性を損ねる要因になってしまうことを表しています。生産性とメールの量の関係をグラフにすると以下のようになり、メールの量が膨大になると生産性が落ち込むことが読み取れます。

ではその「電子メールのパラドックスにならない方法」をご案内していきましょう。

1. 「返事がいつくるかわからない」への対応

「相手に読んでもらいたい」「返事が欲しい」というメールもそうでないメールもあると思います。本当にすぐにでも返事が欲しいような用件は、電子メールではなく、対面や電話で確認したほうが良いかもしれません。しかし、相手が捕まらない場合はひとまずメールを送っておくという手段はコミュニケーションを取る上での一手になります。そのような場合はこうしませんか? IBM の電子メール「IBM Verse」では、送信したメールにメモを付けたり、フォローするタイミングを設定したりすることができます。下図のように、メール送信の際に 1 クリックし日時設定とメモを書き込みます。すると「対応待ち」に格納されます。これによりこの用件は一旦忘れることができるのです。頭のなかで「これをやらなければ! あれを対処しなければ!」と考えていると作業や仕事に集中できず生産性を落としかねません。頭を空っぽにして別の仕事に集中していきましょう。

2.「レレレメール」にならないための対応

今度は送信側ではなく、受信側での場合を考えてみましょう。受信したメールに返信を出すことはよくあります。さらにその返信を待つということもあるでしょう。メールソフトによりますが、送受信が続くと「Re:Re:Re:」といつまでも Reply の Re: がつながっていく「レレレメール」になっていくことがあります。また、ちょっとした用件のメールに何分も何時間も掛けてやり取りした経験はありませんか? このような場合は、「在席確認とチャット機能」が役に立ちます。IBM Verse には在席確認とチャット機能が利用できるようになっています。

人を選んで在席状況を確認してチャットをすることもできますし、受信したメールに在席マークが表示されますので、そこからチャットで話しかけてサッと用件を済ましてしまうことも可能です。これにより、例えば 5 時間かかっていたやり取りが 50 秒で終わる、そして次の仕事に取り掛かるということもできるのです。

3.「情報の管理」への対応

「宛先に入れた人にしか伝わらない」「私その情報もらっていない」・・・とならないように、とりあえずcc に全員入れておく。このようなことありますよね。結果、不要なメールが増えてしまう、また反対にメールを受け取った人はその情報をフォルダ分けなどで整理しておく必要がある。いかにも非効率です。情報は共有しましょう、そして共有しておく場所を決めておき、必要なメンバーが把握/参加でき、経緯や最新情報/結果をいつでも見ることができるようにしておきましょう。これによって、類似情報が社内に点在したり、並行して複数の人が同じ作業をしたりする無駄を省くことができます。そして、最初の情報発信源がメールだった場合、IBM Verse では 1 クリックで情報共有の場に導いてくれるようになっています。

4.「転送の危険性」への対応

「送ったメールが誰かに転送されてしまう」これは致し方ないかもしれません。ですが少なくともメールに添付したファイルを勝手に転送されてしまわないように、場合によっては、ダウンロードすらできないように対処したいという利用シーンもあると思います。ファイルにパスワードを付ければ良いのでしょうか? もしくは、添付ファイルがある場合は自動的にファイルを暗号化できれば良いのでしょうか? 残念ながらそれでは不十分です。結局、受信者はファイルをダウンロードして、パスワードで復号できてしまいます。そんな信用ならない人にはファイルを送らなければ良い、ごもっともですが、すぐに共有したいということもあるでしょう。

このような場合は、「IBM VerseBox」 を組み合わせて利用することをお勧めいたします。

IBM Verse でのメール作成時にファイル添付を示すクリップのアイコンがありますが、隣接して Box の “b” アイコンが表示されます。これをクリックすると、クラウド型コンテンツ(ファイル)管理である Box  にアクセスします。Box からファイルを選択するとファイルを添付するのではなく、リンク情報だけを付けるようになります。これにより、万が一このメールが転送されてもファイル格納元の Box へのアクセス権がなければアクセスできませんし、Box のアクセス権限で、「プレビューアー」を設定しておくと、ファイルをプレビューすることはできますが、手元にダウンロードすることはできないようになります。手軽にセキュリティ高く、迅速・円滑な情報共有ができることと思います。

最後に・・・

このように電子メールの数そのものを減らすことは難しいかもしれませんが、電子メールの良いところは活かしながら、問題点をそれぞれの方法で対処していく、これにより、個人やチームの生産性を向上していくというのはいかがでしょうか?
ご紹介しました IBM のソリューション(IBM VerseBox)は、きっと皆様のメール処理の生産性向上のお役に立てるでしょう。是非ご検討なさってください。

 

★予告★ 次回は、”もう少し Box に触れながら「資料の検索、共有や準備」にメスを入れます。ご期待ください!

その他の記事

2021年06月18日

“増えて消せない”データのために描く、企業規模のストレージ戦略

日本企業が未来のために進むべき道の1つとして、DXがあります。ただしその一方で、こうした業務のデジタライゼーションがデータ爆発を加速させていることも確かです。 重要な資産であるデータを格納するストレージは容量がひっ迫しがちになり、パフォーマンスの劣化やその回避策に苦慮している企業は多いことでしょう。データが増えるとバックアップ運用の難易度も上がります。 また、ストレージは業務システムごとに部分最適で導入される傾向があり、管理工数という点でもコストという点でも、負荷の高さが課題でした。 本格的な DR対策も長年の懸案事項です。加えて、企業の収益向上に資するデータ分析や AI活用も求められています。スピード経営を実現するためにコンテナ技術を取り入れたい、と構想する企業も増えてきました。 本記事では、まだまだストレージの機能を使いこなせていないというエンドユーザー企業の悩みに応えるために、企業情報システムのストレージ戦略の中核テクノロジーとして活躍する IBM Spectrum Scale をご紹介します。   ストレージ課題で悩む企業への解決策は、IBM Spectrum Scale IBM Spectrum Scale は、企業情報システムのデータ戦略の中核に位置付けるにふさわしいスケールアウト型のストレージ・ソフトウェアであり、エンタープライズ・データ・サービスです。 これによって様々なストレージ課題を解決できます。 その構成は、クライアントに対する窓口の役目を果たし、NFS/SMB/オブジェクトプロトコルに対応するプロトコルノードと、共有ディスク・アクセスを直接行うNSDサーバーからなります。 また、ストレージはそのバックエンドのストレージプールにおいて共用可能な状態で提供されます。 図1. IBM Spectrum Scale は、多様なデータのハブとなるエンタープライズ・データ・サービス プロトコルノードと NSDサーバーは、利用形態に合わせて柔軟に増減できます。 ストレージ上のファイルにアクセスするクライアントが増えるのならプロトコルノードを増やす、データ量が増えたなら NSDサーバーを増設するといった具合に、どんどんスケールアウトしていくことが可能です。 あらためて IBM Spectrum Scale の特長を紹介すると、次のようになります。   1. バックアップ効率化やDR対策として活用できる拠点間連携機能 IBM Spectrum Scale には Active File Management (以下、AFM) と呼ばれる機能があり、複数拠点間で非同期コピーを自動で実現します。データがすべてを選択することも可能で、一部に絞ることもできます。 また、キャッシュはリードオンリー、リード/ライト、DR など、様々なモードが選択可能です。   2.担当者を手作業管理から解放するデータ階層化機能 これは、データの自動振分け機能です。 IBM Spectrum Scale は、フラッシュ、SSD、SAS、SATA、 NL-SAS といった異なった種類のストレージを混在させてファイルシステムを構成することができます。 そのため、高頻度にアクセスされるデータは高速ストレージに、アクセス頻度の低いデータは低速ストレージに、といったデータの適材適所の保存を苦もなく実現。ストレージのみならず、テープやクラウドとも自動連携可能 (テープとの連携は別途ソフトウェアが必要) です。 ユーザーは、どのストレージプール上にファイルがあるか を意識する必要がなく、データが移動しても同じ操作でアクセスが可能です。これによって、ストレージ担当者はデータ保管先を管理する作業から完全に解放されます。   3.高い拡張性とパフォーマンス 拡張性・パフォーマンスに優れたファイルシステムです。 プロトコルノードは最大16,384ノードまで拡張可能。格納できるファイルの上限数は9千兆個で、最大ファイルシステム・サイズは8 エクサバイト。つまり、800万テラバイトに上ります。 これだけの容量があれば、ほとんどのケースでストレージ容量の上限に悩まされることなく、リニアに拡張性を追求していくことができます。 パフォーマンスという観点でも、ブロックサイズ単位で分散並列I/O が可能な一方で、最大16MiBの大容量ファイルにも対応。2.5テラバイト/secという高いスループットもすでに実証されており、高速処理が求められるシステムに適用可能です。   4.多様なプロトコル対応で全体最適のデータ戦略を後押し プロトコルノードの追加により、Windows環境の CIFS、SMB、UNIX環境の NFS、オブジェクトの HTTPS、Hadoop の HDFS など、様々なプロトコルでのファイルアクセスが可能です。 そのため、異なるプロトコルが混在する企業情報システムであってもそれぞれを "サイロ化" させず、部分最適ではなく全体最適の観点でストレージ活用が可能になります。   5.ビジネススピードを加速させるOpenStack対応 KVMホストに Spectrum Scale Client をインストールすることで、IBM Spectrum Scale は OpenStack のバックエンドストレージとしても活用できます。 Copy on Write機能により、インスタンス/ボリューム の高速な作成や容量の効率的な使用が可能。複数ホストでファイルシステムを共有できるため、Live Migration を行いたいなどというときも、データのコピーを行うことなく短時間で切り替えられます。   6.分析結果をよりスピーディーに活用できるHDFS対応 Hadoop はオープンソースで大量のテキストデータを分散処理によって高速に処理可能な主要技術ですが、分析対象となるデータを配置するファイルシステム HDFS はそのままではデータの格納庫として利用できません。 分析結果の利用先システムが分析対象データの発生元システムのデータを利用するにはデータコピー作業が必要になり、ストレージを別に用意しなければなりません。 しかし IBM Spectrum Scale なら、分析対象データの発生元システムが Hadoop で利用する IBM Spectrum Scale 上のディレクトリにデータを直接書き込みさえすれば、分析結果の利用先システムはデータを直接読むことができます。 これは、分析結果をそれだけ早く現場で活用できることを意味し、DX推進につながります。   短期間で構築可能なアプライアンス:IBM Elastic Storage System IBM Spectrum Scale は Software Defined Storage であるため、プロトコルノードや NDSサーバーを自由に選択したり、既存のサーバーを有効活用できる、という利便性があります。 その稼働環境も、IBM AIX®、Red Hat Linux、SUSE Linux Enterprise Server、Microsoft Windows Server、Microsoft Windows、IBM z Systems™と幅広いため、企業のシステム環境に合わせて選択できる自由があります。 しかし、エンドユーザーであるお客様によってはそれがかえって面倒と感じられるかもしれません。 その場合は、アプライアンスとして提供される IBM Elastic Storage System がお勧めです。 幅広いラインナップがそろっており、ハードウェア構築、ソフトウェア導入およびテストを工場で事前に実施。お客様サイトには、ラックにマウント可能な状態で搬入できます。 お客様は当初から利用に専念でき、保守およびサポート窓口が一本化されるため、自ら障害切り分けに動く必要もありません。   こんなシチュエーションで活かせます Case 1. バックアップ運用の効率化に AFM機能を利用します。 全拠点の全ファイルを、本社データ・センターで集中管理します。IT担当者のいない遠隔地拠点では、バックアップ運用は行わず本社データ・センター側でまとめて実施します。遠隔地拠点では、よく使うファイルだけがキャッシュされるようにします。 拠点内であるため、高速なアクセスが実現します。 図2. AFM機能を利用した本社・遠隔地拠点間連携   Case 2. AI分析基盤として IBM Spectrum Scale は、データ蓄積のために求められるストレージ要件を満たしています。 それは、「多様なシステムと連携可能なプロトコル対応」「分散したデータを集約する遠隔地連携機能」「高いコストパフォーマンス」です。また、データ分析のために求められるストレージ要件にも合致しています。 それらは、「処理性能に合わせた分散処理機能とスケーラビリティ」「高い性能を引き出すオールフラッシュ・ストレージとの連携機能」「ハイブリッド・クラウド環境でのデータ連携機能」で、これらの点から、深層学習の基盤などとしても最適の環境です。   Case 3. アーカイブ自動化で ストレージプールを、ゴールド、シルバー、ブロンズと階層化します。 階層化に使用できるファイル属性には「最後にファイルアクセスがあった日時」「最後にファイル修正があった日時」「ファイルセット名」「ファイル名 / ファイル拡張子名」「ファイルサイズ」「ユーザーID / グループID」「ファイルアクセス頻度(ファイルヒート)」があり、これらに基づいてポリシーを策定。 Gold にあるデータがポリシーの閾値を超えたらシルバーに移動、またそこで閾値を超えたらブロンズに移動させます。そして、ブロンズで365日間アクセスがなかった場合はファイルシステムから削除。逆に、2日未満の間隔でアクセスがあったらシルバーに移動、などといった具合に、アーカイブ自動化により絶え間ないデータ循環が実現します。   Case 4. 増え続ける大容量データへの対応に 生命科学研究の最前線ではゲノム解析が進んでおり、そこでは膨大なデータが発生します。 10人分の全ゲノムで1テラバイトボリュームのデータになるといい、さらに解析を付加することでデータ容量はますます膨らんでいきます。 こうした指数関数的なデータ増加に対しても、800万ペタバイトまで拡張可能な IBM Spectrum Scale であれば、余裕を持ってシステム構築を行えます。   ビジネス機会を逃していませんか?NI+C Pなら提案・サポートできます エヌアイシー・パートナーズ (NI+C P) は、1990年代に IBM Spectrum Scale の前身である GPFS が登場したときから、進化を長く見守ってきました。そのため、この技術については深く熟知しているという自信があります。 提案先のストレージ担当者が何か課題を抱えておられるようなら、ぜひ、その情報を共有してください。ともに解決策を模索しましょう。 ひょっとすると、IBM Spectrum Scale はソフトウェア製品であるために全体像がつかみにくいかもしれません。そのような場合には、弊社の検証環境設備で実際に製品の動作を見ながらご相談にのることも可能です。 データを企業資産ととらえ、全社ストレージ戦略を立案したい情報システム部門と、それを支えたいパートナーの皆様のお力になれると思います。お気軽にお声がけください。     この記事に関するお問合せ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは、「こちら」からお願いします。   参考情報 IBM Spectrum Scale (製品情報) IBM Spectrum Archive (製品情報) データ爆発時代が生んだ、“手間レス”オールフラッシュストレージ (コラム) 「壊れにくく、処理速度が落ちない」IBM FlashSystem の特長とラインナップを徹底解説 (コラム)  

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

back to top