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

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

レッドハット株式会社

中井悦司 / Etsuji NakaiSenior Solution Architect

and Cloud Evangelist

v1.1 2016/01/29

2

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

Contents

Dockerが生まれた背景 OpenShiftの主要機能 OpenShiftのイメージ管理機能 アプリケーションのデプロイ方法 参考資料

Dockerが生まれた背景

4

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

クラウドサービスとしてのPaaS環境の課題

PaaSのメリット⇒ 実行環境の構築・管理に手間をかけず、アプリケーション開発に集中

アプリケーション実行環境（フレームワーク／ライブラリー）

サーバー／OS

開発したコードをクラウドにデプロイ

アプリケーションプログラム

5

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

アプリケーション実行環境（フレームワーク／ライブラリー）

サーバー／OS

アプリケーションプログラム

クラウドサービスとしてのPaaS環境の課題

アプリケーションのコードと実行環境は、多くの場合、密結合しており、「ありもの」の実行環境だけでは、不便が生じることも多い

「悪魔は細部に宿る」

・使いたいフレームワークが無い・必要なライブラリーが不足・ライブラリーバージョンの不整合・etc...

6

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

dotCloudが実行環境のメンテナンスに用意した仕組み dotCloud社は、クラウド内部の仕組みとして、アプリケーションの実行

環境を自動構築して「Dockerイメージ」に固める技術を開発– さらに、クラウド以外の環境でも利用できるようにオープンソースとして公開

Dockerサービス

サーバー／OS

アプリケーションプログラム

さまざまな実行環境をDockerイメージとして

作成・メンテナンス

Dockerイメージ

7

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

Dockerが提供する基本機能

Dockerfile

① Dockerイメージを自動作成

OSイメージ

アプリケーションライブラリー

アプリケーションフレームワーク

イメージの作成手順を記載

Dockerイメージ

OS上にインストール可能なものはすべてイメージ化可能

② Dockerイメージを保存・公開

③ Dockerサーバーに　イメージを配布・実行

OpenShiftの主要機能

9

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

OpenShiftが提供する主な追加機能

Dockerイメージのバージョン管理– イメージストリームとイメージビルドシステム– 「開発環境」そのものを開発可能に

同一の開発環境のクラウド上への配布– テンプレート機能– それぞれの開発者に「自分専用」の開発／検証環境を提供

マルチテナントでの利用– プロジェクト単位でのネームスペースの分割– 開発機能（ブランチ）単位で独立した開発／検証環境を提供

サーバーの境界を意識しないコンテナのデプロイ– Kubernetesによるコンテナのオーケストレーション– マイクロサービス型アプリケーションのDevOps環境を実現

10

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

従来のPaaSの利用形態

アプリ開発者

開発環境テンプレート

新しいコードをPushすると開発・テスト環境に展開してビルド

開発したコードの稼働確認

11

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

従来のPaaSの利用形態

アプリ開発者

開発環境テンプレートテンプレートそのものの

メンテナンスはどうする？開発中に開発環境の

アップデートは可能？

開発が終わったアプリはどうやって本番展開する？

12

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

OpenShiftにおける役割分担

アプリ開発者

開発環境構成テンプレート

テンプレート管理者公式RHELイメージ

Dockerfile

テスト担当者

開発環境イメージ

テスト環境構成テンプレート

開発中アプリイメージ

ソースコード

動作確認

コード開発

テスト用デプロイ環境

動作確認

本番環境構成テンプレート

開発用デプロイ環境本番用デプロイ環境

開発済みアプリイメージ

テスト済みアプリイメージ

リリース担当者

13

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

OpenShiftにおける「開発環境」のメンテナンス機能

RHELイメージ

開発環境イメージ

テスト用アプリイメージ

セキュリティ問題等の修正が入った新しいRHELイメージをアップロード

Dockerfileを用いて開発環境イメージを更新

アプリケーションを自動ビルドして機能テスト

開発環境イメージ

修正・テスト済みの開発環境イメージを参照

開発中アプリイメージ

新しいコードをPushするとアプリイメージを自動更新

テンプレート管理者

アプリ開発者

14

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

マルチテナントによる機能別の並行開発

アプリ開発者

開発環境イメージ

アプリケーションイメージ

開発機能ごとにコードのブランチを分けて、各ブランチ専用の開発環境を個別に用意します。

アプリ開発者

開発環境イメージ

アプリケーションイメージ

テスト担当者

開発環境イメージ

アプリケーションイメージ

マスターブランチ

開発済み機能をマージしたマスターブランチのコードを検証

機能Aの開発

機能Bの開発

開発した機能をマージ

開発した機能をマージ

15

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

OpenShiftによるDevOpsの実現

開発／テストとサービス用でプロジェクトを分割することで、OpenShift上でのDevOps環境が実現できます。

内部レジストリー

ImageStream

BuildConfig

DeploymentConfig

Route

Service Service

エイリアス

テスト済みイメージをエイリアスで参照

DeploymentConfig

開発／テストプロジェクト

サービス用プロジェクト

イメージの実体を保存アプリケーションの元ネタ

（Dockerfile/ソースコード）を保存

Route

RHEL7

MyApp MyApp

16

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

テンプレートとGUIの組み合わせによるPaaSの提供

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

アプリケーション開発者はコードの開発のみに集中

OpenShiftの内部構造

18

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

OpenShiftの基本サーバー構成

etcd

・・・

バックエンドデータベース（KVS）

マスターノード

・・・

クラスタ構成で負荷分散可能

Docker Docker Docker

必要に応じて追加可能

１台のマスターから複数のノードを管理するシンプルなアーキテクチャーです。– 各ノードのエージェントとマスターが直接に通信します。– バックエンドデータベースは、etcd（分散KVS）を使用します。– OpenShiftの利用者（CLI）は、マスターが公開するAPIにアクセスします。

利用者（CLI）

19

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

OpenShiftのネットワーク構成

etcd マスター

オーバーレイネットワークとして構成

・・・

物理的には、全サーバーを共通のサービスネットワークに接続するだけで利用可能です。– コンテナ間通信用の内部ネットワークは、オーバーレイネットワークとして構成されます。– 外部からのアクセスは、ルータ用コンテナを経由します。

• ルータがあるノードの80番ポート宛のパケットは、iptablesでルーターに転送されます。ルータは、URLベースで接続先のコンテナを決定します。

サービスネットワーク

ノード

内部ネットワーク

コンテナ コンテナ

ブリッジ

コンテナ コンテナ

ルータ

ブリッジ

ノード

20

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

「サービス」によるコンテナ間接続

コンテナで起動したアプリケーションに対して、「サービス」を定義すると、内部ネットワーク上の「サービスアドレス」が割り当てられます。

– 他のコンテナから「サービスアドレス」にアクセスすると、対応するコンテナにパケットが転送されます。（複数のコンテナがある場合は、ラウンドロビンで負荷分散が行われます。）

– 事前に「サービス」を定義した状態で、新規のコンテナを起動すると、サービスのIPアドレス／ポートを示す環境変数が自動的にセットされます。

# oc get serviceNAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR AGEetherpad-lite 172.30.14.201 <none> 9001/TCP deploymentconfig=etherpad-lite 7dmysql 172.30.86.51 <none> 3306/TCP name=mysql 7d

apiVersion: v1 kind: Service metadata: name: mysqlspec: ports: - name: mysql port: 3306 protocol: TCP targetPort: 3306 selector: name: mysql-pod sessionAffinity: None

mysql-service.yml

MYSQL_SERVICE_HOST=172.30.86.51MYSQL_SERVICE_PORT_MYSQL=3306

サービス定義ファイルの例

割り当てられたサービスアドレス

新規のコンテナにセットされる環境変数の例

21

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

「ルーティング」による外部接続

「サービス」に加えて「ルーティング」を定義すると、外部からのURLアクセスが可能になります。

– HAProxyが稼働するルータコンテナがURLベースのルーティング処理を行ないます。– 下記の例では、「*.oso.example.com」が「ルータコンテナが稼働するノードのパブリックIP」に解決されるように外部DNSが事前設定されています。

– 複数のルータコンテナを起動して、DNSラウンドロビンで負荷分散することも可能です。

# oc get routeNAME HOST/PORT PATH SERVICE etherpad-lite-route eplite.project01.oso.example.com etherpad-lite

apiVersion: v1kind: Routemetadata: name: etherpad-lite-routespec: host: eplite.project01.oso.example.com to: kind: Service name: etherpad-lite

etherpad-lite_route.yml ルーティング定義ファイルの例

アプリケーションのURL

22

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

「サービス」と「ルーティング」のパケット経路 「サービス」として定義されたIPアドレス宛のパケットは、iptables設定によって、ノード

上の「openshift-nodeエージェント」に転送されます。– openshift-nodeエージェントは、実際にサービスを提供するコンテナにラウンドロビンでパケットを転送します。

「ルーティング」を定義すると、ルータコンテナ上のHAProxyに、対応する設定がなされることで、URLベースでのルーティングが実施されます。

openshift-nodeエージェント

オーバーレイネットワーク

ブリッジ

コンテナ コンテナルータ

コンテナ

iptables

iptables

DNSラウンドロビン

ラウンドロビン リースト

コネクション

コンテナ間のアクセス

外部からのアクセス

openshift-nodeエージェント

ブリッジ

コンテナ コンテナルータ

コンテナ

iptables

iptables

ラウンドロビン リースト

コネクション

OpenShiftのイメージ管理機能

24

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

OpenShiftにおけるイメージ管理

Docker Hub、もしくは、Dockerホストローカルのイメージは、「ユーザー名/リポジトリ名 : タグ」という名称で識別されます。

– タグによるバージョン管理が可能ですが、自由に付け替えができるため、利用者自身が意識的にタグ名を操作する必要があります。

OpenShiftで取り扱うイメージは、専用の内部レジストリーに保存して、独自のバージョン管理を行ないます。

– 内部レジストリーの中では、「プロジェクト名/リポジトリ名@<sha256ハッシュ>」という名称でイメージを識別します。ハッシュ値が、GitのコミットIDに相当するユニークな識別子になります。

– バージョン情報（イメージが更新された時系列）については、別途、「イメージストリーム」を定義して、そちらで管理します。

# oc get isNAME DOCKER REPO TAGS UPDATEDcentos7 172.30.84.64:5000/project01/centos7 latest 7 days agoetherpad-lite 172.30.84.64:5000/project01/etherpad-lite latest 7 days agonodejs-base 172.30.84.64:5000/project01/nodejs-base latest 7 days ago

# oc describe is etherpad-liteName: etherpad-liteCreated: 7 days agoLabels: <none>Annotations: openshift.io/image.dockerRepositoryCheck=2016-01-03T09:53:25ZDocker 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 v3主要機能と内部構造のご紹介

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 isNAME DOCKER REPO TAGS UPDATEDcentos7 172.30.84.64:5000/project01/centos7 latest 7 seconds ago

# oc describe is centos7ame: centos7Created: 24 seconds agoLabels: <none>Annotations: openshift.io/image.dockerRepositoryCheck=2015-12-28T11:32:19ZDocker 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 v3主要機能と内部構造のご紹介

OpenShiftのイメージビルドシステム

イメージビルドシステムは、「ビルド設定（BuildConfig）」を定義して利用します。次は、GitHubで公開したDockerfile（および、ビルドに必要な関連ファイル）からイメージをビルドする設定の例です。

apiVersion: v1kind: BuildConfigmetadata: name: nginx-samplespec: output: to: kind: ImageStreamTag name: nginx-sample:latest source: git: uri: https://github.com/enakai00/openshift_nginx_sample type: Git strategy: dockerStrategy: from: kind: ImageStreamTag name: centos7:latest type: Docker triggers: - imageChange: {} type: ImageChange

nginx-sample_bc.yml– Docerfileの「FROM:」行は、イメー

ジストリーム「centos7」のイメージで置き換えられます。

– 作成されたイメージは、内部レジストリーに保存された後、イメージストリーム「nginx-sample」に自動登録されます。

– 「start-build」コマンドを明示的に実行する他に、イメージストリーム「centos7」のイメージが更新されたタイミング、GitHubに新たなCommitが行われたタイミングでも自動的にビルドが実行可能です。

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

28

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

イメージストリームからのコンテナのデプロイ

「デプロイ設定（DeploymentConfig）」を用いて、イメージストリームに登録したイメージからコンテナをデプロイします。

apiVersion: v1kind: DeploymentConfigmetadata: name: nginx-samplespec: 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: kind: ImageStreamTag name: nginx-sample:latest - type: ConfigChange

nginx-sample_dc.yml– レプリカ数で指定した数のコンテナが起動します。先に説明した「サービス」の定義により、複数コンテナに対するロードバランスが行われます。

– イメージストリームに新しいイメージが登録されると、自動で再デプロイを実施することができます。再デプロイ時は、新バージョンのコンテナを追加起動して、新しいセッションから新バージョンに振り分けるといった動作が可能です。

29

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

複数コンテナが連携するシステムの構築例

下記の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.