OpenShift の基礎コンテナのメリット

OpenShift の基礎コンテナのメリット 1 2021/11/02 Cloud Solution Architect Yuhki Hanada

コンテナとは? 2

Hardware Hardware Hardware Hypervisor / 通常 Operating System Container Runtime
(Application) Operating System Operating System App App App App App App Library Operating System Library Library Library container container Library Knernel Knernel Knernel Knernel 通常Operating System / コンテナ専用 OS 仮想マシンコンテナ物理サーバー • コンシュマー PC • エンタープライズサーバー (※1) • エンタープライズサーバー • エンタープライズ・サーバーアプリケーション実行環境の分離 VMWare (1998～) AIX LPAR (2001～) Xen (2003～) KVM (2007～) Hyper-V (2008～) Solaris Container (2005～) AIX WPAR (2007～) LXC (2008～) Docker (2013～) Openなテクノロジーコンテナに比べて・単純・完全な分離レベル仮想マシンに比べて・小さなオーバーヘッド・高集約コンテナは、複数アプリを実行する「環境分離」のための「仮想化技術」の一つです。仮想化技術のどれが優れている。という訳ではなく適材適所です。 ※）年の所は、どこを開始点と見るかはいろいろありそうなので大体の目安です(wiki調べ)。例えば Vmware がESXをリリースしたのは、2001年ですが、仮想化業界全体に影響を与えた観点から会社の設立年1998年を記載しています。

仮想化とコンテナ Hardware Hardware Hardware Hypervisor Container Runtime (Application) docker /
podman Operating System Operating System App App App App App App Library Operating System Library Library Library container container Library Knernel Knernel Knernel Knernel 通常Operating System or コンテナ専用 OS 仮想マシンコンテナ物理サーバー • コンシュマー PC • エンタープライズサーバー (※1) • エンタープライズサーバー • エンタープライズ・サーバーコンテナの仕組みは、物理サーバー上のアプリに近く、分離度が低い分、集約度が高い仮想マシン上のアプリは OSレベルで完全に分割されている技術的なギャップコンテナ環境を作るための Application ※1) 仮想マシンが出始めた頃は、IOのパフォーマンスが良くないケースがあったので、DBなど IO Performance が必要なものは、仮想マシンを使用しないケースがあった。この傾向は薄れてきているが、現在でもサーバー丸毎の Performance を使用するためDBに専用サーバーを用意する事がある。科学技術計算などで使用されるHPC (High Performance Computing) と呼ばれる世界でもパフォーマンスの観点から物理サーバーを使う事が多い。

仮想化とコンテナ Hardware Hardware Hardware Hypervisor / 通常 Operating System Container
Runtime (Application) docker / podman 等 App App App App Library Operating System Library container container Library Knernel Knernel 通常Operating System / コンテナ専用 OS • コンシュマー PC • エンタープライズサーバー (※1) • エンタープライズサーバー • エンタープライズ・サーバー Linux / Red Hat CoreOS Vmware ESXi Hyper-V(Windows) / KVM, Xen (Linux) コンテナ物理サーバーコンテナの仕組みは、物理サーバー上のアプリに近く、分離度が低い分、集約度が高いコンテナ環境を作るための Application Operating System Operating System App App Library Library Knernel Knernel 仮想マシン仮想マシン上のアプリは OSレベルで完全に分割されている ※1) 仮想マシンが出始めた頃は、IOのパフォーマンスが良くないケースがあったので、DBなど IO Performance が必要なものは、仮想マシンを使用しないケースがあった。この傾向は薄れてきているが、現在でもサーバー丸毎の Performance を使用するためDBに専用サーバーを用意する事がある。科学技術計算などで使用されるHPC (High Performance Computing) と呼ばれる世界でもパフォーマンスの観点から物理サーバーを使う事が多い。技術的なギャップ

アプリケーションが依存するものアプリケーション本体 (.exe / .app / binary) OSのディストリビューション等が提供するライブラリ OSやミドルウェアが提供するもの
アプリケーションのパッケージに含まれるものの例設定ファイル (.a,.so, .lib, .dll 等) (.ini) OSのデータベースアプリケーション実行時に参照アプリケーション実行時に参照アプリケーション実行時に参照いろいろなバージョンコンテナは、アプリケーションだけでなく、OSの一部やミドルウェアを含むミドルウェア等のライブラリ (python, Java 等) アプリケーション実行時に参照いろいろなバージョン参照 OSカーネル Linux もディストリビューションによって独自機能を提供作りの良いソフトウェアは、バージョンが変わっても後方互換性を維持するが全てがそうとは限らないシステムコールシステムコール用ライブラリ・Linux のカーネルはバージョンの違いはあるが、基本的には1つしかない(ディストリビューション毎に、多少の違いがある場合はある）・Linux のカーネルは、基本、後方互換性がある。・Windows は Windowsのカーネルがある。Linux との互換性は無いここを絵的にどう表現するかは、何を伝えたいかによっていろいろな表現があるのでざっくりとしたイメージです。 Linux なら OSカーネルは基本、共通 Windows Registry アプリケーション独自定義の設定ファイル OSが参照する設定ファイル Linux のシステムディレクトリに配置されるファイル /etc/init.d/xxxx 等

OSカーネルアプリケーションが依存するもの OSディストリビューション等が提供するライブラリ OSやミドルウェアが提供するものアプリケーションのパッケージに含まれるもの (.a,.so, .lib, .dll 等)
アプリケーション実行時に参照作りの良いソフトウェアは、バージョンが変わっても後方互換性を維持するが全てはそうとは限らないいろいろなバージョンコンテナは、アプリケーションだけでなく、OSやミドルウェアを含むミドルウェア等のライブラリ (python, Java 等) アプリケーション実行時に参照いろいろなバージョンイメージとして固めてしまう＝環境による依存性が無くなる (可搬性の向上) 参照 Linux もディストリビューションによって独自機能を提供・Linux のカーネルはバージョンの違いはあるが、基本的には1つしかない(ディストリビューション毎に、多少の違いがある場合はある）・Linux のカーネルは、基本、後方互換性がある。・Windows は Windowsのカーネルがある。Linux との互換性は無い Linux なら OSカーネルは基本、共通システムコールシステムコール用ライブラリアプリケーション本体 (.exe / .app / binary) 設定ファイル (.ini) OSのデータベースアプリケーション実行時に参照アプリケーション実行時に参照アプリケーション独自定義の設定ファイル OSが参照する設定ファイル Linux のシステムディレクトリに配置されるファイル /etc/init.d/xxxx 等 Windows Registry

コンテナとCoreOS (コンテナ専用OS) RHEL7固有の部分 Linux Kernel RHEL7 SLES 固有の部分
Linux Kernel SLES RHEL8 固有の部分 Linux Kernel RHEL8 Linux Kernel Core OS 固有 CoreOS Linux Kernel Core OS 固有の部分 RHEL8 UBI Python USER APP Aコンテナアプリ RHEL8 UBI Python USER APP Bコンテナアプリ 4 core(仮想コア) OpenShift コンテナ Linux Kernel 仮想サーバー仮想サーバー仮想化ハイパーバイザー (VMware / Hyper-V / PowerVM / Xen ) コンテナの実行に必要なコンポーネント OpenShift コンテナ RHEL8 UBI Python USER APP Bコンテナアプリコンテナの実行に必要な部分 RHEL 8 固有の部分 (通常使われない) 物理サーバー OpenShift の実体もコンテナ RHEL 8 CoreOS 物理仮想 vCPU vCPU 4 vCPU (HT = on) 2 Core vCPU vCPU vCPU vCPU 4 vCPU (HT = on) 2 Core vCPU vCPU core core core core 4 core(仮想コア) core core core core

コンテナの「ベース・イメージ」 • いろんな Linux のディストリビューションのコンテナの「ベース・イメージ」が存在する • Red Hat の場合、UBI (Universal
Base Image) というベース・イメージを提供 • 含まれているコンポーネントの違いで 4種類のベース・イメージを用意 • コンテナは小さければ小さいほど軽量で便利。自分のアプリが使用するコンポーネントだけ入っていれば良い。 • 一方で、はじめからあまりにも何も入ってない小さいコンテナだとと、「ビルド」時に自分でいろいろ追加しないといけなくなる。 UBI Micro UBI Minimul UBI Standard (Platform) UBI Multi-service ※1) サイズは、ある時点での圧縮時の値。バージョンによって異なります。参考：自由に再配布可能なRed Hat Enterprise Linux 8ベースのコンテナ用OSイメージ「Red Hat Universal Base Image」が公開 https://www.publickey1.jp/blog/19/red_hat_enterprise_linux_8osred_hat_universal_base_image.html • UBI イメージは再配布可能で、RHEL / CoreOS の上で使用した場合、Red Hat のサポートが受けられるコンテナのベース・イメージ。 • UBI イメージに関する詳細な解説はこちら：Red Hat Universal Base Images (UBI) | Red Hat Developer • コンテナイメージは、UBIの場合は「Red Hat Ecosystem Catalog」というサイトで公開している。Explore Certified Container Images - Red Hat Ecosystem Catalog ubi (72.1MB(※1)) ubi-minimal (37.6MB(※1)) ubi-init (76.4MB(※1)) Red Hat が提供するコンテナのベース・イメージ例 ubi-micro (12.9MB(※1))

可搬性の向上 Linux がベースであるので、同じコンテナが動かせる範囲が広い異なる CPUアーキテクチャーでも Linux である限り移植はしやすい Linux Server (Power)
Windows (x86) Linux Server (x86) Mac (x86) Linux Server (s390) Linux仮想マシン (x86) Linux仮想マシン (x86) コンテナコンテナコンテナコンテナコンテナコンテナベース・イメージの変更が必要アプリの改変が必要なケースもベース・イメージの変更が必要アプリの改変が必要なケースも・Linux は簡単に手に入れられる= 広いユーザー層が存在する。・CPUアーキテクチャー毎に Linux は異なっている。RHEL だと x86用、POWER用、Host用がある。補則：従来はコンテナ = Linux だったが、Windows のコンテナも Microsoft が推進しており、立ち上がりつつある。参考：CNDT2020シリーズ：Windowsコンテナの基本 Host OS Host OS x86 の Linux

アークテクチャー毎のコンテナ・イメージ Explore Certified Container Images - Red Hat Ecosystem Catalog
• 同じ Linux ディストリビューションでも、CPU アーキテクチャー毎にイメージが違う。 • 特殊な使い方をしてなければ、ベースイメージを差し替えるだけで、別のアーキテクチャー上に移植できる（はず）。テストは必要。 IBM System p (POWER) IBM System z (Host) Intel (x86) ARM コンテナのカタログには、Architecture 毎にイメージが用意されている

コンテナのイメージコンテナのダウンロードコンテナの実行時 • 実行時には、Read /Write ができる layer が作成される •
保存しなければ、コンテナ終了時に破棄され、元の状態に戻る（ Immutable ) • ベースのイメージに対する変更内容をマージした、新しいイメージを作成する作業をコンテナの「ビルド」と言う Read Only コンテナ「イメージ」 $ docker pull ubuntu Using default tag: latest latest: Pulling from library/ubuntu e6ca3592b144: Pull complete 534a5505201d: Pull complete 990916bd23bb: Pull complete Digest: sha256:cbcf86d7781dbb3a6aa2bcea25403f6b0b443e20b9959165cf52d2cc9608e4b9 Status: Downloaded newer image for ubuntu:latest docker.io/library/ubuntu:latest $ 一つのイメージでもレイヤーの積みかさねになっている ※イメージなので書き込みはできない Base Image utility command nginx 同じ OS を使用しつつ、おのおののコンテナが OSのファイルを書き替えても影響しないようにするための技術自分が書き替える部分だけ差分として持つ（コンテナ終了時に消える) Read Only Read / Write いつでも同じ部分 Base Image utility comand nginx ・OSのディスク部分を、「差分」として管理するようになった。・アプリケーションの本体だけでなく、アプリケーションに依存するOSのファイルが一緒に、アプリケーションとしてパッケージされるようなった。自分で必要なコンポーネントを追加してイメージとして固める一番目の層を「ベース・イメージ」と言う[1] [1]イメージ、コンテナ、ストレージ・ドライバの理解 — Docker-docs-ja 1.11.0 ドキュメント

コンテナと永続的なデータ Read Only Read / Write 自分が書き替える部分だけ差分として持つが、コンテナ終了時に消える。アプリケーション本体とアプリケーションを実行するため
に、必要なOSの最低限のファイル。 990916bd23bb 534a5505201d e6ca3592b144 コンテナ終了後も、消えて欲しくないデータは別途、コンテナの外に書き出す Kubernetes では、消えては困るデータを、Kuberentes 側で残す仕組みを提供している。・ConfigMap ・Secret ・PV (Persistent Volume) Kuberentes の etcd という Database に保管される。 Kubernetes に、ストレージを接続しストレージのボリュームをコンテナに接続する事で実現される。小さめなデータ (設定ファイル、パスワード) 大きめなデータ (データベースのデータ) 明確な境界は無い・データとデータを使うアプリケーションを仕組みとして明確に区別した事でイメージ部分の可搬性が向上した。・一方でこれまでのアプリケーションとは別のルールに従う必要がでてきたもしユーザー毎に変更する必要の無い値ならコンテナに埋め込むという方法もある。 Kubernetes の用語 (プロセスは、稼働中にログを吐いたり、OSのファイルシステムに何らかの変更をもたらす) OSが提供するライブラリの違い OSに書き込んだ設定変更素のOSとの差分等を吸収コンテナでは、変化するデータと、変化しないデータの明確な分離が行われる。 Linux OS 上でに残したいデータを書き出す

コンテナ開発者が普段取り扱うデータサイズの変化 ※Linux Kernel の互換性はバージョン･アップで維持される。 ※異なる Linux ディストリビューション間でも Kernel は共通
※Windows と Linux のコンテナは同じ Kernel を持てないので分離する必要がある (コンテナ = Linux が現状）開発者が取り扱わなければいけない部分 Linux Kernel RHEL SLES Ubuntu アプリA アプリ B アプリ C Hardware Layer • 開発者が扱うデータサイズの減少 • ネットワークを介した可搬性の向上 • 作業の自由度の向上（作業の自動化・レポジトリ化の実現) • 重たかった作業が軽くアプリケーション開発スピードの向上疎結合疎結合アプリデータ疎結合のラインアプリがOSに対して行う変更部分アプリのインストールは、インストールされたOS にも変化をもたらすので、OSまるごと「アプリ」として取り扱う必要がある。仮想マシン Linux Kernel RHEL 固有部分 Hardware Layer アプリの行うOSへの変更アプリA 疎結合のラインアプリデータ RHELのライブラリをコール消したくないアプリのデータを保管する仕組みは Kubernetes が提供する。

Liux (or Linux Kernel) Linux アプリA アプリデータ開発環境 (サーバー)
200GByteの仮想マシン 0.２ GByteのコンテナ小さなサイズが生み出した変化 (1) アプリ部分だけ取り出して、インストールアップロード (0.2 GByte) アプリだけをFTPなどで転送し、毎回インストール。 Linux (Linux Kernel) Hardware アプリデータ改良してアップロード Hardware ハイパーバイザー改良してアップロード「可搬性」と「開発サイクルの短縮化」につながる。開発者のPC Docker 以前のエンタープライズのコンテナ技術が流行らなかったのは、開発者の手元に Solaris だったり AIXが必要で、しきいが高かったから。とする意見があります。複数の仮想マシン立ちあげると Note PC が重くて大変…。ディスク容量も足りない… 幾つアプリ立ちあげても、重たい仮想マシンは１個だけ立ちあげればOK コンテナは瞬時に起動 Linux アプリA Linux コンテナ前回 OSに行った変更のゴミ。OSへの変更はアプリに内包されない (毎回 OSをクリーン・インストールすれば綺麗になるが…) Linux コンテナアプリを毎回インストールするのは、一回一回の作業がそれなりに手間… 環境の設定に依存して動かないのもあるあるハイパーバイザーハイパーバイザー OSへの変更は、コンテナに内包されている動かない可能性は低い違うアプリを一つのOSに入れると互いに影響しあったり管理が大変なので、1つのOSに一つのアプリという形で管理。 Linux OSの上で複数のコンテナを動かしても、コンテナは完全に分離されているので管理しやすい Kubernetes ではコンテナ・レジストリーを介して行われるアプリインストール前のアプリ削除 OS再設定試行錯誤が発生

小さなサイズが生み出した変化 (2) コンテナイメージのダウンロード・ダウンロードしてそのまま実行・改変して実行( =ビルド) ・ユーザーが作ったコンテナ・ベンダーが開発したコンテナインターネットからダウンロードして使用するのが標準に
ライセンス的な障壁でOSS製品が中心に自分で作ったものをみんなに公開ベンダーサポートをあまり気にしない、Web サイトの分野で広まりはじめる。 PS C:¥Users¥yuhki> docker run nginx:1.7 Unable to find image 'nginx:1.7' locally 1.7: Pulling from library/nginx Image docker.io/library/nginx:1.7 uses outdated schema1 manifest format. Please upgrade to a schema2 image for better future compatibility. More information at https://docs.docker.com/regist ry/spec/deprecated-schema-v1/ 193224d99eda: Pull complete a3ed95caeb02: Pull complete eb250aa1fe8b: Pull complete 26547bfb8cca: Pull complete 9118cfaa8eaa: Pull complete a6efe51e1a3b: Pull complete a2318bfd27ef: Pull complete Digest: sha256:02537b932a849103ab21c75fac25c0de622ca12fe2c5ba8af2c7cb23339ee6d4 Status: Downloaded newer image for nginx:1.7 PS C:¥Users¥yuhki> 簡単であると同時に、コンテナである事の「作法」がいろいろ生まれる。

簡単なデモ docker run -d --name my-nginx -p 8080:80 nginx:latest 1)
コンテナを Internet からダウンロードしてきて実行する 2) コンテナの稼働を確認する 3) コンテナを停止するインターネット上のベースイメージ名自分で作るコンテナの名前アクセスポートの設定デタッチする curl localhost:8080 docker stop my-nginx 設定したポート 8080 に curl アクセスする (ブラウザでもOK) docker ps コンテナで Webサーバーを立てる事の早さを体感する。

小さなサイズが生み出した変化 (3) アプリケーションのネット上での公開ネット上でアプリ（コンテナ）のイメージを配布する文化が誕生仮想マシン時代も同様な試みは存在し、インフラベンダーが、アプリベンダーのパートナーに、自社サイトに、アプリが簡単に実行できる仮想マシンの登録を促す様な流れがあった。が流行らなかった。コンテナは Linux なので誰もが、自分が作ったイメージをアップ
ロード。ユーザーの裾野が広い。 docker が docker Hubを普及させる Red Hat Ecosystem Catalogサイト Docker Hub Red Hat のサイトは、ライセンス・キー(pull secret) が無いとダウンロードできない仕組み誰でもアップロードできるし、ダウンロードできる。

ベースを元に改変した新しいイメージの作成( =ビルド) ベンダー/ユーザーが開発したベースコンテナ企業が公開している安全が保証されたコンテナをベースのイメージに使用企業アプリなどを埋め込んだ場合は、
そのままネットに公開できないので、プライベートなレポジトリに小さなサイズが生み出した変化 (4) コンテナである事のお作法企業サポートが欲しいユーザーもコンテナに参入 PULL PUSH PULL 企業のプライベートな、レポジトリ企業が作成したアプリを保管する重要な場所ユーザーが Kuberenetes の上に直接コンテナをインストールするのではなく、Kubernetes がユーザーが書いた構成ファイルに従って、指定されたレポジトリから、コンテナを PULL してくる。コンテナのイメージをKuberenetes 上に直接置く事はできない。こういうパスは無い。 Kuberenetes 上に置くと、万が一ダウンしても自動で再起動したり、負荷に応じてコンテナを増やしてくれる。 RHEL コンテナは、必ず、まず、レポジトリーからイメージがPULLされる ※ただコンテナを動かすだけれであれば、 Linux OSがあれば良い。Kubernetes は必要無い。小さなコンテナは起動の速さにつながる。 → コンテナを小さくする事が大事になる

小さなサイズが生み出した変化 (5) コンテナ化による開発サイクルの高速化仮想マシンにおける開発サイクル工程コンテナにおける開発サイクル工程コーディング作業コンテナのビルドテスト（開発者端末) レポジトリに PUSH
テスト環境に Deploy / Test 本番環境に Deploy / 確認コーディング作業 VMへのアプリインストール(開発者端末) テスト（開発者端末) テスト環境にコードをFTP テスト環境VMへのアプリインストール/Test 本番環境にコードをFTP 本番環境VMへのアプリインストール /確認テスト環境用のアプリ・OS周り設定本番環境用のアプリ・OS周り設定開発のワンサイクル開発のワンサイクル新規機能機能改善バグFix • 他のアプリとの依存関係が「コンテナ」に内包。「可搬性」が高い。 • 開発環境で作成したものと同じものがテスト環境、本番環境にそのままデプロイ可能。 • コンテナ開発プロセス導入による CI/CDツール導入の容易化。開発サイクル高速化の加速。 • 環境毎に新規アプリの「インストール」 • 環境毎にアプリを動かすためのIPや構成など OS周りの設定 t x 開発サイクル数セキュリティパッチ新規機能機能改善バグFix セキュリティパッチ CI/CDツールによる自動化ポイント

コンテナの可用性と Kubernetes 21

仮想マシン上のアプリ可用性コンテナ(アプリ)可用性 Hardware Linux アプリA Linux Hardware OSの再起動アプリの移動 High
Availability Software High Avalability Software コンテナの移動監視・状態の維持監視・状態の維持コンテナの immutability、コンテナの可搬性を活用した HAとコンテナが使用するネットワーク、ボリュームを管理する Software → 「オーケストレター」(Kubrenetes) Kubernetes (k8s) の登場本番環境でアプリを使用する場合、障害時に自動対応してくれるソフトが必要になる。 Linux Linux RHEL Ubuntu アプリA アプリ B A) 元々同じアプリをインストールして待機させておく B) アプリが入って居るボリューム毎マウントする。 C) AとBの混合レポジトリからコンテナを再ダウンロードする高可用性ソフトウェアの例： ClusterPerfect EX, CLUSTERPRO, VMware HA, Power HA etc. アプリケーション内部に高可用性を維持するための機構が組み込まれているものも。 (Oracle RAC 等の DB系のソフトウェアに多い) 独自の作り込みをし、無停止を実現するものものある。 Hardware Hardware 監視、障害対応パターンは単純化(再起動)、規格化。

Kubernetes の基本機能 Host Host コンテナコンテナ Host Host コンテナコンテナ
サービスロードバランス機能仮想ネットワーク機能 Host コンテナリソースの使用制限・1CPUまで・特定の Node以外には置かない Host Host コンテナコンテナ冗長性の確保隣のHost 等で再起動自動スケールアウト Host Host コンテナコンテナコンテナ Host 負荷が増えたので追加 • コンテナを適切なノードに配置する事を「スケジュール」という • プロセスを監視し、適切な Host 上で起動する。前ページで説明していた所コンテナ同士が通信するための専用ネットワーク Kubernetes クラスタ内のロードバランスの機能とクラスタの外の機能があり、この話は少し複雑。最低限必要な CPU / Memory リソースを確保できる所で起動、上限を設定仕組みとしては左の冗長製の確保と同じ OpenShift の場合は環境によっては、Host もスケールアウト/インできる。

Node Node Node Node 24 用語：宣言的 / 命令的 / マニフェストファイル
/ Pod apiVersion: apps/v1 kind: Deployment metadata: name: test-nginx spec: selector: matchLabels: app: nginx replicas: 3 #レプリカ数（Podの数） template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80 #ポート番号 Deploy 使用するコンテナ名コンテナコンテナ・レジストリ pull nginx ・アプリケーション（コンテナ）・アプリケーションのインスタンス数の両方が一つのマニフェスト (yaml ファイル）に記載されている • こういうものをデプロイすべきものですと「宣言」するファイル(マニフェスト・ファイル) • アプリケーションだけでなくマニフェスト・ファイルも必要になる。 • このファイルは基盤 (オンプレ、AWS、GCP、 Azure、IBM Cloud)に依存しない。Kubernetes がインフラストラクチャ・レイヤーの違いを隠してくれる。 Kubernetes が解釈し、その通りに構成を作るこういうものですと「宣言」すると、Kubernetes が「宣言」した通りに作ってくれる。ファイルにしてないで、コマンドを複数実行して同じ事をする事もできる。（その場合「命令的」と言う。柔軟だが作業を保存しておく事はできない）宣言的(declarative) ←→ 命令的 (imperative) 「Pod」は Kubernetes 上で「コンテナ」を扱う単位。

Kubernetes によるインフラ機能の「規格化」高可用性SW サーバー高可用性SW サーバーユーザーSW サーバーユーザーSW(Pod) サーバー
ロードバランサーユーザーSW(Pod) 物理 / 仮想マシンにおける高可用性設計コンテナにおける高可用性設計 • Kubernetesがロードバランサーオブジェクトを提供 • Kuberenetes がユーザーSW(Pod)の高可用性機能を提供 • Deployment の manifest に必要な Pod数を指定するだけで Kuberntesが全て必要な処理を提供 • 開発者がアプリ開発時に高可用性も設計可能 • Active-Active 構成を使用する事ができ、ローリングアップデート等無停止の構成も SW開発者が設計できる。高可用性 SW設定設定ファイル高可用性 Kubernetes ユーザー SW設定 • ユーザーSWの高可用性は、ユーザーSWとは、別の専用SWで担保される。 • ユーザーSWの開発者と高可用性SWの担当者は通常別になる。 • Active-Standbyの構成が前提である事が多い。 • Active-Active 構成の場合は、特殊な高可用性SWを使用するか、担当者間での綿密なすりあわせを元にした設計が必要となる。インフラ管理者の協力も必要。高可用性SW管理者ユーザーSW開発者ユーザーSW管理者インフラ管理者製品選定、インストール設定ファイルに従って Kubernetes が用意してくれる (規格化) ロードバランサーロードバランサー設定ロードバランサー管理者

典型的なWeb三層構造とコンテナ Web 層アプリケーション層データ層 (主にRDB) ロードバランサー数を単純に増やす事で処理能力がスケールする層・大量のCPU /
Memory が必要・高可用性、スケールアウトに物理的な前提がある・etc コンテナが向いている部分コンテナ化のメリットで議論が発生する部分スケール・アウトスケール・アウトコンテナ化されているOSS のRDBはたくさんありますが・・・実際のエンタープライズ・プロジェクトで、 RDBが使われている場合は良く議論になるコンテナコンテナコンテナコンテナコンテナコンテナコンテナコンテナ高速な開発

開発環境の変化 27

コンテナが無い場合の開発環境たくさんの開発者各自が違う環境で、自分の書いたコードをテスト (会わせようと思っても、いろいろズレる) 開発ステージングプロダクションテストOK テストOK ソース・レポジトリ
Deploy (Delivery) Deploy Deploy 本番環境コンテナを使用する事によるメリット・共用の開発環境をシェアする必要が無い (環境が壊れがち) ・最新の環境を簡単にセットアップ (時間短縮、品質向上) みんなのPRを「マージ」= Integration ステージング環境開発環境コードのマージ、ビルド、テスト、デプロイ CI/CDの”D” CI/CDの”I” 人数が少なかったら自分が管理人でも各自の自作環境でテスト各自がテスト済みのコードを共通のレポジトリに送信 (PR:Pull Request) 環境環境は自分でそれぞれ構築非コンテナ環境は、テストの度に環境が汚れるビルドビルドビルドアプリアプリアプリアプリアプリアプリテスト過去の「インストール」の残骸が残りやすい

全員に同じ最新の開発環境をたくさんの開発者各自が全く同じ環境で、自分の書いたコードをテスト開発ステージングプロダクションテストOK テストOK テスト Kubernetes
ソース・レポジトリ Deploy (=Delivery) Kubernetes Kubernetes Deploy Deploy 本番環境コンテナを使用する事によるメリット・共用の開発環境をシェアする必要が無い (環境が壊れがち) ・最新の環境を簡単にセットアップ (時間短縮、品質向上) みんなのPRを「マージ」= Integration ステージング環境開発環境コードのマージ、ビルド、テスト、デプロイ CI/CDの”D” CI/CDの”I” 同じ環境でテスト人数が少なかったら自分が管理人でも開発環境は、最新版の環境のコンテナをダウンロードでして使用各自がテスト済みのコードを共通のレポジトリに送信 (PR:Pull Request) ビルドビルドビルドこういった開発フローは、決まったものがあるわけではなく、何を開発するか、メンバー数がどのくらいか。にも依存して最適解が異なるビルド

まとめ 30

まとめコンテナのメリット： 1 ) サイズが小さくなる事で開発者が使いやすく便利になった。そのためアプリケーション開発の高速化が図れるようになった。 2 ) アプリケーションの依存性をコンテナにパッケージする事で、環境の構成に依存しにくく、どこでも簡単に動かせるようになった。
3 ) イメージ化された事、小さくなった事で、簡単にインスタンス数を増やせるようになった。負荷の変動の大きいアプリケーションでは、スケールアウトが簡単にできるようになった。

linkedin.com/company/red -hat youtube.com/user/RedHat Videos facebook.com/redhatinc twitter.com/RedHat Red Hat is the
world’s leading provider of enterprise open source software solutions. Award-winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500. Thank you 32

OpenShift の基礎コンテナのメリット

OpenShift の基礎コンテナのメリット

Yuhki Hanada

More Decks by Yuhki Hanada

Other Decks in Technology

Featured

Transcript