1. 概要

このチュートリアルでは、Jenkinsアーキテクチャの基本について説明します。 さらに、パフォーマンスを向上させるためにJenkinsを構成する方法を学習します。 さらに、Jenkinsを手動で再起動またはシャットダウンするオプションについても説明します。

2. ジェンキンスアーキテクチャ

1台のJenkinsサーバーでは特定のニーズを満たすことができませんでした。 まず、ビルドをテストするための複数の異なる環境が必要になる場合があります。 単一のJenkinsサーバーはこれを行うことができません。 第二に、より大きくて重いプロジェクトが定期的に作成されている場合、単一のJenkinsサーバーが圧倒されます。

Jenkins分散アーキテクチャは、上記の要件を満たすために作成されました。 さらに、 Jenkinsは、マスタースレーブアーキテクチャを使用して分散ビルドを管理します。 TCP / IPプロトコルは、この設計のマスターとスレーブ間の通信に使用されます。

2.1. ジェンキンスマスター

Jenkinsマスターは、ジョブのスケジューリング、スレーブの割り当て、およびジョブを実行するためのビルドのスレーブへの送信を担当します。 また、スレーブの状態（オフラインまたはオンライン）を追跡し、スレーブからビルド結果の応答を取得して、コンソール出力に表示します。

2.2. ジェンキンス奴隷

リモートサーバー上で実行されます。 JenkinsサーバーはJenkinsマスターの要求に従い、すべてのオペレーティングシステムと互換性があります。 マスターによってディスパッチされたビルドジョブは、スレーブによって実行されます。 また、特定のスレーブマシンを選択するようにプロジェクトを構成することもできます。

2.3. 分散型マスタースレーブアーキテクチャ

例を使用して、Jenkinsアーキテクチャを見てみましょう。 次の図に、1つのマスターと3つのJenkinsスレーブを示します。

Ubuntu、Windows、MacなどのさまざまなシステムでテストするためにJenkinsをどのように利用できるかを見てみましょう。

この図では、次の項目が処理されています。

  • Jenkinsは、定期的にソースコードに変更がないかGITリポジトリをチェックします
  • 各Jenkinsビルドには独自のテスト環境が必要であり、単一のサーバー上に作成することはできません。 ジェンキンスは、必要に応じてさまざまなスレーブを採用することでこれを実現しています
  • Jenkins Masterは、テストの要求とテストレポートをこれらのスレーブに通知します。

3. ジェンキンスCLI

Jenkinsには、ユーザーと管理者がスクリプト環境またはシェル環境からJenkinsにアクセスするために使用できるコマンドラインインターフェイスがあります。 SSH、Jenkins CLIクライアント、またはJenkinsに含まれているJARファイルは、このコマンドラインインターフェイスを使用できます。

そのためには、最初にjenkins-cli.jarをURL/jnlpJars/jenkins-cli.jarのJenkinsコントローラーからダウンロードする必要があります。事実上JENKINS_URL/ jnlpJars / jenkins-cli.jar、次に、次のように実行します。

java -jar jenkins-cli.jar -s http://localhost:8080/ -webSocket help

このオプションは、[Jenkinsの管理]ページの[ツールとアクション]セクションから[JenkinsCLI]を選択すると使用できます。

使用可能なコマンドのリストがこの領域に表示されます。 コマンドラインツールを使用して、これらのコマンドを使用してさまざまな機能にアクセスできます。

4. Jenkinsを手動で再起動します

Jenkinsを手動で再起動またはシャットダウンする場合は、以下の手順に従ってください。

4.1. 再起動

JenkinsRestAPIを使用して再起動を実行できます。 これにより、既存のジョブが終了するのを待たずに、プロシージャが強制的に再起動されます。

http://(jenkins_url)/restart

Jenkins Rest APIを使用して、safeRestartを実行できます。 これにより、既存のタスクをすべて完了することができます。

http://(jenkins_url)/safeRestart

rpmまたはdebパッケージとしてインストールすると、次のコマンドが機能します。

service jenkins restart

4.2. Ubuntu

apt-get / dpkg を使用して、以下をインストールすることもできます。

sudo /etc/init.d/jenkins restart
Usage: /etc/init.d/jenkins {start|stop|status|restart|force-reload}

4.3. ジェンキンスを安全にシャットダウンするために

Jenkinsを安全にシャットダウンしたい場合は、JenkinsRestAPIを使用して終了を実行できます。

http://(jenkins_url)/exit

Jenkins Rest APIを使用してキルを実行し、すべてのプロセスを終了できます。

http://(jenkins_url)/kill

5. ジェンキンスのパフォーマンスを高める

応答の遅れや応答の遅さは、ジェンキンスのユーザーの間でよくある不満であり、多くの報告された障害があります。 遅いCIシステムは、開発を遅くし、時間を浪費するため、不便です。 いくつかの簡単な推奨事項を使用して、これらのシステムのパフォーマンスを向上させることができます。

次のセクションでは、Jenkinsを改善し、エンジニアの顔を笑顔にするためのいくつかの提案について説明します。

5.1. マスターノードでのビルドを最小化する

マスターノードは、アプリケーションが実際に実行されている場所です。 それはジェンキンスの頭脳であり、奴隷とは異なり、交換することはできません。 そのため、スレーブでのビルドのスケジューリングとトリガーにCPUとRAMを使用して、Jenkinsマスターを可能な限り「作業不要」に保ちたいと考えています。 これは、ジョブをSlaveNodeなどのノードラベルに制限することで実現できます。

パイプラインジョブにノードを割り当てるときは、次のようにラベルを使用します。

stage("stage 1"){
    node("SlaveNode"){
        sh "echo \"Hello ${params.NAME}\" "
    }
}

このような場合、タスクとノードブロックは、SlaveNodeラベルを持つスレーブでのみ実行されます。

5.2. ビルド履歴をあまり多く保持しないでください

ジョブを構成するときに、ファイルシステムに保持するビルドの数と期間を指定できます。 短時間で多くのジョブのビルドをトリガーする場合、DiscardOldBuildsと呼ばれるこの機能が役立ちます。

履歴制限の設定が高すぎて、過剰なビルドが保存される例を見てきました。 また、ジェンキンスはこれらの状況で多くの古いビルドをロードする必要がありました。

5.3. 古いジェンキンスデータをクリアする

ビルドデータに関する以前の提案に続き、知っておくべきもう1つの重要な要素は、古いデータ管理機能です。 Jenkinsは、ご存知かもしれませんが、ジョブを管理し、ファイルシステムにデータを保存します。 コアのアップグレード、プラグインのインストール、更新などのアクションを実行すると、データ形式が変更される場合があります。

Jenkinsは、古いデータ形式をファイルシステムに保存し、この状況で新しい形式をメモリにロードします。 アップグレードをロールバックする必要がある場合は非常に有益ですが、RAMにロードされるデータが多すぎる場合があります。 UIの応答性が遅いことや、OutOfMemoryの問題でさえ、メモリ使用量が多いことを示しています。 このような状況を回避するために、前のデータ管理ページを開くことをお勧めします。

5.4. 適切なヒープサイズを定義する

最大ヒープサイズオプションは、現在の多くのJavaアプリケーションで使用されています。 ヒープサイズを定義する際に注意すべき重要なJVMの側面があります。 UseCompressedOops はこの機能の名前であり、ほとんどの人が使用している64ビットプラットフォームでのみ機能します。 オブジェクトのポインタを64ビットから32ビットに減らし、メモリを大幅に節約します。

このフラグは、サイズが最大32GB（少し小さい）のヒープではデフォルトで有効になっており、それより大きいヒープでは機能しなくなります。 失われた容量を補うために、ヒープを48GBに拡張する必要があります。 そのため、ヒープサイズを定義するときは、32GB未満に抑えることをお勧めします。

次のコマンド（ jinfo はJDKに含まれています）を使用して、フラグが設定されているかどうかを確認できます。

jinfo -flag UseCompressedOops <pid>

5.5. ガベージコレクターを調整する

ガベージコレクターは、バックグラウンドで実行されるメモリ管理システムです。

その主な目的は、ヒープ内の未使用のオブジェクトを見つけて、それらに含まれるメモリを解放することです。 一部のGCアクションの結果としてJavaアプリケーションが停止する場合があります（UIがフリーズすることを覚えていますか？）。 これは、アプリケーションに巨大なヒープ（4GBを超える）がある場合に発生する可能性が最も高くなります。 このような状況で遅延時間を短縮するには、GCの最適化が必要です。 複数のJenkinsセットアップでこれらの課題に対処した後、次の推奨事項を考え出しました。

  • G1GC を有効にする—最新のGC実装（JDK9のデフォルト）
  • GCロギングを有効にする–これは将来の監視と調整に役立ちます
  • 必要に応じて、追加のフラグを使用してGCを構成します
  • 監視を続ける

6. 結論

このクイックチュートリアルでは、最初にJenkinsの分散マスタースレーブアーキテクチャについて説明しました。 その後、Jenkinsを手動で開始、停止、再起動するためのいくつかのオプションを検討しました。 最後に、パフォーマンスを向上させるためにJenkinsのさまざまな構成を調査しました。

Jenkinsに時間を割いてこれらのガイドラインに従うと、潜在的な危険を回避しながら、その多くの便利な機能を利用できるようになります。