我使用Go [1]的Compute Engine API以及我制作的名为vmproxy [2]的工具以编程方式启动新实例。
我遇到的问题是,如果我使用指向https://bitbucket.org/ronoaldo/debian-custom/raw/tip/tools/autobuild的startup-script-url启动可抢占的VM,则构建脚本无法下载。我可以在串行控制台输出中看到启动脚本元数据存在,并且它尝试使用curl下载,但该部分失败。
但是,如果我通过开发人员控制台重置实例,则脚本会正确下载并运行。
我用来设置实例的代码是:
// Ronolinux is a VM Proxy that runs an live systems build on Compute Engine
var (
Ronolinux = &vmproxy.VM{
Path: "/",
Instance: vmproxy.Instance{
Name: "ronolinux-buildd",
Zone: "us-central1-f",
Image: vmproxy.ResourcePrefix + "/debian-cloud/global/images/debian-8-jessie-v20150915",
MachineType: "n1-standard-1",
Metadata: map[string]string{
"startup-script-url": "https://bitbucket.org/ronoaldo/debian-custom/raw/tip/tools/autobuild",
"shutdown-script": `!#/bin/bash
gsutil cp /var/log/startupscript.log gs://ronoaldo/ronolinux/build-$(date +%Y%m%d%H%M%S).log
`,
},
Scopes: []string{ storageReadWrite },
},
}
)
答案 0 :(得分:0)
如果您的启动脚本未托管在云端存储上,则下载失败的可能性很小。如果查看串行控制台输出,请确保水平滚动,因为它不会换行长行。在我的情况下,错误行很长,这隐藏了消息的真实结束:
(... long curl on-line progress output )
curl: (7) Failed to connect to bitbucket.org port 443: Connection timed out
(...)
您的主机必须在10秒内超时响应。在我的情况下,第一次启动通常无法联系Bitbucket,因此无法下载脚本; VM重置也使事情有效,因为Google Cloud之外的网络延迟可能更好。
我最终搬到云存储上托管脚本以避免这些问题。