コンテナプラットフォームのエンタープライズ活用における良いところ ～ OpenShift編 ～

TIS株式会社の斎藤辰徳です。前回は同主題のKubernetes編において「Kubernetesの良いところ」を書かせていただきました。今回は前回のまとめにも書かせていただいた通り、OpenShiftの良いところをご紹介いたします。

OpenShiftとは？ ～Kubernetesとの違い～

OpenShiftとはRed Hat社製のPaaS基盤ソフトウエア、あるいは同社が提供するPaaSそのものです。

PaaS基盤ソフトウエアとしては「Red Hat OpenShift Container Platform」と「OKD」があります。前者はRed Hat社による商用サポートのあるダウンストリーム版で、後者はオープンソースソフトウエアとしてのアップストリーム版となります。RHELとFedoraのような立ち位置ですね。

PaaSとしては「Red Hat OpenShift Online」と「Red Hat OpenShift Dedicated」があります。通常のパブリックPaaSが前者で専有型PaaSが後者になります。本記事ではエンタープライズ活用ということで、プライベートPaaSを構築したいというニーズが強いであろうことから、PaaS基盤ソフトウエアに焦点を当てて書かせていただきます。

そんなOpenShiftですが、v3からはKubernetesをベースにしており、PaaSとして必要な機能がKubernetesに付加されています。具体的には次のような機能が付加されています。

ソースコードからコンテナイメージをビルドする機能

ビルドされたコンテナイメージを保存しておくレジストリ機能

コンテナおよびクラスタのメトリクスを取得・可視化する機能

コンテナおよびクラスタのログを収集・可視化する機能

これらのKubernetesに対する付加機能、すなわちOpenShiftの良いところを順に説明していきます。

OpenShiftの良いところ

ソースコードからコンテナイメージをビルドする機能

前回も説明した通り、Kubernetesはあくまでコンテナオーケストレータであるため、起動するコンテナイメージは提供されている前提で動作します。このためソースコードをビルドし、出来上がったバイナリをコンテナイメージに焼き付けるような機能を備えていません。このような機能はPaaSとして必須の機能となります。OpenShiftでは素のKubernetesに対し、S2I(Source to Image)と呼ばれる当該機能を備えています。具体的にはソースコードを含んだGitリポジトリを指定し、「oc new-app」コマンドを実行すると、Gitリポジトリのソースコードがどんな言語で書かれているかを自動的に検出し、適切なビルドスクリプト実行を含んだ「docker build」が実行されます。これによって実行可能なバイナリを含むコンテナイメージが作成されます。

「oc new-app」コマンドはさらに、後述するOpenShiftクラスタ内部のDockerレジストリに作成されたコンテナイメージをpushし、Workerノード上で当該コンテナイメージからコンテナを実行させるところまで実施してくれます。

ビルドされたコンテナイメージを保存しておくレジストリ機能

OpenShiftはクラスタ内部にDockerレジストリをコンテナの形で持っています。OpenShiftではこれを「統合レジストリ」と呼んでいます。

主に統合レジストリはOpenShiftによってソースコードからビルドされたコンテナイメージを配置する場所として利用されます。Docker Hubのような外部レジストリを利用せずに統合レジストリに配置することで、イメージの変更をレジストリからOpenShiftに通知することができます。これにより修正されたソースコードから新バージョンのコンテナイメージをビルドした時、自動的に新バージョンのコンテナをデプロイし、旧バージョンのコンテナを削除するといった、デプロイの自動化を実施することができるようになります。

また統合レジストリはクラスタ内部に配置され、レイテンシが小さいため、ビルドしたコンテナイメージを迅速にWorkerノードに展開することも可能にします。

コンテナおよびクラスタのメトリクスを取得・可視化する機能

CPU・メモリ・ディスク使用率をはじめとした、コンテナおよびクラスタのメトリクスを取得し、可視化する機能をOpenShiftではインストールオプションの指定で簡単に有効化できます。OpenShiftのインストールには構成管理ツールであるAnsibleを利用するのですが、メトリクス取得・可視化機能制御のための専用playbookが用意されているため、ユーザは面倒なインストール作業をすることなくこれらの機能を有効化できます。

この機能により、コンテナの負荷状況によってコンテナの数を増減させるKubernetesの機能、HorizontalPodAutoscaler(HPA)をインストール後すぐに使い始めることができます。アクセス量の予測が難しいアプリケーションにとって、本機能はリソース最適化のために必須の機能となるでしょう。

なお、本機能のバックエンドとしてメトリクスの取得においてはPrometheusが、可視化においてはGrafanaが使用されています。またインストール時だけでなく任意のタイミングで本機能を追加、削除が可能です。

コンテナおよびクラスタのログを収集・可視化する機能

基本的にコンテナは必要な時に作成され、不要な時に削除される一時的なリソースです。このため何もしなければコンテナのログはコンテナの削除と同時に消えてしまいます。本番環境では、もしもの障害や障害予測のために、コンテナのログを収集、蓄積しておくことが重要になります。

OpenShiftではメトリクスと同様、ログを収集し、可視化する機能もインストールオプションの指定で簡単に有効化できます。ログの収集・可視化機能制御を行うAnsibleの専用playbookが用意されているからです。

本機能のバックエンドとしてログの取得においてはFluentdが、蓄積・分析にはElasticsearchが、可視化においてはKibanaが使用されています。メトリクスと同様、インストール時だけでなく任意のタイミングで本機能を追加、削除ができます。

まとめ

OpenShiftを利用すると、アプリケーションから見たインフラ部分、すなわちミドルウエアやOS、ハードウエアレイヤを抽象化することができ、開発者は本質的に行いたいロジックの作成に集中することができます。また開発者を支えるインフラ担当者のために、本番運用を見据えた必要な機能が盛り込まれています。開発サイクルを短くしたい、しかしオンプレミスで開発を行うことはポリシー上避けられない企業はOpenShift Container PlatformやOKDを活用してオンプレミスPaaSの構築を検討してみてはいかがでしょうか。

OpenShiftが他のPaaS製品・サービスと異なる点は「Kubernetesベース」であることです。このため、ソースコードが単に動けば良いのであれば、OpenShiftで拡張されているPaaSとしての機能を十分に活用すればよいでしょう。そうではなく、ミドルウエアのパラメータを調整するなどコンテナイメージも柔軟にコントロールしたければ、敢えてOpenShiftの拡張機能を利用せず、コンテナイメージをOpenShift外で作成、OpenShiftはコンテナオーケストレータとしてのみ利用するという使い方もできます。いわゆる「Container as a Service(CaaS)」としての使い方もOpenShiftならできるのです。PaaSの領域とCaaSの領域を同一プラットフォーム上で展開できることが、他のPaaS製品・サービスと異なるOpenShiftの一番の魅力ではないでしょうか。

関連リンク

IT-Exchange「Red Hat OpenShift」紹介ページ