m-adawi / swarm-cd

SwarmCD: Declarative GitOps and Continuous Deployment tool for Docker Swarm.
GNU General Public License v3.0
54 stars 2 forks source link

feature request: handle stacks dependencies (i.e. external networks declared in other stacks) #61

Open sanzoghenzo opened 2 weeks ago

sanzoghenzo commented 2 weeks ago

There are some cases where there's the need of deploy stacks in a certain order.

A common example is deploying a single reverse proxy (traefik in my case) in its own stack and then attach the services to be published to the same network (declared as external in their stacks):

services:
   traefik:
       image: traefik:latest
       networks: [traefik-public]
# ...
networks:
  traefik-public:
    name: traefik-public
services:
    whoami:
      image: traefik/whoami
      networks: [traefik-public]
      # traefik labels here...
networks:
  traefik-public:
    external: true

At first boot SwarmCD could try to deploy the dependent services (whoami in this case) before the dependency (traefik), and this results in an error; only the dependency is deployed and one needs to wait the next cycle to get everything up and running.

While this could be a rare event (mostly during the bootstrap phase of a new infrastructure), it would be nice if we don't have to wait that long to reach consistency.

One way to try to solve that is to create a DAG based on the external resources declared in the stacks, but it would be a ton of work for little gain. Another, simpler approach would be to queue a failed deployment for retry at the end of the update stacks cycle, with a backoff limit to avoid infinite loops (it may be the case when one forgot to add a resource, either manually or via another stack)

m-adawi commented 1 week ago

One way to try to solve that is to create a DAG based on the external resources declared in the stacks, but it would be a ton of work for little gain. Another, simpler approach would be to queue a failed deployment for retry at the end of the update stacks cycle, with a backoff limit to avoid infinite loops (it may be the case when one forgot to add a resource, either manually or via another stack)

Or we can add something like depends_on in stack definition, similar to compose but for stacks

sanzoghenzo commented 1 week ago

Or we can add something like depends_on in stack definition, similar to compose but for stacks

Maybe I'm too ahead of time, but this would not work well with #23 especially if stacks that match a wildcard path have dependencies between each other. Anyway, this can wait until the other, more important issues are solved