コンテナ共創センター勉強会#6_1.Keynote : コンテナの価値を享受するために

© 2019 IBM Corporation 1 © 2020 IBM Corporation 1
1 コンテナの価値を享受するために ~OpenShiftを活⽤するためのポイントや体験談について~

2 はじめに ü 個⼈利⽤の範囲を超えて、本資料の複製、転載、転⽤、引⽤等の⼆次利⽤は禁⽌させていただきます。 ü 本資料は講師が慎重に著述・編集しています。ただし、本資料の記述内容に関わる構築・運⽤結果にまつわるあらゆる損害・障害につきましては、責任を負いませんのであらかじめご了承ください。 ü 本資料における全ての掲載内容は、あくまで私⾃⾝の⾒解であり、必ずしも私の所属団体・企業における⽴場、戦略、意⾒を代表するものではありません。

3 講師紹介 Yoichiro Suzuki（鈴⽊洋⼀朗）所属︓ キンドリルジャパン合同会社 ※本資料における全ての掲載内容は、あくまで私⾃⾝の⾒解であり、必ずしも私の所属団体・企業における⽴場、戦略、意⾒を代表するものではありません。経歴︓ マルチテナント型クラウドサービスの運⽤を経て、様々な業界におけるクラウド・コンテナの設計・構築・運⽤・技術⽀援を担当。サービス開発やコンサル⽀援にも従事。共著︓ 『OpenShift徹底活⽤ガイド』シーアンドアール研究所出版認定資格︓ twitter︓ @yoichiro_2 SPECIALIST IN OPENSHIFT ADMINISTRATION SPECIALIST IN OPENSHIFT APPLICATION DEVELOPER

4 コンテナ共創センター勉強会 #1 振り返り • コンテナのオーケストレーション • コンテナ管理の⾃動化 • 開発⽣産性向上 • 可搬性の向上 • 資源の効率化 • サーバー仮想統合頻繁なアプリ開発・リリースを実現するのに限界が膨⼤に膨れ上がるコンテナの管理に限界が https://speakerdeck.com/satokota/kontenafalsejia-zhi-toha コンテナ共創センター勉強会 #1 「コンテナの価値とは」より再掲

5 • コンテナのオーケストレーション • コンテナ管理の⾃動化 Kubernetesスキルを持つ⼈材を確保するにはハードルが⾼い ü 不具合発⽣時は⾃⾝で問題レポートを調査 ü 未修正の不具合は、⾃⾝で修正コードを適⽤（もしくは誰かが修正するのを待つ） ü Kubernetesから開発機能や運⽤機能までを⾃⾝で組み合わせてバージョン管理 • 修正プログラムの享受や問い合わせが可能 • コンテナを開発・運⽤する上で必要な機能の提供 • 各企業の製品・サービスとの連携 • テスト済みの機能が出荷 OSSの壁を越える Kubernetesのディストリビューション製品が誕⽣

6 ミドルウエア物理/仮想環境 OS アプリケーションサーバ環境ミドルウエアコンテナコンテナ基盤コンテナ環境アプリチームインフラチームアプリケーション物理/仮想環境 OS OSモジュール ü ベースイメージの⽤意は︖ ü コンテナのビルドは︖ ü CI/CDパイプラインは︖ ü CI/CDの設定やビルド・テストスクリプトを作成するのは誰︖ ü アプリ⽤のマニフェストファイル作成は誰がどうやって︖ ü コンテナ基盤の権限を管理は︖ ü 外部とのネットワーク接続管理は︖ ü コンテナ基盤の可⽤性の管理は︖ ü コンテナ基盤とコンテナのログはどうやって︖既存環境との連携は︖ ü コンテナ基盤のセキュリティ設定は︖ ・・・ディストリビューション製品でも考えないといけないことはそれなりにある

7 コンテナの価値を教授するために何を考え実装しないといけないのか、 OpenShiftを例に私の経験からいくつか紹介します。 ※ OpenShiftについては、コンテナ共創センター勉強会 #5で解説された「OpenShiftって何ができるの︖Kubernetesとの違いをわかりやすく解説︕」をご参照ください。クラスタの構築クラスタの設定コンテナのビルドコンテナのデプロイコンテナの運⽤本⽇のテーマ本⽇メインでお話しする範囲

8 本⽇の内容 Ø 物理構成を意識したクラスタ設定 Ø マルチテナント Ø ビルドとデプロイの役割分担

10 コンテナの価値を享受するためにその① コンテナ環境どんなにアプリ開発のスピードが向上しても、信頼性が低ければ、ユーザが満⾜するようなサービスは提供できない。コンテナの価値を享受するためには、コンテナ環境の信頼性向上も不可⽋。コンテナコンテナコンテナ

11 OCP（OpenShift Container Platform）の物理構成例 ※ あくまでも構成例です。インストール⽅法や設計によって構成は異なります。マスターノードマスターノードマスターノードワーカーノードワーカーノードロードバランサ DNS DHCP ロードバランサロードバランサクラスタを構築したら物理環境は考えなくていいわけではない。 OpenShiftの物理構成全体を意識した設定をすることで、より信頼性⾼いのコンテナ環境を実現できる。

12 例）OCPの基本的な通信マスターノードマスターノードマスターノードワーカーノードワーカーノードロードバランサ DNS DHCP ロードバランサロードバランサコンテナアプリへの通信（http, https）マスターAPIへの通信（oc cli等） OpenShift Web UIやアプリ管理画⾯への通信（https）マスターとワーカー間の通信（6443, 22等）エンドユーザ管理者・開発者管理者・開発者

13 例）物理構成を意識したインバウンド通信マスターノードマスターノードマスターノードワーカーノードワーカーノードロードバランサ DNS DHCP ロードバランサロードバランサコンテナアプリへの通信（http, https）マスターAPIへの通信（oc cli等）マスターとワーカー間の通信（6443, 22等）外部ネットワーク管理ネットワーク管理ネットワーク内部 DNS アクセス経路やセキュリティの観点でネットワークを制御したいこともある OpenShift Web UIやアプリ管理画⾯への通信（https）エンドユーザ管理者・開発者管理者・開発者

14 インターネット例）OCP上で設定する例 OCP route https://aaa.com Public router pod Web Application pod route https://pbbb.priv.com Container Management pod route https://paaa.priv.com Private router pod RouteあるいはProject単位で、どのRouterを利⽤するか制御できるエンドユーザ開発者・管理者他拠点専⽤線 https://aaa.com https://paaa.priv.com

15 Zone B Worker Node Zone A 例）マルチゾーン構成でのPod配置 Worker Node Zone C Worker Node OCP Deployment（replicas=3）アプリ Pod アプリ Pod アプリ Pod

16 Zone B Worker Node Zone A 例）マルチゾーン構成でのPod配置 Worker Node Zone C Worker Node OCP Deployment（replicas=3）アプリ Pod アプリ Pod アプリ Pod ゾーン障害でサービス停⽌になりかねない。マルチゾーンのメリットを活かしきれていない。

17 Zone B Worker Node Worker Node Topology Zone C Worker Node Worker Node Topology Zone A 例）マルチゾーン構成でのPod配置︓topologySpreadConstraints Worker Node Worker Node Topology zone: a zone: a zone: b zone: b zone: c zone: c OCP Deployment （replicas=3, topologyKey=“zone”, maxskew=1）アプリ Pod アプリ Pod アプリ Pod ノードに指定したラベルの値で Topologyを作成 skewとは、トポロジー間におけるPod数の差分。他のゾーンにデプロイされると、 Skewの値が2-0=2となってしまうため、必ずZone Cにデプロイされる

19 シングルテナントかマルチテナントか OpenShift Cluster OpenShift Cluster プロジェクトチームA OpenShift Cluster シングルテナント OpenShiftを利⽤する複数のユーザをクラスタ単位で分離マルチテナント OpenShiftを利⽤する複数のユーザを単⼀クラスタ上で論理的に分離 ü 資源コストの効率化 ü 運⽤管理負担の軽減 ü 環境の払出しが⽐較的早い ü クラスタ障害の影響を局所化 ü 他システムの影響を受けにくいプロジェクトチームB プロジェクトチームA プロジェクトチームB

20 コンテナの価値を享受するためにその② マルチテナントでガバナンスを効かせ過ぎると、開発スピードの⾜枷になりかねない。コンテナ環境をある程度統制しつつ、テナントユーザがある程度⾃由に利⽤できる環境を提供することで、コンテナのスピードを活かせる。 OpenShift Cluster プロジェクトチームA プロジェクトチームB マルチテナント管理者

21 インターネット OCP Project A プロジェクトチームA プロジェクトチームB Project B ネットワーク⽤ Project PV PVC Storage PVC PVC Route Route 開発機能（OCR, Web UI等）プロジェクトA プロジェクトB エンドユーザ提供されたProjectの範囲内で、リソースを作成してコンテナアプリをデプロイする Router Pod ネットワーク⽤ Project Router Pod マルチテナントの構成例マルチテナント管理者必要な周辺機能を取り揃え、必要な権限を各プロジェクトに割り当てる PV PV 運⽤機能（EFK, Grafana等）プロジェクトA プロジェクトB

22 インターネット OpenShift Cluster Project A Project B ネットワーク⽤ Project PV PVC Storage PVC PVC Route Route 開発機能（OCR, Web UI等）プロジェクトA プロジェクトB エンドユーザ Router Pod ネットワーク⽤ Project Router Pod マルチテナントの構成概要例マルチテナント管理者 PV PV 運⽤機能（EFK, Grafana等）プロジェクトA プロジェクトB RBAC機能を活⽤し、利⽤するプロジェクトのみ権限を与え、 Project上で⾃由に操作させる NetworkPolicyで、 Project間の通信をブロックする静的/動的プロビジョニングで PVCに対してPVを割り当てる LimitRangeやQuotaで、リソースの利⽤を制限する周辺の開発・運⽤機能も同様に権限を制御する必要がある（OpenShiftは基本考慮されている）プロジェクトチームA プロジェクトチームB

24 Kubernetesにおけるコンテナデプロイの流れ ① Dockerﬁleを作成する ② コンテナイメージをビルドする ④ コンテナアプリを実⾏する Dockerfile マニフェストファイル ③ マニフェストファイルを作成する

25 コンテナデプロイまでの責任分界点についてアプリチームインフラ担当者新チーム責任分界点を明確にする ü これまでの体制を踏襲しやすい ü 両者間でコミュニケーションを密にしなければならない責任分界点を取り除く ü ⾃律的に開発・デプロイができる ü 責任範囲が従来よりも⼤きくなりがち Dockerfile OS ミドルウェアアプリマニフェストファイル Dockerﬁle OS ミドルウェアアプリマニフェストファイル

26 コンテナの価値を享受するためにその③ 責任分界はアプリ開発スピードの妨げになりかねない。コンテナのスピードを活かすには、コード開発からデプロイまでのフローを整備する必要がある。アプリチームインフラ担当者 Dockerfile OS ミドルウェアアプリマニフェストファイル

27 責任分界点を明確にするときのよくあるパターンアプリチームインフラ担当者アプリチームインフラ担当者アプリチームインフラ担当者 CIツールソースコードリポジトリ 1. インフラチームがビルド ü ガバナンスを効かせやすい ü ビルド時にリードタイム発⽣ 2. アプリチームがビルド ü アプリ開発者が⾃律的にビルド ü ガバナンスを効かせにくいマニフェストファイルアプリソースコード Dockerfile ビルド⼿順書マニフェストファイルデプロイ⼿順書 3. CI/CDツールでビルド ü ガバナンスが効かせやすく、開発⼯数を削減 ü CI/CDパイプラインの構築・保守が必要アプリソースコード CDツール

28 責任分界点を明確にするときのよくあるパターンアプリチームインフラ担当者アプリチームインフラ担当者アプリチームインフラ担当者 CIツールソースコードリポジトリ 1. インフラチームがビルド ü ガバナンスを効かせやすい ü ビルド時にリードタイム発⽣ 2. アプリチームがビルド ü アプリ開発者が⾃律的にビルド ü ガバナンスを効かせにくいマニフェストファイルアプリソースコード Dockerfile ビルド⼿順書マニフェストファイルデプロイ⼿順書 3. CI/CDツールでビルド ü ガバナンスが効かせやすく、開発⼯数を削減 ü CI/CDパイプラインの構築・保守が必要アプリソースコード CDツール

29 OpenShiftで利⽤するコンテナイメージ OS ミドルウェアアプリ OS ミドルウェア S2Iスクリプトアプリケーションイメージ S2Iビルダーイメージ実⾏可能なイメージソースコードからアプリケーションイメージをビルドするイメージ or OpenShiftのコンテナイメージ

30 コンテナをデプロイするまでの流れアプリケーションイメージ S2Iビルダーイメージ S2Iビルドデプロイマニフェストファイルアプリソースコード OS ミドルウェアアプリビルドコンテナ OS ミドルウェア S2Iスクリプトビルド共通のフローアプリケーションイメージを直接ビルドするフロー S2Iビルダーイメージからアプリケーションイメージをビルドするフロー

31 Templateとは Service Route Deployment BuildConﬁg Secret ConﬁgMap Image Stream Template “テンプレートでは、パラメーター化や処理が可能な⼀連のオブジェクトを記述し、 OpenShift Container Platform で作成するためのオブジェクトの⼀覧を⽣成します。” 2021/09 バージョン4.8時点の「Red Hat Customer Portal , Product documentation, OpenShift Container Platform, イメージ第10章テンプレートの使⽤」より引⽤アプリチームA アプリチームB アプリチームC DB_PASSWORD=aaa DB_PASSWORD=bbb DB_PASSWORD=ccc

32 OCP OpenShiftの機能を利⽤した役割分担の例インフラ担当者 S2Iビルダーイメージ OS ミドルウェア S2Iスクリプトコンテナレジストリ Template OCR ビルド S2I ビルドデプロイカタログインフラ担当者の作業 OpenShiftによる⾃動作業アプリ開発者の作業ソースコードリポジトリアプリチームソースコードリードタイムなしでデプロイ可能コミュニケーションにかかる負担を軽減

33 責任分界点を明確にするときのよくあるパターンアプリ開発者インフラ担当者アプリ開発者インフラ担当者アプリ開発者インフラ担当者 CIツールソースコードリポジトリ 1. インフラチームがビルド ü ガバナンスを効かせやすい ü ビルド時にリードタイム発⽣ 2. アプリチームがビルド ü アプリ開発者が⾃律的にビルド ü ガバナンスを効かせにくいマニフェストファイルアプリソースコード Dockerﬁl e ビルド⼿順書マニフェストファイルデプロイ⼿順書 3. CI/CDツールでビルド ü ガバナンスが効かせやすく、開発⼯数を削減 ü CI/CDパイプラインの構築・保守が必要アプリソースコード CDツール

34 CI/CDに有⽤なOpenShiftの機能 CI/CDツールの管理から解放される Kubernetesを拡張して CI/CDに有⽤な機能を提供 Source to Image Build Conﬁg Image Stream Integrated Docker Registry Deployment Conﬁg Pods Replication Controller Persistent Volume Claim Persistent Volume Services Routes Software Defined Network 凡例 OpenShift Pipeline (Tekton) OpenShift GitOps (Argo CD) Jenkins Image Git Kubernetes機能 OpenShift機能外部ツール ※ただし、CI/CDツール上でのビルド・デプロイ設定は⾏う必要がある

35 ミドルウエアコンテナコンテナ基盤コンテナ環境アプリケーション物理/仮想環境 OS OSモジュール ü 物理構成を意識したクラスタ設定で、より信頼性の⾼いコンテナ環境を実現 ü ある程度統制しつつ、ある程度⾃由に利⽤できるマルチテナントでコンテナのスピードを活かす ü S2IやCI/CDツールを活⽤し、ガバナンスの効いた迅速なデプロイを実現今⽇の内容 ※ 上記以外にも考えることはたくさんありますが、今⽇の話が皆様のヒントになったのなら幸いです。

36 ご清聴ありがとうございました︕︕

コンテナ共創センター勉強会#6_1.Keynote : コンテナの価値を享受するために

コンテナ共創センター勉強会#6_1.Keynote : コンテナの価値を享受するために

More Decks by nakaji1106

Featured

Transcript