Red Hat Openshift

【2018年9月13日開催】 実例紹介! Ansible自動化セミナー開催

Ansible自動化セミナー開催決定!

2018年9月13日に「実例紹介!3社共催 Ansible自動化セミナー」を三菱総研DCS様、レッドハット様と3社共同で開催します。

自動化導入の実例として三菱総研DCS様より「FINEQloud × AnsibleTower クラウド運用自動化への挑戦」を講演いただきます。そして、レッドハット様からはInfrastructure as Code / DevOpsをテーマにAnsible TowerとRed Hat OpenShiftの最新事例を紹介いただきます。今注目の技術に関する実例を知ることができるなりますので、ご興味をお持ちの方はぜひお誘い合わせの上でご登録をお願いいたします。

※セミナーへのご参加には、以下のURLから事前のご来場登録が必要となります。
「実例紹介!3社共催 Ansible自動化セミナー」
<URL> https://sios.secure.force.com/webform/SeminarDetail?id=701100000012QnNAAU

 

共催 三菱総研DCS株式会社 / レッドハット株式会社 / サイオステクノロジー株式会社
日時 2018年09月13日 (木) 15:30~18:15 受付開始 15:00
対象者 エンドユーザー企業及びSIerのOSSシステム管理者、情報システム部門、システムアーキテクト
講演内容 プログラム 15:00~

受付 15:30~15:40 オープニング

15:40~16:10  サイオステクノロジー講演

企業に求められる自動化
~現場の声から知る自動化の課題~

講師: IaC活用研究会員  サイオステクノロジー株式会社   イノベーティブソリューション事業企画部
村田 龍洋

16:10~16:55  三菱総研DCS講演

FINEQloud × AnsibleTower クラウド運用自動化への挑戦
~システム運用からのヒトの解放とガバナンス強化~

講師: 三菱総研DCS株式会社 技術推進事業本部 技術企画統括部事業企画グループ
西岡 裕子

16:55~17:05 休憩

17:05~17:50  レッドハット講演

Infrastructure as Code / DevOpsにおけるレッドハットの最新事例紹介
~自動化プラットフォーム Ansible TowerからエンタープライズKubernetes OpenShiftまで~

講師: レッドハット株式会社 プロダクトソリューション本部  クラウドビジネスデベロップメント  中村 誠

17:50~18:00  サービス紹介

18:00~18:15  Q&A クロージング

参加費 無料
締め切り 2018年09月13日
定員 80名
会場 レッドハット株式会社
東京都渋谷区恵比寿4-1-18 恵比寿ネオナート 3F
<アクセス> JR恵比寿駅 東口改札出口より徒歩2分
セミナー登録URL  https://sios.secure.force.com/webform/SeminarDetail?id=701100000012QnNAAU

コンテナアプリケーションプラットフォーム「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 OpenShift」を触ってみた Vol.2

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

はじめに

本連載はサイオスグループのキーポート・ソリューションズの開発プログラマーが、コンテナアプリケーションプラットフォーム「Red Hat OpenShift」(以降、「OpenShift」と記載)を触ってみて、その概要と感想をご紹介します。(普段はアプリケーション開発に従事しているため、OS、ミドルウェアについては決して得意ではない筆者です。)
第2回目のテーマは「環境構築」、サーバ環境の準備からOpenShiftのインストールまでをゴールとし、極力自力で構築してみて課題や問題点を洗い出そうという主旨です。

環境構築時の作業リスト

事前の準備なしに1から環境構築を実施して発生した作業項目と作業時間を下記に記載します。
様々なエラーが発生し、調査も含めかなりの時間を要しましたが、本記事が皆様のトラブルシューティングの参考にしていたければと思います。下記にに発生事象などをご紹介したいと思います。
事前に準備ができていた場合、実際の作業量としては半日もかからない内容であると思います。
  ※「今回の作業時間」・・・手探りながらもなんとか実施した環境構築にかかった実績時間。調査時間が大半・・・。
  ※「今後の想定時間」・・・今回の環境構築により作成した手順書を元に、次回以降できるであろう想定の構築時間。

事前準備

開発プログラマーの立場からすると、ある意味OpenShiftの勉強からのスタートでした。Dev/Opsという言葉もあるため、今後はこのような仕組みも理解しなければならないと痛感します。
下記に環境構築にあたり参照したサイトをご紹介しておきます。
  • OpenShift Container Platform 3.6 Installation and Configuration

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.6/pdf/installation_and_configuration/OpenShift_Container_Platform-3.6-Installation_and_Configuration-en-US.pdf

  • Install OpenShift Container Platform

https://docs.openshift.com/container-platform/latest/getting_started/install_openshift.html

次に、OpenShiftの推奨環境です。

要件

  • Red Hat Enterprise Linux 7.3 / 7.4
  • マスター:2vCPU、16GBメモリ
  • ノード:1vCPU、8GBメモリ
※All in One 構成も可能
上記の推奨環境を用意しようとしたのですが、弊社の諸事情によりMaster環境についてはメモリ8GBの環境しか用意できませんでした。

(このせいで後々ハマることには、この時点では気づきませんでした)
その後、RHEL 7.4 OSのインストールは難なく完了し、RHEL・OpenShiftのサブスクリプションも登録。
ちなみに、サブスクリプションは必ず登録しましょう!登録は以下のコマンドで簡単にできます。
#subscription-manager register
また、コマンドに慣れていない方はRHELのGUIからサブスクリプションメニューも用意されていますので、ご活用を。

OpenShiftインストールの前に

OpenShiftをインストール前にいくつかの設定が必要となります。
・DNSサーバの設定
  Master環境とNode環境をDNSサーバに登録する必要があります。
  
  MasterとNodeは互いにアクセスできるよう設定しておくことがポイントです。
  ちなみに、今回弊社では、外部からのOpenShift環境へのアクセスはさせたくなかったため、
      OpenShift環境(Master環境)内にDNSサーバを立てることにしました。
が、このせいで後々ハマッてしまうことに、現時点では気づきもしないのであった・・・。(その2)
・SSHの設定
  1. Node側のサーバでssh-keyを作成する。
#ssh-keygen
  2. 下記のコマンドを実行する
#ssh-copy-id -i ~/.ssh/id_rsa.pub XXX.XXX.XXX.XXX

・その他

  hosts設定、iptables設定等も実施。

 OpenShiftインストール

さあ、やっとOpenShiftのインストールです。
(事前確認から始めたため、ここまで来るのに数日かかりました・・・。自力で0から始めるのは大変ですね・・・。)
OpenShiftでは、いくつかのパッケージをインストールする必要があります。
ここでは詳細までは書ききれませんので、各パッケージのインストールコマンドのみ記載します。
なお、今回の環境構築では、アドバンスドインストールではなく、クイックインストールで実施しています。
※今回弊社では、詳細な手順書も作成していますが、それはまた別の機会に・・・。

1.パッケージインストール

ベースパッケージのインストール
→Master環境、Node環境それぞれで実行します。
yum install wget git net-tools bind-utils iptables-services bridge-utils bash-completion kexec-tools sos psacct
atomicパッケージのインストール
→Master環境、Node環境それぞれで実行します。
yum install atomic-openshift-utils
yum install atomic-openshift-excluder atomic-openshift-docker-excluder -y
システムパッケージのアップデート
→Master環境、Node環境それぞれで実行します。
yum update

2.Docker インストールと設定

dockerをインストール
→Master環境、Node環境それぞれで実行します。
yum install docker-1.12.6 -y
docker-storage設定
→Master環境、Node環境どちらかで実行すればOkです。
vim /etc/sysconfig/docker-storage-setup
docker-storage-setup

3.OpenShiftインストールと設定

OpenShift Container Platformをインストール
→Master環境、Node環境それぞれに対しインストールが必要ですが、片方のサーバにてまとめてインストールすることができます。
atomic-openshift-installer install
※インストール中の確認ポイント
→IPアドレスの入力を要求されます。このとき、Master環境のインストールか、Node環境のインストールか
 を質問されますので、まずはMaster環境をインストールします。
Enter hostname or IP address: 10.10.20.36
Will this host be an OpenShift master? [y/N]: y
→Master環境のインストールが完了すると、以下のサマリーが表示されます。
*** Installation Summary ***
Hosts:
– 10.10.20.36
  – OpenShift master
  – OpenShift node
  – Etcd
Total OpenShift masters: 1
Total OpenShift nodes: 1
NOTE: Add a total of 3 or more masters to perform an HA installation.
→続けて、ホストを追加するかどうかを質問されますので、次はNode環境をインストールします。
Do you want to add additional hosts? [y/N]: y
Enter hostname or IP address: 10.10.20.37
Will this host be an OpenShift master? [y/N]: n
→Node環境のインストールが完了すると、以下のサマリーが表示されます。
*** Installation Summary ***
Hosts:
– 10.10.20.36
  – OpenShift master
  – OpenShift node (Unscheduled)
  – Etcd
– 10.10.20.37
  – OpenShift node (Dedicated)
Total OpenShift masters: 1
Total OpenShift nodes: 2
NOTE: Add a total of 3 or more masters to perform an HA installation.
※「Hosts:」欄にNode側の環境も追加されています。
 また、「Total OpenShift nodes:」が「2」に増えていますね。
 なお、「Total OpenShift nodes:」が「2」になっている点についてですが、Master環境をインストールすると
 「1」となっているので、その際にNodeもインストールはされていますが、これはどうやらMaster環境が
 デフォルトでインストールするNodeであり、実際にユーザーが使用するNodeとは違うもののようです。

     ・・・こんなエラーが出ました!!

     
      推奨値である16GBに対し、5.8GBしかメモリがないよ!ということのようです。

推奨環境を用意できなかったツケが早速出てしまいました。

      調査したところ、インストール時にリソースの制限チェックが実行されており、これに引っかかってしまったことが判明。

下記の設定ファイルに対し、制限チェックをしない設定を追加し、なんとかクリアしました。

      ファイル名:「/root/.config/openshift/hosts」
      設定内容:
openshift_disable_check=disk_availability,memory_availability,docker_storage, docker_image_availability

4.疎通確認

      発生したエラーの調査も含め、3日間も費やしてしまいましたが、なんとかインストールが完了し、いざ疎通確認を開始。
      しかし、エラーは続けざまに発生するものです・・・。
NODEが”Ready”状態にならない!!
 
# oc get nodes
NAME                            STATUS                     AGE       VERSION
master.openshift.fiosys.co.jp   NotReady   16h       v1.6.1+5115d708d7
→調査したところ、OpenShiftでは全てのMaster、及びNodeでdnsmasqを使用するよう自動的に設定されますが、
 本事象では、こちらで立てたDNSサーバがポート53を使用しており、dnsmasqもポート53を使用するため、
 ポートが競合したために発生したものでした。

~参考~

※2 :
    
   ということで、気持ちとサーバをリフレッシュしようと、サーバを再起動して再度疎通確認を実施。
 すると、今度はNODE以前にOpenShift自体(Masterサービス)が起動しなくなってしまいました・・・。
 
  ※ちなみに正常に起動した場合は、下記のように表示されます。
 
再度調査を実施したところ、Master上で各NodeのPodやネットワーク情報を保持するetcdサーバがなぜか起動されていませんでした。
※おそらく自動起動するよう設定が必要と思われるが、今回はそこまでは調査できておりません。

手動でetcdサーバを起動することで、なんとかMasterサービスを起動することができました!

ということで、ついに環境構築が完了!
 
→「oc get nodes」コマンドでMaster、NodeともにReady状態になっていることを確認。
# oc get nodes
NAME                            STATUS                     AGE       VERSION
master.openshift.fiosys.co.jp   Ready,SchedulingDisabled   16h       v1.6.1+5115d708d7
node.openshift.fiosys.co.jp     Ready                      31m       v1.6.1+5115d708d7
 
→「oc get pods」コマンドでPodが稼働中であることを確認。


# oc get pods
NAME                       READY     STATUS    RESTARTS   AGE
docker-registry-1-3gnzp    1/1       Running   0          3m
registry-console-1-mm6dl   1/1       Running   0          4m
→ログイン画面を表示することが出来ました。
→ログインもできました!

→無事デプロイもできました!

注意すべきポイント(ハマッたことなど)

今回は普段よりアプリケーション開発に従事しており、ミドルウェアや基盤の構築はあまり経験がないメンバーにて
OpenShiftの環境構築を実施してみたのですが、かなり大変でした。
発生した事象は前述の通りですが、それ以外の細かい点も含め下記に記載しておきます。
  ●メモリ不足(制限チェックエラー)
   →推奨環境はきちんと守りましょう!
  ●Node状態が「Not Ready」になる事象(DNSサーバとポートが競合した事象)
   →用途が異なるものはサーバを分けましょう!
  ●サーバ再起動時にMasterサービスがactiveにならない
   →必要なプロセスはさらに勉強して把握しておきましょう!
  ●プロキシ設定に漏れがあった
   →Linuxをもっと勉強しましょう!

感想(大変だったことや今後の課題など)

今回環境構築を通してOpenShiftを触ってみて、感じたことを記載します。
  1.色んな参考サイトを見ながら構築作業を実施したが、そのまま利用できるものが見つからなかったため、
            やはり自分たちで手順書を作成する必要があると感じた。
  2.今回はクイックインストールで環境構築を実施したが、上述のエラーが発生した際に、
           その原因が分からず調査に苦労した。(実際にはRed Hatのサポートケースへの問合せも実施して対応)
    Red Hatの推奨はアドバンスドインストールとのことなので、今後改めて勉強し、理解する必要があると感じた。
  3.Red Hatのサポートケースで問合せたところ、迅速に回答が得られ、効果的であると感じた。
    また、コミュニティサイトを利用して質問を投げてみたが、こちらも比較的早めに回答が得られ、
            改めてOSSの強み(温かさ?)を感じることができた。

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

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

アプリケーション開発において、コンテナ技術の重要性が高まっているようです。金融IT分野のアプリケーション開発を生業としているサイオスグループの株式会社キーポート・ソリューションズ(以降:弊社)では今回、流行りに乗り遅れまいとレッドハット社が提供するコンテナベースのアプリケーションプラットフォーム「OpenShift」を触ってみることにしました。

実際、触るのは「これから」なのですが、今後数回にわたり以下のような観点で「OpenShift」を触ってみて、開発者視点でのメリットやデメリット、疑問点とその解決策、良い使い方がないか、などを探ってみたいと思います。

まずは、第1回目となる本記事では、「OpenShift」を触ってみることになった背景、目的、今回やってみたい内容などをご紹介したいと思います。

 

背景

以前、ポケモンGoが話題になったときにサーバ側処理が気になって調べたことがあります。Googleクラウド、Googleコンテナエンジン、Kubernetes、Dockerといったあまり馴染みのなかったワードが・・・。それまで、コンテナに対して、“便利なことができるんだろうなぁ“程度に思っていた私にとって、コンテナの有効性を初めて身近に感じた一件となりました。

さて、現在のIT業界において、コンテナの存在は急激に注目され始めています。そんな中、「OpenShift」はDocker、Kubernetesの機能に加えて、DevOpsに便利な機能を有すると謳われています。

OpenShiftによって、現課題は解消できる?開発の生産性は上がるの?運用は容易になるの?といった素朴な疑問を解消するためにもまずは触ってみよう!ということになりました。

 

  • アプリケーションを開発するにあたって現在の課題 (同じような課題をお持ちのベンダーさんは多いはず・・・)
    • 保守、開発しているシステムが多数あるが、システムごとに開発環境を用意しており、OS、M/W、フレームワーク、開発言語などさまざまで、環境が乱立している。
    • システムごとに環境や手順や異なるため、ナレッジを共有できず属人化している。(サーバ環境だけでなく、ローカル端末の開発環境も様々で、自分のPCは色んなツールがいっぱいで動きが重い。)
  • 素朴な疑問
    • 乱立している開発環境や手順など、本当に効率化できる?
    • 開発における生産性、スピードは本当に上がる?
    • DevOpsっていうけど、運用側のメリットって一体何?
    • コンテナによる環境の標準化の方法って?
    • また、標準化するために必要な下準備の内容とは?

などなど・・・。

そして、ひょっとするとこんな夢も叶えられるのでは?と次第に思うように・・。

  • このような課題や疑問を解決することは開発効率を上げることだけではなく、疲弊しがちな開発者のストレスも軽減し、ワークライフバランスまで改善したりするのかも・・・
  • 流行りのコンテナ技術を活用することによってDevOpsを実現するソリューションを提供することができるようになり、本分野における先駆けのSIerになれるかも・・・
  • そして、技術者個人としてもスキルアップできるかも・・・

目的

「OpenShift」を導入したとしても、使いこなせなければ効果は出ないはず。
というわけで、下記のような目的で「OpenShift」を触ってみることにします。

  • 目的
  1. メリット、デメリットを明確にする。
  2. 弊社のような開発ベンダーが利用するための情報を整理する。
  3. お客様環境に適用するための情報を整理する。
 

確認する内容

今後「OpenShift」を使って何をするか、を考えてみました。

 

基本的には、開発者視点で触ってみたいので、下記3点を試していきたいと思います。

① 環境を作る。
② OpenShiftをアプリケーション開発で利用する。
③ OpenShiftをアプリケーション運用で利用する。

■確認する内容

⇒「① 環境を作る」

      • 大変な部分はどこ?・・・みんなが詰まる部分を洗い出したい。
      • 必要な作業項目は?・・・今後、他の人が構築し易いようにTODOリストを作りたい。
      • 注意点すべき点はどこ?・・・パフォーマンス、リソース、設定などサイジングを考える上での元ネタを集める。

⇒「② OpenShiftをアプリケーション開発で利用する。」
「OpenShift」を触ってみる過程において、一番やってみたいことが盛りだくさんなのは、やはりアプリケーション開発です。
今回は弊社で持っている既存システムを試験的に移行し、軽微なPG改修を実施してみながら、以下の観点で確認したいと思います。

      • ビルド、デプロイの作業負荷は軽減できる?
      • システムの移行はスムーズにできる?
      • 複数システムの開発は容易にできるか?
      • 複数の開発メンバーによるビルド、デプロイ時の制御はできるか?
      • オーケストレーション機能ってどんなもの?
      • gitやJenkinsとの連携がスムーズにできるか?
      • ローカル端末の開発環境構築時の作業負荷は軽減できるか?

⇒「③ OpenShiftをアプリケーション運用で利用する。」
開発ベンダーとして「OpenShift」を利用する場合、その運用面においても気になる点がいくつもあります。
運用面においても前述の「②アプリケーションを開発する」にて移行、改修したシステムを用いて、以下の観点で確認したいと思います。

      • 開発環境用のコンテナを、そのまま本番環境にデプロイできるか?
      • パラメータを利用して簡単にコンテナ環境を構築することができるか?
      • 複数の開発メンバーによるビルド、デプロイ時の効率的なコンテナ管理方法は?
      • OS、M/W等のアップデートを自動化できるか?(もし試せれば。。)