[CI/CD-Jenkins] 다양한 형태의 배포 환경에서 Jenkins CI/CD 전략 (feat. ChatGPT)

 

 

🤖

✅ 다양한 형태의 배포 환경에서 Jenkins CI/CD 전략

현재 다양한 배포 방식이 혼재된 상황이므로, 각각의 방식에 맞게 Jenkins에서 CI/CD를 연결하는 전략을 정리해볼게요.

🚀 현재 배포 대상:
1️⃣ Docker Compose로 관리되는 애플리케이션
2️⃣ 독립적인 서버처럼 동작하는 컨테이너 (--privileged --net=host --ipc=host)
3️⃣ 서버 경로에서 직접 배포하는 프론트엔드
4️⃣ 클라우드 (GCP Compute Engine, GCS 버킷 업로드)

➡ 각각의 배포 방식에 맞는 Jenkins 전략을 적용해야 함!

---

🚀 1. Docker Compose로 구동하는 앱 (컨테이너 기반 CI/CD)

✅ 배포 전략: Jenkins에서 docker-compose pull && up 실행

이 경우, Jenkins에서 새로운 이미지 빌드 & 푸시 → 서버에서 docker-compose up -d 실행하는 방식이 적합.

🔹 CI/CD 파이프라인 예시

1️⃣ Jenkins에서 Docker 이미지 빌드 및 푸시

pipeline {
  agent any
  stages {
    stage('Build Docker Image') {
      steps {
        sh '''
          docker build -t my-app:latest .
          docker tag my-app:latest my-registry.com/my-app:latest
          docker push my-registry.com/my-app:latest
        '''
      }
    }
    stage('Deploy to Server') {
      steps {
        sshagent (credentials: ['your-ssh-key-id']) {
          sh '''
            ssh user@your-server "cd /home/user/app && docker-compose pull && docker-compose up -d"
          '''
        }
      }
    }
  }
}

✅ 이렇게 하면 다음 과정이 자동화됨

1. Jenkins에서 코드 변경 감지 → docker build로 새 이미지 생성
2. Docker Hub or 개인 레지스트리에 docker push
3. 서버에서 docker-compose pull && up을 실행하여 최신 이미지 반영
4. 다운타임 없이 배포 가능

---

🚀 2. 독립된 서버처럼 동작하는 컨테이너 (--privileged --net=host --ipc=host)

✅ 배포 전략: SSH로 컨테이너 내부에서 직접 업데이트

이런 컨테이너는 사실상 서버처럼 동작하므로 SSH로 직접 접속해서 업데이트하는 것이 더 자연스러움.

🔹 CI/CD 파이프라인 예시

pipeline {
  agent any
  stages {
    stage('Build') {
      steps {
        sh 'npm install && npm run build'
      }
    }
    stage('Deploy to Privileged Container') {
      steps {
        sshagent (credentials: ['your-ssh-key-id']) {
          sh '''
            scp -r ./dist user@your-server:/var/www/app
            ssh user@your-server "docker exec my-privileged-container systemctl restart my-app"
          '''
        }
      }
    }
  }
}

✅ 이렇게 하면

1. Jenkins에서 빌드 수행 (npm install && npm run build)
2. SSH로 서버에 파일 전송 (scp -r ./dist)
3. 컨테이너 내부에서 직접 애플리케이션 재시작 (docker exec my-privileged-container systemctl restart my-app)

➡ 이 방식이 더 적절한 이유
✔ --privileged --net=host 컨테이너는 마치 서버처럼 동작하므로, 일반적인 Docker 방식(docker stop && rm && run)보다 내부에서 명령 실행이 더 자연스러움.

---

🚀 3. 서버 경로에서 직접 배포하는 프론트엔드

✅ 배포 전략: SSH로 정적 파일 전송 후, Nginx 또는 서비스 재시작

프론트엔드 애플리케이션은 npm run build 이후, 정적 파일을 특정 경로에 업로드하는 방식이 일반적.

🔹 CI/CD 파이프라인 예시

pipeline {
  agent any
  stages {
    stage('Build Frontend') {
      steps {
        sh '''
          npm install
          npm run build
        '''
      }
    }
    stage('Deploy to Server') {
      steps {
        sshagent (credentials: ['your-ssh-key-id']) {
          sh '''
            ssh user@your-server "mv /var/www/frontend /var/www/frontend_backup_$(date +%Y%m%d%H%M); mkdir -p /var/www/frontend"
            scp -r ./build/* user@your-server:/var/www/frontend
            ssh user@your-server "sudo systemctl restart nginx"
          '''
        }
      }
    }
  }
}

✅ 이렇게 하면

1. Jenkins에서 프론트엔드 빌드 (npm run build)
2. SSH를 통해 /var/www/frontend의 기존 파일을 백업 후 새로운 파일 업로드
3. Nginx 또는 서버를 재시작 (systemctl restart nginx)

➡ 이 방식이 더 적절한 이유
✔ 프론트엔드는 단순 정적 파일이라 Docker 컨테이너를 새로 배포할 필요 없이, 파일을 덮어쓰는 방식이 더 효율적.

---

🚀 4. GCP Compute Engine에 배포

✅ 배포 전략: SSH 접속 후 애플리케이션 업데이트

GCP의 Compute Engine도 사실상 하나의 VM이므로, 일반적인 서버처럼 SSH를 이용한 배포가 자연스러움.

🔹 CI/CD 파이프라인 예시

pipeline {
  agent any
  stages {
    stage('Deploy to GCP Compute Engine') {
      steps {
        sshagent (credentials: ['gcp-ssh-key']) {
          sh '''
            scp -r ./build user@gcp-server:/home/user/app
            ssh user@gcp-server "cd /home/user/app && ./deploy.sh"
          '''
        }
      }
    }
  }
}

✅ 이렇게 하면

1. Jenkins가 GCP 서버로 SSH 접속
2. 최신 코드 또는 빌드 파일을 scp로 전송
3. 서버 내부에서 deploy.sh 실행하여 애플리케이션 업데이트

➡ 이 방식이 더 적절한 이유
✔ GCP Compute Engine은 일반적인 서버와 같아서, SSH 배포 방식이 가장 자연스러움.

---

🚀 5. GCP Cloud Storage (GCS) 버킷 업로드

✅ 배포 전략: gsutil cp로 정적 파일 업로드

GCS 버킷은 정적 사이트 배포 또는 백업에 자주 사용됨.

🔹 CI/CD 파이프라인 예시

pipeline {
  agent any
  environment {
    GOOGLE_APPLICATION_CREDENTIALS = '/var/lib/jenkins/gcp-key.json'
  }
  stages {
    stage('Upload to GCS') {
      steps {
        sh '''
          gsutil cp -r ./dist gs://my-bucket-name/
        '''
      }
    }
  }
}

✅ 이렇게 하면

1. Jenkins가 gsutil을 사용하여 GCS에 파일 업로드
2. 필요하면 Cloud CDN 캐시 무효화 (gcloud compute url-maps invalidate-cdn-cache)

➡ 이 방식이 더 적절한 이유
✔ GCS는 정적 파일 업로드만 필요하므로, 간단한 gsutil cp가 가장 적절한 방법.

---

🚀 최종 정리: Jenkins에서 각 배포 방식에 맞춘 CI/CD 연결

배포 대상 CI/CD 방식 실행 방법

Docker Compose 애플리케이션	Docker 빌드 & 푸시 후, 서버에서 docker-compose pull && up 실행	ssh + docker-compose
독립 서버처럼 동작하는 컨테이너	SSH로 컨테이너 내부에서 직접 업데이트	ssh + docker exec
서버 경로에서 배포하는 프론트엔드	SSH로 정적 파일 업로드 후 Nginx 재시작	scp + nginx restart
GCP Compute Engine	SSH로 파일 전송 후 업데이트 스크립트 실행	scp + ssh
GCP Cloud Storage (GCS)	gsutil cp로 파일 업로드	gsutil

🚀 즉, 배포 환경마다 최적의 Jenkins CI/CD 방식이 다르므로, 각 방식에 맞는 전략을 적용해야 함!
추가로 궁금한 점 있으면 질문 주세요! 😊