77歳の爺が最初にコンテナアーキテクチャーを聞いたのは、1983前後か1995前後か思い出せないが
1985にデータベースと言う感性が飛び交い、ドキュメンテーションのデリバリーシステムとして
様々な情報をコンテナの入れ物に運ぶと言うコンセプトが議論されていた。
SNAの通信手段がスタートストップやBSCから、VTAMと言うアクセスメソッドに対して
TCP/IPと言う軍事技術からインターネットの技術が生まれたように、
2005ー2024 は全くコンピューターを勉強していないが、久し振りに読むと
2013のCatalinaMACosを使っている身には楽しめるなあ。とくにクラウド環境を少し学ぶ気になる。
コンテナをさらに活用しよう! 「マイクロサービス」と「サーバーレス」
2021年4月6日(火)
日暮 哲（ヒグラシ サトシ）
へえ、面白い。コンテナアーキテクチャで検索して読めた。
みずほ銀行の大トラブルのとき朝日の記者が質問し、その後話されたことはないが、
こんな思想で３銀行を統一したため、と説明できなくもない。
ユーチューブやフェースブックを利用すると個々の事実は思い当たる。
ゆっくり解説して行きたい。
→アプリレーヤーを２層にする、従来の７レイヤーのインプリメンテーションが全く違うだろうね。
→ソニー銀行と富士通がマイクロアーキテクチャと呼んで居たが到底無理だろうね。取りやめたね。
勘定系の現場に必要性がないのだろうね。
フェースブックやXでの金融犯罪広告の多さにウンザリだが、騙される人を救う思想はないなあ。
日本IBMがITゼネコンとして参画している、みずほ銀行や三菱UFJ銀行にも犯罪に立ち向かう思想が
つくづく欠けていると感じる。アメリアの銀行業界でATM還付詐欺なってあるのだろうか？
まず、老人が騙されて振り込む社会風土がないのか。
それに財界が不思議な程に左翼化して、電気代に寄生する太陽光発電など、既に滑稽を通り過ぎている。
株価も一種の仮想マネーだね。暗号通貨よりマネーだろう。
【ニューヨーク=伴百江】米企業の経営者が自社株の売り
今年に入り、メタ・プラットフォームズのマーク・ザッカーバーグ最高経営責任者（CEO）や
アマゾン・ドット・コム創業者のジェフ・ベゾス会長などが相次いで大規模に売却
株式相場の「天井シグナル」との見方。
昨年11月1日から12月末までの売却は約128万株、総額4億2800万ドル（約642億円）
メタの株価は330ドル前後とほぼ同水準だ。株価が回復したために売却を再開した
2月16日の約15万株から28日には23万株
「ザッカーバーグ氏がメタ株が高くなりすぎたとみて売りを増やした可能性がある」
アマゾンのベゾス氏の売りは2月8日から20日までに約5000万株、総額85億ドル 21年以来
JPモルガンのジェイミー・ダイモンCEOは2月22日、自社株82万株、金額にして1億5000万ドルを売却
ザッカーバーグ氏やベゾス氏、ダイモン氏はSECに自社株売却計画を提出し、売却
ダイモン氏は昨年10月にSECに提出した書類で24年に保有する自社株を最大100万株売却計画
今回も、自社株売りの増加は主要な株価指数が最高値圏にある米国株相場が「天井」に近づいているシグナル
「経営者などは業種や企業の知見が投資家よりも深く、その価格帯で売ることには意味があると考えられる」
USスチール、CEOが暗示した買収価格
日本製鉄による買収で合意した米USスチール。デビッド・ブリットCEOが合意できる買収価格の水準を「暗示」
ブリットCEOが昨年6月初旬にSECに提出した売却計画書では、USスチール株が49.87ドルまで上昇したら売却
当時の株価は22ドル台
12月18日、1株55ドルで日本製鉄による買収を承諾 自社株を50ドルで25万株売却
→トランプが反対したね。
https://thinkit.co.jp/article/18240
コンテナを中心にした技術をより有効活用するためのアーキテクチャ(構造)
「マイクロサービス」と「サーバーレス」
サービスの分割や開発者によって作られるアプリケーションの開発手法
マイクロサービスアーキテクチャとは
アプリケーションをある程度の細かな機能単位で分割し、独立して起動・停止できる「マイクロサービス」
つなぎ合わせて連動して動く「マイクロサービスアーキテクチャ」
独立して開発してデプロイ、単一機能の変更が他のサービスに影響しない(いわゆる疎結合)
独立してスケールできるため、単一機能のサービスのみ処理性能を高める
スピーディな開発と変更により、
ビジネスの状況変化に素早く対応でき、
必要な時に必要な分だけ開発の人的リソースやアプリケーションを動かすための環境、
つまり物的リソースに適材適所で投資
マイクロサービスの課題
サービスの規模が大きくなり、個々のサービス(機能)間の通信が複雑化
サービス間通信における通信の暗号化や認証・認可の機能
KubernetesではPod間やNode間の通信はデフォルトでは暗号化されていない
複雑化したサービス間の依存関係などの影響範囲を事前に調べ、テストして実装する
個々の要件に応じてサービス間通信をセキュアにすることはとても難しくなる
サービスメッシュとは
マイクロサービスアーキテクチャにおけるサービス間通信の課題を、
個々のサービス内のコードを書き換えて解決しよう
膨大な開発工数が必要で現実的でない。
個々のサービス内通信に制御周りの機能を実装するのではなく、
通信制御に関する専用のレイヤを追加することでサービス間接続の管理を実現させよう
ソフトウェアとして「Istio」「Linkerd」「Consul」などが挙げられます。ここでは、これら3種の中でも最も知名度の高いIstioを紹介します。
Istio
Istioは、ライドシェアサービスを展開するLyft社が社内システムの構築用に開発した「Envoy」をベースに、GoogleやIBM、Lyftの3社が協力して開発したサービスメッシュのオープンソースプロジェクト
Istioの大きな特徴は、KubernetesのPodごとにEnvoy(Proxy)をサイドカーとしてデプロイする
Pod間通信を全てEnvoy経由で制御し、管理できる
サイドカーはKubernetesのPod内で主たるコンテナを補助する役割を持つ別のコンテナを同居させる構成パターン
マイクロサービス、ネットワーク制御を個々のサービスで対応するのではなく、ネットワークプロキシで実現させる
コンテナの入れ替わりで動的に変わるIPアドレスなどの接続先情報をサービス自身が意識しなくても良く
通信先が変わってもアプリケーション側のコードを変更せず、Envoy側で接続先情報を更新するだけで済む
開発者はサービス間接続に関する課題から開放
Envoyにはロードバランシングやトラフィックのモニタリング
Istioにおけるサービスメッシュはコントロールプレーンとデータプレーンの2つ
データプレーンでは、各サービスにサイドカーとしてEnvoyをデプロイして、
マイクロサービス間での全ての通信を仲介、制御
全てのトラフィックに関する各種統計情報を収集
コントロールプレーンでは「Istiod」というコンポーネントによって
プロキシやトラフィックルーティングなどの設定や管理
トラフィックマネジメント、セキュリティ、可観測性の3つの主要機能
トラフィックマネジメント機能
トラフィックの宛先に関するルーティングや負荷分散方式などのトラフィック処理方法の制御、
サービスメッシュ内外へのインバウンドおよびアウトバウンドトラフィック管理
タイムアウトやリトライ、
サーキットブレーカー
(同時接続数や呼び出し失敗回数を定義して制限に達すると、それ以上の接続を停止させる機能)
障害復旧ポリシーを定義、アプリケーション全体の障害回復能力をテスト
セキュリティ機能
IDやポリシー、TLS暗号化、認証・認可、監査ツール
サービスとデータを保護
可観測性機能
サービスメッシュ内通信の全てのテレメトリを生成
テレメトリには3種類あり、
プロキシレベル、サービスレベル
トラフィックの全体量やエラー率
要求の応答時間などの情報を提供する「メトリクス」や
サービスメッシュ内を通過するリクエストを監視して
サービスの依存関係やレイテンシの原因を把握するために利用できる「分散トレース」
サービスメッシュ内トラフィックのアクセスログを生成する「アクセスログ」
サービスメッシュコントロールプレーンを使用すると、
Kubernetesなどによるマイクロサービスアーキテクチャが抱える
サービス間通信の課題を解決できる
サーバーレスアーキテクチャと
FaaS(Function as a Service)
「サーバーレス」には「広義のサーバーレス」と「狭義のサーバーレス」の2種類
利用者側はリソースを意識せず、クラウドベンダーが提供するマネージドサービス利用する
クラウドベンダー側がそのサービスを動かすためのサーバを管理
「サーバーレスコンピューティング」「FaaS(Function as a Service)」
Functionは関数で、ITの世界では入力した値に対して処理を実行し、結果を返してくれるプログラムの部品
入力イベントを起点としてプログラムの処理がクラウド上で実行されるサービスがFaaS
AWSの「Lambda」、Googleの「Cloud Functions」、Microsoftの「Azure Functions」
クラウドベンダーに依らない
サーバーレスアーキテクチャ
リソース(サーバやストレージなど)をユーザが意識しなくても良いFaaSはクラウドとの相性が抜群
提供するクラウドベンダーのサービス仕様
(サービスのスペック、アプリケーションのデプロイ方法、管理方法、実行環境のバージョン)
「どの環境でも動かすことができる」サーバーレスアーキテクチャを実現が「Knative」
Knativeはシステム基盤がオンプレミスでもクラウドでも、サーバーレスアーキテクチャを提供できないサードパーティのデータセンタでも、Kubernetesが作れる環境であれば同じ条件で動かすことができる
Knative
Knativeを使用することで、以下のようなことを実現できます。
Deployment、Serviceなど複数のKubernetesリソースの設定が1つで完結
長時間使用していないサービスを0個にスケールイン
同一リクエストを複数のコンテナに対してトラフィック分割が可能
クラスタ内でコンテナをビルド
Pub/SubトピックへのPublishイベントを検知してコンテナでメッセージを処理
Knativeを使えば、アプリケーション開発者にとって単調で難しいビルドやデプロイ、管理など、の作業から解放され、コーディングに集中することができます。
次に、Knativeの主なコンポーネントを紹介します。以前は、図10のように3つのコンポーネントが存在していました。
図10：Knative概要
「Knative Build」は「Tekton」という名前のCI/CDパイプラインツールとして独立して存在するようになり、現在のKnativeでは「Knative Build」「Knative Serving」と「Knative Eventing」のみで構成されます(※Tektonを含めた3つのCI/CDパイプラインツールを組み合わせてサーバーレス環境を作り上げるため、最後にTektonも併せて取り上げます)。また、これらのコンポーネントはKubernetesの拡張リソースであるCRD(Custom Resource Definition)で組み立てられているため、他のKubernetesのリソースのマニフェストと同じようにYAML形式で記述できます。
それでは、各コンポーネントについて説明していきましょう。
・Knative Serving
Knative Servingを支えているのはIstioです。Istioの通信制御や認証・認可の機能によりサービス間接続を制御し、コンテナのアプリケーションと関数のデプロイをサポートします。またKnative Servingは簡単に開始でき、高度なシナリオをサポートするように拡張もできます。
Knative Servingで実現できることをまとめると、図11のようになります。
図11：Knative Serving
その中で「0個～N個へのオートスケーリング」が特徴的で、アプリケーションに全くリクエストが来ない状態が続くと、アプリケーションのPod自体が1個も立ち上がらない状態になります。0個の状態で再びアプリケーションへのリクエストが発生すると改めてPodが立ち上がるのです。
・Knative Eventing
Knative Eventing イベント処理を実現
KnativeをFaaSのようにイベント受信を契機に処理を実行させる
Knative Eventingはイベントソースとイベントコンシューマ、
汎用的なイベント連携インターフェースを備え
各イベントのデータはイベントソースからBrokerへ送信
別途設定するTriggerにより適切なConsumerへ振り分けて転送
Knative Eventingは「CloudEvents」というCNCFで定義された
クラウドで発生するイベント
通知するための標準仕様に準拠
様々なサービス同士の疎結合性を高める
・Tekton
Tektonは、CI/CDパイプラインをKubernetes上で実行する
「Tekton Pipelines」としてCDF(Continuous Delivery Foundation)というCI/CDを標準化する組織で開発
Tektonは、単位でパイプラインを組む、再利用性が高い
Step : Pod内で実行するコマンドを定義
Task : 複数のStepをまとめて単一のPod内に処理フローを定義
Pipeline : 複数のTaskをまとめて処理フローを定義
3つの関係性
パイプラインのインプットを定義する「PipelineResource」
Taskのみの実行を定義する「TaskRun」
Pipelineの実行を定義する「PipelineRun」を組み合わせる
コンテナのビルドやテストを実行
イメージをレジストリにPushしてリリース
や難しめの「マイクロサービス」と「サーバーレス」
コンテナがどのようなもので、どこでどうやって使われるか
触って動かしてみる
Dockerを触り、
Kubernetesでコンテナの管理を実感し、
アプリケーション開発にもコンテナを取り込む
様々なシステムにも少しずつコンテナが使われ
コンテナを身近な存在として積極的に扱う
1985にデータベースと言う感性が飛び交い、ドキュメンテーションのデリバリーシステムとして
様々な情報をコンテナの入れ物に運ぶと言うコンセプトが議論されていた。
SNAの通信手段がスタートストップやBSCから、VTAMと言うアクセスメソッドに対して
TCP/IPと言う軍事技術からインターネットの技術が生まれたように、
2005ー2024 は全くコンピューターを勉強していないが、久し振りに読むと
2013のCatalinaMACosを使っている身には楽しめるなあ。とくにクラウド環境を少し学ぶ気になる。
コンテナをさらに活用しよう! 「マイクロサービス」と「サーバーレス」
2021年4月6日(火)
日暮 哲（ヒグラシ サトシ）
へえ、面白い。コンテナアーキテクチャで検索して読めた。
みずほ銀行の大トラブルのとき朝日の記者が質問し、その後話されたことはないが、
こんな思想で３銀行を統一したため、と説明できなくもない。
ユーチューブやフェースブックを利用すると個々の事実は思い当たる。
ゆっくり解説して行きたい。
→アプリレーヤーを２層にする、従来の７レイヤーのインプリメンテーションが全く違うだろうね。
→ソニー銀行と富士通がマイクロアーキテクチャと呼んで居たが到底無理だろうね。取りやめたね。
勘定系の現場に必要性がないのだろうね。
フェースブックやXでの金融犯罪広告の多さにウンザリだが、騙される人を救う思想はないなあ。
日本IBMがITゼネコンとして参画している、みずほ銀行や三菱UFJ銀行にも犯罪に立ち向かう思想が
つくづく欠けていると感じる。アメリアの銀行業界でATM還付詐欺なってあるのだろうか？
まず、老人が騙されて振り込む社会風土がないのか。
それに財界が不思議な程に左翼化して、電気代に寄生する太陽光発電など、既に滑稽を通り過ぎている。
株価も一種の仮想マネーだね。暗号通貨よりマネーだろう。
【ニューヨーク=伴百江】米企業の経営者が自社株の売り
今年に入り、メタ・プラットフォームズのマーク・ザッカーバーグ最高経営責任者（CEO）や
アマゾン・ドット・コム創業者のジェフ・ベゾス会長などが相次いで大規模に売却
株式相場の「天井シグナル」との見方。
昨年11月1日から12月末までの売却は約128万株、総額4億2800万ドル（約642億円）
メタの株価は330ドル前後とほぼ同水準だ。株価が回復したために売却を再開した
2月16日の約15万株から28日には23万株
「ザッカーバーグ氏がメタ株が高くなりすぎたとみて売りを増やした可能性がある」
アマゾンのベゾス氏の売りは2月8日から20日までに約5000万株、総額85億ドル 21年以来
JPモルガンのジェイミー・ダイモンCEOは2月22日、自社株82万株、金額にして1億5000万ドルを売却
ザッカーバーグ氏やベゾス氏、ダイモン氏はSECに自社株売却計画を提出し、売却
ダイモン氏は昨年10月にSECに提出した書類で24年に保有する自社株を最大100万株売却計画
今回も、自社株売りの増加は主要な株価指数が最高値圏にある米国株相場が「天井」に近づいているシグナル
「経営者などは業種や企業の知見が投資家よりも深く、その価格帯で売ることには意味があると考えられる」
USスチール、CEOが暗示した買収価格
日本製鉄による買収で合意した米USスチール。デビッド・ブリットCEOが合意できる買収価格の水準を「暗示」
ブリットCEOが昨年6月初旬にSECに提出した売却計画書では、USスチール株が49.87ドルまで上昇したら売却
当時の株価は22ドル台
12月18日、1株55ドルで日本製鉄による買収を承諾 自社株を50ドルで25万株売却
→トランプが反対したね。
https://thinkit.co.jp/article/18240
コンテナを中心にした技術をより有効活用するためのアーキテクチャ(構造)
「マイクロサービス」と「サーバーレス」
サービスの分割や開発者によって作られるアプリケーションの開発手法
マイクロサービスアーキテクチャとは
アプリケーションをある程度の細かな機能単位で分割し、独立して起動・停止できる「マイクロサービス」
つなぎ合わせて連動して動く「マイクロサービスアーキテクチャ」
独立して開発してデプロイ、単一機能の変更が他のサービスに影響しない(いわゆる疎結合)
独立してスケールできるため、単一機能のサービスのみ処理性能を高める
スピーディな開発と変更により、
ビジネスの状況変化に素早く対応でき、
必要な時に必要な分だけ開発の人的リソースやアプリケーションを動かすための環境、
つまり物的リソースに適材適所で投資
マイクロサービスの課題
サービスの規模が大きくなり、個々のサービス(機能)間の通信が複雑化
サービス間通信における通信の暗号化や認証・認可の機能
KubernetesではPod間やNode間の通信はデフォルトでは暗号化されていない
複雑化したサービス間の依存関係などの影響範囲を事前に調べ、テストして実装する
個々の要件に応じてサービス間通信をセキュアにすることはとても難しくなる
サービスメッシュとは
マイクロサービスアーキテクチャにおけるサービス間通信の課題を、
個々のサービス内のコードを書き換えて解決しよう
膨大な開発工数が必要で現実的でない。
個々のサービス内通信に制御周りの機能を実装するのではなく、
通信制御に関する専用のレイヤを追加することでサービス間接続の管理を実現させよう
ソフトウェアとして「Istio」「Linkerd」「Consul」などが挙げられます。ここでは、これら3種の中でも最も知名度の高いIstioを紹介します。
Istio
Istioは、ライドシェアサービスを展開するLyft社が社内システムの構築用に開発した「Envoy」をベースに、GoogleやIBM、Lyftの3社が協力して開発したサービスメッシュのオープンソースプロジェクト
Istioの大きな特徴は、KubernetesのPodごとにEnvoy(Proxy)をサイドカーとしてデプロイする
Pod間通信を全てEnvoy経由で制御し、管理できる
サイドカーはKubernetesのPod内で主たるコンテナを補助する役割を持つ別のコンテナを同居させる構成パターン
マイクロサービス、ネットワーク制御を個々のサービスで対応するのではなく、ネットワークプロキシで実現させる
コンテナの入れ替わりで動的に変わるIPアドレスなどの接続先情報をサービス自身が意識しなくても良く
通信先が変わってもアプリケーション側のコードを変更せず、Envoy側で接続先情報を更新するだけで済む
開発者はサービス間接続に関する課題から開放
Envoyにはロードバランシングやトラフィックのモニタリング
Istioにおけるサービスメッシュはコントロールプレーンとデータプレーンの2つ
データプレーンでは、各サービスにサイドカーとしてEnvoyをデプロイして、
マイクロサービス間での全ての通信を仲介、制御
全てのトラフィックに関する各種統計情報を収集
コントロールプレーンでは「Istiod」というコンポーネントによって
プロキシやトラフィックルーティングなどの設定や管理
トラフィックマネジメント、セキュリティ、可観測性の3つの主要機能
トラフィックマネジメント機能
トラフィックの宛先に関するルーティングや負荷分散方式などのトラフィック処理方法の制御、
サービスメッシュ内外へのインバウンドおよびアウトバウンドトラフィック管理
タイムアウトやリトライ、
サーキットブレーカー
(同時接続数や呼び出し失敗回数を定義して制限に達すると、それ以上の接続を停止させる機能)
障害復旧ポリシーを定義、アプリケーション全体の障害回復能力をテスト
セキュリティ機能
IDやポリシー、TLS暗号化、認証・認可、監査ツール
サービスとデータを保護
可観測性機能
サービスメッシュ内通信の全てのテレメトリを生成
テレメトリには3種類あり、
プロキシレベル、サービスレベル
トラフィックの全体量やエラー率
要求の応答時間などの情報を提供する「メトリクス」や
サービスメッシュ内を通過するリクエストを監視して
サービスの依存関係やレイテンシの原因を把握するために利用できる「分散トレース」
サービスメッシュ内トラフィックのアクセスログを生成する「アクセスログ」
サービスメッシュコントロールプレーンを使用すると、
Kubernetesなどによるマイクロサービスアーキテクチャが抱える
サービス間通信の課題を解決できる
サーバーレスアーキテクチャと
FaaS(Function as a Service)
「サーバーレス」には「広義のサーバーレス」と「狭義のサーバーレス」の2種類
利用者側はリソースを意識せず、クラウドベンダーが提供するマネージドサービス利用する
クラウドベンダー側がそのサービスを動かすためのサーバを管理
「サーバーレスコンピューティング」「FaaS(Function as a Service)」
Functionは関数で、ITの世界では入力した値に対して処理を実行し、結果を返してくれるプログラムの部品
入力イベントを起点としてプログラムの処理がクラウド上で実行されるサービスがFaaS
AWSの「Lambda」、Googleの「Cloud Functions」、Microsoftの「Azure Functions」
クラウドベンダーに依らない
サーバーレスアーキテクチャ
リソース(サーバやストレージなど)をユーザが意識しなくても良いFaaSはクラウドとの相性が抜群
提供するクラウドベンダーのサービス仕様
(サービスのスペック、アプリケーションのデプロイ方法、管理方法、実行環境のバージョン)
「どの環境でも動かすことができる」サーバーレスアーキテクチャを実現が「Knative」
Knativeはシステム基盤がオンプレミスでもクラウドでも、サーバーレスアーキテクチャを提供できないサードパーティのデータセンタでも、Kubernetesが作れる環境であれば同じ条件で動かすことができる
Knative
Knativeを使用することで、以下のようなことを実現できます。
Deployment、Serviceなど複数のKubernetesリソースの設定が1つで完結
長時間使用していないサービスを0個にスケールイン
同一リクエストを複数のコンテナに対してトラフィック分割が可能
クラスタ内でコンテナをビルド
Pub/SubトピックへのPublishイベントを検知してコンテナでメッセージを処理
Knativeを使えば、アプリケーション開発者にとって単調で難しいビルドやデプロイ、管理など、の作業から解放され、コーディングに集中することができます。
次に、Knativeの主なコンポーネントを紹介します。以前は、図10のように3つのコンポーネントが存在していました。
図10：Knative概要
「Knative Build」は「Tekton」という名前のCI/CDパイプラインツールとして独立して存在するようになり、現在のKnativeでは「Knative Build」「Knative Serving」と「Knative Eventing」のみで構成されます(※Tektonを含めた3つのCI/CDパイプラインツールを組み合わせてサーバーレス環境を作り上げるため、最後にTektonも併せて取り上げます)。また、これらのコンポーネントはKubernetesの拡張リソースであるCRD(Custom Resource Definition)で組み立てられているため、他のKubernetesのリソースのマニフェストと同じようにYAML形式で記述できます。
それでは、各コンポーネントについて説明していきましょう。
・Knative Serving
Knative Servingを支えているのはIstioです。Istioの通信制御や認証・認可の機能によりサービス間接続を制御し、コンテナのアプリケーションと関数のデプロイをサポートします。またKnative Servingは簡単に開始でき、高度なシナリオをサポートするように拡張もできます。
Knative Servingで実現できることをまとめると、図11のようになります。
図11：Knative Serving
その中で「0個～N個へのオートスケーリング」が特徴的で、アプリケーションに全くリクエストが来ない状態が続くと、アプリケーションのPod自体が1個も立ち上がらない状態になります。0個の状態で再びアプリケーションへのリクエストが発生すると改めてPodが立ち上がるのです。
・Knative Eventing
Knative Eventing イベント処理を実現
KnativeをFaaSのようにイベント受信を契機に処理を実行させる
Knative Eventingはイベントソースとイベントコンシューマ、
汎用的なイベント連携インターフェースを備え
各イベントのデータはイベントソースからBrokerへ送信
別途設定するTriggerにより適切なConsumerへ振り分けて転送
Knative Eventingは「CloudEvents」というCNCFで定義された
クラウドで発生するイベント
通知するための標準仕様に準拠
様々なサービス同士の疎結合性を高める
・Tekton
Tektonは、CI/CDパイプラインをKubernetes上で実行する
「Tekton Pipelines」としてCDF(Continuous Delivery Foundation)というCI/CDを標準化する組織で開発
Tektonは、単位でパイプラインを組む、再利用性が高い
Step : Pod内で実行するコマンドを定義
Task : 複数のStepをまとめて単一のPod内に処理フローを定義
Pipeline : 複数のTaskをまとめて処理フローを定義
3つの関係性
パイプラインのインプットを定義する「PipelineResource」
Taskのみの実行を定義する「TaskRun」
Pipelineの実行を定義する「PipelineRun」を組み合わせる
コンテナのビルドやテストを実行
イメージをレジストリにPushしてリリース
や難しめの「マイクロサービス」と「サーバーレス」
コンテナがどのようなもので、どこでどうやって使われるか
触って動かしてみる
Dockerを触り、
Kubernetesでコンテナの管理を実感し、
アプリケーション開発にもコンテナを取り込む
様々なシステムにも少しずつコンテナが使われ
コンテナを身近な存在として積極的に扱う
