Incorrect Handling of Active Profiles in Docker Compose Integration

[kcsurapaneni]

Incorrect Handling of Active Profiles in Docker Compose Integration

[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!