JFrog PipelinesでJenkinsビルドを効率的に実施
現在、Jenkinsは最も人気のあるオープンソースのCIツールです。マーケットにいち早く参入したことで、JenkinsはCIを普及させました。他のCIツールと同様、Jenkinsは開発者がソースリポジトリにコードをコミット後、自動的にビルドしてテストを行うことが可能です。これにより開発者はバグを早期に把握し、素早くデプロイすることができます。
初期リリースから10年以上経った今、Jenkinsは岐路に立たされています。Jenkinsコミュニティの大部分にとってJenkinsは”容認”するツールとなっています。Jenkinsスプロール（管理するサーバの数が増える）という言葉はIT用語として定着しています。多数のプラグインを使用することで互いに干渉してJenkinsは複雑になってしまいます。この”プラグイン地獄”を回避する一つの方法は、より多数のサーバーやインスタンスにワークロード（とプラグイン）を分散することです。しかし開発チームがJenkinsのインスタンスを増加することによってサイロ化してしまい、今度は増加するJenkinsの構成を管理することになるという課題に直面します。残念ながら、複雑さの種類が変わるだけになってしまいます。また、Jenkinsはコンテナやマイクロサービス以前の時代のために作成されました。どのようなツールであれ、その価値を維持するためには、技術トレンドと上手く連携する必要があります。
このブログではSDLCの一部としてJFrog Pipelinesを使用し、CI/CD DevOpsフローを加速し、改善する方法をご説明します。
JFrog Pipelinesはソフトウェアを構築、テスト、デプロイするための自動化ソリューションです。以下のような機能を含む、すべての主要なDevOpsパイプラインプロセスのエンドツーエンドのオーケストレーションと最適化を提供します:
- Pipelinesは単体のCI/CDソリューションではなく、Artifactoryとバイナリを中心としたJFrog Platformの一部
- プラグインフリーのアーキテクチャ – プラグインのメンテナンスは面倒
- ネイティブStepによる迅速かつシンプルなパイプライン設定
- 無限に拡張できる（Jenkinsスプロールと比較して）集中型サービス
- YAML – 習得が容易
- JFrog Xrayよる脆弱性スキャンとライセンス・コンプライアンス
JFrogのソリューションエンジニアとしてEnterprise+を導入するお客様からよく受ける質問や懸念事項をご紹介します。具体的にはJenkinsからJFrog Pipelinesへの移行方法です。
- なぜ、動作しているプロセスを変更してデプロイを危険にさらす必要があるのでしょうか？
- すべてのCI/CDプロセスをJFrog Pipelinesに移行するには膨大な時間がかかりませんか？
- Jenkinsではプラグインがあります。JFrogでも同様にサポートされるのでしょうか？
Jenkinsパイプライン例
以下のエンドツーエンドのKubernetes CI/CD Jenkinsパイプラインを使用し、JFrog Pipelinesがどのように機能するのかを示します。このパイプラインは一般的に知られているpet-clinic Mavenプロジェクトをビルドし、Dockerでコンテナ化し、作成したイメージをHelm chartを使用してK8sクラスタ環境にデプロイします。この処理には以下のステップが含まれています:
継続的インテグレーション（CI）
- Mavenプロジェクト（Pet Clinic Springアプリケーション）をビルドし、作成されたバイナリをArtifactoryにデプロイします。
- 新しいアプリケーションをDockerでコンテナ化し、新しいイメージをArtifactoryにデプロイします。
継続的デリバリー（CD）
- k8s用のパッケージマネージャであるHelmをインストールします。
- Artifactoryで利用可能なHelm Chartを使用し、アプリケーションが保存されているイメージをk8sベースの本番環境にデプロイします。
上記のパイプライン（JenkinsfileとDockerfile）のコードサンプルはこちらにあります。
この一般的なCI/CDの例を利用して実装可能なテクニックを見てみましょう。
JFrogパイプラインで効率的に実施
JFrog Pipelinesを開始するには3つの基本的なテクニックがあります。最初の2つはJenkinsとのインテグレーションを実現するもので順番を問わずに実施するもできますし、これら2つのインテグレーション・アプローチの内の1つだけを選択することもできます。JenkinsをJFrog Pipelinesとのインテグレーション後は#3に進むことができます:
- Incoming Webhookを使用してJenkins（CI）からPipelines（CD）をトリガー
- SDLCの一部を移行する方法はJFrog Pipelines（CI）からJenkinsインテグレーションを使用して、Jenkins（CD）を起動
プロセスを合理化するために自動化を推進し、JFrog Pipelinesを使用して新しいCI/CDプロセスを設計します。
1. JFrog PipelinesのWebhook
1つの方法として、JenkinsでCIを保持しつつ、デプロイはJFrog Pipelinesで行うという方法があります。
JFrog PipelinesとJenkinsをリンクする場合、Dockerイメージとビルド情報がArtifactoryにデプロイされた時にJenkinsの最終ステップでJFrog PipelinesにWebhookリクエストを送信することで、Jenkinsの新しい実行をトリガーするIncoming Webhookを使用することができます。
メリット:
-
- HelmとGoogle Cloud SDKのインストールが不要で迅速にデプロイを実行できます。
- KubernetesプラグインをベースにしたJenkinsスプロールや”プラグイン地獄”を避け、代わりにJFrog PipelinesのネイティブStepを使用してKubernetesにデプロイします。
- Helm ChartをPullして管理するためのArtifactoryとのネイティブなインテグレーション。
Jenkinsのビルドが完了後、JFrog Pipelinesはk8sクラスターへのchartのデプロイを管理することができます。
これはJFLog PipelinesのHelmスクリプトを必要としない事前にパッケージ化された宣言的ステップのHelmDeployネイティブStepで実施することができます。
私たちのクラスタはGoogle Kubernetes Engine上で動作しています。そのため、デプロイのステップを可能にするためにGoogle Cloud Integrationを追加しました:
コードサンプル（Jenkinsfileとpipelines.yml）はこちらにあります。
2. JenkinsとJFrog Pipelinesのインテグレーション – 部分的な移行で効率的な移行が可能
2. JenkinsとJFrog Pipelinesのインテグレーション – 部分的な移行で効率的な移行が可能
CI/CD全体を一から書き直しても意味がありません。これまでJenkinsで行ってきた努力はすべて価値があります。Jenkinsインテグレーションを使用することによって特定の部分だけを移行することができます。現在のワークロードをJenkinsから移行することなくインテグレーションすることも可能ですが、すべてJFrog Pipelinesに集約することもできます。この目的のためにワークロードの一部を移行したいと仮定します。
例えばCDプロセスに高い投資をしているため、現在の実装をJenkinsで維持し、CI部分のみを移行してJFrog Pipelinesのメリットを享受したいとします。
メリット:
- JFrog PipelinesとArtifactoryの標準インテグレーション
- JFrog CLI/FileSpecを使用してArtifactoryから最新のソフトウェアを取得してアプリケーションを簡単にDocker化
JFrog Pipelinesに新しいJenkinsインテグレーションを作成します:
Jenkinsのユーザー名、APIトークン、URLはJFrog Pipelinesが通信に使用し、コールバックURLはJenkinsが使用します。
以下はJenkinsの設定です:
“Test Connection”でJFrog Pipelinesで作成したURLを元にJenkinsからも通信が可能であることを検証します。
これにより、CIはJFrog Pipelinesで実行することができます:
最後のステップは新しいデプロイメント（CD）を起動します。:
Jenkinsでは最終ステップでデプロイが正常に完了したことをレポートします。
コードサンプル（Jenkinsfileとpipelines.yml）はこちらにあります。
3. Helm CI/CD – プロセスを効率化するための自動化機能を追加
HelmはKubernetesのパッケージマネージャです。Helmはパッケージ化されたアプリケーションを定義するchartをデプロイします。バージョン管理された事前に設定されたすべてのアプリケーション・リソースの集合体で1つの単位としてデプロイすることができます。
私たちは頻繁にソフトウェアのデプロイ方法を変更しており、その変更は異なるHelm chartのバージョンに反映されます。これらはすべてHelm chartリポジトリを利用して Artifactory に保存することができます。
JFrog PipelinesでHelmPublishネイティブStepを使用して、新しいHelm chartをArtifactoryにデプロイするプロセスを自動化することができます。
メリット:
- chartのパッケージングはHelmでコーディングをせずに実施しますが、ネイティブStepを利用し、chartに問題がないかも調べます（lint: true）。
- Helmのインストール処理を軽減します（バージョンはv2/v3を選択できます）。
既存のPipeline Resourceを更新することで、Resourceを入力とする他のパイプラインが直ちにトリガーされます。
コードサンプル（pipelines.yml）はこちらにあります。
このブログでは既存のJenkinsベースのDevOpsプロセスの一部としてJFrog Pipelinesを活用する3つの異なる方法をご紹介しました。これをきっかけに複数のアプローチを併用することを検討されてはいかがでしょうか。
JFrog Pipelinesがどのように機能するかを無料でお試しください。
