Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

restart behavior when using network_mode: service #10263

Closed
nicks opened this issue Feb 9, 2023 · 5 comments · Fixed by #10273
Closed

restart behavior when using network_mode: service #10263

nicks opened this issue Feb 9, 2023 · 5 comments · Fixed by #10273

Comments

@nicks
Copy link
Contributor

nicks commented Feb 9, 2023

Repro Steps

  • Use this Compose file:
services:
  pause:
    image: busybox
    command: "sleep infinity"
    ports:
    - 8800:8800
  bba:
    network_mode: "service:pause"
    image: busybox
    command: "sh -c 'echo ok > index.html && busybox httpd -f -p 8800'"
    depends_on:
    - pause
  • docker compose up -d
  • curl localhost:8800 -> returns "ok"
  • docker compose restart pause
  • curl localhost:8800

Expected Result

Server returns "ok"

Actual Result

Unable to connect

Additional context

Sometimes I work with services that need to speak to each other on localhost. So I use Pod-like networking so that all my containers can reach each other. There's a pause container that sets up the network namespace, and the other compose services join to that pause container. That's what this compose file is implementing.

But suppose I want to expose a new port on the network. I add it to the pause service and run docker compose restart pause.

Oops! everything is now broken, because bba's network got disconnected from the pause container.

If I restart bba, the container works again.

I'm not sure what feature I'm actually asking for here. Maybe we should auto-restart 'bba' when the pause container restarts? Not sure.

[edit - rewrote the ticket to be a bit more structured]

@nicks
Copy link
Contributor Author

nicks commented Feb 9, 2023

(this is on compose 2.15.1)

(also, it took me quite a while to figure out why my containers were randomly breaking, though it made sense once i figured out the repro case)

@melyux
Copy link

melyux commented Jul 25, 2023

@ndeloof Does that change apply to the case where the first container is restarted using autoheal? Your doc says:

"This applies to an explicit restart controlled by a Compose operation, and excludes automated restart by the container runtime after container died."

@systemmonkey42
Copy link

systemmonkey42 commented Apr 20, 2024

Hi,

I realise this is an old issue, but I wondered about this

  • restart: when true a Compose implementation MUST restart service after dependent service has been restarted.

vs

  • restart: when true a Compose implementation MUST restart this service after updates to the dependency service.

If a dependent service restarts because of failure, exit, termination or "autoheal" as mentioned above, the service which depends on it, should also be restarted.

I notice it currently only applies after a manual docker-compose-restart or as the result of a configuration change.

In my case, the "depends_on" is accompanied by a "network_mode: service:<dependent_service>", which means the
container MUST be restarted after the dependent container restarts or all network connectivity is lost.

Is there a way to express this requirement in the current implementation?

Thanks

@ndeloof
Copy link
Contributor

ndeloof commented Apr 20, 2024

@systemmonkey42 compose only can manage restart triggered by an explicit command, (auto)restart after container failure is handled by docker engine, which doesn't have such a "dependencies" logic.

@systemmonkey42
Copy link

systemmonkey42 commented Apr 20, 2024

(auto)restart after container failure is handled by docker engine

Makes sense. I ended up using a simple healthcheck which determines if the default route has disappeared, combined with an autoheal container.

Thanks for the response, and sorry for the noise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants