Início / server / Perguntas / 770003
Accepted
aknuds1
Asked: 2016-04-14 03:21:02 +0800 CST

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

  • 772

Estou definindo um serviço one-shot em minha configuração de nuvem do CoreOS, mas está falhando devido à impossibilidade de baixar arquivos do Google Cloud Storage (via wget):

13 de abril 11:09:56 staging-node-ys9y.c.experimentalberlin.internal sh[1132]: conectando-se a storage.googleapis.com|74.125.133.128|:443... falhou: conexão expirou.

Como devo garantir que o serviço seja capaz de baixar arquivos da Internet?

Minha configuração de 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
systemd wget cloud-config coreos

1 respostas

  1. Best Answer

    Eu adotaria uma tática de várias etapas para solucionar isso. Perdoe as informações extras e explicações excessivas, todos aqui no CoreOS precisam lidar com isso comigo. ;)

    Em primeiro lugar, você deseja certificar-se de que a URL da qual você está tentando fazer o download pode ser recuperada de dentro do cluster. Atualmente, não vejo nenhuma razão para que esse não seja o caso, já que consegui (como um aparte, geralmente é melhor não colocar material de chave privada em um tarball acessível ao público. Nesse caso, embora ainda não seja o ideal pode ser melhor incluir esses ativos no user-dataou pelo menos proteger o tarball com criptografia simétrica .)

    Como o cloud-init é executado depois que a rede está online, isso deve ser suficiente (o serviço de metadados reside em http://169.254.169.254e, portanto, o cloud-config não pode ser recuperado até que a rede esteja online). problemas de rede ou outros detalhes.

    Quando 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á informando que houve um problema ao executar o próprio script. Explorar isso faz todo o sentido, pois quando olho para o topo desse script de shell, não há nenhum shebang dizendo ao systemd como executar o executável (neste caso, são todos os comandos compatíveis com Bourne Shell / Bourne-Again Shell , então o shebang provavelmente deve ser ou .) Adicionar um #!/bin/shshebang #!/bin/bashdeve corrigir esse problema.

    Algumas outras lêndeas menores:

    • ao usar wgetespecifique 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 que você os separe em suas ExecStart=opções relevantes, o que fornece registro adicional.

    • Como a maioria desses comandos é um preâmbulo para a execução do bootstrap.shscript real, eu mudaria todas as ExecStart=opções (com exceção da última) para ExecStartPre=.
    • 2

relate perguntas