IBMのRed Hat買収の成果「Red Hat OpenShift on IBM Cloud」によって、複雑なマルチゾーンのOpenShiftクラスタの構築はどれほど簡単になるのか?IBM Champion for Cloud 2019が評価

IBMのソリューションやソフトウェアに対し、そのテクニカルコミュニティーにおいて高度な貢献をしたエンジニアを表彰する制度「IBM Champions」。今回はIBM Champion for Cloud 2019に選出された平岡大祐氏に、その知見・ノウハウを体感できる記事を執筆していただいた。昨今のDXトレンドなどについて聞いたショートインタビューとともに、3回にわたって「Red Hat OpenShift on IBM Cloud」の実践的な活用方法をお届けする。

» 2019年10月18日 10時00分 公開
[PR/@IT]
PR

IBMテクノロジーを使ってビジネス、社会をリードするエンジニアに贈られる称号「IBM Champions」

 DX(デジタルトランスフォーメーション)トレンドが進展し、ビジネスが「ITを使った体験価値の競争」に変容して久しい。テクノロジーはビジネスのコアとなり、それを使いこなすエンジニアこそが、ビジネスの推進役となる時代が到来したといえるだろう。

 そうした中、IBMが主催しているのが「IBM Champions」だ。IBMのソリューションやソフトウェアに対し、年間を通してテクニカルコミュニティーに優れた貢献をしたエンジニアを表彰する制度で2008年に創設。2018年までにグローバルで650人、うち日本人は51人が選出されている。開発者、ビジネスリーダー、経営層など、全世界のITに携わる人に向けたインフルエンサーとして認定され、「IBM Analytics Champions」「IBM Cloud Champions」「IBM Collaboration&Talent Champions」「IBM Power Systems Champions」「IBM Storage Champions」「IBM Z Champions」の6部門で表彰。IBMのグローバルイベント、公式サイト、ブログなどを通じた意見発信の機会が与えられる。

 今回はIBM Champion for Cloud 2019に選出された平岡大祐氏に、その知見・ノウハウを体感できる記事を執筆していただいた。昨今のDXトレンドなどについて聞いたショートインタビューとともに、3回にわたって「Red Hat OpenShift on IBM Cloud」の実践的な活用方法をお届けする。手を動かして“最先端の視点”を体感してはいかがだろうか。

IBM Champion for Cloud 2019の平岡大祐氏

平岡大祐

IBM Champion for Cloud 2019

2002年からエンジニアとして、業務系、基幹系システム、プロダクトの設計、開発、運用などさまざまな業務に従事。2016年の夏に2カ月でIBM CloudのベアメタルサーバにOpenShift環境を構築し、2017年1月から本番環境で稼働させ、運用する業務を経験。以降、コンテナやOpenShiftの業務を多く経験するようになる。2018年3月刊行の『コンテナ・ベース・オーケストレーション Docker/Kubernetesで作るクラウド時代のシステム基盤』(翔泳社)に、OpenShiftに関する章の共著で参加。Red Hat認定資格「Red Hat Certified Specialist in OpenShift Administration」を取得している。

ショートインタビュー

―― 2018年10月に発表されたIBMによるRed Hat買収をどう見ていたか?

 買収が発表されたときは「IBM Cloud Kubernetes Service(IKS)」が成熟し始めていて、OpenShiftはKubernetesの機能拡張といえるものなので、IKSの上にOpenShiftを乗せたものが出てくるのではないかと予想していました。Red Hat OpenShift on IBM Cloudが提供される以前からIBM CloudとOpenShiftを組み合わせる環境の構築、運用してきた経験から言いますと、Kubernetes、CI/CD(継続的インテグレーション/継続的デプロイ)、運用監視といった環境を自前で構築するのではなく、簡単に借りられるというのは、大きなコスト削減につながるでしょう。また、OpenShiftでアプリケーションを開発すると、オンプレミスとパブリッククラウドで行き来がしやすくなるのもポイントです。

―― 近年のDXトレンドと今エンジニアに求められている役割について

 ある企業で働いていたときに、経営者が「プロダクトのリリーススピードを速めたい」と言っていましたが、そういったDXトレンドに乗っているような企業では、事業部門がIT部門に業務理解を求めていましたね。ただ、今に限らず昔からそういう企業はあったと思います。また企業によっては、IT部門やエンジニアに、変革を迫るところもありますし、従来通りコスト削減だけを求めるところもあります。いずれにせよ、今のエンジニアにはリリーススピードと自動化が求められていると思います。

―― 開発、運用の在り方はどう変わるのか?

 Red Hat OpenShift on IBM Cloudは、必要な情報を入力してボタンをクリックするだけで複雑なマルチゾーンのOpenShiftクラスタでも簡単に作成できます。運用エンジニアはKubernetesの学習や環境構築にかかるコストを下げ、運用監視に集中できます。また開発では、いったん設定を済ませば、コーディング後にGitリポジトリにプッシュすると、自動でビルド、デプロイが行われます。開発者はCI/CD、Kubernetesやコンテナの学習にコストをかける必要がなく、ビジネスロジックのコーディングに集中できるようになります。

 今回の記事では、Red Hat OpenShift on IBM Cloudによる環境構築の簡単さを見てもらえればと思います。


※以下は日本アイ・ビー・エムから提供されたコンテンツを、許諾を得て転載したものです。このため、用字用語の統一ルールなどは@ITのそれとは一致しません。あらかじめご了承ください。

はじめに

 2019年7月9日、IBMのRed Hat買収完了という歴史的な発表がありました。発表からたった3週間後の2019年8月1日にIBMは、自身のソフトウェア・ポートフォリオをよりクラウド・ネイティブ強化に刷新し、「Red Hat OpenShift」上で動作するよう最適化した(かつ、していく)ことを発表しました。

 この新しいクラウド・ネイティブ製品群は、「IBM Cloud Paks」と呼ばれ、IBMが自社のミドルウェアをコンテナ化、そしてパッケージ化してOpenShift対応を進めたものです。これらの事実から見てもIBMは、企業がアプリケーションを最新にする方法を簡素化し、特にこれまでクラウドへの移行に障壁があったミッションクリティカルなシステムのクラウド移行を重視していることがわかります。

 また、IBMの主力のコンテナプラットフォームとなったRed Hat OpenShiftは、もともとオンプレミス、パブリック/プライベート・クラウドで動作するように柔軟に設計されています。そのため、企業はOpenShift上でアプリケーションを一度構築すれば、OpenShiftが動く環境ならばIBM Cloudはもちろん、すべての主要なパブリッククラウド(AWS、Microsoft Azure、Google Cloudなど)、プライベート・クラウド、オンプレミスを問わず、そのアプリケーションを実行できるようになります。

 今回、8月1日の発表と同日にサービスを開始したIBM CloudのOpenShiftのマネージドサービス「Red Hat OpenShift on IBM Cloud」を利用し、Tokyoリージョンにある3つのデータセンター(TOK02、TOK04、TOK05)を利用するマルチゾーン・クラスターを評価しました。IBMが今、最も重要視しているRed Hatとの統合サービスを評価する――このエキサイティングで興味深い体験をみなさんと共有できればと思います。

 余談ですが、このRed Hat OpenShift on IBM Cloudは、もともと、Kubernetesのマネージドサービス「IBM Cloud Kubernetes Service(IKS)」として利用できていたサービス群に内包されています。Kubernetesネイティブの環境が必要な場合は、Kubernetesクラスターを、OpenShift環境が必要ならOpenShiftクラスターを構成することができるので、必要に応じて使い分けられるのは便利ですね。

マルチゾーン・クラスターとは

 OpenShiftクラスターのワーカー・ノードを複数のデータセンターに配置する構成のことです。データセンターレベルの障害が発生しても、システムへの影響を最小限にとどめられるようになります。マスター・ノードはIBM Cloud側で管理され、ワーカー・ノードの耐障害性などは利用者が指定できるようになっています。

マルチゾーン・クラスター構成図

OpenShiftクラスターの作成

 OpenShiftのクラスター作成プロセスを順に追って説明します。

 IBM Cloudポータル「https://cloud.ibm.com/」にログインし、ダッシュボード画面から「カタログ」「コンテナ」の順に遷移し「Red Hat OpenShift Cluster」をクリックします。

コンテナ画面

 「Red Hat OpenShift Cluster」のサービスに関する説明が表示されます。「作成」ボタンをクリックして進みます。

Red Hat OpenShift Cluster

 「新規OpenShiftクラスターの作成」画面が表示されます。

新規OpenShiftクラスターの作成1
  • クラスター名:jp-tokcluster(任意の名前)
  • リソース・グループ:Default
  • リージョン:Asia Pacific
  • 可用性:複数ゾーン
  • メトロ:Tokyo
  • ワーカー・ゾーン:Tokyo 02、Tokyo 04、Tokyo 05

 今回、Tokyoで複数ゾーンを選択しました。ですが、IBM Cloudでは世界中にマルチゾーンのリージョンがあり、同一リージョン内で複数のデータセンターで高可用性クラスターを構成できます。エンドユーザーに最も近いリージョンで構成するのがよいでしょう。なお、可用性はありませんが、単一ゾーンを選択すると、1つのデータセンター(例:Tokyo 02)のみの構成も作成することができます。

Note

 複数ゾーンを利用する場合のみ「VLANスパニング」を有効にする必要があります。


新規OpenShiftクラスターの作成2
  • マスター・サービス・エンドポイント:パブリックエンドポイントのみ
  • OpenShiftのバージョン:3.11.135(2019年9月時点では固定)
  • フレーバー:4vCPU 16GB RAM(仮想・共有)[一番安いマシン]

 フレーバーには「仮想・共有」「仮想・専用」「ベアメタル(物理サーバ)・専用」と用途に応じたマシンを選択できます。また、ユース・ケースに合わせて、CPU、メモリ、ディスクのたくさんの組み合わせが用意されています。このたくさんの組み合わせは、クラスター作成後の負荷状況に応じてマシンを変更、追加、削除することができて便利です。「ガッツリ重い処理をワーカー・ノードで、という場合にはベアメタルを使う」など、他のクラウドでは選択できないワーカー・ノードのフレーバーがあるのはIBM Cloudの良いところの一つだと思います。

新規OpenShiftクラスターの作成3
  • ローカル・ディスクの暗号化:選択
  • ワーカー・ノード:1

 ワーカー・ノードの数を「1」にすると、各ゾーンに1個(TOK02:1個、TOK04:1個、TOK05:1個)と合計3個のワーカー・ノードが展開されます。

 インフラストラクチャーのアクセス権のチェッカーでアクセス権の要件およびすべての推奨が満たされていない場合は「IBM Cloud IAM アクセス・ポリシー」を確認してください。契約しているIBM Cloudの管理者ではない場合は、管理者に確認してください。

 そして「クラスターの作成」ボタンをクリックすると、クラスターのプロビジョニングが始まります。約30分でクラスター、ワーカー・ノードの準備が完了し使用できるようになります。

クラスター作成中

 プロビジョニングが正常完了するとクラスターの「概要」タブではクラスターやワーカー・ノードの状態が緑色に変わります。

クラスター概要

 「ワーカー・ノード」タブでは、3つのワーカー・ノードがそれぞれTokyoリージョンにある3箇所のデータセンター(TOK02、TOK04、TOK05)に配置されているのがわかります。

ワーカー・ノード一覧

 「OpenShift Webコンソール」をクリックすると、OpenShiftのWebコンソールが起動し、OpenShiftが正常に動作していることが確認できます。

OpenShift Webコンソール

1クリックでOpenShiftクラスターが作成可能

 これまでご覧いただいた通り「Red Hat OpenShift on IBM Cloud」は必要な情報を入力して「クラスターの作成」ボタンをクリックするだけの簡単操作で、Tokyoリージョンにある3箇所のデータセンター(TOK02、TOK04、TOK05)を利用するマルチゾーン・クラスターが起動します。他社クラウドの環境では、マルチゾーン・クラスターをセットするのに自分で設定することが必要ですが、IBM Cloudだと、入力してボタンを押すだけで出来上がってしまうのに大変驚きました。

 特にオンプレミスの環境を自分で構築すると、学習・設計・構築など、出来上がるまで何ヶ月かかることかと思います。IBM Cloudのマネージドのサービスを利用することによって、企業はプラットフォームの構築から解放されます。

ブラウザ操作で簡単にアプリケーションをビルド・デプロイ

 OpenShiftでは、難しいCLIの操作がわからなくてもWebコンソールのブラウザ操作でアプリケーションのビルド・デプロイが簡単にできます。またOpenShiftでは、様々な言語、ミドルウェア、CI/CDの「サービスカタログ」(テンプレートのこと、以下「カタログ」と表記)が利用できアプリケーション開発が加速する仕組みが備わっています。

 例えばPHP開発の場合は、アプリケーションのソースコードを用意してPHPのサービスカタログを使うと、ソースコードからコンテナイメージをビルドする「s2i(source to image)」と呼ばれるOpenShiftのビルド方式によって、アプリケーションが自動でデプロイされます。

 それでは、実際にデプロイを試してみましょう。

 カタログ一覧から「PHP」を選択します。

カタログ一覧

 PHPのカタログの情報が表示されます。「Next>」ボタンをクリックして進みます。

PHPカタログ情報

 設定画面が表示されます。必要な情報を入力し「Create」ボタンをクリックしてアプリケーションを作成します。

設定
  • Add to Project:「Create Project」を選択
  • Project Name:phptest(任意の名前)
  • Version:「7.1」を選択(PHPのバージョン)
  • Application Name:helloworld(任意の名前)
  • Git Repository:https://github.com/daihiraoka/phptest.git(ソースコードのあるGitリポジトリを記述)

 作成結果が表示されます。今回作成したアプリケーション(helloworld)は問題なく作成できたので「Close」ボタンをクリックして終了します。

 OpenShiftのWebコンソールに今回作成したアプリケーション(helloworld)が登録されます。

 表示されたURLにブラウザからアクセスすると、アプリケーションの実行結果が出力されます。

 ここまで、ソースコードを用意しブラウザ操作で必要事項を入力するだけでアプリケーションをビルド・デプロイすることができましたが、Dockerで同様のことをするならば、ソースコードの用意以外に

  • Dockerfileの作成
  • 「docker build」コマンドでコンテナイメージの作成
  • 「docker run」コマンドでコンテナイメージの起動

の手順が必要です。しかし、この手順ではDockerの知識が必要です。

 OpenShiftでは、開発者は最低限のコンテナのセキュリティについて把握しておけばよいのです。ブラウザ操作だけでアプリケーションをビルド・デプロイできるように機能強化されています。

 特に大規模のアプリケーション開発では、「プログラムを書く人は、プログラムを書くだけ」という具合に役割が限定されるので、OpenShiftを開発環境にすると、新規参加される方のパソコンにDockerを入れたり、Dockerの作法を教えたりする必要がないため、すぐにプログラムを書き始めることができると効果的です。

アプリケーションのスケールアップ・ダウン

 アプリケーションのPod(コンテナ)のスケールアップ、スケールダウンについてもボタン操作で実現できます。

アプリケーションの変更

 アプリケーションを変更する場合、開発者はソースコードを修正しGitリポジトリにpushしてOpenShiftのWebコンソールで「Start Build」ボタンをクリックするだけです。

Buildの実行

 「Start Build」ボタンをクリックすると、Gitリポジトリから新しいソースコードを取得してビルドし、デプロイを自動実行します。

 さらにWebhook機能を使うと便利です。開発者がソースコードをGitリポジトリに登録すると、OpenShiftは、Gitリポジトリが発行した変更通知を受け取って、自動でビルド・デプロイを開始します。このWebhook機能を使うことにより、開発者はOpenShiftに触れることなく、ソースコードの変更を確認することができます。

 Pod(コンテナ)のリリース方式は、デフォルトではローリングアップデートで展開されます。これはアプリケーションのアクセス不可が発生することなく、新しいバージョンへの更新・切り戻しができる仕組みになっています。

デプロイの動作

アプリケーションのマルチゾーンへの展開

 IBM Cloudではマルチゾーンを構成するとリージョン単位でクラスターが構成され、Pod(コンテナ)は、ゾーン(データセンター)を意識せずリージョン単位で、リソースの空いているワーカー・ノードに分散配置される設計になっています。

マルチゾーン・クラスター構成図

 この設計により、アプリケーションをデプロイすると、今回作成したTOK02、TOK04、TOK05の3箇所のゾーン(データセンター)のリソースの中から、空いているワーカー・ノードにPod(コンテナ)が分散配置されます。これは、利用者が特にゾーンを意識しなくても、標準でゾーン(データセンター)の災害対策が行える仕様です。筆者は「利用者がゾーン(TOK02、TOK04、TOK05)を指定してPod(コンテナ)を展開して災害対策を行わなければならない」と想像していたため、自動的に災害対策が行える仕様になっていることに気がついたときは大変驚きました。

Note

 ゾーン(データセンター)を指定してPod(コンテナ)を配置することもできます。厳密に言うと、OpenShiftのスケジューラーはリソース(CPU、メモリ)の空いているワーカー・ノードにPod(コンテナ)を配置します。

 実運用ではワーカー・ノードがリソース不足になったり、障害が発生したりするケースが想定されます。その場合は、リソース不足や障害が発生したワーカー・ノードにはPod(コンテナ)は配置されないので、運用回避が必要です。


 では、実際に今回作成したアプリケーションの3個のPod(コンテナ)がそれぞれのゾーン(データセンター)に分散配置されているかどうかを確認します。Pod(コンテナ)の一覧は、CLIで出力するのがわかりやすいので、CLIで「oc get pod」コマンドを実行して、Pod(コンテナ)の一覧を出力します。

 上図のワーカー・ノードの一覧とPod(コンテナ)の一覧で、IPアドレスで見比べてもらうと、わかるようにTOK02、TOK04、TOK05に分散配置されているのがわかります。

 次に、実際にアプリケーションにアクセスしてみます。このアプリケーションはPod(コンテナ)が特定できるようにホスト名が出力される仕組みになっています。

 curlコマンドでアプリケーションに3回アクセスしてみます。下図の枠で囲ったホスト名と上図のPod(コンテナ)の一覧のPod名を見比べてみると、負荷分散しているのがわかります。

 これまで仮想マシン(VM)で運用していた時は、例えば、繁忙期や、急なアクセスが増えてロードバランス対象の仮想マシン(VM)を増やさなければならない場合などは、ロードバランサーの設定追加が必要でした。企業によっては、ネットワーク担当に設定変更をお願いする期限が数日だったり、2週間後だったりと、リードタイムが長いケースがありました。

 OpenShiftは、アプリケーションを外部公開した段階で、外部公開用のネットワーク設定を自動化したり、Pod(コンテナ)が複数ある場合は、自動的に負荷分散したりする仕組みになっています。OpenShiftを使うと、ネットワーク設定においても、アプリケーション公開のリードタイムを短縮できます。

Note

 curlの実行結果で出力されているIPアドレスはPod(コンテナ)のIPアドレスではないので疑問に思う方がいるかもしれません。「ibm-system」プロジェクトのネットワーク・ロード・バランサー(NLB)のIPアドレスが出力されています。NLBからOpenShiftのRouteを経由してPod(コンテナ)のEndPoint(PodのIPアドレス)にロードバランスするようになっています。

 OpenShiftのRouteとRouterはKubernetesで言うところの「Ingress」「Ingress Controller」に当たり、独自に実装されています。Routerはフロントエンドルーターとして「HAProxy」を使用しており、HAProxyの設定で、RouterからPod(コンテナ)のEndPoint(PodのIPアドレス)にロードバランスするようになっています。

 興味のある方は「default」プロジェクトにある、RouterのPodにrshしてHAProxyの設定を参照すると面白いと思います。


まとめ

 「Red Hat OpenShift on IBM Cloud」は、必要な情報を入力して「クラスターの作成」ボタンをクリックするだけで複雑なマルチゾーンのOpenShiftクラスターでも簡単に、約30分で作成されます。このことにより、企業はプラットフォームの構築から解放されます。

 また、IBMやRed Hatの用意したカタログ(テンプレート)の中から必要な言語を選択して、ソースコードを一度OpenShiftに登録しておけば、アプリケーション開発者はビルド(Start Build)を実行するだけでソースコードの変更を確認できるようになりました。さらにWebhook機能を使えば、OpenShiftに触れずにソースコードを確認することができます。アプリケーション開発者はアプリケーション開発以外のことはIBMやRed Hat、またはシステム管理者に任せ、ソースコードを書くことだけに集中できるのです。

 このように専門分野で本来のパフォーマンスを発揮できる環境を標準装備しているのがOpenShiftの強みです。

Note

 それぞれの組織に合わせて独自のカタログを作成して利用することもできます。


 これでTokyoリージョンにある3箇所のデータセンター(TOK02、TOK04、TOK05)を利用するマルチゾーン・クラスターを利用できるようになりました。

 残り2回の連載では、

  • OpenShiftによるJava EEアプリケーションのモダナイゼーション
  • IBM Cloudのモニタリングサービス(「SysDig」「LogDNA」)を使ったコンテナの監視
  • OpenShiftでDevOpsを実践するためのチュートリアル

を取り上げる予定です。

Copyright © ITmedia, Inc. All Rights Reserved.


提供:日本アイ・ビー・エム株式会社
アイティメディア営業企画/制作:@IT 編集部/掲載内容有効期限:2019年11月13日

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。