다음은 글은 infrean의 "자바와 스프링 부트로 생애 최초 서버 만들기, 누구나 쉽게 개발부터 배포까지! [서버 개발 올인원 패키지]" 강의의 학습 목적으로 작성된 것입니다. 강의의 디테일한 내용이나, 코드 등은 빠져있을 수 있습니다.
0. 들어가기 전
1) 배포가 무엇인가? 그리고 배포를 위한 준비하기
2) 스프링 서버 실행 시, DB와 같은 설정들을 기존 코드 변경 없이 제어하는 방법을 알아보자
3) Git과 Github에 대해 알아보자
4) AWS의 EC2가 무엇인가? AWS를 통해 클라우드 컴퓨터를 빌려보자
1. 배포란?
최종 사용자에게 SW를 전달하는 과정
사실, 우리가 지금껏 만들었던 도서 관리 서비스는 "로컬"에서 실행/종료 모두 진행된 것이다.
Spring과 MySQL 모두 말이다.
그렇다면 이런 방식을 생각해볼 수 있다.
1) 유저의 컴퓨터에서 우리 컴퓨터로 접속하는 방법...
문제 :
그러나...우리의 컴퓨터(서버)가 24시간 가동시킬 수 없다는 점..
또, 우리는 서버만 켜놓는 것이 아니라 다른 작업도 해야한다.. (자원을 서버 가동에만 쓰지 않는다는 말이다)
나아가 보안의 문제도 있다!!!
2) 전용 컴퓨터(서버 가동만 전담해줄 대여 컴퓨터)에 코드를 옮기고, 그 곳에 Spring, MySQL 등을 설치한다.
이후 유저들이 그 곳으로 접속하게 한다.
Point : 코드를 옮겨야 한다. 또한 코드를 돌릴 수 있는 초기 작업을 해주어야 한다.
=> 이것이 "배포"
정리하자면
최종 사용자에게 SW를 전달하는 과정
= 전용 컴퓨터에 우리의 서버를 옮겨 실행시키는 것
1-1. AWS
우리는 서버를 돌려줄 전용 컴퓨터가 없는데요?
그래서 우리가 아는 아마존에서 클라우드 서비스를 만들어줬다!
AWS(Amazon Web Services)는 아마존 닷컴의 클라우드 컴퓨팅 플랫폼 및 서비스!! (IaaS)
AWS는 기업 및 개발자에게 IT 인프라 및 다양한 서비스를 제공하여 애플리케이션을 구축, 배포, 운영할 수 있는 환경을 제공한다!
컴퓨터에는 기본적인 운영체제(OS)가 깔려 있는데, 보통 서버용 컴퓨터에는 Linux(리눅스)가 깔려 있다!
2. Profile과 H2 DB
2-1. Profile
전용컴퓨터는 전용컴퓨터의 OS(리눅스)에서 JAVA와 DB를 사용해야 한다.
같은 코드를 사용하지만 실행될 때 설정을 다르게 하는 것을 profile이라 한다.
사실 우리는 profile이라는 것을 사용하고 있었다.
Spring Server를 실행시키고 콘솔창을 보면, profile이라는 단어가 눈에 띄인다.
똑같은 서버 코드를 실행시키지만,
local 이라는 profile을 입력하면, H2 DB를 사용하고
dev 라는 profile을 입력하면 MySQL DB를 사용하도록 변경해보자.
2-2. H2 DB 란?
경량 DB로, 개발 단계에서 많이 사용한다.
Disk가 아닌 Memory에 데이터를 저장한다.
메모리에 저장하면? 데이터가 서버를 끄는 순간 휘발된다고 했다!!
그래서 매우 경량 DB이고, 개발 (TEST) 단계에서만 사용된다.
그래서 local 서버에서는 H2 DB를, 실제 사용자 DB를 저장해야할 때에는 MySQL DB를 사용하도록 변경할 것이다!
또한, 개발 단계에서는 테이블과 안의 데이터 값들이 계속 변경되는데,
이렇게 데이터가 휘발되기 때문에 ddl-auto 옵션을 create로 주면 테이블을 가볍게 다룰 수 있어서 코드에만 집중할 수 있다.
*ddl-auto 옵션에 대해 :
create: 기존 테이블을 삭제하고 새로운 테이블을 생성한다. (주의: 기존 데이터는 모두 손실된다.)
update: 기존 테이블을 유지하면서 변경된 내용만 업데이트합니다. 새로운 테이블을 생성하지는 않는다.
validate: 엔티티와 테이블이 일치하는지만 확인하고, 테이블은 만들거나 변경하지 않는다.
none: 자동으로 스키마를 생성 또는 업데이트하지 않는다.
2-3. Profile 적용해보기
//application.yml
spring:
config:
activate:
on-profile: local
datasource:
url: "jdbc:h2:mem:library;MODE+MYSQL:NON_KEYWORDS=USER"
username: "sa"
password: ""
driver-class-name: org.h2.Driver
jpa:
hibernate:
ddl-auto: create
properties:
hibernate:
show_sql: true
format_sql: true
dialect: org.hibernate.dialect.H2Dialect
h2:
console:
enabled: true
path: /h2-console
---
spring:
config:
activate:
on-profile: dev
datasource:
url: "jdbc:mysql://localhost/library"
username: "root"
password: ""
driver-class-name: com.mysql.cj.jdbc.Driver
jpa:
hibernate:
ddl-auto: none
properties:
hibernate:
show_sql: true
format_sql: true
dialect: org.hibernate.dialect.MySQL8Dialect1) spring.config.active.on-profile:
- 어떤 profile에서 활성화 되는 설정인지 지정한다.
- 아랫부분은 dev에서, 기존에 사용하던 MySQL을 사용하도록 하고 (코드 변경 X)
- 윗 부분을 --- 구분선으로 local profile을 작성해보자
2) jdbc:h2:mem:library;NON_KEYWORDS=USER
- H2를 사용하기 위한 url 설정
- 🚨 H2에서는 user라는 키워드가 예약어로 잡혀 있어. 사용하려면 다음 처리를 처리해주어야 한다.
... 생략
2-4. IntelliJ (Ultimate & Community) 에서 스프링부트 active profile 설정하기
1) Ultimate ver.
해당 설정에서 Active profiles : 를 local과 dev로 선택하여 바꿔주면 된다.
2) Community ver.
(자세한 내용은 구글링 참고)
https://adg0609.tistory.com/61
[IntelliJ] IntelliJ profiles 옵션 지정하기
[IntelliJ] IntelliJ profiles 옵션 지정하기 - IntelliJ local, dev 옵션 지정하기 - 개발을 하다보면 local에서 1차 테스트 후, 2차로 dev 서버에 올리는 경우가 있는데 application.yml 에 -dev, -local 이라 명명한 뒤 sp
adg0609.tistory.com
- Ultimate ver. 첫번째 사진과 같은 부분을 클릭
- Modify Options 클릭 후 ADD VM Options 선택.
- VM Options 클릭후 아래의 내용 기입!!!
-Dspring.profiles.active=local
-Dspring.profiles.active=local형식 : - Dspring.profiles.active=프로파일명
- 저장 후 해당 실행 Application 으로 실행!
2-5. H2 Console 확인하기
http://localhost:8080/h2-console/
해당 url로 들어가면, H2에 접속할 수 있는 창이 나온다.
거기에서 JDBC URL : 에 우리가 적었던 url을 복사/붙여넣기 해준다.
user name과, password도 마찬가지.
그리고 CONNECT를 눌러주면, DB를 볼 수 있는 인터페이스가 나온다.
3. Git과 GitHub
3-1. Git이란?
Git은 쉽게 말해 코드를 쉽게 관리할 수 있도록 해주는 버전 관리 프로그램이다.
조금 더 어려운 말로 분산 버전 관리 시스템(DVCS)으로,
형상 관리(Version Control) 도구로써 사용된다!
소스 코드와 같은 리소스의 변경 이력을 관리하는 도구라는 뜻이다.
<소프트웨어 공학> 수업을 들어보면 좀 더 이해하기 편한데...
어쨌든 우리는 현대 사회에서 개발을 할 때!!!
피할 수 없는 것이 있다.
바로 "협업"이다!!!
이게 참 처음 개발 협업을 해보면 느끼는 건데...
공사나 현실 세계의 일들은 사람이 많아지면 많아질 수록 시간이 단축되는데,
코딩은 사람이 많아질 수록 뭔가 더 걸리는 느낌이다....
협업의 복잡성, 코드 충돌과 통합, 코드 일관성 유지의 어려움, 커뮤니케이션 오버헤드, 테스트 및 디버깅의 어려움....
협업하다보면, 오히려 혼자하는 것이 편하다는 생각이 들때도 있다ㅠㅠ
어쨌든 서론은 이쯤하고,
우리는 결국 회사에 들어가면, "따로 개발하고 결국 코드를 합치는 과정"을 빼놓을 수 없을 것이다.
손쉽게 개인의 최종본(commit 후 push in branch)을 뽑을 수 있게 해주고,
개개인의 여러 최종본을 합친 "합본(merge)"을 쉽게 만들 수 있는 TOOL이 필요했다.
(사실 합치는 과정이 상당히 어렵다!ㅜㅜ)
그래서 나온 것이 바로 "GIT"
3-2. GitHub란?
그렇다면, GitHub란 무엇인가!?!?
Git 저장소 호스팅 서비스 중 하나로, Git을 사용하여 관리되는 프로젝트를 온라인 상에서 저장하고 공유할 수 있는 플랫폼이다.
git으로 관리되는 프로젝트의 코드가 이곳에 저장된다!
그렇다면 왜 GitHub에 저장해야 할까?
우리 컴퓨터는 LOCAL
GitHub는 REMOTE(원격) 이다.
local에만 저장해두면, 내 컴퓨터에 있는 코드는 모종의 이유로 소실 될 수 있다!
그래서 백업의 용도로 원격 저장소에 올려두는 것이다!
그리고 또 중요한 이유!
정적인 웹 페이지를 호스팅할 수 있는 GitHub Pages라는 서비스를 제공하고,
자동화 도구로써 CI/CD(Continuous Integration/Continuous Deployment) 서비스인 GitHub Actions도 제공한다!
일단, 지금 중점적으로 볼 것은 "배포" 할 수 있게 해준다는 것이다!
원격 보관해준다는 점을 활용하여, 배포할 전용 컴퓨터 (AWS CLOUD)에 옮겨주는 역할을 해줄 수 있다!
3-3. Git 기초 사용법
(대부분의 깃 사용법을 알기 때문에 간단히만 적어놓겠당)
IntelliJ Terminal을 이용해 git 명령어를 써보자!
git init : 이 프로젝트를 이제 git이 관리하겠다.
git remote add origin [github 주소] : git 프로젝트의 github 원격저장소 설정
Git이 사실 사용하다보면, 진짜 에러도 많이나고, 적응하기까지 너무 오래걸린다..
(아직도 골아플때가 많다.)
각 명령어가 어떤 느낌인지를 이해하는 것이 더 좋을 것 같다.
* 우리는 "로컬 저장소의 코드를 원격 저장소로 보내는 행위"를 할 것이다.
1. 내가 변경한 코드를 박스에 담는다.
2. 박스를 포장하고 송장을 붙인다. 이때 하고 싶은 말도 적을 수 있다.
3. 택배 박스를 원격저장소로 보낸다.
<그리고 추가적으로 말하지만 "협업 툴"이기 때문에, 작업할 당시외에는
원격저장소와 내 집(local)의 내용물이 항상 일치해야 한다.>
1) git add .
:변경된 모든 파일을 스테이징 영역에 추가한다.
스테이징 영역을 박스라고 비유했다.
변경된 파일들을 기록하기 전에 일시적으로 보관하는 곳 이다.
. 은 모든 파일을 의미하며, 일부 파일 명을 적을 수도 있다.
*추가) git status
: 현재 저장소의 상태를 확인한다.
어떤 파일이 변경되었고, 스테이징 영역에 있는지 등을 보여준다.
박스를 다시 뜯어서 확인하는 행위를 생각하면 편하다.
2) git commit –m “메시지”
: 테이징 영역에 있는 변경 사항을 로컬 저장소에 확정(커밋)한다.
-m은 커밋 메시지를 직접 명령어 뒤에 작성할 수 있도록 하는 옵션이다.
commit을 포장하고, 송장을 붙이는 형태. (전송을 확정)
-m "message"를 송장에 붙이는 메시지라고 생각하면 편하다.
3) git push –-set-upstream origin master
git push –-set-upstream origin main
: 로컬 저장소의 변경 사항을 원격 저장소에 업로드한다.
--set-upstream 옵션은 현재 브랜치를 원격 저장소의 마스터 브랜치에 연결한다. (최초 1회만 사용하면 된다)
요즘에는 master이라는 단어보다는 main이라는 단어를 default로 사용한다.
이후에는 git push origin main만 해주면 된다!
그리고 추가적으로 아까, "원격저장소와 내 집(local)의 내용물이 항상 일치해야 한다." 라고 했다.
그래서 push 전에는, 항상 pull을 땡겨와서
원격 저장소와 내 로컬의 내용물을 동기화시킨 뒤에 push 해야 한다!!!
그런데 2번 git status 명령어를 쳐보니
로컬 설정 파일이나, 환경파일, key나 id,password가 들어있는 파일 등도 같이 박스에 담겨있는 것을 볼 수 있다!
이러한 파일은 이후 git 원격 저장소에 올리지 않기 위해 제외시켜줘야 한다.
->
.gitignore 파일은 Git 저장소에서 제외하고자 하는 파일이나 디렉토리 목록을 지정하는 데 사용한다.
// .gitignore
build/
.gradle/
.idea/
*추가 ) git reset
: git add . 이후 들어간 스테이징 영역에 있는 코드들을 빼주는 코드이다.
4. AWS의 EC2 사용하기
(회원가입)로그인 후 -> 메인화면 -> 오른쪽 상단에 지역을 "아시아 태평양 (서울)"으로 변경
우리가 이용할 것은 AWS EC2 서비스!
Amazon Elastic Compute Cloud (Amazon EC2)는 AWS에서 제공하는 클라우드 컴퓨팅 서비스 중 하나이다.
Amazon EC2를 사용하면 가상 서버(인스턴스)를 실행할 수 있다.
이를 통해 탄력적으로 원격 컴퓨터를 사용할 수 있다!
"탄력적"이라는 용어는 클라우드 컴퓨팅에서 자주 사용되는데,
주로 리소스의 확장성과 유연성을 나타낸다.
쉽게 말해, 트래픽 수요의 증가 감소에 따라 자동으로 서버 자원을 확장 축소 하고,
원할 때 빌리고, 반납하는 행위가 자유로운 것을 의미한다.
이후, EC2 페이지에 들어가면 하단의 화면이 뜰 것이다.
인스턴스란 우리가 빌린 원격 컴퓨터, 즉 가상 서버를 의미한다.
왼쪽바의 인스턴스 혹은, 중앙에 인스턴스(실행 중)을 누르면, 인스턴스 창이 뜨고,
오른쪽 상단의 인스턴스 시작을 눌러 가상 서버를 빌릴 수 있다.
이제 엄청나게 복잡한 목록이 나오게 된다...
차근차근 설명해보겠다.
4-1. 인스턴스 목록
- 이름 및 태그
- 우리가 빌릴 컴퓨터의 이름을 지정. 원하는 대로 naming해주면 된다.
- 애플리케이션 및 OS 이미지
( Application and OS Images (Amazon Machine Image) )- 이전에 말했던 서버 가동을 위한 OS 를 선택하는 과정이다.
- 디폴트 값인 Amazon Linux 운영 체제를 선택
- 인스턴스 유형
- 가상 서버의 사양이다.
- CPU / memory 등의 하드웨어 사양을 결정한다.
- 디폴트 값인 t2.micro를 선택 (계정 생성 후 첫 1년 동안 무료; 우측에 프리 티어 사용 가능 표시)
- X.Y와 같은 형태의 인스턴스 유형이 있는데,
X : 컴퓨터의 성격과 세대
Y : 컴퓨터의 성능을 의미
- 키 페어(로그인)
- 우측의 "새 키 페어 생성" 클릭
- 우리가 빌린 가상 서버에 접속할 때 필요한 보안 file (키 페어)
- 이 키 페어를 보관해두어야 한다.
- RSA와 .pem 유형은 건들지 말고, 키 페어 이름만 설정해주자. (파일명)
- 그렇게 "키 페어 생성" 을 클릭하면, 본인이 설정한 이름.pem 의 파일이 다운로드 될 것이다.
- 네트워크 설정
- 방화벽이라고 생각하면 편하다.
- 보안 그룹 생성 클릭
- 이후에 서버에 접속 access/deny 할 port를 설정해 줄 수 있다.
- 스토리지 구성
- 빌릴 서버의 disk 용량을 결정한다.
- 디폴트 값인 8GB로 두자.
- 고급 세부 정보
- 여러 세부 옵션을 설정할 수 있다. (현재 수준에서는... 건드릴 것은 없어보인다.)
- -> "인스턴스 시작" 을 클릭하여 대여해보자!
자, 이제 배포를 위한 준비는 모두 끝났다!
실제로 배포해보자!!!
