Jenkinsから移行する

プラン: Free、Premium、Ultimate
提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

JenkinsからGitLab CI/CDへ移行する場合、Jenkinsのワークフローをレプリケートする、あるいはそれを強化するCI/CDパイプラインを作成できます。

主な類似点と相違点

GitLab CI/CDとJenkinsは、いくつかの類似点を持つCI/CDツールです。GitLabとJenkinsの両方で:

ジョブの集まりにはステージを使用します。
コンテナベースのビルドをサポートします。

さらに、両者にはいくつかの重要な違いがあります:

GitLab CI/CDパイプラインはすべてYAML形式の設定ファイルで設定されます。Jenkinsは、Groovy形式の設定ファイル（宣言型パイプライン）またはJenkins DSL（スクリプト型パイプライン）のいずれかを使用します。
GitLabは、マルチテナントのSaaSサービスであるGitLab.comと、完全に分離されたシングルテナントのSaaSサービスであるGitLab Dedicatedを提供しています。また、独自のGitLab Self-Managedインスタンスを実行することもできます。Jenkinsのデプロイはセルフホストである必要があります。
GitLabは、ソースコード管理（SCM）をすぐに利用できる形で提供します。Jenkinsは、コードを保存するために別のSCMソリューションを必要とします。
GitLabは、組み込みのコンテナレジストリを提供します。Jenkinsは、コンテナイメージを保存するために別のソリューションを必要とします。
GitLabは、コードをスキャンするための組み込みテンプレートを提供します。Jenkinsは、コードをスキャンするためにサードパーティのプラグインを必要とします。

機能と概念の比較

多くのJenkinsの機能と概念は、GitLabに同様の機能を提供する同等のものがあります。

設定ファイル

Jenkinsは、Groovy形式のJenkinsfileで設定できます。GitLab CI/CDは、デフォルトで.gitlab-ci.ymlファイルを使用します。

Jenkinsfileの例:

pipeline {
    agent any

    stages {
        stage('hello') {
            steps {
                echo "Hello World"
            }
        }
    }
}

同等のGitLab CI/CD.gitlab-ci.ymlファイルは次のとおりです:

stages:
  - hello

hello-job:
  stage: hello
  script:
    - echo "Hello World"

Jenkinsパイプライン構文

Jenkinsの設定は、セクションとディレクティブを持つpipelineブロックで構成されます。GitLab CI/CDは、YAMLキーワードで設定される同様の機能を持っています。

セクション

Jenkins	GitLab	説明
`agent`	`image`	Jenkinsパイプラインはエージェント上で実行され、`agent`セクションはパイプラインの実行方法と使用するDockerコンテナを定義します。GitLabのジョブはRunner上で実行され、`image`キーワードは使用するコンテナを定義します。Kubernetesまたは任意のホストで独自のRunnerを設定できます。
`post`	`after_script`または`stage`	Jenkinsの`post`セクションは、ステージまたはパイプラインの最後に実行すべきアクションを定義します。GitLabでは、ジョブの最後に実行するコマンドには`after_script`を、ジョブ内の他のコマンドの前に実行するアクションには`before_script`を使用します。ジョブを実行する正確なステージを選択するには、`stage`を使用します。GitLabは、他のすべての定義されたステージの前後で常に実行される`.pre`と`.post`の両方のステージをサポートしています。
`stages`	`stages`	Jenkinsのステージはジョブのグループです。GitLab CI/CDもステージを使用しますが、より柔軟です。複数のステージをそれぞれ複数の独立したジョブで持つことができます。最上位レベルで`stages`を使用してステージとその実行順序を設定し、ジョブレベルで`stage`を使用してそのジョブのステージを定義します。
`steps`	`script`	Jenkinsの`steps`は、実行する内容を定義します。GitLab CI/CDは、同様の`script`セクションを使用します。`script`セクションは、各コマンドを順に実行するための個別のエントリを持つYAML配列です。

ディレクティブ

Jenkins	GitLab	説明
`environment`	`variables`	Jenkinsは、環境変数に`environment`を使用します。GitLab CI/CDは、ジョブの実行中だけでなく、より動的なパイプラインの設定にも使用できるCI/CD変数を定義するために`variables`キーワードを使用します。これらは、GitLab UIのCI/CD設定で設定することもできます。
`options`	該当なし	Jenkinsは、タイムアウトやリトライ値などの追加の設定に`options`を使用します。GitLabはオプションの個別のセクションを必要とせず、すべての設定はジョブまたはパイプラインレベルで`timeout`または`retry`のようなCI/CDキーワードとして追加されます。
`parameters`	該当なし	Jenkinsでは、パイプラインをトリガーする際にパラメータが必要になる場合があります。パラメータは、パイプラインの設定、プロジェクトの設定、ランタイムでUIを介して手動で、またはAPIなど、多くの場所で定義できるCI/CD変数によってGitLabで処理されます。
`triggers`	`rules`	Jenkinsでは、`triggers`は、たとえばcron表記を通じて、パイプラインをいつ再度実行するかを定義します。GitLab CI/CDは、Gitの変更やマージリクエストの更新など、多くの理由でパイプラインを自動的に実行できます。ジョブを実行するイベントを制御するには、`rules`キーワードを使用します。スケジュールされたパイプラインは、プロジェクトの設定で定義されます。
`tools`	該当なし	Jenkinsでは、`tools`は環境にインストールする追加ツールを定義します。GitLabには同様のキーワードはありません。ジョブに必要な正確なツールを組み込んだコンテナイメージを使用することが推奨されるためです。これらのイメージはキャッシュされ、パイプラインに必要なツールがすでに含まれるようにビルドできます。ジョブが追加のツールを必要とする場合、それらは`before_script`セクションの一部としてインストールできます。
`input`	該当なし	Jenkinsでは、`input`はユーザー入力のプロンプトを追加します。`parameters`と同様に、入力はCI/CD変数を通じてGitLabで処理されます。
`when`	`rules`	Jenkinsでは、`when`はステージを実行すべきタイミングを定義します。GitLabには、`when`キーワードもあります。これは、たとえばジョブが合格したか失敗したかなど、以前のジョブのステータスに基づいてジョブを開始すべきかを定義します。特定のパイプラインにジョブを追加するタイミングを制御するには、`rules`を使用します。

一般的な設定

このセクションでは、一般的に使用されるCI/CDの設定について説明し、それらをJenkinsからGitLab CI/CDに変換する方法を示します。

Jenkinsパイプラインは、新しいコミットがプッシュするされるなど、特定のイベントが発生したときにトリガーするされる自動化されたCI/CDジョブを生成します。Jenkinsパイプラインは、Jenkinsfileで定義されます。GitLabの同等物は、.gitlab-ci.yml設定ファイルです。

Jenkinsはコードを保存する場所を提供しないため、Jenkinsfileは別のソースコントロールリポジトリに保存する必要があります。

ジョブ

ジョブは、特定の成果を達成するために設定された順序で実行される一連のコマンドです。

たとえば、Jenkinsfileでコンテナをビルドするし、それを本番環境にデプロイする場合:

pipeline {
    agent any
    stages {
        stage('build') {
            agent { docker 'golang:alpine' }
            steps {
                apk update
                go build -o bin/hello
            }
            post {
              always {
                archiveArtifacts artifacts: 'bin/hello'
                onlyIfSuccessful: true
              }
            }
        }
        stage('deploy') {
            agent { docker 'golang:alpine' }
            when {
              branch 'staging'
            }
            steps {
                echo "Deploying to staging"
                scp bin/hello remoteuser@remotehost:/remote/directory
            }
        }
    }
}

この例では:

golang:alpineコンテナイメージを使用します。
コードをビルドするするためのジョブを実行します。
- ビルドされた実行可能ファイルをアーティファクトとして保存します。
stagingにデプロイするための2番目のジョブを追加します。これは:
- コミットがstagingブランチをターゲットにしている場合にのみ存在します。
- ビルドステージが成功した後に開始されます。
- 以前のジョブからのビルドされた実行可能アーティファクトを使用します。

同等のGitLab CI/CD.gitlab-ci.ymlファイルは次のとおりです:

default:
  image: golang:alpine

stages:
  - build
  - deploy

build-job:
  stage: build
  script:
    - apk update
    - go build -o bin/hello
  artifacts:
    paths:
      - bin/hello
    expire_in: 1 week

deploy-job:
  stage: deploy
  script:
    - echo "Deploying to Staging"
    - scp bin/hello remoteuser@remotehost:/remote/directory
  rules:
    - if: $CI_COMMIT_BRANCH == 'staging'
  artifacts:
    paths:
      - bin/hello

並列

Jenkinsでは、以前のジョブに依存しないジョブは、parallelセクションに追加すると並列で実行できます。

たとえば、Jenkinsfileで:

pipeline {
    agent any
    stages {
        stage('Parallel') {
            parallel {
                stage('Python') {
                    agent { docker 'python:latest' }
                    steps {
                        sh "python --version"
                    }
                }
                stage('Java') {
                    agent { docker 'openjdk:latest' }
                    when {
                        branch 'staging'
                    }
                    steps {
                        sh "java -version"
                    }
                }
            }
        }
    }
}

この例では、異なるコンテナイメージを使用して、PythonとJavaのジョブを並列で実行します。Javaのジョブは、stagingブランチが変更された場合にのみ実行されます。

同等のGitLab CI/CD.gitlab-ci.ymlファイルは次のとおりです:

python-version:
  image: python:latest
  script:
    - python --version

java-version:
  image: openjdk:latest
  rules:
    - if: $CI_COMMIT_BRANCH == 'staging'
  script:
    - java -version

この場合、ジョブを並列で実行するために追加の設定は必要ありません。ジョブはデフォルトで並列実行され、すべてのジョブに対して十分な数のRunnerがあることを前提として、それぞれが異なるRunner上で実行されます。Javaのジョブは、stagingブランチが変更された場合にのみ実行されるように設定されています。

マトリックス

GitLabでは、マトリックスを使用して、単一のパイプラインでジョブを複数回並列で実行できますが、ジョブの各インスタンスには異なる変数値が設定されます。Jenkinsはマトリックスを順次実行します。

たとえば、Jenkinsfileで:

matrix {
    axes {
        axis {
            name 'PLATFORM'
            values 'linux', 'mac', 'windows'
        }
        axis {
            name 'ARCH'
            values 'x64', 'x86'
        }
    }
    stages {
        stage('build') {
            echo "Building $PLATFORM for $ARCH"
        }
        stage('test') {
            echo "Building $PLATFORM for $ARCH"
        }
        stage('deploy') {
            echo "Building $PLATFORM for $ARCH"
        }
    }
}

同等のGitLab CI/CD.gitlab-ci.ymlファイルは次のとおりです:

stages:
  - build
  - test
  - deploy

.parallel-hidden-job:
  parallel:
    matrix:
      - PLATFORM: [linux, mac, windows]
        ARCH: [x64, x86]

build-job:
  extends: .parallel-hidden-job
  stage: build
  script:
    - echo "Building $PLATFORM for $ARCH"

test-job:
  extends: .parallel-hidden-job
  stage: test
  script:
    - echo "Testing $PLATFORM for $ARCH"

deploy-job:
  extends: .parallel-hidden-job
  stage: deploy
  script:
    - echo "Testing $PLATFORM for $ARCH"

コンテナイメージ

GitLabでは、imageキーワードを使用して、個別の隔離されたDockerコンテナでCI/CDジョブを実行できます。

たとえば、Jenkinsfileで:

stage('Version') {
    agent { docker 'python:latest' }
    steps {
        echo 'Hello Python'
        sh 'python --version'
    }
}

この例は、python:latestコンテナで実行されるコマンドを示しています。

同等のGitLab CI/CD.gitlab-ci.ymlファイルは次のとおりです:

version-job:
  image: python:latest
  script:
    - echo "Hello Python"
    - python --version

変数

GitLabでは、CI/CD変数を定義するためにvariablesキーワードを使用します。変数を使用して、設定データを再利用したり、より動的な設定を行ったり、重要な値を保存したりできます。変数は、グローバルまたはジョブごとに定義できます。

たとえば、Jenkinsfileで:

pipeline {
    agent any
    environment {
        NAME = 'Fern'
    }
    stages {
        stage('English') {
            environment {
                GREETING = 'Hello'
            }
            steps {
                sh 'echo "$GREETING $NAME"'
            }
        }
        stage('Spanish') {
            environment {
                GREETING = 'Hola'
            }
            steps {
                sh 'echo "$GREETING $NAME"'
            }
        }
    }
}

この例は、変数をジョブ内のコマンドに値を渡すために使用できる方法を示しています。

同等のGitLab CI/CD.gitlab-ci.ymlファイルは次のとおりです:

default:
  image: alpine:latest

stages:
  - greet

variables:
  NAME: "Fern"

english:
  stage: greet
  variables:
    GREETING: "Hello"
  script:
    - echo "$GREETING $NAME"

spanish:
  stage: greet
  variables:
    GREETING: "Hola"
  script:
    - echo "$GREETING $NAME"

変数は、GitLab UIのCI/CD設定で設定することもできます。場合によっては、保護されたおよびマスクされた変数をシークレット値に使用できます。これらの変数は、設定ファイルで定義された変数と同じようにパイプラインジョブでアクセスできます。

たとえば、Jenkinsfileで:

pipeline {
    agent any
    stages {
        stage('Example Username/Password') {
            environment {
                AWS_ACCESS_KEY = credentials('aws-access-key')
            }
            steps {
                sh 'my-login-script.sh $AWS_ACCESS_KEY'
            }
        }
    }
}

同等のGitLab CI/CD.gitlab-ci.ymlファイルは次のとおりです:

login-job:
  script:
    - my-login-script.sh $AWS_ACCESS_KEY

さらに、GitLab CI/CDは、パイプラインとリポジトリに関連する値を含む定義済み変数をすべてのパイプラインとジョブで利用可能にします。

式と条件

新しいパイプラインが開始されると、GitLabはそのパイプラインでどのジョブを実行すべきかを確認します。変数のステータスやパイプラインのタイプなどの要因に応じてジョブを実行するように設定できます。

たとえば、Jenkinsfileで:

stage('deploy_staging') {
    agent { docker 'alpine:latest' }
    when {
        branch 'staging'
    }
    steps {
        echo "Deploying to staging"
    }
}

この例では、コミットするブランチがstagingという名前の場合にのみジョブが実行されます。

同等のGitLab CI/CD.gitlab-ci.ymlファイルは次のとおりです:

deploy_staging:
  stage: deploy
  script:
    - echo "Deploy to staging server"
  rules:
    - if: '$CI_COMMIT_BRANCH == staging'

Runner

Jenkinsのエージェントと同様に、GitLabのRunnerはジョブを実行するホストです。GitLab.comを使用している場合、独自のRunnerをプロビジョニングすることなくジョブを実行するためにインスタンスRunnerフリートを使用できます。

JenkinsのエージェントをGitLab CI/CDで使用できるように変換するには、エージェントをアンインストールしてから、Runnerをインストールして登録します。Runnerは多くのオーバーヘッドを必要としないため、使用していたJenkinsのエージェントと同様のプロビジョニングを使用できる可能性があります。

Runnerに関するいくつかの主要な詳細:

Runnerは、インスタンス、グループ全体、または単一のプロジェクトに特化して共有されるように設定できます。
よりきめ細かな制御のためにtagsキーワードを使用し、Runnerを特定のジョブに関連付けることができます。たとえば、専用の、より強力な、または特定のハードウェアを必要とするジョブにはタグを使用できます。
GitLabには、Runnerのオートスケール機能があります。オートスケールを使用して、必要なときにのみRunnerをプロビジョニングするし、不要なときにスケールするダウンします。

たとえば、Jenkinsfileで:

pipeline {
    agent none
    stages {
        stage('Linux') {
            agent {
                label 'linux'
            }
            steps {
                echo "Hello, $USER"
            }
        }
        stage('Windows') {
            agent {
                label 'windows'
            }
            steps {
                echo "Hello, %USERNAME%"
            }
        }
    }
}

同等のGitLab CI/CD.gitlab-ci.ymlファイルは次のとおりです:

linux_job:
  stage: build
  tags:
    - linux
  script:
    - echo "Hello, $USER"

windows_job:
  stage: build
  tags:
    - windows
  script:
    - echo "Hello, %USERNAME%"

アーティファクト

GitLabでは、任意のジョブがartifactsキーワードを使用して、ジョブの完了時に保存するアーティファクトのセットを定義できます。アーティファクトは、たとえばテストやデプロイのために、以降のジョブで使用できるファイルです。

たとえば、Jenkinsfileで:

stages {
    stage('Generate Cat') {
        steps {
            sh 'touch cat.txt'
            sh 'echo "meow" > cat.txt'
        }
        post {
            always {
                archiveArtifacts artifacts: 'cat.txt'
                onlyIfSuccessful: true
            }
        }
    }
    stage('Use Cat') {
        steps {
            sh 'cat cat.txt'
        }
    }
  }

同等のGitLab CI/CD.gitlab-ci.ymlファイルは次のとおりです:

stages:
  - generate
  - use

generate_cat:
  stage: generate
  script:
    - touch cat.txt
    - echo "meow" > cat.txt
  artifacts:
    paths:
      - cat.txt
    expire_in: 1 week

use_cat:
  stage: use
  script:
    - cat cat.txt
  artifacts:
    paths:
      - cat.txt

キャッシュ

ジョブが1つ以上のファイルをダウンロードして将来の高速アクセスに備えて保存すると、キャッシュが作成されます。同じキャッシュを使用する後続のジョブは、ファイルを再度ダウンロードする必要がないため、より高速に実行されます。キャッシュはRunnerに保存され、分散キャッシュが有効な場合はS3にアップロードされます。Jenkinsコアはキャッシュ機能を提供しません。

たとえば、.gitlab-ci.ymlファイルで:

cache-job:
  script:
    - echo "This job uses a cache."
  cache:
    key: binaries-cache-$CI_COMMIT_REF_SLUG
    paths:
      - binaries/

Jenkinsプラグイン

Jenkinsでプラグインを通じて有効になる一部の機能は、GitLabで同様の機能を提供するキーワードと機能によってネイティブにサポートされています。例:

Jenkinsプラグイン	GitLabの機能
Build Timeout	`timeout`キーワード
Cobertura	カバレッジレポートアーティファクトとコードカバレッジ
コードカバレッジAPI	コードカバレッジとカバレッジの可視化
Embeddable Build Status	パイプラインステータスバッジ
JUnit	JUnitテストレポートアーティファクトと単体テストレポート
Mailer	通知メール
Parameterizedトリガープラグイン	`trigger`キーワードとダウンストリームパイプライン
ロールベース認可戦略	GitLabの権限とロール
Timestamper	ジョブログにはデフォルトでタイムスタンプが付けられます。

セキュリティスキャン機能

Jenkinsで、コード品質、セキュリティ、または静的アプリケーションスキャンなどのプラグインを使用したことがあるかもしれません。GitLabは、SDLCのすべての部分で脆弱性を検出するために、すぐに使用できるセキュリティスキャナーを提供します。これらのプラグインは、テンプレートを使用してGitLabに追加できます。たとえば、パイプラインにSASTスキャンを追加するには、.gitlab-ci.ymlに以下を追加します:

include:
  - template: Jobs/SAST.gitlab-ci.yml

CI/CD変数を使用することで、セキュリティスキャナーの動作をカスタマイズできます。たとえば、SASTスキャナーを使用する場合などです。

シークレット管理

「シークレット」とよく呼ばれる特権情報は、CI/CDワークフローで必要となる機密情報または認証情報です。シークレットを使用して、ツール、アプリケーション、コンテナ、およびクラウドネイティブ環境で保護されたリソースや機密情報をアンロックすることができます。

Jenkinsでのシークレット管理は通常、SecretタイプフィールドまたはCredentialsプラグインで処理されます。Jenkinsの設定に保存されている認証情報は、Credentials Bindingプラグインを使用することで、環境変数としてジョブに公開できます。

GitLabでのシークレット管理には、外部サービス向けのサポートされているインテグレーションのいずれかを使用できます。これらのサービスはGitLabプロジェクトの外部でシークレットを安全に保存しますが、そのサービスに対してサブスクリプションが必要です。

GitLabは、OIDCをサポートする他のサードパーティサービスに対してもOIDC認証をサポートしています。

さらに、認証情報をCI/CD変数に保存することで、ジョブで利用可能にできますが、プレーンテキストで保存されたシークレットは、Jenkinsと同様に偶発的な漏洩の危険性があります。機密情報は、常にマスクされたおよび保護された変数に保存する必要があります。これにより、リスクの一部が軽減されます。

また、プロジェクトにアクセスできるすべてのユーザーに公開されている.gitlab-ci.ymlファイルに、シークレットを変数として保存しないでください。機密情報を変数に保存する場合は、プロジェクト、グループ、またはインスタンスの設定でのみ行うべきです。

セキュリティガイドラインを確認して、CI/CD変数の安全性を向上させてください。

移行の計画と実行

以下の推奨ステップのリストは、この移行を迅速に完了できた組織を観察した後に作成されました。

移行計画の作成

移行を開始する前に、移行の準備のために移行計画を作成する必要があります。Jenkinsからの移行のために、準備として以下の質問を自問してください:

今日、Jenkinsのジョブでどのようなプラグインが使用されていますか？
- これらのプラグインが具体的に何をするかご存知ですか？
- いずれかのプラグインが一般的なビルドツールをラップしていますか？たとえば、Maven、Gradle、またはNPMですか？
Jenkinsのエージェントには何がインストールされていますか？
共有ライブラリは使用されていますか？
Jenkinsからどのように認証していますか？SSHキー、APIトークン、または他のシークレットを使用していますか？
パイプラインからアクセスする必要がある他のプロジェクトはありますか？
外部サービスにアクセスするためのJenkinsに認証情報はありますか？たとえば、Ansible Tower、Artifactory、または他のクラウドプロバイダーやデプロイターゲットですか？

前提条件

移行作業を行う前に、まず以下を実行する必要があります:

GitLabに慣れてください。
- 主要なGitLab CI/CD機能について読んでください。
- 最初のGitLabパイプラインと、静的サイトをビルドする、テストする、デプロイするより複雑なパイプラインを作成するためのチュートリアルに従ってください。
- CI/CD YAML構文リファレンスを確認してください。
GitLabを設定してセットアップします。
GitLabインスタンスをテストします。
- 共有GitLab.com Runnerを使用するか、新しいRunnerをインストールすることで、Runnerが利用可能であることを確認してください。

移行ステップ

プロジェクトをSCMソリューションからGitLabへ移行する。
- （推奨）利用可能なインポーターを使用して、外部SCMプロバイダーからの大量のインポートを自動化できます。
- あなたはURLでリポジトリをインポートできます。
各プロジェクトに.gitlab-ci.ymlファイルを作成します。
Jenkinsの設定をGitLab CI/CDジョブに移行するし、マージリクエストに直接結果を表示するように設定します。
クラウドデプロイテンプレート、環境、およびKubernetes向けGitLabエージェントを使用して、デプロイメントジョブを移行する。
異なるプロジェクト間でCI/CDの設定を再利用できるかどうかを確認し、CI/CDテンプレートを作成して共有します。
パイプライン効率性ドキュメントを確認して、GitLab CI/CDパイプラインをより高速かつ高効率的にする方法を学んでください。

追加リソース

JenkinsFileラッパーを使用して、プラグインを含む完全なJenkinsインスタンスをGitLab CI/CDジョブ内で実行できます。このツールを使用して、緊急性の低いパイプラインの移行を遅らせることで、GitLab CI/CDへの移行を容易にしてください。
JenkinsFileラッパーはGitLabにはパッケージ化されておらず、サポート範囲外です。詳細については、サポートに関する声明を参照してください。

ここで回答されていない質問がある場合は、GitLabコミュニティフォーラムが優れたリソースとなりえます。