• 주요 유사성과 차이점
• 기능 및 컨셉 비교
  • 구성 파일
  • Jenkins 파이프라인 구문
    • 섹션
    • 디렉티브
  • 일반 구성
    • 작업
      • 병렬
      • 행렬
    • 컨테이너 이미지
    • 변수
    • 표현식과 조건부
    • Runners
    • 아티팩트
    • 캐싱
  • Jenkins 플러그인
  • 보안 스캐닝 기능
  • 시크릿 관리
• 이주를 계획하고 수행하기
  • 이주 계획 작성
  • 전제 조건
  • 이주 단계
  • 추가 리소스

Jenkins에서의 이주

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(클라우드) 또는 Self-managed 배포 중 하나로 실행할 수 있습니다. Jenkins 배포는 반드시 Self-managed여야 합니다.
• GitLab은 Out of the box로 소스 코드 관리(SCM)를 제공합니다. Jenkins는 코드를 저장하기 위한 별도의 SCM 솔루션이 필요합니다.
• GitLab은 내장된 컨테이너 레지스트리를 제공합니다. Jenkins는 컨테이너 이미지를 저장하기 위한 별도의 솔루션이 필요합니다.
• GitLab은 코드를 스캔하기 위한 내장된 템플릿을 제공합니다. Jenkins는 코드를 스캔하기 위해 3rd party 플러그인이 필요합니다.

기능 및 컨셉 비교

많은 Jenkins 기능과 컨셉은 같은 기능을 제공하는 GitLab의 동등한 기능이 존재합니다.

구성 파일

Jenkins는 Jenkinsfile Groovy 형식으로 구성될 수 있습니다. GitLab CI/CD는 기본적으로 .gitlab-ci.yml YAML 파일을 사용합니다.

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 CI/CD로 변환할 수 있는 일반적으로 사용되는 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 컨테이너 이미지를 사용합니다.
• 코드를 빌드하는 작업을 실행합니다.
  • 빌드된 실행 파일을 artifact로 저장합니다.
• staging으로 배포하는 두 번째 작업을 추가하며:
  • 커밋이 staging 브랜치를 대상으로 하는 경우에만 실행합니다.
  • 빌드 단계에 성공한 후에 시작됩니다.
  • 앞의 작업에서 빌드된 실행 파일 artifact를 사용합니다.

해당하는 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/CD 작업을 실행할 수 있으며, 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에서는 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 설정에서 설정할 수도 있습니다. 경우에 따라 비밀 값에 대한 protected 및 masked 변수를 사용할 수도 있습니다. 이러한 변수는 설정 파일에서 정의된 변수와 동일한 방식으로 파이프라인 작업에서 액세스할 수 있습니다.

표현식과 조건부

새로운 파이프라인이 시작되면 GitLab은 해당 파이프라인에서 실행해야 할 작업을 확인합니다. 변수의 상태 또는 파이프라인 유형과 같은 요소에 따라 작업을 구성할 수 있습니다.

예를 들어, Jenkinsfile에서:

stage('deploy_staging') {
    agent { docker 'alpine:latest' }
    when {
        branch 'staging'
    }
    steps {
        echo "스테이징으로 배포 중"
    }
}

이 예에서는 작업이 커밋 중인 브랜치가 ‘staging’으로 지정된 경우에만 실행됩니다.

동등한 GitLab CI/CD .gitlab-ci.yml 파일은 다음과 같습니다:

deploy_staging:
  stage: deploy
  script:
    - echo "스테이징 서버로 배포"
  rules:
    - if: '$CI_COMMIT_BRANCH == staging'

Runners

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

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

러너에 관한 몇 가지 주요 세부 정보는 다음과 같습니다:

• 러너는 인스턴스, 그룹 또는 단일 프로젝트에 대해 공유로 구성할 수 있습니다.
• 더 정밀한 제어를 위해 tags 키워드를 사용하고 특정 작업에 러너를 연결할 수 있습니다. 예를 들어, 전용 더 강력한 하드웨어 또는 특정 하드웨어를 사용하는 작업에 대한 태그를 사용할 수 있습니다.
• GitLab은 러너를 위한 자동 스케일링을 제공합니다. 필요할 때만 러너를 프로비저닝하고 필요하지 않을 때는 축소할 수 있도록 자동 스케일링을 사용하세요.

예를 들어, Jenkinsfile에서:

pipeline {
    agent none
    stages {
        stage('Linux') {
            agent {
                label 'linux'
            }
            steps {
                echo "안녕하세요, $USER"
            }
        }
        stage('Windows') {
            agent {
                label 'windows'
            }
            steps {
                echo "안녕하세요, %USERNAME%"
            }
        }
    }
}

동등한 GitLab CI/CD .gitlab-ci.yml 파일은 다음과 같습니다:

linux_job:
  stage: build
  tags:
    - linux
  script:
    - echo "안녕하세요, $USER"

windows_job:
  stage: build
  tags:
    - windows
  script:
    - echo "안녕하세요, %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주

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

캐싱

작업이 하나 이상의 파일을 다운로드하고 나중에 더 빠른 액세스를 위해 저장할 때 캐시가 생성됩니다. 동일한 캐시를 사용하는 후속 작업은 파일을 다시 다운로드할 필요가 없으므로 실행이 더 빨리 완료됩니다. 캐시는 러너에 저장되며 만약 분산 캐시가 활성화되어 있다면 S3에 업로드됩니다. Jenkins 코어는 캐싱을 제공하지 않습니다.

예를 들어, .gitlab-ci.yml 파일에서:

cache-job:
  script:
    - echo "이 작업은 캐시를 사용합니다."
  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 변수를 사용하여 사용자정의할 수 있습니다.

시크릿 관리

“시크릿”으로 자주 참조되는 특권 정보는 CI/CD 워크플로우에서 필요한 민감한 정보나 자격 증명입니다. 보호된 리소스를 잠그거나 툴, 응용프로그램, 컨테이너 및 클라우드 네이티브 환경에서 민감한 정보를 해제하는 데 시크릿을 사용할 수 있습니다.

Jenkins에서는 주로 Secret 유형 필드나 자격 증명 플러그인을 사용하여 시크릿 관리를 처리합니다. Jenkins 설정에 저장된 자격 증명은 Credentials Binding 플러그인을 사용하여 작업에서 환경 변수로 노출될 수 있습니다.

GitLab의 시크릿 관리를 위해 지원되는 통합 중 하나를 사용할 수 있습니다. 이러한 서비스는 GitLab 프로젝트 외부에 안전하게 시크릿을 저장하지만 해당 서비스의 구독이 있어야 합니다:

• HashiCorp Vault
• Azure Key Vault.

또한, GitLab은 OIDC 인증을 지원하여 OIDC를 지원하는 타사 서비스에 대한 OIDC 인증을 제공합니다.

또한, 시크릿을 CI/CD 변수에 저장하여 작업에서 이를 사용할 수 있도록 할 수 있지만, 평문으로 저장된 시크릿은 우연한 노출 가능성이 있으므로, Jenkins와 마찬가지로 민감한 정보를 항상 masked 및 protected 변수에 저장해야 합니다.

또한, .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 러너 또는 새 러너를 설치하여 러너(runner)를 사용할 수 있도록 합니다.

이주 단계

1. SCM 솔루션에서 프로젝트를 GitLab으로 이주하기
   • (권장) 사용 가능한 이포터를 사용하여 외부 SCM 공급자에서 자동화된 대량 이포트를 수행할 수 있습니다.
   • URL로 리포지터리 가져오기를 사용할 수 있습니다.
2. 각 프로젝트에 .gitlab-ci.yml 파일을 생성합니다.
3. Jenkins 구성을 GitLab CI/CD 작업으로 이주하고, 해당 작업이 Merge Request에 직접 결과를 표시하도록 구성합니다.
4. 클라우드 배포 템플릿을 사용하여 배포 작업을 이주하십시오.
   • 환경 및 GitLab 쿠버네티스 에이전트를 사용하여 배포 작업을 이주하십시오.
5. 다른 프로젝트 간에 재사용할 수 있는 CI/CD 구성이 있는지 확인한 후, CI/CD 템플릿을 만들고 공유합니다.
6. GitLab CI/CD 파이프라인을 보다 빠르고 효율적으로 만드는 방법을 배우려면 파이프라인 효율성 문서를 확인하십시오.

추가 리소스

• JenkinsFile 래퍼를 사용하여 플러그인을 포함한 완전한 Jenkins 인스턴스를 GitLab CI/CD 작업에서 실행할 수 있습니다. GitLab에 패키지되어 있지 않으며 지원 범위를 넘어섭니다. GitLab 지원 성명을 참조하십시오.

  JenkinsFile 래퍼는 GitLab에 패키지되어 있지 않으며 지원 범위를 넘어섭니다. 자세한 정보는 지원 성명을 참조하십시오.

여기서 답변되지 않은 질문이 있으면 GitLab 커뮤니티 포럼이 유용한 자원이 될 수 있습니다.