Как убедиться, что служба облачной конфигурации CoreOS может загружать файлы?

Я определяю однократную службу в своей облачной конфигурации CoreOS, но она не работает из-за невозможности загрузки файлов из облачного хранилища Google (через wget):

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-адрес, с которого вы пытаетесь загрузить, может быть получен из кластера. В настоящее время я не вижу никаких причин, почему это не должно быть так, как я смог это увидеть (в качестве отступления, как правило, лучше не помещать материал с закрытым ключом в общедоступный архив). В этом случае, хотя он все еще не оптимален может быть лучше включить эти активы либо в user-data или, по крайней мере, защитить тарбол с помощью симметричного шифрования.)

Поскольку 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

Это сообщение говорит о том, что при запуске самого скрипта возникла проблема. Копаться в этом имеет смысл, так как, когда я смотрю на верхнюю часть этого сценария оболочки, нет никакого шебанга, указывающего systemd, как запускать исполняемый файл (в данном случае это все команды, совместимые с Bourne Shell/ Bourne-Again Shell, поэтому шебанг, вероятно, должен быть или #!/bin/sh или же #!/bin/bash.) Добавление Шебанга должно решить эту проблему.

Некоторые другие мелкие гниды:

  • когда используешь 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= параметры, которые обеспечивают дополнительное ведение журнала.

  • Поскольку большинство из этих команд являются предварительными для выполнения фактического bootstrap.sh сценарий, я бы изменил все ExecStart= варианты (за исключением последнего) ExecStartPre=,
Источник
Другие вопросы по тегам