고려해야 할 것
- 환경(프로필)에 따라 각기 다른 설정 파일 제공하는 방법
- 로깅
- 패키징
- 배포 방법
배포 시 주의해야 할 것은 설정파일! 😉
여러가지 환경에 따라 각기 다른 설정을 해줘야 하는데 스프링, 스프링 부트에서는 스프링 부트가 제공하는 profile 별 application.properties를 통해서!
spring.profiles.active=local
# 개발할 때에만 create-drop 또는 update를 사용하고 운영 환경에서는 validate를 사용합니다.
spring.jpa.hibernate.ddl-auto=create-drop
# 개발시 SQL 로깅을 하여 어떤 값으로 어떤 SQL이 실행되는지 확인합니다.
spring.jpa.properties.hibernate.format_sql=true
logging.level.org.hibernate.SQL=DEBUG
logging.level.org.hibernate.type.descriptor.sql.BasicBinder=TRACE
server.tomcat.max-http-form-post-size=5MB
app.host=http://localhost:8080
# HTML <FORM>에서 th:method에서 PUT 또는 DELETE를 사용해서 보내는 _method를 사용해서 @PutMapping과 @DeleteMapping으로 요청을 맵핑.
spring.mvc.hiddenmethod.filter.enabled=truelocal에서 개발할 때는 최대한 sql 로깅하고 있고, 로깅하고 싶은 패키지가 있으면 로깅 설정을 할 수 있다. 톰캣 사이즈, 웹 서버 호스트도 중요하다.
application-dev.properties 에다가 개발 환경을 구축을 했었는데 개발 환경에서는 실제로 postgresql (db)를 사용한다.
spring.jpa.hibernate.ddl-auto=update
spring.datasource.url=jdbc:postgresql://localhost:5432/testdb
spring.datasource.username=testuser
spring.datasource.password=testpass
spring.mail.host=smtp.gmail.com
spring.mail.port=587
# 본인 gmail 계정으로 바꾸세요.
spring.mail.username=studyolledev1@gmail.com
# 위에서 발급받은 App 패스워드로 바꾸세요.
spring.mail.password=qetvekwyilxxuxqv
spring.mail.properties.mail.smtp.auth=true
spring.mail.properties.mail.smtp.timeout=5000
spring.mail.properties.mail.smtp.starttls.enable=true한참 local로 사용하다가 db를 postgresql로 갈아탄 다음에 pom.xml에서 h2를 삭제했을 것이다. 지금은 local로 실행할 수 없는 상태이고 그런 의미에서 h2를 남겨놓는 게 좋을 것 같다는...
개발환경은 정해져있는 데이터베이스 설정이 있다. 이 두 설정이 중복되는 값이 있으면 특정한 profile에 있는 값으로 오버라이딩한다.
- application.properties (기본)
- application-dev.properties (dev라는 profile)
기본 설정에 들어가 있는 값들은 일단 기본으로 쓰이면서 dev profile 일때 바뀌는 것이다. application.properties에 db 설정이 없으므로 추가가 될 것이다. smtp 역시 없기 때문에 추가 될 것!
주의해야 할 것
- spring.jpa.hibernate.ddl-auto=create-drop 에서는 validate로 바꿔줘야 한다. 직접 스키마를 관리하는 방법을 사용하는 게 좋다. entity 맵핑이 jpa 맵핑이 db에 제대로 맵핑 되는지를 확인해준다. 만들어주는 게 아니라!
- 만들 때는 스프링부트가 제공하는 스키마닷 sql을 resources 디렉토리에 넣어 생성해주는 방식
- db 를 전문적으로 관리하는 flayway 등을 사용하는 방식
주의해야 할 것
- 로깅
# 개발시 SQL 로깅을 하여 어떤 값으로 어떤 SQL이 실행되는지 확인합니다.
spring.jpa.properties.hibernate.format_sql=true
logging.level.org.hibernate.SQL=DEBUG
logging.level.org.hibernate.type.descriptor.sql.BasicBinder=TRACESQL에 있는 것을 그대로 쓰는 것은 굉장히 위험하다. db가 노출된 것과 마찬가지이다. local이 아니면 보이지 않는 게 좋다. 개발 서버도 외부에 노출되고 패킹을 할 수 있기 때문에 조심해야 한다.
프로필별 설정 파일
- application-{profile}.properties
- 위치에 따른 우선 순위
-- 파일 시스템 “현재 디렉토리/config”에 있는 application-{profile}.properties
- 파일 시스템 “현재 디렉토리”에 있는 application-{profile}.properties
- 클래스패스의 “.config”에 들어있는 application-{profile}.properties
- 클래스패스 루트에 있는 application-{profile}.properties (지금 사용하고 있는 것)
가장 우선 순위가 낮은 설정 파일이 된다.
가장 우선 순위가 높은 파일은 폴더 내 바로 있는 파일
만약 외부에 소스코드를 공개하고 싶지만 설정파일은 공개하고 싶지 않다고 하자. 설정 파일은 private project로 만들어 놓고 application.properties 만 넣어 놓는 것이다. 그리고 이 프로젝트에 공개가 되어도 상관없는 것들은 공개한다.
만약 이 서비스를 운영한다면 비공개 프로젝트에 설정 파일을 넣어놓고 비공개 프로젝트에 있는 파일들은 배포하기 전에 받아오는 과정을 배포 프로세스에게 넣어놓을 것이다. 그 애플리케이션을 실행하는 위치에다가! 즉 2번을 사용하는 것이다.
private project에다가 파일 시스템 “현재 디렉토리”에 있는 application-{profile}.properties 다음과 같은 파일을 넣어두고 현재 실행하는 위치에다가 git pull .. 등 해서 그 다음에 실행하도록 하면 설정 파일을 숨겨놓을 수 있다.
로깅
- 모니터링 시스템과 연동 필요
- 민간한 데이터를 로깅하지 않도록 설정
- 각 배포 환경에 알맞은 로길 설정 필요
지금 우리는 스프링 부트가 기본으로 제공하는 기본 로거, 로깅설정을 하고 있다.
logging.level.org.hibernate.SQL=DEBUG
logging.level.org.hibernate.type.descriptor.sql.BasicBinder=TRACE로그가 콘솔에만 찍힌다. 사실상 운영할 때는 logging.file.name or logging.file.path 와 같이 로그가 특정 위치에 남기도록 해야 한다.
또는 log 설정 파일을 resources 폴더에 넣어 놓으면 거기에 남게 된다. 로깅은 지나치게 많은 로깅은 좋지 않다. 운영환경에서는 디버그 레벨 보다는 에러 레벨로 찍는 게 성능에 유리하다. 그만큼 메세지를 덜 찍기 때문이다.
패키징
- 외부 톰캣 인스턴스에 WAR로 배포할 것인가
- 이미 어떤 다른 서버에서 관리하는 톰캣 인스턴스가 있고, 거기에다가 애플리케이션을 배포한 형태이다.
- 톰캣을 내장한 형태의 JAR로 배포할 것인가
- 이미 어떤 다른 서버에서 관리하는 톰캣 인스턴스가 있고, 거기에다가 애플리케이션을 배포한 형태이다.
이 애플리케이션을 어떤 형태로 배포할 것인지!
기본적으로 스프링 부트가 제공하는 기능 중 하나
mvc clean package패키징으로 하면 java -jar target/*.jar 로 실행할 수 있는 jar 파일 하나가 만들어진다. 이로 인해 배포가 상당히 편리해졌다. (스프링 부트에서 해냄!)
배포방법
- CI / CD 구축 필요
- 선택에 따라 달라진다. 어느 서버 (aws, cafe24 etc..)
CI/CD의 "CD"는 지속적인 서비스 제공(Continuous Delivery) 및/또는 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용됩니다.
mvc clean package
master branch에 들어왔을 때 merge가 되었을 때 실행한다. 모든 test가 ci 서버에서 실행될 것,
- 코드를 변경했을 때마다 CI 서버가 모든 테스트를 실행하고 packaging 한다.
- CD는 코드를 배포할 준비가 됐거나, 주기적으로 특정 환경에 패키징한 애플리케이션을
배포
출처 : 인프런 백기선님의 스프링과 JPA 기반 웹 애플리케이션 개발
https://www.redhat.com/ko/topics/devops/what-is-ci-cd
