2004年にHudsonとして誕生しました。それ以来、Jenkinsはソフトウェア開発とデリバリーに関わる私たちにとってなじみの名前になり、今では継続的インテグレーションに加え継続的デリバリーツールのリーダーでもあります。現時点で2050万以上のJenkinsジョブがあり、20万近くのJenkinsサーバーが稼働しています。これは驚異的な数字です!この成長の間に、クラウドやコンテナ化など、技術的にも大幅な進歩がありました。そのため、Jenkinsはより優れた実装となる必要があり、私たちはそれを活用することに目を向けなければなりません。今日では、ほとんどの企業がクラウドを推進しているため、私たちはJenkinsを時代とともに進化させ、Jenkins自身のクラウドネイティブへの旅を進めることを望んでいます。エクスペリエンスを提供し続ける必要があります。Jenkinsは多大な成功を収めましたが、それには痛みも伴います。私たちが耳にしている大きな問題は次のとおりです。Jenkinsサーバーが単一障害点(SPOF)になっている。メンテナンスによるダウンタイム中にgitのwebhookイベントが失われる。Jenkinsサーバーでは、頻繁にディスク領域が不足するため、機能を維持し続けるためには、スクリプトや手動によるクリーンアップが必要である。プラグインのバージョンが合っていないと、アップグレード時に競合が発生する可能性がある。マルチブランチプラグインのスキャンによるGitHubのレート制限。大きなメモリを必要とする大規模なJava仮想マシン(JVM)は、使用量ベースの価格設定では、ビルドが実行されていない場合にも不必要なコストが発生する。そこで、もし以下が可能となるとどうなるでしょうか。ビルドが要求され、パイプラインを実行するときにだけJenkinsを動かし、クラウドの使用料金を減らす。ビルドが完了したら、一時的なパイプラインエンジンを破棄し、ファイルシステムがいっぱいになってディスクスペースが不足するのを防ぐ。継続的インテグレーションで、新しいプラグインやプラグインのアップグレードを検証する。高可用性とスケーラブルなWebhookハンドラーを提供して、SPOFに対処する。APIのスキャンを避け、レ​​ート制限のリスクを軽減する。すべてのジョブ設定をGitに保存し、障害リカバリー戦略を可能にする。CDとして発表されました。>プロダクション)自動GitOpsプロモーション機能を備えています。definitions)を使用してKubernetesを拡張し、Jenkinsサーバーおよびパイプラインをオーケストレーションします。Jenkinsを発表しました。Jenkins、静的なJenkinsマスター、またはチームごとのKnativeビルドのいずれもオーケストレーションできるようになりました。Jenkinsは、広く支持されている革新的なオープンソースプロジェクトを使用して、上記のような静的Jenkinsマスターの問題を解決します。Buildに焦点を当てたいと思います。Jenkinsが実際に動いているところをデモしている未編集のYouTube録画へのリンクがあります。ProwとはProwはKubernetesエコシステムから生まれました。リポジトリでJenkinsを使うのに苦労していたときに開発したものです。ProwはKubernetesの140のリポジトリすべてに加えて、IstioとJetstackでも使用されています。Prowは個別の機能を担当する多数のマイクロサービスから構成されたイベントベースのソリューションであり、クラウドネイティブアーキテクチャにとって理想的な、緩やかに結合されたアーキテクチャを提供します。Prowは、マスターへのマージ(プルリクエストビルドの実行前と実行後の両方の)を強力に制御することを可能にし、また、ChatOpsを使用してビルドシステムとやり取りします。CRDをKubernetesに書き込むことで、他のマイクロサービス(ProwJobイベントを監視するKubernetesコントローラー)がイベントに応じて継続的インテグレーションまたはデリバリーパイプラインを実行することを可能にします。Gitイベントは、新しいPRや課題、コメント、マージ、プッシュなどによってトリガーされるので、さまざまなトリガーに対処することができます。ラベルに基づくルールセットを指定し、プルリクエストを自動的にマージする機能もあります。このリポジトリを参照してください。Prowはジョブの設定をGitに保存します。障害からのリカバリーを行わなければならない場合も、すべてのCIジョブとCDジョブを復元できます。XプロジェクトはいつものようにProwを真っ先に自プロジェクトで採用し、検証してからユーザーに公開しました。Xプロジェクト自体のProw設定を参照できます。Buildも、やはりクラウドネイティブソリューションです。Buildは、KubernetesをCRDで拡張し、ユーザーがソースからアプリケーションをビルドする方法を提供します。Buildの画期的な特長の1つは、同じKubernetesポッドで順次実行される複数の単純なステップを組み立てて、異なるコンテナを使用して各ステップ間で状態を共有できることです。Kubernetesのinitコンテナを使用します。ビルドテンプレートは、ビルド実行用に作成されるKubernetesポッドのタイプを記述する方法です。ビルドテンプレートを使用すると、ビルドを実行するDockerイメージ、ビルド時に必要な環境変数やサービスアカウント、シークレット、マウントする必要があるボリューム​​を指定できます。Xのリリースごとに自動的にアップグレードされます。Xによって生成されるProw設定は、ビルドテンプレートを参照します。Jenkinsとは何かを見てみましょう。Jenkinsの取り組みの一部です。Xを使用すると、ProwとKnativeが自動的にインストールされ、設定されます。リポジトリのwebhookエンドポイントを更新します。Jenkinsfileを使用してアプリケーションビルドパイプラインを実行します。ビルドが完了すると、Jenkinsfileランナーポッドは破棄されます。(CWP)を利用して、必要なビルドツールを含むさまざまな種類のJenkinsサーバーを構築します。言語検出機能により、適切な種類が使用されます。(CasC)を使用します。Jenkinsが起動するときではなく)にJenkinsプラグインを抽出することです。XベースのJenkinsイメージのコンテナおよびJVMの起動に要する時間は5秒未満です。JenkinsサーバーをKubernetesで起動する場合は数分かかることもあります。Xのリリースのたびに、monorepoを使用して、これらの言語固有のJenkinsイメージが自動的にビルドおよびリリースされます。これは、私たちのプラグインがyamlで定義され、Gitに保存されているので、私たちのCI/CDツールの開発にCI/CDを適用できるということも意味します。プラグインをアップグレードしたい場合、プルリクエストを作成すると、それをトリガーとしてCIが開始され、プレビュー用Jenkinsイメージをビルドするので、そこでプラグインの競合がないことを確認するとともに、自動テストとしてモックジョブを実行することもできます(この部分はまだ現実化されてはいませんが)。Jenkinsイメージを構築し、同じようにパイプラインで使用することができます。Jenkinsに切り替えると、ビルドとビルドの間で状態が保存されないことです。各ジョブのビルド番号は常に1になります。PipelineActivity用のCRDを作成するので、次のビルド番号を生成することができます。ビルドに関する情報も保存できるので、Jenkinsのシングルショットのビルドが完了した後、パイプラインの以前のビルドを視覚化できます。Prowがwebhookイベントを受信すると、KubernetesにKnativeビルドリソースが作成されます。コードをクローンするinitコンテナを自動的に追加します。Jenkinsfileランナーを利用して、シングルショットのJenkinsを別のステップで起動し、Knativeによってクローンされたソースコードにアクセスし、アプリケーションのJenkinsfileを処理します。terraformを使用してGKE上にクラスターを作成したとき、デフォルトでProwが含まれています。clusterコマンドまたはinstallコマンドで機能フラグを使用した場合も同様です。これは非常に重要な点なので、もう少し詳しく説明しましょう。Xの開発者にとって使いやすいIDEとCLIのツールがあります。GUIはもうありません。Xとともにデフォルトでインストールされます。Q.ビルドログはどこにありますか?A.より良いソリューションはこれから開発されるところですが、今のところ、Jenkinsfileランナーはビルドログを標準出力に出力するので、Stackdriver、CloudWatchなどのKubernetesクラスターの集中ログソリューションを活用することができます。log`(数時間利用可能)も使用できます。MBP関連のすべての環境変数が同じ形式で追加されるようにしました。私たちが見逃しているものがあれば、どうぞお知らせください。Jenkinsを使用するように移行ました。Jenkinsに移動したのです。JenkinsXサイトのプルリクエストを見ると、実際の動作を確認できます。Xにインポートするときに追加されるものです)を使用していました。Jenkinsへの移行は、Jenkinsfileへのわずかな調整だけで済みました。エージェントタイプを「any」に変更して、パイプラインが一時的なワンショットJenkinsで実行されるようにします。すべてのJenkinsfileのコンテナブロックを削除します。すべてのステップがワンショットのJenkinsパイプラインエンジンで実行されることになるからです。'github/foo.git'に変更する必要があります。これは、Jenkinsワークスペースにリポジトリを追加するときにシンボリックリンクが使用されるらしく、cloneされたリポジトリをKnativeおよびJenkinsfileランナーから再利用するのに問題があるためです。この問題はいずれ修正したいと考えています。上記の変更の例は、ここで参照できます。IDを使用する同様のOWNERSファイルも必要です。現在のところはGitHubのみがサポートされています。他のGitプロバイダーのサポートも行われる予定です。Xは、デフォルトで宣言型パイプラインJenkinsfilesを作成します。スクリプト型Jenkinsfileおよび共有ライブラリJenkinsfileパイプラインではテストされていません。私たちは、これらが期待通りに機能するかどうかについてのフィードバックを求めています。PodTemplatesはまだサポートされていません。サポートするべきかについても、結論は出ていません。{...}ブロックを持つ既存のJenkinsfileを移行する場合は、上のCWPで作成したシングルショットのJenkinsに各コンテナのビルドツールを追加する必要があります。roomsに顔を出して、課題を手伝ってください。試してみて、どんな感じかを教えてください。ChatOpsを使用して静的、サーバーレス、またはKnativeのビルドジョブをオーケストレーションするチームのためのワンストップショップであり、Kubernetesワークロード用の自動化されたCI/CDが付属しています。