我正在研究使用Windows Azure REST API在Windows Azure环境中创建虚拟机。查看Windows Azure REST API reference我看到应该向其发出POST请求的URL是:
https://management.core.windows.net/<subscription-id>/services/hostedservices/<cloudservice-name>/deployments/<deployment-name>/roles
我的困惑在于需要<cloudservice-name>
和<deployment-name>
。实际上,如果我直接登录到我的Windows Azure订阅门户并通过菜单创建虚拟机,我就不必指定cloudservice-name或deployment-name。我所做的就是为VM选择一个图像(centos,ubuntu,windows等),为VM选择一个风格(xsmall,small,large等)并单击“Create”,几分钟后创建VM 。
鉴于我可以通过这种方式创建VM,我无法理解为什么我必须在REST API curl调用中传递<cloudservice-name>
和<deployment-name>
参数以及要传递给哪些值那些参数。事实上,我的订阅中没有部署,也没有打算订阅。我想要的只是创建一个我可以使用的虚拟机。
我是否可以跳过这些参数,仍然可以在Azure订阅中创建虚拟机?即只是通过<subscription-id>
?
之前使用过Windows Azure REST API的人或者有Windows Azure专业知识的人是否会对此有所了解并帮助澄清?
更新星期三,07/31/2013:再次感谢您对我的问题的反馈。我想更新一下,我能够最终使用REST API调用创建虚拟机。但奇怪的是,创建虚拟机只能成功运行一次。随后,当我尝试使用不同的名称创建VM时,它出现了“暂存部署被阻止”之类的错误。因此,为了理智,我继续删除现有的VM并进行了一些帐户清理。我尝试了POST操作再次创建VM,现在发生的事情是POST响应回复正常,带有202 Accepted消息,但尽管如此,我还是看不到在我的Azure帐户中创建的VM。我不知道在哪里以及如何开始解决这个问题,因为我既没有收到错误,也没有创建VM。
我发布在我发布的用于创建VM的整个XML请求正文下面:
<Deployment xmlns="http://schemas.microsoft.com/windowsazure" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<Name>Staging</Name>
<DeploymentSlot>Staging</DeploymentSlot>
<Label>stk_curl_label_1</Label>
<RoleList>
<Role>
<RoleName>stk_curl_role_1</RoleName>
<RoleType>PersistentVMRole</RoleType>
<ConfigurationSets>
<ConfigurationSet>
<ConfigurationSetType>WindowsProvisioningConfiguration</ConfigurationSetType>
<ComputerName>stkVm1</ComputerName>
<AdminPassword>Password123</AdminPassword>
<EnableAutomaticUpdates>false</EnableAutomaticUpdates>
</ConfigurationSet>
</ConfigurationSets>
<OSVirtualHardDisk>
<HostCaching>ReadWrite</HostCaching>
<DiskLabel>Visual studio ultimate</DiskLabel>
<DiskName>stk_disk_1</DiskName>
<MediaLink>http://stk11.blob.core.windows.net/communityimages/visual_studio_ultimate.vhd</MediaLink>
<SourceImageName>03f55de797f546a1b29d1b8d66be687a__Visual-Studio-2013-Preview-Ultimate-12.0.20617.1</SourceImageName>
</OSVirtualHardDisk>
<RoleSize>ExtraSmall</RoleSize>
</Role>
</RoleList>
</Deployment>
我正在接受我正在接受卷曲呼叫的响应的尾部:
> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
> Host: management.core.windows.net
> Accept: */*
> x-ms-version: 2012-03-01
> Content-Type: application/xml
> Content-Length: 1236
> Expect: 100-continue
>
* SSLv3, TLS handshake, Hello request (0):
SSLv3, TLS handshake, Client hello (1):
SSLv3, TLS handshake, Server hello (2):
SSLv3, TLS handshake, CERT (11):
SSLv3, TLS handshake, Request CERT (13):
SSLv3, TLS handshake, Server finished (14):
SSLv3, TLS handshake, CERT (11):
SSLv3, TLS handshake, Client key exchange (16):
SSLv3, TLS handshake, CERT verify (15):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
HTTP/1.1 100 Continue
HTTP/1.1 202 Accepted
< Cache-Control: no-cache
< Content-Length: 0
< Server: 33.0.6198.68 (rd_rdfe_stable.130710-0833) Microsoft-HTTPAPI/2.0
< x-ms-servedbyregion: ussouth
< x-ms-request-id: b2f3dd01319049a5a6728bbdbcde6c4a
< Date: Wed, 31 Jul 2013 17:26:54 GMT
* Connection #0 to host management.core.windows.net left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
您可以清楚地看到,这是一个“202 Accepted”回复。但正如我之前提到的,尽管如此,当我查看我的Azure帐户时,我看不到正在创建VM。
对于如何找出导致其无法正常工作的根本原因的任何专家见解/想法表示感谢?
答案 0 :(得分:5)
你所看到的是门户幕后的一点魔力。部署虚拟机时,它确实最终位于Cloud Service容器中。最近这个更改在门户网站中变得更加明显,之前他们正在隐藏这个。当人们删除VM或将其他VM添加到同一组(以前称为“附加到”)时,云服务将显示在门户中。人们对这是什么感到困惑,只是引起了更多的问题。
现在,在门户网站中,系统会提示您提供云服务。如果您在快速创建时询问DNS名称(并在其旁边显示.cloudapp.net),那么这就是您提供的Cloud Service名称。当您通过Gallery进行创建时,在第3步中要求创建新的Cloud Service或选择已存在的Cloud Service时更为明显。
要通过REST API执行您想要的操作,您需要提前创建云服务或在创建VM之前调用。此外,您提供的链接用于添加Cloud Service角色,而不是创建虚拟机。对于那个REST API调用,您将要使用它:http://msdn.microsoft.com/en-us/library/windowsazure/jj157194.aspx它仍然需要云服务,但不需要部署名称。
答案 1 :(得分:1)
有两种不同的API,一种用于在云服务下创建部署和VM,另一种用于向先前创建的部署添加角色。
这是2个API
用于VM部署
http://msdn.microsoft.com/en-us/library/azure/jj157194.aspx
对于部署中的角色
http://msdn.microsoft.com/en-us/library/azure/jj157186.aspx
您使用的是第二个,首先需要使用第一个API创建VM部署,然后使用第二个API在同一个云服务中添加更多角色。
答案 2 :(得分:1)
我遇到了同样的问题,添加角色让我接受了202但没有创建VM。经过几个小时试图找出问题所在,我发现在管理门户上他们有这些管理服务 - &gt;操作日志,它显示所有API调用的日志。
正是在这里,我的添加角色API调用告诉我这是一个404错误请求而不是202接受,它也向我显示了特定错误。
管理服务 - &gt;当您遇到API时,操作日志非常有用。