Add a property to enable/disable service connection in Docker Compose Support

[doljae]

Description

Spring Boot provides Docker Compose support, which automatically creates ServiceConnection instances based on the services defined in a docker-compose.yml file. These connections override the default connection settings of the Spring Boot application, which can be very convenient.

However, this behavior can cause issues in certain scenarios, making it difficult to use an existing docker-compose.yml as-is.

For example, when using Redis, a RedisDockerComposeConnectionDetails instance is created internally. If the container does not use the default Redis port (6379), this leads to an exception at runtime. Similar problems can arise with other services or due to both technical and non-technical reasons affecting the docker-compose.yml.

Some users may simply want to reuse their existing docker-compose.yml to manage service lifecycles in conjunction with the Spring Boot application, without necessarily leveraging the automatic service connection feature.

Proposal

Introduce a new property that allows users to disable the automatic creation of service connections from Docker Compose.

This would provide greater flexibility, enabling users to:

• Run existing docker-compose.yml files without modification.
• Opt out of automatic service connection behavior when not needed.
• Still benefit from Docker Compose lifecycle management.

Example

spring:
  docker:
    compose:
      service-connection:
        enabled: false

This addition would allow developers to integrate Docker Compose into their Spring Boot applications in a more controlled and adaptable way.

[wilkinsona]

I'm not sure I understand the need here. If you want to disable the service connection support entirely, remove the spring-boot-docker-compose dependency from your application. You'll lose lifecycle management, but I think that's preferable to providing multiple ways to do the same thing. Similarly, if you want to ignore an individual service, you can do so with a label.

[doljae]

Hello @wilkinsona.
I understand what you're saying and I agree with you completely, and I also see what your concerns are.

I just want to say that as a user, being able to control docker-compose.yml and the lifecycle of a container with application settings is a great feature, and I remember that being the case when Docker Compose support was first introduced.

While it can be convenient to override the connection information to ensure that your application is well connected to the containers you run, it can also be confusing for users, may also not want to modify docker-compose.yml. And as you may have noticed, the ServiceConnection settings as currently implemented don't cover all the different settings you can set with docker-compose.yml.

This suggestion actually started with the realization that the current ServiceConnection implementation doesn't detect it when set to a Redis Cluster structure in docker-compose.yml. I haven't checked every Docker Compose-related ServiceConnection, but I thought one good, convenient way to solve this problem would be to support the original Docker Compose support, i.e. not overriding the container connection information to the application.

[doljae]

As you have guided, if we don't want to use specific container connection information, we can use promised labels, or we can remove the Docker Compose dependency from our project and use docker-compose.yml with your project in a different way.

If this is the direction of the project, I agree with this. But even so, I think the feature I'm proposing could in many ways allow users to have only the good parts of what they want.

On second thought, if controlling containers with specific labels is the direction of the project, I think we could use this to improve some ServiceConnection implementations. I'll propose this as a separate issue and PR.