Puppet ： Não foi possível encontrar o nó padrão ou pelo nome com o nó test2

Question

Eu instalei o Puppet 3.1.1 em um servidor Ubuntu.

Minha pasta manifests ficou assim:

├── nodes
│   └── test1.pp
└── site.pp

O conteúdo do site.pp era:

# site.pp
import "nodes/*.pp"

O nó test1 funcionou bem.

Em seguida, criei um novo arquivo chamado test2.pp . O conteúdo era o mesmo que test1.pp, exceto pelo nome do nó, e eu o adicionei na pasta de nós.

Então a pasta manifests se tornou assim:

├── nodes
│   ├── test1.pp
│   └── test2.pp
└── site.pp

Em seguida, executei puppet agent --test no nó test2.

O agente pode trocar chaves SSL com o mestre de marionetes, mas recebi uma mensagem de erro:

Could not find default node or by name with test2

Se eu não criar um novo arquivo test2.pp e apenas adicionar o conteúdo ao arquivo test1.pp , nenhum erro será exibido.

Então, estou pensando que o Puppet não importará dinamicamente um novo arquivo pp depois que o mestre de marionetes for iniciado.

É possível definir nós em arquivos pp individuais e importá-los dinamicamente?

Fico feliz por qualquer sugestão.

O conteúdo dos dois arquivos pp:

node 'test1' {
  include tmp::params
  tmp::gtp { 'node1':
    name            => 'node1',
    version         => '6.0.0.0',
    ip              => '168.1.193.97',
    port            => '1255',
  }
}

node 'test2' {
  include tmp::params
  tmp::gtp { 'node2':
    name            => 'node2',
    version         => '6.0.0.0',
    ip              => '168.1.193.98',
    port            => '1255',
  }
}

    

Answer 1

Eu recomendaria que você se afastasse das definições do nó do manifesto para o Hiera. Você precisará ajustar um pouco as coisas para se afastar de ter esse tipo definido chamado diretamente de seu nó, mas parece que isso não está sendo usado várias vezes em um catálogo, portanto, a conversão para uma classe deve funcionar bem. / p>

Portanto, com um hiera.yaml como este ...

---
:backends:
  - yaml

:hierarchy:
  - '%{::clientcert}'
  - 'os-%{::osfamily}'
  - common

:yaml:
   :datadir: /etc/puppet/hieradata

E um site.pp com apenas:

hiera_include(classes)

.. seus nós serão lidos dos arquivos YAML em /etc/puppet/hieradata . Por exemplo, digamos que você queira tmp::params em todos os nós que reportam ao Puppet, mas talvez você queira tmp::gtp apenas em determinados nós. E você deseja definir centralmente o parâmetro version , mas deixe os outros parâmetros a serem definidos por nó. Então, colocaremos tmp::params e version parameter /etc/puppet/hieradata/common.yaml :

classes:
  - tmp::params

tmp::gtp::version: 6.0.0.0

Então você terá um arquivo para cada nó.

/etc/puppet/hieradata/test1.yaml :

classes:
  - tmp::gtp

tmp::gtp::name : node1
tmp::gtp::ip   : 168.1.193.97
tmp::gtp::port : 1255

/etc/puppet/hieradata/test2.yaml :

classes:
  - tmp::gtp

tmp::gtp::name : node2
tmp::gtp::ip   : 168.1.193.98
tmp::gtp::port : 1255

E sim, ele selecionará as alterações nos arquivos Hiera sem a reinicialização do serviço. Parece que você precisa?

Editar : para usar o Hiera para configurar várias instâncias de um tipo definido, você vai querer fazer algo assim:

/etc/puppet/hieradata/test1.yaml :

classes:
  - gtpsetup

gtp_instances:
  - node1_instance1
  - node1_instance2

gtp_instanceconfig:
  node1_instance1:
    ip      : 168.1.193.97
    port    : 1255
    version : 5.3.2.1

  node1_instance2:
    ip      : 168.1.193.97
    port    : 1268
    version : 6.0.0.0

/etc/puppet/modules/gtpsetup/manifests/init.pp :

class gtpsetup {
  gtp_instances = hiera('gtp_instances')
  gtp_instanceconfig = hiera('gtp_instanceconfig')

  define gtp_instance {
    # this is using your existing defined type, but you can just move the stuff it's doing to here.
    tmp::gtp { $title:
      name    => $title,
      version => gtp_instanceconfig[$title]['version'],
      ip      => gtp_instanceconfig[$title]['ip'],
      port    => gtp_instanceconfig[$title]['port'],
    }
  }

  gtp_instance { $gtp_instances: }
}

    

Answer 2

Shane deu uma excelente resposta com uma maneira melhor de abordar seu problema, mas quero abordar: "Então, estou pensando que o Puppet não importará dinamicamente um novo arquivo pp depois que o mestre de marionetes for iniciado".

Isso é meio verdade. Quando o Puppet é iniciado, ele lê todos os arquivos de configuração e, em seguida, começa a observá-los em busca de alterações. Quando o conteúdo de um desses arquivos for atualizado, o Puppet relerá o arquivo. O Puppet também tem um conjunto de locais padrão para os arquivos que serão consultados quando necessário, portanto, se você adicionar uma nova classe foo::bar a um nó em um arquivo que está monitorando, ele procurará um arquivo chamado foo/manifests/bar.pp ( ou foo/manifests/bar.rb ) em seu $modulepath , mesmo que não tenha precisado desse arquivo quando foi iniciado.

Importante, as diretivas import só são avaliadas quando o arquivo em que estão é analisado. Quando o mestre de marionetes começou, ele leu seu arquivo site.pp , viu a instrução import e encontrou apenas nodes/test1.pp , então os únicos arquivos monitorados para as alterações foram site.pp e nodes/test1.pp . Nunca viu nodes/test2.pp .

Uma solução para isso seria simplesmente touch site.pp após adicionar um novo arquivo ao diretório nodes . Isso fará com que o mestre de marionetes releia site.pp , o que fará com que ele reprocesse a instrução import e, em seguida, verá o novo arquivo.

No longo prazo, porém, é melhor seguir as recomendações do Shane e separar seus dados do seu código. Se você puder estruturar suas definições para não precisar da instrução import , ficará melhor; ainda tem seus usos, mas de várias maneiras import é uma relíquia das práticas de Marionetes mais antigas que não são mais relevantes.