• 주요 유사점 및 차이점
• 기능 및 개념 비교
  • 구성 파일
  • Jenkins 파이프라인 구문
    • 섹션
    • 지침
  • 일반 구성
    • 작업
      • 병렬
      • 매트릭스
    • 컨테이너 이미지
    • 변수
    • 표현식과 조건문
    • 러너
    • 아티팩트
    • 캐싱
  • Jenkins 플러그인
  • 보안 스캐닝 기능
  • 비밀 관리
• 마이그레이션 계획 및 수행
  • 마이그레이션 계획 작성
  • 필수 조건
  • 마이그레이션 단계
  • 추가 리소스

Jenkins에서 GitLab으로의 마이그레이션

Offering: GitLab.com, 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(클라우드) 또는 자체 관리 배포에서 실행할 수 있습니다. 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 "스테이징에 배포 중"
                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 "스테이징에 배포 중"
    - 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에서는 CI/CD 작업을 별도의 격리된 Docker 컨테이너에서 실행할 수 있습니다

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/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 설정에서 설정할 수도 있습니다. 일부 경우에는 protected 및 masked 변수를 사용하여 비밀 값을 보호할 수 있습니다.

이러한 변수는 구성 파일에 정의된 변수와 동일하게 파이프라인 작업에서 접근할 수 있습니다.

예를 들어, 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 Plugin을 사용하여 처리됩니다. Jenkins 설정에 저장된 자격 증명은 Credentials Binding 플러그인을 사용하여 작업에서 환경 변수로 노출될 수 있습니다.

GitLab에서 비밀 관리를 위해 외부 서비스에 대한 지원되는 통합 중 하나를 사용할 수 있습니다. 이러한 서비스는 GitLab 프로젝트 외부에 비밀을 안전하게 저장하지만, 서비스에 대한 구독이 필요합니다:

• HashiCorp Vault
• Azure Key Vault.

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로의 전환을 용이하게 할 수 있습니다.

  주의:
  JenkinsFile Wrapper는 GitLab과 함께 패키징되지 않으며 지원 범위를 벗어납니다.
  자세한 내용은 지원 성명서를 참조하세요.

여기에 명시되지 않은 질문이 있으면 GitLab 커뮤니티 포럼이 훌륭한 리소스가 될 수 있습니다.