Kubernetes で Jenkins を使用する方法をご存知ですか?

[[403811]]

この記事はWeChatの公開アカウント「Ask Qi」から転載したもので、著者はChen Shaowenです。記事を転載する場合は公式アカウントまでご連絡ください。

1. より大きな-Xms -Xmxパラメータを設定する

Jenkins は Java で書かれたオーケストレーション エンジンであり、Full GC 中に Stop The World (STW) を実行します。大規模ビルドでは、STW により Jenkins が新しいリクエストを処理できなくなる可能性があります。

頻繁な STW を回避し、同時実行性を高めるには、より大きなヒープ (-Xms3g -Xmx6g -XX:MaxRAM=6g) を設定することをお勧めします。監視値に応じて具体的な値を設定できます。 Java Full GC 後、メモリ使用量は大幅に減少します。

2. リクエスト値を小さくしすぎない

リクエストが小さすぎると、Jenkins の実行後にノード リソースが不足し、ノードの削除やクラッシュが発生する可能性があります。

リクエストは実際の値に近いはずです。十分なマシン リソースがある場合は、Jenkins が可能な限り別のマシンで実行できるようにアフィニティを構成する必要があります。要求 >= 1.25 * JVM 最大ヒープ メモリ、制限 >= 2 * JVM 最大ヒープ メモリ。

3. IOパフォーマンスは悪くない

Jenkins はディスク ファイルを使用してデータを保存します。各パイプラインと各ビルドはファイル ディレクトリを占有し、多数のファイルを生成します。通常、パイプラインの数は限られていますが、ビルド履歴が 10,000 を超えるレベルに達すると、Jenkins に対する IO の影響が感じられるようになるでしょう。

ローカルストレージを使用する場合は、高性能 SSD をお勧めします。ネットワーク ストレージを使用する場合は、高性能なネットワーク サポートが必要であり、クライアントのキャッシュ プールを増やす必要があります。

4. jenkins_home のディスク容量を増やす

ディスクがいっぱいになると、Jenkins は動作しなくなり、Jenkins のバックグラウンドにエラー メッセージが表示されます。

Jenkins の作業ディレクトリのディスク使用量を監視し、アラーム ルールを構成することをお勧めします。監視アラームシステムがない場合は、/var/jenkins_home ディレクトリに、より大きなディスク領域を直接設定することをお勧めします。一部のストレージ クラスは動的拡張をサポートしていないため、ディスクがいっぱいになった場合は手動でのみコピーできます。

5. Kubernetesプラグインを使用してKubernetes上に構築する

物理マシンと仮想マシンに基づく構築では、運用および保守コストが増加し、同時実行数が制限されます。

Kubernetes プラグインを使用して Kubernetes 上に構築することで、拡張性や保守性が容易なクラウドネイティブの利点を最大限に活用し、大規模な構築を行うことができます。参考: Kubernetes 上で Jenkins スレーブを動的に作成する、https://www.chenshaowen.com/blog/creating-jenkins-slave-dynamically-on-kubernetes.html)。ビルドには多くのリソースが消費されるため、クラスターへの影響を回避するために、ビルド Pod を指定されたノードに集中させて実行するようにアフィニティを設定できます。

6. CasCを使用してJenkinsの設定を管理する

Jenkins ページを通じてさまざまなビルド、セキュリティ、その他の構成を実行するのは面倒で保守が難しいだけでなく、再利用もできません。

CasC プラグインを使用すると、ユーザーは Jenkins の構成をテキスト形式で記述し、それを Git リポジトリに配置してバージョン管理を行うことができます。

ジェンキンス：
  セキュリティレルム:
    ldap:
      構成:
        -グループメンバーシップ戦略:
            ユーザーレコードから:
              属性名: "memberOf"  
          ルートDNの推測を禁止: false  
          ルートDN: "dc=acme,dc=org"  
          サーバー: "ldaps://ldap.acme.org:1636"   
 
  ノード:
    - 永続：
名前: "静的エージェント"  
        リモートFS: "/home/jenkins"  
        ランチャー:
          翻訳:
            作業ディレクトリ設定:
              無効: true  
              failIfWorkDirIsMissing: false  
              内部ディレクトリ: "リモート"  
              作業ディレクトリパス: "/tmp"   
 
  スレーブエージェントポート: 50000
  エージェントプロトコル:
    - 「jnlp2」  

7. カスタム WAR パッケージャーを使用して Jenkins をパッケージ化する

新しい Jenkins 環境をデプロイする場合、多数のプラグインをインストールする必要があり、デプロイ速度に大きく影響します。同時に、プラグインが正常にダウンロードできるかどうかについても不確実性があります。

カスタム WAR パッケージャーを使用すると、ユーザーは Jenkins、構成、プラグインを完全な WAR パッケージまたはイメージにパッケージ化できます。このように、開発やテストでも、オンライン展開でも、非常に便利に展開でき、環境は一貫しており、ユーザーは yaml ファイルを記述するだけで済みます。

バンドル：
  グループID: com.dev
  アーティファクト ID: "jenkins"  
  説明: 「Jenkins Custom With Package」  
  ベンダー: 「Jenkins Project」  
ビルド設定:
  ドッカー:
    ベース: jenkins/jenkins:2.277.4
    タグ: シャオウェンチェン/ジェンキンス:2.277.4
    ビルド: true  
戦争：
  グループ ID: org.jenkins-ci.main
  アーティファクト ID: jenkins-war
  ソース：
    バージョン: 2.277.4
プラグイン:
  - グループID: io.jenkins
    アーティファクト ID:構成コード
    ソース：
      バージョン: "1.47"  
 libパッチ:
  - グループ ID: "org.jenkins-ci.main"  
    アーティファクト ID: 「リモート処理」  
    ソース：
      git: https://github.com/jenkinsci/remoting.git
システムプロパティ: {
     jenkins.model.Jenkins.slaveAgentPort: "50000" 、
     jenkins.model.Jenkins.slaveAgentPortEnforce: "true" }
グルーヴィーフック:
  - タイプ: "init"  
    id: "initScripts"  
    ソース：
      dir: スクリプト
カス:
  - ID: "jcasc-config"  
    ソース：
      ディレクトリ: jenkins.yml

8. Jenkins 共有ライブラリ

Groovy を使用して Pipeline を記述する場合、多くのコードが繰り返されることがよくあります。

Jenkins 共有ライブラリは関数レベルの共有を提供し、同じ関数ロジックのセットを異なるパイプライン間で再利用できるようにします。プラットフォーム構築や大規模な利用シナリオに適しています。パイプラインの書き込みを高速化するだけでなく、メンテナンスやスムーズなアップグレードも容易になります。

 @Library( 'utils' ) org.foo.Utilities をインポートします
def utils = 新しいユーティリティ(これ)
ノード {
  utils.mvn 'クリーンパッケージ'  
 }

9. 参考文献

• https://www.jenkins.io/zh/doc/book/pipeline/shared-libraries/
• https://github.com/jenkinsci/configuration-as-code-plugin
• https://github.com/jenkinsci/custom-war-packager
• https://zhuanlan.zhihu.com/p/370241822