Jenkinsから移行する

JenkinsからGitLab CI/CDに移行する場合、Jenkinsのワークフローをレプリケートおよび強化するCI/パイプラインを作成できます。

主な類似点と相違点

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

• ジョブのコレクションにステージを使用します。
• コンテナベースのビルドをサポートします。

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

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

機能とコンセプトの比較

多くのJenkinsの機能とコンセプトには、同じ機能を提供するGitLabと同等の機能があります。

設定ファイル

JenkinsはJenkinsfile（Groovy形式）で設定できます。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キーワードで設定されます。

セクション

ディレクティブ

共通設定

このセクションでは、一般的なCI/CI/CD設定GitLab CI/CDに変換する方法を示します。

Jenkinsパイプラインは、新しいコミットのプッシュなど、特定のイベントが発生したときにトリガーされる自動化されたCI/ジョブを生成します。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では、個別の分離されたDockerコンテナでCI/ジョブを実行するには、imageキーワードを使用します。

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

次に、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/設定で設定することもできます。場合によっては、保護された変数とマスクされた変数をシークレット値に使用できます。これらの変数は、設定ファイルで定義された変数と同じように、パイプラインジョブでアクセスできます。

次に、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フリートを使用してジョブを実行できます。

GitLab CI/CDで使用するためにJenkinsエージェントを変換するには、エージェントをアンインストールしてから、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には、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のシークレット管理では、外部サービスでサポートされているインテグレーションの1つを使用できます。これらのサービスは、GitLabプロジェクトの外部にシークレットを安全に保存しますが、サービスのサブスクリプションが必要です。

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

さらに、CI/CD変数に保存することで、ジョブで認証情報を使用できるようにすることもできます。ただし、プレーンテキストで保存されているシークレットは、Jenkinsと同じように、誤って公開される可能性があります。リスクを軽減するために、マスクされた変数と保護された変数に機密情報を常に保存する必要があります。

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

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

移行の計画と実行

次に示す推奨手順のリストは、この移行を迅速に完了できた組織を観察した後に作成されました。

移行計画を作成する

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

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

前提要件

何らかの移行作業を行う前に、まず以下を行う必要があります:

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

移行の手順

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

その他のリソース

• JenkinsFileラッパーを使用して、プラグインを含むGitLab CI/CDジョブ内で完全なJenkinsインスタンスを実行できます。このツールを使用して、緊急性の低いパイプラインの移行を遅らせることにより、GitLab CI/CDへの移行を容易にしてください。

  JenkinsFileラッパーはGitLabにパッケージ化されておらず、サポートのスコープ外です。詳細については、サポートステートメントを参照してください。

ここに記載されていない質問がある場合は、GitLabコミュニティフォーラムが役立ちます。