Argo Rollouts using kube configmap in blue/green deploy strategy

[i25959341]

In a Kubernetes microservice environment, typically a Service A talks to Service B over https. Using argo in a blue/green rollout strategy, how do we get Service A blue/canary to talk to Service B blue/canary?

[kostis-codefresh]

This is a very common question and I recently added a non-answer to the FAQ https://argoproj.github.io/argo-rollouts/FAQ/#how-can-i-deploy-multiple-services-in-a-single-step-and-roll-them-back-according-to-their-dependencies

Unfortunately Argo Rollouts currently doesn't know or track service dependencies. It is focused on a single service/application only

Your options

1. Construct something on top of Argo Rollouts that handles this.
2. Try some hacks with Kustomize and configmap generators that might work or not in your case (there are too many limitations and assumptions for this to work as expected)
3. Perform individual backwards and forwards compatible deployments (see below)

I personally recommend the last option (until somebody implements 1)

Basically

1. Do a rollout on Service B first (Service A is still original version)
2. If things go wrong Service B will be rolled back
3. If things are ok new version of Service B will be up (but old version of service A will talk to it)
4. Do a rollout on Service A (Service B is already at new version)
5. If things are ok both services are on new version. If not, you only rollback service A (but it still talks to new version of Service B and you already know that this works from the previous deployment)

It is the same idea as with database refactorings if you have seen how deployments work there with backwards/forward changeset refactorings.

[sourceful-karlson]

tks for you answer