[우아한테크코스 FE 5기]프론트엔드 배포 과정 #3

대망의 배포 자동화에 대해 포스팅할 시간이네요.

이전의 포스팅들이 사실상 어떠한 자세한 설명없이 실행방법만을 기록하거나, 간단히 경험만을 가볍게 풀어낸 것이었다면, 이번 포스팅에서는 현재의 배포 형태를 자세히 뜯어보려고 해요.

프로젝트 6주차까지는 배포를 해주기 위해서는 결국 쉘 스크립트를 실행해주어야하는 수동 배포 형태를 띄고 있었죠? 하지만 개발자로서 수동이라는 단어를 용납할 수 없지 않겠어요? 결코 CI/CD가 프로젝트 요구사항이기 때문은 아니라는 점 알아주세요😅

그래서 저와 라잇이 기능 구현과 UI/UX에 집중하는 동안 윤생이 CD를 위해 아주 애를 써주었고, 그 과정을 옆에서 지켜본 제가 문서화를 해보기로 했습니다.

4. 자동화

2차 데모데이 이후 백엔드 크루들이 도커에 젠킨스를 설치, 배포 자동화도 구현해놓은 상태였습니다. 이에 본격적으로 프론트엔드 인프라 구축에 나선 윤생이 젠킨스 파이프라인 스크립트를 작성하여 Git에서 프로젝트가 merge될 때마다 자동으로 배포가 되도록 하였습니다.

젠킨스 설치 및 초기 설정에 관한 글은 우리 팀 백엔드 크루 깃짱코딩 포스팅에서 확인하실 수 있습니다.

👇👇👇👇

깃짱코딩 블로그

 

그래서 제가 다룰 내용은 젠킨스가 설치된 이후에 배포 자동화 설정에 대한 것입니다.

젠킨스가 설치되어있고, 젠킨스 계정이 있고, 초기 세팅이 되어있으며, 트리거가 merge되었을 때임을 가정하고 진행합니다.

 

 

프로젝트의 구성을 클릭하여 진행해볼게요.

 

1. 깃허브 프로젝트 설정

배포할 때 사용할 소스코드가 존재하는 레포지터리를 설정해줍니다.

2. 파이프라인 스크립트 작성

프로젝트의 develop 브랜치에서 merge하는 행위가 파이프라인의 트리거가 되는데요.

 

그럼 이제 이 파이프라인이 어떻게 동작할 지를 스크립트로 작성하는 절차를 진행합니다.

 

구성 -> pipeline으로 이동하여서

깃 레포지터리에서 develop 브랜치의 소스코드를 가져와 빌드하고, 그 파일을 압축한 뒤, EC2에 보냅니다. 그리고 deploy 단계에서 ec2에 작성해 놓은 run.sh를 실행하여 NGINX 내에서 빌드를 완료합니다.

위와 같은 절차를 진행하는 pipeline 스크립트를 아래와 같이 작성하였습니다.

pipeline {
    agent any
                // 환경변수 설정
        environment {
        NODEJS_HOME = tool name: 'NodeJS', type: 'jenkins.plugins.nodejs.tools.NodeJSInstallation'
        PATH = "${NODEJS_HOME}/bin:${env.PATH}"
    }
    stages {
                // git branch에서 가져옴
        stage('Github') {
            steps {
                git branch: 'develop', url: 'https://github.com/woowacourse-teams/2023-stamp-crush.git'
            }
        }
                // 빌드
        stage('Build') {
            steps {
              dir('frontend'){
              sh 'node -v'
              sh "echo 'REACT_APP_BASE_URL' = 'https://www.stampcrush.site/api' > .env"   
              sh 'npm i && npm run build'    
              }
             }  
        }
              // 빌드된 파일 압축
        stage('compress file') {
            steps {
              dir('frontend') {
                  sh 'tar -cvf dist.tar dist'
              }
            }   
        }
                // 압축된 파일 ssh로 전송
        stage('send file to instance') {
            steps {
                dir('frontend') {
                    sshagent(credentials: ['key-stamp-crush']){
                        sh 'scp -o StrictHostKeyChecking=no dist.tar ubuntu@XXX.XXX.XXX.XXX:/home/ubuntu/frontend'
                    }                    
                }
            }
        }
                // ec2 인스턴스에 있는 쉘 스크립트 실행
        stage('deploy') {
            steps {
                dir('frontend') {
                    sshagent(credentials: ['key-stamp-crush']){
                        sh 'ssh ubuntu@XXX.XXX.XXX.XXX ./frontend/run.sh'
                    }
                }
            }
        }
    }

}

 

./frontend/run.sh

#!/bin/bash

# 압축된 dist 디렉토리의 압축을 해제합니다.
tar -xvf /home/ubuntu/frontend/dist.tar -C /home/ubuntu/frontend

# 압축해제된 dist 디렉토리를 nginx로 이동시킵니다. 
sudo cp -r /home/ubuntu/frontend/dist /usr/share/nginx
# nginx를 다시 시작합니다.
sudo systemctl restart nginx.service
# 필요없는 파일을 지웁니다.
rm -rf ./frontend/dist && rm -rf ./frontend/dist.tar

위 코드는 deploy 스테이지에 실행될 run.sh인데요. 

 

압축하여 전송한 빌드 파일의 압축을 푼 뒤, 해체된 빌드 파일을 NGINX로 이동시킵니다. 이후 이전 포스팅에서 보았던 restart 명령어를 사용하여 NGINX를 재시작하여 배포 자동화를 이룩해내는데요.

 

이 일련의 과정들(deploy의 run.sh동작을 제외한)을 젠킨스의 Stage View에서 라이브로 확인하실 수 있습니다! 

 

예를 들어 develop 브랜치에 merge를 하게 되면!

젠킨스에서 확인할 수 있는 배포 실시간 중계

짜란~ 이제 위와 같이 젠킨스에서 진행 상황을 체크할 수 있구요. 각 열의 타이틀을 보시면 파이프라인 스크립트에서 작성한 stage의 이름들임을 확인할 수 있습니다.

 

이상 저희 스탬프 크러쉬 팀의 CD 과정을 기록한 포스팅이었습니다.

 

읽어주셔서 감사합니다.