feature: moving ALB

[katcipis]

I was thinking about how to perform blue/green updates that works well with two scenarios that I know we have:

• the entire old resource group will be removed after update
• the same resource group will be used, with the old and new cluster inside

So, I thought on something like this:

azure_alb_move(src_resgroup, albname, dst_resgroup, vms_pattern)

The high level steps is:

• Collect all vms that are currently on the alb
• Add all vms from $dst_resgroup that matches the given $vms_pattern
• Remove old vms from alb
• If $src_resgroup != $dst_resgroup, move alb from src to dst, otherwise do nothing

This way it seems like a good building block for blue/green updates (nothing will be actually removed).

Performing a transition:

azure_alb_move("sourcegroup", "myalb", "destinygroup", "newvms*")

Ooops something went wrong, going back:

azure_alb_move("destinygroup", "myalb", "sourcegroup", "oldvms*")

When using the same resource group it is important to be able to differentiate between different clusters of VMs using a pattern (disambiguation)

[lborguetti]

What do you think about keep ALB in another resource group?

This way is more easy, you need remove the backendpool from VMs in old resource group and add to VM's in new resource group.

Example:

Deploy your green resource:

https://www.trendmicro.com/azure/wp-content/uploads/2016/11/Picture-2-1.png

Destroy your blue resource:

https://www.trendmicro.com/azure/wp-content/uploads/2016/11/Picture-3.png

[katcipis]

I would have a resgroup just for the ALB and instead of just one resgroup per env we would have always two. People are usually working that way on Azure ?

@tiago4orion @vitorarins what u guys think ?

[vitorarins]

Collect all vms that are currently on the alb
Add all vms from $dst_resgroup that matches the given $vms_pattern

I am not sure I understand. If we are going to collect all the vms that are in the ALB why do we need the vms pattern?