SpringBoot's multi-environment packaging and configuration file exclusion methods

SpringBoot project multi-environment packaging and configuration file exclusion

In actual development, Spring Boot projects usually need to adapt to different operating environments, such as development environment, test environment, production environment, etc. Configurations in these environments may contain sensitive information, such as database connection passwords, API keys, etc. Therefore, when packaging a project, we not only need to support multi-environment configuration, but also consider how to exclude sensitive configuration files to ensure security.

1. Implementation method of multi-environment configuration
2. How to exclude configuration files when packaging
3. Best practices for dynamically loading external configuration files

Implementation method of multi-environment configuration

1. Configure multi-environment files

Spring Boot loads by defaultorConfiguration file.

In order to support multi-environment configuration, the environment can be distinguished by file naming, such as:

• : Development environment configuration
• : Test environment configuration
• : Production environment configuration

Each environment configuration file can define different parameters. For example, the following is the database configuration for the development and production environment:

Development environment:

server:
  port: 8081

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/dev_db
    username: dev_user
    password: dev_password

Production environment:

server:
  port: 8080

spring:
  datasource:
    url: jdbc:mysql://prod-server:3306/prod_db
    username: prod_user
    password: prod_password

2. Dynamic switching environment

existConfigure the default activation environment in the following:

spring:
  profiles:
    active: dev

Dynamically specify the environment when started with command line parameters:

java -jar  --=prod

How to exclude configuration files when packaging

In some cases, sensitive configuration files (e.g.) may contain important information about the production environment.

We want these files to be excluded when packaged, rather than being included directly in the final JAR package.

1. Use Maven to exclude configuration files

Method 1: Bymaven-resources-plugin

In MavenIn, bymaven-resources-pluginExclude files during resource packaging:

<build>
    <resources>
        <resource>
            <directory>src/main/resources</directory>
            <excludes>
                <exclude></exclude>
                <!-- Troubleshoot all configuration files in all directories <exclude>**/*.*</exclude> -->
            </excludes>
        </resource>
    </resources>
</build>

Method 2: Bymaven-assembly-plugin

usemaven-assembly-pluginCustom packaging configuration:

Add plugin configuration:

<build>
    <plugins>
        <plugin>
            <groupId></groupId>
            <artifactId>maven-assembly-plugin</artifactId>
            <version>3.3.0</version>
            <configuration>
                <descriptors>
                    <descriptor>src/main/assembly/</descriptor>
                </descriptors>
            </configuration>
        </plugin>
    </plugins>
</build>

createdocument:

<assembly xmlns="/plugins/maven-assembly-plugin/assembly/1.1.3">
    <id>jar-with-dependencies</id>
    <formats>
        <format>jar</format>
    </formats>
    <fileSets>
        <fileSet>
            <directory>${}/src/main/resources</directory>
            <excludes>
                <exclude></exclude>
            </excludes>
        </fileSet>
    </fileSets>
</assembly>

Execute the build command:

mvn clean package

2. Use Gradle to exclude configuration files

In GradleIn the file, you can passprocessResourcesTask exclusion file:

 {
    exclude ''
}

Run at build time:

./gradlew clean build

Dynamically load external configuration files

To further improve security, we can store sensitive configuration files externally and use them dynamically loaded.

1. Store external configuration files

Convert sensitive configuration files (e.g.) The secure path stored in the server, for example/etc/app-config/。

2. Specify the external configuration path at startup

By starting parameters--Specify the path to the external configuration file:

java -jar  --=/etc/app-config/

3. Configure environment variables

Specify the configuration path as an environment variable and automatically loads on startup:

export SPRING_CONFIG_LOCATION=/etc/app-config/
java -jar 

4. Specify an additional path in the configuration file

In the main configuration file, use-locationSpecify an additional loading path:

spring:
  config:
    additional-location: file:/etc/app-config/

Summarize

Multi-environment configuration:

• Create independent configuration files for different environments (、）。
• useDynamic switching environment.

Configuration file exclusion:

• Maven:passmaven-resources-pluginormaven-assembly-pluginExclude sensitive files.
• Gradle:passprocessResourcesConfigure exclusion files.

Dynamically load external configuration:

• Store sensitive files in external paths and load them through startup parameters, environment variables, or additional paths.

Recommended practice:

1. Externalization of sensitive information: Avoid packaging sensitive information into JARs.
2. Version control: Include environment-independent public configurations into version management, but exclude sensitive files.
3. Environmental isolation: Automatically deploy corresponding configurations in different environments through the CI/CD process.

The above is personal experience. I hope you can give you a reference and I hope you can support me more.