Moby: restart option for docker services (1.12 swarm mode)

[miketonks]

It would be useful to have "docker service restart" command (docker 1.12 swarm mode):

docker service --help

Usage:  docker service COMMAND

Manage Docker services

Options:
      --help   Print usage

Commands:
  create      Create a new service
  inspect     Display detailed information on one or more services
  tasks       List the tasks of a service
  ls          List services
  rm          Remove a service
  scale       Scale one or multiple services
  update      Update a service

Proposal to add: restart Restart a service (possibly also start & stop?)

Currently restart can be achieved using update command and making some small change, e.g. environment variable:

docker service create --name nginxtest --replicas 5  nginx:alpine

...

docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS               NAMES
a423e652d7aa        nginx:alpine        "nginx -g 'daemon off"   2 minutes ago       Up 2 minutes        80/tcp, 443/tcp     nginxtest.2.9ovt80inulc83dx54s44abwcl
03d0fd19495c        nginx:alpine        "nginx -g 'daemon off"   2 minutes ago       Up 2 minutes        80/tcp, 443/tcp     nginxtest.3.2p6i7koib4jyft8hjm040n4r9
f4fd7037ca64        nginx:alpine        "nginx -g 'daemon off"   2 minutes ago       Up 2 minutes        80/tcp, 443/tcp     nginxtest.1.5icr2v7lo4bc1gmfeugjaeafb
56c1885c48ff        nginx:alpine        "nginx -g 'daemon off"   2 minutes ago       Up 2 minutes        80/tcp, 443/tcp     nginxtest.5.5t72qvz1he48azymoo7w1s83y
03ff0eda8a8d        nginx:alpine        "nginx -g 'daemon off"   2 minutes ago       Up 2 minutes        80/tcp, 443/tcp     nginxtest.4.32ze8c6s2pr9ogvc9i6a84qak

...

docker service update nginxtest -e TEST:foo
nginxtest

docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                  PORTS               NAMES
6061a6e89733        nginx:alpine        "nginx -g 'daemon off"   2 seconds ago       Up Less than a second   80/tcp, 443/tcp     nginxtest.1.awphkdsvuwbifayvbzvyy8cju
d827eeeb1826        nginx:alpine        "nginx -g 'daemon off"   2 seconds ago       Up Less than a second   80/tcp, 443/tcp     nginxtest.5.2dfooji7rjdjzuahfbx880p5z
fd17d1d87e50        nginx:alpine        "nginx -g 'daemon off"   2 seconds ago       Up Less than a second   80/tcp, 443/tcp     nginxtest.4.1b1a9pn67zlf9cfmz5s2q2j6x
fdc87806ce6a        nginx:alpine        "nginx -g 'daemon off"   2 seconds ago       Up Less than a second   80/tcp, 443/tcp     nginxtest.3.cz797anjh5kqrexa5m2wntj27
36943cef6abd        nginx:alpine        "nginx -g 'daemon off"   2 seconds ago       Up Less than a second   80/tcp, 443/tcp     nginxtest.2.323q7w45ycoe01xdmlnnjn9sd

However update with no changes does nothing, and setting only one env variable can remove existing ones so this option does not feel quite right.

Update also (from my limited understanding) removes the actual container and creates a new one, in order to allow new settings to be applied. Restart should simply restart the container without removing and recreating it.

Workaround is to read tasks list and iterate over containers, issuing restart to individual hosts and containers, but it would be more convenient to restart via swarm.

[cpuguy83]

But why do you need to restart?

[miketonks]

Our containers do some initialisation at startup (downloading config data).

We want to trigger this to happen again, so new config will be loaded. We're not updating the image (update would work great for that).

Same thing could be achieved with a signal handler, but we need to ensure signal goes to all the containers in the service.

[spiralsyzygy]

+1 on this feature request

[itzg]

FYI @miketonks I was able to trick it into restarting a service by adding a bogus environment variable, like:

docker service update --env-add UPDATE=1 my_service

[thaJeztah]

Note that docker 1.13 will have a --force option, that allows you to force an update, even if no changes are detected. See https://github.com/docker/docker/pull/27596 for the implementation

[fer2d2]

This is very useful when you are deploying PHP applications. When you update your data-only container with your application code, you need to restart Nginx and FPM to reload the data volume in both containers.

[inikhilp]

You can also do following to restart a service

docker service scale SERVICE_NAME=0
docker service scale SERVICE_NAME=1

[miggy282]

+1

[miketonks]

Thanks for all the advice. I think this issue can be closed now.

[alex-dixon]

These seem like hacks. Should there be a command for this? Even if it aliases update --force (don't know what the command actually does)

[gabrielfsousa]

i would like to know how to restart a service too

[gabrielfsousa]

thanks @thaJeztah --force make my day !! 👍

[koenpunt]

@inikhilp that won't work for services with mode=global

[nestorbolivar]

Agree we should have a docker service {restart, stop, start} service_name

[Dean-Christian-Armada]

I agree with @nestorbolivar , the scale command will not work for global. So my current turn around for this is just to rm the service and start again

[giorgited]

+1

[alrf]

+1

[deniercounter]

+1

[suiwenfeng]

+1 That`s better if changes on running container won`t loss after docker service update.

[TheM1984]

+1

I would very much like this option to. With developing java apps, I run it in debug mode in eclipse much. But also in times want te rerun the containers with the new jar file.

Next to down and up scaling the service, there is another method I use:

docker stop $(docker ps -qf name=SERVICENAME)

Don't know if that works for windows though.

[davidwaizer]

+1 for restart

[rodrigopmatias]

+1 to restart

[AnthonyTsang]

+1 to restart

[miketonks]

Seems like a popular issue, I'll reopen

[AnthonyTsang]

My case is that, I have a migration service which is global. Every time I deploy a change, this service should start and check if there is any migration added and try run it. If it exits without error, those web service will be updated. Either case, the migration service is shutdown until next deployment.

My workaround is to remove the migration service and create it again in every deployment.

[prologic]

I use-case is autodock-cron where I'd like to call ServiceRestart(...) on the docker client (API). The basic idea here is a "service" that is part of a larger "stack" that is periodically restarted on a schedule.

[peterstory]

I can describe a specific use-case where the ability to restart without recreating the container is valuable.

My stack contains a postgres container. I needed to enable the pg_stat_statements shared library in order to debug expensive queries in production. However, loading the shared library requires editing a config file and restarting the postgres process. I cannot simply scale the service up and down, or else my edits to the config file will be wiped out.

Now technically, it would be cleaner to simply edit the entrypoint to make the edit to the config file, and update the service. However, that seems like a lot of work to run some debugging commands. I suspect that this type of scenario is not too uncommon.

My story has a sad ending: I issued a docker restart postgres, which stopped the running container. Swarm saw this, and create a new postgres container. Then, docker restart started the old postgres container. Now there were two postgres containers on the same host, accessing the same database volume! This corrupted my database, and I had to restore from backup.

[thiagolsfortunato]

Any news ?

[schurigh]

+1

[JonDum]

My story has a sad ending: I issued a docker restart postgres, which stopped the running container. Swarm saw this, and create a new postgres container. Then, docker restart started the old postgres container. Now there were two postgres containers on the same host, accessing the same database volume! This corrupted my database, and I had to restore from backup.

I had this happen too thinking I could docker restart out from under swarm's nose with no issue — after all swarm is just managing containers right? Ended up with several dozen copies of a container before realizing what was going on 😆

So yea, definitely don't use docker restart in a swarm context.

[CWX-iggy]

You can also do following to restart a service

docker service scale SERVICE_NAME=0
docker service scale SERVICE_NAME=1

That sort of defeats the purpose of maintaining service uptime, continuous deployment etc. if you have to take all your services offline temporarily...

AFAIK, docker service update --force only forces an update of the image. I'm not certain that it actually restarts the service, or if it does, it's certainly not restarting it with the new image. In many cases, I have had to manually scale the service to 0 and then back up to >1 in order for the service to restart with the new image.

Preferably the service update should do a rolling upgrade - which is kinda the point in the first place. Failing that, a docker service [stop|start|restart] would be the next best option.

[tbolis]

+1

[snowshoes]

Is there any way to restart all services ?
I ran into a situation where all services has been shut down by accident, it would be nice to have away to avoid starting each one by one.

[williamwebb]

docker service ls -q | xargs -t -n1 docker service update --force should work to restart all services at once.