狠狠撸

RED HAT ENTERPRISE LINUX 71
OpenShift v3 Technical Overview
Kenjiro Nakayama
Technical Support Engineer
Jan 14, 2016

1. コンテナオーケストレーション
2. PaaS プラットフォーム
3. DevOps プラットフォーム
コンテンツ

コンテンツ内訳
l?? アーキテクチャ概要 (OpenShift Master/Node)
l?? デプロイのコンセプト (Pod、ReplicationController、Service)
l?? ネットワーク (HA Proxy ルーター、OpenShift SDN)
l?? コンテナビルドと実行環境 (DeploymentConfig、BuildConfig、S2I)
l?? デプロイメントパイプライン (ImageStream)

1. コンテナオーケストレーション

1.1 コンポーネント

ブラウザ
CLI
etcd
web UI
scheduler
controller
API server
kublet
openshift sdn
docker service
OpenShift v3 主要コンポーネント
OpenShift Master
OpenShift Node
OpenShift CLI

ブラウザ
CLI
etcd
web UI
scheduler
controller
API server
kublet
open-vswitch + atomic-openshift-sdn-ovs
OpenShift v3 コンポーネント (パッケージ単位)
atomic-openshift-node
atomic-openshift-master (master)
atomic-openshift-clients
docker

ブラウザ
CLI
etcd
web UI
scheduler
controller
API server
kublet
openshift sdn
① コンテナデプロイ要求
② スケジューリング
…/nodeX.example.com/リソース情報
③ API アップデート
④アップデート情報の監視
⑤コンテナ(Pod)デプロイ
OpenShift v3 デプロイフロー概略
docker service

Open Shift v3 主要コンポーネント (Master)
OpenShift Master
l?? サービス名: atomic-openshift-master
l?? APIサーバーを公開し、Nodeの管理とpodのスケジューリン
グを行うホスト
l?? etcdサーバーで、各NodeのPodやNetwork情報を保持
l?? v3.1からは、MasterサーバーをActive-Active構成でHAを組む
ことが可能

Open Shift v3 主要コンポーネント (Node)
OpenShift Node
l?? サービス名: atomic-openshift-node
l?? コンテナのランタイム環境を提供するホスト
l?? 内包されているkubeletが、Master上のAPI「/registry/hosts/<
ノードホスト名>」を監視し、更新があればコンテナ(Pod)や
リソースの更新を行う
OpenShift SDN
l?? atomic-openshift-node サービスの一部として機能する
l?? Open vSwitchを使ったSDNを実現し、別ホスト上のコンテナ
に同一ホスト上のコンテナかのようにアクセスを可能にする

Open Shift v3 主要コンポーネント (Client)
$ openshift コマンド
l?? 管理者用コマンド
l?? Master、Nodeの起動時にsystemdから呼び出されるのみで、基本
的には利用しない
$ oadm コマンド
l?? 管理者用コマンド
l?? Nodeの管理、証明書の生成、OpenShift上のHAProxyルーター、
Docker reigstryをデプロイする際に利用
$ oc コマンド (Web コンソール)
l?? 一般ユーザー(OpenShift利用者)が使用するコマンド
l?? Masterが公開しているAPIにアクセスする

[補足] インストール方法について
l?? インストーラー、Ansible Playbooksを利用した2通りのインストール方法が
ある (2016年1月14日時点)
l?? 対話方式(インストーラー利用時)か非対話式(Ansible Playbooks)である点
が大きな違い
l?? インストール方法によって、インストール後のNode追加/アンインストール
方法がインストーラー方式かAnsible Playbooksによる更新方式になる
インストール方法
形式
ドキュメント
atomic-openshift-installer
(インストーラー)の利用
対話式
Quick Installation:
https://docs.openshift.com/enterprise/3.1/
install_config/install/quick_install.html
Ansible Playbooks
/etc/ansible/hostsでインストール設
定を編集
Advanced Installation:
https://docs.openshift.com/enterprise/3.1/
install_config/install/advanced_install.html
注: イストール前には、「Prerequisites(事前準備)」のドキュメントもご参照ください
https://docs.openshift.com/enterprise/3.1/install_config/install/prerequisites.html

1.2 デプロイのコンセプト

デプロイのコンセプト - Pod
l?? Pod は、OpenShiftでアプリケーションをデプロイするための最小単位
l?? 1つのPodは、1つ以上のコンテナを含む
l?? Pod内のコンテナは、ネットワークや永続化ボリューム、PID等を共有する
l?? 複数のコンテナをまとめて、1つの“論理的なOS環境”を作る単位がPodである
pod pod

デプロイのコンセプト - Replication Controller
API server
pod
…
Replication Controller
pod pod pod
l?? Repllication Controller は、指定した数のPodが起動している状態を保持する
l?? scale(Podの起動数)=1とすれば、1つのPodが起動している状態を保持し、
scale=5とすれば、5つのPodが起動している状態を保持する
pod

デプロイのコンセプト - Service
API server
podpod pod pod pod
l?? 同一PodにVirtual IPを持たせたアクセスポイント
l?? バックエンドのPodに対してロードバランサ(ラウンドロビン)の役割を担う
l?? Replication Controllerで増加させたPodもServiceによって、均一なアクセスが可能
service
Pod
JBoss
MySQL
MySQL
MySQL
MySQL
MySQL
例: JBoss(scale=1) x MySQL(scale=5)

OpenShift v3 の「リソース」について
l?? クライアントからNodeへの命令は、Masterに対しJSON形式の「リソース」として、生成/
編集/削除を要求
l?? 要求された「リソース」は、MasterのAPIサーバーを通して公開され、NodeはAPIを通じ
て自分のNodeのコンテナを管理する
l?? クライアントからは $ oc get <リソースName> で、リソース状況の確認が可能
Name (省略形)
機能/役割
Pod (po)
アプリケーションをデプロイするための最小単位。1つ以上のコンテナの
集合
Replication Controller (rc)
起動しているpod数を制御する
Service (svc)
同一podの集合に Virtual IP を保持させたアクセスポイント
Deployment Config (dc)
デプロイの設定
Build Config (bc)
ビルドの設定
ImageStream (is) イメージ管理。ImageStreamTag(istag)のセット。istagを使ってDocker
Registry内のイメージ、または別のistagへの参照を保持する
Route (route)
外部ネットワークから各サービスにアクセスするためのURL情報を管理
主な「リソース」の例

デプロイコンセプトデモンストレーション

2. PaaS プラットフォーム

[補足] オンプレミス/PaaS/IaaSについて
ハードウェア
OS/ネットワーク
実行環境/MW
アプリケーション
ハードウェア
実行環境/MW
ハードウェア
実行環境/MW
OS/ネットワーク OS/ネットワーク
オンプレミス IaaS PaaS
ーー
開
発

ー
提
供

2.1 ネットワーク

ネットワーク(Pod内アプリケーションからの経路)
Pod Pod??? PodPod ???
①
lb0
tun0
②③
eth0 (physical) vxlan vxlan eth0 (physical)
tun0
lb0
① 同一ホスト内のPodへの通信
l?? Docker ブリッジ(lb0)を経由してアクセス
② 別ホスト上のPodへの通信
l?? vxlanデバイスを経由したOverlayネットワークを通してアクセス
③ 外部ネットワークへの通信
l?? tun0デバイスからNATし、物理NICを経由してアクセス
10.1.1.210.1.1.1
10.1.2.1 10.1.2.2
10.1.0.0/16 (のように見える)
veth
eth0 eth0
veth
10.1.1.0/24 10.1.2.0/24

OpenShift SDN の主な役割
Pod
Project A
Pod??? PodPod
Project B
???
lb0
tun0
③
eth0 (physical) vxlan vxlan eth0 (physical)
tun0
lb0
10.1.1.0/24 10.1.2.0/24
① 各種ネットワークデバイス(vxlan0/tun0/lbr0)の生成
l?? OpenShift Node 起動時に生成
② podが利用するサブネットアドレスの登録
l?? 各Nodeが初回起動時に割り当てられたサブネットを受信し、Open vSwitch によりネットワ
ークフローを管理
③ (内部ネットワークを使った)別プロジェクトのpodへのアクセス制御 ※v3.1からPluginを利用して可能
①
②
10.1.1.1 10.1.2.1

ネットワーク(外部ネットワークからのアクセス)
HA Proxy
(Pod) Pod??? PodHA Proxy
(Pod)
???
192.168.133.1:80
192.168.133.2
*.apps.example.com 192.168.133.1
192.168.133.2
① DNSラウンドロビン
② 各Podへの振り分け
192.168.133.1
192.168.133.2:80
l?? 外部ネットワークからPodへのアクセスは、NodeにデプロイしたHA Proxyルーター
(Pod)を経由する

ネットワーク(routeリソースによる経路の追加)
HA Proxy
(Pod) Pod???
③ HA Proxyルータの更新 (reload)
Pod
② Master API 監視
① Route の生成 (oc expose コマンド)
oc expose hostname=hello.apps.example.com svc jboss
[補足] Apache の graceful と同様に haproxy reload で、
シームレスに設定の更新を行う、
backend be_http_demo_hello-app RETURN)
…
server 10.1.0.4:8080 10.1.0.4:8080 cookie 10.1.0.4:8080
(haproxy.config)
hello.apps.example.com be_http_demo_hello-app
(os_http_be.map)

2.2 アプリケーション実行環境/ミドルウェア

l?? 実行環境、MW はDockerイメージとして registry.redhat.com から提供
l?? 利用(デプロイ)方法は以下の2通り
(ビルド不要な)ミドルウェアイメージの場合:
l?? 例: データベースイメージ、Jenkinsイメージ
l?? 提供された Docker イメージをそのままデプロイ
アプリケーション実行環境イメージの場合:
l?? 例: 各種アプリケーション実行環境/MW
l?? 利用者のアプリケーションソースコードを、OpenShiftで提供されている
Builderイメージにバインド(再ビルド)してデプロイ
l?? Builderイメージを使ったビルドフレームワークはS2I (= Source to
Image)と呼ばれる
実行環境/ミドルウェア

???
Node
DeploymentConfig
(ビルド不要な)ミドルウェアイメージのデプロイ
① DeploymentConfigの作成
l?? Masterサーバーに、DeploymentConfig(コンテナイメージのデプロイ設定)を作成リクエ
スト
② Nodeへのコンテナデプロイ
l?? DeploymentConfigの設定に基づいて、NodeホストがDockerイメージをデプロイ
①
②
デプロイ用イメージ

DeploymentConfig
Pod デプロイ時のプロセスを設定するリソース
Replicas
初回にデプロイされるPodの数を指定。Replication
Controllerに引き継がれる。
Triggers:
デプロイを実行させるタイミング。「from: ImageChange」に関
しては、後ろのスライドで説明。
Strategy
デプロイプロセスを設定する。(例アップデート中のPodのダウ
ンタイムの調整等)。Lifecycle Hookによって、Podデプロイ前
後に別コンテナを実行することも可能。
{
"kind": "DeploymentConfig",
…中略…
"replicas": 5,
"selector": {
"name": "frontend"
},
"triggers": [
{
"type": "ConfigChange"
},
{
"type": "ImageChange",
"imageChangeParams": {
"automatic": true,
"containerNames": [
"helloworld"
],
"from": {
"kind": "ImageStreamTag",
"name": "origin-ruby-sample:latest"
}
}
}
],
"strategy": {
"type": "Rolling"
}
}
}

Node
アプリケーションイメージのデプロイ(1)
① BuildConfigの生成とビルドの開始
l?? Masterサーバーに、BuildConfig(コンテナイメージのビルド設定)の生成リクエスト
② ③ Builderイメージによるアプリケーションのビルド
l?? BuildConfigを元に、ソースコードをgit cloneし、Builderイメージ上でビルド
l?? 利用者のソースコードと実行環境をバインドしたイメージを生成
DeploymentConfigBuildConfig
①
②
③
④
⑤
Builderイメージ
OpenShift内部レジストリ

Node
アプリケーションイメージのデプロイ(2)
④ 生成されたイメージをDockerレジストリにPush
l?? OpenShift上にDockerレジストリにPushする。Docker registryはPodとして予めデプロ
イしておく
⑤ DeploymentConfigによるイメージのデプロイ
l?? ビルド不要なイメージのデプロイ時と同様。利用するイメージが④でPushされたイメージ
になる点が異なる
DeploymentConfigBuildConfig
①
②
③
④
⑤
Builderイメージ
OpenShift内部レジストリ

BuildConfig
ビルドプロセスを設定するためのリソース
Triggers:
ビルドを実行させるタイミング。「ImageChange」に関しては、後の
スライドで説明。
Source:
ビルドするソースコードやDockerfileのgitレポジトリを指定。
Strategy:
Source(ソースコードからビルド)、Docker(Dockerfileからビル
ド)、Customビルドの3種類を指定。
Output:
ビルド後のDockerイメージのアウトプット先。
「ImageStreamTag」を指定した場合、ImageStreamTagを生成し
た後、OpenShift内部のDocker RegistryにPushする。
「DockerImage」を指定した場合、外部のDockerRegistryを指
定。
{
"kind": "BuildConfig",
"apiVersion": "v1",
"metadata": {
"name": "ruby-sample-build"
},
"spec": {
"triggers": [
{
"type": "GitHub",
"github": {
"secret": "secret101"
}
},
{
"type": "Generic",
"generic": {
"secret": "secret101"
}
},
{
"type": "ImageChange"
}
],
"source": {
"type": "Git",
"git": {
"uri": "git://github.com/openshift/ruby-hello-world.git"
}
},
"strategy": {
"type": "Source",
"sourceStrategy": {
"from": {
"name": "ruby-20-centos7:latest"
}
}
},
"output": {
"to": {
"name": "origin-ruby-sample:latest"
}
}
}
}

[補足] oc new-app コマンドとテンプレート
oc new-app コマンド
l?? コマンド oc new-app を利用することで、json/yaml設定ファイルを自動生成させるコマンド
l?? 利用されるビルダーイメージは、アプリケーションレポジトリに含まれる言語特有のファイルで自動的に選択
l?? 例: pom.xmlがレポジトリに存在した場合、builderイメージはJavaが利用される(利用するビルダーイメージを明示的
に指定することも可能)
テンプレート
l?? BuildConfig、DeploymentConfig、Service、Route等をまとめてテンプレートとして予め生成しておく機能
l?? デプロイ済みの既存アプリケーションからexportして、テンプレートを生成することも可能
l?? Red Hatからのサンプルテンプレートは /usr/share/openshift/examples/ 以下に提供
Command
説明
oc new-app .
カレントディレクトリ(要:gitレポジトリ)のアプリケーションコード(または、Dockerfile)からビルドを実行
oc new-app
https://github.com/nak3/helloworld-v3.git
https://github.com/nak3/helloworld-v3.git をビルド (PHPのビルダーイメージが自動的に選択)
oc new-app
openshift/ruby-20-centos7:latest~https://
github.com/openshift/ruby-hello-world.git

https://github.com/openshift/ruby-hello-world.git をビルド (openshift/ruby-20-centos7:latest~が
ビルダーイメージとして選択)
oc new-app -f application-template-.json

テンプレートファイルからビルドを実行

ImageStream
BuildConfig
Build
Look for
builder image
New
Builder
container
S2I Build
Process
DeploymentConfig
Service
Deployer container
IP tables
Replication Controller
Pod
oc new-app https://
Resources
Buildprocess
Container
ImageStream
Tag
[補足] Background of oc new-app <git repo>

S2I ビルドデモンストレーション

Red Hat が提供しているビルダー/MWイメージ
l?? 提供されているイメージは、以下のサイトから確認可能
https://access.redhat.com/search/#/container-images
Name
Version
Ruby
2.0,2.2
Node.js
0.10
PHP
5.5,5.6
Python
3.3,3.4
Perl
5.16,5.20
JBoss EAP
6.4
JBoss JWS
3.0
JBoss DataGrid
6.5
JBoss BRMS
6.2
JBoss A-MQ
6.2
JBoss Fuse
6.2
Name
Version
MySQL
5.5,5.6
PostgreSQL 9.2,9.4
MongoDB 2.4,2.6
Jenkins 1.609
注: 2016年1月14日時点の情報です

その他 PaaS的要素
l?? OpenShiftをPaaSとして採用した際にデフォルトで提供される機能(一部)
Kind
Description
マルチテナント対応
?? ネームスペースやVXLAN IDを使ったプロジェクト単位での分離
?? リソース、ネットワークの他に、SELinux MCSを利用したセキュリ
ティ対策
認証
?? Web UI、CLI利用時の各ユーザー認証フレームワークを提供
?? Basic認証、LDAPの他にOauthによる認証も可能
リソースコントロール
?? CPU、メモリによる各プロジェクトへのリソースの上限設定が可能
テンプレート
?? デプロイアプリケーション環境一式をテンプレートとして、デプロイ
可能。
?? クイックスタート等のテンプレートを用意することも可能

3. DevOps プラットフォーム

3.1 デプロイメントパイプライン

Jenkins デモンストーレション

ImageStreamとImageStreamTag
ImageStreamTag
ImageStreamTag
ImageStreamTag
デベロッパー
QA/テストエンジニア
リリースエンジニア
sha@wwwwwwwwww
sha@xxxxxxxxxxxxxxx
sha@yyyyyyyyyyyyyyy
sha@zzzzzzzzzzzzzzz
demo:dev
Push

latest
demo:dev
demo:qa
demo:release
新
l?? ImageStreamは、Gitのブランチ1つと同じ概念。
l?? 各イメージストリームは、1つ以上のtagを持つ。(デフォルトのタグは「latest」)
l?? 各タグは、レジストリ内のイメージ、または、同じ
　ImageStream内の別のタグをポイントする。
ImageStreamTag
ImageStream
テスト失敗
latestlatestlatest
古

始めてみましょう
パッケージインストール or ホスティングサービス
OpenShift Enterprise 30日評価版サブスクリプション
- https://access.redhat.com/products/openshift-enterprise-red-hat/evaluation
OpenShift Dedicated
- https://www.openshift.com/dedicated/
※ OpenShift DedicatedはRed Hatがセットアップしてメンテナンスも提供する製品となり、お客様は利用するだけという
モデルになっています。AWS上全リージョンで提供されるので東京リージョンでも利用可能です。
ドキュメント
- https://docs.openshift.com/
ソースコード(upstream)
- https://github.com/openshift/origin (Origin - OpenShift Enterpriseのupstream版)?
- https://github.com/openshift/openshift-sdn (OpenShift SDN)?
- https://github.com/openshift/source-to-image (Source to Image (s2i))?
- https://github.com/openshift/openshift-ansible (Ansible インストールスクリプト)

参考資料(1)
オーケストレーション
URL
Kubernetes Infrastructure
https://docs.openshift.com/enterprise/3.1/architecture/
infrastructure_components/kubernetes_infrastructure.html
Pod&ServicesPods (K8S
doc)
http://kubernetes.io/v1.1/docs/user-guide/pods.html
Replicatoin Controller
(K8S doc)

http://kubernetes.io/v1.1/docs/user-guide/replication-controller.html
Services (K8S doc)
http://kubernetes.io/v1.1/docs/user-guide/services.html
Pod&Services
core_concepts/pods_and_services.html

参考資料(2)
PaaS
URL
OpenShift SDN
additional_concepts/sdn.html
HA Proxy router
core_concepts/routes.html
https://docs.openshift.com/enterprise/3.1/dev_guide/routes.html
Builds (BuildConfig)
https://docs.openshift.com/enterprise/3.1/dev_guide/builds.html
Deployments
(DeploymentConfig)
https://docs.openshift.com/enterprise/3.1/dev_guide/
deployments.html
oc new-app
https://docs.openshift.com/enterprise/3.1/dev_guide/new_app.html
DevOps
URL
ImageStream
core_concepts/builds_and_image_streams.html

END

狠狠撸

OpenShift v3 Technical Overview

More Related Content

OpenShift v3 Technical Overview