머리말

현대 서비스의 클라우드 네이티브 이론의 12가지 요소를 기반으로 컨테이너화된 배포를 사용할 때 서로 다른 환경에서 서로 다른 장면을 패키징하는 대신 동일한 이미지가 서로 다른 환경의 배포 요구 사항을 충족할 수 있는지 확인해야 합니다. 본 문서에서는 환경 그룹화에 따른 시작 항목 구성을 통해 동일한 이미지를 다른 환경에 배포할 수 있도록 다양한 환경 구성을 충족하는 스프링 프레임워크 기반의 컴파일 및 패키징 솔루션을 주로 소개합니다.

기존 솔루션 및 문제점

우리가 본 가장 일반적인 구성 파일 관리 솔루션은 다중 환경 전환을 달성하기 위한 Maven의 프로필 구성을 기반으로 합니다. 단점은 pom.xml에서 프로필을 구성한다는 것입니다. 컴파일하고 패키징할 때마다 컴파일 명령을 통과해야 합니다. - P는 현재 환경 구성을 식별합니다. 이로 인해 발생하는 문제는 우리가 패키징한 이미지에 환경 속성이 있어 하나의 이미지에 대한 다중 환경 배포 요구 사항을 충족하지 못한다는 것입니다.

Spring 프로필을 기반으로 구성 파일을 관리하는 또 다른 구성 솔루션이 있습니다. 이 두 가지 솔루션에 대해 다음에는 몇 가지 분석과 비교를 수행하겠습니다.

두 프로필 구성의 차이점과 장단점 비교

a. 두 프로필 솔루션의 비교

1. 메이븐 프로필:

◦ Maven 프로필은 빌드 시간 동안 환경이나 기타 조건에 따라 활성화되는 다양한 구성 컬렉션입니다. 프로젝트 파일에 여러 프로필을 정의할 수 있으며 Maven 명령줄 매개변수 또는 기타 구성을 사용하여 특정 프로필을 활성화할 수 있습니다 .pom.xml

◦ 장점 :

▪높은 유연성, 다양한 빌드 환경이나 조건에 따라 다양한 프로파일을 활성화할 수 있습니다.

▪ 빌드 프로세스 중에 다양한 종속성, 플러그인 구성 등을 사용할 수 있습니다.

◦단점 :

▪ 구성이 상대적으로 분산되어 있으며 Maven 파일에서 여러 프로필을 정의하고 관리해야 합니다 .pom.xml

▪ 구성과 코드의 분리가 직관적이지 않습니다.

2. Spring의 프로필 구성:application.properties

◦ Spring 파일은 활성화된 프로필을 기반으로 다양한 구성을 로드할 수 있습니다. 파일의 여러 프로필에서 구성을 정의하고 구성 파일이나 환경 변수를 사용하여 특정 프로필을 활성화할 수 있습니다.application.propertiesapplication.properties

◦ 장점 :

▪구성이 중앙 집중화되어 있으며 여러 프로필의 구성을 하나의 파일에 정의할 수 있으므로 관리 및 유지 관리가 더 쉽습니다.

▪구성 이 코드와 유사하여 더욱 직관적이고 읽기 쉽습니다.

◦단점 :

▪ 프로파일을 활성화하는 방법은 상대적으로 제한적이며 일반적으로 구성 파일이나 환경 변수를 통해 지정해야 합니다.

▪ 빌드 프로세스 중 구성에는 적용되지 않으며 주로 애플리케이션 구성을 실행하는 데 사용됩니다.

일반적으로 빌드 프로세스 중 구성에는 Maven 프로필이 더 적합하며 빌드 환경이나 조건에 따라 다른 프로필을 활성화할 수 있는 반면, 애플리케이션 실행 구성에는 Spring의 프로필 구성이 더 적합하며 다른 프로필을 로드할 수 있습니다. 다른 프로필 구성에 따라. 어느 것을 선택하느냐는 귀하의 필요와 선호도에 따라 다릅니다.application.properties

b. 클라우드 네이티브 및 컨테이너화된 배포 시나리오 분석

클라우드 네이티브 및 컨테이너화된 배포 시나리오에서는 Spring의 프로필 구성 방법을 사용하는 것을 선호합니다.application.properties

클라우드 네이티브 및 컨테이너화된 배포 시나리오에서 프로필 구성을 사용하면 다음과 같은 이점이 있습니다.application.properties

환경 독립성: 활성화된 프로필에 따라 다양한 구성을 로드할 수 있으므로 애플리케이션이 다양한 환경에서 실행될 때 일관된 동작을 갖습니다. 애플리케이션이 다양한 환경(예: 개발, 테스트, 프로덕션)에서 실행되어야 할 수 있으므로 이는 클라우드 네이티브 및 컨테이너화된 배포에 중요합니다.application.properties
구성 중앙 집중화: 프로필 구성 방법을 사용하면 여러 프로필의 구성을 하나의 파일에 정의할 수 있으므로 구성 관리가 더욱 중앙 집중화되고 편리해집니다. 이는 여러 Maven 프로필을 분산하여 관리할 필요 없이 다양한 프로필에 따라 적절한 구성을 로드할 수 있기 때문에 클라우드 네이티브 및 컨테이너화된 배포 시나리오에 매우 유용합니다.application.properties
컨테이너 친화성: 컨테이너화된 배포 시나리오에서는 일반적으로 컨테이너 오케스트레이션 도구(예: Kubernetes)를 사용하여 애플리케이션의 구성 및 배포를 관리합니다. 프로필 구성 방법을 사용하면 구성 파일의 환경 변수나 속성을 통해 활성화된 프로필을 지정하여 컨테이너 오케스트레이션 도구와 통합할 수 있습니다.application.properties

요약하자면, Spring의 application.properties를 사용하는 프로필 구성 방법은 환경 독립성, 중앙 집중식 구성 및 컨테이너 친화성의 이점을 제공하기 때문에 클라우드 네이티브 및 컨테이너화된 배포 시나리오에 더 적합합니다.

속성 기반 다중 환경 구성 기법의 실습

다음 스킴은 springboot를 예로 듭니다.물론 springMVC 스킴도 적용할 수 있지만 추가 구성이 필요합니다.우리의 새 프로젝트는 기본적으로 springboot를 기반으로 구축되었으므로 여기서는 springMVC의 실선 스킴을 확장하지 않습니다.필요한 경우 , 추가적인 mvc 구성 체계 제공을 추가하겠습니다.

a. 구성 파일 트리

도에 도시된 바와 같이

속성 폴더 : 속성 폴더 아래에는 dev, online, test, uat 등 다양한 환경에 따라 별도의 폴더가 있으며 각 폴더에는 현재 환경의 구성 정보가 저장됩니다.
spring 폴더 : 일반적인 JSF 구성(jsf.xml) 및 xml 구성을 통해 주입되어야 하는 기타 비즈니스 시나리오와 같은 xml 구성 정보를 저장합니다. 물론 springboot 공식 웹사이트의 제안에 따라 모든 사람은 주석 코드를 사용하여 Bean 주입을 구현하고 xml 메서드를 최소화해야 합니다.
application.properties 파일 : 이 파일은 핵심 구성 spring.profiles.active=**를 통해 현재 프로파일 환경을 식별합니다. 물론 다른 전역 클래스 구성도 여기에 배치할 수 있습니다. 그림과 같이 spring.profiles.active의 값을 변경하려면 서로 다른 배포 그룹을 기반으로 이 파일을 덮어써야 하기 때문에 Xingyun 배포의 그룹 구성에서 application.properties 파일을 구성해야 합니다. 아래에. 물론 런타임 시작 지침을 통해 다양한 프로필을 선택할 수도 있습니다.
중요.properties 파일 : 이 파일은 JD Xingyun 배포 프로토콜입니다. 비밀 키와 같은 보안 수준이 높은 파일은 암호화된 방식으로 이 파일에 저장되며 Xingyun 배포 그룹의 원격 구성에 배포됩니다.

클라우드 배포의 구체적인 구성은 다음과 같습니다.

b. 속성 파일 로딩

일반적인 상황에서는 Properties/**/*.properties 아래의 구성 파일이 시작 항목에 자동으로 로드되지 않습니다. 따라서 동적 로딩을 위해서는 추가적인 방법이 필요하며, 구체적인 방법은 환경 변수와 결합된 스프링 프레임워크의 PropertySourcesPlaceholderConfigurer 클래스 속성을 통해 구성 파일을 일괄적으로 동적으로 로드하는 것이다. ( 추가 참고사항, springMVC 프레임워크인 경우 xml 구성 context:property-placeholder 속성을 통해 구현할 수도 있습니다. )

구체적인 코드는 다음과 같습니다.

/**
 * 配置文件环境配置
 *
 * @Author zhaoyongping
 * @date 2023/7/10 15:13
 * @ClassName EnvPropertiesConfig
 * @Descripiton 配置文件环境配置
**/
@Configuration
public class EnvPropertiesConfig {
    /**
     * 加载属性配置
     *
     * @param environment 环境属性
     * @return PropertySourcesPlaceholderConfigurer
     * @author zhaoyongping
     * @date 2023/7/10 15:13
     * @description 加载属性配置
     */
    @Bean
    public static PropertySourcesPlaceholderConfigurer propertySourcesPlaceholderConfig(Environment environment) throws IOException {
        PropertySourcesPlaceholderConfigurer config = new PropertySourcesPlaceholderConfigurer();
        String[] activeProfiles = environment.getActiveProfiles();
        if (activeProfiles.length > 0) {
            String resourceUrl = "classpath:properties/" 
                         + environment.getActiveProfiles()[0] + "/*.properties";
            config.setLocations(
           new PathMatchingResourcePatternResolver().getResources(resourceUrl));
        } else {
            //兜底策略
            config.setLocations(
            new PathMatchingResourcePatternResolver()
            .getResources("classpath:properties/dev/*.properties"));
        }
        return config;
    }


}

요약하다

위의 단계를 통해 컴파일되고 패키징된 이미지는 환경 변수에 바인딩될 필요가 없으며 실행을 시작할 때 다양한 그룹을 기반으로 application.properties 파일을 동적으로 구성하면 다양한 환경에 적응할 수 있다는 것을 알 수 있습니다. 런타임 시 구성 파일을 변경할 수 있는 이 메커니즘은 클라우드 네이티브 시대의 컨테이너화된 배포 솔루션에 더 적합하며 서비스의 이식성에도 도움이 됩니다. 물론 위의 내용은 저자의 개인적인 실제 경험일 뿐, 이것이 최선의 실무적 해결책이라는 의미는 아닙니다.

저자: JD Logistics Zhao Yongping

출처: JD Cloud 개발자 커뮤니티 Ziyuanqishuo Tech 재인쇄 시 출처를 명시해 주세요.

Spring 구성 파일의 마법 연금술: 컨테이너화 시대를 위한 완벽한 레시피를 만드는 방법 | JD Logistics Technical Team

머리말