Geekly Articles each Day

Jenkinsのタスク管理



Jenkinsは、おそらく、アプリケーションとインフラストラクチャの自動展開と、さまざまな種類のタスクの便利な管理が必要なほぼすべての企業で使用されています。

市場には、継続的インテグレーションのプロセスを可能な限り快適に構築できる多くのツール（有料および無料）があります。

Jenkinsは、絶えず追加および更新される数千のプラグインの形で優れた機能を備えた無料のツールです。

タスク管理への基本的なアプローチは、Jenkins自体のWebインターフェイスを介して提供されます。ここでは、何でも設定できますが、多数のタスクとその不均一性でこれを維持することはより難しくなります。

以下では、Jenkinsでのタスク作成を単純化および高速化する方法について説明します。

使用するツール


ジェンキンスのジョブビルダー


これは、HTTP APIを介してサーバーにダウンロードされるタスクをYAMLまたはJSON形式で記述することができるPythonユーティリティです。 作業には、ローカルマシンにインストールし、接続を使用して構成を記述し、必要なタスクを説明するだけで十分です。

実際のプロジェクト文書

DSLプラグイン


これはJenkinsのプラグインであり、特別な言語（DSL、ドメイン固有言語）でタスクを記述し、これらの記述に基づいてタスクを作成できます。 Jenkinsサーバー自体でローカルに動作します。

プラグインページ

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


これはJenkinsのタスクのタイプであり、これを使用して、アプリケーションを段階的にデプロイまたはビルドするために必要なプロセスを説明できます。 パイプラインは、プロジェクトリポジトリに保存される特別なJenkinsfileで説明します。

GitlabおよびGitlab CI


最も人気があり開発中のセルフホストプロジェクトであり、多くの企業でも使用されています。 コミュニティバージョンとエンタープライズソリューションが含まれています。

内部には、Goで記述された独自のCIがあり、特別なランナーを使用して、アセンブリと展開のさまざまな段階を実行できます。

使用を開始するには、必要なシーケンスを記述するプロジェクトリポジトリに.gitlab-ci.ymlファイルを作成するだけで十分です。 仕事には、Dockerを完全に使用できます。

それでは始めましょう


まず、必要なツールを配置します。 この場合のJenkins-job-builderは、ローカルマシンとgitlabエージェントが動作するマシンの両方にインストールする必要があります。 ローカルのgitlabマシンだけでうまくいくことができます。

LinuxおよびMacでローカルに、利用可能な最新バージョンをインストールします。

pip install jenkins-job-builder brew install jenkins-job-builder

ローカルでは、シードジョブを説明するために、そのパフォーマンスをテストできます。
DSLプラグイン用語のシードジョブは、DSLスクリプトから残りのタスクを作成するフリースタイルプロジェクトタイプのタスクであると付け加えます。

gitlabサーバーでのインストールは、Linuxマシンでのローカルインストールと変わりません。

 pip install jenkins-job-builder

念のため、ユーティリティを実行し、機能することを確認します。

 ➜ ~ jenkins-jobs usage: jenkins-jobs [-h] [--conf CONF] [-l LOG_LEVEL] [--ignore-cache] [--flush-cache] [--version] [--allow-empty-variables] [--user USER] [--password PASSWORD] {update,test,delete,delete-all} ...

プラグインのインストール


Jenkinsにプラグインをインストールします。 インストールするには、Jenkinsの管理→プラグインの管理→利用可能なセクションの古典的なUpdateCenterを使用するか、curl / wgetを使用したインストールを使用して、プラグインの公式ページからプラグインをダウンロードします。


リポジトリを作成


タスクを記述するコードのリポジトリを作成しましょう。

最初に、シードジョブを準備します。これは、残りのすべてをそれ自体から生成するタスクの名前です。 リポジトリは次のファイルで構成されます。

jenkins.ini


 [job_builder] ignore_cache=True keep_descriptions=False include_path=. recursive=False allow_duplicates=False [jenkins] user=username password=secret-pass url=http://example-ci.org

job-generator.yml


 --- - job: name: job-generator description: 'Do not edit this job through the web!' scm: - git: url: git@gitlab-selfhosted.org:group/repo-dsl.git branches: - origin/master credentials-id: some-credentials-id timeout: 20 basedir: dsl triggers: - gitlab: trigger-push: true trigger-merge-request: false trigger-open-merge-request-push: both ci-skip: false set-build-description: false add-note-merge-request: false add-vote-merge-request: false add-ci-message: true allow-all-branches: true branch-filter-type: RegexBasedFilter target-branch-regex: '.*master*.' builders: - dsl: target: "dsl/*.groovy" ignore-existing: "false" removed-job-action: "DISABLE" removed-view-action: "DELETE" lookup-strategy: "SEED_JOB"

.gitlab-ci.yml


 job: script: 'jenkins-jobs --conf jenkins.ini update job-generator.yml'

gitlab-runnerをプロジェクトに接続します。 gitlabインターフェースは最近頻繁に変更されているため、 公式ドキュメントを参照することをお勧めします。

接続すると、次のようになります。



変更をコミットすると、プロジェクトのJobsセクションに次のように表示されます。



スキーム全体は次のとおりです。



タスクの説明を含むリポジトリを準備します。 名前repo-dslとフラット構造で作成します。 すべてのファイルは現状のままです。
パイプラインを含むファイルを配置します。

 pipelineJob('testpipeline-build') { description('Build test docker image, test and push it to local registry') definition { cpsScm { scm { git { branch('origin/master') remote { url('git@gitlab-selfhosted.org:test-group/sample-project.git') credentials('gitlab-creds') } } } scriptPath('Jenkinsfile') } } }

そして、先ほど作成したシードジョブを実行するためにwebhookをセットアップします。

このバージョンでは、gitlab webhooksはプロジェクトの[設定]→[統合]にあります。
プッシュ時にWebhookを作成します（http：// gitlab：pass@ci.org/project/job-generator）。 概略的には、次のようになります。



Jenkinsには次の2つのタスクがあります。

  1. シードジョブジェネレータータスク
  2. testpipeline-buildと呼ばれるパイプラインタスク。

テストパイプラインでは、Dockerイメージを収集し、ローカルのdockerレジストリにロードします。 画像ファイルは別のプロジェクトから取得されます。

sample-projectというプロジェクトで、次の内容のJenkinsfileを作成します。

 node { def app stage('Clone repository') { checkout([$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId: 'gitlab-repo-creds', url: 'git@gitlab-selfhosted.org:test-group/docker-image-file.git']]]) } stage('Build image') { app = docker.build("docker-image") } stage('Test image') { sh ''' if ! docker inspect docker-image &> /dev/null; then echo 'docker-image does not exist!' exit 1 fi ''' } stage('Push image') { echo 'Push image' docker.withRegistry('https://local-registry:9666', 'registry-creds') { app.push("${env.BUILD_NUMBER}") app.push("latest") } } stage('Clean existing image') { sh "docker rmi docker-image" } }

結果として、完成したパイプラインはJenkins ブルーオーシャンインターフェースでは次のようになります。



または、古典的なインターフェースでは：



このタスクを実行するために、docker-imageを使用してプロジェクトにwebhookを自動的に追加できます。リポジトリに変更を送信すると、このタスクが起動します。

結論として、この記事ではjenkinsのタスク管理に対する多くのアプローチの1つのみを説明していることに注意してください。 柔軟性と機能性により、さまざまなアプローチを使用して、要件とインフラストラクチャ要件に基づいて、できるだけ簡単かつ便利にタスクを管理できます。

Source: https://habr.com/ru/post/J339390/

More articles:


All Articles