내가 application-cloud.yml 이라 명명했던 이유

이번 카카오 테크 캠퍼스 활동을 하면서, 정말 부끄러운 에피소드가 발생했다.

우리 모르는개 산책팀은 위와 같은 Profile들을 통해서 각 크램폴린, 클라우드 타입 배포나 테스트 환경마다 다른 환경설정을 제공 및 관리하고 있었다.

나는 클라우드 타입 배포 환경을 담당했기에, application-cloud.yml을 주로 관리했었다.

application-cloud.yml

spring:
  jpa:
    hibernate:
      ddl-auto: update
    properties:
      hibernate:
        show_sql: true
        format_sql: true
        dialect: org.hibernate.dialect.MariaDBDialect
        naming:
          physical-strategy: org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl
          implicit-strategy: org.hibernate.boot.model.naming.ImplicitNamingStrategyLegacyJpaImpl
  datasource:
    driver-class-name: org.mariadb.jdbc.Driver
    url: jdbc:mariadb://${DB_url}:${DB_port}/${DB_dataBaseName}?characterEncoding=UTF-8&serverTimezone=UTC
    username: ${DB_name}
    password: ${DB_password}

cloud:
  aws:
    s3:
      bucket: ${Bucket_name}
    stack.auto: false
    region.static: ap-northeast-2
    credentials:
      accessKey: ${Access_key}
      secretKey: ${Secret_key}

위 코드는 최신화가 된 버젼이고, 원래는 아래와 같이 작성되어있었다.

spring:
  profiles:
    active: cloud
  jpa:
    hibernate:
      ddl-auto: update
    properties:
      hibernate:
        show_sql: true
        format_sql: true
        dialect: org.hibernate.dialect.MariaDBDialect
        naming:
          physical-strategy: org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl
          implicit-strategy: org.hibernate.boot.model.naming.ImplicitNamingStrategyLegacyJpaImpl
  datasource:
    driver-class-name: org.mariadb.jdbc.Driver
    url: jdbc:mariadb://${DB_url}:${DB_port}/${DB_dataBaseName}?characterEncoding=UTF-8&serverTimezone=UTC
    username: ${DB_name}
    password: ${DB_password}

cloud:
  aws:
    s3:
      bucket: ${Bucket_name}
    stack.auto: false
    region.static: ap-northeast-2
    credentials:
      accessKey: ${Access_key}
      secretKey: ${Secret_key}

위와 같이 작성을 하면, 나는 아래 사진처럼 클라우드 타입에서 default로 지정해준 default 실행 yaml이 cloud가 될 줄 알았다.

그러나 실 배포시 cloud Yaml이 배포되는 것이 아니라 default yaml인 application.yml이 실행이 되었다.

이는 yaml 전략을 아예 이해하지 못한 내 패착이었다.

기본적으로 Spring에서는 default yaml로 application-.yml 을 default로 실행한다.

application-.yml

spring:
  profiles:
    active: cloud

만약 active 된 Profile이 없다면 application-.yml 이 default로 실행되며, active 된 프로파일이 있다면 해당 Profile이 애플리케이션 실행 시 실행되게 된다.

그리고 Profile을 생성할 때, application-cloud.yml 처럼 ‘-(대시)’를 기준으로 프로파일명을 yml 파일 이름 안에 포함을 시켜야 한다.

Spring은 ‘-(대시)’ 뒤의 이름을 통해서 yaml의 Profile을 구분하는 것이다.

나는 직접 Profile을 Activate 시키기 위해서 직접 spring:profiles:active에 Profile의 이름만 적어주면 그만이라고 생각했었다.

이는 틀렸었고 파일 이름에 Profile에 맞는 이름 설정과 기본적으로 실행되는 yaml 안에서 실행 Profile을 적어주어야 한다.

application.yml

spring:
  profiles:
    active: cloud

application-cloud.yml

문제 해결은 했고, 좀 더 Spring이 Profile을 다루는 방법들을 자세하게 공부해보자.

위에서 default Profile이 application.yml로 실행 되게 되는 이유는 뭘까?

기본 프로파일의 이름은, 아무것도 없는 상태이며 “none”으로 칭하게 된다.

spring:
  profiles:
    default: "none"

Spring에서는 기본적으로 아래와 같은 명령어가 애플리케이션 실행 시점에 날라가게 된다.

--spring.profiles.default=none

그렇기에 ‘-(대시)’ 뒤에 아무것도 작성하지 않은 ‘none’ application.yml이 설정되게 된다.

이게 싫다면 아래와 같이 Spring 명령어로 기본 Profile을 변경 시켜주면 된다.

--spring.profiles.default=cloud

이렇게 Yaml 전략으로 Profile을 분리 시키는 이유는 뭘까?

Yaml 전략을 사용하면 default yaml에는 활성화 시킬 Profile만 적어두면 되기에 코드가 가독성이 좋아진다.

활성화 시킬 Profile을 한개가 아니라 여러개 적을 수 있다.

spring:
      profiles:
         active: "cloud", "prod", "test"

또한 여러 yaml 파일들을 역할에 따라 각각 분할이 가능하게 된다는 장점이 생긴다.

그러나 만약 activate 시킬 profile이 100개가 되어버렸다고 하자, 일단은

그런 경우에는 오히려 activate 한 줄 자체가 점점 길어지는 현상이 일어날 것이다. 이는 yaml의 장점을 살리지 못하게 된다.

그렇기에 Profile Group이라는 것을 제공한다.

여러개의 Profile들을 하나로 묶을 수 있는 명령어로 group: 을 추가해주고, group이 되는 profile gruop명과, 속하게 되는 profile 구성원을 입력해주면 된다.

spring:
  profiles:
    group:
      production: # Group 명
      - "cloud" # profile 구성1
      - "prod" # profile 구성2

위의 코드를 실행시킬 때는 Group 명인 production 하나만 실행시키면 된다.

또한 command Line의 명령어로는 —spring.profiles.active=production 으로 실행시키면 된다.