はじめに
本連載はサイオスグループのキーポート・ソリューションズの開発プログラマーが、コンテナアプリケーションプラットフォーム「Red Hat OpenShift」（以降、「OpenShift」と記載）を触ってみて、その概要と感想をご紹介します。（普段はアプリケーション開発に従事しているため、OS、ミドルウェアについては決して得意ではない筆者です。）
第3回目のテーマは「開発」。開発ベンダーの立場から社内にてアプリケーション開発を行うにあたり、OpenShiftを利用することにより、どのようなメリットがあるのか、どのような不明点や課題があるのかを洗い出そうという主旨です。
アプリケーション開発における問題点
普段アプリケーション開発に従事している弊社では、以下のような問題点を抱えています。
・保守、開発しているシステムが多数あるが、システムごとに開発環境を用意しており、OS、M/W、
フレームワーク、開発言語などさまざまで、環境が乱立している。
・システムごとに環境や手順が異なるため、ナレッジを共有できず属人化している。
（サーバ環境だけでなく、ローカル端末の開発環境も様々で、自分のPCは色んなツールがいっぱいで動きが重い。）
OpenShiftを利用することにより、乱立する環境を整備し、かつ、容易に環境を構築することができれば、
無駄なコストは大幅に軽減されるのではないか、という期待を持てます。
したがって、まずはOpenShiftを触ってみて、基本的な機能でどこまで改善できるのかを探ってみました。
OpenShiftの利便性
OpenShiftというか、まずはコンテナの魅力として、HW、OSとの依存関係が切り離されることにより、
これらを意識しなくて済むことです。
アプリケーションとその実行環境だけを意識すればよいので、かなり楽になります。
さらに、OpenShiftでは、これらのContainerをPodという単位でラッピングし、各Node内に配置、
Masterで管理することができます。
また、下記図には記載されていませんが、OpenShift上にデプロイされるアプリケーションやPod、
その他のリソースはプロジェクトという論理的な単位で管理しています。
ProjectやPodの作成はWebコンソール画面から非常に簡単に実行することができます。
ProjectやPodの作成手順
それでは、実際にProjectやPodを作成してみたいと思います。
◆Project/Podの作成
03. テンプレートを元にコードをビルド＆デプロイ
今回はOpenshift側で用意されたRubyのサンプルプロジェクトを自分のgithubにforkしたものを
使用します。カタログが表示されるので「Ruby」を選択。
04. アプリケーション設定画面が表示されるので、「Name」にアプリケーション名、「Git Repository URL」にソースのあるGithubのURLを入力します。
05. 上記画面で「advanced options」のリンクをクリックすると、Gitのブランチ、タグからの
ビルド＆デプロイなど、さらに詳細な設定ができます。
08. アプリケーションのビルドが完了したことを確認する。Podが立ち上がっていることが
確認できたら、「ROUTES External Traffic」に表示されたURLをクリックし、
アプリケーションにアクセスできるか確認します。
◆Podの操作次にProject内にあるPodを操作してみたいと思います。
【Podのスケールアップ】
Podの追加・削除は、Pod数が表示されたリングの右側にあるスケールアップ、スケールダウン
の矢印をクリックするだけで可能です。
内部的なことは意識せずにPodが追加され、アクセスするURLも変化しません。
こうして複数のPodを作成すると、自動的に負荷分散もしてくれるようです。
【Gitのブランチ、タグからのビルド＆デプロイ】
アプリケーション設定画面で「advanced options」のリンクをクリックし、「Git Reference」
の部分にタグを入力することでGitレポジトリ内のタグ・ブランチを指定してアプリケーション
をデプロイすることもできます。
一度作成したPodはOpenShiftの別Projectでビルドされたイメージを指定して
デプロイすることもできます。
これを応用すればテスト環境は開発環境と別Projectにすることができます。
Projectの左メニューから「Resources」→「Membership」を選択するとMembershipの設定画面
となるので、プルを行うProjectのdefaultサービスアカウントに対し「system:image-puller」
の権限を付与します。
ここまでの感想
実際にProjectやPodを作成してみて、とにかく操作は簡単でした。
また、Container ではHW、OSを意識しなくていいということは冒頭でも記載しましたが、
OpenShiftを利用することにより、Podの増量によるスケールアウトがとても簡単に実行でき、
さらに、アプリケーションがURLで公開されることにより、IPアドレスも意識しなくて済みます。
※本ブログを掲載するにあたり、弊社ではOpenShiftの環境構築から実施していますが、
アプリケーション開発者であり、環境構築には疎いため、非常に苦労しましたが、
こういった形で環境を構築できることはすごく管理も楽であり、助かりますね。
※今回は試すことができていませんが、Containerが落ちた際に自動的に再起動してくれたり、
アクセス数が増えてきた場合に自動的にContainerを追加してくれたりもするようです。
開発プロジェクトでどう使うか
では、弊社のようなアプリケーション開発ベンダーが、社内の開発環境としてOpenShiftを利用する場合、
どういった利用方法がいいか、少し考察してみました。
まず、弊社でよくある開発パターンとして、以下のような例を挙げます。
１） 開発メンバーがローカルPC上に環境を構築し、開発・単体テストはローカルPCで実施する。
２） 結合テストは社内の仮想サーバ上に構築し、各メンバーで共有する。
３） Gitによるソース管理は、本番用ブランチ、結合テスト用ブランチ、開発メンバー用ブランチ
に分かれている。
→開発メンバー用ブランチは各開発メンバー単位で用意し、開発・単体テストまで実施。
→結合テスト用ブランチは、開発メンバー用ブランチにてソースレビュー後にマージされ、
結合テスト環境にビルド、デプロイする。
→本番用ブランチは、結合テスト完了後に結合テスト用ブランチよりマージされ、
お客様環境にビルド、デプロイする。
これをOpenShiftを利用して開発する場合、以下のように改善が可能であると思われます。
１） 開発メンバーのローカルPCへの負荷が軽減される。また、OpenShiftへのアクセスもURLで可能であり、
Podの追加やスケールアウトも可能。
２） Projectを分けることにより、管理者により各メンバーの権限を制御することができる。
３） 各Podは対応したブランチと紐づけることができるため、ブランチにPushすれば各Podへ自動的に
ビルド、デプロイされるため、手動での作業が不要となる。
開発プロジェクトで使う際の課題
とはいえ、課題もいくつか見えてきました。現状以下の課題（疑問点）があり解決できていません。
これについては、今後継続して調査、検証してみたいと思っています。
①DBサーバをOpenShift外に設置する必要がある？
上述の通り、OpenShiftではIPアドレスを意識しなくてよい仕様となっています。
その場合、アプリケーションサーバからDBサーバへの接続についてIPアドレスで接続することが
出来なくなります。
その場合、特にJavaで開発されている環境などでは、例えば、DBのIPアドレスを格納したOS環境変数
を元にDBサーバと接続するような処理をアプリケーション側で実装する必要があると思われます。
【後日談】
Redhatに確認したところ、「OpenShiftでは同一プロジェクト内のPod間は、サービス名をホスト名
として利用することができるため、それを使ってアクセスすることができる。」とのこと。
②Dockerのimportができていない。
OpenShift外にあるDockerイメージを、OpenShift内に移行しようとした場合、OS、ミドルウェアなど
のインフラ部分はDocker側でイメージ化し、Gitなどとの連携情報についてはOpenShiftにてテンプレート
として取り込むなどの考慮が必要と思われる。
※Webコンソール画面からの操作で、容易に実行できないものだろうか・・・。
【後日談】
OpenShiftのWebコンソール画面から移行することができるかと思っていましたが、
Redhatに確認したところ、Gitリポジトリの情報をBuildConfigで定義し、s2iビルド
にて実行するとのことでした。
改めてこの方法で検証したいと思います。
