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