Назад | Перейти на главную страницу

Как мне убедиться, что служба облачной конфигурации 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

Я бы применил многоступенчатую тактику для устранения этой проблемы. Прошу прощения за дополнительную информацию и излишние объяснения, всем здесь, в CoreOS, приходится иметь дело с этим от меня. ;)

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

Это сообщение сообщает вам, что при запуске самого скрипта возникла проблема. Копаться в этом имеет смысл, поскольку, когда я смотрю на верхнюю часть этого сценария оболочки, нет 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

  • при расширении архива вы можете вывести его в определенное место с помощью -C:

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

Это позволяет вам разделить их на соответствующие ExecStart= options, обеспечивающий дополнительное ведение журнала.

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