application.properties를 프로젝트 내부에 두고 사용한다 하더라도, 여전히 이전 강의와 동일한 문제점이 있는 거 아닌가요?
195
작성한 질문수 2
1. 강의 내용과 관련된 질문인가요? 예
2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예
3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예
[질문 내용]
안녕하세요!
이전 강의(설정 데이터1 - 외부 파일)를 보면,
application.properties를 외부에 두고 사용할 경우, 다음과 같은 문제점이 있다고 말씀하셨습니다.
"application.properties의 내용을 변경해야 하는 경우에 만약 10대의 서버를 운영 중이라면,
10대의 서버에 있는 application.properties의 내용을 모두 일일이 변경해 주어야 하는 불편함이 있다."
그런데 이 문제점은 이번 강의처럼 application.properties를 프로젝트 내부에 두고 사용한다 하더라도,
여전히 남아 있는 문제점 아닌가요?
답변 2
1
안녕하세요. WTeobp님, 공식 서포터즈 y2gcoder입니다.
사진과 함께 봐주시면 감사하겠습니다. 특히 해당 상황은 배포와 밀접한 관련이 있습니다!
위의 사진이 애플리케이션 외부에 설정 파일이 위치할 때, 아래의 사진이 애플리케이션 내부에 설정 파일이 위치할 때입니다.
위의 사진과 같이 애플리케이션 외부의 서버 인스턴스 내에 설정 파일이 위치할 때, 공통 설정 값을 변경해줘야 한다면 N개의 서버 인스턴스를 일일이 들어가서 설정값을 수정해줘야 합니다!
반면에 아래의 사진과 같이 애플리케이션 내부에 설정파일로 관리한다면 공통 설정 값을 변경하기 위해 N개의 서버 인스턴스 내부로 일일이 들어갈 필요 없이 공통 설정값을 변경한 애플리케이션을 배포하면 각 N개의 서버 인스턴스에 공통 설정값이 변경된 애플리케이션이 자동으로 배포되게 됩니다. 외부 설정값에서 언급한 불편함은 이런 부분이라고 생각해주시면 감사하겠습니다!
감사합니다.
0
답변 감사합니다!
무슨 말씀인지 느낌이 오긴 하는데...
그런데 설정 파일이 애플리케이션 내부에 위치해 있는 경우에도
결국 설정 파일을 수정하는 행위는 1번만 하면 될지 몰라도,
대신 배포하는 행위를 N번, 즉 N대의 서버에 일일이 다시 배포해 주어야 하는 거 아닌가요?
그럼 결국 이 경우에도 설정 파일 수정에 의한 불편함이 여전히 남아 있는 건데,
왜 설정 파일이 외부에 위치해 있는 경우에만 해당하는 문제점처럼 말씀하신 거지...?
라는 의문이 들어서 질문드렸습니다.
제가 별거 아닌 걸 가지고, 잘못된 방향으로 너무 오래 생각하고 있는 것 같네요...
죄송합니다.
1
아닙니다 ㅎㅎ
그런데 설정 파일이 애플리케이션 내부에 위치해 있는 경우에도
결국 설정 파일을 수정하는 행위는 1번만 하면 될지 몰라도,
대신 배포하는 행위를 N번, 즉 N대의 서버에 일일이 다시 배포해 주어야 하는 거 아닌가요?
=> 저는 이 경우는 배포방식을 자동화해줌에 따라 편하게 개선할 여지가 있다고 생각합니다 🙂 항상 10대의 서버에 배포를 하는 애플리케이션이라면 코드를 git으로 푸시했을 때 빌드한 결과물을 10대의 서버에 배포되도록 자동화할 수 있습니다. 그렇다면 일일이 서버에 배포할 수고로움을 덜 수 있을 것 같습니다.
0
안녕하세요, 인프런 AI 인턴입니다.
WTeobp님께서 설명해주신 문제는 실제 운영 환경에서 중요한 고려 사항입니다. application.properties 파일을 프로젝트 내부에 두는 경우에도 서버 여러 대의 설정을 개별적으로 관리하는 불편함이 있을 수 있습니다. 이 문제점을 해결하기 위해 보통 다음과 같은 방법을 고려할 수 있습니다:
환경별 프로필 사용: Spring Boot에서는 다양한 환경 (예: 개발, 테스트, 운영 등)에 맞춰 다양한 프로필을 사용할 수 있게 해줍니다. 각각의 환경에 알맞는
application-{profile}.properties파일을 만들어 환경별 설정을 쉽게 관리할 수 있습니다.외부 설정 파일 활용:
spring.config.location속성을 활용하여 애플리케이션이 실행될 때 외부 경로로부터 설정 파일을 불러올 수 있습니다. 이렇게 하면 실제 배포된 환경의 설정을 쉽게 관리할 수 있으며, 모든 서버에서 통일된 파일을 사용할 수 있습니다.구성 서버 사용: Spring Cloud Config처럼 중앙 관리 서버를 사용하는 방법도 있습니다. 이를 통해 여러 서버의 설정을 중앙에서 관리하고 자동으로 업데이트할 수 있습니다.
아래 링크에서 유사한 주제를 다루고 있는 질문을 확인하실 수 있습니다:
- application.yml vs application.properties
위에서 설명한 내용이 현재 질문의 맥락을 잘 설명하는 데 도움이 되었길 바랍니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
보안이 엄격한 데이터
0
73
1
MyProperties 자체를 클라이언트 코드에서 사용
1
43
1
http://localhost:8080/actuator/prometheus
0
85
3
jar 추가에대한 질문드려도될까요?
0
64
1
build.gradle bom link 변경
0
65
2
@Counted 초기화
0
47
1
@Validated를 적용해도 빈 검증이 안되는 경우에 대한 조치 공유..
0
101
2
springboot에서 actuator없이 micrometer를 사용할수 있나요?
0
67
1
@Configuration 질문드립니다.
0
84
2
[공유] 터미널 말고 IDE 에서 jar 실행하기
0
100
1
localhost:8080/hello-servlet 404오류
0
123
2
내장톰캣2 서블릿 톰켓 실행이 안됩니다
1
154
2
최대 Tomcat 스레드 수를 확인하는 지표
0
159
1
mac m2에서 startup.sh 실행후 아무 반응이 없습니다.
0
94
2
내장 톰캣 실행 오류 관련 질문드립니다.
0
157
1
스프링 발전 과정들도 자세히 알아둬야하나요??
1
127
1
스프링부트 ioc 컨테이너 갯수
0
89
1
404 페이지
0
133
3
actuator 호출시 타임스탬프 질문
0
90
1
순수 라이브러리 사용하기 2 - memory-v1
0
125
1
외부설정 @ConfigurationProperties의 내부 클래스에서 static을 사용하는 이유를 알고 싶습니다.
0
105
1
서블릿 컨테이너 초기화1 강의 관련 질문입니다~
0
93
1
Thread Config Max 패널 설정 변경 질문
0
128
1
스프링 액츄에이터 shutdown 엔드포인트 활성화가 안됩니다.
0
107
1