OpenShiftのトラブルシューティングの第一歩

現象によって調べるポイントは色々ありますが、トラブルシューティングの第一歩としてまずチェックしているログをご紹介します。

OS レベルでのログをチェック

journal の確認

OpenShift のマスタサーバでは、atomic-openshift-master-controllers、atomic-openshift-master-api　と atomic-openshift-node というデーモンが動いてます。 ノードサーバでは、atomic-openshift-node が動いています。

v3.6 まではマスターサーバがシングル構成の場合は atomic-openshift-master というデーモンが動いていましたが、v3.7 からはシングルマスター構成の場合でも、HA構成と同様に2つのデーモンに別れました。

これらのデーモンの journal をチェックします。

journalctl -xe -f -u atomic-openshift-master-controllers
journalctl -xe -f -u atomic-openshift-master-api
journalctl -xe -f -u atomic-openshift-node

ログレベルの変更

ログの出力内容を増やして細かく調査したい場合には、ログレベルを変更します。ログレベルを変更する場合は、/etc/sysconfig ディレクトリにある　atomic-openshift-master-controllers, atomic-openshift-master-api, atomic-openshift-node というファイルのログレベルを変更してデーモンを再起動します。例えば、atomic-openshift-master-controllers の再起動は

systemctl restart atomic-openshift-master-controllers

というコマンドを実行します。

設定可能なログレベルは、以下の通りです。

ログレベル 表示されるログ
0 Error と Warningのみ表示
2 デフォルトのログレベル。Information レベルのログを表示
4 Debug レベルのログを表示
6 Request/Response のAPIレベルのデバッグログを表示
8 Request/Response のボディレベルのデバッグログを表示

詳細は OpenShift のドキュメントのログレベルの設定を参照してください。

その他のデーモンのログレベルの変更

etcd などのログレベルの変更方法は、Red Hat のカスタマーポータルのナレッジを参照してください。

OC コマンドでのログ出力

OpenShift の CLI(Command Line Interface)の実行時に --loglevel=8 のようにログレベルを設定することで、REST のリクエストの内容を出力させることができます。

# oc whoami --loglevel=8
I0129 17:07:04.917363    9103 loader.go:357] Config loaded from file /root/.kube/config
I0129 17:07:04.918401    9103 round_trippers.go:383] GET https://master.example.com:8443/apis/user.openshift.io/v1/users/~
I0129 17:07:04.918434    9103 round_trippers.go:390] Request Headers:
I0129 17:07:04.918456    9103 round_trippers.go:393]     Accept: application/json, */*
I0129 17:07:04.918468    9103 round_trippers.go:393]     User-Agent: oc/v1.7.6+a08f5eeb62 (linux/amd64) kubernetes/c84beff
I0129 17:07:04.970330    9103 round_trippers.go:408] Response Status: 200 OK in 51 milliseconds
I0129 17:07:04.970359    9103 round_trippers.go:411] Response Headers:
I0129 17:07:04.970370    9103 round_trippers.go:414]     Cache-Control: no-store
I0129 17:07:04.970381    9103 round_trippers.go:414]     Content-Type: application/json
I0129 17:07:04.970404    9103 round_trippers.go:414]     Content-Length: 224
I0129 17:07:04.970415    9103 round_trippers.go:414]     Date: Mon, 29 Jan 2018 17:07:04 GMT
I0129 17:07:04.970522    9103 request.go:994] Response Body: {"kind":"User","apiVersion":"user.openshift.io/v1","metadata":{"name":"system:admin","selfLink":"/apis/user.openshift.io/v1/users/system%3Aadmin","creationTimestamp":null},"identities":[],"groups":["system:cluster-admins"]}
system:admin

アプリケーションのログをチェック

実行中のアプリケーションのログの確認

アプリケーションの動作がおかしい場合は、アプリケーションのPodのログをチェックします。 まずは、Pod名を確認します。

oc get pods

ログをチェックしたい Pod 名を指定して、Podのログを確認します。

oc logs app-2-n5jjz

Crash Loopback になってしまうアプリケーションのログの確認

デプロイに失敗して、Crash Loopback になってしまった場合には、oc logs コマンドに --previous オプションを指定して起動しようとした時のログを確認します。

# oc get pods
NAME            READY     STATUS             RESTARTS   AGE
mysql-1-fd6p7   0/1       CrashLoopBackOff   3          2m
# oc logs mysql-1-fd6p7 --previous
error: database is uninitialized and password option is not specified 
  You need to specify one of MYSQL_ROOT_PASSWORD, MYSQL_ALLOW_EMPTY_PASSWORD and MYSQL_RANDOM_ROOT_PASSWORD

イベントをチェック

Pod のデプロイを開始したけど、ステータスが Pending のままだったり、Container Creating で止まってしまった場合は、コンテナが起動していないのでコンテナのログではなく、コンテナのイベントをチェックします。

oc get events

Azure と AWS上でOpenShiftをワンクリックでデプロイ - Azure 編 -

AWSとAzure 上で、テンプレートを利用して簡単にOpenShiftがデプロイできるようになったので、その方法を2回に分けてご紹介します。

BYOL を利用するメリット

OpenShift DedicatedのようなマネージドなOpenShift環境では、管理せずに利用することができるので、すぐに使いたいというニーズにあっています。一方で、インフラ管理面などは管理者に依存する部分もあるので、インフラを自由に構成することが難しいという点もあります。

インフラ構成や管理は自分たちでできるけど、構築の手間はかけずにすぐに環境が欲しいという場合には非常に有効な方法です。

作業の流れは、AWS、Azureのいずれの場合も 1. クラウドアクセスの登録 2. テンプレートを選択してデプロイ

まず、1回目はAzureへのデプロイ方法をご紹介します。

Azureでのインフラ構成

Azureでは3種類の構成が選択できるようになっています。

Small

シングルマスター構成の小さな環境です。まずは、ちょっと使ってみようという場合に手軽に利用できる環境です。

種別 ノード数
Master 1
Infranode 1
Application Node 2
Bastion Host 1
合計 5インスタンス, 10core

Medium

HA構成の小さな環境です。HA構成で使ってみようという場合に手軽に利用できる環境です。

種別 ノード数
Master 3
Infranode 2
Application Node 4
Bastion Host 1
合計 10インスタンス、38core

Large

HA構成で中くらいの環境です。HA構成である程度の数のアプリケーションを実行するために利用できる環境です。

種別 ノード数
Master 3
Infranode 2
Application Node 6
Bastion Host 1
合計 12インスタンス、70core

OpenShiftの構成

  • ユーザ認証
    認証方式はhtpasswdになっており、ファイルはMasterサーバの/etc/orign/master/htpasswdファイルです。 初期状態では、clusteradminというユーザにウィザードの3ステップ目で指定したOpenShift Admin User Passwordが設定されています。 OpenShiftの管理コンソールへログインするためのユーザ認証は、HTTDPassword方式になってoインストール直後はclusteradminユーザにウィザードで設定したパスワードが設定されています。

  • マスターサーバのホスト名
    Masterサーバにはクライアントからアクセスするためのパブリックなホスト名とIPアドレスが付与されています。 命名規則は masterdns<暗号みたいな文字列>.<データセンターのリージョン名>.cloudapp.azure.comとなっています。

  • アプリケーションのサブドメイン名
    <マスターサーバのIPアドレス>.nip.io

  • Persistent Storage
    Persistent Storageは作成されていないので、必要に応じて別途準備する必要があります。

構成などなどがわかったところで、BYOL(Bring Your Own License)のテンプレートを使ってAzureにOpenShiftをデプロイしていきましょう。

デプロイの準備

Red Hat Cloud Access への登録や、BYOLでのデプロイ途中で必要な情報を取得しておきます。

AzureのSubscription

Azure PortalにログインしてSubscriptionsを参照して、自分のSUBSCRIPTION IDをチェックします。

Red HatのSubscription

Subscriptionが割り当てられている Account と PoolID を確認します。

デプロイの作業

BYOLを利用してデプロイするには、2つのリソースグループを利用します。 一つはkeyvaultを登録しておくもの、もう一つはOpenShiftのクラスタを構築するものです。

Red Hat Cloud Accessの登録

Red Hat Cloud Access のサイトから登録します。 f:id:akubicharm:20171218165642p:plain

# パラメータ名 値 備考
1 Cloud Provider Microsoft Azure プルダウンメニューから選択
2 Microsoft Subscription Number/s Azure Portalで確認したSubscriptionIDを入力
3 Product Name 割り当てらているOpenShiftのサブスクリプションを選択
4 Quantity 必要な本数を設定。Azureの場合は、2coreモデルのサブスクリプションが適用されるので、必要な Core数の満たす分を登録。smallならばApplicationNodeは2core x 2ノードなので2です。ただし、検証用Subscriptionの場合には、Master/Infranode分が含まれていませんので、Small の場合 10core / 2 = 5本となります。

登録が完了すると証明書のような画面が表示されます。 f:id:akubicharm:20171218165711p:plain

Azureでのデプロイ

Keyvaultの作成

OpenShiftのインストールにはansibleを利用します。bationサーバからMaster/Nodeに鍵認証でアクセスするため、事前にkeyvaultを作成します。

  1. RSA の鍵作成
% ssh-keygen
  1. 作成した鍵を使って Secret 登録
% az group create --name examplegroup --location 'South Central US’
% az keyvault create \
  --name myvault \
  --resource-group examplegroup\
  --location 'South Central US' \
  --enabled-for-template-deployment true
% az keyvault secret set --vault-name myvault --name mysecret --file ./id_rsa

OpenShiftのデプロイ

  1. Market PlaceからBYOLのテンプレートの選択 検索キーワードに"OpenShift"を入力して検索し、「Red Hat OpenShift Container Platform (BYOL)」を選択します。 f:id:akubicharm:20171218165900p:plain

  2. ウィザード開始 テンプレートの詳細を確認し、画面下部の"Create"ボタンをクリックしてウィザードを開始します。 f:id:akubicharm:20171218165921p:plain

  3. パラメータ入力

1 Basic Configure basic settings

f:id:akubicharm:20171218165938j:plain

以下のパラメータを入力します。

# パラメータ名 値 備考
1 VM Admin UserName clusteradmin 仮想サーバへSSHでログインするためのユーザを指定
2 SSH Public Key for VM Admin User 仮想サーバへSSHでログインするための公開鍵を指定
3 Subscription 利用可能なAzureのサブスクリプションをプルダウンメニューから選択
4 Resource group OpenShiftをデプロイするResource Groupを指定。keyvaultとは異なるResource Groupを指定
5 Location VMをデプロイするリージョンを指定

2 Infrastructure Settings Confgure Infrastructure settings

f:id:akubicharm:20171218165951j:plain

以下のパラメータを入力します。

# パラメータ名 値 備考
1 OCP Cluster Name Prefix ocpcluster
2 OpenShift Cluster Size Small Small, Medium, Large からクラスタサイズを選択
3 Key Vault Resource Group Name Keyvaultを作成したResource Groupを指定
4 Secret Name Keyvaultに登録したSecret名を指定

3 OpenShift Container Platform Configure OpenShift Container Plartform

Azure Disk 利用の設定があるので、追記を読んでください！！！

f:id:akubicharm:20171218170005j:plain

# パラメータ名 値 備考
1 OpenShift Admin User Password OpenShiftの管理コンソールへログインするユーザ(system:admin権限を保持）のパスワードを指定する)
2 Confirm OpenShift Admin User Password 上記のパスワードと同じものを入力
3 Red Hat Subscription Manager User Name or Activation Key Red Hat Customer Portalへのログインに利用するユーザ名またはActivationKey
4 Red Hat Subscription Manager User Password or Org ID Red Hat Customer Portalへのログインに利用するパスワードまたはOrg ID
5 Red Hat Subscription Manager Pool ID Subscriptionに紐づけられたPoolID
6 Default Router Subdomain アプリケーションのRouterに利用するサブドメンをプルダウンから指定

4 Summary

f:id:akubicharm:20171218170021j:plain

内容を確認して"OK"ボタンをクリックしてデプロイを開始します。

デプロイが完了すると、Bastionノード、Masterサーバ、InfranodeサーバとNodeサーバが2台います。 f:id:akubicharm:20171218170035p:plain

おまけ

basion サーバには、OpenShiftのインストール時に利用するインベントリファイルが保存されています。内容はこんな感じです。 IPアドレスは 00.00.00.00 に書き換えています。

# Create an OSEv3 group that contains the masters and nodes groups
[OSEv3:children]
masters
nodes
master0
new_nodes

# Set variables common for all OSEv3 hosts
[OSEv3:vars]
ansible_ssh_user=clusteradmin
ansible_become=yes
openshift_install_examples=true
deployment_type=openshift-enterprise
openshift_release=v3.6
docker_udev_workaround=True
openshift_use_dnsmasq=True
openshift_master_default_subdomain=00.00.00.00.nip.io
openshift_override_hostname_check=true
#osm_use_cockpit=false
os_sdn_network_plugin_name='redhat/openshift-ovs-multitenant'
console_port=443
openshift_cloudprovider_kind=azure
osm_default_node_selector='type=app'
openshift_disable_check=memory_availability,docker_image_availability

# default selectors for router and registry services
openshift_router_selector='type=infra'
openshift_registry_selector='type=infra'

openshift_master_cluster_hostname=masterdnszwtikzua45vga.koreacentral.cloudapp.azure.com
openshift_master_cluster_public_hostname=masterdnszwtikzua45vga.koreacentral.cloudapp.azure.com
openshift_master_cluster_public_vip=00.00.00.00

# Enable HTPasswdPasswordIdentityProvider
openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider', 'filename': '/etc/origin/master/htpasswd'}]

# Setup metrics
openshift_hosted_metrics_deploy=false
#openshift_metrics_cassandra_storage_type=dynamic
openshift_metrics_start_cluster=true
openshift_metrics_hawkular_nodeselector={"type":"infra"}
openshift_metrics_cassandra_nodeselector={"type":"infra"}
openshift_metrics_heapster_nodeselector={"type":"infra"}
openshift_hosted_metrics_public_url=https://metrics.00.00.00.00.nip.io/hawkular/metrics

# Setup logging
openshift_hosted_logging_deploy=false
#openshift_hosted_logging_storage_kind=dynamic
openshift_logging_fluentd_nodeselector={"logging":"true"}
openshift_logging_es_nodeselector={"type":"infra"}
openshift_logging_kibana_nodeselector={"type":"infra"}
openshift_logging_curator_nodeselector={"type":"infra"}
openshift_master_logging_public_url=https://kibana.00.00.00.00.nip.io

# host group for masters
[masters]
ocpcluster-master-0

[master0]
ocpcluster-master-0

# host group for nodes
[nodes]
ocpcluster-master-0 openshift_node_labels="{'type': 'master', 'zone': 'default'}" openshift_hostname=ocpcluster-master-0
ocpcluster-infra-0 openshift_node_labels="{'type': 'infra', 'zone': 'default'}" openshift_hostname=ocpcluster-infra-0
ocpcluster-node-0 openshift_node_labels="{'type': 'app', 'zone': 'default'}" openshift_hostname=ocpcluster-node-0
ocpcluster-node-1 openshift_node_labels="{'type': 'app', 'zone': 'default'}" openshift_hostname=ocpcluster-node-1

# host group for adding new nodes
[new_nodes]

f:id:akubicharm:20171218165642p:plainf:id:akubicharm:20171218165711p:plain

追記

2018-02-27

Azure Disk をストレージとして利用するため Cloud Provider の設定が必要となりました。 ウィザードの3番目で、以下のパラメータを設定する必要があります。

# パラメータ名 値
1 Confiure Azure Cloud Provider Yes
2 Azure AD Service Principal Client ID GUID Azure AD Service Principal Client ID GUID - also known as AppID
3 Azure AD Service Principal Client ID Secret Azure AD Service Principal Client ID Secret

手順はこちらを参照してください。

私の場合、1番目の方法で azure cli でうまくいかなかったので、2番目の方法で azure portal から設定しました。

1. Azure AD でアプリケーションを登録

Create identity for Azure app in portal | Microsoft Docs

# パラメータ名 値
1 Name openshiftsp
2 Application Type Web app/API
3 Sign-on URL https://openshiftsp

2. アプリケーションIDと認証キーの作成

Create identity for Azure app in portal | Microsoft Docs

Azure AD に登録したアプリケーション（ここでは openshiftsp）の Application ID を、ウィザードの"Azure AD Service Principal Client ID GUID"パラメータに設定します。

Key を保存した時にVALUEに表示される値を、ウィザードの"Azure AD Service Principal Client ID Secret"パラメータに設定します。

3. アプリケーションへの権限付与

Create identity for Azure app in portal | Microsoft Docs

Azure AD に登録したアプリケーション（ここでは openshiftsp）に Contributor の権限を付与します。

Masterサーバに　/etc/azure/azure.conf というファイルができています。

{"aadClientSecret": "ウィザードで指定した Application Secret",
 "aadClientID": "ウィザードで指定した Application ID",
 "tenantID": "Azure AD の Directory ID",
 "resourceGroup": "ウィザードで指定したリソースグループ名",
 "location": "ウィザードで指定したリージョン",
 "subscriptionID": "Azure のサブスクリプションID"}

HA構成のOpenShift on Azure で Cockpit を有効にする

Cockpit を利用するとOpenShiftに作成したプロジェクトやコンテナを横断的に管理することができます。

Cockpitのインストール手順は以下を参照してください。

ちょっとした動作確認で、All in One 構成の場合は上記の手順通りで簡単に利用できるのですが、Azure上にHA構成で構築している場合はLBの設定などに変更が必要です。

Azureの設定変更

Inboudセキュリティルールの追加

Masterサーバのネットワークセキュリティグループ(masterSubnetNSG)に Inboundのポートを追加します。

  1. リソースグループのOverview画面でmasterSubnetNSGを選択
  2. masterSubnetNSGのSettingsメニューからInbound security rulesを選択
  3. 画面上部の「+Add」ボタンをクリックしてルールを追加
項目名 値
Name cockpit
Priority 変更せず
Source Any
Service Custom
Protocol TCP
Port range 9090
Action Allow

LBのルールの追加

Masterサーバ用のロードバランサ(masterLB)に9090ポートへのロードバランスルールを追加します。

  1. リソースグループのOverview画面でmasterLBを選択
  2. masterLBのSettingsメニューからLoad balancing rulesを選択
  3. 画面上部の「+Add」をクリックしてルールを追加
項目名 値
Name cockpitRule
IP Version IPv4
Frontend IP address masterLBFrontEndを選択
Protocol TCP
Port 9090
BackendPort 9090
Backend pool 変更せず
TcpProbe(TCP:8443) 変更せず
Session persistence None

ユーザ設定

Cockpitのログインユーザが、OpenShiftのクラスタ情報にアクセスできるように設定します。 ここでは myadmin とユーザで設定します。

ユーザ作成

myadmin ユーザが各Nodeに鍵認証でログインできるように設定します。

作業対象：全サーバ

  1. myadmin ユーザを作成
  2. myadmin ユーザの鍵を配布
  3. myadmin ユーザのパスワード設定（ここで設定したパスワードは、Cockpitのログインで使います）

myadminユーザの設定

myadminユーザが system:admin 権限で OpenShift のクラスタ管理ができるようにします。

作業対象：Masterサーバ

  1. /etc/origin/master/admin.kubeconfig ファイルを ~myadmin/.kube/config ファイルにコピー
cp /etc/origin/master/admin.kubeconfig ~myadmin/.kube/config

あとは、cockpit の管理画面にブラウザでアクセスすれば、OpenShiftのNodeやコンテナの情報が参照可能になります。

f:id:akubicharm:20170815193047p:plain

f:id:akubicharm:20170815193057p:plain

OpenShift 3 Online がリリース

OpenShift Online が v3 に対応し、無償で OpenShift の最新版が使えるようになりました。ということで、今回はエントリ方法を紹介します。

OpenShift Onlineとは

OpenShift Onlineは、Red Hat が管理運用している Public な OpenShift Container Platform の環境です。Free Plan も用意されているので、OpenShift を開発者として利用したい場合には非常に便利です。

利用プラン

まずは、Free Planがリリースされました。 Free Plan では、Project(Kubernetes の Namespace　を拡張した概念）を一つ作成することができます。Web App, DB, Jenkins を使ったCI/CDを試すには十分でしょう。今後、有償プランもリリースされていく予定です。

使えるアプリケーション

アプリケーションの実行環境を選択するテンプレートがカテゴリ別に用意されています。テンプレートでは、プログラミング言語の単体の実行環境や、Data Store と連携させるテンプレートなどが提供されています。

プログラミング言語

Java
OpenJDK1.8、Red Hatがエンタープライズ向けに提供しているTomcat 7/8 であるRed Hat JBoss Web Server、Red Hat JBoss EAP のアップストリーム版である WildFly
Java Script
Node.jsの実行環境と、Node.js + MongoDB の実行環境
.NET
.NET Core 1.1
Perl
Perl5の実行環境と、Dancer サンプルアプリケーション + MySQL の実行環境
PHP
PHP7の実行環境と、CakePHPサンプルアプリケーション + MySQLの実行環境、Laravel サンプルアプリケーション + MySQL の実行環境
Python
Python3.5の実行環境と、Djangoサンプルアプリケーション + PostgreSQLの実行環境
Ruby
Ruby2.3の実行環境と、Railsサンプルアプリケーション+ PostgreSQLの実行環境

テクノロジ

CI/CD
Jenkins2.0の実行環境
Data Store
MariaDB、MongoDB、MySQL、PostgreSQL、Redisの実行環境

f:id:akubicharm:20170507151950p:plain

ユーザ認証

ユーザ認証は、Red Hat Customer Portal のアカウントの他に、Github.com、JBoss Developerといった開発者系のWebアカウントのほか Twitter、FacebookなどのSNSでの認証も可能になっています。

使ってみよう

パート1 エントリ

(1)OpenShift OnlineのURLにアクセス

https://www.openshift.com/にアクセスし、画面右上部のSIGN UP FOR FREEをクリックします。

f:id:akubicharm:20170508025139p:plain

(2)ログイン画面からサインアップ

画面中央のLOGIN WITH RED HATをクリックしサインアップ画面に遷移します。

f:id:akubicharm:20170508025153p:plain

(3)認証方式を選択します

Red Hatのカスタマーポータルのアカウントでログインする場合

f:id:akubicharm:20170508025544p:plain

 

フィールド名 説明
Email address or other Red Hat Login ID Red Hatのカスタマポータルで利用しているE-Mailアドレス
Password パスワード

SNSのアカウントなどで認証を行う場合は、画面を下にスクロールし連携させたい外部のサービスを選択します。

f:id:akubicharm:20170508025227p:plain

ここからプラン選択のウィザードでプランを選択していきます。

(4)プラン選択

FREE プランなので、画面下部のFREEボタンをクリックします。

f:id:akubicharm:20170508025243p:plain

(5)リージョン選択

ここも選択肢がないので、画面下部のUS East (Virginia)ボタンをクリックします。

f:id:akubicharm:20170508025252p:plain

(6)プランの確認

選択したプランの内容を確認し、画面下部のConfirm subscriptionボタンをクリックします。

f:id:akubicharm:20170508025303p:plain

アカウントプロビジョニング中の画面が表示されます。

f:id:akubicharm:20170508025330p:plain

少し待ってからリロードし、Open Web Consoleボタンをクリックして、OpenShift OnlineのWebコンソール画面に遷移します。

f:id:akubicharm:20170508025644p:plain

 

 

Azure Container RegistryのDocker Imageを指定してデプロイ

せっかくOpenShiftをAzureにデプロイしているので、Azureのサービスを活用した仕組みを作ってみました。

f:id:akubicharm:20170127194249p:plain

Azure Container Registryからコンテナイメージを取得するようにしておけば、危険かもしれない野良コンテナを持ち込まれないようにすることも可能になります。 また、社内のコンテナリポジトリで標準化されたコンテナイメージを配布する仕組みがあれば、OpenShift上でもローカルで実行する場合でも環境を統一することができます。

Azure Container Registry に Wildfly イメージを登録

docker hub から wildfly のコンテナイメージを取得して、Azure Container Repository に pushします。

docker pull docker.io/jboss/wildfly 
docker tag docker.io/jboss/wildfly xxxregistry-on.azurecr.io/komizoregistry/wildfly
docker login xxxregistry-on.azurecr.io
docker push xxxregistry-on.azurecr.io/komizoregistry/wildfly

OpenShift にアプリケーションをデプロイ

今回デプロイする Wildfly のコンテナイメージは、root ユーザーで実行されるようになっているので、特権コンテナとして実行するための設定と、Azure Container Registry へのアクセスに認証が必要になるのでsの設定も必要です。

プロジェクトの作成

oc new-project extrepo

Secret の作成

Azure Container Registory にアクセスするための認証情報を登録します。 docker login すると、ホームディレクトリの配下に認証情報のファイルが作成れます。 Docker version 1.12.5, build 047e51b/1.12.5 では、~/.docker/config.json ファイルです。

この認証情報を利用して、OpenShift から Azure Container Registry にアクセスするためのSecretを作成します。

oc secrets new external-registry .dockerconfigjson=docker-config.json

特権コンテナの実行を許可

OpenShiftのMasterサーバーで、クラスタ管理者(system:admin)でポリシーを設定します。

oadm policy add-scc-to-group anyuid system:serviceaccounts:extrepo

Secret を設定

oc secrets add serviceaccount/default secrets/external-registry --for=pull

コンテナイメージのpullにsecretが設定されたことを確認します。

$ oc describe serviceaccount/default
Name:       default
Namespace:  extrepo
Labels:     <none>

Image pull secrets: default-dockercfg-8tmb3
                    external-registry

Mountable secrets:  default-token-miful
                    default-dockercfg-8tmb3

Tokens:             default-token-c36r2
                    default-token-miful

コンテナイメージを指定してデプロイ

アプリケーションをデプロイして、URL でアプリケーションを公開できるようにRouteを作成します。

oc new-app --docker-image=xxxregistry-on.azurecr.io/komizoregistry/wildfly:latest
oc expose wildfly

OpenShiftのDynamic Storage Provisioning環境の構築 (containerized gluster on azure)

OpenShift 3.4 からDynamic Storage Provisioningが利用可能になったので、GlusterFSを使って試してみました

PersistentVolume(PV) と Persistent Volume Claim(PVC) を利用する仕組みでは、OpenShiftのクラスタ管理者が事前に Persistent Volumeという形でStoragePoolを準備しておき、アプリケーション側の要求(PVC)にマッチするものが関連づけられて、永続化ストレージが利用可能になる仕組みでした。 それに対して、Dynamic Storage Provisioning は、大きくストレージ領域を確保しておいて、必要に応じてボリュームを切り出してアプリケーションに割り当てます。

ホールケーキとピースのケーキみたいなイメージとか、袋菓子と小分包装のお菓子みたいなイメージと勝手に思ってる。。。 f:id:akubicharm:20170127122904p:plain

f:id:akubicharm:20170127121219p:plain

OpenShift 3.4 を Azure 上にデプロイ

Master サーバー（InfraNode, etcd も同居） 1台、Node サーバー 3台の構成で GlusterFSコンテナは3台のNodeサーバーにデプロイします。

事前準備

/etc/hosts に各サーバーのFQDNを含むIPアドレスを登録

52.175.xxx.yyy komizo-master.japanwest.cloudapp.azure.com
72.247.116.251 cdn.redhat.com

10.0.1.4 master master.r5xks4ipxxxxxxxxxxxxxxxxxxx.mx.internal.cloudapp.net
10.0.1.5 node01 node01.r5xks4ipxxxxxxxxxxxxxxxxxx.mx.internal.cloudapp.net
10.0.1.6 node02 node02.r5xks4ipxxxxxxxxxxxxxxxxxx.mx.internal.cloudapp.net
10.0.1.7 node03 node03.r5xks4ipxxxxxxxxxxxxxxxxxx.mx.internal.cloudapp.net

必要なパッケージのインストール

USER=`cat rhn-user`
PASSWORD=`cat rhn-password`
POOL_ID=`cat rhn-poolid`

subscription-manager register --username $USER --password $PASSWORD
subscription-manager attach --pool=$POOL_ID

subscription-manager repos --disable="*"
subscription-manager repos \
    --enable="rhel-7-server-rpms" \
    --enable="rhel-7-server-extras-rpms" \
    --enable="rhel-7-server-ose-3.4-rpms"


yum -y install wget git net-tools bind-utils iptables-services bridge-utils bash
-completion
yum -y update
yum -y install atomic-openshift-utils
yum -y install atomic-openshift-excluder atomic-openshift-docker-excluder
atomic-openshift-excluder unexclude

yum -y install docker

sed -i '/OPTIONS=.*/c\OPTIONS="--selinux-enabled --insecure-registry 172.30.0.0/16"' /etc/sysconfig/docker

Ansible プレイブック実行ユーザーの公開鍵を配置

drwx------. 2 ansible ansible 29 Jan 26 10:29 /home/ansible/.ssh
-rw-------. 1 ansible ansible 396 Jan 26 10:29 /home/ansible/.ssh/authorized_keys

Ansible インベントリファイルの準備

サーバーに割り振られたサブネットが、dockerのデフォルトのサブネットと重複するのでosm_cluster_network_cidrで、dockerのサブネットを指定します。

# Create an OSEv3 group that contains the masters and nodes groups
[OSEv3:children]
masters
nodes

# Set variables common for all OSEv3 hosts
[OSEv3:vars]
# SSH user, this user should allow ssh based auth without requiring a password
ansible_ssh_user=ansible

# If ansible_ssh_user is not root, ansible_become must be set to true
ansible_become=true

deployment_type=openshift-enterprise

openshift_master_default_subdomain=52.175.xxx.yyy.xip.io
osm_cluster_network_cidr=10.128.0.0/14

os_sdn_network_plugin_name=redhat/openshift-ovs-multitenant 


# uncomment the following to enable htpasswd authentication; defaults to DenyAllPasswordIdentityProvider
openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider', 'filename': '/etc/origin/master/htpasswd'}]

# host group for masters
[masters]
komizo-master.japanwest.cloudapp.azure.com

# host group for nodes, includes region info
[nodes]
komizo-master.japanwest.cloudapp.azure.com openshift_node_labels="{'region': 'infra', 'zone': 'default'}" openshift_public_hostname=komizo-master.japanwest.cloudapp.azure.com openshift_schedulable=true
node01 openshift_node_labels="{'region': 'primary', 'zone': 'east'}"
node02 openshift_node_labels="{'region': 'primary', 'zone': 'west'}"
node03 openshift_node_labels="{'region': 'primary'}"

OpenShift のインストール

 ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/byo/config.yml

Containerized Gluster のデプロイ

事前準備

必要なパッケージのインストール

Masterサーバーに必要なパッケージをインストールします。

subscription-manager repos --enable=rh-gluster-3-for-rhel-7-server-rpms
yum -y install cns-deploy heketi-client

iptables の編集

以下のルールを /etc/sysconfig/iptables に登録します。

-A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 24007 -j ACCEPT
-A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 24008 -j ACCEPT
-A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 2222 -j ACCEPT
-A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m multiport --dports 49152:49664 -j ACCEPT

変更を反映します。

systemctl reload iptables
iptables -L

GlusterFS用のディスクを追加

3台のNodeサーバーにディスクを追加します。 /dev/sda, /dev/sdb はすでにできているので、新たに追加したボリュームは /dev/sdcになります。

f:id:akubicharm:20170127103111p:plain

  1. ボリュームを追加するVirtual Machineを選択
  2. Disksを選択
  3. Attach Newでディスクの追加
  4. 必要なパラメータを設定して「OK」をクリック

※ここで、Locationは同一リソースグループ内のStorageAccountを選択すること！！

GlusterFSのデプロイ

トポロジーファイルの作成

/usr/share/heketi/topology-sample.json をコピーして今回の環境に合うように編集します。

[topology.json]

{
    "clusters": [
        {
            "nodes": [
                {
                    "node": {
                        "hostnames": {
                            "manage": [
                                "node01.r5xks4ipxxxxxxxxxxxxxxxxxx.mx.internal.cloudapp.net"
                            ],
                            "storage": [
                                "10.0.1.5"
                            ]
                        },
                        "zone": 1
                    },
                    "devices": [
                        "/dev/sdc"
                    ]
                },
                {
                    "node": {
                        "hostnames": {
                            "manage": [
                                "node02.r5xks4ipxxxxxxxxxxxxxxxxxx.mx.internal.cloudapp.net"
                            ],
                            "storage": [
                                "10.0.1.6"
                            ]
                        },
                        "zone": 2
                    },
                    "devices": [
                        "/dev/sdc"
                    ]
                },
                {
                    "node": {
                        "hostnames": {
                            "manage": [
                                "node03.r5xks4ipxxxxxxxxxxxxxxxxxx.mx.internal.cloudapp.net"
                            ],
                            "storage": [
                                "10.0.1.7"
                            ]
                        },
                        "zone": 1
                    },
                    "devices": [
                        "/dev/sdc"
                    ]
                }
            ]
        }
    ]
}

GlusterFSコンテナのデプロイ

GlusterFS のコンテナをデプロイするためのプロジェクトを作成し、特権コンテナとして実行するための権限設定などを行います。

以下の作業はMasterサーバーにてsystem:adminユーザで実行します。

oc new-project storage-project
oadm policy add-scc-to-user privileged -z default

コンテナ版のGlusterFSをデプロイします。

cns-deploy -n storage-project -g topology.json

デプロイの実行結果は https://access.redhat.com/documentation/en/red-hat-gluster-storage/3.1/single/container-native-storage-for-openshift-container-platform/#idm140637724619968を参照してください。

※ここで何かエラーがあって、再実行する場合はoc delete all --allで作成済みPodなどを削除してから再実行します。

Glusterのトポロジを確認します。

export HEKETI_CLI_SERVER=http://heketi-storage-project.52.175.148.91.xip.io
heketi-cli topology info

NodeサーバーでVolumeができていることを確認します。

[root@node01 ~]# pvs
  PV         VG                                  Fmt  Attr PSize PFree
  /dev/sdc   vg_b3dfc1b27ddc928dfe5dab9855d234d7 lvm2 a--  9.87g 6.84g

Dynamic Stroge Provisioningの利用

StorageClassの作成

StorageClassとSecretの定義ファイルを作成します。

[glusterfs-storageclass.yaml]

apiVersion: storage.k8s.io/v1beta1
kind: StorageClass
metadata:
  name: gluster-container
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://heketi-storage-project.52.175.xxx.yyy.xip.io"
  restuser: "admin"
  secretNamespace: "default"
  secretName: "heketi-secret"

[glusterfs-secret.yaml]

apiVersion: v1
kind: Secret
metadata:
  name: heketi-secret
  namespace: default
data:
  # base64 encoded password. E.g.: echo -n "mypassword" | base64
  key: bXlwYXNzd29yZA==
type: kubernetes.io/glusterfs

StorageClassとSecretを作成します。

oc project storage-project
oc create -f glusterfs-storageclass.yaml
oc create -f glusterfs-secret.yaml

Persistent Storageを利用するアプリケーションのデプロイ

JBoss EAP7 とMySQLを使ったToDoアプリケーションをデプロイします。OpenShiftのインストール時に用意されているテンプレートは、StaticなPersistent Volumeを利用するようになっているので、少し編集してDynamic Persistent Volumeを利用するテンプレートを新しく準備してアプリケーションをデプロイします。

テンプレートの作成

既存の eap70-mysql-persistent-s2i テンプレートをエクスポートします。

oc get templates -n openshift |grep eap70-mysql
oc export templates eap70-mysql-persistent-s2i -n openshift -o json > eap70-mysql-storageclass-s2i.json

metadata.nameをeap70-mysql-persistent-s2iからeap70-mysql-storagclass-s2iに変更します。
labels.templateをeap70-mysql-persistent-s2iからeap70-mysql-storagclass-s2iに変更します。
PersistentVolumeClaimにannotationを追加します。

    "metadata": {
        "name": "eap70-mysql-storageclass-s2i",
        "creationTimestamp": null,
        "annotations": {
            "description": "Application template for EAP 7 MySQL applications with persistent storage built using S2I.",
            "iconClass": "icon-jboss",
            "tags": "eap,mysql,javaee,java,database,jboss,xpaas",
            "version": "1.3.2"
        }
    },

>>> 中略 <<<
        {
            "apiVersion": "v1",
            "kind": "PersistentVolumeClaim",
            "metadata": {
                "labels": {
                    "application": "${APPLICATION_NAME}"
                },
                "name": "${APPLICATION_NAME}-mysql-claim",
                "annotations": {
                    "volume.beta.kubernetes.io/storage-class": "gluster-container"
                }
            },
            "spec": {
                "accessModes": [
                    "ReadWriteOnce"
                ],
                "resources": {
                    "requests": {
                        "storage": "${VOLUME_CAPACITY}"
                    }
                }
            }
        }

>>> 中略 <<<

    "labels": {
        "template": "eap70-mysql-storageclass-s2i",
        "xpaas": "1.3.2"
    }

テンプレートを登録します。

oc create -f eap70-mysql-storageclass-s2i.json -n openshift

ここで、-n openshiftオプションを指定することで、OpenShiftのユーザー全員がこのテンプレートを利用可能になります。このオプションを指定しない場合は、作業中のプロジェクトのみでこのテンプレートが利用可能になります。

アプリケーションのデプロイ

Secretの準備

[eap7-app-secret.json]

{
    "kind": "List",
    "apiVersion": "v1",
    "metadata": {
        "annotations": {
            "description": "Examples that can be installed into your project to allow you to test the EAP template. You should replace the contents with data that is more appropriate for your deployment."
        }
    },
    "labels": {
        "template": "eap7-app-secret"
    },
    "items": [
        {
            "kind": "ServiceAccount",
            "apiVersion": "v1",
            "metadata": {
                "name": "eap7-service-account"
            },
            "secrets": [
                {
                    "name": "eap7-app-secret"
                }
            ]
        },
        {
            "kind": "Secret",
            "apiVersion": "v1",
            "metadata": {
                "annotations": {
                    "description": "Default secret file with name 'jboss' and password 'mykeystorepass'"
                },
                "name": "eap7-app-secret"
            },
            "data": {
                "keystore.jks": "/u3+7QAAAAIAAAABAAAAAQAFamJvc3MAAAFNbVtLLAAABQMwggT/MA4GCisGAQQBKgIRAQEFAASCBOsxl4wqa+E+XP8+qMZY9XLhvKrRX8V1MHdwFZQaLTEVURCizqYXoMnbhtfV0oMAUFsE7013TTA9Q2l+pSs+cqz6HH/vwjEEIkqJx5wD8WcD/bu9e9F9EHQ+zrjZFmpMFvXsvj9+ux1o/YLBDGY3kd4MoDcJy0yJ/ZpzNYLkXanlrMhWqxC7MAliCBsdyVgNn5RFb4Nn+JZgJuNSIGo/K292+0IFaFv9vsXbX889W9HPCvfO0mQIzoy8In0NhzdKli/67y4kbDkWaI0fRONckZTxNpxn6rMc0nN9zKrGVToLxj1Ufcoj/tCvR8agtPpv7KIWUqBYDg83ad+i4EE5XYISovlsl6RmtrrTb39PJcL86+wJ+x2ZrLuyzh6C9sAOdSBiKt/DY97ICIYltRMrb+cNwWdnJvT+PeYvv3vKo7YThha+akoJDjsWMp1HWpbIC9zg9ZjugU+/ao6nHtmoZmCaYjLuEE+sYl5s179uyQjE3LRc+0cVY2+bYCOD6P6JLH9GdfjkR40OhjryiWy2Md6vAGaATh6kjjreRHfSie4KCgIZx9Ngb1+uAwauYSM8d9OIwT5lRmLd4Go9CaFXtFdq/IZv3x5ZEPVqMjxcq0KXcs1QcfK3oSYL/rrkxXxKFTrd0N3KgvwATWx/KS90tdHBg65dF3PpBjK1AYQL3Q7KV3t45SVyYHd92TUsaduY1nUQk4TukNC8l9f8xYVeOFXoFHZRx9edqn8fjDMmCYn5PTPNuMPHQm7nKxeWhV2URY5jt774gmvHLNcXeEgrM7US81wOvs2y1jY/paJWn+OACf2x2a75MWFFkZH67bZoh9pPWAwOUEtegXTL5QVicHjzZrop8Qb7K7hlGgD0RP5YYOFYF4DD+SL5BHKr6fw/LS6MMJaK1wKsJd0oGg9HcHXjph9Kb+mqXrQ54C1KI42LpFftU3DCg8wGoqvg/zO/UtVeHX3rBZDUIkeQrCULEkki9oL5diDxe9mNx9Qua5FJ6FJGIffQmsC4b0+Xys6NyqUu1aeWLcAPA/5hcs6ZTiSRTHTBe3vxapyBjnAL5uij4ILbWbEGH1e0mAHBeiihRx+w4oxH4OGCvXOhwIDHETLJJUcnJe1CouECdqdfVy/eEsIfiEheVs8OwogJLiWgzB7PoebXM4SKsAWL3NcDtC1LV3KuPgFuTDH7MjPIR83eSxkKlJLMNGfEpUHyg+lm7aJ98PVIS+l1YV9oUzLfbo3S6S2sMjVgyviS90vNIPo5JOTEFHsg5aWJNHL0OV4zRUeILzwwdQz+VkTk9DobnkLWUeLnwUNWheOpaQh79Mk0IfwfLj4D0Vx9p+PShKKZCGs0wjckmCFBM5Pc1x2lwMdaP5yATzrw+jUc+/3UY4PF/4Ya66m/DRsBKEcXjVAHcTce6OdNdGlBNT8VgkxPiylwO8hvyvpf6j+wdb9iXi6eOnk0AiEJ6mUAXs/eyDD/cqQjnUBKRGLQUSdHhvtpw8RfvyVhAAxNOnBsOT0WYol9iK6pSclGTF5mZleASRzZhH69GgdebfFhXimb0j/wYj3uLgf6mrKMDwlrXJ80SiWkXxd5TX/7XtB9lbPzNpaR12M8U8UVg16VOtMwCR2Gss2vmhqQnQFLsUsAKcYM0TRp1pWqbzpGebCvJkVWiIYocN3ZI1csAhGX3G86ewAAAAEABVguNTA5AAADeTCCA3UwggJdoAMCAQICBGekovEwDQYJKoZIhvcNAQELBQAwazELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAk5DMRAwDgYDVQQHEwdSYWxlaWdoMRYwFAYDVQQKEw1teWNvbXBhbnkuY29tMRQwEgYDVQQLEwtFbmdpbmVlcmluZzEPMA0GA1UEAxMGanNtaXRoMB4XDTE1MDUxOTE4MDYxOFoXDTE1MDgxNzE4MDYxOFowazELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAk5DMRAwDgYDVQQHEwdSYWxlaWdoMRYwFAYDVQQKEw1teWNvbXBhbnkuY29tMRQwEgYDVQQLEwtFbmdpbmVlcmluZzEPMA0GA1UEAxMGanNtaXRoMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAk0zbGtem+If//jw0OTszIcpX4ydOCC0PeqktulYkm4pG0qEVBB+HuMj7yeTBc1KCDl2xm+Q6LPeTzUufk7BXFEg4Ru1l3PSW70LyJBfHy5ns0dYE5M1I0Avv9rvjgC1VTsiBmdXh+tIIQDPknIKpWpcs79XPOURGLvuGjfyj08EZWFvAZzYrk3lKwkceDHpYYb5i+zxFRz5K6of/h9gQ9CzslqNd7uxxvyy/yTtNFk2J797Vk3hKtbiATqc9+egEHcEQrzADejPYol5ke3DA1NPRBqFGku5n215i2eYzYvVV1xmifID/3lzvNWN0bWlOxl74VsPnWa/2JPP3hZ6p5QIDAQABoyEwHzAdBgNVHQ4EFgQURLJKk/gaSrMjDyX8iYtCzPtTBqAwDQYJKoZIhvcNAQELBQADggEBAA4ESTKsWevv40hFv11t+lGNHT16u8Xk+WnvB4Ko5sZjVhvRWTTKOEBE5bDYfMhf0esn8gg0B4Qtm4Rb5t9PeaG/0d6xxD0BIV6eWihJVtEGOH47Wf/UzfC88fqoIxZ6MMBPik/WeafvOK+HIHfZSwAmqlXgl4nNVDdMNHtBhNAvikL3osxrSbqdi3eyI7rqSpb41Lm9v+PF+vZTOGRQf22Gq30/Ie85DlqugtRKimWHJYL2HeL4ywTtQKgde6JDRCOHwbDcsl6CbMjugt3yyI7Yo9EJdKb5p6YoVOpnCz7369W9Uim+Xrl2ELZWM5WTiQFxd6S36Ql2TUk+s8zj/GoN9ov0Y/yNNCxAibwyzo94N+Q4vA=="
            }
        }
    ]
}

CLIの場合

  1. プロジェクトの作成 oc new-project [プロジェクト名]
  2. Secretの登録 oc create -f eap7-app-secret.json
  3. アプリケーションのデプロイ oc new-app eap70-mysql-storageclass-s2i

WebUIの場合

  1. プロジェクトの作成
    「New Project」ボタンをクリックしてウィザードを開始します。ウィザードの「Name」フィールドにプロジェクト名を入力します。
  2. Secretの登録
    CLIの場合と同様にSecretを作成します。 oc create -f eap7-app-secret.json
  3. テンプレートの選択
    カタログから「Java」–> 「Red Hat JBoss EAP」–> 「eap70-mysql-storageclass-s2i」 を選択
  4. アプリケーションのデプロイ
    「Create」ボタンをクリックしてアプリケーションのデプロイを開始します。

アプリケーションのデプロイの確認

oc get routeで接続先URLを確認しブラウザでアクセスします。 ToDoアプリケーションの画面で、「Summary」と「Description」を入力します。 f:id:akubicharm:20170127114829p:plain

PVの確認

$ oc get pv
NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                      REASON    AGE
pvc-d8621646-e437-11e6-abba-000d3a4075fa   1Gi        RWO           Delete          Bound     app/eap-app-mysql-claim              2m
$ oc get pvc
NAME                  STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
eap-app-mysql-claim   Bound     pvc-d8621646-e437-11e6-abba-000d3a4075fa   1Gi        RWO           4m

Podを再起動して永続化されていることを確認

MySQLのPodを削除し、再起動されるのを待ちます。

$ oc get pods
NAME                    READY     STATUS      RESTARTS   AGE
eap-app-1-0etnn         1/1       Running     0          6h
eap-app-1-build         0/1       Completed   0          6h
eap-app-mysql-1-a16oe   1/1       Running     0          6h
$ oc delete pod eap-app-mysql-1-a16oe

MySQLのPodが再起動された、再び ToDo アプリケーションにアクセスし、先ほど入力した「Summary」と「Description」が表示されていることを確認します。

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の向上が両方できた良い事例でした。