Jenkins을 이용한 Spring Boot 배포 자동화

 

로컬에서 Spring Boot 빌드하고 docker image 만들어서 docker hub에 올리고..
EC2 들어가서 docker hub에 있는 이미지 pull 받아서 run 시키기...

 

개발을 하면 할수록 CI/CD의 중요성이 깊게 느껴지는 것 같다... 
배포에 있어서 나와 같이 귀찮음 혹은 어려움을 느끼고 있는 다른 분들을 위해 기록을 남기려고한다

 

 

시작하기에 앞서

 

슬픈 사연 (Jenkins 도입기..)

 

일단 시작하기에 앞서 Jenkins을 도입하기까지의 슬픈 전설이 있다..

 

https://hanjungyo.tistory.com/126

Github Actions 톺아보기

 

원래 위 게시글의 이름은 Github Actions를 이용한 Spring Boot 배포 자동화였다...

 

Github Actions는 GitHub와 연동되기에 굉장히 편리한 기능들이 많았고 난이도도 상대적으로 쉬워서 선택하게 되었는데

 

열심히 글을 쓰던 도중 현재 프로젝트의(졸업 프로젝트) 레포지토리가 대학교 organization에서만 생성을 해야하는데 Repo Setting 권한이 막혀있음...

 

self-hosted runner 환경을 쓰자니 결국 EC2(t2.micro 사용중)에서 빌드를 돌려야 하는 상황이 생기는데 t2.micro에서 시도해본 결과 빌드를 하던 도중 CPU 100%을 뚫고 무한 로딩에 걸려버리는 리소스 이슈가 파악되었기 때문에 Github Actions를 포기했다
(어쩌피 원본 레포지토리에서 runner 등록 못하므로 self-hosted runner도 불가능)

 

AWS Lambda + AWS CodeBuild + GitHub Actions로 레포지토리 Setting을 사용하지 못하는 상황을 우회? 할 수 있을 것 같지만 비용과 네트워크 지연 등으로 Jenkins를 사용하는 것이 더 좋은 선택이라고 생각함

 

=> Jenkins에서 Git Plugin으로 목표로했던 "Git 저장소와 통합하여 트리거"를 할 수 있고 Circle CI, Travis CI 같은 다른 CI/CD 툴들도 살펴보았는데 무료 플랜의 한계 및 비용 이슈도 있기에 오픈소스인 Jenkins를 선택함

 

 

Jenkins란?

 

 

 

Jenkins는 오픈 소스 CI/CD 도구로, 소프트웨어 개발 프로세스를 자동화하는 데 사용됨

 

=> 다양한 플러그인을 지원하여 빌드, 배포, 테스트 등의 작업을 유연하게 수행할 수 있으며 여러 프로그래밍 언어와 버전 관리 시스템을 지원함

 

특징을 살펴보면

 

• 약 1500개 이상의 플러그인을 통해 기능을 확장할 수 있어, 팀의 요구 사항에 맞게 커스터마이즈할 수 있음
  
  
• 파이프라인 기능을 사용하면 CI/CD 프로세스를 코드로 정의할 수 있음
  
  => 버전 관리 시스템에서 파이프라인을 관리할 수 있음
  
  
• 오픈소스이기에 무료로 사용할 수 있고, 커뮤니티가 잘 활성화 되어있음
  
  
• 웹 기반의 대시보드를 제공하기에 빌드 상태와 로그를 쉽게 확인할 수 있음

 

Jenkins는 기본적으로 단일 서버에서 실행되기에 많은 플러그인과 작업을 사용할 경우 리소스를 많이 소모하며 이로 인해 대규모 프로젝트에서 성능이 저하될 수 있음

이를 해결하기 위해서는

Jenkins 에이전트를 설정하여 작업을 분산시키거나 AWS, GCP와 같은 클라우드 서비스를 사용하여 필요한 리소스를 확장하거나, 성능에 영향을 미치는 플러그인을 최소화하고 필수적인 플러그인만 사용하는 것이 좋음

 

 

Jenkins을 이용한 Spring Boot 배포 자동화

 

 

원래 EC2에 Jenkins 서버를 실행시켜놓고 하려고했는데 개발 초기 단계이고 팀 인원도 적기에

비용을 최대한 절약하고자 로컬에서 진행하였습니다.

이렇게 되면 CD를 하기 위해서는 로컬에서 jenkins 서버를 키고 있어야 하기에 인원 한 명이 이를 담당해야함
하지만, 위에서 말한대로 인원도 적고 개발 초기 단계라 아직 빈번하게 merge가 발생하지 않기에 로컬에서 jenkins를 사용하며 비용을 최대한 절약하다가 추후 MVP(Minimum Viable Product)가 완성되면서 추가 기능 구현이 빈번해질 때 EC2 상에 올리는 방식으로 변경 예정

 

EC2에서 Jenkins를 띄우게 될 때 관련 내용도 기록해두도록 하겠습니다.
(방식은 거의 유사함)

 

Mac에서 진행하였습니다‼️

 

1. Jenkins 설치 및 설정

 

터미널에서 brew install jenkins-lts 명령어 입력

 

=> Homebrew를 사용하여 Jenkins를 설치
(시간이 좀 소요되고 Java로 작성되었기 때문에 JDK를 먼저 설치하면 좋음
-> Homebrew에서 자동으로 OpenJDK를 설치하는 경우도 많다고함)

 

 

localhost:8080

 

brew services start jenkins-lts 명령어로 Jenkins 서비스를 시작하고

웹 브라우저를 열어 http://localhost:8080 으로 접속하면 Jenkins에 접근할 수 있음

 

cat /Users/$(whoami)/.jenkins/secrets/initialAdminPassword

 

위 명령어를 통해  초기 암호를 찾은 후 입력해줘야함

 

 

 

그 후 초기 세팅(플러그인)을 해줘야하는데 위에서 말했듯이 필요한 플러그인만 설치하는게 성능면에서 더 좋은 선택이지만 이제 막 처음 써보는 단계이기에 일단 suggested로 설치를 하고 Git과 Docker만 추가 설치를 해줬음

(Dashboard -> Jenkins 관리 -> Plugins에서 추후 설치 가능)

 

 

설치가 완료되면 계정을 생성하는 페이지로 넘어가는데 계정 생성 및 URL을 설정할 수 있음

 

2. SSH 설정

 

SSH 인증 방식

 

SSH(Secure Shell)은 비대칭 암호화 방식을 사용해서 안전하게 원격 서버에 접속하는 프로토콜임

 

=> 공개키와 프라이빗 키로 이루어진 키 쌍을 사용

 

 

클라이언트(접속하는 쪽)가 private key(id_rsa)를 가지고 있고 서버(접속 받는 쪽)이 public key(id_rsa.pub)을 가지고 있어야 통신이 가능함

현재 상황에서 생각해보면 Jenkins에서 GitHub와 EC2에 접근하여 CD작업을 수행해야 하므로

 

• 프라이빗 키 (id_rsa) → Jenkins이 가지고 있어야 함
  
  
• 공개 키 (id_rsa.pub) → 원격 서버(GitHub, EC2)의 ~/.ssh/authorized_keys에 저장되어 있어야 함

 

ssh-keygen -t rsa -b 4096 -C "github 이메일"

 

우선 로컬 터미널에서 위 명령어를 통해 SSH키를 생성하고 id_rsa(프라이빗 키) 와 id_rsa.pub(퍼블릭 키) 값을 복사함

(~/.ssh 에 존재)

Jenkins에서 SSH키 추가

 

이제 Jenkins에 SSH키(프라이빗 키)를 추가해야함

 

(좌) Credentials 클릭 후 화면, (우) System 클릭 후 화면

 

 

Jenkins UI에서 프로필을 클릭하고 Credentials 클릭 -> System 클릭 -> Global credentials에서 Add Credentials 클릭

 

 

ID는 ssh-key로 하였음 (사진에는 github-ssh-key라고 되어있음)

 

 

Kind를 SSH Username with private key로 설정하고 Username으로 git이나 GitHub 사용자이름을 적어주고 Private Key에서 Enter directly로 복사한 SSH 개인 키를 넣어줌 (~/.ssh/id_rsa 의 내용을 넣어줌)

 

GitHub에서  SSH 키 추가

 

위에서 ssh키를 만드는 명령어를 잘 수행했다면 로컬의 ~/.ssh/id_rsa.pub 에 공개키가 담겨져있을텐데

해당 내용을 cat 명령어등으로 확인 후 복사하여

 

 

GitHub 계정의 Settings -> SSH and GPG keys로 이동하여 새로운 SSH 키를 추가해줌 

 

EC2에서 SSH키 추가

 

 

마찬가지로 ~/.ssh 로 이동 후 vi authorized_keys 명령어를 통해 authorized_keys에 로컬에서 만든 SSH키 (id_rsa.pub)의 내용을 넣어줌

 

 

3. Jenkins 파이프라인 생성

 

 

 

Jenkins 대시보드에서 New Item을 클릭한 후 2번째에 있는 Pipeline을 선택

 

4. Poll SCM 설정 (GitHub Webhook 사용 불가 이슈의 대안)

 

맨위에서 말했듯이 현재 fork된 레포지토리에서만 작업해야한다는 제약이 걸려 레포지토리의 Setting을 건들 수 없는 상황이라
GitHub Webhook 추가 후 특정 브렌치의 변경 사항을 전달받아 CD를 진행할 수 없는 상태임

=> 대안으로 생각한 방식이 Poll SCM을 설정하여 특정 주기(시간)마다 Git 저장소를 확인하며 변경 사항이 있으면 작업을 하는 것임

사실 Poll SCM을 사용하는 방식을 하게되면 변경이 없더라도 일정 주기마다 Git 저장소를 확인하므로 불필요한 요청이 많을 수 밖에 없고 정해진 주기만큼의 딜레이가 있을 수 있음(특히 많은 프로젝트 관리하면 성능이...)

하지만 불필요한 요청의 경우 로컬에서 CD 동작을 해야할 때만 Jenkins을 켜서 활용할 것이기에 문제가 없다고 생각했고 딜레이의 경우도 현재는 프로젝트 초기 단계이기에 감수할 수 있다고 생각했음(일단 당장은 수동 배포의 귀찮음을 해소하는 정도로만 사용)

=> 가장 현실적으로 할 수 있는 방안이 Poll SCM!!

 

 

Jenkins 대시보드에서 위에서 만든 Pipeline Job을 클릭해주고

 

왼쪽 구성(Configure) 클릭 후 Triggres 클릭

 

 

 

Poll SCM 선택 후 H/5 * * * * 와 같이 원하는 주기 선택

=> Ignore post-commit hooks는 git commit, push 등의 특정 Webhook 이벤트가 발생해도 무시하도록 설정하는 것임
(어쩌피 Webhook 설정을 못하기에 이벤트가 올리 없지만 확실하게 체크!)

 

H/5 * * * * 는 cron 표현식으로 순서대로 MIN / HOUR / DAY / MONTH / DAT_OF_WEEK를 의미함

=> H(해시) 값을 기준으로 5분마다 실행됨
(*은 와일드카드로 매시간, 매일, 매월, 매요일 실행되므로)

참고로 0/5 와 H/5의 차이는

H는 Jenkins의 해시 값으로 특정 시간에 빌드가 몰리는 걸 방지하기 위해 각 Job마다 다른 시작 시간을 자동으로 배정해줌
(각 Jenkins Job이 동일한 시각에 실행되지 않고 분산해서 실행) 

0/5는 정확히 0, 5, 10 ... 분마다 실행되는거라 모든 Job이 같은 시각에 실행됨

 

 

5. Jenkins에서 환경변수 설정 (+ Docker Hub credentials 설정)

 

 

 

Jenkins 대시보드에서 Manage Jenkins(Jenkins 관리) -> System -> Global properties 섹션에서 Environment variables를 체크한 후 설정할 수 있음

 

• GITHUB_BRANCH : 빌드와 배포에 사용될 GitHub 저장소의 브랜치
  
  => backend/main
  
  
• GITHUB_REPO_URL : GitHub 저장소 URL
  
  (HTTPS말고 SSH URL을 가져와야함)
• GRADLE_TASK : Gradle 빌드 시 실행할 태스크
  
  => clean bootJar
  
  
• DOCKER_BUILD_PLATFORMS : Docker 이미지를 빌드할 대상 플랫폼
  
  => linux/amd64,linux/arm64
  
  
• DOCKER_IMAGE_NAME : 빌드된 Docker 이미지의 이름과 태그
  
  => hjungyo/2025capstone:latest 와 같이 dockerhub-username/your-app:version 의 형태
  
  
• EC2_HOST : 배포 대상 EC2 인스턴스의 퍼블릭 IP
  
  
• EC2_USER : EC2 인스턴스에 SSH 접속할 때 사용할 사용자 이름
  
  => ubuntu (linux라면 ec2-user)
  
  
• CONTAINER_PORT : Docker 컨테이너가 사용할 포트 번호
  
  => 8080

 

이렇게 환경변수 설정을 마치면 끝이 아님!

로컬에서 빌드하여 만든 이미지를 Docker Hub에 올린 후 올라간 이미지를 EC2에서 가져와 컨테이너를 띄우므로 관련 설정을 해줘야함
=> Docker Hub 설정

 

 

위에서 ssh키를 등록했던대로 credentials 설정에서 docker hub 아이디를 Username 필드에, 비밀번호를 Password에 입력 후 Create 하면 됨

 

ID같은 경우는 알아볼 수 있게 dockerhub-credentials라고 명시하였음

 

6. Jenkins Pipeline Script 작성

 

최종 Script는 트러블 슈팅 부분 참고‼️

 

 

Jenkins는 Groovy를 기반으로 CI/CD 스크립트를 작성함 => Groovy는 JVM에서 실행되는 객체 지향 언어임

 

 

마찬가지로 아까 만든 파이프라인의 구성(Configure) 클릭 후 Pipeline을 클릭하면 스크립트를 작성할 수 있음 

 

밑에 체크된 Use Groovy Sandbox는 Jenkins Pipeline에서 Groovy 스크립트를 실행할 때 보안을 강화하기 위해 사용하는 옵션임


=> Sandbox 환경은 코드 실행이 제한된 격리된 환경을 의미함
(특정 메서드나 클래스의 사용이 제한되어 위험한 작업을 방지, 악의적인 코드 실행 방지 등)

 

 

스크립트를 작성해보면

 

pipeline {
    agent any
    
    stages {
        stage('Checkout') {
            steps {
                git branch: env.GITHUB_BRANCH, url: env.GITHUB_REPO_URL
            }
        }
        
        stage('Build') {
            steps {
                dir('backend') {
                    sh "./gradlew ${env.GRADLE_TASK}"
                }
            }
        }
        
        stage('Build and Push Docker Image') {
            steps {
                dir('backend') {
                    withCredentials([usernamePassword(credentialsId: 'dockerhub-credentials', usernameVariable: 'DOCKER_USER', passwordVariable: 'DOCKER_PASS')]) {
                        sh """
                            echo $DOCKER_PASS | docker login -u $DOCKER_USER --password-stdin
                            docker buildx build --platform ${env.DOCKER_BUILD_PLATFORMS} -t ${env.DOCKER_IMAGE_NAME} --push .
                        """
                    }
                }
            }
        }
        
        stage('Deploy to EC2') {
            steps {
                sshagent(credentials: ['ssh-key']) {
                    sh """
                        ssh -o StrictHostKeyChecking=no ${env.EC2_USER}@${env.EC2_HOST} '
                            sudo docker stop \$(sudo docker ps -q --filter ancestor=${env.DOCKER_IMAGE_NAME})
                            sudo docker rm \$(sudo docker ps -aq --filter ancestor=${env.DOCKER_IMAGE_NAME})
                            sudo docker pull ${env.DOCKER_IMAGE_NAME}
                            sudo docker run --platform linux/amd64 -d -p ${env.CONTAINER_PORT}:${env.CONTAINER_PORT} ${env.DOCKER_IMAGE_NAME}
                        '
                    """
                }
            }
        }
    }
}

 

 

 

• 각 stage가 독립적으로 실행되므로dir('backend')를 통해 디렉토리를 이동하는 것을 볼 수 있음
  
  => 현재 GitHub에는 backend와 front 디렉토리가 함께 존재하기에 backend 디렉토리로 이동 후 작업을 수행해야함
  
  
  
• EC2 배포 부분을 살펴보면
   
  • SSH 명령을 사용하여 EC2 인스턴스에 연결하고있는데 -o StrictHostKeyChecking=no 옵션의 경우 초기 연결 시 호스트 키 확인을 건너뛰는 것임
    
    (호스트 키는 SSH 서버의 고유 식별자임 -> 클라이언트가 연결하려는 서버의 신원을 확인하는 데 사용됨)
    
    
    "Are you sure you want to continue connecting (yes/no)?" 프롬프트를 방지
    
    => 보안을 위해 known_hosts 파일을 관리하는게 더 좋음
    (보안 계층 추가)
    
    
    
  • sshagent는 Jenkins 파이프라인에서 SSH 연결을 안전하게 관리하고 사용하기 위한 기능인데 이를 사용하기 위해서는 SSH Agent 플러그인을 설치해줘야함!
    
    

호스트키 확인은 연결하려는 서버가 실제로 의도한 서버인지 확인하는 과정이라고 말했는데
이를 건너뛰면 공격자가 중간에서 통신을 가로채거나 위조된 서버로 연결을 유도할 위험이 있음
(Man-in-the-Middle 이라는 중간자 공격)

=> SSH키 없으면 어쩌피 의미가 없지 않나? 라고 생각을 했는데 찾아보니

암호화된 내용은 볼 수 없겠지만 통신의 패턴, 빈도, 크기 등의 메타데이터를 수집하며 가로챈 데이터를 저장해두고 향후 공격 준비를 할 수 있다는 내용을 보고 보안이 중요하구나를 느꼈음....

 

 

known_hosts 파일을 관리하는 방식으로 파이프라인 스크립트 변경

 

pipeline {
    agent any
    
    stages {
        stage('Checkout') {
            steps {
                git branch: env.GITHUB_BRANCH, url: env.GITHUB_REPO_URL
            }
        }
        
        stage('Build') {
            steps {
                dir('backend') {
                    sh "./gradlew ${env.GRADLE_TASK}"
                }
            }
        }
        
        stage('Build and Push Docker Image') {
            steps {
                dir('backend') {
                    withCredentials([usernamePassword(credentialsId: 'dockerhub-credentials', usernameVariable: 'DOCKER_USER', passwordVariable: 'DOCKER_PASS')]) {
                        sh """
                            echo $DOCKER_PASS | docker login -u $DOCKER_USER --password-stdin
                            docker buildx build --platform ${env.DOCKER_BUILD_PLATFORMS} -t ${env.DOCKER_IMAGE_NAME} --push .
                        """
                    }
                }
            }
        }
        
        stage('Update Known Hosts') {
            steps {
                sh """
                    mkdir -p ~/.ssh
                    ssh-keyscan -H ${env.EC2_HOST} >> ~/.ssh/known_hosts
                """
            }
        }
        
        stage('Deploy to EC2') {
            steps {
                sshagent(credentials: ['ssh-key']) {
                    sh """
                        ssh ${env.EC2_USER}@${env.EC2_HOST} '
                            sudo docker stop \$(sudo docker ps -q --filter ancestor=${env.DOCKER_IMAGE_NAME})
                            sudo docker rm \$(sudo docker ps -aq --filter ancestor=${env.DOCKER_IMAGE_NAME})
                            sudo docker pull ${env.DOCKER_IMAGE_NAME}
                            sudo docker run --platform linux/amd64 -d -p ${env.CONTAINER_PORT}:${env.CONTAINER_PORT} ${env.DOCKER_IMAGE_NAME}
                        '
                    """
                }
            }
        }
    }
}

 

 

Update Known Hosts라는 스테이지를 추가하였고 
ssh-keyscan 명령을 사용하여 EC2 호스트의 SSH 키를 가져오고있음

 

=> 가져온 키를 ~/.ssh/known_hosts 파일에 추가

 

(기존의 StrictHostKeyChecking=no 옵션은 제거하였음)

 

작동 방식을 살펴보면

ssh-keyscan으로 가져온 호스트 키는 ~/.ssh/known_hosts 파일에 저장되고

SSH 연결시, 클라이언트는 서버가 제공하는 호스트 키를 know_hosts 파일의 키와 비교함
=> 키가 일치하면 연결을 진행하고, 일치하지 않으면 경고를 표시

(이를 통해 초기 연결 시 호스트 키를 자동으로 저장하고, 이후 연결에서는 저장된 키를 사용하여 서버의 신원을 확인함)

 

트러블 슈팅

 

 

 

해치웠나..? 라고 생각이 들었다면 뭔가를 놓치고 있다는 뜻!

 

1. 까먹은 application.yaml 파일... (with Permission denied)

 

 

우선 위에서 설정하던대로 Jenkins 관리 > Credentials > System > Global credentials 로 이동 후

kind를 'Secret file'로 하여 로컬에서 사용중인 application.yaml을 올려주었음
(현재 깃허브에는 application.yaml.example만 올라가있기에 로컬에서 사용하는 yaml을 주입하기 위해)

 

        stage('Inject Configuration') {
            steps {
                withCredentials([file(credentialsId: 'application.yaml', variable: 'APP_YAML')]) {
                    sh 'cp -f $APP_YAML backend/src/main/resources/application.yaml'
                }
            }
        }

 

다음과 같이 GitHub에서 Checkout 후에 application.yaml을 추가하는 stage를 넣어주었음

 

이 때, cp 명령어에 -f 옵션을 추가하여 permission denied를 무시하고 강제로 파일을 덮어쓰도록 하였습니다

 

 

2. No credentials specified

 

첫번 째 stage인 Checkout 부분에서 자꾸 No credentials specified 오류가 발생하였음

 

=> Git 저장소에 접근하기 위한 인증 정보가 제공되지 않았음을 나타냄

 

프라이빗 저장소의 경우 적절한 SSH 키나 인증 정보가 필요하기에 이전에 GitHub에 함께 설정해둔 ssh-key를 Script에 명시해줬음

 

    stages {
        stage('Checkout') {
            steps {
                git branch: env.GITHUB_BRANCH, url: env.GITHUB_REPO_URL, credentialsId: 'ssh-key'
            }
        }

 

다음과 같이 credentialsId에 ssh-key를 명시해줬음

 

3. gradlew Permission denied

 

위 에러 같은 경우는 Jenkins 작업공간(workspace)에 있는 gradelw 파일에 대해 실행 권한을 부여해야함

 

        stage('Grant Permission') {
            steps {
                sh 'chmod +x ./backend/gradlew'
            }
        }

 

다음과 같이 스크립트에 Permission 허용을 해주었음

 

4. JDK를 찾지 못하는 오류

 

자꾸 빌드할 때 JDK를 못찾아서 실패했음 

 

여러 블로그들을 설펴보았는데 Docker가 아니라 위에서 진행한 방식대로 Jenkins를 설치하게 되면 JDK가 기본적으로 설정이 되어있지 않는 것 같음

=> 따로 설정해보자!

 

 

 

대시보드에서 Jenkins 관리 -> Tools 에 들어가 ADD JDK를 해주면됨

(Java 17기준)

만약 Java 17이 설치되지 않았다면 brew install openjdk@17 로 설치해줌

 

echo 'export PATH="/opt/homebrew/opt/openjdk@17/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc

 

 

설치가 되었다면 환경 변수를 설정해주면됨

명령어를 살펴보면 $PATH 를 통해 OpenJDK 17의 bin 디렉토리가 기존 PATH 앞에 추가됨

 

=> 이렇게 설정하면 Java 관련 명령어를 입력할 때 시스템은 먼저 OpenJDK 17의 bin 디렉토리에서 해당 명령어를 찾고, 그 다음에 다른 디렉토리들을 검색함

(homebrew로 설치하게 되면 기본적으로 opt/homebrew/opt/openjdk@17 의 경로로 설치가 됨)

 

이제 

 

Jenkins Tools 에서 JAVA_HOME 부분에 

/opt/homebrew/Cellar/openjdk@17/17.0.14/libexec/openjdk.jdk/Contents/Home 라고 설치된 Java의 실제 경로를 입력해줌

 

(이는 /usr/libexec/java_home -v 17를 터미널에 입력 후 설치 경로를 확인할 수 있음)

 

5. docker : command not found

 

위에서 docker 플러그인을 설치했는데 왜 이런 에러가 났을까..?

 

=> 플러그인은 Jenkins와 Docker의 통합 기능을 제공하지만, 실제 Docker 명령어의 위치는 알지 못하기 때문임

 

환경 변수를 설정해서 Jenkins에게 Docker 실행 파일의 정확한 위치를 알려줘야함
(Jenkins가 sh 'docker ...' 명령어를 실행할 때, 시스템의 PATH 환경 변수를 통해 Docker CLI 실행 파일을 찾음)

 

environment {
    PATH = "/usr/local/bin:/Applications/Docker.app/Contents/Resources/bin:${env.PATH}"
}

 

which docker 명령어를 사용할 때 /opt로 시작하는 경로가 나와서 이를 PATH에 적으면 docker-credential-desktop 이라는 오류가 발생함

 

=> Docker Desktop의 인증 도구를 찾지 못해 발생하는 오류

 

Docker Desktop의 기본 설치 경로인 /usr/local/bin:/Applications/Docker.app/Contents/Resources/bin를 PATH에 추가하여 docker-credential-desktop을 찾을 수 있게 해야함

 

현재 로컬에서 Docker Desktop을 설치하여 사용중이기에 ~/.docker/config.json 파일의 credsStore 설정이 "desktop"으로 되어 있음

=> 이 설정 때문에 Docker는 docker-credential-desktop을 찾으려고 하기에 위와 같이 에러가 발생한 것임
(무조건 Docker Desktop을 깔아야하는건 아님!!)

 

위의 PATH를 설정하는 코드를 보고 PATH를 통해 어떻게 명령어가 동작하는지 궁금해서 더 찾아봄

 

운영체제는 PATH에 나열된 디렉토리를 왼쪽에서 오른쪽으로 순차적으로 검색하며 명령어와 일치하는 실행 파일을 찾으면 즉시 그 파일을 실행하고 검색을 중담함
(왼쪽이 우선순위를 가지므로 동일한 이름의 명령어가 여러 디렉토리에 있다면, 가장 왼쪽에 있는게 실행됨)

 

:$PATH를 통해 이어붙이는 이유는 새로운 디렉토리를 추가하면서 기존의 명령어도 계속 사용할 수 있게 하기 위함임
(만약 :를 쓰지 않고 PATH = 으로 끝냈다면 기존에 추가한 PATH들이 사라지기에 다른 명령어들의 사용이 불가능함)

=> 기존의 $PATH 경로 앞에 추가

 

 

또한 Jenkins 파이프라인을 돌릴 때 Docker 데몬이 활성화되어 있어야함

=> Docker Desktop이 실행중이여야함

(Homebrew를 통해 Docker Engine만 설치했다면 다르게 설정)

 

최종 테스트 및 파이프라인 코드

 

pipeline {
    agent any
    
    environment {
        PATH = "/usr/local/bin:/Applications/Docker.app/Contents/Resources/bin:${env.PATH}"
    }

    
    stages {
        stage('Checkout') {
            steps {
                git branch: env.GITHUB_BRANCH, url: env.GITHUB_REPO_URL, credentialsId: 'ssh-key'
            }
        }
        
        stage('Inject Configuration') {
            steps {
                withCredentials([file(credentialsId: 'application.yaml', variable: 'APP_YAML')]) {
                    sh 'cp -f $APP_YAML backend/src/main/resources/application.yaml'
                }
            }
        }
        
        stage('Grant Permission') {
            steps {
                sh 'chmod +x ./backend/gradlew'
            }
        }
        
        stage('Build') {
            steps {
                dir('backend') {
                    sh "./gradlew ${env.GRADLE_TASK}"
                }
            }
        }
        
        stage('Build and Push Docker Image') {
            steps {
                sh 'docker info'
                dir('backend') {
                    withCredentials([usernamePassword(credentialsId: 'dockerhub-credentials', usernameVariable: 'DOCKER_USER', passwordVariable: 'DOCKER_PASS')]) {
                        sh """
                            echo $DOCKER_PASS | docker login -u $DOCKER_USER --password-stdin
                            docker buildx build --platform ${env.DOCKER_BUILD_PLATFORMS} -t ${env.DOCKER_IMAGE_NAME} --push .
                        """
                    }
                }
            }
        }
        
        stage('Update Known Hosts') {
            steps {
                sh """
                    mkdir -p ~/.ssh
                    ssh-keyscan -H ${env.EC2_HOST} >> ~/.ssh/known_hosts
                """
            }
        }
        
        stage('Deploy to EC2') {
            steps {
                sshagent(credentials: ['ssh-key']) {
                    sh """
                        ssh ${env.EC2_USER}@${env.EC2_HOST} '
                            sudo docker stop \$(sudo docker ps -q --filter ancestor=${env.DOCKER_IMAGE_NAME})
                            sudo docker rm \$(sudo docker ps -aq --filter ancestor=${env.DOCKER_IMAGE_NAME})
                            sudo docker pull ${env.DOCKER_IMAGE_NAME}
                            sudo docker run --platform linux/amd64 -d -p ${env.CONTAINER_PORT}:${env.CONTAINER_PORT} ${env.DOCKER_IMAGE_NAME}
                        '
                    """
                }
            }
        }
    }
}

 

 

 

 

EC2에 들어가 sudo docker ps 명령어를 통해 실행중인 컨테이너를 확인해보면 잘 동작하고 있는 것을 볼 수 있음

 

 

 

추가로 간단한 회원가입 로직도 잘 동작하는 것을 확인할 수 있다

 

바라보고 있는 Branch의 커밋 기록의 변화가 생기면 정해진 시간마다 확인 후 스크립트가 실행됨! 

=> 테스트 해보길!!