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 키워드로 구성됩니다.

섹션#

지시문#

공통 구성#

이 섹션에서는 자주 사용되는 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에 배포하는 두 번째 잡을 추가하며, 이 잡은:
  • 커밋이 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

이 경우, 잡을 병렬로 실행하기 위한 추가 구성이 필요하지 않습니다. 잡은 기본적으로 병렬로 실행되며, 충분한 러너가 있다고 가정하면 각각 다른 러너에서 실행됩니다. 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에서는 variables 키워드를 사용하여 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/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'

러너#

Jenkins 에이전트와 마찬가지로 GitLab 러너는 잡을 실행하는 호스트입니다. GitLab.com을 사용하는 경우, 자체 러너를 프로비저닝하지 않고도 인스턴스 러너 플릿을 사용하여 잡을 실행할 수 있습니다.

Jenkins 에이전트를 GitLab CI/CD에서 사용하도록 변환하려면 에이전트를 제거한 다음 러너를 설치하고 등록합니다. 러너는 많은 오버헤드가 필요하지 않으므로 사용하던 Jenkins 에이전트와 유사한 프로비저닝을 사용할 수 있습니다.

러너에 대한 몇 가지 주요 세부 정보:

• 러너는 인스턴스 전체, 그룹 또는 단일 프로젝트 전용으로 구성할 수 있습니다.
• tags 키워드를 사용하여 더 세밀하게 제어하고 러너를 특정 잡과 연결할 수 있습니다. 예를 들어, 전용되거나 더 강력하거나 특정 하드웨어가 필요한 잡에 태그를 사용할 수 있습니다.
• GitLab에는 러너 자동 확장이 있습니다. 자동 확장을 사용하여 필요한 경우에만 러너를 프로비저닝하고 필요하지 않을 때는 축소합니다.

예를 들어, 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

캐싱#

캐시는 잡이 하나 이상의 파일을 다운로드하고 향후 더 빠른 접근을 위해 저장할 때 생성됩니다. 동일한 캐시를 사용하는 후속 잡은 파일을 다시 다운로드할 필요가 없으므로 더 빨리 실행됩니다. 캐시는 러너에 저장되고 분산 캐시가 활성화된 경우 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에서의 시크릿 관리를 위해 외부 서비스에 대한 지원되는 통합 중 하나를 사용할 수 있습니다. 이러한 서비스는 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 또는 기타 클라우드 제공업체 또는 배포 대상?

사전 조건#

마이그레이션 작업을 시작하기 전에 다음을 먼저 수행해야 합니다:

1. GitLab에 익숙해지기.
   • 주요 GitLab CI/CD 기능에 대해 읽어보세요.
   • 첫 번째 GitLab 파이프라인 생성 및 정적 사이트를 빌드, 테스트, 배포하는 더 복잡한 파이프라인 생성 튜토리얼을 따라하세요.
   • CI/CD YAML 구문 레퍼런스를 검토하세요.
2. GitLab 설정 및 구성하기.
3. GitLab 인스턴스 테스트하기.
   • 공유 GitLab.com 러너를 사용하거나 새 러너를 설치하여 러너가 사용 가능한지 확인하세요.

마이그레이션 단계#

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 Wrapper를 사용하여 GitLab CI/CD 잡 내에서 플러그인을 포함한 전체 Jenkins 인스턴스를 실행할 수 있습니다. 덜 긴급한 파이프라인의 마이그레이션을 지연하여 GitLab CI/CD로의 전환을 쉽게 하는 데 이 도구를 사용하십시오.

  [!note] JenkinsFile Wrapper는 GitLab과 함께 패키지되지 않으며 지원 범위를 벗어납니다. 자세한 정보는 지원 성명을 참조하십시오.

여기에서 답을 찾지 못한 질문이 있는 경우, GitLab 커뮤니티 포럼이 훌륭한 리소스가 될 수 있습니다.