☰

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

tag-icon • tag-icon systemd wget coreos cloud-config
如何确保 CoreOS 云配置服务能够下载文件？

我正在 CoreOS 云配置中定义一次性服务，但由于无法从 Google Cloud Storage 下载文件（通过 wget）而失败：

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

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

我的云配置

#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

答案1

我会采取多步骤策略来解决这个问题。请原谅我提供的信息过多和解释过多，CoreOS 的每个人都需要我来处理这个问题。;)

首先，你要确保你尝试下载的 URL 可以从集群内部检索。目前，我看不出有什么理由这样做不是因为我能够通过 wget 获取它（顺便说一句，通常最好不要将私钥材料放在可公开访问的 tarball 中。在这种情况下，虽然仍然不是最佳的最好将这些资产包含在 tarball 中，user-data或者至少使用以下方法保护 tarball：对称加密。

由于 cloud-init 在网络在线后运行，这应该足够了（元数据服务驻留在http://169.254.169.254网络在线，因此在网络在线之前无法检索云配置。）这意味着可能的罪魁祸首是瞬态网络问题或其他细节。

当我尝试运行此程序时出现以下错误：

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如何运行可执行文件（在本例中是伯恩壳牌/重回伯恩之壳兼容命令，因此 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=。

相关内容