如何确保CoreOS云configuration服务能够下载文件？

我在CoreOS云configuration中定义了一次性服务，但由于无法从Google云端存储（通过wget）下载文件，因此无法正常运行：

4月13日11:09:56 staging-node-ys9y.c.experimentalberlin.internal sh [1132]：正在连接到storage.googleapis.com | 74.125.133.128 |：443 …失败：连接超时。

我应该如何确保服务能够从互联网上下载文件？

我的云configuration

#cloud-config coreos: units: - name: bootstrap.service command: start content: | [Unit] Description=Bootstrap instance After=network-online.target Requires=network-online.target [Service] Type=oneshot RemainAfterExit=true ExecStart=/usr/bin/mkdir -p /tmp/kubernetes-staging ExecStart=cd /tmp/kubernetes-staging ExecStart=/bin/sh -c "cd /tmp/kubernetes-staging && wget https://storage.googleapis.com/experimentalberlin/staging.tar.gz && tar xf staging.tar.gz" ExecStart=/tmp/kubernetes-staging/worker/bootstrap.sh [Install] WantedBy=local.target

我会采取一个多步骤的策略来解决这个问题。请原谅，额外的信息和解释，在CoreOS的每个人都必须处理这个从我。 ;）

首先，您要确保您尝试从中下载的URL可以从群集中检索。目前，我看不出有什么理由不这样做，因为我可以想像它（另外，通常最好不要将私人密钥材料放在可公开访问的tar包中，在这种情况下，仍然不是最佳的将这些资产包含在user-data或者至less用对称encryption保护tarball可能会更好）。

由于cloud-init在networking上线之后运行，这应该足够了（元数据服务位于http://169.254.169.254 ，因此直到networking联机后才能检索到cloud-config。）这意味着可能的罪魁祸首是暂时的networking问题或其他细节。

当我试图通过这个我得到以下错误：

 core@rbtest ~ $ journalctl -u bootstrap.service -- Logs begin at Wed 2016-04-13 17:31:35 UTC, end at Wed 2016-04-13 17:33:09 UTC. -- Apr 13 17:31:47 rbtest.c.coreos-support.internal systemd[1]: [/etc/systemd/system/bootstrap.service:10] Executable path is not absolute, ignoring: cd /tmp/kubernetes-staging Apr 13 17:31:47 rbtest.c.coreos-support.internal systemd[1]: Starting Bootstrap instance... Apr 13 17:31:47 rbtest.c.coreos-support.internal sh[1074]: --2016-04-13 17:31:47-- https://storage.googleapis.com/experimentalberlin/staging.tar.gz Apr 13 17:31:47 rbtest.c.coreos-support.internal sh[1074]: Resolving storage.googleapis.com... 209.85.200.128, 2607:f8b0:4001:c08::80 Apr 13 17:31:47 rbtest.c.coreos-support.internal sh[1074]: Connecting to storage.googleapis.com|209.85.200.128|:443... connected. Apr 13 17:31:48 rbtest.c.coreos-support.internal sh[1074]: HTTP request sent, awaiting response... 200 OK Apr 13 17:31:48 rbtest.c.coreos-support.internal sh[1074]: Length: 4722 (4.6K) [application/x-tar] Apr 13 17:31:48 rbtest.c.coreos-support.internal sh[1074]: Saving to: 'staging.tar.gz' Apr 13 17:31:48 rbtest.c.coreos-support.internal sh[1074]: 0K .... 100% 47.4M=0s Apr 13 17:31:48 rbtest.c.coreos-support.internal sh[1074]: 2016-04-13 17:31:48 (47.4 MB/s) - 'staging.tar.gz' saved [4722/4722] Apr 13 17:31:48 rbtest.c.coreos-support.internal systemd[1]: bootstrap.service: Main process exited, code=exited, status=203/EXEC Apr 13 17:31:48 rbtest.c.coreos-support.internal systemd[1]: Failed to start Bootstrap instance. Apr 13 17:31:48 rbtest.c.coreos-support.internal systemd[1]: bootstrap.service: Unit entered failed state. Apr 13 17:31:48 rbtest.c.coreos-support.internal systemd[1]: bootstrap.service: Failed with result 'exit-code'.

这里的线索是：

  bootstrap.service: Main process exited, code=exited, status=203/EXEC

此消息告诉您运行脚本本身时出现问题。挖掘这一点非常有意义，因为当我查看shell脚本的顶部时，并没有告诉systemd 如何运行可执行文件（在这种情况下，所有Bourne Shell / Bourne-Again Shell兼容命令，所以shebang应该可能是#!/bin/sh或#!/bin/bash 。）添加一个shebang应该可以解决这个问题。

其他一些小瑕疵：

使用wget指定下载位置：

 wget -O /tmp/kubernetes-staging/staging.tar.gz https://storage.googleapis.com/experimentalberlin/staging.tar.gz

当扩展你的压缩包时，你可以使用-C输出到特定的位置：

 tar xf /tmp/kubernetes-staging/staging.tar.gz -C /tmp/kubernetes-staging/

这使您可以将它们分离到相关的ExecStart=选项中，该选项提供了更多的日志logging。

由于这些命令中的大部分都是对实际bootstrap.sh脚本执行的ExecStart= ，所以我会将所有ExecStart=选项（最后一个除外）更改为ExecStartPre= 。