Himodu의 tech-log

열심히 개발한 SpringBoot 프로젝트를 Docker 를 사용하여 EC2 배포 서버에 배포해보자!

Why Docker?

docker 를 사용하는 데에는 정말 다양한 이점이 있다. 이에 관해서 포스팅한 내용이 있다.

https://himodu-tech.tistory.com/12

직접 개발한 스프링부트 프로젝트를 도커를 통해 배포하기 위해선 다음과 같은 과정이 필요하다.

0. 로컬 환경에 Docker 를 설치한다. (잘 나와있는 자료들이 많아서 생략)

1. 프로젝트 내에 jar 실행파일을 만든다.

2. 프로젝트 내에 Dockerfile 을 만들어 Docker 가 해당 jar 파일을 찾을 수 있도록 한다.

3. 프로젝트에서 터미널을 열어 Docker 명령어를 통해 이미지를 build 한다.

4. build 한 이미지를 Docker Hub 에 공유한다. 

5. 준비된 서버에서 Docker Hub 에 공유된 이미지를 다운(pull)받는다. (서버에는 도커가 설치되어야함)

6. 다운받은 이미지를 가지고 컨테이너를 실행한다.

과정이 조금 길다. 차례차례 살펴보도록 하자

1. 프로젝트 내에 jar 실행파일 만들기

jar 실행파일이란 java 애플리케이션 실행을 위한 모든 파일들을 압축해놓은 하나의 실행가능한 파일로써

흔히 '자르' 라고 부른다.   (교수님들도 그렇게 부르시더라... '자~ㄹ' 파일이라고 부르면 좀 어색해보인다.)

jar 실행파일을 만드는 방법은 gradle 을 사용한다면 매우 간단하다. 

먼저 인텔리제이 우측상단에 코끼리 모양  gradle 아이콘을 누른 다음 tasks -> build -> bootJar 를 선택

그럼 밑에 콘솔 창에서 실행결과를 확인할 수 있고

프로젝트 내에 build/lib 하위 경로에 실행파일이 생성된다.

2. 프로젝트 내 Dockerfile 생성

프로젝트 최상단에 새로운 파일을 만들고 이름을 'Dockerfile' 이라고 지어준다. 토씨 하나도 틀려선 안된다.

 (최상단이 아니어도 좋지만, 이러한 경우 build 시에 경로를 따로 명시해줘야하기 때문에 귀찮다.)

Dockerfile 의 내용은 아래와 같다.

FROM openjdk:17-jdk-alpine

ARG JAR_FILE=build/libs/*.jar

COPY ${JAR_FILE} app.jar

ENTRYPOINT ["java","-jar","/app.jar"]

Dockerfile 이 하는 일은 Docker 가 이미지를 빌드할 때의 정보를 제공해주는 것이다.

위에서 부터

만들 이미지의 기초가 될 java 이미지를 선택하고, (버전을 꼭 맞춰줘야한다.)

jar 파일의 위치를 매개변수로 저장하고

app.jar 라는 이름의 jar 파일로 이를 복사한 다음

'java -jar /app.jar' 라는 명령어를 해당 이미지의 ENTRY POINT 로 설정한다.

ENTRY POINT란 이 이미지를 바탕으로 컨테이너를 실행하는 그 순간 초기에 실행할 명령어를 의미한다.

3. 터미널을 열어 docker 명령어를 통해 이미지를 빌드한다.

docker build -t {도커허브 이름}/{이미지 이름} .

프로젝트 최상단 경로에서 터미널을 열고, 위와 같은 명령어를 입력한다.

여기서 중요한 것은!

이미지의 이름을 정해줄 때 DockerHub에서 사용하는 이름을 앞에, 해당 이미지의 이름을 뒤에 적어줘야 한다는 것이다.

해당 이미지의 이름은 얼마든지 겹칠 수 있으니 이를 식별하기 위해서 앞에 자신의 DockerHub 이름을 붙여주는것이다.

그리고 중요한 것은 마지막에 '.' 이걸 꼭 찍어주자. 이 점이 의미하는 것은 해석할 Dockerfile 이 있는 위치이다.

우리는 방금 최상단에 Dockerfile 을 만들었기 때문에 현재 위치('.')에서 찾을 수 있지만, 만약 다른 곳에 있다면 여기에 도커파일이 있는 파일경로를 적어줘야한다.

4. build 한 이미지 DockerHub에 업로드

Docker를 설치했다면, DockerDesktop 또한 설치되었을 것이다. GUI 로써 도커를 훨씬 편히 이용할 수 있으니 사용하는 것을 추천한다. 그리고 DockerHub 에 꼭 로그인 해주자.

하단에 'Not connected to Hub' 이라고 뜬다면

우측상단에 Sign In 버튼을 눌러 로그인할 수 있다. 소셜 로그인을 지원하기 때문에 어렵지 않을 것이다.

하여튼 성공적으로 이미지가 빌드됐다면, DockerDesktop에 images/Local에 이미지가 보일 것이다.

배포할 이미지의 좌측에 세로 점 3개 버튼을 누르고 'push to Hub' 를 선택하면, Docker Hub에 업로드 되며, DockerDesktop 에 'images/Hub ' 에서 확인할 수 있다.

5 ~ 6 과정은

서버에 도커를 설치하고, Hub에 올라간 이미지를 다운받아 그대로 컨테이너를 실행하는 과정이고

따로 포스팅한 내용이 있다. 아래 링크를 참고하면 된다.

https://himodu-tech.tistory.com/10

아래 영상은 전 과정을 영상으로 기록한 내용이다. (영상이 안뜬다면? = https://www.youtube.com/watch?v=X6Fb6pT11eo)

2020년 20학번으로 경북대학교에 입학하고 난 후 코로나 이슈로 인해 대학교 축제를 경험하지 못했고,  그렇게 복학을 한 2023년에는 총 학생회가 투표율이 과반을 넘지 못해 구성되지 못하여 대학교 축제가 아예 논의조차 되지 않는 그런 어이없는 상황을 겪었습니다.

사실 애초에 대학생활의 낭만에 대한 기대는 크게 없었지만 그래도 그렇게 힘들었던 코로나 팬데믹과 군 생활을 견디고 온 후 맞이한 현실이라고 하기엔 너무 열이 받는 건 어쩔 수 없었습니다. 그리고 그러한 학생들의 불만이 쌓인건지, 드디어 총 학생회가 간신히 투표율이 과반이 넘어 구성되게 되었고, 드디어 대학교에 입학한지 4년만에 제대로 된 축제를 경험하게 되었습니다! 

설레는 마음을 안고, 가장 먼저 든 생각은 "아! 축제 안내 웹페이지를 무조건 만들자!!" 였습니다. 사실 작년부터 다른 학교에서 각 학교의 축제 안내 웹을 제작하여 자랑했었고 그런 모습들을 쭉 보면서 굉장히 부러웠고 굉장히 좋은 프로젝트 경험이 될 것 같았기에 나도 나중에 만들 능력, 여력이 생기면 꼭 만들어서 자랑해야겠다는 생각이 먼저 들었습니다. 또 올해 초 들어서 향후 개발 공부의 방향을 생각하다 뭔가 해커톤 수준의 MVP를 개발하고 끝내는 것이 아닌, 실제로 서비스를 운영할 것을 목표로 개발하여 배포 후 운영해보는 경험이 필요하다고 생각했기에 축제 안내 웹 페이지는 복잡한 기능도 필요 없고, 단기간이긴 하지만 목표 고객층이 뚜렷하며 규모도 꽤 크고 무엇보다 내가 이 도메인 (우리학교 축제)에 굉장히 관심이 많고 열정적으로 몰입할 수 있겠다고 생각하여,  가능하다면 꼭 진행해보고 싶었습니다.

개발을 진행할 팀원을 모으기 위해서 제가 소속되어있는 교내 동아리인 "멋쟁이 사자처럼" 의 동료들에게 해당 프로젝트에 대한 이야기를 꺼내었고, 운이 좋게도 프론트엔드 쪽 개발을 담당해줄 2명을 먼저 모을 수 있었고, 추후에 개발이 진행되면서 백엔드도 두 명 더 합류되고 프론트도 2명이 더 참여하면서 프론트 4 명, 백 3 명 총 7명 정도의 팀원들이 함께하게 되었습니다. 다들 능력이 뛰어난 (제 기준에서...) 동료들이었고, 그래서 7명은 좀 과하지 않나? 라는 생각도 들었지만 개발, 배포, 운영의 과정을 진행해보니 하... 한명이라도 없었으면 정말 큰일 났겠구나 싶었습니다. 저에게 있어서 개발부터 운영까지의 경험은 아예 처음이었기에 너무나도 벅찼습니다.

그래서 결국 서버가 다운되어 DB가 사라지기도 하고, 치명적인 실수를 하여 사용자가 가장 많이 들어올 피크 시간대에 신규유저의 유입을 제한하기도 하고 그 와중에 축제를 즐기는 중이라 제대로 모니터링이 되지 않아 대응이 9시간이나 지체되는 등...

아무래도 운영진들이 모두 학업생활로 바쁜 학생이었고 저희가 자발적으로 만든, 어떤 대가를 받거나 계약을 하고 진행한 것이 아닌 서비스이다 보니 실제로 외주를 받거나 기업에서 진행중인 프로젝트였다면 대번에 해고당했을... 그런 실수들도 많았었습니다.

그런데도 불구하고, Google Analytics 기준 최고 활성 사용자 1.08만명, 이벤트 수 23만 정도의 제 기준에서는 정말 기대 이상의 어마어마한 트래픽이 일어났고, 실제로도 많은 분들이 관심을 가져주시고 서비스에 관련하여 많은 문의를 주셔서 위에서 말했던 저런 오류들이 더더욱 가슴이 아팠습니다... 아직 결혼을 하진 않았고 늦둥이 동생이 있는 건 아니지만 "자식같은 내 서비스" 라는 말이 정말 공감이 되었고, 내 자식이 아프고 다치는게 얼마나 속이 상하는지.. 뭔가 알 것만 같았습니다. 너무 속상해서 잠을 못 이룰 정도로.. 서비스 운영 기간동안은 거의 4시간 이상 잠을 잔 적이 없던 것 같습니다.

하지만 그만큼 깨우치고 배운 것이 정말 많았고, 앞으로의 글 에서는 제가 이 프로젝트의 개발, 배포, 운영 과정에서의 느낀 점을 모두 적어보려 합니다. 저는 이 프로젝트에서 프로젝트 기획, 백엔드 서버개발/배포, DB 등 인프라 구축, 서비스 DB관리, 서비스 운영 등을 맡았고, 해당 작업들에 관한 기술적인 이야기가 될 수도 있고, 구조적인 이야기, 시행착오 혹은 반성문이 될 수도 있을 것 같습니다. 

만약 해당 서비스를 이용하시다 불편을 겪은 분들이 계시다면 정말 고개 푹 숙여 사과드리고 싶습니다... 하여튼 서비스 사용해주신 모든 분들께 정말 감사드리고, 사실 운영하는 동안 죄송하고 속상한 만큼 너무 설레고 기분 좋았었기 때문에 다시 이런 기회가 주어진다면 무조건 하고싶고, 무엇보다 같이 했던 우리 12기 멋사 운영진 들에게 정말 너무너무 고맙다 는 말을 전하고 싶습니다. 

"Thank you For Your Service!!"