Diferenças entre local 'puppet apply' e 'puppet agent' para um puppetmaster

Question

Estamos no processo de migrar de um repositório de fantoches monolítico que contém todas as configurações. Este repositório contém coisas que realmente não deveriam estar em todos os nós, então um sistema baseado em puppetmaster parece ser a melhor maneira de segregar as coisas de maneira apropriada.

O problema que estou tendo é que o mesmo repositório funciona bem quando copiado para os nós locais e puppet apply /etc/puppet/manifests/site.pp é executado nele. Nossas instalações são executadas de maneira muito clara.

Quando eu coloco o repositório de fantoches no mestre de bonecos e faço com que o agente seja assinado, ele não parece fazer nada além de relatar seu catálogo local para o mestre de bonecos.

Por um tempo, e eu não consegui reproduzir a configuração que fez isso, um de nossos módulos auto-compilados estava lançando um erro que sugeria que ele estava tentando copiar um arquivo da máquina local modules diretório, em vez de o puppetmaster como deveria.

O que sugere que pode haver diferenças de sintaxe de módulo e manifesto ao criar um repositório para uso local e via mestre de fantoches.

Se houver alguma diferença, quais são eles ou quais são os principais pontos de partida para os esforços de conversão?

O arquivo /etc/puppet/puppet.conf no mestre:

[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
pluginsync=true

# Set up Environments
## Each environment has a dedicated 'modules' directory under /environments/ from
## which puppet will preferentially pull. Otherwise, it'll use the top level  
## 'modules' directory. That is where common code goes.
[master]
  manifest=$confdir/manifests/site.pp
  modulepath=$confdir/environments/$environment/modules:$confdir/modules
  ssl_client_header= SSL_CLIENT_S_DN
  ssl_client_verify_header = SSL_CLIENT_VERIFY
[production]
  manifest=$confdir/manifests/site_prod.pp
[integration]
  manifest=$confdir/manifests/site_integ.pp
[development]
  manifest=$confdir/manifests/site_dev.pp
[operations]
  manifest=$confdir/manifests/site_ops.pp

No momento, o arquivo site_prod.pp e ilk são links simbólicos para site.pp .

As classes definidas no arquivo site.pp funcionam fora do nome do host. Como mencionei, quando executado via puppet apply , as coisas funcionam bem. Se o pior acontecer, posso fazer o que preciso por meio de uma montagem NFS temporária, mas prefiro não fazer isso.

site.pp Para sua diversão:

filebucket { "main": server => $server; }
File { backup => "main" }

Exec { path => "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" }

import "stages.pp"
import "int_setup.pp"
import "nodes.pp"

Os arquivos .pp importados estão no mesmo diretório que site.pp. nodes.pp é onde a carne está, mas também contém molho secreto. Alguns trechos:

node /clunod\-wk\d+\.sub\.example\.local/ {

  class { "int_setup": stage => "setup"; }
  include base
  include curl
  include custommodule
  [...]
}

Que pode e combina nós denominados clunod-wk01234.sub.example.local quando executado via marionete.

[int-setup.pp]

class int_setup {
  file { "/var/cluebat":
    ensure => directory,
    mode => "755",
    owner => "root",
    group => "root";
  }

  group{"puppet":
    ensure => present
  }

}

    

Answer 1

A única dificuldade que conheço está no tipo de recurso file .

O backup dos arquivos substituídos se comporta de maneira diferente, usando o filebucket do servidor por padrão, em vez do filebucket local.

O mais importante é estar ciente do parâmetro source .

source => '/tmp/somepath/sshd_config',

Com um caminho de arquivo bruto, ele sempre tentará o caminho local.

source => 'puppet://puppetmaster1/modules/sshd/sshd_config',

Com um caminho puppet://server/ , ele sempre tentará o caminho remoto.

source => 'puppet:///modules/sshd/sshd_config',

Com uma especificação de servidor vazia, fica interessante.

Aplicado localmente, o caminho do módulo puppet local é usado para encontrar o arquivo.

Quando se reporta a um puppetmaster, o servidor que lhe deu o manifesto é tratado como o servidor.

Além disso, se você precisar ser criativo sobre a origem de um arquivo, poderá fornecer uma lista à lista source :

source => [ '/tmp/somepath/sshd_config', 'puppet:///modules/sshd/sshd_config'],

O primeiro local onde algo foi encontrado será usado.

    

Answer 2

O problema acabou sendo uma diferença em como os nós estavam sendo selecionados. O código no arquivo nodes.pp original:

node /clunod\-wk\d+\.sub\.example\.local/ { )

Que corresponde corretamente a um nó chamado clunod-wk01234.sub.example.local. Isso estava funcionando muito bem quando puppet apply foi executado contra um manifesto de marionetes local. Mas não foi remotamente.

O problema foi como a linha localhost foi definida em /etc/hosts .

Não funciona:

127.0.0.1  localhost clunod-wk01234 clunod-wk01234.sub.example.local

Trabalhando:

127.0.0.1  localhost clunod-wk01234.sub.example.local clunod-wk01234

O primeiro formulário estava relatando um nome de nó "clunod-wk01234" para o puppetmaster, o segundo formulário estava relatando o FQDN. A segunda forma satisfaz o delcaration node , onde o primeiro não. Isso foi quebrado alterando as linhas do nó para não incluir o FQDN, ponto no qual tudo funcionou muito bem.

As máquinas com o fantoche remoto eram uma imagem atualizada, assim como algumas pequenas diferenças em relação às que executavam o fantoche local. Uma dessas mudanças acabou sendo em como essa linha em /etc/hosts foi declarada. Agora nós sabemos.

Eu, então, encontrei duas chamadas de arquivo foram escritas usando caminhos difíceis, o resto foi usado correto fantoche: / / / sintaxe.

    

Answer 3

Não há diferença entre as regras de fantoches 'locais' e 'remotas'.

Você pode postar seu site.pp para que possamos verificar erros?

O servidor e os clientes usam o mesmo servidor DNS? Seus arquivos /etc/resolv.conf diferem nas linhas de 'pesquisa' ou 'domínio'?

Você também pode executar o fantoche com --debug --verbose --no-daemonize opções e obter mais resultados.