스프링 외부 설정 방법 (커맨드 라인 인수, 커맨드 라인 옵션 인수, 스프링 통합)

 

스프링 외부 설정 방법 (OS 환경 변수, 자바 시스템 속성) (tistory.com)

스프링 외부 설정 방법 (OS 환경 변수, 자바 시스템 속성)

저번 글에서는 스프링 외부 설정하는 방법 중 OS 환경 변수, 자바 시스템 속성을 사용해서 읽어오는 방법에 대해서 알아봤다. 

이번에는 나머지 외부 설정 방법에 대해서 작성할 예정이다. 

 

 

1️⃣ 외부 설정 방법 :  커맨드 라인 인수 

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

java -jar XXX.jar dataA dataB 

이런식으로 뒤에 필요한 데이터를 스페이스로 구분해서 전달하면 args에 dataA, dataB 문자가 전달된다. 

 

CommandLineV1

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

실행결과

실행 결과 dataA, dataB가 로그로 출력된 것을 확인할 수 있다. 

 

근데 보통 환경변수 설정을 할 때는 key=vaue 형식으로 사용하고, 받는 것이 더 편리하고 실제로 그렇게 더 많이 사용된다. 

따라서 dataA dataB 이렇게 지정하는 것 말고 url=devdb username=dev_user password=dev_pw 이런식으로 바꿔서 다시 실행해보면 

key=vaue 형식이 아니라 그냥 그대로 적은 문자가 출력되는 것을 확인할 수 있다. 

그러면 이걸 개발자가 직접 분리해서 key=value 형식으로 맞게 변환해줘야 하는 번거러움이 있다. 

 

 

 

2️⃣ 외부설정 방법 : 커맨드 라인 옵션 인수 

일반적인 커맨드 라인 인수는 띄어쓰기로 구분하고 key=value 형식을 구분하는 방법이 없다. 

따라서 커맨드 라인 인수를 key=value 형식으로 구분하는 방법이 필요했는데 스프링은 이제 커맨드 라인 인수를 key=value 형식으로 편리하게 사용할 수 있도록 스프링 만의 표준 방식을 정의했다.  -> 커맨드 라인 옵션 인수 

 

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

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

(하나의 키에 여러값 설정 가능) 

 

CommandLineV2

@Slf4j
public class CommandLineV2
{
   // --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 applicationArguments = new DefaultApplicationArguments(args);
      log.info("SourceArgs = {}", List.of(applicationArguments.getSourceArgs()));
      log.info("NonOptionArgs = {}", applicationArguments.getNonOptionArgs());
      log.info("OptionsNames = {} ", applicationArguments.getOptionNames());
      
      Set<String> optionNames = applicationArguments.getOptionNames();
      for (String optionName : optionNames)
      {
         log.info("option arg {}={}", optionName, applicationArguments.getOptionValues(optionName));
      }
      
      List<String> url = applicationArguments.getOptionValues("url");
      List<String> username = applicationArguments.getOptionValues("username");
      List<String> password = applicationArguments.getOptionValues("password");
      List<String> mode = applicationArguments.getOptionValues("mode");
      
      log.info("url = {}", url);
      log.info("username = {}", username);
      log.info("password = {}", password);
      log.info("mode = {}", mode);
   }
}

스프링이 제공하는 ApplicationArguments 인터페이스와 이를 구현한 DefaultApplicationArguments 를 사용하면 커맨드 라인 옵션 인수를 편리하게 사용할 수 있다. 

 

--urldb=devdb --username=dev_user --password=dev_pw mode=on 을 사용했는데 이때 mode 는 앞에 --를 붙여주지 않았다. 

 

NonOptionArgs 를 사용하면 --를 사용하지 않은 즉, 옵션 인수가 아닌 것을 조회할 수 있고, 

OptionNames를 하면 key 값을, OptionValue(key) 를 하면 value 값을 조회할 수 있다. 

 

arg : 커맨드 라인의 입력 결과를 그대로 출력한다. 

SourceArgs : 커맨드 라인 인수 전부 출력 

 

 

* 옵션 인수는 --username=dev1 --username=dev2 처럼 하나의 키에 여러 값을 담을 수 있기 때문에 applicationArguments.getOptionsValue(key) 의 결과가 List를 반환한다. 

(그리고 참고로 커맨드 라인 옵션 인수는 자바 언어의 표준 기능이 아니고, 스프링이 편리함을 위해 제공하는 기술이다.) 

 

 

💌 스프링 부트는 커맨드 라인을 포함해서 커맨드 라인 옵션 인수를 활용할 수 있는 ApplicationArguments 를 스프링 빈으로 등록해두고, 해당 빈을 주입받으면 커맨드 라인으로 입력한 값을 어디서든 사용할 수 있다. 

 

 

CommandLineBean

@Slf4j
@Component
public class CommandLineBean
{
   private final ApplicationArguments arguments;
   
   public CommandLineBean(ApplicationArguments arguments)
   {
      this.arguments = 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));
      }
   }
}

 

 

 

3️⃣ 외부 설정 방법 : 스프링 통합 

지금까지 외부 설정 방법으로 OS 환경 변수, 자바 시스템 속성, 커맨드 라인 인수, 커맨드 라인 옵션 인수 등을 봤는데 넓게(?) 보면 외부 설정 방법은 key=value 형식이고 이 설정값을 외부에 지정해둔 것이다. 

위에서 4가지 본 것처럼 외부 설정값 형식은 같은데 어디에 지정해뒀느냐에 따라서 각각 읽는 방법이 다르다는 단점이 있다. 

 

예를 들어서 OS 환경 변수로 설정값 지정해뒀다면 System.getenv(key) 를 사용해야 하고, 자바 시스템 속성으로 외부값 설정했다면 

System.getProperty(key) 를 사용해야 한다...! 만약 지금은 자바 시스템 속성에 외부 설정 값을 지정해서 사용하고 있었다고 한다. 

그런데 이제 정책 변경으로 인해서 다음부터는 커맨드 라인 인수로 설정 값을 지정해서 사용하기로 바꿨다고 한다면...

이제 이 코드들을 모두 바꿔줘야 한다는 번거로움이 존재한다. 

 

-> 외부 설정값이 어디에 위치하든 상관없이 일관성 있고, 편리하게 key=value 형식의 외부 설정값을 읽을 수 있으면 코드 변경을 하지 않아도 되니까 개발자 입장에서는 더 편리하고 외부 설정값 설정하는 방법도 더 유연해진다. 

스프링은 Environment와 PropertySource 를 통해 추상화를 해서 이 문제를 해결했다! 

 

 

 

PropertySource 

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

CommandLinePropertySource

SystemEnviornmentPropertySource 

...

이렇게 스프링은 로딩 시점에 필요한 PropertySource들을 생성하고 Environment에서 이를 사용할 수 있게 연결해준다. 

 

 

Environment

/**
 * Interface representing the environment in which the current application is running.
 * Models two key aspects of the application environment: <em>profiles</em> and
 * <em>properties</em>. Methods related to property access are exposed via the
 * {@link PropertyResolver} superinterface.
 *
 * <p>A <em>profile</em> is a named, logical group of bean definitions to be registered
 * with the container only if the given profile is <em>active</em>. Beans may be assigned
 * to a profile whether defined in XML or via annotations; see the spring-beans 3.1 schema
 * or the {@link org.springframework.context.annotation.Profile @Profile} annotation for
 * syntax details. The role of the {@code Environment} object with relation to profiles is
 * in determining which profiles (if any) are currently {@linkplain #getActiveProfiles
 * active}, and which profiles (if any) should be {@linkplain #getDefaultProfiles active
 * by default}.
 *
 * <p><em>Properties</em> play an important role in almost all applications, and may
 * originate from a variety of sources: properties files, JVM system properties, system
 * environment variables, JNDI, servlet context parameters, ad-hoc Properties objects,
 * Maps, and so on. The role of the {@code Environment} object with relation to properties
 * is to provide the user with a convenient service interface for configuring property
 * sources and resolving properties from them.
 *
 * <p>Beans managed within an {@code ApplicationContext} may register to be {@link
 * org.springframework.context.EnvironmentAware EnvironmentAware} or {@code @Inject} the
 * {@code Environment} in order to query profile state or resolve properties directly.
 *
 * <p>In most cases, however, application-level beans should not need to interact with the
 * {@code Environment} directly but instead may have to have {@code ${...}} property
 * values replaced by a property placeholder configurer such as
 * {@link org.springframework.context.support.PropertySourcesPlaceholderConfigurer
 * PropertySourcesPlaceholderConfigurer}, which itself is {@code EnvironmentAware} and
 * as of Spring 3.1 is registered by default when using
 * {@code <context:property-placeholder/>}.
 *
 * <p>Configuration of the {@code Environment} object must be done through the
 * {@code ConfigurableEnvironment} interface, returned from all
 * {@code AbstractApplicationContext} subclass {@code getEnvironment()} methods. See
 * {@link ConfigurableEnvironment} Javadoc for usage examples demonstrating manipulation
 * of property sources prior to application context {@code refresh()}.
 *
 * @author Chris Beams
 * @since 3.1
 * @see PropertyResolver
 * @see EnvironmentCapable
 * @see ConfigurableEnvironment
 * @see AbstractEnvironment
 * @see StandardEnvironment
 * @see org.springframework.context.EnvironmentAware
 * @see org.springframework.context.ConfigurableApplicationContext#getEnvironment
 * @see org.springframework.context.ConfigurableApplicationContext#setEnvironment
 * @see org.springframework.context.support.AbstractApplicationContext#createEnvironment
 */
public interface Environment extends PropertyResolver {

   /**
    * Return the set of profiles explicitly made active for this environment. Profiles
    * are used for creating logical groupings of bean definitions to be registered
    * conditionally, for example based on deployment environment. Profiles can be
    * activated by setting {@linkplain AbstractEnvironment#ACTIVE_PROFILES_PROPERTY_NAME
    * "spring.profiles.active"} as a system property or by calling
    * {@link ConfigurableEnvironment#setActiveProfiles(String...)}.
    * <p>If no profiles have explicitly been specified as active, then any
    * {@linkplain #getDefaultProfiles() default profiles} will automatically be activated.
    * @see #getDefaultProfiles
    * @see ConfigurableEnvironment#setActiveProfiles
    * @see AbstractEnvironment#ACTIVE_PROFILES_PROPERTY_NAME
    */
   String[] getActiveProfiles();

   /**
    * Return the set of profiles to be active by default when no active profiles have
    * been set explicitly.
    * @see #getActiveProfiles
    * @see ConfigurableEnvironment#setDefaultProfiles
    * @see AbstractEnvironment#DEFAULT_PROFILES_PROPERTY_NAME
    */
   String[] getDefaultProfiles();

   /**
    * Return whether one or more of the given profiles is active or, in the case of no
    * explicit active profiles, whether one or more of the given profiles is included in
    * the set of default profiles. If a profile begins with '!' the logic is inverted,
    * i.e. the method will return {@code true} if the given profile is <em>not</em> active.
    * For example, {@code env.acceptsProfiles("p1", "!p2")} will return {@code true} if
    * profile 'p1' is active or 'p2' is not active.
    * @throws IllegalArgumentException if called with zero arguments
    * or if any profile is {@code null}, empty, or whitespace only
    * @see #getActiveProfiles
    * @see #getDefaultProfiles
    * @see #acceptsProfiles(Profiles)
    * @deprecated as of 5.1 in favor of {@link #acceptsProfiles(Profiles)}
    */
   @Deprecated
   boolean acceptsProfiles(String... profiles);

   /**
    * Return whether the {@linkplain #getActiveProfiles() active profiles}
    * match the given {@link Profiles} predicate.
    */
   boolean acceptsProfiles(Profiles profiles);

}

스프링은 Environment 를 제공해서 특정 외부 설정에 종속되지 않고 일관성있게 key=value 형식의 외부 설정에 접근할 수 있다. 

environment.getProperty(key)를 통해서 값을 조회할 수 있고, Environment가 내부에서 여러 과정을 거쳐서 PropertySource에 접근한다. 

따라서 이제 모든 외부 설정은 Environment 를 통해서 조회하면 된다. 

 

@Slf4j
@Component
public class EnvironmentCheck
{
   private final Environment environment;
   
   public EnvironmentCheck(Environment environment)
   {
      this.environment = environment;
   }
   
   @PostConstruct
   public void init()
   {
      String url = environment.getProperty("url");
      String username = environment.getProperty("username");
      String password = environment.getProperty("password");
      
      log.info("environment url = {}", url);
      log.info("environment username = {}", username);
      log.info("environment password = {}", password);
   }
   
}

자바 시스템 속성 

-Durl=devdb -Dusername=dev_user -Dpassword=dev_pw 

 

커맨드 라인 옵션 인수 

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

 

로 각각 한번씩 지정해서 실행해보면 둘다 동일하게 Environment 를 통해서 설정 값을 읽을 수 있는 것을 확인할 수 있다. 

따라서 이제 Environment로 설정 값을 읽으면 되기 때문에 외부 설정값이 지정하는 곳이 바뀌어도 코드 변경을 하지 않아도 된다! 

 

 

* 우선순위 

만약 자바 시스템 속성과 커맨드 라인 옵션 인수에 동시에 설정값을 지정해뒀다면 

커맨드 라인 옵션 인수로 지정한 외부 설정 값을 조회하는 것을 확인할 수 있다. 

우선순위는 보통 더 범위가 좁은 것이 우선권을 가지게 되는데 자바 시스템 속성은 해당 JVM 내에서 모두 접근 할 수 있지만, 커맨드 라인 옵션 인수는 main의 arg를 통해서 들어오기 때문에 접근 범위가 더 좁기 때문에 커맨드 라인 옵션 인수가 우선권을 가진다.