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

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

はじめに

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

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

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

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

   ・保守、開発しているシステムが多数あるが、システムごとに開発環境を用意しており、OS、M/W、
フレームワーク、開発言語などさまざまで、環境が乱立している。

 ・システムごとに環境や手順が異なるため、ナレッジを共有できず属人化している。
(サーバ環境だけでなく、ローカル端末の開発環境も様々で、自分のPCは色んなツールがいっぱいで動きが重い。)

OpenShiftを利用することにより、乱立する環境を整備し、かつ、容易に環境を構築することができれば、無駄なコストは大幅に軽減されるのではないか、という期待を持てます。

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

OpenShiftの利便性

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

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

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

openshift-20180213-01

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

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

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

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

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

※次章をご参照ください。
 openshift-20180213-02

ProjectやPodの作成手順

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

◆Project/Podの作成

01.Openshift Web ConsoleにてCreate Projectボタンを押下して新プロジェクト作成画面へ
openshift-20180213-03
02. 必要項目を入力してプロジェクトを作成
openshift-20180213-03-01

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

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

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

openshift-20180213-04

04. アプリケーション設定画面が表示されるので、「Name」にアプリケーション名、「Git Repository URL」にソースのあるGithubのURLを入力します。

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

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

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

  ※設定項目は多岐にわたるため、下記画面は中略しています。
openshift-20180213-06
06. 「Create」ボタンを押下するとPodのビルド&デプロイが開始されます。
openshift-20180213-07
07. 「Continue to overview」のリンクをクリックしてProjectの画面に移動します。
openshift-20180213-08

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

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

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

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

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

 

【Podのスケールアップ】

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

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

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

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

openshift-20180213-10

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

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

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

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

openshift-20180213-11

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

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

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

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

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

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

の権限を付与します。

この後、改めて上記画面から設定を行い「Create」ボタンを押下するとビルド&デプロイが行われます。
openshift-20180213-13
ビルドデプロイが完了しましたが、Routeが作成されていないので「Create Route」をクリックして
Routeを作成します。
openshift-20180213-14
Createボタンを押下するとRouteが作成されます。
openshift-20180213-15
openshift-20180213-16
URLが生成されるのでクリックしてアプリケーションにアクセスすることを確認します。
openshift-20180213-17
※これでGitのブランチ、タグからのビルド&デプロイは完了です。(これも簡単です!)
openshift-20180213-18

 ここまでの感想

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

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

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

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

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

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

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

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

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

openshift-20180213-19

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

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

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

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

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

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

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

に分かれている。

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

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

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

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

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

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

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

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

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

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

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

openshift-20180213-20

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

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

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

 

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

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

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

出来なくなります。

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

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

 

【後日談】

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

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

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

 

②Dockerのimportができていない。

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

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

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

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

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

 

【後日談】

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

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

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

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

次回の内容

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

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

OpenShiftを触ってみます。

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

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

など

ご覧いただきありがとうございます! この投稿は役に立ちましたか? 役に立った 役に立たなかった

Be the first to comment

コメント投稿

Your email address will not be published.


*