Answers: <p>To ensure a stack is in a consistent state after an upgrade, see the documentation on <a href="https://docs.docker.com/compose/compose-file/compose-file-v3/#update_config" rel="nofollow noreferrer">update_config</a>. <code>failure_action</code> defaults to <code>pause</code> so you need to set it to <code>continue</code> to ensure docker updates the services regardless.</p>
  <pre class="lang-yaml prettyprint-override"><code>services:
    proxy:
      deploy:
        update_config:
          on_failure: continue
    backend:
      deploy:
        update_config:
          on_failure: continue
  </code></pre>
  <p>That said - docker does not support green/blue deployments - but it is possible to use network aliases to ensure proxy:2 does not route to backend:1. Something like this for e.g.:</p>
  <pre class="lang-yaml prettyprint-override"><code>services:
    proxy:
      image: proxy:${VER}
      environment:
        BACKEND_HOST: backend-${VER}
  
    backend:
      image: backend:${VER}
      networks:
        default:
          aliases: [&quot;backend-${VER}&quot;]
  </code></pre>
  <p>To achieve your final requirement, you need to set the <code>update_config</code> <code>parallelism</code> to 1, and ensure that the <code>order</code> is set to <code>start-first</code>.</p>
  <p>A naive deployment would have a race condition if &quot;proxy:2&quot; is available before &quot;backend:2&quot; is available, but as long as there is a healthcheck, &quot;proxy:2&quot; can prevent itself receiving traffic until it has a successful connection test to &quot;backend-2&quot;</p>
  <pre class="lang-yaml prettyprint-override"><code>services:
    proxy:
      image: proxy:${VER}
      environment:
        BACKEND_HOST: backend-${VER}
      healthcheck: [&quot;CMD&quot;, &quot;/bin/sh&quot;,&quot;-c&quot;,&quot;test_backend.sh&quot;]
  </code></pre>
  <p>Of course, you can run into problems if &quot;proxy:2&quot; finishes deploying, but &quot;backend:2&quot; errors out - you could eventually have a situation where you have no proxy:1 running, only proxy:2, but only backend:1 running and no backend:2. So you want to ensure the <code>update_config</code> delays updating the next task until the current one is health - or pause if that never happens.</p>
  <p>PS. It seems potentially much less hassle to just design and code around the principal that backwards compatibility of +-1 version is expected.</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-11-22T06:25:19.897Z
Answers: 2022-11-22T09:39:12.527Z
Answers: 2022-11-22T09:39:12.527Z
Answers: Chris Becke
Body: <p>I have a Docker Swarm with three services: <code>proxy</code>, <code>backend</code>, <code>frontend</code>.</p>
  <p>Currently it seems that if I do <code>docker stack deploy</code> and one service fails, it might just rollback to the previous version while the rest will be on the new version.</p>
  <p>I want to ensure two things:</p>
  <ol>
  <li><p>A request coming to <code>proxy</code> will always be served <strong>by the same combination of service versions.</strong> Doesn't matter if old or new, but I don't want <code>proxy:v2</code> to route a request to <code>backend:v1</code>.</p>
  </li>
  <li><p><strong>No downtime during an upgrade.</strong> <code>proxy:v1</code> should continue serving requests until the full set of new services is ready, and only then the failover should happen.</p>
  </li>
  </ol>
  <p>Is this possible?</p>
  
Tags: <docker><docker-swarm>
Title: How to update Docker Swarm services all at once?
UserDisplayName: Emily
ThreadText: # How to update Docker Swarm services all at once?
  
  (Asked by: username_0 on 2022-10-29)
  
  I have a Docker Swarm with three services: `proxy`, `backend`, `frontend`.
  
  Currently it seems that if I do `docker stack deploy` and one service fails, it might just rollback to the previous version while the rest will be on the new version.
  
  I want to ensure two things:
  
  1. A request coming to `proxy` will always be served **by the same combination of service versions.** Doesn't matter if old or new, but I don't want `proxy:v2` to route a request to `backend:v1`.
  2. **No downtime during an upgrade.** `proxy:v1` should continue serving requests until the full set of new services is ready, and only then the failover should happen.
  
  Is this possible?
  
  **Tags:** docker, docker-swarm
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2022-11-22. Score: 1
  
  To ensure a stack is in a consistent state after an upgrade, see the documentation on [update\_config](https://docs.docker.com/compose/compose-file/compose-file-v3/#update_config). `failure_action` defaults to `pause` so you need to set it to `continue` to ensure docker updates the services regardless.
  
  ```yaml
  services:
    proxy:
      deploy:
        update_config:
          on_failure: continue
    backend:
      deploy:
        update_config:
          on_failure: continue
  
  ```
  
  That said - docker does not support green/blue deployments - but it is possible to use network aliases to ensure proxy:2 does not route to backend:1. Something like this for e.g.:
  
  ```yaml
  services:
    proxy:
      image: proxy:${VER}
      environment:
        BACKEND_HOST: backend-${VER}
  
    backend:
      image: backend:${VER}
      networks:
        default:
          aliases: ["backend-${VER}"]
  
  ```
  
  To achieve your final requirement, you need to set the `update_config` `parallelism` to 1, and ensure that the `order` is set to `start-first`.
  
  A naive deployment would have a race condition if "proxy:2" is available before "backend:2" is available, but as long as there is a healthcheck, "proxy:2" can prevent itself receiving traffic until it has a successful connection test to "backend-2"
  
  ```yaml
  services:
    proxy:
      image: proxy:${VER}
      environment:
        BACKEND_HOST: backend-${VER}
      healthcheck: ["CMD", "/bin/sh","-c","test_backend.sh"]
  
  ```
  
  Of course, you can run into problems if "proxy:2" finishes deploying, but "backend:2" errors out - you could eventually have a situation where you have no proxy:1 running, only proxy:2, but only backend:1 running and no backend:2. So you want to ensure the `update_config` delays updating the next task until the current one is health - or pause if that never happens.
  
  PS. It seems potentially much less hassle to just design and code around the principal that backwards compatibility of +-1 version is expected.
  
  
  ---
  
  