I totally agree with wanting to make things as simple as possible for people to get started - that’s exactly why I started investigating docker-for-azure in the first place. Having lots of stuff done automatically behind the scenes makes me slightly nervous when planning how to move into production though. If the automation fails for any reason, it’s hard to know where to start looking. For prod systems, the deployment is only the start, most of the work is in the ongoing maintenance and updating.
This especially applies to data storage, because we need to ensure it is backed up and replicated correctly. Having the data stored somewhere in one of the many storage accounts in the resource group (which all have pretty opaque names !) makes it harder to ensure that.
The code snippets you’ve supplied help a lot - if possible for a future release I’d suggest creating storage accounts with more descriptive names (e.g. the logging account at least has the word “logs” at the end), and trying to add a sanitised version of the volume to the share name. Azure naming restrictions are a real PITA though - why they are so restrictive is beyond me. At least allow hyphens…!
It’s a shame docker4x isn’t opensource, so we can’t dig through the code as a last resort. I guess Docker have their reasons for that, but it’s a shame as it makes it harder to work out what is going on automatically behind the scenes.