DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브 DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브

첫 번째 Jenkins 선언형 파이프라인 구축하기 (CI/CD)

스테이지, 에이전트, 체크아웃, 테스트, 배포 게이트, 자격 증명 및 사후 작업을 포함한 첫 번째 Jenkins 선언형 파이프라인을 구축합니다.

첫 번째 Jenkins 선언형 파이프라인 구축하기 (CI/CD)

첫 번째 Jenkins 선언형 파이프라인은 실용적인 질문에 답해야 합니다: Jenkins가 코드를 체크아웃하고, 빌드하고, 테스트하고, 올바른 브랜치가 통과했을 때만 배포 단계를 실행할 수 있을까요? Jenkinsfile은 앱과 동일한 저장소에 코드로 워크플로우를 제공합니다.

선언형 구문은 예측 가능한 구조(pipeline, agent, stages, steps, post)를 제공하기 때문에 좋은 시작점입니다.

선언형 파이프라인 구조 이해하기

선언형 파이프라인은 전체 워크플로우를 Jenkinsfile이라는 파일에 정의하며, 이 파일은 애플리케이션 코드와 함께 SCM 저장소(예: Git)에 저장됩니다. 이러한 방식을 파이프라인 as 코드라고 합니다.

선언형 파이프라인의 핵심 요소

선언형 파이프라인은 다음 최상위 블록을 포함해야 합니다:

  1. pipeline: 파이프라인 콘텐츠를 정의하는 필수 최상위 블록입니다.
  2. agent: 파이프라인 또는 특정 스테이지가 실행될 위치를 지정합니다(예: any, none 또는 특정 레이블).
  3. stages: 하나 이상의 순차적 stage 블록을 포함합니다.
  4. stage: 작업의 개념적 블록(예: 빌드, 테스트, 배포)을 정의합니다.
  5. steps: stage 내에서 실행되는 하나 이상의 명령 또는 함수를 포함합니다.
pipeline {
    agent any 
    environment { // 선택 사항: 환경 변수 정의
        APP_VERSION = '1.0.0'
    }
    stages {
        stage('Build') {
            steps {
                // 명령어가 여기에 위치합니다
            }
        }
    }
    post { // 선택 사항: 파이프라인 완료 후 실행되는 작업
        always { 
            echo 'Pipeline finished.' 
        }
    }
}

1단계: Jenkins 작업 설정하기

코드에서 파이프라인을 실행하려면 저장소에서 Jenkinsfile을 읽도록 Jenkins 작업을 구성해야 합니다.

  1. Jenkins 대시보드로 이동하여 새 항목을 선택합니다.
  2. 파이프라인 이름을 입력합니다(예: my-first-ci-pipeline).
  3. 파이프라인 항목 유형을 선택하고 확인을 클릭합니다.
  4. 구성 페이지에서 파이프라인 섹션으로 스크롤합니다.
  5. 정의를 파이프라인 스크립트에서 SCM 소스의 파이프라인 스크립트로 변경합니다.
  6. SCM(예: Git)을 선택합니다.
  7. 저장소 URL을 입력하고 필요한 경우 자격 증명을 구성합니다.
  8. 스크립트 경로가 Jenkinsfile(기본값)로 설정되어 있는지 확인합니다.

2단계: CI/CD를 위한 Jenkinsfile 정의하기

성공적인 배포를 위한 표준 스테이지를 통합하여 간단한 CI/CD 워크플로우를 시뮬레이션하는 포괄적인 Jenkinsfile을 생성하겠습니다.

애플리케이션 소스 코드(예: 간단한 Python 또는 Java 프로젝트)와 Jenkinsfile이 루트에 있는 저장소 구조가 있다고 가정합니다.

완전한 선언형 파이프라인 예제

이 파이프라인은 node 에이전트(구성된 경우)를 사용하고 기본 셸 단계(sh)를 활용하여 실제 작업을 시뮬레이션합니다. 배포 스테이지는 조건부이며, 이전 스테이지가 성공적으로 완료된 경우에만 실행됩니다.

// Jenkinsfile
pipeline {
    // 1. 에이전트 정의: 전체 파이프라인이 실행될 위치를 지정합니다
    agent { 
        label 'my-build-agent' // 사용 가능한 경우 특정 레이블을 사용하거나 'any'를 사용합니다
    }
    
    // 2. 환경 변수: 파이프라인 전체에서 사용할 수 있는 변수를 정의합니다
    environment {
        CONTAINER_REGISTRY = 'registry.example.com'
        IMAGE_NAME = 'myapp'
    }
    
    stages {
        
        // 스테이지 1: 체크아웃 (소스 코드 관리)
        stage('Checkout Source') {
            steps {
                // 'checkout scm' 단계는 Jenkins 작업 설정에 정의된 구성을 기반으로
                // 자동으로 코드를 체크아웃합니다.
                checkout scm
                sh 'echo "Source code successfully checked out."'
            }
        }
        
        // 스테이지 2: 빌드 아티팩트
        stage('Build Artifact') {
            steps {
                sh 'echo "Starting build for $IMAGE_NAME:$BUILD_ID"'
                // 시뮬레이션: Docker 이미지 빌드 또는 jar/war 파일 컴파일
                sh "docker build --label build_id=${BUILD_ID} -t ${CONTAINER_REGISTRY}/${IMAGE_NAME}:${BUILD_ID} ."
            }
        }
        
        // 스테이지 3: 테스트 및 품질 게이트
        stage('Run Tests') {
            steps {
                sh './run_unit_tests.sh'
                sh 'echo "Running integration tests..."'
                // 테스트 결과 수집 예시 (적절한 플러그인 필요)
                // junit '**/target/surefire-reports/*.xml'
            }
        }
        
        // 스테이지 4: 배포 (조건부)
        stage('Deploy to Staging') {
            // 'when' 지시문은 특정 조건에서만 스테이지가 실행되도록 보장합니다
            when {
                branch 'main'
            }
            steps {
                sh "docker push ${CONTAINER_REGISTRY}/${IMAGE_NAME}:${BUILD_ID}"
                sh 'kubectl apply -f k8s/deployment-staging.yaml'
                script {
                    // Script 블록은 선언형 단계 내에서 전통적인 Groovy 로직을 허용합니다
                    echo "Deployment successful to Staging environment."
                }
            }
        }
    }
    
    // 3. 사후 작업: 최종 파이프라인 상태에 따라 작업을 정의합니다
    post {
        success {
            echo 'Pipeline completed successfully. Notifying team via Slack...'
            // slackSend channel: '#devops-alerts', message: 'CI/CD Success!'
        }
        failure {
            echo 'Pipeline failed. Review logs for errors.'
        }
        cleanup {
            sh 'docker image prune -f --filter "label=build_id=$BUILD_ID"'
        }
    }
}

3단계: 파이프라인 실행 및 모니터링

Jenkinsfile이 커밋되어 Jenkins 작업에 구성된 브랜치로 푸시되면:

  1. Jenkins 작업 페이지에서 지금 빌드를 클릭합니다(또는 SCM 폴링/웹훅 트리거를 기다립니다).
  2. 빌드 기록 패널에서 빌드를 모니터링합니다.
  3. 실행 중인 빌드 번호를 클릭하고 콘솔 출력을 선택하여 단계별 실행 세부 정보를 확인합니다.
  4. 스테이지 보기 시각화(플러그인이 설치된 경우)를 사용하여 체크아웃, 빌드, 테스트, 배포 스테이지의 진행 상황을 그래픽으로 볼 수도 있습니다.

모범 사례 및 고급 기능

라이브러리 및 공유 코드 활용

복잡하거나 반복적인 단계의 경우 Jenkinsfile에 장황한 Groovy를 직접 작성하지 마십시오. 대신 공유 라이브러리를 사용하십시오. 이러한 외부 라이브러리를 사용하면 여러 파이프라인에서 호출할 수 있는 공통 함수(예: 표준 배포 루틴 또는 알림 함수)를 정의하여 Jenkinsfile을 더 깔끔하게 만들 수 있습니다.

// 공유 라이브러리 단계 호출
stage('Custom Setup') {
    steps {
        customLibrary.initializeEnvironment(env: 'prod')
    }
}

자격 증명 작업

민감한 정보(비밀번호, 토큰, API 키)를 Jenkinsfile에 직접 하드코딩하지 마십시오. Jenkins의 내장 자격 증명 관리 시스템을 사용하십시오.

withCredentials 단계를 사용하면 저장된 비밀을 안전하게 액세스할 수 있습니다:

stage('Authenticate Registry') {
    steps {
        withCredentials([usernamePassword(credentialsId: 'docker-registry-creds', 
                                          passwordVariable: 'PASS', 
                                          usernameVariable: 'USER')]) {
            sh '''
                printf '%s' "$PASS" | docker login \
                  --username "$USER" \
                  --password-stdin "$CONTAINER_REGISTRY"
            '''
        }
    }
}

에이전트 선택

팁: 항상 agent any 대신 label을 사용하여 에이전트를 구체적으로 정의하십시오. agent any를 사용하면 파이프라인이 Jenkins 컨트롤러 노드에서 실행될 수 있으며, 이는 보안 위험이 있고 컨트롤러 성능에 영향을 줄 수 있습니다. 필요한 도구(Docker, Maven, Node.js)가 설치된 Jenkins 에이전트(노드)가 적절히 구성되어 있는지 확인하십시오.

핵심 요점

첫 번째 파이프라인은 지루하고 안정적으로 유지하십시오: 실제 에이전트 레이블을 선택하고, 코드를 체크아웃하고, 빌드하고, 테스트하고, 브랜치별로 배포를 게이트하고, 비밀은 Jenkins 자격 증명에 보관하십시오. 이것이 작동하면 아티팩트 게시, 보안 스캔, 환경 승격을 한 번에 한 단계씩 추가하십시오.