【最終回】Kubernetes 時代の CI/CD「Jenkins X」とは？ 〜後編その2〜

いよいよ長期に渡り連載してきた本シリーズも最終回です！

後編その1 で予告した通り、前回作成した quickstart プロジェクト中のコードを修正し、production 環境へのリリース作業を実施し、最後に筆者が Jenkins X を実際に触って受けた印象を書いてみたいと思います。

[adinserter block="1"]

本記事では、前回の記事からの作業をそのまま引き継いだ形で記載しているため、まだ読まれていない方は先に 後編その1 から読まれることをお勧めします。

コードを修正して Pull Request を作ってみる

では、作成したリポジトリにブランチを作成して、コードを修正して Pull Request を作成してみましょう。
今回は、上記で確認できるレスポンスに、現在日時のフィールドを加える改修を実施してみます。

ブランチを作成して、コードを修正してみる

まず jx create quickstart 時にいたディレクトリ配下にリポジトリが存在するので、そのディレクトリへ移動して、ブランチを適当に切ります。
ジョブの初期設定では、master ブランチ、 PR- で始まるブランチ、feature で始まるブランチがジョブの CI 処理対象となっているため、ブランチ名はその規則に従うようにしましょう。

$ cd quickstart-spring-boot
$ git checkout -b feature/add-date-field

次に、GreetingController クラス内でレスポンスの内容として利用されている Greeting クラスを以下の様な内容に変更してみます。
(Date クラスの date 変数を追加しています)

package hello;

import java.util.Date;

public class Greeting {

    private final long id;
    private final String content;
    private final Date date; // 追加

    public Greeting(long id, String content) {
        this.id = id;
        this.content = content;
        this.date = new Date(); // 追加
    }

    public long getId() {
        return id;
    }

    public String getContent() {
        return content;
    }

    // このメソッドを追加
    public Date getDate() {
        return date;
    }
}

ファイルの編集が完了したら、git add/commit して push します。

$ git add -u
$ git commit -m 'add date field'
$ git push origin feature/add-date-field

次に、Web ブラウザで quickstart-spring-boot リポジトリへアクセスし、今回作成したブランチに関して Pull Request を作成します。

しばらくすると、Jenkins ジョブ上の Pull Requests タブに PR-1 というジョブが現れるはずです。
5分ごとにリポジトリスキャンが行われますが、お急ぎの場合ジョブ画面の左側にある Scan Repository Now ボタンを押しても同じ効果が得られます。

このジョブで実行されるビルドでは、以下の作業が行われます。

• docker イメージの作成、jenkins-x-docker-registry へのpush
• jenkins-x-chartmuseum への Helm chart アップロード
• jx preview コマンドによる preview 環境の構築

しばらく待つと、Pull Request でリクエストされたコードの動作を確認できる動作環境へのリンクが貼られたコメントが Pull Request に記載されます。

 

here の部分のリンクをコピーし/greeting を追加して、改修したコードで動作しているアプリケーションへアクセスしてみましょう。
以下のようなレスポンスを確認出来たら成功です！

{"id":1,"content":"Hello there, World!","date":"2018-09-21T08:54:27.814+0000"}

PR をマージする

master ブランチが更新され、リポジトリ作成時の初期コミット時に実施された作業と同等の作業が実施され、 staging 環境がアップデートされます。

[adinserter block="1"]

production 環境へリリースしてみる

以下のコマンドを実行します。

$ jx promote quickstart-spring-boot --env production --version 0.0.2

staging 環境と同じく、production 環境の構成情報を保持しているリポジトリに対してアプリケーション追加の PR、マージが自動で行われ、アプリケーションの公開が自動で行われます。

ビルドが完了したら、以下のコマンドを実行してみましょう。

$ jx get applications
APPLICATION            STAGING PODS URL                                                             PRODUCTION PODS URL
quickstart-spring-boot 0.0.2   1/1  http://quickstart-spring-boot.jx-staging.XXX.XXX.XXX.XXX.nip.io 0.0.2      1/1  http://quickstart-spring-boot.jx-production.XXX.XXX.XXX.XXX.nip.io

PRODUCTION という列にリリースしたバージョンが記載され、稼働中の Pod の情報、URL が新たに追加されているのが確認できるはずです。
また、production 環境の URL へアクセスしてみて、staging 環境と同様のレスポンスが返ってくることも確認してみましょう。

[adinserter block="1"]

Jenkins X を試用してみた感想

一通り Jenkins X の構築から quickstart プロジェクトを用いてのアプリケーションの修正・デプロイ時の挙動を見てきましたが、筆者が思った現状の Jenkins X に対する感想を箇条書きで書いてみたいと思います。

• 予め用意されている quickstart project を使うとアプリケーション開発の最初でかかる環境整備の稼働が減るのは確か
  • Kubernetes クラスタに Jenkins X を用意すると、自動で development/staging/production 用の namespace を用意してくれる
  • Jenkins X の対象に追加したプロジェクトでは PR を作ると自動で CI/CD が実行され、さらにアプリケーションが動作する環境が整う
• 半面、Jenkins のジョブをカスタマイズしていく場合に、知っていかないといけない知識は少なくない
  • Jenkinsfile
  • Dockerfile
  • helm chart
  • Makefile
  • jx コマンドの挙動
    • jx help でコマンド一覧が出ますが、記事では紹介できないくらい機能が多い…
    • jx コマンドは人が Jenkins X の操作をするために用意されているだけでなく、Jenkins ジョブ内でのバージョン bump とか、リリースなどを行うためにも使われている
  • 初期に自動で用意してくれる箇所については、最終的に全部学習しなければいけなくなりそう
• ドキュメントがまだ不十分
  • https://jenkins-x.io/documentation/
  • ただ、ドキュメントを格納しているリポジトリの最新コミットを確認しても、非常に活発にコミットが進んでいるようなので、期待はできる
    • https://github.com/jenkins-x/jx-docs
    • 本記事の前編、中編、後編と本記事を記載している最中もアップデートされていた
      • Jenkins X のアーキテクチャ、promote 手順のドキュメントについては前編を執筆中には存在していなかったが、現在は存在している
• Jenkins の稼働構成を把握しておく必要がありそう
  • 基本的に Jenkins マスタではジョブをこなさない
  • ジョブが実行されるたびに jnlp-slave が入った Pod を起動してジョブを走らせている(という Jenkinsfile になっている)
    • Kubernetes plugin により実現している
  • なので、通常のサーバ上に Jenkins を稼働させる環境と比較して、ジョブが開始するまでちょっとラグがある
• 現段階でマルチクラスタに未対応
  • https://jenkins-x.io/contribute/roadmap/
  • ロードマップを確認すると、対応予定にはなっている
• Spinnaker とは違って、リリースしたもののを数クリックでロールバックできる機能やカナリアリリースなどは未対応である模様
  • ロールバックに関しては、 jx promote で明示的に前のバージョンを指定すれば戻せる

CI を用意する立場から見てみると、Jenkins X 内部で利用されている構成技術の数が多いので、稼働構成の把握と仕組みを理解するために必要となる時間を多く要すると感じました。
ただ、日頃から Jenkins を利用して開発物の CI/CD を実施していて、Jenkinsfile や Kubernetes に触れている人であれば、調査するにも手掛かりがまったくないという状態ではないので、今後の Jenkins X の進化に期待しましょう。

[adinserter block="1"]

まとめ

本連載では、CI/CD というものが何者であるかの説明に始まり、Jenkins X のインストール、プロジェクトの作成、実際の Git を用いた開発フローを行った場合に Jenkins X がどのように CI/CD を実施してくれるのかをご紹介しました。
アプリケーションの動作環境・デプロイを圧倒的に便利・安全に実現可能にする Kubernetes が出現してまだ数年ですが、CI/CD についてもこれだ！というベストプラクティスがない中、Jenkins X も今後に注目できるプロダクトの一つではないか、というのが筆者の感想でした。引き続き Jenkins X のプロジェクトをウォッチしていきたいと思います。

最後に、全編読んでいただいた方に感謝すると同時に、本連載がみなさまの CI/CD ライフに少しでもお役に立てれば幸いです。

＞Kubernetes 時代の CI/CD「Jenkins X」とは？ 〜前編〜
＞Kubernetes 時代の CI/CD「Jenkins X」とは？ 〜中編 〜
＞Kubernetes 時代の CI/CD「Jenkins X」とは？ 〜後編その1〜