はい ということで ここからクラウドネイティブ時代のCIとCDのありがたということで 北山の方からお送りしたいなと思っておりますさっそくなんですけども 今日はですね クラウドネイティブ時代のCI-CDということでオープンシフトパイプラインと オープンシフトGitOpsといわれるこのCIとCDのことについてお話ししていきたいなと思っておりますまずはですね このCI-CDとよく聞く言葉なんですけどもこれのクラウドネイティブ時代のと言われた時にどういったことに気をつけなければいけないのかということをまずお話ししていきたいなと思っておりますさっそくなんですけども CI-CDといわれると皆さん何を読むかぶでしょうかね 継続的インテグレーションまあ 継続的デプロイメント デリバリーとかって言われるものの短縮がコンティナスインテグレーションとコンティナスデリバリー デプロイメントと言われているところでCI-CDと呼ばれていますただですね これ実際CIにアプリケーションを乗っけるというまでにですね いわゆるローカルで開発するといったところがあるかなと思っておりますこのところがですね いろんな開発者がですね繰り返しの開発とか 修正とかを行って開発量をしていくということが必要なんですけども実際に開発者としてはですね 自分自身がクラウド上で開発してもまあオンプレのローカル上で開発してもまたまだ自分のラップトップですね ラップトップで開発しても同じような環境が使えるということが 結構重要なことになっている一方 CIといわれると何が重要なのかというとですね基本的にはビルドとかテストとかを自動化するということが必要にはなってきますが それを繰り返すことによって品質の高い成果物を求めるということが 必要になってきますただですね これ自身はエンタープライドと言うとですね品質を高めると何をやっているのかというとですねいわゆるガバナンスですねを徹底するということが重要になってきますよとで 次にデプロイメントということでデプロイ作業を自動化しますよ ということが必要なんですけどもこれもですね 品質の高いデプロイメントをしていくシートは失敗しないデプロイメントをするということが重要なことになってきますこの3つの役割があって一つ一つ役割ごとに違うことをやっているというのが重要なことなんですねじゃあ これまでのトラディショナルの CI CD今後現れてくるプラウドネイティングの CI CD何が違うのかという項目がですね ここに書かれています一つ一つ読んでいってもいいんですけども重要なところっていうのがこの真ん中に書かれているところなんですけれどもこれまでのCIっていうのはCIツール自体が共通で使われていました具合で共有で使われることによって一つ一つのプラグインであったりとかバージョンとかのシラは縛られることが多かったですねで 今後のクラウドネイティングな CI CDと言うとですねCIツール自体が独立していることによって各パイプラインであったり デリバリー デプロイメントと言われるものがですね横立的な感情でできるということが重要なことになってきます一方ですね このトラディショナルなCI CDをもうちょっと深く見ていくと こんな風になっています開発者と運用者というのが分かれているんですけども開発者からするとですねいわゆる運用者 いわゆるこのCIツールと言われるものに設定依頼をかけてですね設定作業をするとっていうのは結局運用者の方がパイプライン設定をしてジェンピースみたいなCIツールでビルドの実行とかテストの実行をしていらっしゃるとこれ CDも同じですねCI CDに対してもデプロイメント作業っていうのを依頼してデプロイメントの設定は 運用者側でやっておいてその運用者側でデプロイメント実行っていうのはジェンピースで自動化していますよということが多かったんじゃないでしょうこれによってですねいわゆる運用者がこのジェンピースの重りをするということでですねよく話の中で出てくるのはジェンピースオジさんっていう人がいてですねその人が運用していくっていうこともよく見られたみたいなと思いますこれがクラウドネイティブに変わるとどうなるのかっていうとですねいわゆる開発者が開発者自身で開発ラインを設定するということが可能になります今までこれもやってたよという方もいらっしゃるかもしれないんですけども実際に開発をする上で自分の環境に開発ラインを仕込み込むということができますよこれビルドとかテストの実行も自動化されますしデプロイの実行に関してもですねこれまでインプラの方もしくはオペレーションの方に依頼してたことがですねデプロイの設定ということ自体も開発者側で柔軟に行えるこれが今までオペレーション側いわゆる運用者側ですねにアクセスしてコミュニケーションが発生したことをこのクーバレッジスネイティブな環境によってですねいわゆるCIもCDも自分自身で行えるCDは機械が代替してくれますよと運用を代替してくれますよと言ったところがこのクラウドネイティブなCI CDの大きなリテントを言われているここらに書かせないのがクーバレッジスネイティブと言われる話ですねこれまでクラウドネイティブとかクーバレッジスネイティブとかまあ同じようなことが出てきてこんな合わせてしまうことに注意なんですけどクーバレッジスネイティブというのはですねクーバレッジスの設定方法を前提として作られた通りのことを言っていますこのクーバレッジスの設定方法を前提にするというのがどういうことかというといわゆるこのマニフェストと言われるところに書かれているのであったりとかいわゆるリソースですねこれまではポットとかデプロイメントとかサービスとかそういったもののリソースと同じような形態でいわゆるCIのタイプラインと言われるものを書くことができますなのでゲットからソースコードを取得したりとかイメージをビルドしたりとかそういった作業はいわゆるマニフェストに記載することができるようになるのかこのクーバレッジスネイティブと言われるものになっていますそれによってですね出来上がった構成というのはこちらのコートになりますいわゆる書かれている人がいわゆるクーバレッジスのリソースと同じようにCIのパイプラインであったりとかCEITはですねデプロイメント デリバリーと言われているところのいわゆるマニフェスト自体の方針もしくはデプロイメントといったところも自動化していくということができるのがこのCI CD クラウドネイティブのCI CD売っているところに記載していますなので開発者はですね基本的にはアプリケーションのソースコードのリポジトリーにアプリケーションコードを置くそうすることによって自動的にCIを回すことができてCIから生成されたいわゆるマニフェストですねデプロイするための設定CEITはコンテナのイメージですねこういったものに関しては基本的にCIが作ってあげてそれらをどうのようにデプロイするのかといったところはコンテナのデリバリーというところで実装してくれるというような話になってこのCIとCDについて今日は深掘りしていきたいなと思っておりますまずはCIのほうですねオープンシュートのCIというのはオープンシュートパイクラインと言われるものがになっていますレッドフォットのオープンシュートパイクラインというものですねテクトンに基づいたクラウドネイティブなCI、CDのポリューションを持っているテクトンはですねもともとオープンソースのツールであっていくつかのコンポーネントで形成されています代表的なものがテクトンパイクラインと言われるものですねこれはCIとかCDのパイクラインを構築させるためのいわゆるオブジェクトとしてオブジェクトとまっているテクトントリガーと言われるものこれはですねイベントのポリガーに基づいてパイクラインを実行すると一体のことができるのがテクトントリガーと言われるもの最後はテクトンダッシュボートと言われるものでこれはテクトンパイクラインをそういうのように可視化するのかといったところのインターツといったものがテクトンのダッシュボートと言われるものですこうしたそれぞれの機能はオープンシュートのパイクラインオペレーターと言われるもので全て管理されていることになりますオープンシュートではですねオープンシュートパイクラインがオープンシュートパイクラインオペレーターですねオペリーターと言われるものが テクトをデプロイすることになっていますテクトをデプロイするんですけども このOpenShift Pipelineオペリーターというものは基本的にすべてのネームスペース レッドハウトのOpenShiftと言うとプロジェクトという名前になってますけども 全てのプロジェクトに禁印するオペリーターになっていて 基本的にはこのテクトがOpenShift Pipelineと言われるプロジェクト内に展開されそのテクトがすべてのプロジェクトですね対してカスタムリソースを払い出していくと逆に言うとこのすべてのプロジェクト上から カスタムリソースを定義したものに関してはこのOpenShift Pipelineの中にあるテクトが処理しているというような形になっていますこれがOpenShift Pipelineの構成になっています実際にテクト自体のコンポーネントと どういうものがあるかというと大きくは2つに分類されていて 一つはタスクに関するものですね他ではステップとかタスクタップラン 仕事はパイプラインリソースと言われるものがかかりている下旗にかかれているものがですね パイプラインとパイプラインランというものがありこの2つに関してはですね いわゆるパイプラインを操作するのがいいなってこの2つを同時にちょっと見ていこうかなと 思いますまずはタスク側ですねステクトの中に入ってある タスクという定義これは何をしているのかというのを まずご紹介していきたいなと思いますステクトの中にですね タスクというものに関してはまずステップとタスクという 実態がありますステップって何を示すというのかというとですねこれはいわゆるコマンドの実行単位を 発信していますなのでこのステップの中にですね まあコマンドを実行するためのイメージの指定と そのイメージの中で 適合する 実行するコマンドっていうのを書いてもらうのがこのステップと言われるのこのステップを並べてあげると 一つのタスクと言われるものになりますなのでですね まあ一つのコマンドだけで実行できるタスクってなかなか少ないと思うんですねなので いわゆるステップを組み合わせていきて最終的にタスクという実行の 形態にしてあげるというのがこのタスクの定義になっておりますこのタスクを生成する いわゆるこう作ってあげるとタスクが実行されるのかというと 実はそうではないんです実際にはこのタスクを書いてあげて タスクの次にですねタスクランと言われるものを作りますタスクランというのは いわゆる この先ほど書いたタスクと言われるものを実行するオブジェクトだと 思ってくださいタスクランと言われるものを 作ってあげることによってですねタスクランはタスクを参照するタスクランの参照の中身を見て ステップの実行を一つ一つのコンテラとして 実行するようになってきます実際にタスクランの中で こういうステップがあるんだなというのを解釈するとタスクランはポットを作り上げますポットの中の一つ一つのコンテラで このタスクランに書かれている実行携帯のコマンドを提供していく というような話になっていますなのでですね このタスクランを書くということが最終的にこのタスクを実行することになります逆に言えばですね 一つ一つのステップと言われるものがコンテラに随日にいて 一つのステップは一つのコンテラができるシートの一つのタスクと言われるものはポットの中で全ての処理が行われる ような状況になっていますオープンシュートパイプラインを利用すると こんなふうに見えることですねいわゆるパイプラインと言われる カテゴリーが出来上がりこの中のタスクと言われる項目を開いてあげるとタスクごとのステータスの確認ができるのでタスクランを実行してあげると 実際にこのタスクごとのステータスでサクセスとかフェイルとかっていうものが 確認できますよといったところがありもちろん中で動いてるものはコンテナになってますよねコンテナ自体のログであったり それにジョンゼルステータスというものはそういうのをポッとして見れるような 形になっていますでは一方 パイプラインを書くと言うとどういうことを書くのかというのが 次の話になっていますパイプラインの定義と言われると実行したい一連のタスクの流れを書くことになりますこれまではタスクという中で 一つ一つのコマンドをステップで打つというようなことをしてたんですけども実際にパイプラインを書くと言うとこのタスクを組み合わせることによって パイプラインが制御されますなので パイプラインという定義の中にはこれまでのタスクを どのタスクを使いますかと言ったところを定義することになるんですねなのでタスクを組み合わせるというのは 主意ではパイプラインを書くことによっていわゆるこのタスクがフェイルしたら こちらのタスクをしてくださいもしくはこのタスクが成功したら こちらのタスクをしてくださいみたいないわゆるコンディションと言われるものでそういったものも生成することができますと言ったところに パイプラインによっていわゆるタスクの条件分析と言われるものが 書かれることになりますここで書くと思う方もいらっしゃるんですねCIとかでよくありがちなことなんですよタスクごとでデータ結果であったりとかタスクごとが共通で使うディスク いわゆるアプリケーションデータみたいなものですねそういったものはどうやって管理するのか ということなんですけどそういったものもテクトンでは提供されていますタスクの中にリザルトと言われるものとワークスペースと言われるものがありませんリザルトっていうのは いわゆるキャッシュみたいなもので小さめのデータを共有する場合に 利用するものもう一つのワークスペースと言われるものはこちらは大きめのデータです共有する場合に使われるものになっていますデータとして挙げられているのは ソースであったりとかバイナリーであったりビジュールしたのは 後のバイナリーであったりそういったもののバイナリーであったりとか実行結果もしくはテストとかを置けるのがテストレポートですねそういったもののファイルっていうのをここのワークスペースっていうところに保存しますよこのワークスペースは パーシステントボリュームクレームの中でボリュームとしてマウントしてあげてこのボリュームの中にデータがかかるというような形になります実際パイプラインも実行するときはタスクとタスクランの関係と同じようにパイプラインとパイプラインランと言われるものがあるなのでパイプラインを定義するだけでパイプラインが走るわけではなくって実際にはパイプラインランと言われるものを書くことによって実行されることになりますこのパイプラインランっていうのは何をしているのかというとあくまでパイプラインに書かれているのはテンプレートだと思ってくださいテンプレートの中に実行の変数値を埋め込んだりとか変数で条件分岐とかしたい場合ですねそういったところをパイプラインランに書いてあげて実際にはパイプラインランを走らすことによってタスクが実行されますタスクの中では先ほど言ったみたいにパスクランを呼び付けることになるのでパスクランを呼び付けられると各ポットが生成されてポットの中でコンテナがステップという形でコマンドを実行するというような形をしていますこういったタスクとパイプラインの関係性を覚えておくことによってテクトンと言われるものをすぐに活用することができるオープンシュートパイプラインの実行ですけども今まで話してきたのがこんな感じになりますいわゆる開発者はパイプラインの定義ということでタスクとパイプラインを定義してあげるというようなことですねそうすることによってパイプラインランを実行させてあげるとあとはテクトンが自分でそれをインスタンス化してあげてポットやコンテナとして実行してくれますよとただしパイプラインを実行するのはパイプラインコントローラーといわれるテクトンのコンテナが実行処理をしてくれるというような形になっていますこれはですねパイプラインランを実行するとオープンシュートでもですねパイプラインの実装に応じて条件分岐とかをするのであれば条件分岐に応じてこのようにタスクの内容と言われるものが表示されるようになっていますパイプラインのステータスも確認できるのでもしここで途中でコケたりとかした場合はですねパイプラインの中でこれだけを再実行させるとかといったこともこのビューからできるような形になっていますで一つ一つのパイプラインであったりタスクってどういったものがあるんですかシートはこれ一つ一つ書かないといけないんですかみたいな話になるかなと思うんですねそういったタスクを一つ一つ書いていくとかなり大変な話になるのでレッドハットはですねテクトンのコミュニティと協力することによってテクトンのタスクであったりとかパイプラインのいわゆるテンプレートですね帯りを可能なテンプレートというものを紹介していますこれをテクトンハウズを言われているところに置かれていて実際にインターネット上からアッセスしていただくと見えるんですけどもここに安心の実行する形態であったりとかシートは対損であったりとかゴーであったりとかそういったものを実行するものシートはあとはコンテナをビルとするためのカニコーであったりとかオープンシフトでいうとS2Iビルとみたいなものもあるんですけどそういったものが提供されていますオープンシフトのパイプラインを使うとこういったものがクラスタータスクと言われているところに記載されていますこういったところで提供することによってパイプラインを導入したすぐにこのタスクを選ぶだけで基本的にはパイプラインを作るということができるようになっているオープンシフトのパイプラインのところでひとつだけ記を置けないといけないことがありますよくCI-CDと言われているとCIもするしCDもするしみたいな話になってくるんですけども基本的にデプロイメントパイプラインを生成することが可能なんですけどもデプロイメント先を状態を変化を見てこのデプロイメントパイプラインが実行してくれているというわけではないんですねあくまでジェンキンとかも同じですけども基本的にはパイプラインを生成するとデプロイメント作業というもの自体は開発者もしくはデプロイメントする人が実行のパイプラインというのを書かなければいけませんそれを書いていくともちろん作業の独人化というのも発生しますしCI-CDはデプロイするためにはデプロイするための権限というのが必要になりますのでこのテクトンにデプロイするための権限というのを与えないといけませんそうするとCIにも関わらずCIが結構強い権限を持ってデプロイメントをしなければいけないというような事態になってくるので明らかにセキュリティ的にもよろしくないそうなってくると作業も独人化するしセキュリティもちょっと脆弱になってしまいますCI-CDはデプロイメント作業の統一みたいなことも開発者ごとに違う方にするので統一もなかなかできないといったことになりますそういったところがあるので基本的にはオッコーシュートパイプラインはCIとして作ってあげてデプロイメントとしてはテクトンを使うのではなくここからがアルゴCDを使っていくというような流れになって基本的にアルゴCDを使うと各環境にデプロイメントをしにかかるというわけではなくデプロイメントの環境が変わったらどう的にそれをチェックして変わったのを指定されたあるべき姿とチェックしてよければそのままにしておくしもし変更が必要なのであれば変更をかけるというようなプル型の変更方式になりますこうすることによってCIの役割とCDの役割というのを明確に分離して最終的にはデプロイ先の変化状態変化を見ながら定義された状態に持っていくというようなことを基本的にしていくということがCDの役割になっているこの辺りが今までのCDと大きく違うんです最後にオープンシュートGitOpsと言われているところをご紹介しますオープンシュートGitOpsと言われるものは基本的にアルゴのCDを基盤としたGitOpsのソリューションになっています現時点ではオープンシュート4.6というバージョンなんですがこっちの間はサポートはまだアルゴCDもしかしたら初めて聞くという方もいるかもしれないですけども基本的にはGitのリポジトリーを見てGitのリポジトリーと展開されているクラスターですねクラスターで展開されているアプリケーションの状態を確認して成功性をチェックした上でデプロイをかけるという自動デプロイメントツールだと思っていただければいいかなと思っているそこで重要なのがGitOpsという概念ですリリースの変更とか運用とかみたいして一個一個コマンドで提供するのではなく一個一個コマンドではなくGitの状態を同的にこのアルゴCDと言われるものが検知し検知したものでもし状態の変更が必要なのならば状態を更新しますしクラスターの状態が何かしらいわゆるあるべき姿で違ってるのであれば売られるような作業をしてくれますもちろんクーワレッジ自体もそれはやってくれるんですけども実際にデプロイするためのリソースと言われるもの全てを見ているわけではありますなので一つ一つのリソースを的確にGitと同じような形にしていく聞いてはGitを正確な構成管理ツールと考えてあげてGitの構成管理ツールとクラスターの状態というのを一致させるということがこのGitオープンの重要なところになりますなので多くのアプリケーションの開発においてはアプリケーションの開発のソースコードとマニフェストのリポジトリーというのが分割されている全然違うところで管理されているというのはこういうところにあるなのでマニフェストのリポジトリー自体を更新してあげるとクラスターの状態も変わって変わってすくるというような状態をことによって安定したしては迅速な開発デプロイメントというのができるようになってくるというのがこのGitオープンと言われるものですこれまでは空辺コントローとかOCコマンドによってマニフェストのデプロイしていたと思うこういったマニフェストのデプロイというのはですねそれなりに課題もありましたともちろん一つの環境に一つのマニフェストをデプロイするまあ簡単なことかなと思うんですけどこれが複数の環境になった時に一つ一つのパラメーターですねみたいなものが違っているともしく一つ一つのパラメーター自体にですね設定を間違えるもしくは設定漏れみたいなものが生じてしまって最終的にはステージングとプロダクションの状態が違っているというようなことにもなりかれないのかなと思うそういったことを防ぐためにですねこの空辺コントロールだけだとはやはりデプロイメントの課題というのがありました先ほど言ったみたいなことなるデータベースの接続先であったりとかシークレットの使用とかここならデプリカスデプロイメントであってとかもう一つ一つの設定ですねマニフェストを一個一個手で書き書いていてはやっぱり人間がやるからでは設定漏れとかミスとかがありますそういったことが空辺コントロールでは起きていたんですけども実際にこういったバージョン管理環境管理と言われるものが他の通路を使います例えばですねいくつかあるんですけどもカスタマイズであったりとかヘルムチャートでオープンシュートテンプレートみたいなものがありますカスタマイズって言われまでは空辺コントロールの方に組み込まれたパッケージ製品になっているんですけどもそういったパッケージの通路を多い人であげていわゆるテンプレート自体をパッケージ化してあげてそれに対して環境変数を変えてあげたりと言うかいわゆる環境ごとも設定ですねっていうものを変えていくというようなことができますヘルムも同じような形なんですけどもこれはパッケージとして提供されていていわゆる一つ一つのパッケージを環境ごとに用意することによって変数でこれも環境を変えれると言われるものなんですけどもカスタマイズよりもヘルムチャートのほうが分岐であったりそういったことができるようになっていまして実際ロールバックとかアップデートとかっていうこともですねヘルムの中でできるのでこのGitOpsと組み合わせてやるということも重要なことかなと思ってオープンシュートを使う必要はオープンシュートテンプレートみたいなものもありますこれを活用してやるということも可能なんですけどもどちらかというとこのオープンシュートテンプレートというもの自体がいわゆるGUIとして提供されているのでGUI画面からポチポチする専用になっているので基本的にGitOpsで使うという意味だとカスタマイズかヘルムチャートを使うことが多いんじゃないかなと思いますこの後のセッションでNTT東日本様がやっていらっしゃるヘルムを使ったGitOpsの実装についてもご紹介がありますのでこちらでもまた詳しく見ていただければなと思いますこういったGitOpsのアプリケーションを作るという意味ではGitOpsアプリケーションマネージャーといわゆるコマンドラインが今開発されています実際にリポジトリー見ていただいた方が早いんですけどもGitOpsとブートストラップで立ち上げることになっていわゆる環境ごとの設定であったりとか実際に先ほどご紹介したGitの設定ですねみたいなものを初期設定を動的にやってくれるようなコマンドになっていますそれでアプリケーションの環境を増やしたりとかもしくは今ある環境に合わせたりとかっていう言葉は簡単にできますそういったことをカスタマイルとかヘルムとか組み合わせることによってできますよというのがこのGitOpsアプリケーションマネージャーといわれるものになっていますこういったツールも出来上がっているという状況ではありますオープンシフトGitOpsビューといわれるもののビューが提供されますGitOpsサービスオペレーターといわれるGitOpsを提供するためのオペレーターを入れることによってオープンシフト内にGitOpsの環境を自体を可視化するようなツールというものが開発されていて今後これが投稿されることによってオープンシフトの中でGitOpsを資格的に取り扱うことというのが出来るようになっていますいった状況になっていますこれを使うことによってGitOpsと先ほどテクトンパイプライですねこういったものをコマンドラインフォーサーだけではなくて視覚的に作りやすくアプリケーションを管理しやすくなっているというのがこれからのクラウドネイティブのCI CDの提供になっていますということで最後さまりだけしたいなと思います今日はですねクラウドネイティブ時代のCIとCDのあり方ということでご紹介してきましたけれども話としてはですねこれまでのCIとCDというものは一緒にやっていたってことも多かったんじゃないかなと思うんですけれどもこれからはですねCIはCDのCIをCIのやることということがあってここではやはりこれからのCIのためのコンテナイメージと言われるものを正しく作ることCIはマニフェストを正しく書くことと言ったところがCIに求められるところではあるのですしエンタープライズで言うならば先ほど言ったみたいなガバナンスをここで構成することというのがこのCIに求められることです今後継続的デプライメントというところでアルゴCDと言われるものがあるんですけどもこういったものに関しても安定的に継続的にデプライメントを受けといったことが必要なので各環境ごとにデプライメントの操作を手動で変えていくのではなく自動的にコンフィグを読み込むことによって同的にデプライメントができると言ったことを作るのが継続的デプライメントが出資であってマルゴCDがそういったものを提供しているということになりますということですねこれまで運用の作業をCI-CDもそれがより自立的に動くようになってきますのでこういった継続的インテクレーションと継続的デリバリーCI-CDの役割を正しく分離してあげるというようなことが重要になってきますこれをできてことですねクラウドネイティブ時代のCIとCDの役割というのが終わりますのでこれまでのCI-CDとちょっと違うところっていうのをやはり運用やプロセスにしていかなければ結果的にウェリットが得られないというところもありますねこういったところに注意していただければなと思っておりますということで今日はですねクラウドネイティブ時代のCI-CDの役割というところでご紹介してさせていただきましたご提供ありがとうございました