OpenShift を活用してデリバリのリードタイムの短縮した事例

The fast-moving monolith: how we sped-up delivery from every three months, to every week – RHD Blog で紹介されている KeyBankでのリードタイム短縮のチャレンジを要約してみました。

リリースサイクルを3ヶ月から1週間へ

ここで紹介されているのは、KeyBankのリリースサイクルが四半期ごとから毎週になったという話です。

  • リリースサイクルを短縮するにあたっては、WebSphereからTomcatへの移行と、コンテナのランタイムとしてOpenShiftの採用

  • これらの変革を最重要プロジェクト(The digital channel modernization)の一環として実施

課題

  • SLAを満たすようにメンテナンスするにはコストがかかる、典型的なモノリシックなアプリケーション
  • 四半期リリースは、コストが高いしリスクも高く、週末の一大イベント （もちろん月曜日にはちゃんと使える状態になっていなくてはならなりません!!）

Motivation

担当者が色々と調べているときに、カンファレンスで Netflixのプレゼンを見て、自分たちよりも2-3倍の規模なのに、リリースに関わるメトリックは自分たちのそれをはるかに超えていることを知りました。 そして、銀行のDigital Channel にはウィークリのリリースは合理的であると考えました。

このプロジェクトでやったこと

  • 古いアプリケーションをモダンなモバイルでも利用可能なウェブアプリケーションにすること
  • プレゼンテーションレイヤとビジネスロジックレイヤを分離して、CI/CD が実現しやすいアーキテクチャにすること
  • 自動化を推し進めてリードタイムを短縮すること
  • 時間を浪費していた承認プロセスを削減すること

アプリケーションアーキテクチャ

対象のアプリケーション

かつて流行っていた構成でした。

新しいアーキテクチャ

  • AngularJS と Ionic を採用

このプロジェクトを進めていく過程で直面した課題

Ops との戦い

アーキテクチャを変更しJAX-RS を使うためには、JDK1.7が必要でした。しかし、Ops チームはやりたがりません（寝た子は起こすななので）。しかし、 JDK1.6のサポートライフサイクルが半年で終わってしまうとサポートされた環境でシステムを運用したい Ops もやらざるを得なくなりました。

Dev vs Ops

Dev は正しい方法で自分たちのニーズを伝えられず、Opsはシステムがサービスを継続できる状態を保つことが気がかりで、新しいことにチャレンジしたがりません。 この板挟みでモデレートすることに苦労したようです。

必要なプラットフォーム

デリバリチームは、自分で必要なインフラはセルフサービスでプロビジョニングできるべきと悟り、それを実現するにはプライベートなクラウドインフラが必要という結論に達し、それには Kubernetes が最適となりました。

最適なプラットフォームはOpenShift

WebSphere で動いている古いMVCモデルのアプリケーションをモダンな技術に移行することは技術的には問題ありませんでした。しかし、以前として課題は、週次のリリースとインフラのセルフプロビジョニングと普遍のインフラの実現をどうするかということでした。

Opsチームはセルフサービスでプロビジョニングされた環境を保証しなくてはならないので、サポートのあるOpenShiftを採用しました。

自動化の促進

Jenkinsのパイプラインを活用して CI を実現し、QA環境でのテストが終わったらプロダクションにリリースできるようにしました。 しかし、プロダクションに持ち込むために、たくさんの承認プロセスがありましたが、これは時間を浪費する作業だったので、OpenShiftの中だけで済むようなコンポーネントのリリースは、承認プロセスを不要にしました。 ここまで自動化とプロセスの見直しを行いましたが、最後に残った課題は、リグレッションテストの自動化です。手動でのテストでは毎週のリリースには間に合わないので、テストツールを導入して自動化を可能としました。

まとめ

このプロジェクトを実施した結果、毎週のリリース時にサービスを止めることなく、ローリングアップデートが可能となりました。 サービスの提供環境としても、オートスケールの機能も活用して、アクセスが急激に増えた場合にも対応できるようになりました。

OpenShift の導入によって、リリースサイクルの短縮とサービス提供のSLAの向上が両方できた良い事例でした。

Horizontal Pod Autoscaler

Kubernetes Advent Calendar 2016。投稿が遅れてしまいましたが、コンテナを本番サービスで利用する場合にすごく便利ではないかなと思われる Horizontal Pod Autoscaler について紹介します。

Horizontal Pod Autoscalerとは

f:id:akubicharm:20161216145111p:plain

Horizontal Pod Autoscaler(HPA)はPodに割り当てられた CPU の使用率にしたがって、Pod の数を増減させる仕組みです。この仕組みを使うと Pod として動かしているアプリケーションが高負荷になった場合に、スケールアウトして負荷分散が可能になります。 デフォルトでは 30 秒ごとに負荷状況がチェックされ、スケールアウト/ダウンが実行されます。

ここまでで想像ができるかもしれませんが、CPU の使用率にしたがってPodを増減させるということは、CPU のメトリクスを収集する機能が実装されていなければいけません。Kubernetes では Heapster を使って CPU の使用を収集します。

OpenShift でのメトリクス収集とHPAの仕組み

メトリクス収集の仕組み

OpenShiftでは、Heapsterを使ったメトリクスの収集に加えて、Hawkular Metricsと Cassandra を利用してメトリクスの蓄積と可視化を行っています。 Heapster, Hawkular Metrics, Cassandra もそれぞれコンテナとして OpenShift 上で実行されます。

f:id:akubicharm:20161216144645p:plain

メトリクス収集の仕組みを有効にしておくと、OpenShift 管理コンソールではCPU, Memory, Network IO の状況を図のような折れ線グラフで参照することが可能になります。 f:id:akubicharm:20161216144634p:plain

HPA の仕組み

OpenShift は Kubernetes を活用した Container 型のアプリケーションプラットフォームですので、HPA の仕組みも Kubernetes の HPA と同様です。

HPA が Heapster から CPU の利用状況を、Replication Controller から稼働中のレプリカ数を取得します。CPU の使用率が閾値を超えている場合にはレプリカ数を増やし、CPU の使用率が閾値を下回った場合にはレプリカ数を減らします。また、レプリカ数が変更された場合には、 Replication Controller のステータスもアップデートされます。

f:id:akubicharm:20161216144639p:plain

OpenShift では、CPU、Memory のリソース割り当ては、Pod のデプロイ方式を定義した Deployment Config で行います。例えば、CPU の割り当てが 50m 〜 100m、メモリの割り当てが 100Mi 〜 200Mi の場合には、Deployment Config は次のようになります。

        resources:
          limits:
            cpu: 100m
            memory: 200Mi
          requests:
            cpu: 50m
            memory: 100Mi

レプリカ数を 1 〜 4 個、CPU 使用率の閾値を 80% とした場合、HPA は次のようになります。

spec:
  maxReplicas: 4
  minReplicas: 1
  scaleTargetRef:
    apiVersion: extensions/v1beta1
    kind: DeploymentConfig
    name: php
  targetCPUUtilizationPercentage: 80

OpenShift での設定

OpenShift でメトリクス収集を有効にする場合は、Heapster, Hawkular Metrics, Cassandra をそれぞれデプロイするのではなく、Metrics Deployer という、Metrics収集プラグインをセットアップするためのコンテナに環境設定を任せてしまうことができます。

設定方法を紹介する前に、ちょっとはまったことを...

今回は OpenShift Origin で環境構築をしたので、Kubernetes と Heapster のバージョンの組み合わせには注意が必要でした。

Metrics Deployer は Docker Hub から origin-metrics-deloyer のコンテナイメージ(docker.io/openshift/origin-metrics-deployer)を Pull してきて利用するのですが、latest のイメージだと、Kubernetes と Heapster のAPIバージョンが不一致となってしまい、Metrics 収集機能はりようできるけれでも HPA がちゃんと動作しませんでした。正しい組み合わせは、

Kubernetes Heapster
ver 1.3 ver 1.1
ver 1.4 ver 1.2

Kubernetes 1.3 で heapster 1.2 を使った場合には、ログ(journal)に以下のように unmarshall できないというエラーメセージが出ていました。

W1214 05:04:48.140190  112006 horizontal.go:99] Failed to reconcile hello: failed to compute desired number of replicas based on CPU utilization for DeploymentConfig/test/hello: failed to get CPU utilization: failed to get CPU consumption and request: failed to unmarshall heapster response: json: cannot unmarshal object into Go value of type []v1alpha1.PodMetrics

メトリクスプラグインの設定

OpenShift Originのインストールは https://docs.openshift.org/latest/install_config/install/advanced_install.html に従って実施します。

メトリクス収集機能は openshift-infra というProjectにデプロイします。

Project : Kubernetes の Namespace を拡張した概念

1. Metrics URL の追加

OpenShift の Master サーバの定義ファイル /etc/origin/master/master-config.yamlに metricsPublicURL を追加します。 Hawkular のコンテナも他のアプリケーションと同様に OpenShift にデプロイされるので、他のアプリケーションと同様に OpenShift の Route 経由でアクセス可能な URL を指定します。

assetConfig:
  < 中　略 >
  metricsPublicURL: "https://hawkular-metrics.192.168.1.1.xip.io/hawkular/metrics"
  < 中　略 >
routingConfig:
  subdomain:  "192.168.1.1.xip.io"

2. Service Account の作成

Metrics 収集のデプロイと実行に必要な Service Accountを作成します。

oc project openshift-infra
oc create -f - <<API
apiVersion: v1
kind: ServiceAccount
metadata:
  name: metrics-deployer
secrets:
- name: metrics-deployer
API

3. ポリシーの設定

先ほど作成した metrics-deployer、heapster, hawkular 用の Service Account に権限を付与します。

Metrics Deployer 用の Service Account に、openshift-infra プロジェクトの edit 権限を付与します。

oadm policy add-role-to-user \
    edit system:serviceaccount:openshift-infra:metrics-deployer

Heapster 用の Service Account に、cluster-reader 権限を付与します。

oadm policy add-cluster-role-to-user \
    cluster-reader system:serviceaccount:openshift-infra:heapster

Hawkular 用の Service Account に openshift-infra プロジェクトの view 権限を付与します。

oadm policy add-role-to-user view \
        system:serviceaccount:openshift-infra:hawkular \
        -n openshift-infra

4. metrics-deployer の secrets を作成

oc secrets new metrics-deployer nothing=/dev/null -n openshift-infra

5. metrics-deployer の準備

kubernetes v1.3 を使っている場合には、heapster の最新版を使ってしまうと、API バージョンが不整合になってしまいます。 そこで、既存のテンプレートを少し修正して利用します。

まず、既存のテンプレートを使って metrics-deployer をデプロイするための yaml ファイルを生成します。ここでは、簡易的にデプロイするために永続化ストレージを使わないオプション USE_PERSISTENT_STORAGE=false もつけておきます。

oc get templates -n openshift
oc process metrics-deployer-template -v HAWKULAR_METRICS_HOSTNAME=hawkular-metrics.192.168.1.1.xip.io -v USE_PERSISTENT_STORAGE=false -n openshift > metrics.yaml

Template : OpenShift にアプリケーションをデプロイするための雛形。OpenShift の Cluster 全体で利用するものは openshift プロジェクトに保持されている。

6. YAML ファイルの編集

生成された　metrics.yaml ファイルを編集します。 IMAGE_VERSION を latest から v1.3.1 に変更します。

{
    "name": "IMAGE_VERSION",
    "value": "v1.3.1"
},

利用する metrics-deployer の Image Tag を latest から v1.3.1 に変更します。

"image": "openshift/origin-metrics-deployer:v1.3.1",

7. Metrics プラグインのデプロイ

編集した YAML ファイルを利用して、metrics-deployer をデプロイします。

oc create -f metric.yaml

あとは、気長に待ちましょう。。。

8. アプリケーションの設定

https://github.com/akubicharm/OpenShiftv3HandsOn/blob/master/3.3/autoscale/autoscale.md　を参考に、やってみてください。

HPA で CPU の使用率を見ていくと、こんな風に使用率が表示されます。

oc get hpa -n test -w
NAME      REFERENCE              TARGET    CURRENT   MINPODS   MAXPODS   AGE
php       DeploymentConfig/php   10%       0%        1         4         21h

NAME      REFERENCE              TARGET    CURRENT   MINPODS   MAXPODS   AGE
php       DeploymentConfig/php   10%       168%      1         4         21h
php       DeploymentConfig/php   10%       168%      1         4         21h
php       DeploymentConfig/php   10%       700%      1         4         21h
php       DeploymentConfig/php   10%       700%      1         4         21h

終わりに

HPA のような仕組みで簡単にアプリケーションをスケールアウトできるのは、Container & Kubernetes だからこそですね。HPA を設定しておけば、急なアクセス過多になった場合でも滞りなくサービスを持続することができますので、運用の利便性も高くなりますので、ぜひ、試してみてください。

OpenShift Online Next Generationがやってきたー

Red Hatが管理・運営をしているPublicなPaaS環境であるOpenShift Onlineに、待望のOpenShift v3対応のプレビュー版がリリースされました。 環境があったらOpenShift v3 を試してみたい！と考えている方必見です。

利用方法

前提条件

  • Github.com のアカウントがあること。

※Github.comのアカウントがない方はまずアカウントを登録しましょう。

利用登録登録

  1. https://www.openshift.com/devpreview/register.html にアクセスします f:id:akubicharm:20160617140444p:plain

  2. Login with GitHub ボタンをクリックします f:id:akubicharm:20160617134419p:plain

  3. github.com のアプリケーション認証サイトで認証可能にします f:id:akubicharm:20160617134607p:plain

  4. OpenShift Onlineの登録フォームで必要事項を入力して「REGISTER」ボタンをクリックします f:id:akubicharm:20160617134732p:plain このとき、Github Username, Github ID はプリセットされています。

  5. あとはアカウント作成完了のメールを待ちましょう f:id:akubicharm:20160617134900p:plain

メールに、OpenShift Online (v3 版）のURLがあるのでアクセスしましょう。

アプリケーションをデプロイしよう

利用登録ができたら、早速アプリケーションをデプロイしてみましょう。ここではWebUIを使ったアプリケーションのデプロイ方法をご紹介します。

OpenShiftのクラスタ内では、プロジェクト名が一意である必要があります。もしもすでに他の人が使っている名前を指定すると、こんな風にエラーになります。 f:id:akubicharm:20160617134945p:plain

OpenShiftは、テンプレートを使って簡単にアプリケーションの実行環境を構築することができます。テンプレートはベースとなるコンテナイメージ、ビルド方式、デプロイ方式などを定義することができます。 ここでは、JBoss EAPのテンプレートを使って、JBoss のサンプルアプリケーションをデプロイします。

https://github.com/jboss-developer/jboss-eap-quickstarts/tree/6.4.x/kitchensink

  1. 「LOGIN WITH GITHUB」ボタンをクリックしてログイン f:id:akubicharm:20160617140444p:plain

2.「New Project」ボタンをクリックして、プロジェクト作成を開始 f:id:akubicharm:20160617135013p:plain

  1. Nameでプロジェクト名を指定して「Create」ボタンをクリック f:id:akubicharm:20160617135032p:plain

  2. テンプレート一覧から「jboss-eap64-openshift:1.3」を選択 f:id:akubicharm:20160617140947p:plain

  3. Nameにアプリケーション名を入力、「Try it」をクリックして、Git Repository URLのテキストフィールドにGithubのリポジトリを指定 f:id:akubicharm:20160617135245p:plain ※アプリケーション名はプロジェクト内で一意であれば良いので、好きな名前をつけましょう。

  4. 「Create」ボタンをクリックして、アプリケーションのビルド＆デプロイの開始 f:id:akubicharm:20160617135317p:plain

  5. 「Continue to deploy」をクリックして Overview 画面を表示 f:id:akubicharm:20160617135441p:plain f:id:akubicharm:20160617135645p:plain

  6. デプロイが終わったら、アプリケーションへのリ ンクをクリックしてアプリケーションを利用 f:id:akubicharm:20160617135722p:plain

f:id:akubicharm:20160617135742p:plain

FAQ（抜粋）

https://www.openshift.com/devpreview/register.htmlにFAQがありますので、詳細はそちらを参照してください。

  • 30日でアカウントは失効しデプロイしたアプリケーションも消滅します。再び利用したい場合は、再度、登録フォームで登録します。
  • 1プロジェクトにつき 2GiBメモリ、4CPU Core、 1GiBの永続化ストレージx2　のリソースが利用可能です。
  • 2016/6/16 時点で、利用できる言語やミドルウェアは Node.js(0.10)、 PHP(5.5, 5.6)、Python(2.7, 3.3, 3.4)、Ruby(2.0, 2.2)、　Perl(5.16, 5.20), Java(6, 7, 8, EE)とJBoss EAPとJBoss Web Server が利用可能です。 利用できるデータベースは、MongoDB(2.4, 2.6)、MySQL(5.5, 5.6)と PostgreSQL(9.2, 9.4)です。
  • コンテナ内のプロセスを root ユーザ(PID=1)で実行するコンテナは、セキュリティの制限により利用できません。

OpenShift Enterprise 3 on Microsoft Azure - RHELインストール編 -

準備するもの

  • Azure のアカウント
  • Red Hat Network ID
  • RHEL 7.2 KVM イメージ

準備

1.Cloud Accessの登録

(1)azureのサブスクリプションの確認

f:id:akubicharm:20160114233028p:plain

(2)Red Hat Cloud Accessのエンロールを開始

http://www.redhat.com/en/technologies/cloud-computing/cloud-access にアクセスして、Cloud Access の登録をします。 画面左下の "ENROLL" をクリックします。 f:id:akubicharm:20160114225017p:plain

(3)登録

CloudProviderとMicrosoftSubscriptionNumberを入力します。

|Name|Value| |---|---| |CloudProvicer|Microsoft Azure| |MicrosoftSubscriptionNumber|(3)で確認したazureのサブスクリプション番号| |ProductName|azureで利用するRed Hatのサブスクリプションを選択| |Quantity|導入するサブスクリプションの本数を入力| f:id:akubicharm:20160114233203p:plain

(4)登録完了

f:id:akubicharm:20160115012823p:plain

VDH イメージ

Linux VHD の作成とアップロード | Microsoft Azure に従って、アップロードするイメージの作成。

Kickstartを使いたかったのですが、Hyper-V Manager の使い方がわからないので断念。

(1)KVMイメージをダウンロード

https://access.redhat.com/downloads/content/69/ver=/rhel---7/7.2/x86_64/product-software から、KVM イメージをダウンロードします。

(2)qcow2からvdhの変換

Linux VHD の作成とアップロード | Microsoft Azure に従って guestfish で、root パスワードをchangemeに変更後、VDHへ変換。

virt-install で KVM イメージをインポート

sudo virt-install \
--connect qemu:///system \
--ram 1024 -n rhel_72_azure -r 2048  \
--os-type=linux \
--os-variant=rhel5  \
--disk path=/home/komizo/azure/rhel-guest-image-7.2-20151102.0.x86_64.qcow2,device=disk,bus=virtio,format=qcow2
  \
--vcpus=2 \
--vnc \
--noautoconsole  \
--import

virsh で仮想OSの起動

virsh -c qemu:///system
console rhel_72_azure

Azure CLIのイストール

Azure SDK とツールのダウンロード | Azure からAzure CLI ツールをダウンロード

RHELのVM作成

(1)VDHイメージのアップロード

Linux VHD の作成とアップロード | Microsoft Azure の手順2に従って、イメージをアップロード

azure vm image create rhel-7.2 --location "Japan East" --os Linux rhel-guest-image-7.2-20151102.0.x86_64.vhd

1回目は container がないとエラーになるので、もう一度やったら出来ているっぽい。

azure vm image list で一覧を表示すると、rhel-7.2 が表示されます。WebUIでは表示されないっぽい。

$ azure vm image list |grep rhel-7.2
data:    rhel-7.2                                                                                                              User      Linux    undefined

(2)仮想OSの作成

azure vm create <仮想マシン名>.cloudapp.net rhel-7.2 --vm-size "Medium" guest --location "Japan East"
info:    Executing command vm create
+ Looking up image rhel-7.2                                                    
Enter VM 'guest' password:******** ← @Dmin123
Confirm password: ********
+ Looking up cloud service                                                     
info:    cloud service <仮想マシン名> not found.
+ Creating cloud service                                                       
+ Creating VM                                                                  
info:    vm create command OK

ここで、location か affinity-group の指定が必要なので、azure vm location list か azure account affinity-group list で確認します。

(3) SSH の有効化

仮想OS起動したのに、SSHできないーと悩んでいたら、SSHのエンドポイントがありませんでした。自分で追加する必要があります。

Webコンソールで「仮想マシン（クラッシック） > [仮想サーバ名] > 設定 > エンドポイント」を指定し、エンドポイントに SSH ようの 22 番ポートを指定。

f:id:akubicharm:20160114232628p:plain

(4)追加ユーザの作成

Webコンソールで「仮想マシン（クラッシック） > [仮想サーバ名] > 設定 > ユーザ」を指定し、ユーザと認証方式を設定します。

(5)ログイン

パスワード認証にした場合は、ユーザと仮想マシンを指定して ssh を実行します。

ssh -l <ユーザ名> <仮想マシン名>.cloudapp.net>

参考

1.Linux VHD の作成とアップロード | Microsoft Azure 2.Create and upload a Linux VHD | Microsoft Azure 3.Use the Azure CLI with Service Management | Microsoft Azure 4.Use SSH on Linux and Mac | Microsoft Azure

Optimizing Twelve-Factor Apps for OpenShift by Red Hat

原文 : Optimizing Twelve-Factor Apps for OpenShift by Red Hat - Red Hat Customer Portal

OpenShift Enterprise by Red Hat は、アプリケーションアーキテクチャ非依存な PaaS 基盤です。さらに、ステートフルな旧来型のアプリケーションも実行することができます。OpenShift Enterpriseは、モダンでステートレスな Twelve-Factor Apps も実行することができます。この文書では、Twelve-Factor Apps のアーキテクチャの最適化とOpenShift Enterprise へのデプロイの方法を紹介します。

Note: Twelve-Factor App は、モダンなクラウド環境にアプリケーションを構築するためのメソドロジーです。詳細は http://12factor.net/ja/ を参照してください。

Factor Relationship
Codebase - コードベース バージョン管理されている1つのコードベースと複数のデプロイ。OpenShift Enterpriseは、ソースコードリポジトリからソースコードを取得してアプリケーションのビルドとデプロイが可能。
Dependencies - 依存関係 依存関係を明示的に宣言し分離。OpenShift Enterprisは、プログラミング言語ごとの依存関係の管理システムの利用が可能。Maven、Java、CPANやその他にも多数のプログラミング言語の依存関係管理システムをサポート。
Config - 設定 設定を環境変数に格納する。OpenShift Enterpriseは、複数の環境変数の設定方法を提供。
Baking Service - バックエンドサービス バックエンドサービスをアタッチされたリソースとして扱う。OpenShift Enterpriseでは、多数のバックエンドサービスを提供いしている（データベース、メッセージブローカなど）。さらに、外部リソースをアタッチすることも可能。
Build, release, run - ビルド、リリース、実行 ビルド、リリース、実行の3つのステージを厳密に分離する。OpenShift Enterpriseは、厳密にビルド、リリース、実行のステージのコードベースを分離し、サードパーティのデプロイツール統合し、継続的インテグレーション／継続的デリバリ（CI/CD）が可能。
Processes - プロセス アプリケーションを1つもしくは複数のステートレスなプロセスとして実行。OpenShift Enterpriseな、デプロイ可能な単位としてDockerコンテナをネイティブにサポート。Dockerコンテナはステートレスでポータブル。
Port binding - ポートバインディング ポートバインディングを通してサービスを公開。OpenShift Enterpriseは、アプリケーションをポートバインディングによって公開し、サービスを公開可能。サービスな OpenShift 内部での利用も、バックエンドサービスとして外部に公開することも可能。
Concurrency - 並行性 プロセスモデルによってスケールアウト。OpenShift Enterpriseは、手動／自動でアプリケーションをスケールアウトが可能で、真のウェブスケールのアプリケーションのデプロイが可能。
Disposability - 廃棄容易性 高速な軌道とグレースフルシャットダウンで堅牢性を最大化。コンテナの起動と停止。OpenShift Enterpriseはコンテナを利用し、堅牢なツールの仕組みを活用して、迅速な起動とグレースフルシャットダウンが可能。
Dev/prod parity - 開発／本番一致 開発、ステージング、本番環境をできるだけ一致させた状態を保つ。OpenShift Enterpriseの中の”環境”は名称が異なるだけ。唯一の本番環境か100ステップの本番環境かに関わらず、インフラもアプリケーションアーキテクチャも変更なし
Logs - ログ ログをイベントストリームとして扱う。OpenShift Enterpriseは、アプリケーション開発者が特別な操作をすることなしに、すべてのインスタンスのアプリケーションログデータを集約可能。
Admin process - 管理プロセス 管理タスクを1回限りのプロセスとして実行。OpenShift Enterpriseはデプロイ前後のフックを実行する昨日を提供する。また、同様にcronのようなタスクを”管理／運用タスク”として実行可能。

Red Hat は、Twelve-Factor Apps には上記以外にも特徴があると考えている。

Characterristics Relationship
Microservices - マイクロサービス 業務として意味のある単位または、ビジネスの価値を提供することができる最小単位でのソフトウェアのビルド方式
Self Service Full Stack Infrastructure OpenShiftは、セルフサービスでアプリケーションの実行環境の取得を可能にする。OS、コンテナ、ストレージ、ネットワーク、ミドルウェア、ソースコード管理／ビルド／デプロイツール
Support your choice of deployment OpenShiftは、物理サーバ・仮想サーバ、プライベートクラウド・パブリッククラウドなど、お好きな環境に構築可能！
Enterprise Ready Containers OpenShiftで採用しているDockerコンテナは、単に root ユーザ以外でコンテンを実行するだけではなく、SELinuxによってセキュリティを担保。さらに Red Hat は、Docker社以外でDockerの開発に最も貢献している。Red Hat Enterprise Linux が Docker の最適な実行環境となることを目標としている。
Immutable Infrastructure OpenShift は、テストされたアプリケーションのバージョンを本番環境にデプロイできるような機能を提供。この機能により、コードベースのトレーサビリティが向上し、環境の違いによる障害を減らすことが可能。
API-Based Collaboration 複数のサービスやアプリケーションを跨る連携は、公開されバージョン付けられたAPIを通じて利用。Red Hatは、サービスやアプリケーションを WebService、REST、JMSやその他のプロトコルやフォーマットを利用して連携するプロダクトを提供。→JBoss Fuse、JBoss AMQ
Test Driven Development Red Hatは、OpenShift/Kubernetesに配備されたアプリケーションをテストするためのMavenのプラグイン(fabric8-arquillian)を提供。fabric8-arquillianは、OpenShift/KubernetesのDockerのクラスタ環境で利用するためのArquillianの拡張。OpenShift/Kubernetesにデプロイされた環境のテストで利用可能。
Community Based Innovation OpenShiftは、Kubernetes、Dockerなどのオープンソースのプロジェクトを活用。これらのプロジェクトへの有力な貢献者でありかつ、これらのプロジェクトの利用者でもある。Red Hatは、より良いソフトウェア開発を牽引している。
Continuous Integration and Continuous Deployment OpenShiftは、CI/CDを実現可能とする Jenkins の Docker イメージを提供。

その他の参考記事: マイクロサービス，DevOps, PaaSが最新のJava EEアーキテクチャに与える影響

備忘録：OpenShift 3.1のインストール

Mac側の準備

毎回、DNSMasq を仮想環境に設定するのは手間なので、ホストOSであるMacでDNSMasqを動かして、/etc/resolver にファイルを配置することでホストOSのネットワーク環境の変化の影響を受けなくなって、かなり快適です。

Dnsmasq のインストール

http://qiita.com/ono_matope/items/cd3be40b5179731d4460

起動と停止

sudo launchctl start homebrew.mxcl.dnsmasq
sudo launchctl stop homebrew.mxcl.dnsmasq

設定ファイル

/usr/local/etc/dnsmasq.conf

address=/apps.ose31/192.168.31.11

resolverの設定

/etc/resolver にdnsmasqで名前解決させたいドメイン名でファイルを作成 ex. apps.ose31 を解決したい場合は、 /etc/resolver/apps.ose31 を作成

nameserver 127.0.0.1

OS の準備

Box イメージのサイズ拡張

ディスクの拡張

VBoxManage clonehd "vagrant-virtualbox-box.vmdk" "cloned.vdi" --format vdi
VBoxManage modifyhd "cloned.vdi" --resize 20480 
VBoxManage clonehd "cloned.vdi" "resized.vmdk" --format vmdk

ボリュームの拡張

参考にしたサイトhttp://qiita.com/nouphet/items/fea026c03ca86ec54111 *lvdisplay, pvdisplay でストレージ確認 -fdisk でパーティション追加

# fdisk /dev/sda3 
# n 新たに領域を作成する 
n 
# p 領域テーブルを表示する 
p 
# 領域番号 (1-4): 1 
# 最初 シリンダ (1-1827, default 1): 
Enter 
# 終点 シリンダ または +サイズ または +サイズM または +サイズK (1-1827, default 1827): 
Enter 
# t 領域のシステム ID を変更する 
t 
# 16進数コード (L コマンドでコードリスト表示): 
8e 
# p 領域テーブルを表示する 
p 
# w テーブルをディスクに書き込み、終了する 
w

ボリューム作成

pvcreate /dev/sda4 vgextend VolGroup00 /dev/sda4 
lvextend -L +20Gb /dev/VolGroup00/LogVol00 
resize2fs /dev/VolGroup00/LogVol00

OpenShiftのインストール

クイックインストールの場合、インストールを実行するユーザのホームディレクトリ配下に設定ファイル(~/.config/openshift/installer.cfg.yml)を配置して、インストールを開始します。

atomic-openshift-installer -u install

アンインストールは

atomic-openshift-installer -u uninstall

備忘録：Cisco UCS セットアップ

RHEL がインストールできるようになるまで

  • BIOSの設定画面の表示 -> F6
  • LSI RAID管理画面の表示 -> Ctrl-h

RHEL7.1 から 7.2 へのアップグレード

  • Rootユーザで ssh ログインする -> /etc/ssh/sshd_conf の編集
yum upgrade redhat-release

KVM のインストール

yum install qemu-kvm qemu-img
yum install virt-manager

Vagrant インストール

この辺を参考にインストールhttps://github.com/pradels/vagrant-libvirt

wget https://releases.hashicorp.com/vagrant/1.7.4/vagrant_1.7.4_x86_64.rpm
rpm -i vagrant_1.7.4_x86_64.rpm 
vagrant -v

vagrant plugin install vagrant-libvirt
yum install libxslt-devel libxml2-devel libvirt-devel libguestfs-tools-c
  • vagrantup で起動しなかったので、ld のリンクを修正
alternatives --set ld /usr/bin/ld.gold
  • 色々設定
groupadd libvirt
usermod -aG libvirt <user>
vi /etc/libvirt/libvirtd.conf
  # Enable following lines to skip auth
  unix_sock_group = "libvirt"
  unix_sock_ro_perms = "0777"
  auth_unix_ro = "none"
  auth_unix_rw = "none"
systemctl enable libvirtd && systemctl start libvirtd

Box イメージのダウンロード

Red Hat のカスタマーポータルで配布している box イメージをゲット https://access.redhat.com/downloads/content/293/ver=2/rhel---7/2.0.0/x86_64/product-downloads

nginx でリバプロ

この辺りを参考に、見よう見まねで設定。 https://www.digitalocean.com/community/tutorials/how-to-configure-nginx-with-ssl-as-a-reverse-proxy-for-jenkins

証明書作成

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/nginx/cert.key -out /etc/nginx/cert.crt

設定

/etc/nginx/conf.d/default.cfg を編集

server {

    listen 8443;
    server_name master.m1n2.cloud;

    ssl_certificate           /etc/nginx/cert.crt;
    ssl_certificate_key       /etc/nginx/cert.key;

    ssl on;
    ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers on;

    access_log            /var/log/nginx/master.m1n2.cloud.access.log;

    location / {

      proxy_set_header        Host $host;
      proxy_set_header        X-Real-IP $remote_addr;
      proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header        X-Forwarded-Proto $scheme;

      # Fix the “It appears that your reverse proxy set up is broken" error.
      proxy_pass          https://192.168.1.100:8443;
      proxy_read_timeout  90;

      proxy_redirect      http:/// https://;
    }
  }