Kubernetes時代のCI/CD Jenkins Xとは?-前編

2018年3月に Jenkins を開発している CloudBee から「Jenkins X」というプロダクトが発表されました。

https://jenkins.io/blog/2018/03/19/introducing-jenkins-x/

社内で検証する機会がありましたので、この記事では前後編に渡って、CI/CD の解説から、Jenkins X を実際に使うまでに必要となった道のりや、使ってみての感想を書いていきたいと思います。

CI とは?

CI とは、Continuous Integration (継続的インテグレーション)の略です。
インテグレーション、と一言で言われても初めて聞く人にとっては何のことやらわからないと思いますが、アプリケーション開発中にエンジニアが頻繁に実施する以下の様なことを指します。

  • ビルド

    • ex.) コンパイルしてエラーなくバイナリなどの成果物を得る
  • テスト

    • ex.) 開発したアプリケーションをテストするコードを作成し、テストに記載された通りの動きになることを確認する
  • lint

    • ex.) 開発チーム内で予め決めたコーディングルールに則って、コードが書かれていることを確認する

ある機能を開発する際に Git などのブランチを新規に作成してから開発する、という昨今では当たり前のフローを取っていた場合、インテグレーション作業を以下の様なタイミング・内容で行いたくなるはずです。

  • master ブランチにブランチがマージされるたびに、ビルド、テスト、lint の実行結果が正常であることを確認したい
  • ブランチを切ってコードをコミット・プッシュするたびに、逐一ビルド、テスト、lint が正常であることを確認したい
  • テスト実行時には、モックではなく本番と同様のミドルウェアへ接続した上で、統合テストを実施したい

このような作業は、作成するアプリケーションの品質を向上させる効果があるため、可能であれば全て実施するべきです。

しかし、これだけの量の作業を毎度開発する人たちが手動で実行するのはとても大変です。
人間が手動で全てを実行する場合、開発に利用している端末のリソースを取られるので開発が止める必要があるかもしれません。また手動で実行しなければならないので、実行すること自体をそもそも忘れてしまうかもしれません。統合テストを実施するために、毎回環境を準備する作業も必要になります。テストを実行する環境(OS のバージョン、ミドルウェアのバージョン…)が厳密には揃っておらず、実行結果が異なるものになるかもしれません…などなど

これらの作業を自動化して、開発スピードの向上、成果物の品質向上を継続的に実現できるようにするものが、CI です。

CI を実現するプロダクトは本記事でも紹介する Jenkins や、SaaS としてサービスしている Travis CICircle CI など様々なものがあります。

CD とは?

CD とは、Continuous Delivery (継続的デリバリ)の略です。
前項で説明した CI を実施しているアプリケーションに対して、さらに頻繁なデリバリ(リリース)の実施作業を追加することによって、以下の様な効用が得られる、というソフトウェア開発における手法の1つです。

  • 一回のリリースでの変更点が少なくなり、リリース作業のリスク、リリースに伴うコスト、時間を抑えられる

    • リリース作業の自動化が実現している = リリース作業の定型化ができているとなるため、コスト・時間を大幅に抑えられます
  • アプリケーションを任意のタイミングでリリースできるようになる

アプリケーションのデリバリを頻繁に実施できるようにするためには、そのアプリケーションに関して CI が実施できていることが必須条件となり、それに加えて開発環境や本番環境などの異なる環境へのデプロイも自動化、または人間が判断できるタイミングを設けて、方針の決定後に素早く実行できる状態にしておく必要があります。

上記のような CD を実現するプロダクトは、Jenkins のほかに、SpinnakerGoCD などがあります。

Jenkins とは?

最初は Hudson という名前で Sun Microsystems の配下で OSS として開発されていましたが、Sun Microsystems がオラクルに吸収された後の 2011 年に Jenkins という名称でフォークし、現在は CloudBee の配下で OSS として活発に開発されています。

Jenkins は CI を実現するプロダクトとして人気を博しており、以下のような特徴を有しています。

  • Java Servlet アプリケーションとして開発されており、war ファイル 1 つで起動できる

    • docker イメージも存在し、公式にメンテナンスされているため、起動は本当に簡単です。
  • Jenkins 起動後に設定した内容は 1 ディレクトリ内に全て収まるため、バックアップが非常に用意しやすい

  • GUI 操作によるジョブの設定やテストレポートの表示が可能

  • 設定するジョブに対して、柔軟な設定が可能

    • ex.) リポジトリが更新されたら/X時間ごとにジョブを実行する、ジョブ実行後にメールや Slack で結果を通知する、など
  • 豊富なプラグインによる機能拡張が可能

  • Jenkinsfile によるジョブのコード化(Infrastructure as Code)を実現可能

  • ジョブの設定次第で CD ツールとしても運用可能

    • SEROKU もプラグインやシェルスクリプトの実行の組み合わせで Jenkins による CD を実現しています
    • SEROKUを支える技術〜CI/CD編〜 でも紹介しておりますので、是非ご覧ください!
  • 動作が非常に安定している

    • 筆者の経験上の話ですが、ジョブの量が多かったり、プラグインが大量にインストールされていても、Jenkins 自体が原因で動作が不安定になったり遅くなったりしたところに遭遇したことがありません

Jenkins を CD ツールとして利用した場合の難点

上記で紹介した通り Jenkins は非常に柔軟で、CD ツールとしても利用可能ではありますが、実施したいことは自前でプラグインなりスクリプトなりを組み合わせてジョブとして設定する必要があります。

昨今流行している Kubernetes 環境への CI/CD を Jenkins で実現しようとした場合、以下の作業を自分たちで設定する必要が出てきます。

  • アプリケーションのビルド・テスト(CI)
  • Docker コンテナのビルド(CI)
  • コンテナレジストリへの push (CD)
  • Kubernetes クラスタのデプロイ (CD)

アプリケーションの開発者の範疇では、アプリケーションのビルド・テストまでは考えることができても、それ以外の項目を準備するのは非常に工数がかかる作業となってしまいますので、できればあまり手をかけずに準備できないものかと考えるはずです。

上記の問題を解消すべく、CloudBee が新たに発表したものが今回ご紹介する「Jenkins X」です。

Jenkins X とは?

Jenkins X は、以下のような環境でアプリケーションを開発する場合に限り、従来自前で考えて自動化しなければならない箇所をある程度簡単に実現できるようにしてくれます。

  • Git リポジトリでアプリケーションのソースコードをバージョン管理する
  • ビルドした成果物を Docker イメージ化する
  • 完成した Docker イメージを Kubernetes クラスタ上で稼働させる

Jenkins X には、従来の Jenkins に加えて以下の機能が標準装備されています。

  • Jenkins 以外に CD として扱う上で必要となるツールのインストール

    • Artifactory, Monocular, Nexus, Docker registry など
  • Git/Docker/Kubernetes を扱うためのプラグイン・Jenkins 設定のプリセット

  • Jenkins X を CLI から叩けるようにした jx

    • Kubernetes クラスタ・Jenkins X が動作する環境構築から、Jenkins X に設定したプロジェクトのビルド状況を確認するところまで CLI でできます

まとめ

本記事では、CI/CD 自体の解説、必要性から Jenkins/Jenkins X の概要について簡単に説明しました。

次回以降、実際に Jenkins X をインストールする手順を解説しつつ、何がインストールされるのか、どういう形で動くのかを記載していきたいと思います。

関連記事と中編

Kubernetes時代のCI/CD Jenkins Xとは?-中編

Kubernetes+Let’s Encryptでワイルドカード証明書の自動発行基盤を作る