이전에 Webhook을 통해서 GitLab으로 부터 특정한 branch로 부터 Open Merge Request나 Push 작업이 실행하게되면 Jenkins가 해당 브랜치의 프로젝트의 클론을 진행했다.
이 프로젝트는 EC2에 접속해서 cd /var/lib/jenkins/workspace/${Jenkins Job 이름}/으로 해당 프로젝트를 확인할 수 있다.
추가적으로 이 프로젝트는 계속해서 덮어씌어져 여러번의 Webhook이 작동해도 하나의 프로젝트만 존재한다.

이어서 해당 Webhook이 걸리게 되었을때 CI/CD를 진행할 수 있도록 구현해보자

CI 구축

우선 먼저 EC2에 접속해서 클론해온 프로젝트를 ./gradlew bootJar 명령어를 통해서 jar파일을 생성해보려고 한다.

EC2에서 접속해서 빌드

Jenkins를 이용한 CI를 구현하기 전에 EC2에 직접 접속해서 ./gradlew bootJar 명령어를 사용해서 직접 빌드를 확인해보자

sudo chmod +x gradlew 를 사용해서 gradlew를 사용할 수 있는 권한을 부여한 뒤 진행

트러블 슈팅

• ./gradlew 접근 거절
  • 해당 명령어를 실행할 수 있는 권한이 존재하지 않다고 에러가 발생했다
  • sudo chmod +x graldew를 사용해서 권한을 부여하고 진행
    • 위 코드는 파이프라인 작성할때도 추가해줘야함
• Jenkins가 아니라 EC2에 직접 접속해서 빌드 진행시 빌드가 멈추는 현상 발생
  • 위 현상을 찾아보니 free Tier로 ec2를 진행하면 ram 크기가 2기가라서 멈춤현상이 발생한다고 한다.
  • 램 크기 확장을 참고해서 랩 크기를 늘려주자
  • 안되면 아래 코드 참고

    스왑 메모리 설정
    // swap 파일을 생성해준다. 
    // (메모리 상태 확인 시 swap이 있었지만 디렉토리 파일은 만들어줘야한다.)
    sudo mkdir /var/spool/swap
    sudo touch /var/spool/swap/swapfile
    sudo dd if=/dev/zero of=/swapfile bs=128M count=16bs=1024
    // swap 파일을 설정한다.
    sudo chmod 600 /var/spool/swap/swapfile
    sudo mkswap /var/spool/swap/swapfile
    sudo swapon /var/spool/swap/swapfile
    // swap 파일을 등록한다.
    sudo echo '/var/spool/swap/swapfile none swap defaults 0 0' | sudo tee -a /etc/fstab
    // 메모리 상태 확인
    free -h

    

Jenkins에서 CI 구현

EC2에서 정상적으로 작동되는 것을 확인했으니 빌드 시킬 수 있는 파이프라인을 작성해서 실행해보자

 pipeline {
    agent any



    stages {
        stage('Clone') {
            steps {
               git branch: 'dev', credentialsId: 'qkrtprjs', url: 'https://lab.ssafy.com/qkrtprjs456/test.git'
            }
            post {
                failure {
                  echo 'Repository clone failure !'
                }
                success {
                  echo 'Repository clone success !'
                }
            }
        }
        stage('Build'){
            steps{
                sh 'pwd'
                sh 'chmod +x gradlew' // 실행 권한 추가
                sh './gradlew bootJar'
            }
            post {
                failure {
                  echo 'Repository build failure !'
                }
                success {
                  echo 'Repository build success !'
                }
            }
        }
    }
}

---

트러블 슈팅

빌드 과정에서 무한으로 대기하는 현상 발생

• 메인 사용공간이 거의 없는 것을 확인
• 메인 용량을 늘리기위해 AWS의 EBS(Elastic Block Store)를 통해 볼륨의 크기를 30GB로 수정
  • EBS는 서비스의 이름이며, 특정 기능을 제공하는 플랫폼입니다.
  • 볼륨은 EBS 서비스를 통해 사용하는 개별 저장소로, 데이터 저장 및 관리를 담당합니다.
• lsblk 명령어로 용량 확인
  • 볼륨 크기는 30 GB커졌지만 /dev/xvda 의 파티션인 /dev/xvda1 은 아직 8GB인 상태.
• sudo growpart /dev/xvda 1 명령을 통해 파티션의 크기를 증가
  
• 파티션의 크기를 늘렸으면 이제 파일 시스템의 크기를 늘려주어야한다
  • 볼륨 : EC2에서 사용하는 전체 저장소
  • 파티션 : 볼륨을 나누는 개념, 특정 용도별로 나눔
  • 파일 시스템 : ec2내에서 사용하는 파일 시스템, 이 부분을 우리가 직접 사용하는 부분이된다.
• sudo resize2fs /dev/xvda1 명령어 입력
  
  • 정상적으로 파일시스템의 크기가 증가한것을 확인

---

• 정상적으로 빌드를 완료하여 jar 파일을 생성하는 것을 확인

---

생각해볼 점

CheckOut vs Clone

Webhook이 걸렸을때에 해당 코드를 jar 파일로 만들어서 빌드를 진행하고 배포까지 진행할 과정을 계획하고있다.
이 때마다 매번 Clone을 진행하는 과정과 한번 파일을 Clone 해놓고 다음부터는 CheckOut으로 진행하는 과정중에 어떤 과정이 더 효율적일지 생각해보자