It would separate the вЂњtransientвЂќ data like OS disks etc from the business data. The default could be like now, which is very easy to use, but just have some extra optional settings where needed. Not unlike having separate OS and data disks on a server, but on a slightly larger scale.

This could possibly even be done as a very safe way of doing blue/green swarm updates. in a DR scenario, or if anything breaks (and IвЂ™ve broken it plenty in testing mainly by accidentally losing the raft quorum) then, itвЂ™s relatively easy to use version controlled templates and compose files to re-provision the entire stack and services in a new resource group, connect the services to the existing datastores, swap some DNS records, and delete the old resources. databases, redis cache, file storage etc) it makes the resource group disposable. This is because if all data is stored outside the вЂњdocker-for-azureвЂќ resource group (i.e. cloudstor I would like to be able to specify storage that is outside of the вЂњdocker-for-azureвЂќ resource group. This has gone somewhat off topic, but r.e. Luckily for us it was the вЂњgwbridgeвЂќ that conflicts. I couldnвЂ™t get the docker0 bridge to change, because I think that needs to be done by configuring DOCKER_OPTS before the docker engine itself starts up, and I couldnвЂ™t see anyway to hook into that. by being able to specify network ranges etc so they can be compatible with existing networks, or by being able to specify existing storage shares to the вЂњcloudstorвЂќ plugin. For our use-case which is trying to move existing legacy systems to a more modern platform, the current template would benefit from being more customisable. For greenfield deployments the current template is probably fine, but you would have to fit other non-docker systems around the docker configuration. IвЂ™m not sure what most peoples use-cases are for this project. I donвЂ™t know how it to change the docker0 bridge, this is created earlier in the init process. This seems to survive OK across rolling swarm updates as well, so I think we are going to go with this. So I tried adding 'docker network create -subnet 192.168.128.0/17 -opt .name=docker_gwbridge -opt .enable_icc=false docker_gwbridge' to the customData part of the template, and that has put the bridge onto the network specified. For the вЂњdocker_gwbridgeвЂќ (which for us happens to be the one that conflicts with our network) the docker docs say you can create the bridge in advance. IвЂ™ve actually just managed to half solve this, but it feels very hacky and brittle. This range conflicts with the range the вЂњdocker_gwbridgeвЂќ is on. This vnet has routing (actually itвЂ™s a VPN) to an onsite network that coincidentally is on 172.18.0.0/16. We need the Docker Swarm to connect to our existing systems, and so have modified the ARM template slightly to deploy into an existing VNET and subnet, rather than provisioning itвЂ™s own. Sorry with hindsight there wasnвЂ™t anywhere near enough detail in this.

Docker ip addresses