2018年 2月 の投稿一覧

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

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

はじめに

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

第4回目のテーマは「運用」。開発ベンダーの立場からアプリケーション環境を管理、運用するにあたり、OpenShiftを利用することにより、どのようなメリットがあるのか、どのような不明点や課題があるのかを考察しようという主旨です。

運用におけるよくある問題点

開発ベンダーとしてアプリケーション開発に従事している弊社が、お客様と開発プロジェクトを進める際に、色々と問題点があります。

特に弊社は金融機関のお客様との取引が多いのですが、下記のような問題点は顕著に見られます。

・まず、開発プロジェクトにおいてアプリケーション開発とインフラ環境構築は多くの場合、別の担当者が実施

するため、アプリケーションとインフラの線引きが明確にされており、壁を感じることが多々あります。

この壁は運用フェーズに移行してからも残ることが多く、運用担当者はアプリケーション担当、インフラ担当

それぞれから引き継いだ内容を元に運用を行います。

そのため、どうしても申請や手続きが煩雑、かつ、慎重となり、対応が遅くなってしまいます。

・インフラ環境をスケールアウトしたいと思った場合、構成によってはミドルウェアやアプリケーションにまで

影響が及ぶこともあり、また、スケールアウト自体も運用監視や障害対応手順などの見直しも必要となり、

かなり負荷のかかる作業になってしまうことが多々あります。

運用時に便利な機能と手順

OpenShiftでは、テンプレートを事前に用意しておくことで、容易に外部の環境を移行したり新規環境を構築することができます。

また、ビルド&デプロイといった開発担当者に依存せざるを得ない作業も、コンフィグ設定しておくことで自動化することができます。

今回は、以下の作業について検証してみました。

 

①    OpenShift外にある既存のDockerコンテナをOpenShift内に移行する。

②    Podのオートスケール

③    ビルド&デプロイの自動化

 

本ブログでは上記のうち、①・②の手順をご紹介したいと思います。

①   OpenShift外にある既存のDockerコンテナをOpenShift内に移行する。

registry-consoleを開き今回使いたいUbuntu用のイメージストリームを作っておく。

registry-consoleにログインしてプロジェクト「openshift」を選択し、「新規イメージストリーム」からイメージストリームを作成する。

イメージがプルされているのを確認。

githubにプロジェクトを作成し、必要なファイルを配置する。

Dockerfileはトップに配置し、Webサーバ用のコンテンツをhtmlフォルダ以下に置いておく。

(基本的にはローカルでDockerコンテナをビルドするときと同じフォルダ構成にする)

その他Dockerコンテナに必要なファイルがあればそれも置いておく。(今回はApache起動用のrun-apache2.sh)

 

Dockefileを修正する。

※「#ベースイメージの指定」にて、イメージの取得元を外部Docker Hubのパスから内部Openshiftのパスに

変更する。

# ベースイメージの指定

FROM openshift/ubuntu:14.10

 

# 作者情報

MAINTAINER keyportsolutions XXXXXXXXX@keyportsolutions.com

 

# 必要なファイルのインストール

USER root

RUN sudo sed -i -e ‘s;utopic;trusty;g’ /etc/apt/sources.list

RUN apt-get -o Acquire::http::proxy=”http://proxy.fiosys.co.jp:8080″ update

RUN apt-get -o Acquire::http::proxy=”http://proxy.fiosys.co.jp:8080″ -y install apache2

COPY ./html /var/www/html/

COPY ./run-apache2.sh /tmp/

RUN chmod 755 /tmp/run-apache2.sh

EXPOSE 80

CMD /tmp/run-apache2.sh

Openshift用のテンプレートを作成する。

※下記yaml形式の場合インデントを厳密にみるので注意すること。

apiVersion: v1
items:
– apiVersion: V1
kind: ImageStream
metadata:
name: ubuntu-apache
– apiVersion: V1
kind: BuildConfig
metadata:
annotations:
description: Ubuntu Apache test
labels:
app: ubuntu-apache
name: ubuntu-apache
spec:
output:
to:
kind: ImageStreamTag
name: ubuntu-apache:latest
source:
git:
uri: https://github.com/アカウント名/openshift-test1.git
type: Git
strategy:
dockerStrategy:
from:
kind: ImageStreamTag
name: ubuntu:14.10
namespace: openshift
type: Docker
triggers:
– type: ImageChange
– type: ConfigChange
– apiVersion: V1
kind: DeploymentConfig
metadata:
annotations:
description: Ubuntu Apache test
labels:
app: ubuntu-apache
name: ubuntu-apache
spec:
template:
metadata:
labels:
name: ubuntu-apache
spec:
containers:
– name: ubuntu-apache-latest
image: ubuntu-apache:latest
ports:
– containerPort: 80
protocol: TCP
replicas: 1
selector:
name: ubuntu-apache
triggers:
– type: ImageChange
imageChangeParams:
automatic: true
containerNames:
– ubuntu-apache-latest
from:
kind: ImageStreamTag
name: ubuntu-apache:latest
– type: ConfigChange
– apiVersion: V1
kind: Service
metadata:
annotations:
description: Ubuntu Apache test
labels:
app: ubuntu-apache
name: ubuntu-apache
spec:
ports:
– name: web
port: 80
targetPort: 80
selector:
name: ubuntu-apache
– apiVersion: V1
kind: Route
metadata:
name: ubuntu-apache
spec:
host: ubuntu-test.dev.openshift.fiosys.co.jp
to:
kind: Service
name: ubuntu-apache
kind: List
metadata: {}

作ったテンプレートのyamlファイルを元にビルド&デプロイする。

Create Projectボタンを押下して新プロジェクト作成画面へ。

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

今回は自作のテンプレートから作成するので「Import YAML / JSON」タブをクリック。

先ほど作成したテンプレートを貼りつける。

Createを押下すると文法的にOKならビルド&デプロイが開始される。

ビルド&デプロイが完了。

リンクから自分が配置したindex.htmlにアクセスできることを確認。

②   Podのオートスケール

※オートスケールを設定するには、Metrics Plugin が有効になっていることが前提となります。

 

プロジェクトの画面でApplication→Deploymentをクリックしてデプロイメントの一覧を表示する。

対象のデプロイメントの名前をクリック。

Configurationをクリック。

 

Actions→Edit Resource Limitsを選択する。

 

CPU使用率の上限を設定しておく。(今回は1コアまで)

設定後再デプロイされるので完了後もう一度デプロイメントの画面にもどる。

Add Autoscalerをクリック。

ポッド数とオートスケールされる条件となるCPU使用率を入力するとオートスケールが追加される。

運用を効率化するには

上記でご紹介したOpenShift のテンプレートによる環境構築、オートスケール、ビルド&デプロイの自動化などにより、前述の問題点は解決できるのではないかと感じました。

まず、アプリケーションとインフラの壁の問題については、テンプレートによる環境構築の簡易化、およびビルド&デプロイの自動化により、インフラ担当者や開発担当者でなければ作業ができないという状況を変えることができます。

また、OpenShiftという共通の基盤を使用することにより手順も一元化されるため、運用作業における専門性が軽減されます。

申請や手続き等が煩雑になる理由として、作業に専門性が必要になることや、手作業が多々必要となることが挙げられますので、自動化により申請や手続き等も簡易化し、迅速な対応が可能となります。

また、Redhat Ansibleと組み合わせることにより、パッチを適用しテストを実施するところまでを含めた自動化なども可能にできそうなので、さらなる効率化、自動化が図れそうです。

 

次に、やはりオートスケール機能については、かなり有効な機能だと思います。

前述の通り、インフラ環境のスケールアウトはかなり作業負荷が大きいものなので、オートスケールにより許容する範囲内でのスケールアウトは全てOpenShiftに任せてしまうことができます。

これは単にスケールアウトにかかる作業の軽減だけではなく、運用監視についても大きな改善をもたらすと考えられます。

今なお多い運用監視方法としては、CPU、メモリ、DISKなどの使用率を常時監視し、一定の使用率を超えたらアラートを鳴動させ検知するというものですが、オートスケールとなることで少なくともOpenShift内に設置されているシステム環境ごとの監視という点においては、リソースの枯渇を防ぐための監視ではなく、システムのパフォーマンスを最適にするための監視として運用することができます。

これにより、運用監視にかかる作業コストは、よりサービスレベルを維持、向上させるための高度な作業に集中させることができますし、運用コストも大幅に軽減されるのではないかと思います。

それ以外にも上述のようなOpensShiftの機能を活用すれば、例えば、本番環境と同等の開発環境を用意しておくことにより、システム変更が発生した場合に、開発環境にて更新されたものをそのまま本番環境に反映するようなことも可能です。

うまく機能を活用することでテストなど手作業に依存しがちな作業も大幅に軽減することができますし、かなり有効だなと思います。

さいごに

今回、環境構築、開発、運用という観点でOpenShiftを実際に触ってみて、その機能を検証してみました。

正直検証を始める前は、OpensShiftがどのようにDevOpsにつながっていくのか、資料上ではなんとなく理解はしているもののあまり明確なイメージはできていませんでした。

特に、環境構築については、インフラ知識が乏しかったこともあり、かなり苦戦し、色々な勘違いや認識不足もあったため、やはりベースとなる知識が必要であると感じました。

 

開発という観点では、Gitとの連携やビルド&デプロイが非常に簡単に実行できることにちょっとした感動を覚えました。

上述の通り、インフラ知識が不足しているため、OpenShiftによりIPアドレスなどOSレベルの挙動を意識する必要がないことも、開発を実施する上で非常に楽であると実感しました。

また、運用という観点では、特に弊社のようなアプリケーション開発をやっている立場としては、正直どうしても「インフラは担当外だ」、「運用は担当外だ」という思考になりがちで、それが壁になってしまっているために、「DevOps」のイメージがいまいち明確に沸いてこないところがありました。(これは反省すべき点です。)

しかし、実際に触ってみることで、そのような専門外の部分の処理も含めてOpenShiftが実行してくれることで、インフラとか運用とかあまり意識しなくてもいいということを実感することができ、壁が取れそうな気がしています。

 

昨今DevOpsというキーワードをよく目にしますが、まだまだ身近なものだと理解している人は少ないようにも思えますが、それはきっとインフラ担当・開発担当・運用担当の間に距離感や壁のようなものがあるからなのかもしれません。

OpenShiftがそのような壁を取り払ってくれるのではないかと、今回の検証を通して感じました。

コンテナアプリケーションプラットフォーム「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では、これらのContainerをPodという単位でラッピングし、各Node内に配置、

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

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

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

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

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

ProjectやPodの作成手順

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

◆Project/Podの作成

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

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

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

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

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

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

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

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

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

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

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

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

  ※以上でProjectの作成は完了です。Podも作成されます。(とても簡単です!)
◆Podの操作次にProject内にあるPodを操作してみたいと思います。

 

【Podのスケールアップ】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

の権限を付与します。

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

 ここまでの感想

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

に分かれている。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

①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ビルド

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

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

Red Hat InsightsのPlanner機能

Red Hat Insightsに最近追加されたPlanner機能を紹介します。

レッドハットの森若です。

2年ほど前にこのblogの記事で Red Hat Insights をご紹介しましたが、最新のバージョンでは計画的な運用を助けるために活用できる「Planner」という機能が追加されています。この記事ではRed Hat InsightsのPlanner機能を中心として、最近のアップデートをご紹介します。

計画的な保守の重要性

ソフトウェアに限った話ではありませんが、システムの重大な障害を予防するためには計画的な保守が重要になります。いわゆる「重大なシステム障害」のほとんど(Red Hatサポート部門の知見ではおよそ85%)は既知の問題が重要なシステムで発生したもので、既に他のシステムで発生していてなんらかの緩和策・解決策が提供されているものです。

最新の知見をもとに、問題が発生するより前に各種の対策を行うことができれば、重大なシステム障害の発生を大きく減らすことができるでしょう。

Red Hat Insightsとは

Red Hat Insightsは既知の問題がシステムに存在しないかをチェックするための情報を定期的に収集し、対策に役立つレポートを出力するSaaS型のシステム分析サービスです。主に以下のような情報を確認して、問題の説明や対策をレポートします。

  • インストールされているパッケージ
  • 設定ファイル
  • ログ出力
  • 統計情報
  • ファームウェアバージョンなどの情報
  • インストールされているサードパーティ製品

 

執筆時点でおよそ400種類の問題をチェックしており、この数は継続的に増えています。Red Hat Insightsをシステムの健康診断のように利用することで、多くの重大な障害を予防できます。

Red Hat InsightsのPlanner機能

さて、最近追加された Planner機能とは何でしょう?

これは非常に簡単な機能で、検出された多数の問題に対する対策から任意に選んだものを「Plan」と呼ばれるグループにまとめる機能です。

Red Hat Insightsで提示される各種の対策を実施するときには、対象となるシステムの特性や問題の重大さなどにあわせて作業計画を立て、それに従って作業を進めていくことになります。Plannerを使ってそれぞれの対策をPlanにまとめることで、あるタイミングで行う作業を簡単にまとめられます。

対策がAnsibleに対応していれば、Planごとに対策用のAnsible Playbookを生成する機能を持っています。検出される問題の中にはAnsibleで対応できないものも含まれる点にご注意ください。たとえば「ネットワークのチェックサムエラーがxx%発生しているので物理的な問題をチェックしたほうがいい」というような問題の対策にはAnsible Playbookは含まれません。

Planに登録された問題と対策はRed Hat Insightsに保存され、次回以降のスキャンでその問題が継続しているか、対策済みかトラッキングされます。これにより作業の抜け漏れを防ぐこともできます。

参考文献