Machine: Azure driver - resource manager version

[lizrice]

I think I'm right in saying that the current support for docker-machine on Azure uses the Classic deployment model. It would be great to support the Resource Manager model too (since that's what MS is recommending for new deployments).

[jensbruggeman]

:+1:

[squillace]

+1

[ililic]

+1

[SorraTheOrc]

There are plans to move to move the docker-machine Azure provider to use Azure Resource Manager - see #496

[ahmetb]

@lizrice This is currently actively being worked on by myself. We're aware of the demand for this, therefore expect something soon. I will update this thread once we have something new.

[lizrice]

That's excellent news @ahmetalpbalkan :-)

[rafabene]

+1

[LoungeFlyZ]

This will be very helpful! Thanks for actively working on it.

[pcgeek86]

Definitely need this. Also need to get away from using certificates to authenticate, unless using an Azure Active Directory Service Principal. Any progress @ahmetalpbalkan?

Cheers,
Trevor Sullivan

[ahmetb]

@pcgeek86 we won't do the service principal crap. The authn process will look exactly like Azure cross-platform CLI authentication ("azure login" command). Every 2 weeks it'll prompt you to open a browser window and click a button to authorize the app.

[pcgeek86]

@ahmetalpbalkan Excellent, so you'll have --username parameter as well, like azure-clil?

[ahmetb]

@pcgeek86, no. Azure CLI doesn't require the username parameter. It's there for backwards compatibility.

[pcgeek86]

@ahmetalpbalkan I didn't say required. The --username parameter is what enables you to specify the Azure Active Directory (AAD) username. How is this "backwards compatibility?" What are you proposing for the final implementation?

The Azure Service Management (ASM) certificate-based authentication is the "backwards compatibility."

[ahmetb]

@pcgeek86 hmm, I never realized it is used for AAD usernames. When you go to https://aka.ms/devicelogin, does it let you specify your AAD username there? If the same task can be done without azure login (without --username) I intend to keep it that way.

[pcgeek86]

@ahmetalpbalkan You probably need to be in ARM mode (azure config arm) in order to use AAD authentication with ARM. I don't really use the ASM "mode" very often.

Yes, you can use AAD username with https://aka.ms/devicelogin. However, I prefer to avoid going out to a browser, and instead specify the username with --username. Works better in text-only scenarios. :)

If the same task can be done without azure login (without --username) I intend to keep it that way.

So, just to make sure I understand properly, are you intending to require the user to use a web browser to complete authentication, instead of typing their password at the command line?

[squillace]

With an account that requires 2fa, you're going to have to Auth any way. I'm not clear this is much of an optimization for the 2fa case.

[pcgeek86]

@squillace For multi-factor authentication users, sure. But why cater to only one group of users? My guess is that the majority will not be using MFA anyway.

At that point, it's just making it harder for everyone, and aren't you going to piss people off by forcing them to use a web browser to authenticate a command line tool?

In fact, why not take it a step further, and support MFA from the command line somehow?

[LoungeFlyZ]

You shouldn't collect usernames and passwords outside of the normal AAD login screen. It's insecure and bad practice. Plus there are technically too many scenarios to cover to make it actually work. 2FA isnt possible without opening a browser e.g. on prem ADFS, secure fob, smartcard auth etc...

[squillace]

I don't want to cater to only one group, but rather the basic scenario must cover all.

Sent from Outlook Mobilehttps://aka.ms/blhgte

On Thu, Feb 25, 2016 at 10:11 AM -0800, "Trevor Sullivan" <[email protected][e-mail]> wrote:

@squillacehttps://github.com/squillace For multi-factor authentication users, sure. But why cater to only one group of users? My guess is that the majority will not be using MFA anyway.

Reply to this email directly or view it on GitHubhttps://github.com/docker/machine/issues/2742#issuecomment-188910314.

[pcgeek86]

@LoungeFlyZ So are you saying the azure xPlat CLI should remove its --username parameter? That would be a significant, breaking change, but probably possible.

[LoungeFlyZ]

Probably yeah. I'm surprised they still have it ... but i understand why.

[pcgeek86]

@LoungeFlyZ What about command line users? Do you think this will be disruptive to them?

[LoungeFlyZ]

@pcgeek86 Yes of course. It's way less convenient I understand that. But having any tool collect your username and password is a disaster waiting to happen.

[pcgeek86]

@LoungeFlyZ I agree there, too. It seems that we're at a conflict point from a security and usability perspective. Thinking far outside the box, what would be an ideal solution for the security and usability problems we've mentioned above?

[ahmetb]

@pcgeek86 I'm sending your email a binary drop, please try it and lmk if you find it unpractical.

[squillace]

trying the darwin now.. clean. Nice.

[squillace]

Ahmet, very, very clean.

~/workspace/ahmet-machine ‹ruby-2.2.1› $ ld create -d azure \ 1 ↵
--azure-subscription-id \
--azure-ssh-user ops \
--azure-resource-group ahmetsmachine \
--azure-location eastus \
ahmetsmachine
Running pre-create checks...
(ahmetsmachine) Microsoft Azure: To sign in, use a web browser to open the page https://aka.ms/devicelogin. Enter the code to authenticate.
(ahmetsmachine) Completed machine pre-create checks.
Creating machine...
(ahmetsmachine) Querying existing resource group... name="ahmetsmachine"
(ahmetsmachine) Creating resource group... location="eastus" name="ahmetsmachine"
(ahmetsmachine) Creating availability set... name="docker-machine"
(ahmetsmachine) Creating network security group... name="ahmetsmachine-firewall" location="eastus"
(ahmetsmachine) Querying if virtual network already exists... name="docker-machine-vnet" location="eastus"
(ahmetsmachine) Creating subnet... cidr="" name="docker-machine" vnet="docker-machine-vnet"
(ahmetsmachine) Creating public IP address... name="ahmetsmachine-ip"
(ahmetsmachine) Creating network interface... name="ahmetsmachine-nic"
(ahmetsmachine) Creating storage account "" in eastus
(ahmetsmachine) Creating Virtual Machine... name="ahmetsmachine" location="eastus" size="Standard_A2" username="ops" osImage="canonical:UbuntuServer:14.04.3-LTS:latest"
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Detecting the provisioner...
Provisioning with ubuntu(upstart)...
Installing Docker...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Checking connection to Docker...
Docker is up and running!
To see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine-Darwin-x86_64 env ahmetsmachine

I'll try the Windows and Linux versions now. Nice. Info came right up. I also like very much your basic net environment and port choices. Thanks!

[ahmetb]

There's currently an issue on windows, it doesn't authenticate. I suggest trying with other platforms for now. Thanks @squillace!

[squillace]

OK, I'll do the debian family.

[pcgeek86]

Yep, the bug on Windows is related to the token being copied to a token cache. Sent the details to @ahmetalpbalkan earlier this evening.

Cheers,
Trevor Sullivan

[squillace]

works perfectly on mint 17.3.

[ahmetb]

@pcgeek86 please try this new build for windows: http://cl.ly/3k2d0g2B3j0o/docker_machine_azure_rc2.zip the issue should be fixed now. It just worked for me. (Although it is still flaky, we'll be fixing those in Azure SDK soon and import here. I will keep providing builds here as we go.)

Please try the authentication with all sorts of weird account types (Microsoft Account, AAD...) if you have them. This authentication approach just works with my multi-factor AD account as well as my personal account. I appreciate your feedback around it, I feel like we can get this right on the first try! :smile:

[squillace]

I didn't try it with personal; I'll do that now.

[buckett]

I did just try with the binary earlier in this issue on OS X and got:

docker-machine-azure create -d azure --azure-location "North Europe"  --azure-resource-group "career-planner" --azure-subscription-id {ID} azure
Running pre-create checks...
(azure) Microsoft Azure: To sign in, use a web browser to open the page https://aka.ms/devicelogin. Enter the code DRHSTFLSD to authenticate.
(azure) Completed machine pre-create checks.
Creating machine...
(azure) Querying existing resource group...  name="career-planner"
(azure) Resource group "career-planner" already exists.
(azure) Creating availability set...  name="docker-machine"
(azure) Creating network security group...  name="azure-firewall" location="North Europe"
(azure) Querying if virtual network already exists...  name="docker-machine-vnet" location="North Europe"
(azure) Creating subnet...  name="docker-machine" vnet="docker-machine-vnet" cidr="192.168.0.0/16"
(azure) Creating public IP address...  name="azure-ip"
(azure) Creating network interface...  name="azure-nic"
(azure) Creating storage account "vhdsxfxg6xxswwqjih00e7co" in North Europe
(azure) Creating Virtual Machine...  name="azure" location="North Europe" size="Standard_A2" username="ubuntu" osImage="canonical:UbuntuServer:14.04.3-LTS:latest"
Waiting for machine to be running, this may take a few minutes...
Error creating machine: Error waiting for machine to be running: Maximum number of retries (60) exceeded

although I think it did up creating all the resources.

[ahmetb]

@buckett Thanks this is about the one last issue we're trying to address in azure go sdk. We currently aren't waiting on created resources until their completion properly.

Before sending the pull request to this repo, I'm planning to create some 1,000 machines to see how reliable it is. We're already green on functional tests but there are some flakiness as I mentioned earlier.

[ahmetb]

@buckett here is a new release with a bunch of fixes. I currently started testing it and it pretty much seems alright (so far, all failures I got have been non-Azure related, apt repo flakines issues etc).

Here is the binary pack for supported platforms: link http://cl.ly/fKvS

I'm hoping to send a PR to machine with this version.

[buckett]

I downloaded the new build, and attempted to see what machines I had:

$ docker-machine-azure ls
(azure) Obtained access_token or refresh_token is stale. Please reauthenticate.
(azure) Microsoft Azure: To sign in, use a web browser to open the page https://aka.ms/devicelogin. Enter the code {removed} to authenticate.
NAME      ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER    ERRORS
azure              azure        Timeout                                                 
default   *        virtualbox   Running   tcp://192.168.99.101:2376           v1.10.0   

but then when I attempted to remove the stale azure instance I got asked to login again:

$ docker-machine-azure rm azure
About to remove azure
Are you sure? (y/n): y
(azure) NOTICE: Please check Azure portal/CLI to make sure you have no leftover resources to avoid unexpected charges.
(azure) Microsoft Azure: To sign in, use a web browser to open the page https://aka.ms/devicelogin. Enter the code {removed} to authenticate.
(azure) Virtual Machine does not exist. Skipping.  name="azure"
(azure) Network Interface does not exist. Skipping.  name="azure-nic"
(azure) Public IP does not exist. Skipping.  name="azure-ip"
(azure) Network Security Group does not exist. Skipping.  name="azure-firewall"
(azure) Attempting to clean up Availability Set resource...  name="docker-machine"
(azure) Attempting to clean up Subnet resource...  name="docker-machine"
(azure) Attempting to clean up Virtual Network resource...  name="docker-machine-vnet"
Successfully removed azure

When I then created a new azure instance it work up to a point and then fell over:

$ docker-machine-azure create -d azure ....
[..snipped..]
Error creating machine: Error in driver during machine creation: Panic in the driver: runtime error: invalid memory address or nil pointer dereference
goroutine 52 [running]:
runtime/debug.Stack(0x0, 0x0, 0x0)
    /usr/local/Cellar/go/1.6/libexec/src/runtime/debug/stack.go:24 +0x80
github.com/docker/machine/libmachine/drivers/rpc.(*StandardStack).Stack(0x2299078, 0x0, 0x0, 0x0)
    /Users/alp/workspace/gopath-machine/src/github.com/docker/machine/libmachine/drivers/rpc/server_driver.go:23 +0x29
github.com/docker/machine/libmachine/drivers/rpc.trapPanic(0xc82012ba28)
    /Users/alp/workspace/gopath-machine/src/github.com/docker/machine/libmachine/drivers/rpc/server_driver.go:129 +0x96
panic(0x11f78e0, 0xc82000a0f0)
    /usr/local/Cellar/go/1.6/libexec/src/runtime/panic.go:426 +0x4e9
github.com/docker/machine/drivers/azure/azureutil.osDiskStorageContainerURL(0xc820328780, 0xc8202c4468, 0x5, 0x0, 0x0)
    /Users/alp/workspace/gopath-machine/src/github.com/docker/machine/drivers/azure/azureutil/azureutil.go:709 +0x3d
github.com/docker/machine/drivers/azure/azureutil.osDiskStorageBlobURL(0xc820328780, 0xc8202c4468, 0x5, 0x0, 0x0)
    /Users/alp/workspace/gopath-machine/src/github.com/docker/machine/drivers/azure/azureutil/azureutil.go:697 +0x5c
github.com/docker/machine/drivers/azure/azureutil.AzureClient.CreateVirtualMachine(0x16c0590, 0x10, 0x17fb460, 0x20, 0x18ea160, 0x35, 0x17fb4e0, 0x24, 0x17627a0, 0x1d, ...)
    /Users/alp/workspace/gopath-machine/src/github.com/docker/machine/drivers/azure/azureutil/azureutil.go:446 +0x5f2
github.com/docker/machine/drivers/azure.(*Driver).Create.func10(0x0, 0x0)
    /Users/alp/workspace/gopath-machine/src/github.com/docker/machine/drivers/azure/azure.go:322 +0x20f
github.com/docker/machine/drivers/azure.(*Driver).Create(0xc8200c2a00, 0x0, 0x0)
    /Users/alp/workspace/gopath-machine/src/github.com/docker/machine/drivers/azure/azure.go:326 +0x461
github.com/docker/machine/libmachine/drivers/rpc.(*RPCServerDriver).Create(0xc82012d5a0, 0x2299078, 0x2299078, 0x0, 0x0)
    /Users/alp/workspace/gopath-machine/src/github.com/docker/machine/libmachine/drivers/rpc/server_driver.go:140 +0x7c
reflect.Value.call(0x108e980, 0x1518768, 0x13, 0x155ba18, 0x4, 0xc82012bed8, 0x3, 0x3, 0x0, 0x0, ...)
    /usr/local/Cellar/go/1.6/libexec/src/reflect/value.go:435 +0x120d
reflect.Value.Call(0x108e980, 0x1518768, 0x13, 0xc82012bed8, 0x3, 0x3, 0x0, 0x0, 0x0)
    /usr/local/Cellar/go/1.6/libexec/src/reflect/value.go:303 +0xb1
net/rpc.(*service).call(0xc82016a1c0, 0xc82012e000, 0xc820158fd0, 0xc820087880, 0xc82012dcc0, 0xd7d040, 0x2299078, 0x16, 0xd7d040, 0x2299078, ...)
    /usr/local/Cellar/go/1.6/libexec/src/net/rpc/server.go:383 +0x1c2
created by net/rpc.(*Server).ServeCodec
    /usr/local/Cellar/go/1.6/libexec/src/net/rpc/server.go:477 +0x49d

[buckett]

Removing the half setup docker-machine almost all worked. Everything got removed apart from the virtual network and the storage account (by checking in https://portal.azure.com).

[ahmetb]

@buckett argh, can't believe I sent out the link for an older build. Sorry about that. Could you please try this one: http://cl.ly/fKvS

[ahmetb]

@buckett virtual machine should be getting removed (if you could repro on a clean resource group with docker-machine --debug rm that would be great) but storage account won’t get removed. It is free of charge and we clean up OS disks we allocate upon removal as well.

[buckett]

Trying with new build: was just deleting a machine and half way through I got:

Error removing host "azure": azure.ServicePrincipalToken:WithAuthorization 0 Failed to refresh Service Principal Token for request to https://management.azure.com/subscriptions/fb56de48-cb6e-4d0b-8626-8faa062ada02/providers/Microsoft.Network/locations/northeurope/operations/33643d7c-82cc-40f4-8724-bd82de215338?api-version=2015-06-15 -- Original Error: Manually created ServicePrincipalToken does not contain secret material to retrieve a new access token.

[buckett]

The new build's timeout on docker-machine ls for pasting in the authentication token is a little too short as I can't manage to open a browser, copy and paste the auth token in and click to accept it, signin to the correct account and accept the permissions.

[buckett]

And when my laptop isn't suspending halfway through machine creation it created a new host running docker (magic, thanks, :cake:). I did get an error on creation but I was able to run hello-world after creation

Checking connection to Docker...
Error creating machine: Error checking the host: Error checking and/or regenerating the certs: There was an error validating certificates for host "13.69.192.88:2376": tls: DialWithDialer timed out
You can attempt to regenerate them using 'docker-machine regenerate-certs [name]'.
Be advised that this will trigger a Docker daemon restart which will stop running containers.

$ eval $(docker-machine-azure env azure)
$ docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
03f4658f8b78: Pull complete 
a3ed95caeb02: Pull complete 
Digest: sha256:8be990ef2aeb16dbcb9271ddfe2610fa6658d13f6dfb8bc72074cc1ca36966a7
Status: Downloaded newer image for hello-world:latest

Hello from Docker.
This message shows that your installation appears to be working correctly.

After successfully running the hello-world container I did also regenerate the certificates and that worked fine.

[buckett]

In a clean resource group removing the last machine running docker doesn't appear to cleanup the network (although it looks to try):

(azure) Attempting to clean up Virtual Network resource...  name="docker-machine-vnet"
(azure) DBG | Azure request  method="GET" request="https://management.azure.com/subscriptions/fb56de48-cb6e-4d0b-8626-8faa062ada02/resourceGroups/test/providers/Microsoft.Network/virtualnetworks/docker-machine-vnet?api-version=2015-06-15"
(azure) DBG | Azure response  status="200 OK" method="GET" request="https://management.azure.com/subscriptions/fb56de48-cb6e-4d0b-8626-8faa062ada02/resourceGroups/test/providers/Microsoft.Network/virtualnetworks/docker-machine-vnet?api-version=2015-06-15" x-ms-request-id="626af1d8-3f4b-4915-9a8a-f7a0d4844c53"
(azure) DBG | Azure response  request="https://management.azure.com/subscriptions/fb56de48-cb6e-4d0b-8626-8faa062ada02/resourceGroups/test/providers/Microsoft.Network/virtualnetworks/docker-machine-vnet?api-version=2015-06-15" x-ms-request-id="626af1d8-3f4b-4915-9a8a-f7a0d4844c53" status="200 OK" method="GET"
(azure) DBG | Virtual Network does not have any attached dependent resource.  name="docker-machine-vnet"
(azure) Removing Virtual Network resource...  name="docker-machine-vnet"
(azure) DBG | Azure request  method="DELETE" request="https://management.azure.com/subscriptions/fb56de48-cb6e-4d0b-8626-8faa062ada02/resourceGroups/test/providers/Microsoft.Compute/virtualMachines/docker-machine-vnet?api-version=2015-06-15"
(azure) DBG | Azure response  status="204 No Content" method="DELETE" request="https://management.azure.com/subscriptions/fb56de48-cb6e-4d0b-8626-8faa062ada02/resourceGroups/test/providers/Microsoft.Compute/virtualMachines/docker-machine-vnet?api-version=2015-06-15" x-ms-request-id="8799a451-211e-4f7d-a9d7-52b2e702c5f5"
(azure) DBG | Azure response  status="204 No Content" method="DELETE" request="https://management.azure.com/subscriptions/fb56de48-cb6e-4d0b-8626-8faa062ada02/resourceGroups/test/providers/Microsoft.Compute/virtualMachines/docker-machine-vnet?api-version=2015-06-15" x-ms-request-id="8799a451-211e-4f7d-a9d7-52b2e702c5f5"

[pcgeek86]

Everything started off well on Mac OS X. Then, this happened:

(azdh) Creating Virtual Machine...  name="azdh" location="westeurope" size="Standard_A2" username="ubuntu" osImage="canonical:UbuntuServer:14.04.3-LTS:latest"
Error creating machine: Error in driver during machine creation: Panic in the driver: runtime error: invalid memory address or nil pointer dereference
goroutine 90 [running]:

Here is the complete log:

Trevors-MBP:bin trevorsullivan$ ./docker-machine-Darwin-x86_64 create --driver azure --azure-location westeurope --azure-subscription-id 1c9fd9f5-a2dc-4cc9-a73c-cab0ee4a95a1 --azure-resource-group CloudAcademyAutomation azdh
Running pre-create checks...
(azdh) Microsoft Azure: To sign in, use a web browser to open the page https://aka.ms/devicelogin. Enter the code EDPKYDZ2X to authenticate.
(azdh) Completed machine pre-create checks.
Creating machine...
(azdh) Querying existing resource group...  name="CloudAcademyAutomation"
(azdh) Resource group "CloudAcademyAutomation" already exists.
(azdh) Creating availability set...  name="docker-machine"
(azdh) Creating network security group...  name="azdh-firewall" location="westeurope"
(azdh) Querying if virtual network already exists...  location="westeurope" name="docker-machine-vnet"
(azdh) Creating subnet...  name="docker-machine" vnet="docker-machine-vnet" cidr="192.168.0.0/16"
(azdh) Creating public IP address...  name="azdh-ip"
(azdh) Creating network interface...  name="azdh-nic"
(azdh) Creating storage account "vhdsxej59xu1xauhx7kaqs2e" in westeurope
(azdh) Creating Virtual Machine...  name="azdh" location="westeurope" size="Standard_A2" username="ubuntu" osImage="canonical:UbuntuServer:14.04.3-LTS:latest"
Error creating machine: Error in driver during machine creation: Panic in the driver: runtime error: invalid memory address or nil pointer dereference
goroutine 90 [running]:
runtime/debug.Stack(0x0, 0x0, 0x0)
    /usr/local/Cellar/go/1.6/libexec/src/runtime/debug/stack.go:24 +0x80
github.com/docker/machine/libmachine/drivers/rpc.(*StandardStack).Stack(0x2299078, 0x0, 0x0, 0x0)
    /Users/alp/workspace/gopath-machine/src/github.com/docker/machine/libmachine/drivers/rpc/server_driver.go:23 +0x29
github.com/docker/machine/libmachine/drivers/rpc.trapPanic(0xc8204a3a38)
    /Users/alp/workspace/gopath-machine/src/github.com/docker/machine/libmachine/drivers/rpc/server_driver.go:129 +0x96
panic(0x11f78e0, 0xc82000a0b0)
    /usr/local/Cellar/go/1.6/libexec/src/runtime/panic.go:426 +0x4e9
github.com/docker/machine/drivers/azure/azureutil.osDiskStorageContainerURL(0xc82025db80, 0xc8204d0118, 0x4, 0x0, 0x0)
    /Users/alp/workspace/gopath-machine/src/github.com/docker/machine/drivers/azure/azureutil/azureutil.go:709 +0x3d
github.com/docker/machine/drivers/azure/azureutil.osDiskStorageBlobURL(0xc82025db80, 0xc8204d0118, 0x4, 0x0, 0x0)
    /Users/alp/workspace/gopath-machine/src/github.com/docker/machine/drivers/azure/azureutil/azureutil.go:697 +0x5c
github.com/docker/machine/drivers/azure/azureutil.AzureClient.CreateVirtualMachine(0x16c0590, 0x10, 0x17fb460, 0x20, 0x18ea160, 0x35, 0x17fb4e0, 0x24, 0x17627a0, 0x1d, ...)
    /Users/alp/workspace/gopath-machine/src/github.com/docker/machine/drivers/azure/azureutil/azureutil.go:446 +0x5f2
github.com/docker/machine/drivers/azure.(*Driver).Create.func10(0x0, 0x0)
    /Users/alp/workspace/gopath-machine/src/github.com/docker/machine/drivers/azure/azure.go:322 +0x20f
github.com/docker/machine/drivers/azure.(*Driver).Create(0xc8200d0a00, 0x0, 0x0)
    /Users/alp/workspace/gopath-machine/src/github.com/docker/machine/drivers/azure/azure.go:326 +0x461
github.com/docker/machine/libmachine/drivers/rpc.(*RPCServerDriver).Create(0xc82012eec0, 0x2299078, 0x2299078, 0x0, 0x0)
    /Users/alp/workspace/gopath-machine/src/github.com/docker/machine/libmachine/drivers/rpc/server_driver.go:140 +0x7c
reflect.Value.call(0x108e980, 0x1518768, 0x13, 0x155ba18, 0x4, 0xc8204a3ee8, 0x3, 0x3, 0x0, 0x0, ...)
    /usr/local/Cellar/go/1.6/libexec/src/reflect/value.go:435 +0x120d
reflect.Value.Call(0x108e980, 0x1518768, 0x13, 0xc8204a3ee8, 0x3, 0x3, 0x0, 0x0, 0x0)
    /usr/local/Cellar/go/1.6/libexec/src/reflect/value.go:303 +0xb1
net/rpc.(*service).call(0xc82012d5c0, 0xc820013e00, 0xc820212070, 0xc820091880, 0xc82020e6a0, 0xd7d040, 0x2299078, 0x16, 0xd7d040, 0x2299078, ...)
    /usr/local/Cellar/go/1.6/libexec/src/net/rpc/server.go:383 +0x1c2
created by net/rpc.(*Server).ServeCodec
    /usr/local/Cellar/go/1.6/libexec/src/net/rpc/server.go:477 +0x49d

Cheers,
Trevor Sullivan

[ahmetb]

@pcgeek86 seems like you're using rc3 binaries I sent out earlier? Can you please try rc4?

[pcgeek86]

@ahmetalpbalkan Worked this time, to create the Docker Host in Azure. I'll try to deploy an image to it.

[ahmetb]

@buckett you're right, the authorization in ls command is going to be a problem as it times out while we prompt for authorization. I currently have no solution for that, but I think this won't be a big deal often, it works in create/rm. I'll debug the virtual network issue. Thanks for reporting.

@pcgeek86 thanks for trying.

[squillace]

@buckett it would be interesting to see whether there's any difference between the timeout period with this docker-machine as opposed to the Azure CLI. I'll see about that tomorrow.

[ahmetb]

@squillace these two are unrelated. In the ls command machine expects driver to respond within 10 seconds or so, if you can't authenticate within short period of time it'll timeout.

[squillace]

Ah, nice. That's pretty short if you hit the auth moment.

[ahmetb]

@buckett from your output I realized we were attempting to delete the VM instead of VNet while cleaning up VNet :) I fixed it now. Newer builds won't have this problem. Thanks for noticing and reporting!

[buckett]

docker-machine ssh {machine} seems to have a nice long timeout, so if the auth token expires I've just been renewing it by just making a ssh connection and then I have it to use for a few hours.

[pcgeek86]

@ahmetalpbalkan When you deallocate (shutdown) an Azure VM, the new docker-machine command complains.

Trevors-MBP:bin 3 trevorsullivan$ ./docker-mac ls
(azdh) PowerState "deallocated" does not map to a docker-machine state.
(azdh) PowerState "deallocated" does not map to a docker-machine state.
NAME         ACTIVE   DRIVER         STATE     URL                         SWARM   DOCKER    ERRORS
azdh         -        azure                                                        Unknown
dh           -        vmwarefusion   Running   tcp://172.16.217.129:2376           v1.10.2
dockerhost   -        virtualbox     Stopped                                       Unknown

[ahmetb]

@pcgeek86 nice catch. Let me make it look like it is stopped.

[ahmetb]

@buckett that's a nice trick. By the way your credentials shouldn't be expiring (asks you to open browser) earlier than 2 weeks (unless you delete $HOME/.docker/machine). Is that something that doesn't sound like your experience?

[ahmetb]

Here is a new version, should be fixing PowerState issue and Virtual Network cleanup issue: http://cl.ly/fLkb

[pcgeek86]

@ahmetalpbalkan Thanks, that works better. However, another bug is that when the public IP address changes, after a reboot, then an exception is thrown from invalid credentials.

Trevors-MBP:bin 4 trevorsullivan$ ./docker-machine-Darwin-x86_64 ls
NAME         ACTIVE   DRIVER         STATE     URL                         SWARM   DOCKER    ERRORS
azdh         -        azure          Running   tcp://40.118.175.219:2376           Unknown   Unable to query docker version: Get https://40.118.175.219:2376/v1.15/version: x509: certificate is valid for 104.42.125.236, not 40.118.175.219
dh           -        vmwarefusion   Running   tcp://172.16.217.129:2376           v1.10.2
dockerhost   -        virtualbox     Stopped                                       Unknown

[ahmetb]

@pcgeek86 I see that this is the same machine you deallocated from Azure portal. docker-machine normally does not deallocate, it only stops your VM and when you deallocate, you get a new IP address.

I guess the questions here are:

1. should azure driver allocate a static IP for machines –something that costs more to the user? (perhaps can be an argument)
2. should this scenario where user manages/intervenes the VM outside docker-machine be supported?

[pcgeek86]

@ahmetalpbalkan Yes, that is the same machine. I used the azure xplat CLI to deallocate the VM, and then start it back up a few hours later.

In my opinion:

1. Docker is useful only when managed with a static IP. Therefore, this should be a requirement for Docker Hosts on Azure.
2. No, but static IP is still going to be a requirement.

[ahmetb]

@pcgeek86 you might be right. My assumption was docker-machine would use docker-machine ip <vm> command to fetch the IP every time it connects the machine, but apparently it relies on static IP to generate certs (you can mitigate this by using docker-machine regenerate-certs).

Maintainers: do you think machine drivers should allocate static external IPs by default (even if they are not free of charge)?

[ahmetb]

@pcgeek86 I just observed the same behavior in Google driver. It uses ephemeral public IP addresses by default and I get the same TLS certificate error when I restart the Google VM from portal. I guess you're not supposed to do this. :P

But I'm hoping to add --azure-static-public-ip boolean flag in the future but it will not be the default behavior as Static IP allocation has implicit cost to the user.

[squillace]

@ahmetalpbalkan does regenerate-certs work in that case? All three of my VMs worked, but then I tore them down. No problems, but if regenerate-certs works....

[ahmetb]

@squillace yes, that's what it is designed for, in case you lose the certs, you can regenerate them over SSH.

[squillace]

@ahmetalpbalkan that seems like the solution that docker has already implemented. I ran into this in the ASM dm, and regerating worked fine. for Production, you'd go to static.

[pcgeek86]

@squillace @ahmetalpbalkan Excellent, good to know that docker regenerate-certs will work. Would static IP necessarily be required in production though? What if you're using the DNS name instead? Is that an option for Docker? That might actually help work around the cert issue.

[buckett]

@ahmetalpbalkan My credentials seem to be lasting a few hours. Not a day has gone by without having to login again. I'm not clearing out anything in my home directory.

[ahmetb]

@buckett That certainly sounds like a bug that we have not been able to reproduce. Could you please run docker-machine --debug ssh <vm> (replace ssh with ip/status as you wish) and send the debug output to me (ahmetb at microsoft com) (or paste it to a gist) when you are prompted for authentication next time?

edit: following up with him offline over email.