Reputation: 5750
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:
docker stack deploy
and instead use the old docker service create
Am I overlooking something? Was building like this not intended? What is the better approach here?
Upvotes: 2
Views: 577
Reputation: 264156
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.
Upvotes: 1