Open Shift v3 主要機能と内部構造のご紹介

OpenShift v3
主要機能と内部構造のご紹介
レッドハット株式会社
中井悦司 / Etsuji Nakai
Senior Solution Architect
and Cloud Evangelist
v1.1 2016/01/29

2
OpenShift v3主要機能と内部構造のご紹介
Contents
 Dockerが生まれた背景
 OpenShiftの主要機能
 OpenShiftのイメージ管理機能
 アプリケーションのデプロイ方法
 参考資料

4
クラウドサービスとしてのPaaS環境の課題
 PaaSのメリット
⇒ 実行環境の構築・管理に手間をかけず、アプリケーション開発に集中
アプリケーション実行環境
（フレームワーク／ライブラリー）
サーバー／OS
開発したコードを
クラウドにデプロイ
アプリケーション
プログラム

5
アプリケーション実行環境
（フレームワーク／ライブラリー）
サーバー／OS
プログラム
クラウドサービスとしてのPaaS環境の課題
 アプリケーションのコードと実行環境は、多くの場合、密結合しており、
「ありもの」の実行環境だけでは、不便が生じることも多い
「悪魔は細部に宿る」
・使いたいフレームワークが無い
・必要なライブラリーが不足
・ライブラリーバージョンの不整合
・etc...

6
dotCloudが実行環境のメンテナンスに用意した仕組み
 dotCloud社は、クラウド内部の仕組みとして、アプリケーションの実行
環境を自動構築して「Dockerイメージ」に固める技術を開発
– さらに、クラウド以外の環境でも利用できるようにオープンソースとして公開
Dockerサービス
サーバー／OS
プログラム
さまざまな実行環境を
Dockerイメージとして
作成・メンテナンス
Docker
イメージ

7
Dockerが提供する基本機能
Dockerfile
① Dockerイメージを自動作成
OSイメージ
ライブラリー
フレームワーク
イメージの
作成手順を記載
Docker
イメージ
OS上にインストール可能な
ものはすべてイメージ化可能
② Dockerイメージを保存・公開
③ Dockerサーバーに
　イメージを配布・実行

9
OpenShiftが提供する主な追加機能
 Dockerイメージのバージョン管理
– イメージストリームとイメージビルドシステム
– 「開発環境」そのものを開発可能に
 同一の開発環境のクラウド上への配布
– テンプレート機能
– それぞれの開発者に「自分専用」の開発／検証環境を提供
 マルチテナントでの利用
– プロジェクト単位でのネームスペースの分割
– 開発機能（ブランチ）単位で独立した開発／検証環境を提供
 サーバーの境界を意識しないコンテナのデプロイ
– Kubernetesによるコンテナのオーケストレーション
– マイクロサービス型アプリケーションのDevOps環境を実現

10
従来のPaaSの利用形態
アプリ開発者
開発環境
テンプレート
新しいコードをPushすると
開発・テスト環境に展開してビルド
開発したコードの
稼働確認

11
従来のPaaSの利用形態
アプリ開発者
開発環境
テンプレートテンプレートそのものの
メンテナンスはどうする？
開発中に開発環境の
アップデートは可能？
開発が終わったアプリは
どうやって本番展開する？

12
OpenShiftにおける役割分担
アプリ開発者
開発環境
構成テンプレート
テンプレート管理者
公式RHEL
イメージ
Dockerfile
テスト担当者
開発環境
イメージ
テスト環境
開発中
アプリイメージ
ソースコード
動作確認
コード開発
テスト用
デプロイ環境
動作確認
本番環境
開発用デプロイ環境
本番用
デプロイ環境
開発済み
テスト済み
リリース担当者

13
OpenShiftにおける「開発環境」のメンテナンス機能
RHELイメージ
開発環境イメージ
テスト用アプリ
イメージ
セキュリティ問題等の修正が入った
新しいRHELイメージをアップロード
Dockerfileを用いて
開発環境イメージを更新
アプリケーションを
自動ビルドして機能テスト
修正・テスト済みの
開発環境イメージを参照
開発中アプリ
イメージ
新しいコードをPushすると
アプリイメージを自動更新
テンプレート管理者
アプリ開発者

14
マルチテナントによる機能別の並行開発
アプリ開発者
イメージ
 開発機能ごとにコードのブランチを分けて、各ブラ
ンチ専用の開発環境を個別に用意します。
アプリ開発者
イメージ
テスト担当者
イメージ
マスターブランチ
開発済み機能をマージした
マスターブランチのコードを検証
機能Aの開発
機能Bの開発
開発した機能を
マージ
開発した機能を
マージ

15
OpenShiftによるDevOpsの実現
 開発／テストとサービス用でプロジェクトを分割することで、OpenShift上でのDevOps環境
が実現できます。
内部レジストリー
ImageStream
BuildConfig
Deployment
Config
Route
Service Service
エイリアス
テスト済みイメージを
エイリアスで参照
Deployment
Config
開発／テスト
プロジェクト
サービス用
プロジェクト
イメージの
実体を保存アプリケーションの元ネタ
（Dockerfile/ソースコード）
を保存
Route
RHEL7
MyApp MyApp

16
テンプレートとGUIの組み合わせによるPaaSの提供
 テンプレート機能とGUIを組み合わせることで、アプリケーション開発者には、従来型の
「PaaS」環境として見せることができます。
アプリケーション開発者は
コードの開発のみに集中

18
OpenShiftの基本サーバー構成
etcd
・・・
バックエンドデータベース（KVS）
マスター
ノード
・・・
クラスタ構成で
負荷分散可能
Docker Docker Docker
必要に応じて
追加可能
 １台のマスターから複数のノードを管理するシンプルなアーキテクチャーです。
– 各ノードのエージェントとマスターが直接に通信します。
– バックエンドデータベースは、etcd（分散KVS）を使用します。
– OpenShiftの利用者（CLI）は、マスターが公開するAPIにアクセスします。
利用者（CLI）

19
OpenShiftのネットワーク構成
etcd マスター
オーバーレイネットワーク
として構成
・・・
 物理的には、全サーバーを共通のサービスネットワークに接続するだけで利用可能です。
– コンテナ間通信用の内部ネットワークは、オーバーレイネットワークとして構成されます。
– 外部からのアクセスは、ルータ用コンテナを経由します。
• ルータがあるノードの80番ポート宛のパケットは、iptablesでルーターに転送されます。ルータ
は、URLベースで接続先のコンテナを決定します。
サービスネットワーク
ノード
内部ネットワーク
コンテナコンテナ
ブリッジ
ルータ
ブリッジ
ノード

20
「サービス」によるコンテナ間接続
 コンテナで起動したアプリケーションに対して、「サービス」を定義すると、内部ネット
ワーク上の「サービスアドレス」が割り当てられます。
– 他のコンテナから「サービスアドレス」にアクセスすると、対応するコンテナにパケットが転送され
ます。（複数のコンテナがある場合は、ラウンドロビンで負荷分散が行われます。）
– 事前に「サービス」を定義した状態で、新規のコンテナを起動すると、サービスのIPアドレス／ポー
トを示す環境変数が自動的にセットされます。
# oc get service
NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR AGE
etherpad-lite 172.30.14.201 <none> 9001/TCP deploymentconfig=etherpad-lite 7d
mysql 172.30.86.51 <none> 3306/TCP name=mysql 7d
apiVersion: v1
kind: Service
metadata:
name: mysql
spec:
ports:
- name: mysql
port: 3306
protocol: TCP
targetPort: 3306
selector:
name: mysql-pod
sessionAffinity: None
mysql-service.yml
MYSQL_SERVICE_HOST=172.30.86.51
MYSQL_SERVICE_PORT_MYSQL=3306
サービス定義ファイルの例
割り当てられた
サービスアドレス
新規のコンテナに
セットされる環境変数の例

21
「ルーティング」による外部接続
 「サービス」に加えて「ルーティング」を定義すると、外部からのURLアクセスが可能にな
ります。
– HAProxyが稼働するルータコンテナがURLベースのルーティング処理を行ないます。
– 下記の例では、「*.oso.example.com」が「ルータコンテナが稼働するノードのパブリックIP」に解
決されるように外部DNSが事前設定されています。
– 複数のルータコンテナを起動して、DNSラウンドロビンで負荷分散することも可能です。
# oc get route
NAME HOST/PORT PATH SERVICE
etherpad-lite-route eplite.project01.oso.example.com etherpad-lite
apiVersion: v1
kind: Route
metadata:
name: etherpad-lite-route
spec:
host: eplite.project01.oso.example.com
to:
kind: Service
name: etherpad-lite
etherpad-lite_route.yml
ルーティング定義ファイルの例
アプリケーションのURL

22
「サービス」と「ルーティング」のパケット経路
 「サービス」として定義されたIPアドレス宛のパケットは、iptables設定によって、ノード
上の「openshift-nodeエージェント」に転送されます。
– openshift-nodeエージェントは、実際にサービスを提供するコンテナにラウンドロビンでパケットを
転送します。
 「ルーティング」を定義すると、ルータコンテナ上のHAProxyに、対応する設定がなされる
ことで、URLベースでのルーティングが実施されます。
openshift-node
エージェント
オーバーレイネットワーク
ブリッジ
ルータ
コンテナ
iptables
iptables
DNS
ラウンドロビン
ラウンド
ロビンリースト
コネクション
コンテナ間のアクセス
外部からのアクセス
openshift-node
エージェント
ブリッジ
ルータ
コンテナ
iptables
iptables
ラウンド
ロビンリースト
コネクション

OpenShiftのイメージ管理機能

24
OpenShiftにおけるイメージ管理
 Docker Hub、もしくは、Dockerホストローカルのイメージは、「ユーザー名/リポジトリ名
: タグ」という名称で識別されます。
– タグによるバージョン管理が可能ですが、自由に付け替えができるため、利用者自身が意識的にタグ
名を操作する必要があります。
 OpenShiftで取り扱うイメージは、専用の内部レジストリーに保存して、独自のバージョン
管理を行ないます。
– 内部レジストリーの中では、「プロジェクト名/リポジトリ名@<sha256ハッシュ>」という名称でイ
メージを識別します。ハッシュ値が、GitのコミットIDに相当するユニークな識別子になります。
– バージョン情報（イメージが更新された時系列）については、別途、「イメージストリーム」を定義
して、そちらで管理します。
# oc get is
NAME DOCKER REPO TAGS UPDATED
centos7 172.30.84.64:5000/project01/centos7 latest 7 days ago
etherpad-lite 172.30.84.64:5000/project01/etherpad-lite latest 7 days ago
nodejs-base 172.30.84.64:5000/project01/nodejs-base latest 7 days ago
# oc describe is etherpad-lite
Name: etherpad-lite
Created: 7 days ago
Labels: <none>
Annotations: openshift.io/image.dockerRepositoryCheck=2016-01-03T09:53:25Z
Docker Pull Spec: 172.30.84.64:5000/project01/etherpad-lite
Tag Spec Created PullSpec
latest <pushed> 5 days ago 172.30.84.64:5000/project01/etherpad-lite@sha256:9b5e7f9fc58...
7 days ago 172.30.84.64:5000/project01/etherpad-lite@sha256:05c4600b8ab...
project01のイメージストリーム一覧
イメージストリーム
「etherpad-lite」
に含まれるイメージ

25
OpenShiftにおけるイメージ管理
 イメージストリームには、次のような際に新しいバージョンのイメージが登録されます。
– 内部レジストリーにイメージをPushした時
• プッシュ時の「プロジェクト名/レジストリー名」から、対応するプロジェクトの（レジスト
リーと同名の）イメージストリームに新バージョンとして登録されます。
– OpenShiftのイメージビルドシステムを用いて、新しいイメージをビルドした時
• イメージビルドシステムは、GitHubで公開したDockerfile、アプリケーションのソースコードな
どを用いて、新しいイメージを作成、内部レジストリーに保存する機能です。
# docker pull centos:7
# docker login -u enakai -e enakai@example.com -p $(oc whoami -t) registry.oso.example.com
# docker tag docker.io/centos:7 registry.oso.example.com/project01/centos7:latest
# docker push registry.oso.example.com/project01/centos7:latest
# oc get is
NAME DOCKER REPO TAGS UPDATED
centos7 172.30.84.64:5000/project01/centos7 latest 7 seconds ago
# oc describe is centos7
ame: centos7
Created: 24 seconds ago
Labels: <none>
Annotations: openshift.io/image.dockerRepositoryCheck=2015-12-28T11:32:19Z
Docker Pull Spec: 172.30.84.64:5000/project01/centos7
Tag Spec Created PullSpec
latest <pushed> 24 seconds ago 172.30.84.64:5000/project01/centos7@sha256:b04ac...
CentOS7のイメージを
内部レジストリーに
Pushする例

26
OpenShiftのイメージビルドシステム
 イメージビルドシステムは、「ビルド設定（BuildConfig）」を定義して利用します。次は、
GitHubで公開したDockerfile（および、ビルドに必要な関連ファイル）からイメージをビル
ドする設定の例です。
apiVersion: v1
kind: BuildConfig
metadata:
name: nginx-sample
spec:
output:
to:
kind: ImageStreamTag
name: nginx-sample:latest
source:
git:
uri: https://github.com/enakai00/openshift_nginx_sample
type: Git
strategy:
dockerStrategy:
from:
name: centos7:latest
type: Docker
triggers:
- imageChange: {}
type: ImageChange
nginx-sample_bc.yml
– Docerfileの「FROM:」行は、イメー
ジストリーム「centos7」のイメー
ジで置き換えられます。
– 作成されたイメージは、内部レジス
トリーに保存された後、イメージス
トリーム「nginx-sample」に自動登
録されます。
– 「start-build」コマンドを明示的に
実行する他に、イメージストリーム
「centos7」のイメージが更新され
たタイミング、GitHubに新たな
Commitが行われたタイミングでも
自動的にビルドが実行可能です。

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

28
イメージストリームからのコンテナのデプロイ
 「デプロイ設定（DeploymentConfig）」を用いて、イメージストリームに登録したイメー
ジからコンテナをデプロイします。
apiVersion: v1
kind: DeploymentConfig
metadata:
name: nginx-sample
spec:
template:
metadata:
labels:
name: nginx-sample
spec:
containers:
- name: nginx-sample-latest
image: nginx-sample:latest
ports:
- containerPort: 8080
protocol: TCP
replicas: 4
selector:
name: nginx-sample
triggers:
- type: ImageChange
imageChangeParams:
automatic: true
containerNames:
- nginx-sample-latest
from:
name: nginx-sample:latest
- type: ConfigChange
nginx-sample_dc.yml
– レプリカ数で指定した数のコンテナが起動します。
先に説明した「サービス」の定義により、複数コン
テナに対するロードバランスが行われます。
– イメージストリームに新しいイメージが登録される
と、自動で再デプロイを実施することができます。
再デプロイ時は、新バージョンのコンテナを追加起
動して、新しいセッションから新バージョンに振り
分けるといった動作が可能です。

29
複数コンテナが連携するシステムの構築例
 下記のBlog記事に従って、MySQL + node.jsのアプリケーション環境を構築してみます。
– OpenShift OriginによるDockerイメージ管理（4）〜S2Iによるイメージビルド
• http://enakai00.hatenablog.com/entry/2016/01/03/174854
– OpenShift OriginによるDockerイメージ管理（5）〜複数コンテナの連携設定
• http://enakai00.hatenablog.com/entry/2016/01/03/200920

EMPOWER PEOPLE,
EMPOWER ENTERPRISE,
OPEN INNOVATION.

Open Shift v3 主要機能と内部構造のご紹介

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (9)

Similar to Open Shift v3 主要機能と内部構造のご紹介

Similar to Open Shift v3 主要機能と内部構造のご紹介 (20)

More from Etsuji Nakai

More from Etsuji Nakai (20)

Recently uploaded

Recently uploaded (10)

Open Shift v3 主要機能と内部構造のご紹介