[스프링 핵심 원리와 활용] 섹션7. 외부 설정과 프로필 (2)

[juu-n-oo]

OS 환경 변수

OS 환경변수는 해당 OS를 사용하는 모든 프로그램에서 읽을 수 있는 설정값. 다른 외부 설정과 비교해서 사용범위가 가장 넓음

윈도우: set
MAC, 리눅스: printenv

Map<String, String> envMap = System.getenv();
for (String key : envMap.keySet() {
	log.info("env {}={}", key, System.getenv(key));
}

OS 환경 변수를 설정하고, 필요한 곳에서 System.getenv()를 사용하면 외부 설정을 사용할 수 있음

DB 접근 URL과 같은 정보를 OS 환경 변수에 설정하고 읽어들일 수 있음

OS환경변수는 다른 프로그램에서도 사용할 수 있어서 전역 변수 같은 효과가 있음.

자바 시스템 속성

자바 시스템 속성(Java System Properties)는 실행한 JVM 안에서 접근 가능한 외부 설정. 추가로 자바가 내부에서 미리 설정해두고 사용하는 속성들도 존재함

자바 시스템 속성은 다음과 같이 자바 프로그램을 실행할 때 사용함

java -Durl=dev -jar app.jar

-D VM옵션을 통해서 key=value 형식으로 사용함.

-D옵션이 -jar 보다 앞에 위치함

Properties properties = System.getProperties();
for (Object key : properties.keySet()) {
	log.info("prop {}={}, key, System.getProperties(String.valueOf(key)));
}

System.getProperties()를 사용해서 Map과 유사한 (Map의 자식 타입) key=value 형식의 Properties를 받을 수 있음. 이를 통해서 모든 자바 시스템 속성을 조회할 수 있음

System.getProperty(key)를 사용하면 속성값을 조회할 수 있음

file.encoding=UTF-8를 통해 자바가 내부적으로 사용하는 속성을 확인할 수 있음

java -Durl=devdb -Dusername=dev_user -Dpassword=dev_pw -jar app.jar

위의 명령어로 실행할 경우, Properties값은 다음과 같이 설정됨

url=devdb, username=dev_user, password=dev_pw

• 자바 시스템 속성을 자바 코드로 설정하기

자바 시스템 속성은 앞서 본 것 처럼 -D 옵션을 통해 실행 시점에 전달하는것도 가능하고, 자바 코드 내부에서 추가하는것도 가능하다

System.setProperty(propertyName, “propertyValue”)

System.getPRoperty(propertyName)

커맨드 라인 인수

커맨드 라인 인수(Command line arguments)는 어플리케이션 실행 시점에 외부 설정 값을 main(args)메소드의 args 파라미터로 전달하는 방법

java -jar app.jar dataA dataB

필요한 데이터를 마지막 위치에 스페이스로 구분해서 전달함. dataA, dataB가 args로 전달됨

public static void main(String[] args) {
	for (String arg : args) {
		log.info("arg {}", arg);
	}
}

command line value는 key=value 형식이 아님.

어플리케이션을 개발할때는 보통 Key=value 형식으로 데이터를 받는것이 편리함

인수로 key=value형식처럼 입력하더라도 통 문자로 입력받게 된다.

개발자가 직접 =를 기준으로 파싱해서 분리해야하며, 형식이 배열이기에 루프를 돌려서 원하는 데이터를 찾아야하는 불편함이 있다.

커맨드 라인 옵션 인수

• 일반적인 커맨드 라인 인수

커맨드 라인에 전달하는 값은 형식이 없고, 단순히 띄어쓰기로 구분함

• aaa bbb → [aaa, bbb] 2개의 값

• hello world → [hello, world] 2개의 값

• “hello world” → [hello world] 1개의 값 (공백을 연결하려면 “를 사용함)

• key=value → [key=value] 1개의 값

• 커맨드 라인 욥선 인수(command line option arguments)

커맨드 라인 인수를 key=value 형식으로 구분하는 방법이 필요함.

스프링에서는 커맨드 라인 인수를 key=value 형식으로 편리하게 사용할 수 있도록 스프링 만의 표준 방식을 정의했는데, 이것이 커맨드 라인 옵션 인수.

스프링은 커맨드 라인에 -(dash) 2개를 --를 연결해서 시작하면 key=value형식으로 정하고 이것을 커맨드 라인 옵션 인수로 인식한다.

--username=userA --username=userB 처럼 하나의 키에 여러 값 설정도 가능

// --url=devdb --username=dev_user --password=dev_pw mode=on
public static void main(String[] args) {
	for (String arg : args) {
		log.info("arg {}", arg)
	}
ApplicationArguments appArgs =. new DefaultApplicationArguments(args);
log.info("SourceArgs = {}", List.of(appArgs.getSourceArgs()));
// [--url=devdb, --username=dev_user, --password=dev_pw]
log.info("NonOptionsArgs = {}, appARgs.getNonOptionArgs());
// mode=on
log.info("OptionsNames = {}", appArgs.getOptionNames());
// [password, url, username]

}

스프링이 제공하는 ApplicationArguments 인터페이스와 DefaultApplicationArguments구현체를 사용하면 커맨드 라인 옵션 인수를 규격대로 파싱해서 편리하게 사용할 수 있음

arg	커맨드 라인의 입력 결과를 그대로 출력
SourceArgs	커맨드 라인 인수 전부를 출력
NonOptionArgs	옵션 인수가 아닌것
OptionNames	key=value 형식으로 사용되는 옵션 인수

커맨드 라인 옵션 인수는 자바 언어의 표준 기능이 아니며, 스프링이 편리를 위해 제공하는 기능

커맨드 라인 옵션 인수와 스프링 부트

스프링 부트는 커맨드 라인을 포함해서 커맨드 라인 옵션 인수를 활용할 수 있는 ApplicationArguments를 스프링 빈으로 등록해둔다. 그리고 그 안에 입력한 커맨드 라인을 저장해둔다. 해당 빈을 주입 받으면 커맨드 라인으로 입력한 값을 사용할 수 있다.

@Component
@RequiredArgsConstructor
public class CommandLineBean {
private final ApplicationArguments arguments;

@PostConstruct
public void init() {
	log.info("source {}", List.of(arguments.getSourceArgs()));
	log.info("optionNames {}", arguments.getOptionNames());
	Set<String> optionNames = arguments.getOptionNames();
	for (String optionName : optionNames) {
		log.info("option args {}={}", optionName, arguments.getOptionValues(optionName));
	}
}

}

--url=devdb --username=dev_user --password=dev_pw mode=on

위의 커맨드 라인 인수를 입력 후 실행 시 다음과 같이 출력됨

스프링 통합

커맨드 라인 옵션 인수, 자바 시스템 속성, OS환경변수는 모두 외부 설정을 key=value 형태로 사용할 수 있는 방법이다. 이런 외부 설정값을 읽어서 사용하는 개발자 입장에서 같은 key=value형식의 데이터를 어디에 있는 값을 읽어야 하는지에 따라 읽는 방법이 다르다.

OS에 환경 변수로 설정했는데 정책이 변경되어 자바 시스템 속성에 환경변수를 두기로 변경했다면 해당 코드를 모두 수정해야한다.

외부 설정값이 어디에 있든 일관성 있고 편리하게 key=value형식의 외부 설정값을 읽을 수 있으면 개발자 입장에서 편리하고, 외부 설정 값 설정도 유연해질 수 있다.

스프링은 이런 문제를 Environment와 PropertySource라는 추상화를 통해서 해결함

• PropertySource

  org.springframework.core.env.PropertySource

  스프링은 PropertySource라는 추상 클래스를 제공하고, 각각의 외부 설정을 조회하는 XxxPropertySource 구현체를 만들어두었다.

  ie. ComandLinePropertySource, SystemEnvironmentPropertySource

• Environment

  org.springframework.core.env.Environment

  Environment를 통해서 특정 외부 설정에 종속되지 않고, 일관성 있게 key=value 형식의 외부 설정에 접근할 수 있음

  environment.getPropetery(key)를 통해서 값을 조회할 수 있음

  Environment는 내부에서 여러 과정을 거쳐 PropertySource들에 접근함

  같은 값이 있는 경우를 대비해 스프링은 이에 대한 우선수위를 가짐

• 설정 데이터(파일)

  application.properties, application.yml도 PropertySource에 추가됨. 따라서 Environment를 통해서 접근할 수 있음

@Slf4j
@Component
@RequiredArgsConstructor
public class EnvironmentCheck {
	private final Environemnt env;
@PostConstruct
public void init() {
	String url = env.getProperty("url");
	String username = env.getProperty("username");
	String password = env.getProperty("password");
}

}

커맨드 라인 옵션 인수, 자바 시스템 속성 모두 Environment를 통해서 동일한 방법으로 읽을 수 있음

스프링은 Environment를 통해 외부 설정을 읽는 방법을 추상화함. 덕분에 자바 시스템 속성을 사용하다가 만약 커맨드 라인 옵션 인수를 사용하도록 읽는 방법이 변경되어도 소스 코드는 변경하지 않아도 됨

우선순위

• 더 유연한 것이 우선권을 가진다
  • 변경하기 어려운 파일 보다 실행 시 원하는 값을 줄 수 있는 자바 시스템 속성이 더 우선순위 높음
• 범위가 넓은 것보다 좁은 것이 우선권을 가진다
  • 자바 시스템 속성은 해당 JVM안에서 모두 접근 가능. 반면에 커맨드 라인 옵션 인수는 main의 arg를 통해서 들어오기떄문에 접근 범위가 더 좁다

자바 시스템 속성과 커맨드 라인 옵션 인수의 경우 커맨드 라인 옵션 인수의 범위가 더 좁기때문에 커맨드 라인 옵션 인수가 우선권을 가진다.

설정 데이터 - 외부 파일

환경변수, 자바 시스템 속성, 커맨드 라인 옵션 인수 등은 값이 늘어날 수록 불편해진다. 이러한 관리를 위해 어플리케이션 로딩 시점에 .properties 파일을 key=value형식의 데이터를 읽어와 사용한다.

• 스프링과 설정 데이터

개발자가 파일을 읽어서 설정값으로 사용할 수 있도록 개발을 해야겠지만, 스프링 부트는 이미 이런 부분을 다 구현해둠. [application.properties](http://application.properties) 라는 이름의 파일을 자바를 실행하는 위치에 만들어 두기만 하면 된다. 그러면 스프링이 해당 파일을 읽어서 사용할 수 있는 PropertySource의 구현체를 제공함. 스프링에서는 이러한 application.properties파일을 설정 데이터(Config Data)라고 함.

설정 데이터 -내부 파일 분리

설정 파일을 외부에 관리하는 것은 굉장히 번거로운 일이다. 이 문제를 해결하는 간단한 방법은 설정 파일을 프로젝트 내부에 포함해서 관리하는 것. 그리고 빌드 시점에 함께 빌드되도록 한다.

1. 프로젝트 안에 소스 코드 뿐만 아니라 각 환경에 필요한 설정 데이터도 함께 포함해서 관리함

   개발용 설정파일 application-dev.properties
   운영용 설정파일 application-prod.properties

2. 빌드 시점에 개발, 운영 설정 파일을 모두 포함해서 빌드함

3. app.jar는 개발,운영 두 설정 파일을 모두 가지고 배포됨

4. 실행할 떄 어떤 설정 데이터를 읽어야 할지 최소한의 구분은 필요함

   개발 환경이라면 dev, 운영환경이라면 prod

   dev 프로필이 넘어오면 application-dev.properties를 읽어서 사용함

설정 데이터 - 내부 파일 합체

설정 파일을 각각 분리해서 관리하면 하눈에 전체가 들어오지 않는다

스프링은 이런 단점을 보완하기 위해 물리적인 하나의 파일 안에 논리적으로 영역을 구분하는 방법을 제공함

기존의 dev환경은 [application-dev.properties](http://application-dev.properties) prod는 application-prod.propeties를 사용했음

[application.properties](http://application.properties) 파일 안에 논리적으로 영역 구분을 제공함

spring.config.active.on-profile=dev
url=devdb
username=dev_user
password=dev_pw
#---
spring.config.activate.on-profile=prod
url=proddb
username=prod_user
password=prod_pw

우선순위 - 설정 데이터

spring.config.active.on-profile=dev
url=devdb
username=dev_user
password=dev_pw
#---
spring.config.activate.on-profile=prod
url=proddb
username=prod_user
password=prod_pw

이런 상태에서 만약 프로필을 적용하게 되면 해당하는 논리적 프로필이 없으므로 Null이 된다

url=local.db.com
username=local_user
password=local_pw
#---
spring.config.active.on-profile=dev
url=devdb
username=dev_user
password=dev_pw
#---
spring.config.activate.on-profile=prod
url=proddb
username=prod_user
password=prod_pw

다음과 같이 설정해서 프로필과 무관하게 설정데이터를 읽어서 사용한다.

이러한 프로필 설정이 없는 값은 기본값으로 적용된다

• 우선순위 정리

설정 데이터(application.properties)

OS 환경변수

자바 시스템 속성

커맨드 라인 옵션 인수

@TestPropertySource (테스트용)

• 설정 데이터 우선순위

jar 내부 application.properties

jar 내부 프로필 적용 파일 application-{profile}.properties

jar 외부 application.properties

jar 외부 프로필 적용 파일 application-{profile}.properties