fato externo não disponível na primeira corrida de marionetes

Question

Introdução:

Estamos usando o fantoche para configurar os nós através de um fato personalizado que é então referenciado no hiera. O fato pode residir na imagem de ouro em /etc/facter/fact.d/ ou via pluginsync (não faz diferença, testou ambos)

Versões:

dpkg -l|grep puppet
hi  facter                             1.7.5-1puppetlabs1        amd64        Ruby module for collecting simple facts about a host operating system
hi  hiera                              1.3.4-1puppetlabs1        all          A simple     pluggable Hierarchical Database.
hi  puppet                             3.4.3-1puppetlabs1        all          Centralized configuration management - agent startup and compatibility scripts
hi  puppet-common                      3.4.3-1puppetlabs1        all          Centralized configuration management

A configuração é simples:

Puppetmaster:

cat hiera.yaml
:hierarchy:
  - "aws/%{::aws_cluster}"

/etc/puppet/hieradata/aws/web.json

Nó EC2:

cat /etc/facter/facts.d/ec_cluster.sh
echo 'aws_cluster=web'

Portanto, há esta imagem ec2 dourada incluindo o fato aws_cluster. Isso é referenciado no hiera e especifica as classes e configurações a serem feitas.

Problema:

Quando inicializamos a instância e ativamos o autosigning, a primeira execução não terá o $ aws_cluster presente no lado do cliente. Então vai falhar (o que faz sentido) dizendo

puppet-agent[2163]: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find data item classes in any Hiera data file and no default supplied at /etc/puppet/manifests/site.pp:33 on node ip-172-31-35-221.eu-west-1.compute.internal

Quando o agente fantoche é reiniciado, tudo funciona conforme o esperado. Alguma dica sobre isso?

Nosso palpite é:

• tem algo a ver com a geração de certificados?
• o que acontece na primeira corrida?
• é diferente se o iniciarmos manualmente /etc/init.d/puppet start do que sobre init?

Atualização:

ao tentar iniciá-lo em /etc/rc.local, ele também falha. Portanto, deve haver uma diferença entre execuções interativas e não interativas. há variáveis especiais do ambiente que precisam ser definidas?

    

Answer 1

Sinto muito, estamos no caminho errado.

Após mais depuração e registro de saída de rc.local do facter -p, vimos que nosso fato externo está exigindo as credenciais aws para o script ser executado com sucesso. Isso é automaticamente originado quando você está logado como root, mas não quando você o executa no momento da inicialização.

Portanto, exportar os parâmetros env para as credenciais aws resolveu o caso.

as informações que não estão funcionando com o par de valores-chave do plano devem estar incorretas durante a depuração. sry

tl; dr: não foi um problema / problema de marionete