現在位置: ホーム / Red Hat Ch. / Red Hat Business / コンテナアプリケーションプラットフォーム「Red Hat OpenShift」を触ってみた Vol.3

コンテナアプリケーションプラットフォーム「Red Hat OpenShift」を触ってみた Vol.3

【第3回】本記事では、コンテナアプリケーションプラットフォーム「Red Hat OpenShift」(以降、「OpenShift」と記載)を触ってみたエンジニアより、その概要と感想をご紹介したいと思います。

はじめに

本連載はサイオスグループのキーポート・ソリューションズの開発プログラマーが、コンテナアプリケーションプラットフォーム「Red Hat OpenShift」(以降、「OpenShift」と記載)を触ってみて、その概要と感想をご紹介します。(普段はアプリケーション開発に従事しているため、OS、ミドルウェアについては決して得意ではない筆者です。)

第3回目のテーマは「開発」。開発ベンダーの立場から社内にてアプリケーション開発を行うにあたり、OpenShiftを利用することにより、どのようなメリットがあるのか、どのような不明点や課題があるのかを洗い出そうという主旨です。


アプリケーション開発における問題点

普段アプリケーション開発に従事している弊社では、以下のような問題点を抱えています。

   ・保守、開発しているシステムが多数あるが、システムごとに開発環境を用意しており、OSM/W

  フレームワーク、開発言語などさまざまで、環境が乱立している。

 ・システムごとに環境や手順が異なるため、ナレッジを共有できず属人化している。

  (サーバ環境だけでなく、ローカル端末の開発環境も様々で、自分のPCは色んなツールがいっぱいで動きが重い。) 


OpenShiftを利用することにより、乱立する環境を整備し、かつ、容易に環境を構築することができれば、

無駄なコストは大幅に軽減されるのではないか、という期待を持てます。

したがって、まずはOpenShiftを触ってみて、基本的な機能でどこまで改善できるのかを探ってみました。


OpenShiftの利便性

OpenShiftというか、まずはコンテナの魅力として、HWOSとの依存関係が切り離されることにより、

これらを意識しなくて済むことです。

アプリケーションとその実行環境だけを意識すればよいので、かなり楽になります。
20180209-01


さらに、OpenShiftでは、これらのContainerPodという単位でラッピングし、各Node内に配置、

Masterで管理することができます。

また、下記図には記載されていませんが、OpenShift上にデプロイされるアプリケーションやPod

その他のリソースはプロジェクトという論理的な単位で管理しています。

ProjectPodの作成はWebコンソール画面から非常に簡単に実行することができます。

※次章をご参照ください。

20180209-02

ProjectPodの作成手順

それでは、実際にProjectPodを作成してみたいと思います。


Project/Podの作成

01.Openshift Web ConsoleにてCreate Projectボタンを押下して新プロジェクト作成画面へ

20180209-03

02. 必要項目を入力してプロジェクトを作成

20180209-04

03. テンプレートを元にコードをビルド&デプロイ

 今回はOpenshift側で用意されたRubyのサンプルプロジェクトを自分のgithubforkしたものを

 使用します。カタログが表示されるので「Ruby」を選択。


20180209-05


04. アプリケーション設定画面が表示されるので、「Name」にアプリケーション名、

  「Git Repository URL」にソースのあるGithubURLを入力します。

  ※これでGitとの連携ができちゃいます。

20180209-06

05. 上記画面で「advanced options」のリンクをクリックすると、Gitのブランチ、タグからの

  ビルド&デプロイなど、さらに詳細な設定ができます。

  ※設定項目は多岐にわたるため、下記画面は中略しています。

20180209-07

06. Create」ボタンを押下するとPodのビルド&デプロイが開始されます。


07. Continue to overview」のリンクをクリックしてProjectの画面に移動します。

20180209-09

08. アプリケーションのビルドが完了したことを確認する。Podが立ち上がっていることが

  確認できたら、ROUTES External Traffic」に表示されたURLをクリックし、

  アプリケーションにアクセスできるか確認します。

  ※以上でProjectの作成は完了です。Podも作成されます。(とても簡単です!)

20180209-10



Podの操作

次にProject内にあるPodを操作してみたいと思います。

 

Podのスケールアップ】

Podの追加・削除は、Pod数が表示されたリングの右側にあるスケールアップ、スケールダウン

の矢印をクリックするだけで可能です。

内部的なことは意識せずにPodが追加され、アクセスするURLも変化しません。

こうして複数のPodを作成すると、自動的に負荷分散もしてくれるようです。

20180209-11

Gitのブランチ、タグからのビルド&デプロイ】

アプリケーション設定画面で「advanced options」のリンクをクリックし、「Git Reference

の部分にタグを入力することでGitレポジトリ内のタグ・ブランチを指定してアプリケーション

をデプロイすることもできます。


20180209-12

一度作成したPodOpenShiftの別Projectでビルドされたイメージを指定して

デプロイすることもできます。

これを応用すればテスト環境は開発環境と別Projectにすることができます。

別Projectで「Add to Project」→「Deploy Image」を選択します。

20180209-13

Projectの左メニューから「Resources」→「Membership」を選択するとMembershipの設定画面

となるので、プルを行うProjectdefaultサービスアカウントに対しsystem:image-puller

の権限を付与します。

この後、改めて上記画面から設定を行い「Create」ボタンを押下するとビルド&デプロイが行われます。

20180209-14

ビルドデプロイが完了しましたが、Routeが作成されていないので「Create Route」をクリックして
Routeを作成します。

20180209-15

Createボタンを押下するとRouteが作成されます。

20180209-16

20180209-17

URLが生成されるのでクリックしてアプリケーションにアクセスすることを確認します。

20180209-18


※これでGitのブランチ、タグからのビルド&デプロイは完了です。(これも簡単です!)

20180209-19



 ここまでの感想

実際にProjectPodを作成してみて、とにかく操作は簡単でした。

また、Container ではHWOSを意識しなくていいということは冒頭でも記載しましたが、

OpenShiftを利用することにより、Podの増量によるスケールアウトがとても簡単に実行でき、

さらに、アプリケーションがURLで公開されることにより、IPアドレスも意識しなくて済みます。

※本ブログを掲載するにあたり、弊社ではOpenShiftの環境構築から実施していますが、

 アプリケーション開発者であり、環境構築には疎いため、非常に苦労しましたが、

 こういった形で環境を構築できることはすごく管理も楽であり、助かりますね。

※今回は試すことができていませんが、Containerが落ちた際に自動的に再起動してくれたり、

 アクセス数が増えてきた場合に自動的にContainerを追加してくれたりもするようです。

20180209-20
 

開発プロジェクトでどう使うか

では、弊社のようなアプリケーション開発ベンダーが、社内の開発環境としてOpenShiftを利用する場合、

どういった利用方法がいいか、少し考察してみました。


まず、弊社でよくある開発パターンとして、以下のような例を挙げます。

 1)   開発メンバーがローカルPC上に環境を構築し、開発・単体テストはローカルPCで実施する。

 2)   結合テストは社内の仮想サーバ上に構築し、各メンバーで共有する。

 3)   Gitによるソース管理は、本番用ブランチ、結合テスト用ブランチ、開発メンバー用ブランチ

    に分かれている。

    →開発メンバー用ブランチは各開発メンバー単位で用意し、開発・単体テストまで実施。

    →結合テスト用ブランチは、開発メンバー用ブランチにてソースレビュー後にマージされ、

     結合テスト環境にビルド、デプロイする。

    →本番用ブランチは、結合テスト完了後に結合テスト用ブランチよりマージされ、

     お客様環境にビルド、デプロイする。


これをOpenShiftを利用して開発する場合、以下のように改善が可能であると思われます。

 1)   開発メンバーのローカルPCへの負荷が軽減される。また、OpenShiftへのアクセスもURLで可能であり、

    Podの追加やスケールアウトも可能。

 2)   Projectを分けることにより、管理者により各メンバーの権限を制御することができる。

 3)   Podは対応したブランチと紐づけることができるため、ブランチにPushすれば各Podへ自動的に

    ビルド、デプロイされるため、手動での作業が不要となる。

20180209-21



開発プロジェクトで使う際の課題

とはいえ、課題もいくつか見えてきました。現状以下の課題(疑問点)があり解決できていません。

これについては、今後継続して調査、検証してみたいと思っています。

 

DBサーバをOpenShift外に設置する必要がある

 上述の通り、OpenShiftではIPアドレスを意識しなくてよい仕様となっています。

 その場合、アプリケーションサーバからDBサーバへの接続についてIPアドレスで接続することが

 出来なくなります。

 その場合、特にJavaで開発されている環境などでは、例えば、DBIPアドレスを格納したOS環境変数

 を元にDBサーバと接続するような処理をアプリケーション側で実装する必要があると思われます。

 

【後日談】

 Redhatに確認したところ、「OpenShiftでは同一プロジェクト内のPod間は、サービス名をホスト名

 として利用することができるため、それを使ってアクセスすることができる。」とのこと。

 したがって、このサービス名をJDBC URLのホスト名として設定するなどにより対応が可能となる。

 上述の弊社の課題(疑問点)としては、IPアドレスを意識しなくてよい(=IPアドレスが見えない)ため、
 例えばOpenShift内でDHCP的な動きをしているなどにより、名前解決ができないなどの問題があるかもしれない
 との懸念があって記載していましたが、上記のRedhatからの回答により解決できるものと思います。

 

Dockerimportができていない

 OpenShift外にあるDockerイメージを、OpenShift内に移行しようとした場合、OS、ミドルウェアなど

 のインフラ部分Docker側でイメージ化し、Gitなどとの連携情報についてはOpenShiftにてテンプレート

 として取り込むなどの考慮が必要と思われる。

 そのため現状、Dockerイメージの取込みまでは正常に実行できるが、アプリケーションとして正常に接続が出来ない

 事象が発生している。

 ※Webコンソール画面からの操作で、容易に実行できないものだろうか・・・。

 

【後日談】

 OpenShiftのWebコンソール画面から移行することができるかと思っていましたが、

 Redhatに確認したところ、Gitリポジトリの情報をBuildConfigで定義し、s2iビルド

 にて実行するとのことでした。

 改めてこの方法で検証したいと思います。
     
 

次回の内容

4回のブログ内容は以下を予定しています。

  記事内容 :「OpenShift上のアプリケーション環境を運用する」という観点で、以下のような目的で

        OpenShift触ってみます。

          ・自動的なスケールアウト

          ・自動的なビルド、デプロイ

        など

  公開予定 :2018/2中旬
お問い合わせ

問い合わせボタン

RHEL サポート

最近の更新
コンテナアプリケーションプラットフォーム「Red Hat OpenShift」を触ってみた Vol.3 2018年02月13日
Red Hat InsightsのPlanner機能 2018年02月08日
コンテナアプリケーションプラットフォーム「Red Hat OpenShift」を触ってみた Vol.2 2017年11月21日
コンテナアプリケーションプラットフォーム「Red Hat OpenShift」を触ってみた Vol.1 2017年11月07日
ホネまでしゃぶろう、Red Hatサポート 2017年09月21日
パフォーマンスチューニングを自動化するtuned 2017年08月10日
継続的な学習を実現する Red Hat Learning Subscription 2017年07月07日
Red Hat Enterprise Linux 7.4 public betaがでました 2017年05月26日
Automation with Ansibleコース(DO407 :4日間)のご紹介 2017年04月26日
RHELで新しいgitやPython3を使うには? 2017年03月29日
AnsibleとRed Hat Identity Managementを併用すると便利 2017年02月28日
Red Hat Satellite 6でerrataを適用してみる 2016年11月28日
VMware環境上でのRed Hat Enterprise Linux 7.2以前から7.3へアップデート時の注意点と、その解説 2016年11月24日
RHEL4の延長サポートおよびRHEL5の通常サポート終了 2016年10月17日
Red Hat Enterprise Linuxの互換性維持 2016年08月31日
RED HAT FORUM 2016 Tokyo The power of participation -アイデアとテクノロジーが生むオープンイノベーションの破壊力- 2016年08月12日
Red Hat Network ClassicからRed Hat Subscription Managementへ移行のおねがい 2016年07月27日
ABRTで障害時の情報収集とレポートを自動化しよう 2016年06月03日
Red Hat Enterprise Linux 7、使ってますか? 2016年04月27日
Red Hat Developer Programに参加して開発者用サブスクリプションを入手しよう 2016年04月01日