You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was writing a sample application to show how tracing works with the new Micrometer support. For this I have 2 Spring Boot applications which need to connect to the same Zipkin instance. I figured to use the Docker Compose support to have both connect to the same running container. I was not able to accomplish this.
Each application will create it's own network (despite a network being added to the compose.yaml) and as such isn't able to start the container (depending on which application starts first the last one fails).
I also tried to remove the explicit network but then one is generated as well.
Tried to explicitly name the container, which fails as the names have to be unique and it will not connect to the other container.
I also played around with doing START instead of UP but that doesn't yield any better result either.
So I'm probably doing something with the support that it wasn't (or isn't currently) designed for.
The result is 2 networks and a failing application.
So I hoped that a explicitly defined network would do the trick, but the network (judging from the output) is still prefixed with the project name.
2023-10-14T11:40:24.560+02:00 INFO 25467 --- [utReader-stderr] [ ] o.s.boot.docker.compose.core.DockerCli : Network recipe_9_4_i_a_recipe_9_4 Creating
2023-10-14T11:40:24.616+02:00 INFO 25467 --- [utReader-stderr] [ ] o.s.boot.docker.compose.core.DockerCli : Network recipe_9_4_i_a_recipe_9_4 Created
2023-10-14T11:40:24.617+02:00 INFO 25467 --- [utReader-stderr] [ ] o.s.boot.docker.compose.core.DockerCli : Container recipe_9_4_i_a-zipkin-1 Creating
2023-10-14T11:40:24.654+02:00 INFO 25467 --- [utReader-stderr] [ ] o.s.boot.docker.compose.core.DockerCli : Container recipe_9_4_i_a-zipkin-1 Created
2023-10-14T11:40:24.665+02:00 INFO 25467 --- [utReader-stderr] [ ] o.s.boot.docker.compose.core.DockerCli : Container recipe_9_4_i_a-zipkin-1 Starting
2023-10-14T11:40:24.937+02:00 INFO 25467 --- [utReader-stderr] [ ] o.s.boot.docker.compose.core.DockerCli : Container recipe_9_4_i_a-zipkin-1 Started
2023-10-14T11:40:24.938+02:00 INFO 25467 --- [utReader-stderr] [ ] o.s.boot.docker.compose.core.DockerCli : Container recipe_9_4_i_a-zipkin-1 Waiting
2023-10-14T11:40:30.442+02:00 INFO 25467 --- [utReader-stderr] [ ] o.s.boot.docker.compose.core.DockerCli : Container recipe_9_4_i_a-zipkin-1 Healthy
I can imagine that in a microservice environment it is (sometimes) needed to run multiple applications which share a container, like Zipkin in this example. It would be nice if this code be made possible through the docker compose support.
As a workaround I now manually start zipkin and configure it in the application.properties but it does away from the checkout and run experience.
The text was updated successfully, but these errors were encountered:
Pointing it to the exact same file does indeed work.
If I however include the same compose.yaml in both projects (without specifying spring.docker.compose.file it doesn't work (even with an explicit network declaration in the compose.yaml).
That's to be expected as that's how Docker Compose works.
I think it's worth mentioning in the docs that spring.docker.compose.file can be used to share compose configuration between projects.
wilkinsona
changed the title
Docker Compose support for multiple applications
Document that spring.docker.compose.file can be used to share Docker Compose configuration between applications
Oct 14, 2023
philwebb
changed the title
Document that spring.docker.compose.file can be used to share Docker Compose configuration between applications
Document that 'spring.docker.compose.file' can be used to share Docker Compose configuration between applications
Oct 16, 2023
I was writing a sample application to show how tracing works with the new Micrometer support. For this I have 2 Spring Boot applications which need to connect to the same Zipkin instance. I figured to use the Docker Compose support to have both connect to the same running container. I was not able to accomplish this.
Each application will create it's own network (despite a network being added to the
compose.yaml
) and as such isn't able to start the container (depending on which application starts first the last one fails).I also tried to remove the explicit network but then one is generated as well.
Tried to explicitly name the container, which fails as the names have to be unique and it will not connect to the other container.
I also played around with doing START instead of UP but that doesn't yield any better result either.
So I'm probably doing something with the support that it wasn't (or isn't currently) designed for.
The result is 2 networks and a failing application.
So I hoped that a explicitly defined network would do the trick, but the network (judging from the output) is still prefixed with the project name.
I can imagine that in a microservice environment it is (sometimes) needed to run multiple applications which share a container, like Zipkin in this example. It would be nice if this code be made possible through the docker compose support.
As a workaround I now manually start zipkin and configure it in the
application.properties
but it does away from the checkout and run experience.The text was updated successfully, but these errors were encountered: