Como posso garantir que um serviço de configuração de nuvem do CoreOS é capaz de baixar arquivos?

Question

Estou definindo um serviço one-shot na configuração de nuvem do CoreOS, mas está falhando por não conseguir fazer download de arquivos do Google Cloud Storage (via wget):

Apr 13 11:09:56 staging-node-ys9y.c.experimentalberlin.internal sh[1132]: Connecting to storage.googleapis.com|74.125.133.128|:443... failed: Connection timed out.

Como devo garantir que o serviço possa baixar arquivos da Internet?

Minha configuração da nuvem

#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

    

Answer 1

Eu tomaria uma tática de várias etapas para solucionar isso. Perdoem as informações extras e explicações, todos aqui no CoreOS têm que lidar com isso de mim. ;)

Primeiramente, você quer ter certeza de que o URL do qual você está tentando fazer o download pode ser recuperado de dentro do cluster. Atualmente, eu não vejo nenhuma razão para que isso não seja o caso, pois eu era capaz de usá-lo (como um aparte, geralmente é melhor não colocar material de chave privada em um arquivo publicamente acessível). Neste caso, enquanto ainda não é ótimo , pode ser melhor incluir esses recursos no user-data ou, no mínimo, proteger o tarball com criptografia simétrica .)

Como o cloud-init é executado após a rede estar online, isso deve ser suficiente (o serviço de meta-dados reside em http://169.254.169.254 e, portanto, a configuração da nuvem não pode ser recuperada até que a rede esteja on-line). prováveis culpados estão relacionados a problemas de rede transitórios ou outros detalhes.

Quando eu tento executar isso, recebo o seguinte erro:

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'.

A pista aqui é a linha:

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

Esta mensagem está dizendo que houve um problema ao executar o script em si. Cavando isso faz todo o sentido, como quando eu olho para o topo do script de shell, não há shebang dizendo ao systemd como para executar o executável (neste caso, é tudo Bourne Shell / Bourne-Again Shell comandos compatíveis, então o shebang provavelmente deve ser #!/bin/sh ou #!/bin/bash .) Adicionar um shebang deve corrigir esta questão.

Algumas outras pequenas lêndeas:

• ao usar wget , especifique o local de download:

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

• ao expandir seu tarball, você pode enviá-lo para um local específico com -C :

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

Isso permite separá-los em suas opções ExecStart= relevantes, o que fornece registros adicionais.

• Como a maioria desses comandos é pré-editável para a execução do script bootstrap.sh real, eu alteraria todas as opções ExecStart= (com a exceção da última) para ExecStartPre= .