Tekton と Jenkins：Red Hat OpenShift の CI/CD パイプラインとしてどちらが優れているか

Tekton は Knative プロジェクトから発展し、その後、Red Hat OpenShift のあらゆるもののパイプラインで未来を担うものとして Red Hat が支援するようになりました。私は 2018 年に初めて Tekton のことを知ったのですが、そのときの私の反応は「いったいこれはどのような問題を解決するためのものなのか」というものでした。私は Jenkins のことをよく知っており、好んで使っています。ですから、十分に機能するものがあるのに新しいテクノロジーについて学ぶ必要を感じなかったのです。

Red Hat、2023 年 Gartner® Magic Quadrant™ のリーダーに選出される

Red Hat は、Gartner 2023 Magic Quadrant for Container Management において、実行能力とビジョンの完全性が最も高いと評価されました。

レポートを読む

多くの人に Tekton のどこが Jenkins より優れているのかを尋ねましたが、最もよく返ってきた回答は「Tekton はクラウドネイティブだ」であり、その後には大抵沈黙が続くか、話題がすぐに切り替えられました。そこで私は、明確な理解が得られることを期待して「クラウドネイティブ」の正確な定義を調べてみることにしました。 

2018 年に Cloud Native Computing Foundation (CNCF) が公開した定義は次のようなものです。「クラウドネイティブ・テクノロジーにより、組織は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの先進的で動的な環境で、スケーラブルなアプリケーションを構築および実行できる」

というわけで、特に新しいことはわかりませんでした。私には、何年も使い続け、特に問題なく機能するものに対して特に理由もなく固執する傾向があります。これまで私の信頼に応え続けてきた Jenkins に別れを告げるためには、隣の芝生は実際に青いという強い確信が必要でした。ですから、乗り換えるのであれば、Tekton には Jenkins よりもはるかに優れた何かがなければなりません。 

最終的に私は、OpenShift/k8s で使用するのであれば、Tekton は統合の面でより優れており、Jenkins では提供できない新しい可能性の扉を開くことができると結論付けました。

この記事の残りの部分では、これについてさらに詳しく説明します。私と同じような疑問を持っている人に、少しでも答えを提供できればうれしく思います。

私の Jenkins 使用経験

Jenkins は良いものですが、正直なところ、その古さは否定できません。登場したのは 2005 年頃で、それ以降ほとんど変わっていません。その最大の強みは、数多くのプラグインがあり、ほとんどのものと簡単に連携できることです。しかしこれは、逆に弱点にもなっていました。これらのプラグインはライフサイクルが不確定であるためです。プラグインに問題がある場合、できることはその回避策を講じることだけでした。 

Jenkins は Java ベースです。メモリーとプロセッサーを大食いすることで知られており、しかも、常時稼働させなければなりません。コンピュートリソースの総コストが高く、問題と見られることもあります。

コンテナが登場する前は、開発部門全体が単一の Jenkins サーバーを使用する「ビッグ」Jenkins が一般的で、これがボトルネックとなっていました。大きな負荷をかけると処理が重くなり、そういうときには「Jenkins に混乱が生じているから再起動が必要だ」などと言われることが少なくありませんでした。そうなれば、すべて最初からやり直しです。 

その後コンテナが登場すると、チームごとに Jenkins サーバーを立てて好きなように構成できるようになりました。しかし今度は、「Jenkins のスプロール」と呼ばれる別の問題が発生します。これらの Jenkins サーバーはすべて、ほとんどの時間は何もせずにそこにあるだけですが、それでも大量のリソースを消費します。各チームが伝播するパイプラインコードが多種多様なものであることは言うまでもありません。

ですから、フットプリントが小さく、分散して各チームが所持でき、かつすべてのパイプラインを同じように扱えるものがあれば便利です。この点には後でもう一度触れますので、覚えておいてください。

プロセスシーケンシング・モデルについて

ソフトウェアのシステムでは、成果を出すためにサービス呼び出しやプロセスステージのシーケンスを編成する方法が必要であり、そのための方法は 2 つあります。

1 つ目のパターンはオーケストレーションで、最も一般的なのはプロセスマネージャー・パターンです。

出典 (このファイルは、Creative Commons Attribution-Share Alike 4.0 International ライセンスの下でライセンスを取得しています)

プロセスマネージャーは、オーケストラの指揮者のような働きをします。「オーケストレーション」という表現はそこから出たものです。

Jenkins はこのパターンの一例です。Jenkins はプロセスマネージャー、つまり指揮者として動作します。プロセスは JenkinsFile を使用してコーディングし、それによって定義します。プラグインをベースにしたインタフェースを介して Jenkins から渡されたものは、それが何であれ、完了するとプロセスマネージャーに返され、それからプロセスの次のステージが開始されます。ほとんどの場合、これは同期的な動作のように見えます。 

「Refactoring to Patterns」(Krievky 著、2004 年) では、プロセスマネージャー・パターンは「本質的に脆弱」であると説明されています。その理由は、プロセスマネージャーを再起動すると、その時点で実行されているものはすべて失われるためです。ですから、とくに長時間にわたって実行されるプロセスでは、この設計はうまく機能しないことが知られています。 

続けて、2 つ目のシーケンシングパターンを見てみましょう。次の写真は、スタジアムで観客がウェーブをしているところを撮影したものです。

出典(このファイルは、Creative Commons Attribution-Share Alike 2.0 Generic ライセンスの下でライセンスを取得しています)

観客は 1 人 1 人がいつ立ち上がって手を挙げるべきかを知っており、誰かが指示しているわけではありません。大きなスタジアムではあまりにもいろいろなことが起こっており、オーケストレーションでは扱いきれません。これは、コレオグラフィーと呼ばれる、次のシーケンシングパターンの一例です。

オーケストレーションは、ほとんどの開発者が最初に採用する、わかりやすい設計です。コレオグラフィーはわかりやすさでは劣りますが、イベントと連携して極めてうまく機能する、全般的に大きく改善された設計です。

マイクロサービスを扱う際には、これは極めて重要となります。場合によっては何百ものサービスを順序付けて処理する必要があるからです。また同様に、立ち上げ、テスト、解体を行うタイプの、長時間実行が必要になるアクティビティをパイプラインで処理する場合、コレオグラフィーははるかに堅牢で実用的なモデルであると言えます。

Tekton パイプラインは個別のコンテナで構築され、その順序は K8s API サーバー上の内部 Kubernetes イベントを介して制御されます。これはイベント駆動型のコレオグラフィー・シーケンシング・タイプの一例です。単一のプロセスマネージャーは存在しないので、それが固まる、再起動される、リソースを大量に占有する、あるいは何らかの障害で停止することもありません。Tekton は、各 pod が必要に応じてインスタンス化し、パイプラインプロセスのどの段階であれ、それが担っている処理を実行できるようにします。処理が終了すると pod がシャットダウンされてリソースは解放され、別のことに使用できます。

疎結合と再利用による繰り返しの理想形

Tekton は、ソフトウェア・アーキテクチャで疎結合と呼ばれるものも体現します。下の、幼児向けの列車のおもちゃの写真をご覧ください。

「Toy train for wood tracks」、Ultra-lab 作。CC BY-SA 2.0 ライセンスの下でライセンスを取得しています。 

機関車と貨車は磁石でつながれているので、機関車だけで遊ぶことも、一部または全部の貨車を機関車とつなげて遊ぶこともできます。 

水色と黄色の貨車を入れ替えるなど、貨車の順序を変えることもできます。同じような編成をもう 1 つ持っていれば、片方の貨車を全部もう一方の編成にくっつけて「スーパー列車」を作ることもできます。

これが、「疎結合」がソフトウェア設計に最適なアーキテクチャである理由です。疎結合は本質的に再利用を促進し、これは Tekton の理念にも通底しています。一度構築してしまえば、コンポーネントはプロジェクト間で簡単に共有できます。

結合の話をしたところで、疎結合の逆、つまり密結合についても見ておきます。先ほどとは別のおもちゃについて考えてみましょう。

「09506_Pull-Along Caterpillar」、PINTOY^® 作。CC BY-SA 2.0 ライセンスの下でライセンスを取得しています。 

このイモムシのおもちゃもいくつかのパーツでできていますが、すべて固定されており、順序を変えることはできません。パーツの数を減らしたり、増やしてスーパーイモムシを作ったりすることはできません。パーツが 3 つのイモムシが欲しければ、親に頼んでそういう別のイモムシのおもちゃを買ってもらわなければなりません。

この例からは、密結合は再利用を促進せず、実際には重複を強制することがわかります。

もちろん、Jenkins パイプラインを疎結合にしてプロジェクト間でコードを共有することは可能です。しかしそれは自然にそうなるのではなく、パイプラインの設計に大きく依存します。 

別の方法として、1 つの Jenkins パイプラインをすべてのプロジェクトで使用することもできます。しかしこの方法には制限が多く、この画一的なアプローチではカバーしきれないプロジェクトがすぐに出てきます。つまり、その時点で「単一のパイプライン」という設計ではなくなります。 

Tekton は宣言型の性質を持っており、そのパイプラインは先ほどの列車のおもちゃの例とよく似ています。表面だけを見るならば、Tekton の上位レベルのオブジェクト「パイプライン」はおもちゃの機関車であると言ってもよいでしょう。パイプラインには一連のタスクが含まれており、これらは貨車です。パラメーターを変更して再利用するだけで、複数のパイプラインに同じタスクを処理させることもできます。つまり、疎結合のパラメーター化されたタスクがつながってパイプラインを形成します。Tekton は疎結合を強力に促進するので、再利用の機会が直接発生します。つまり、1 つのプロジェクトの作業を取り出して、別の場所につなげて使用することができます。

また、Tekton は Kubernetes オブジェクト定義に追加するだけなので、Everything-as-Code アプローチや GitOps との相性も抜群です。パイプラインコードは、他のクラスタ/Namespace 設定とあわせて簡単にクラスタに適用できます。 

重要である理由

これが重要である理由は、開発、テスト、UAT という形をとる環境がいまや旧時代の概念となっていることです。このような固定的な環境は、物理サーバーを購入してからその用途を決めていた時代にまで遡ります。 

これはすでに過去のものとなっています。今は OpenShift、Everything-as-Code、「ペットと家畜」議論の時代であり、そのような時代においては、パイプラインを使用して環境を動的にインスタンス化し、テストや実行に使用しない理由がありません。実行を完了したインスタンスは完全に破棄して、そのリソースはさらに別のテストなどに使用できます。 

ほとんどの企業は、まだここまでの段階に至っていません。その理由の 1 つとして考えられるのは、これまで利用されてきたツールがそうした用途にあまり適していなかったということです。

まとめ

世界はいまだ、OpenShift のようなテクノロジーが提供する、これまでできなかったあらゆる機会に追いつこうとしている段階にあります。 

コンピューティング・リソースが少なくとも夜間のほとんどの時間帯で何も処理していないことを考えると、より良いソフトウェアを提供するためにテストを自動化する機会は無限にあります。私は長い間このようなアイデアをいろいろ試してきましたが、Jenkins がこの種の作業に向いていると感じたことはありませんでした。オープンな姿勢で Tekton と出会ったとき、最適なツールであるとすぐに感じました。 

Tekton は、Kubernetes API およびセキュリティモデルと最初から統合でき、疎結合/再利用を強力に促進します。イベント駆動型で、コレオグラフィーモデルに準拠しているため、長時間実行されるテストのようなプロセスの制御に適しています。パイプラインアーティファクトは Kubernetes リソース (pod 定義、サービスアカウント、シークレットなど) であり、Everything-as-Code のアプローチにも簡単に適合しますし、他の k8s タイプのエコシステムとも連携できます。

各アプリケーションチームは独自のパイプラインコードを持ち、実行していないときには 0 にまでスケールダウンされるので、アイドル時の負荷なしで「分散 Jenkins」の利点を実現できます。Apache Maven は、ゲームチェンジャーであったため、短期間で大きな成功を収めました。これによって Java プロジェクトが厳格に管理され、開発者はプロジェクト間でビルド構成を簡単に把握できるようになりました。Tekton はパイプラインでこれと同じことを実現し、タスクの再利用を簡単かつ明瞭にします。

2000 年代初頭には Cruise Control が最初の CI ツールとして登場しましたが、個人的な経験から言えば、お世辞にも使いやすいと言えるものではありませんでした。その当時、Jenkins はそれ以前にあったものを大きく改善するツールに思えました。OpenShift/k8s が広く使われるようになった現在では、Tekton がパイプライン・テクノロジーの次のステップであると強く感じます。

詳細はこちら

• Red Hat OpenShift のクラウドネイティブ CI/CD