Incorrect Handling of Active Profiles in Docker Compose Integration

[kcsurapaneni]

Issue Description:
When using Docker Compose in combination with Spring Boot and defining multiple services with profiles in the compose.yaml file, there seems to be an issue with the Spring Boot behavior when specifying an active profile. Specifically, even if only one profile is specified, Spring Boot is considering all the services, leading to unexpected behavior.

Steps to Reproduce:

1. Define multiple services with profiles in the docker-compose.yaml file.

version: "3"
services:
  authorization_server:
    profiles:
      - server
    platform: linux/amd64
    image: mysql:8.0.23
    container_name: server_database
    ---
    ----
  client:
    profiles:
      - client
    platform: linux/amd64
    image: mysql:8.0.23
    container_name: client_database
    ---
    ---

2. Manually start all the services in the Docker Compose file.
3. In the Spring Boot application, set spring.docker.compose.profiles.active=server (or any other specific profile).
4. Observe that Spring Boot is considering all the active services instead of just the one with the specified profile.

Expected Behavior:
When specifying an active profile, Spring Boot should only consider the services associated with that profile, and ignore the others.

Actual Behavior:
Spring Boot is considering all services, leading to conflicts, as illustrated by the following error message:

***************************

APPLICATION FAILED TO START

***************************

Description:

Parameter 1 of method dataSource in org.springframework.boot.autoconfigure.jdbc.DataSourceConfiguration$Hikari required a single bean, but 2 were found:

    - jdbcConnectionDetailsForClient_database: defined in unknown location

    - jdbcConnectionDetailsForServer_database: defined in unknown location

This may be due to missing parameter name information

Action:

Consider marking one of the beans as @Primary, updating the consumer to accept multiple beans, or using @Qualifier to identify the bean that should be consumed

Additional Information:

• Spring Boot version: 3.2.3
• Docker Compose version: v2.24.6-desktop.1
• Operating System: macOS Sonoma 14.2.1

Possible Solution:
Ensure that Spring Boot correctly filters and activates only the services associated with the specified active profile in Docker Compose.

Note:
This issue is causing inconvenience in managing profiles and services, and a resolution is highly appreciated.

[wilkinsona]

The profiles are used to decide which services, if any, Spring Boot's integration should start. If one or more of the services in the compose.yaml file is already running, this step is skipped and Spring Boot uses all of the already running services.

Why are you manually starting the services rather than allowing Spring Boot to control their lifecycle? If you omit this step, I believe things should works as you want. Would that meet your needs?

[mhalbritter]

Adding to that, I'm not sure we can find out when the services are running to what profile they belong, so filtering them on the profile after they have been started might not be possible.

[kcsurapaneni]

@wilkinsona, I encountered an issue in one of my practice projects with three applications (authorization, client, and resource), each requiring a separate database (hence, multiple DB services). I've organized the project with the following structure:

oauth2
- authorization
    - src
- client
    - src
- resource
    - src
compose.yaml

You can find the project on GitHub: oauth2. The goal is for the authorization application to use only the authorization_database service and the client application to use the client_database service.

The authorization application should exclusively utilize the authorization_database service, while the client application is intended to rely on the client_database service. Initially, I contemplated utilizing the profile feature in Docker to achieve this segregation. However, upon initiating the first application (authorization), everything seemed to be in order, as it selectively launched the authorization_database service from the Docker Compose configuration. Subsequently, upon starting the client application, I observed that it failed to initiate the other database service (client_database). The log displayed a message stating "There are already Docker Compose services running, skipping startup," and the client application's schema files were overwritten on the authorization_database. To address this, I manually started both services, expecting that specifying an active profile would make Spring Boot pick only the relevant service from Docker Compose. Unfortunately, both services were considered.

I believe there are two issues at play here:

1. The profile matching between Spring Boot and Docker Compose is not functioning as expected.
2. When starting the second application (client), the spring.docker.compose.profiles.active=client_database property is ignored, and it ends up considering the already running service (authorization_database), leading to schema file conflicts.

[wilkinsona]

Thanks for the additional details. The profile matching may not be working as you would like but it is working as expected and, unfortunately, I don't think it will be possible for us to make it work as you would like.

We use docker compose ps to examine the running services. Unfortunately, it doesn't include any information about the profiles that were active and resulted in the service being started. As such, we can't filter out any existing running services based on the profiles that are active when you start the second application.

For your situation where you have three separate apps and three separate services, I think you would be better using three separate compose.yaml files, one for each app. I also think it would align more closely with the spirit of the Docker Compose documentation and the recommendation that "the core services of your application shouldn't be assigned profiles so they are always enabled and automatically started". As far as I can tell, your current approach relies on every service being assigned to a profile.

[kcsurapaneni]

@wilkinsona Originally, I intended to employ individual compose.yaml file for each application. However, when initiating the authorization application, it failed to retrieve the file located in the authorization folder. Consequently, I reverted to placing the compose.yaml file in the root directory (oauth2). Just now, I retried the process, but this time, I included the property spring.docker.compose.file=authorization/compose.yaml. This adjustment successfully enabled the application to recognize and utilize the specified service. I replicated the same modification in the client application, and it is also started working. Thank you!