2

We have several apps that are part of a larger app.

Each of these apps has a Docker Image built on every commit.

I would like to you use docker swarm mode, and docker stacks to deploy/update this larger app automatically.

Lets pretend I have this compose file (left parts out that are irrelevant)

version: '3'
services:
    product_service:
       image: myregistry.com/product_service:c8372d
       ..
    cart_service:
       image: myregistry.com/cart_service:ee7f32
       ..

When I commit a change to the cart service repo, I would like the stack to update only the cart_service, but leave the product_service pinned at it's current version. Also when the product service is updated I would like to be able to update only that service but leave the cart service at it's currently pinned version.

What are my options in this case?

What I can think of:

  • do some fancy things and regenerate the compose file on commit and only changing the parts I need changed
  • don't use docker stack deploy and instead use the old docker service create
  • some type of environment variable passing into the compose file (problem here is that each service would still have to know the current version of the other services right?)
  • use a different stack for each service (Is there anything wrong with this or problems?)

Am I overlooking something? Was building like this not intended? What is the better approach here?

Kyle Gobel
  • 5,530
  • 9
  • 45
  • 68

1 Answers1

1

I find it easiest to go with the last option, split each service into its own stack without touching anything else. Then you promote the stack of a single service. To do this, I'd add two prerequisites:

  • Define your networks in advance. Then in your compose, define them as external to allow the services to connect to each other. This is the biggest piece you lose when you split up the services into separate stacks.

  • Run your own registry. To me, this is safer than just relying on pinning versions. Pinning will ensure that you pull the same version across all nodes in the swarm, but if you are promoting from dev to test to prod, those will be separate stacks, and probably separate swarms entirely. And for me, it's much easier to rely on a tag in the repo that only gets updated in a controlled manner (CI/CD scripts).

Separate stacks has the pro of independently updating each service without breaking anything else. But on the flip side, the con is that you need to independently update each service when there's a change affecting everything. This may mean more scripting/automation is needed from you to manage the environment.

BMitch
  • 231,797
  • 42
  • 475
  • 450
  • Thanks BMitch, trying a setup like this now, services are on the same overlay network but having trouble figuring out what host names to use. i.e ``http://cart_service`` does not work from the product_service – Kyle Gobel Feb 10 '17 at 15:59
  • Within containers you use the name of the service if they are on the same network. Outside of containers, you need to expose a port and connect o the docker host on that port. – BMitch Feb 10 '17 at 16:33
  • bahh, i had just named the service wrong. That's 2 hours i'll never get back :). Thanks for the help – Kyle Gobel Feb 10 '17 at 17:32