はじめに
本連載はサイオスグループのキーポート・ソリューションズの開発プログラマーが、コンテナアプリケーションプラットフォーム「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使用率の上限を設定しておく。（今回は１コアまで）
設定後再デプロイされるので完了後もう一度デプロイメントの画面にもどる。
Add Autoscalerをクリック。
ポッド数とオートスケールされる条件となるCPU使用率を入力するとオートスケールが追加される。
運用を効率化するには
上記でご紹介したOpenShift のテンプレートによる環境構築、オートスケール、ビルド＆デプロイの自動化などにより、前述の問題点は解決できるのではないかと感じました。
まず、アプリケーションとインフラの壁の問題については、テンプレートによる環境構築の簡易化、およびビルド＆デプロイの自動化により、インフラ担当者や開発担当者でなければ作業ができないという状況を変えることができます。
また、OpenShiftという共通の基盤を使用することにより手順も一元化されるため、運用作業における専門性が軽減されます。
申請や手続き等が煩雑になる理由として、作業に専門性が必要になることや、手作業が多々必要となることが挙げられますので、自動化により申請や手続き等も簡易化し、迅速な対応が可能となります。
また、Redhat Ansibleと組み合わせることにより、パッチを適用しテストを実施するところまでを含めた自動化なども可能にできそうなので、さらなる効率化、自動化が図れそうです。
次に、やはりオートスケール機能については、かなり有効な機能だと思います。
前述の通り、インフラ環境のスケールアウトはかなり作業負荷が大きいものなので、オートスケールにより許容する範囲内でのスケールアウトは全てOpenShiftに任せてしまうことができます。
これは単にスケールアウトにかかる作業の軽減だけではなく、運用監視についても大きな改善をもたらすと考えられます。
今なお多い運用監視方法としては、CPU、メモリ、DISKなどの使用率を常時監視し、一定の使用率を超えたらアラートを鳴動させ検知するというものですが、オートスケールとなることで少なくともOpenShift内に設置されているシステム環境ごとの監視という点においては、リソースの枯渇を防ぐための監視ではなく、システムのパフォーマンスを最適にするための監視として運用することができます。
これにより、運用監視にかかる作業コストは、よりサービスレベルを維持、向上させるための高度な作業に集中させることができますし、運用コストも大幅に軽減されるのではないかと思います。
それ以外にも上述のようなOpensShiftの機能を活用すれば、例えば、本番環境と同等の開発環境を用意しておくことにより、システム変更が発生した場合に、開発環境にて更新されたものをそのまま本番環境に反映するようなことも可能です。
うまく機能を活用することでテストなど手作業に依存しがちな作業も大幅に軽減することができますし、かなり有効だなと思います。
さいごに
今回、環境構築、開発、運用という観点でOpenShiftを実際に触ってみて、その機能を検証してみました。
正直検証を始める前は、OpensShiftがどのようにDevOpsにつながっていくのか、資料上ではなんとなく理解はしているもののあまり明確なイメージはできていませんでした。
特に、環境構築については、インフラ知識が乏しかったこともあり、かなり苦戦し、色々な勘違いや認識不足もあったため、やはりベースとなる知識が必要であると感じました。
開発という観点では、Gitとの連携やビルド＆デプロイが非常に簡単に実行できることにちょっとした感動を覚えました。
上述の通り、インフラ知識が不足しているため、OpenShiftによりIPアドレスなどOSレベルの挙動を意識する必要がないことも、開発を実施する上で非常に楽であると実感しました。
また、運用という観点では、特に弊社のようなアプリケーション開発をやっている立場としては、正直どうしても「インフラは担当外だ」、「運用は担当外だ」という思考になりがちで、それが壁になってしまっているために、「DevOps」のイメージがいまいち明確に沸いてこないところがありました。（これは反省すべき点です。）
しかし、実際に触ってみることで、そのような専門外の部分の処理も含めてOpenShiftが実行してくれることで、インフラとか運用とかあまり意識しなくてもいいということを実感することができ、壁が取れそうな気がしています。
昨今DevOpsというキーワードをよく目にしますが、まだまだ身近なものだと理解している人は少ないようにも思えますが、それはきっとインフラ担当・開発担当・運用担当の間に距離感や壁のようなものがあるからなのかもしれません。
OpenShiftがそのような壁を取り払ってくれるのではないかと、今回の検証を通して感じました。
