OpenShiftで実現するプラットフォーム・エンジニアリングにおけるDevSecOpsの価値

OpenShiftで実現する プラットフォーム・エンジニアリング におけるDevSecOpsの価値

本セッションは個人の見解であり、 所属組織の立場、戦略、意見を代表するものではありません。 また、技術的な内容にも言及しますが、正確性を保証するものではありません。

｜ プラットフォーム・エンジニアリングって知ってますか？ 2026年までに、ソフトウェア・エンジニアリング組織の80％がプラットフォーム・エンジニアリング・チームを 結成し、そのうち75％がセルフサービス開発者ポータルを取り入れるとGartnerは予測している。

｜ とりあえず、これを観ておくと良いよ https://platformengineering.connpass.com/event/275718/

• https://platformengineering.connpass.com/event/275718/

以上！

とかやると、当然方々から怒られるので…

｜ 今日お話ししようと思っていること 1. プラットフォーム・エンジニアリングって何？ 2. OpenShiftでプラットフォーム・エンジニアリングをするって？ 3. OpenShift Pipelines(Tekton)にフォーカスして何ができるか考えてみる ようするに、 OpenShiftで使えるTekton（OpenShift Pipelines）をプラットフォーム・エンジアリングの観点で 『どう使えるか？』、『どう使っていくのがいいのか？』 を中心にお話ししていこうかなって思ってます。

IBM Japan, Hybrid Cloud Services ◼ 2019年2月~ IBM中途入社 ◼ 前職は金融系SIerで20年超のエンジニアとしてのキャリア ◼ 専門領域は「アプリ基盤」（アプリとインフラの間を取り持つ仕事） アプリ基盤という仕事柄、アプリを支える仕事をずっとしてきていたので アプリ生産性と管理統制を両立させる仕組みの構築を考え続けることが多かった。 Satoshi Doi @satoshi55d Senior Application Architect Red Hat Certified Specialist (ちなみに去年末失効して今はモグリです…) 2010年~くらい？ 会社の方針でなんか使い始める。 フレームワークとか作るチームを指揮 2013年~くらい？ Immutable Infrastructure? それ良さそう、と思って注目 2015年~ OpenShiftにフルコミット Red Hat Summitでの出会い ここまでくればビジネスで使えそう

｜ プラットフォーム・エンジニアリングの定義 厳密な定義は存在しないようだが、以下のガートナーの説明が個人的にはしっくりくる • プラットフォーム・エンジニアリングは、再利用可能なツールとセルフサービス機能を実装し、インフラ ストラクチャ・オペレーションを自動化することで、開発者のエクスペリエンスと生産性を向上させる • 新たなテクノロジのアプローチであるプラットフォーム・エンジニアリングは、アプリケーションの再利 用可能で構成可能なコンポーネントとサービスを活用する • ユーザーにとっては、標準化されたツールとコンポーネント、そして自動化されたプロセスを利用できる というメリットがある

｜ 共通基盤ってうまく行ったことありました？ 過去には複数のシステムをまとめて管理する基盤を作り、その上で同じようにシステムを 作っていけば効率的なのでは？として数々の共通基盤が作られ、そして死んでいった。 とにかく中央集権、勝手は許さん 僕の考えた最強のシステム 勝手にやっちゃダメよ。申請してね。 （数週間〜数ヶ月の待ち時間） みんな私の言う通りにやってね。 （べき論の押し付け） 中央集権的に足並みを揃え て上手くいくことといかな いことがあるのでは？ 何やるのも遅すぎるよ… べき論はわかるけど、うち はそんな成熟度に達してな いから開発者がついてこれ ないよ…

｜ ならばセルフサービスだ！Kubernetesだ！ 出典: https://twitter.com/memenetes/status/1637861860039876624?s=20

｜ ならばセルフサービスだ！Kubernetesだ！ 出典: https://twitter.com/memenetes/status/1637861860039876624?s=20

｜ ならばセルフサービスだ！Kubernetesだ！ 圧倒的学習コスト 開発者任せで上手くいく未来、想像できますか？ 出典: https://twitter.com/memenetes/status/1637861860039876624?s=20

｜ これに対処するのがプラットフォーム・エンジニアリング アプリ 顧客 顧客 サービス提供 サービス提供 アプリ ・・・ アプリ 顧客 アプリ サービス提供 ・・・ 管理・統制 インフラ インフラ インフラとアプリをシステム毎に 個別設計・構築。非効率では？ ・・・ インフラ インフラだけ集約してアプリチームを 管理・統制してみました。 ⇨一定の効果はなくはないが、「管理」 されただけの状態で真の価値を提供できるのか？ アプリ アプリ ・・・ サービス提供 プラットフォーム プラットフォームチームからみてアプリチームは サービス提供対象のお客様として捉える。 顧客に価値を提供するためにアプリチームに対して どんな価値を提供できるか？を考えていくこと。 ⇨これがプラットフォーム・エンジニアリング

｜ 手前味噌で恐縮ですが… (2020年発表だからガートナー発表より早いね！) https://speakerdeck.com/sachiwo/enhuramoopenshifttehuratutohuomuwozuo-ritai

• https://speakerdeck.com/sachiwo/enhuramoopenshifttehuratutohuomuwozuo-ritai

｜ さて、話変わってTektonですが、人気ないんですかね… 出典: CI/CD Conference 2023

｜ Tekton, でも便利なんですよ… TaskとしてPipelineの各処理をパーツとして使いまわせる、そして何よりClusterTaskを 作って利用者に公開すればパーツを組み合わせるだけでPipelineが作れる！ namespace namespace Task A クラスタ利用者A 特殊なPipelineであれば各 Taskは利用者が作成。部分的 にClusterTaskを使用して省力 化。 Task B ClusterTask A pipeline A pipeline B taskRef: Task A ↓ TaskRef: TaskB ↓ TaskRef: kind: ClusterTask Task A taskRef: kind: ClusterTask Task C ↓ TaskRef: kind: ClusterTask Task D ClusterTask B ClusterTask C ClusterTask D ClusterTaskはクラスタ提供者 が作成して登録することも できる。 クラスタ提供者 クラスタ利用者B 一般的なPipelineであればTaskを作る 必要がなく、用意されたClusterTask を並べるだけで作成できる。

｜ Tekton, でもでも面倒くさいんですよね ②そしてそれぞれを呼び出す フローをyamlでまた書く + + + + ①CI/CDフローの箱一個ごとにyaml + コンテナ作る ✓ これはCI/CDフローのタスクを使い回しできるように、タスクごとの独立 性を担保して依存を断ち切るために非常に有用な仕組みで、Jenkinsの課題 を解決できる。 ✓ でも辛いものは辛い。 これらを準備してフローを回すまでのハードルが高い。学習コストが高い。 Yaml Hell !!

｜ OpenShift上手く使うと面倒臭さも極小化できます 開発者に対してのサービスとして提供したいパイプラインを登録、払い出しができる。 GUIから簡単に CI/CD Pipelineを払い出し yamlテンプレートを選んで Create押すだけ

｜ Demo: 例えばこんなパイプラインを作るとして… Openshift （開発） Dev Team (Eclipse, VSCode) クラウド環境 ① Ops Team ② Job Trigger Openshift （検証/本番/その他） 手動開始 Pull Webclient Build Source Build SonarQube Analysis Image Build Git(Local) Base Image Source code クラウド 環境 Deploy (開発) TEST: any tool Manifest Repository Release Entry Detect /Pull Deployment Manifest DEPLOY Deploy (本番) custom 配布資料ではデモは割愛させていただきます。 Base Image Push image Webhook or Import Test Tool Pod SonarQube Build Deployment Manifest Job Test Pod Pod Pod App Build deploy PostgreSQL Databases Application Repository Internal Registry Import image Update Internet or RedHat Container Catalog (RHCC) custom Base Image External Registry Import image ITAC(IBM) Base Image Library Repository Push image Internal Registry deploy Pod App Public Image Catalog (DockerHub, Operator.Hub) 環境管理

｜ DevSecOpsの複数の側面 DevOps/DevSecOpsは人や組織、文化的側面が強くハードルが高く感じるかもしれない が、ツールなどを使ってまずは何ができるか、何が良くなるかを試してみるのが大事。 DevOpsの四つの柱(※)とDevSecOps 個々人との 対話 チーム間の 関係性 スケール ツール セキュリティ 仕組みとしてカバーできる範囲 DevOps DevSecOps ※ 出典:「Effective DevOps ―4本柱による持続可能な組織文化の育て方」

｜ Reference Architectureに加えてValidated Patternを提供できる まずは試そう、となった時に学習コストが高ければそこで頓挫してしまうことだってある。 だから、使いやすく、低学習コストなサービスを「開発者」に提供することでハードルを下げる。 Reference Architecture D e v Te a m ( Eclip se , VSCo d e ) Op e n sh ift （ 開発） Validated Pattern クラウド環境 Op s Te a m Jo b Tr ig g e r Op e n sh ift （ 検証/ 本番/その他） ⼿動開始 Pu ll W e b clie n t Bu ild So u r ce B u ild So n a r Qu b e A n a ly sis I m a g e B u ild Git(Local) Base I m age Source code クラウド 環境 D e p lo y ( 開発) TEST: a n y to o l Manifest Repository R e le a se En tr y D e te ct /Pu ll Deploym ent Manifest DEPLOY D e p lo y ( 本番) custom Base I m age Pu sh im a g e W eb h ook or I m p ort Pod Te st Pod Pod Po d App Bu ild deploy Pu sh im a g e PostgreSQL Databases Application Repository I nternal Registry I m p ort im a g e U p d a te I n te r n e t or RedHat Container Catalog ( RHCC) External Registry custom Base I m age I m p ort im a g e I TA C( I B M ) Base I m age Library Repository ＋ Test Tool SonarQube Build Deploym ent Manifest Jo b I nternal Registry deploy Po d App Public I m age Catalog ( DockerHub, Operator.Hub) 環境管理 他社事例、他チーム事例でこんな感じでやってましたよ、これがBest Practice ですよといったReferenceとなるArchitectureは有用ではあるけれども… Reference Architectureが実際に動くものとして払い出せると もっと素敵だと思いませんか？ 当然、使い慣れてきたら自分なりのカスタマイズも可能。

｜ プラットフォーム・エンジニアリングの観点で考えてみる 再掲: ガートナーのプラットフォーム・エンジニアリングについての説明 • プラットフォーム・エンジニアリングは、再利用可能なツールとセルフサービス機能を実装し、 インフラストラクチャ・オペレーションを自動化することで、開発者のエクスペリエンスと生産 性を向上させる • 新たなテクノロジのアプローチであるプラットフォーム・エンジニアリングは、アプリケーショ ンの再利用可能で構成可能なコンポーネントとサービスを活用する • ユーザーにとっては、標準化されたツールとコンポーネント、そして自動化されたプロセスを利 用できるというメリットがある 顧客 サービス提供 簡単にセルフサービスで使える良いもので開発がしたい。 面倒な手続きで時間を取られたくない。 アプリ 自社として標準化して統制が取れた状態でアプリチームの 創意工夫を阻害しない状態で提供したい。 アプリ サービス提供 プラットフォーム ・・・

｜ ほら、プラットフォーム・エンジニアリングしてませんか？ 簡単にセルフサービスで使える良いもので開発がしたい。 面倒な手続きで時間を取られたくない。 ⇨GUIでポチポチして開発者が好きなように払い出し 自社として標準化して統制が取れた状態でアプリチームの 創意工夫を阻害しない状態で提供したい。 ⇨Validated Patternとして標準化したものをセルフサービス で提供

｜ まとめ • プラットフォーム・エンジニアリングは開発者に対して（その先の顧客に対して価値を届け るために）どのようなサービスを提供していくかをエンジニアリングすること。 • 一部の強者が作る、「俺が考えた最強のプラットフォーム」ではなくそれを利用する開発者 の成熟度に合わせて、共に進化していくことも視野に取り組む社会的活動でもある。 • Tekton便利だけど面倒くさい（学習コストが高い）を解消し、開発者に対して有用なサー ビスとして提供できる仕組みがOpenShiftにあるので使ってみると良い。 • Tektonの例のように開発者に対するサービス、という観点で他にも様々な工夫がOpenShift ではされているので見てみてください！（私の過去スライド参照） プラットフォーム・エンジニアリングに寄与できる便利機能がたくさんある。

｜ 最後に宣伝 本日お話しさせていただいたような内容をサービスとして提供したい、という想いで 現在も進化しながら提供させていただいているのが弊社デジタルサービス・プラットフォーム。 https://www.ibm.com/resources/consulting/jp-ja/digital-service-platform/ プラットフォーム・エンジニアリング興味出てきた！やりたいけど何からやれば？ みたいな時にお声がけください🙇‍♂️

• https://www.ibm.com/resources/consulting/jp-ja/digital-service-platform/