Machine: Driver do Azure - versão do gerenciador de recursos

: +1:

+1

+1

Existem planos para mover para mover o provedor do Azure da máquina docker para usar o Azure Resource Manager - consulte # 496

@lizrice Isso está sendo trabalhado ativamente por mim. Estamos cientes da demanda por isso, portanto esperamos algo em breve. Vou atualizar este tópico assim que tivermos algo novo.

Essa é uma excelente notícia @ahmetalpbalkan :-)

+1

Isto será muito útil! Obrigado por trabalhar ativamente nisso.

Definitivamente preciso disso. Também precisa evitar o uso de certificados para autenticação, a menos que use uma entidade de serviço do Azure Active Directory Algum progresso @ahmetalpbalkan?

Felicidades,
Trevor Sullivan

@ pcgeek86 não faremos a porcaria do principal de serviço. O processo authn será semelhante à autenticação CLI de plataforma cruzada do Azure (comando "azure login" ). A cada 2 semanas, ele solicitará que você abra uma janela do navegador e clique em um botão para autorizar o aplicativo.

@ahmetalpbalkan Excelente, então você terá o parâmetro --username também, como azure-clil?

@ pcgeek86 , no. A CLI do Azure não requer o parâmetro de nome de usuário. Ele existe para compatibilidade com versões anteriores.

@ahmetalpbalkan Eu não disse obrigatório. O parâmetro --username é o que permite especificar o nome de usuário do Azure Active Directory (AAD). Como isso é "compatibilidade com versões anteriores?" O que você está propondo para a implementação final?

A autenticação baseada em certificado do Azure Service Management (ASM) é a "compatibilidade com versões anteriores".

@ pcgeek86 hmm, nunca percebi que é usado para nomes de usuário AAD. Quando você acessa https://aka.ms/devicelogin , ele permite que você especifique seu nome de usuário AAD lá? Se a mesma tarefa pode ser feita sem azure login (sem --username ), pretendo mantê-la assim.

@ahmetalpbalkan Você provavelmente precisa estar no modo ARM ( azure config arm ) para usar a autenticação AAD com ARM. Eu realmente não uso o "modo" ASM com muita freqüência.

Sim, você pode usar o nome de usuário AAD com https://aka.ms/devicelogin. No entanto, prefiro evitar usar um navegador e, em vez disso, especificar o nome de usuário com --username . Funciona melhor em cenários somente texto. :)

Se a mesma tarefa puder ser realizada sem o login do azure (sem --username), pretendo mantê-la assim.

Então, apenas para ter certeza de que entendi bem, você pretende exigir que o usuário use um navegador da web para concluir a autenticação, em vez de digitar sua senha na linha de comando?

Com uma conta que requer 2fa, você terá que Auth de qualquer maneira. Não estou certo de que se trata de uma otimização para o caso 2fa.

@squillace Para usuários de autenticação multifator, com certeza. Mas por que atender a apenas um grupo de usuários? Meu palpite é que a maioria não usará o MFA de qualquer maneira.

Nesse ponto, está apenas tornando as coisas mais difíceis para todos, e você não vai irritar as pessoas ao forçá-las a usar um navegador da Web para autenticar uma ferramenta de linha de comando?

Na verdade, por que não dar um passo adiante e oferecer suporte a MFA a partir da linha de comando de alguma forma?

Você não deve coletar nomes de usuário e senhas fora da tela de login normal do AAD. É uma prática insegura e ruim. Além disso, existem tecnicamente muitos cenários para cobrir para que ele realmente funcione. 2FA não é possível sem abrir um navegador, por exemplo, no ADFS local, fob seguro, autenticação de smartcard etc ...

Não quero atender a apenas um grupo, mas sim o cenário básico deve abranger todos.

Enviado do Outlook Mo bilehttps: //aka.ms/blhgte

Na quinta-feira, 25 de fevereiro de 2016 às 10:11 AM-0800, "Trevor Sullivan" < [email protected] [email protected] > escreveu:

@squil lacehttps: //github.com/squillace Para usuários de autenticação multifator, com certeza. Mas por que atender a apenas um grupo de usuários? Meu palpite é que a maioria não usará o MFA de qualquer maneira.

Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/docker/machine/issues/2742#issuecomment -188910314.

@LoungeFlyZ Então você está dizendo que a CLI azure xPlat deve remover seu parâmetro --username ? Isso seria uma mudança significativa e significativa, mas provavelmente possível.

Provavelmente sim. Estou surpreso que ainda o tenham ... mas entendo o porquê.

@LoungeFlyZ E quanto aos usuários de linha de comando? Você acha que isso será perturbador para eles?

@ pcgeek86 Sim, claro. É bem menos conveniente, eu entendo isso. Mas ter qualquer ferramenta para coletar seu nome de usuário e senha é um desastre esperando para acontecer.

@LoungeFlyZ Eu também concordo. Parece que estamos em um ponto de conflito de uma perspectiva de segurança e usabilidade. Pensando muito além da caixa, qual seria a solução ideal para os problemas de segurança e usabilidade que mencionamos acima?

@ pcgeek86 Estou enviando para o seu e-mail um

Olá pessoal, estamos finalmente perto de ter um driver do Azure totalmente novo. Estamos aprimorando algumas coisas e enviarei uma solicitação de pull em breve. Enquanto isso, você pode experimentar a nova versão antes que ela seja lançada e dar feedback. Faça o download abaixo:

• Código fonte
• Documentação do driver do Azure
• Baixe como binário: http://cl.ly/3k2d0g2B3j0o http://cl.ly/2X1j2s2C3Z1j~~

tentando o darwin agora .. limpo. Agradável.

Ahmet, muito, muito limpo.

~ / 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
Executando verificações de pré-criação ...
(ahmetsmachine) Microsoft Azure: para entrar, use um navegador da web para abrir a página https://aka.ms/devicelogin. Digite o códigopara autenticar.
(ahmetsmachine) Verificações de pré-criação da máquina concluídas.
Criando máquina ...
(ahmetsmachine) Consultando grupo de recursos existente ... name = "ahmetsmachine"
(ahmetsmachine) Criando grupo de recursos ... location = "eastus" name = "ahmetsmachine"
(ahmetsmachine) Criando conjunto de disponibilidade ... name = "docker-machine"
(ahmetsmachine) Criando grupo de segurança de rede ... name = "ahmetsmachine-firewall" location = "eastus"
(ahmetsmachine) Consultando se a rede virtual já existe ... name = "docker-machine-vnet" location = "eastus"
(ahmetsmachine) Criando sub-rede ... cidr = "" name = "docker-machine" vnet = "docker-machine-vnet"
(ahmetsmachine) Criando endereço IP público ... name = "ahmetsmachine-ip"
(ahmetsmachine) Criando interface de rede ... name = "ahmetsmachine-nic"
(ahmetsmachine) Criando conta de armazenamento "" em eastus
(ahmetsmachine) Criando máquina virtual ... name = "ahmetsmachine" location = "eastus" size = "Standard_A2" username = "ops" osImage = " canônico: UbuntuServer : 14.04.3- LTS: mais recente "
Esperando que a máquina esteja funcionando, isso pode levar alguns minutos ...
Detectando o sistema operacional da instância criada ...
Aguardando SSH estar disponível ...
Detectando o provisionador ...
Provisionando com ubuntu (upstart) ...
Instalando Docker ...
Copiando certificados para o diretório da máquina local ...
Copiando certificados para a máquina remota ...
Definindo a configuração do Docker no daemon remoto ...
Verificando a conexão com o Docker ...
O Docker está instalado e funcionando!
Para ver como conectar seu Docker Client ao Docker Engine em execução nesta máquina virtual, execute:docker-machine-Darwin-x86_64 env ahmetsmachine

Vou tentar as versões para Windows e Linux agora. Agradável. As informações surgiram imediatamente. Também gosto muito do seu ambiente de rede básico e das opções de porta. Obrigado!

Atualmente há um problema no Windows, ele não autentica. Eu sugiro tentar com outras plataformas por enquanto. Obrigado @squillace!

OK, vou fazer a família debian.

Sim, o bug no Windows está relacionado ao token sendo copiado para um cache de token. Enviou os detalhes para @ahmetalpbalkan no início desta noite.

Felicidades,
Trevor Sullivan

funciona perfeitamente no mint 17.3.

@ pcgeek86 tente esta nova compilação para Windows: http://cl.ly/3k2d0g2B3j0o/docker_machine_azure_rc2.zip o problema deve ser corrigido agora. Simplesmente funcionou para mim. (Embora ainda seja instável, iremos consertá-los no SDK do Azure em breve e importar aqui. Continuarei fornecendo compilações aqui conforme avançamos.)

Por favor, tente a autenticação com todos os tipos de contas estranhas (Microsoft Account, AAD ...) se você as tiver. Essa abordagem de autenticação funciona apenas com minha conta do AD multifatorial, bem como minha conta pessoal. Agradeço seus comentários sobre isso, acho que podemos acertar na primeira tentativa! :sorriso:

Eu não tentei com o pessoal; Eu vou fazer isso agora.

Eu tentei com o binário anteriormente nesta edição no OS X e obtive:

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

embora eu ache que criou todos os recursos.

@buckett Obrigado, isso é sobre o último problema que estamos tentando resolver no azure go sdk. No momento, não estamos esperando os recursos criados até que sejam concluídos adequadamente.

Antes de enviar a solicitação pull para este repo, estou planejando criar cerca de 1.000 máquinas para ver o quão confiável é. Já estamos verdes em testes funcionais, mas há alguns instantes, como mencionei anteriormente.

@buckett aqui é um novo lançamento com um monte de correções. Atualmente, comecei a testá-lo e parece que está tudo bem (até agora, todas as falhas que recebi não eram relacionadas ao Azure, problemas de apt repo flakines etc).

Aqui está o pacote binário para plataformas suportadas: link http://cl.ly/fKvS

Espero enviar um PR para a máquina com esta versão.

Eu baixei a nova compilação e tentei ver quais máquinas eu tinha:

$ 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   

mas, quando tentei remover a instância obsoleta do azure, fui solicitado a fazer login novamente:

$ 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

Quando eu criei uma nova instância do azure, ela funcionou até certo ponto e depois caiu:

$ 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

Quase toda a remoção da docker-machine da meia configuração funcionou. Tudo foi removido, exceto a rede virtual e a conta de armazenamento (verificando em https://portal.azure.com).

@buckett argh, não acredito que enviei o link de uma compilação mais antiga. Me desculpe por isso. Você poderia tentar este: http://cl.ly/fKvS

A máquina virtual docker-machine --debug rm isso seria ótimo), mas a conta de armazenamento não será removida. É gratuito e também limpamos os discos do sistema operacional que alocamos na remoção.

Tentando com a nova construção: estava apenas excluindo uma máquina e no meio do caminho eu obtive:

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.

O tempo limite da nova construção em docker-machine ls para colar o token de autenticação é um pouco curto, pois não consigo abrir um navegador, copie e cole o token de autenticação e clique para aceitá-lo, fazendo login no endereço correto conta e aceite as permissões.

E quando meu laptop não estava suspendendo no meio da criação da máquina, ele criou um novo host executando o docker (mágica, obrigado,: cake :). Recebi um erro na criação, mas consegui executar o hello-world após a criação

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.

Depois de executar com êxito o contêiner hello-world, também gerei novamente os certificados e funcionou bem.

Em um grupo de recursos limpo, a remoção da última máquina em execução no docker não parece limpar a rede (embora pareça tentar):

(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"

Tudo começou bem no Mac OS X. Então, aconteceu o seguinte:

(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]:

Aqui está o registro completo:

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

Felicidades,
Trevor Sullivan

@ pcgeek86 parece que você está usando binários rc3 que enviei antes? Você pode tentar rc4?

@ahmetalpbalkan Desta vez,

@buckett você está certo, a autorização no comando ls vai ser um problema, pois o tempo limite se esgota enquanto solicitamos a autorização. No momento, não tenho solução para isso, mas acho que isso não será um grande negócio com frequência, funciona em create / rm . Vou depurar o problema da rede virtual. Obrigado por relatar.

@ pcgeek86 obrigado por tentar.

@buckett seria interessante ver se há alguma diferença entre o período de tempo limite com esta docker-machine em oposição à CLI do Azure. Vou ver isso amanhã.

@squillace, esses dois não estão relacionados. No comando ls máquina de comando espera que o driver responda dentro de 10 segundos ou mais, se você não puder autenticar em um curto período de tempo, o tempo limite será atingido.

Ah legal. Isso é muito curto se você atingir o momento de autenticação.

@buckett pela sua saída, percebi que estávamos tentando excluir a VM em vez da VNet enquanto limpávamos a VNet :) Corrigi isso agora. As compilações mais recentes não terão esse problema. Obrigado por notar e relatar!

docker-machine ssh {machine} parece ter um bom tempo limite longo, então, se o token de autenticação expirar, acabei de renová-lo apenas fazendo uma conexão ssh e terei de usá-lo por algumas horas.

@ahmetalpbalkan Quando você desaloca ( docker-machine reclama.

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

@ pcgeek86 boa captura. Deixe-me fazer parecer que está parado.

@buckett é um bom truque. A propósito, suas credenciais não devem expirar (pede para você abrir o navegador) antes de 2 semanas (a menos que você exclua $ HOME / .docker / machine). Isso é algo que não se parece com a sua experiência?

Aqui está uma nova versão, deve corrigir o problema do PowerState e o problema de limpeza da rede virtual: http://cl.ly/fLkb

@ahmetalpbalkan Obrigado, isso funciona melhor. No entanto, outro bug é que, quando o endereço IP público muda, após uma reinicialização, uma exceção é lançada a partir de credenciais inválidas.

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

@ pcgeek86 Vejo que esta é a mesma máquina que você desalocou do portal do Azure. docker-machine normalmente não desaloca, ele apenas para sua VM e quando você desaloca, você obtém um novo endereço IP.

Acho que as perguntas aqui são:

1. o driver azure deve alocar um IP estático para as máquinas - algo que custa mais para o usuário? (talvez possa ser um argumento)
2. deve este cenário onde o usuário gerencia / intervém a VM fora da docker-machine ser suportado?

@ahmetalpbalkan Sim, é a mesma máquina. Usei a CLI azure xplat para desalocar a VM e reiniciei algumas horas depois.

Na minha opinião:

1. O Docker é útil apenas quando gerenciado com um IP estático. Portanto, isso deve ser um requisito para hosts Docker no Azure.
2. Não, mas o IP estático ainda será um requisito.

@ pcgeek86 você pode estar certo. Minha suposição era que docker-machine usaria o comando docker-machine ip <vm> para buscar o IP toda vez que conectasse a máquina, mas aparentemente ele depende de IP estático para gerar certificados (você pode atenuar isso usando docker-machine regenerate-certs ) .

Mantenedores: você acha que os drivers da máquina devem alocar IPs externos estáticos por padrão (mesmo que não sejam gratuitos)?

@ pcgeek86 Acabei de observar o mesmo comportamento no driver do Google. Ele usa endereços IP públicos efêmeros por padrão e recebo o mesmo erro de certificado TLS quando reinicio o Google VM no portal. Eu acho que você não deveria fazer isso. : P

Mas espero adicionar o sinalizador booleano --azure-static-public-ip no futuro, mas não será o comportamento padrão, pois a alocação de IP estático tem custo implícito para o usuário.

@ahmetalpbalkan o regenerate-certs funciona nesse caso? Todas as minhas três VMs funcionaram, mas então eu as destruí. Sem problemas, mas se regenerar-certs funcionar ....

@squillace sim, é para isso que ele foi projetado, caso você perca os certificados, você pode regenerá-los via SSH.

@ahmetalpbalkan que parece ser a solução que o docker já implementou. Corri para isso no ASM dm, e regerar funcionou bem. para Produção, você iria para estático.

@squillace @ahmetalpbalkan Excelente, é bom saber que docker regenerate-certs funcionará. O IP estático seria necessariamente necessário na produção? E se você estiver usando o nome DNS em vez disso? Isso é uma opção para o Docker? Isso pode realmente ajudar a contornar o problema do certificado.

@ahmetalpbalkan Minhas credenciais parecem durar algumas horas. Não passa um dia sem ter que fazer o login novamente. Não estou limpando nada em meu diretório inicial.

@buckett Isso certamente soa como um bug que não fomos capazes de reproduzir. Você poderia executar docker-machine --debug ssh <vm> (substituir ssh por ip / status como desejar) e enviar a saída de depuração para mim (ahmetb em microsoft com) (ou colá-la em um gist) quando for solicitada a autenticação na próxima vez?

editar: acompanhando-o offline por e-mail.