【CloudBees CI奮闘記】第1章：モノリシックなJenkins?野良Jenkins?

これまでCI奮闘記として、「Jenkinsを用いてCI環境を構築するには？」という内容のブログを記載してきました。これまでのCI奮闘記はこちらからご覧ください。

Jenkinsは世界中で人気があるフリーでオープンソースの自動化サーバーです。そのため気軽に運用を開始することができ、Jenkinsの豊富な機能やプラグインを用いることで環境を発展させていくことが可能です。その一方でJenkinsの運用を進めていくうちに課題も発生してくることがあります。
今回からはCloudBees CI奮闘記として、Jenkinsを利用していると発生し得る課題の紹介をしながら、それらを解消するエンタープライズ機能を強化した有償版JenkinsであるCloudBees CIの紹介を行っていきます。

はじめに

登場人物

吉田：転職したてのエンジニア。前職では積極的にCIやCDに取り組みながら開発をしていた。CI奮闘記では服部に色々アドバイスを行った。

服部：元々CIやJenkinsについては言葉は聞いたことがある程度であったが、吉田からのサポートをうけつつCI環境の導入担当として日々奮闘している。CI奮闘記では自部署にJenkinsを導入した。

モノリシックなJenkins？

服部さん。最近Jenkinsの調子はどう？いろいろな機能を使えるようになってきた？

はい！おかげさまでCIは軌道に乗ってきたと思います！
開発のみんなもJenkinsを利用することに慣れてきて、今までの手動でビルドだったりデプロイをしていた頃には戻れないって言っていました。

最初は新しい仕組みの導入で混乱した人もいたようだったけど、ここまで利用が広がったのは服部さんの粘り強い説明の賜物ね。

ビルドやデプロイだけじゃないんです。自動テストも勝手に行ってくれるようになったので、開発の方からもすぐ実行結果が確認できて便利と言ってもらえました。いい傾向だってマネージャーの溝口さんが言ってました。

すぐフィードバックを得ることができるのもCI環境いいところだものね。しっかりCI環境を生かして開発できているようで良かったわ。

他のプロダクトの開発者もそんな評判を聞きつけてどんどんJenkinsのジョブも増えてきているんです。本当に着手してよかったなぁと思います。

すごいじゃない。まぁ開発者は手動デプロイとかじゃなくて開発に集中したいものね。これで他の部署の開発効率も上がってくれるといいわね。

そうですね！ただ…どんどん構築したJenkinsを使ってもらえるのはうれしいんですがここのところ少し問題も出始めてきていまして。

あら、どうしたの？

色々な部署の皆さんが利用してくれるのはいいんですが、これ見てください。ジョブの数がすごい量になってしまってこれをメンテナンスするのも最近少し大変になってきまして

本当ね。ビューをうまく使って工夫してはいるもののタブの量も馬鹿にならない量になっているわね…。このまま行ったらもっとぐちゃぐちゃになってしまいそう。

それ以外にもですね、利用ユーザーが増えてきたので社内のActive Directoryを利用した認証に切り替えたのですが、ある部署では協力会社さんも使いたいらしくて。それでも社内のActive Directoryに外部の方を登録するわけにもいかず、かといって今更Jenkinsのユーザーデータベース認証に戻すわけにもいかず、一時的にプロパー社員のアカウントで利用されているみたいで。

それはセキュリティ上あまりよくないわね。

それにいろいろな部署のジョブが一気に並行して実行されると、若干実行速度が遅くなっているような気もするんですよね。あと万が一このJenkinsが止まってしまうと色々な部署に影響が出ちゃいますよね。それもちょっと怖くて。

なるほどなるほど、Jenkinsの利用が促進されたのはいいことだけど、モノリシックなJenkinsの問題点がどんどん顕在化して来たというわけね。

なんですか？そのモノリシックなJenkinsって。

モノリシックなJenkinsとは

モノリシックなJenkins

モノリシックなシステムとは、要素が分割されていない全体が一体となったシステムのことを指します。モノリシックJenkins (つまりひとつのJenkinsに集約された環境)を運用していても、少数のメンバーのみが利用するのであればあまり大きな問題にはなりません。しかし、利用者が増えていき複数のチームが同じ環境を使うようになると様々な問題が顕在化していきます。

問題例

パフォーマンス
大量なジョブが日常的に実行されている場合、パフォーマンス面で問題になる場合があります。最悪のケースではJenkinsコントローラーが利用できるマシンリソースをオーバーし、Jenkinsが異常終了するという事も起こり得ます。
単一障害点
また大量の開発者やプロジェクトが1つのJenkinsに依存している場合、システムにダウンタイムが発生するとその影響は計り知れません。
影響範囲の増大
ある便利なプラグインを導入しようとした場合、特定のプラグインを利用しているチームに意図しない影響を与えてしまうことがあります。バージョンアップした際の影響範囲も同様です。セキュリティの観点から定期的にLTS(https://www.jenkins.io/download/lts/)へのバージョンアップを実施したほうが良い事は理解していても、二の足を踏んでしまうという事も考えられます。
セキュリティ
1つのJenkinsに情報を集約し、誰でもアクセスできてしまう状態はセキュリティとしてもましくありません。Jenkinsはツールの特性上、製品のビルド成果物やソースコードそのものにもアクセス可能な状態である場合が多いので、可能な限り分割したほうが良いでしょう。

対策と課題

パフォーマンスやセキュリティ、管理面などを考慮するのであれば、1チームにつき1コントローラーとして、ジョブ数も100を超えない程度にすることをCloudBeesはおすすめしています。そうすることで、ジョブの実行パフォーマンスは維持され、チーム間でプラグインやエージェントなどの競合も起きません。さらに何か問題が発生したときの影響範囲も小さく済みます。
ただし、このようにチーム毎にJenkinsを作成する際に、構築に時間がかかってしまうことは望ましくありません。Jenkins管理者はなるべく早く利用できる設定を実施した状態で提供する必要があります。

野良Jenkins？

なるほど。聞けば聞くほどまさに今自分がぶち当たっている問題ですね。

Jenkinsが利用されているということ自体はよい傾向ではあるんだけどね。

あ、あとほかにも気になっていることがあるんですよ。うちの部署のJenkinsの評判を聞きつけて導入した人がいるみたいなんですが、どうにもバージョンアップ等されずにそのまま使われているみたいなんです。

それはちょっと怖いわね。確かにバージョンアップしなくても見かけ上使えてしまうけど、2021年12月に起きたApache Log4jの問題の時みたいに対応が必要な場合もあるから、なるべくなら日常的にJenkinsやプラグインのバージョンは上げておきたいわね。

あの時は利用しているすべてのプラグインを確認して少し大変でしたね。あの時は自分が管理しているJenkinsはこの1つだけだったのでそこまで時間はかかりませんでしたが、もっとたくさんあったらあの対応も結構時間かかったと思うんです。あとその時調べて改めてわかったのですがプラグインも長い間メンテナンスされていないものだったり品質がまちまちだったりするじゃないですか。

Jenkins自体の歴史が長いからね。仕方ない部分もあるかもしれないけど、昔はよくつかわれていたプラグインだけど今は放置されていて利用を避けたほうが良い…みたいなプラグインもありそうね。

他の部署のJenkinsなので僕が気にすることでもないかもしれないんですが、Jenkinsを広げた張本人として少し気になってしまいまして。

Jenkinsは製品やソースコードそのものに深くかかわる分、セキュリティ面が気になるのは当然よね。

それに僕は吉田さんにいろいろ教わりながら運用を開始できたのでエージェントを使っての分散ビルドとかきちんと考えながら構築できましたが、なんとなく手探りで作られた非効率なJenkinsも多いと思うんです。

CI環境に組み込むツールのライセンスをJenkins毎に用意してしまって必要以上にコストがかかっているという事もありそうね。Jenkinsが広がっていくと確かにそういった野良Jenkins問題も出てくるわよね。

野良Jenkins…。これもさっきのモノリシックなJenkinsと同じようによくある問題なんですか？

野良Jenkinsとは

野良Jenkins

各チームがそれぞれの開発に合わせてJenkins環境を構築している場合、モノリシックJenkinsの問題はあまり発生しません。しかし、新たな課題としてJenkins環境が乱立して組織としてうまく管理できない、いわゆる野良Jenkinsの課題がうまれてきます。

問題例

管理コストの増大
開発チームがそれぞれに自分たちのJenkins環境の設定、管理を行っていくことになるため、貴重な開発者のリソースが無駄に費やされてしまいます。
良いプラクティスのサイロ化
どこかのチームで優れた運用方法がすでに確立されていても、各Jenkins環境がサイロ化してしまっているため共有されることがありません。
セキュリティリスク
各チームがセキュリティ脆弱性が発見された古いJenkinsの利用、問題の有るプラグインを利用、チームではセキュリティスキャンなど適切なコンプライアンス対応を行っていない、などの状態が起きている場合でも、個々のJenkinsコントローラーの状況を管理者側から見て取ることはできません。

対策と課題

このような状態では、企業全体でJenkins環境管理に大きな無駄な管理コストがかかっていることが多く、また、セキュリティや安定性においてもさまざまなリスクを抱えることになります。Jenkinsを社内で広く運用していくためには、スケーラビリティの高いJenkins環境の構築や、社内のJenkins運用方法の確立、また全体のJenkins環境を監視・コントロールするしくみが必要になります。
しかしJenkinsの標準機能だけでは実現できない問題があります。例えば1つのエージェントを複数Jenkinsコントローラーから共同利用はできないため、ツールのライセンスをJenkinsコントローラー分複数購入している方もいるのではないでしょうか。

まとめ

モノリシックなJenkinsと野良Jenkins…。解決は大変そうですね…。うまいこと運用回避で対応していくしかないのでしょうか。

運用回避で対策していくこともできるとは思うけど、せっかく開発効率を向上させるためのCI/CDなのに運用やツールのメンテナンスコストで時間がかかってしまっては本末転倒感があるから仕組みで解決していきわね。

何か対策はあるのでしょうか。

そうね。私も最近知ったんだけど有償版のJenkinsで、今まで以上に組織としてJenkinsを効率的に使っていくためのCloudBees CIという製品があるみたいなの。

よりエンタープライズ向けのJenkinsということですか？興味あります！

そうしたらどういった事ができるのか、いま生じているモノリシックなJenkinsや野良Jenkinsという問題をどう解決していくことができるのかという点について一緒に学んでいきましょう。

今回は「モノリシックなJenkins」と「野良Jenkins」というJenkinsを活用すると直面しやすい課題について触れました。それ以外にも例えば「フリーでオープンソース」という事がメリットである一方、問題が発生した際に直ちにトラブルシューティングしてくれるサポートがないというデメリット等もあるかと思います。
これから複数回に分けて、そもそもCloudBees CIとは何か、Jenkinsで発生しがちな問題とCloudBees CIであればどう解決していくことができるのか、といった説明を行っていきます。
是非Jenkinsをお使いの皆さんはご一読いただき、自社のCI環境の改善の参考にしていただければと思います。

CloudBees CIの製品ページはこちらから。

CloudBees CI (旧製品名：CoudBees Core)