私の名前はIlyaGulyaevです。DINSのPostDeploymentVerificationチームのテスト自動化エンジニアです。

DINSでは、ビルドの構築からデプロイメントや自動テストの実行まで、多くのプロセスでJenkinsを使用しています。私のチームでは、開発環境から本番環境に各サービスを展開した後、スモークチェックを均一に実行するためのプラットフォームとしてJenkinsを使用しています。

1年前、他のチームは、パイプラインを使用して、更新後に1つのサービスをチェックするだけでなく、大規模なテストバッチを実行する前に環境全体の状態をチェックすることを決定しました。私たちのプラットフォームの負荷は10倍に増加し、ジェンキンスは目前のタスクに対処するのをやめ、ちょうど落ち始めました。リソースを追加してガベージコレクターを調整すると、問題が遅れるだけで、完全には解決されない可能性があることにすぐに気付きました。そのため、ジェンキンスのボトルネックを見つけて最適化することにしました。

この記事では、Jenkins Pipelineがどのように機能するかを説明し、パイプラインを高速化するのに役立つ可能性のある私の調査結果を共有します。この資料は、すでにJenkinsと協力していて、ツールについてもっとよく知りたいエンジニアに役立ちます。

なんて野獣ジェンキンスパイプライン

Jenkins Pipelineは、さまざまなプロセスを自動化できる強力なツールです。 Jenkins Pipelineは、Groovy DSLの形式でアクションを記述できるプラグインのセットであり、BuildFlowプラグインの後継です。

Build Flowプラグインのスクリプトは、Jenkins内部APIへのアクセスを妨げる障壁なしにGroovyコードを実行する別のJavaスレッドのマスターで直接実行されました。このアプローチはセキュリティリスクをもたらしました。これは後にビルドフローを放棄する理由の1つになり、スクリプトを実行するための安全でスケーラブルなツールであるJenkinsPipelineを作成するための前提条件として機能しました。

Jenkins Pipelineの作成の歴史について詳しくは、著者の記事BuildFlowまたはJenkinsでのGroovyDSLに関するOlegNenashevの講演。

ジェンキンスパイプラインのしくみ

次に、パイプラインが内部からどのように機能するかを理解しましょう。彼らは通常、Jenkins Pipelineは、Webインターフェイスでクリックできる古き良きフリースタイルのジョブとは異なり、Jenkinsではまったく異なる種類のジョブであると言います。ユーザーから見ると次のようになりますが、ジェンキンス側から見ると、パイプラインはアクションの説明をコードに転送できるプラグインのセットです。

パイプラインとフリースタイルの仕事の類似点

ジョブの説明（ステップではない）はconfig.xmlファイルに保存されます
パラメータはconfig.xmlに保存されます
トリガーもconfig.xmlに保存されます
また、一部のオプションもconfig.xmlに保存されます

そう。やめる。公式ドキュメントは、パラメータ、トリガー、およびオプションは、パイプラインで直接設定することができることを言います。真実はどこにありますか？

真実は、パイプラインで説明されているパラメータは、ジョブの開始時にWebインターフェイスの構成セクションに自動的に追加されるということです。この機能は最新版で書いたので信頼できますが、これについては記事の後半で詳しく説明します。

パイプラインジョブとフリースタイルジョブの違い

ジョブの開始時に、ジェンキンスはジョブを実行するためのエージェントについて何も知りません。
アクションは、1つのグルーヴィーなスクリプトで説明されています。

ジェンキンス宣言パイプラインの立ち上げ

Jenkins Pipelineの起動プロセスは、次の手順で構成されています。

config.xmlファイルからジョブの説明をロードします
タスクを完了するために別のスレッド（軽量パフォーマー）を開始する
パイプラインスクリプトの読み込み
構文ツリーの構築と確認
ジョブ構成の更新
ジョブの説明とスクリプトで指定されたパラメータとプロパティを組み合わせる
ジョブの説明をファイルシステムに保存する
グルーヴィーなサンドボックスでスクリプトを実行する
ジョブ全体または単一のステップに対するエージェントの要求

パイプラインジョブが開始されると、Jenkinsは別のスレッドを作成し、実行のためにジョブをキューに送信し、スクリプトをロードした後、タスクを完了するために必要なエージェントを決定します。

このアプローチをサポートするために、特別なJenkinsスレッドプール（軽量エグゼキューター）が使用されます。それらがマスターで実行されていることがわかりますが、通常の実行者のプールには影響しません。

このプール内のスレッドの数は制限されていません（この記事の執筆時点）。

パイプラインの作業パラメータ。トリガーといくつかのオプションだけでなく

パラメータの処理は、次の式で表すことができます。

起動時に表示されるジョブパラメータから、前回の起動のパイプラインパラメータが最初に削除され、次に現在の起動のパイプラインで指定されたパラメータが追加されます。これにより、パラメーターがパイプラインから削除された場合に、パラメーターをジョブから削除できます。

それは裏返しにどのように機能しますか？

config.xml（ジョブの構成を格納するファイル）の例を考えてみましょう。

<?xml version='1.1' encoding='UTF-8'?>
<flow-definition plugin="workflow-job@2.35">
  <actions>
    <org.jenkinsci.plugins.pipeline.modeldefinition.actions.DeclarativeJobAction plugin="pipeline-model-definition@1.5.0"/>
    <org.jenkinsci.plugins.pipeline.modeldefinition.actions.DeclarativeJobPropertyTrackerAction plugin="pipeline-model-definition@1.5.0">
      <jobProperties>
        <string>jenkins.model.BuildDiscarderProperty</string>
      </jobProperties>
      <triggers/>
      <parameters>
        <string>parameter_3</string>
      </parameters>
    </org.jenkinsci.plugins.pipeline.modeldefinition.actions.DeclarativeJobPropertyTrackerAction>
  </actions>
  <description></description>
  <keepDependencies>false</keepDependencies>
  <properties>
    <hudson.model.ParametersDefinitionProperty>
      <parameterDefinitions>
        <hudson.model.StringParameterDefinition>
          <name>parameter_1</name>
          <description></description>
          <defaultValue></defaultValue>
          <trim>false</trim>
        </hudson.model.StringParameterDefinition>
        <hudson.model.StringParameterDefinition>
          <name>parameter_2</name>
          <description></description>
          <defaultValue></defaultValue>
          <trim>false</trim>
        </hudson.model.StringParameterDefinition>
        <hudson.model.StringParameterDefinition>
          <name>parameter_3</name>
          <description></description>
          <defaultValue></defaultValue>
          <trim>false</trim>
        </hudson.model.StringParameterDefinition>
      </parameterDefinitions>
    </hudson.model.ParametersDefinitionProperty>
    <jenkins.model.BuildDiscarderProperty>
      <strategy class="org.jenkinsci.plugins.BuildRotator.BuildRotator" plugin="buildrotator@1.2">
        <daysToKeep>30</daysToKeep>
        <numToKeep>10000</numToKeep>
        <artifactsDaysToKeep>-1</artifactsDaysToKeep>
        <artifactsNumToKeep>-1</artifactsNumToKeep>
      </strategy>
    </jenkins.model.BuildDiscarderProperty>
    <com.sonyericsson.rebuild.RebuildSettings plugin="rebuild@1.28">
      <autoRebuild>false</autoRebuild>
      <rebuildDisabled>false</rebuildDisabled>
    </com.sonyericsson.rebuild.RebuildSettings>
  </properties>
  <definition class="org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition" plugin="workflow-cps@2.80">
    <scm class="hudson.plugins.filesystem_scm.FSSCM" plugin="filesystem_scm@2.1">
      <path>/path/to/jenkinsfile/</path>
      <clearWorkspace>true</clearWorkspace>
    </scm>
    <scriptPath>Jenkinsfile</scriptPath>
    <lightweight>true</lightweight>
  </definition>
  <triggers/>
  <disabled>false</disabled>
</flow-definition>

プロパティ セクションには、ジョブの起動に使用するパラメータ、トリガー、およびオプションが含まれています。追加のセクションDeclarativeJobPropertyTrackerActionは、パイプラインにのみ設定されたパラメーターを格納するために使用されます。

パラメータがパイプラインから削除されると、Jenkinsはパラメータがパイプラインでのみ定義されていることを認識するため、DeclarativeJobPropertyTrackerActionとプロパティの両方からパラメータが削除されます。

パラメータを追加すると、状況が逆になり、パラメータはDeclarativeJobPropertyTrackerActionとプロパティに追加されますが、パイプラインの実行時のみです。

そのため、パイプラインでのみパラメータを設定すると、最初の起動時には利用できなくなります。

ジェンキンスパイプライン実行

Pipelineスクリプトがダウンロードされてコンパイルされると、実行プロセスが開始されます。しかし、このプロセスは単にグルーヴィーなことをするだけではありません。ジョブの実行時に実行される主な重い操作を強調しました

。Groovyコード

の実行パイプラインスクリプトは常にマスターで実行されます。Jenkinsに不要な負荷がかからないように、これを忘れてはなりません。エージェントのファイルシステムまたはシステム呼び出しと対話するステップのみがエージェントで実行されます。

パイプラインには、HTTPリクエストを作成できる優れたプラグインがあります。また、回答をファイルに保存することもできます。

httpRequest  url: 'http://localhost:8080/jenkins/api/json?pretty=true', outputFile: 'result.json'

最初は、このコードをエージェントで完全に実行し、エージェントから要求を送信して、応答をresult.jsonファイルに保存する必要があるように思われる場合があります。しかし、すべてが逆に発生し、リクエストはJenkins自身から実行され、ファイルの内容を保存するためにエージェントにコピーされます。パイプラインでの応答の追加処理が必要ない場合は、そのような要求をcurlに置き換えることをお勧めします。

sh  'curl "http://localhost:8080/jenkins/api/json?pretty=true" -o "result.json"'

ログとアーティファクトの操作

コマンドが実行されるエージェントに関係なく、ログとアーティファクトは処理され、マスターファイルシステムにリアルタイムで保存されます。

シークレット（資格情報）がパイプラインで使用されている場合、ログを保存する前に、マスターでさらにフィルタリングされます。

ステップの保存（パイプラインの耐久性）

Jenkins Pipelineは、独立した個別のピースで構成され、マスターがクラッシュしたときに再現できるタスクとして位置付けています。ただし、タスクの設定に応じて、さまざまな詳細度のステップがシリアル化されてディスクに保存されるため、ディスクへの追加の書き込みでこれを支払う必要があります。

パイプラインの耐久性に応じて、パイプライングラフのステップは、ジョブの実行ごとに1つ以上のファイルに保存されます。ドキュメントからの抜粋：

ステップを格納するためのワークフローサポートプラグイン（FlowNode）は、FlowNodeStorageクラスとそのSimpleXStreamFlowNodeStorageおよびBulkFlowNodeStorage実装を使用します。

FlowNodeStorageは、メモリ内キャッシュを使用してディスク書き込みを集約します。バッファは実行時に自動的に書き込まれます。通常、これについて心配する必要はありませんが、FlowNodeを保存しても、すぐにディスクに書き込まれるとは限らないことに注意してください。

SimpleXStreamFlowNodeStorageは、FlowNodeごとに1つの小さなXMLファイルを使用します。ノードにはソフトリファレンスのメモリ内キャッシュを使用しますが、これにより、最初にFlowNodeをトラバースするときのパフォーマンスが大幅に低下します。

BulkFlowNodeStorageは、すべてのFlowNodeを含む1つの大きなXMLファイルを使用します。このクラスは、書き込み頻度がはるかに少ないPERFORMANCE_OPTIMIZED活性モードで使用されます。1つの大きなストリーミング書き込みは、一連の小さなレコードよりも高速であり、OSの負荷を最小限に抑えてすべての小さなファイルを管理するため、これは一般にはるかに効率的です。

元の

Storage: in the workflow-support plugin, see the 'FlowNodeStorage' class and the SimpleXStreamFlowNodeStorage and BulkFlowNodeStorage implementations.

FlowNodeStorage uses in-memory caching to consolidate disk writes. Automatic flushing is implemented at execution time. Generally, you won't need to worry about this, but be aware that saving a FlowNode does not guarantee it is immediately persisted to disk.

The SimpleXStreamFlowNodeStorage uses a single small XML file for every FlowNode — although we use a soft-reference in-memory cache for the nodes, this generates much worse performance the first time we iterate through the FlowNodes (or when)

The BulkFlowNodeStorage uses a single larger XML file with all the FlowNodes in it. This is used in the PERFORMANCE_OPTIMIZED durability mode, which writes much less often. It is generally much more efficient because a single large streaming write is faster than a bunch of small writes, and it minimizes the system load of managing all the tiny files.

保存されたステップは、次のディレクトリにあります。

$JENKINS_HOME/jobs/$JOB_NAME/builds/$BUILD_ID/workflow/

サンプルファイル：

<?xml version='1.1' encoding='UTF-8'?>
<Tag plugin="workflow-support@3.5">
  <node class="cps.n.StepStartNode" plugin="workflow-cps@2.82">
    <parentIds>
      <string>4</string>
    </parentIds>
    <id>5</id>
    <descriptorId>org.jenkinsci.plugins.workflow.support.steps.StageStep</descriptorId>
  </node>
  <actions>
    <s.a.LogStorageAction/>
    <cps.a.ArgumentsActionImpl plugin="workflow-cps@2.82">
      <arguments>
        <entry>
          <string>name</string>
          <string>Declarative: Checkout SCM</string>
        </entry>
      </arguments>
      <isUnmodifiedBySanitization>true</isUnmodifiedBySanitization>
    </cps.a.ArgumentsActionImpl>
    <wf.a.TimingAction plugin="workflow-api@2.40">
      <startTime>1600855071994</startTime>
    </wf.a.TimingAction>
  </actions>
</Tag>

結果

この資料が面白く、パイプラインとは何か、パイプラインが内部からどのように機能するかをよりよく理解するのに役立つことを願っています。それでも質問がある場合は、以下で共有してください。喜んでお答えします。

記事の後半では、ジェンキンスパイプラインの問題を見つけてタスクをスピードアップするのに役立つ個々のケースについて検討します。同時起動の問題を解決する方法を学び、存続可能性のオプションを確認し、Jenkinsをプロファイリングする必要がある理由について説明します。

ジェンキンスパイプライン：最適化ノート。パート1