如何確保 CoreOS 雲配置服務能夠下載文件？

我在我的 CoreOS 雲配置中定義了一次性服務，但由於無法從Google云儲存（通過 wget）下載文件而失敗：

4 月 13 日 11:09:56 staging-node-ys9y.c.experimentalberlin.internal sh

$$ 1132 $$：連接到 storage.googleapis.com|74.125.133.128|:443… 失敗：連接超時。

我應該如何確保該服務能夠從 Internet 下載文件？

我的雲配置

#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。目前，我沒有看到任何理由不應該出現這種情況，因為我能夠得到它（順便說一句，通常最好不要將私鑰材料放在可公開訪問的 tarball 中。在這種情況下，雖然仍然不是最佳user-data的將這些資產包含在或至少使用對稱加密保護 tarball可能會更好。）

由於 cloud-init 在網路上線後執行，這應該足夠了（元數據服務駐留在http://169.254.169.254，因此在網路上線之前無法檢索 cloud-config。）這意味著可能的罪魁禍首是暫時的網路問題或其他詳細資訊。

當我嘗試通過此執行時，我收到以下錯誤：

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 腳本的頂部時，沒有shebang告訴 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

• 擴展 tarball 時，您可以使用以下命令將其輸出到特定位置-C：

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

這允許您將它們分離到它們的相關ExecStart=選項中，從而提供額外的日誌記錄。

• 由於這些命令中的大多數都是實際腳本執行的前導bootstrap.sh，我會將所有ExecStart=選項（最後一個除外）更改為ExecStartPre=.

引用自：https://serverfault.com/questions/770003