Puppet: variáveis que melhoram as práticas recomendadas

1

Eu estou querendo saber quais são as melhores práticas para substituir variáveis no fantoche. Eu gostaria de ter todos os meus nós (que estão localizados em lugares diferentes, alguns deles são qa, alguns ao vivo) com as mesmas classes. Agora eu tenho algo assim:

class base_linux {
   <...> # something which requires $env and $relayhost variables
}

class linux_live {
   $relayhost="1.1.1.1"
   $env = "prod"

   include base_linux
}

class linux_qa {
   $relayhost="2.2.2.2" # override relayhost

   include base_linux
}

class linux_trunk {
   $env = "trunk" # override env

   inlude linux_qa
}

node "trunk01" {
   include linux_trunk
   include <something else>
}
node "trunk02" {
   $relayhost = "3.3.3.3" # override relayhost
   include linux_trunk
   include <something else>
}

node "prod01" {
   include linux_prod
}

Então, eu gostaria de ter alguns padrões em base_linux, que podem ser substituídos por linux_qa / linux_live, que podem ser sobrepostos em classes de nível mais alto e definição de nó.

Claro, isso não funciona (e não se espera que funcione). Também não funciona com herança de classes. Provavelmente, poderei arquivar usando variáveis de escopo global, mas não parece uma boa ideia para mim.

Qual é a melhor maneira de resolver este problema?

    
por rvs 26.06.2011 / 13:35

3 respostas

2

Parece que encontrei uma maneira legal de fazer isso: em vez de definir variáveis em classes, é melhor criar modelos de nós apenas variáveis. Então, acabei com algo como seguir:

node basenode {
}

node linux_prod inherits basenode {
  $relayhost="1.1.1.1"
  $env = "prod"
}

node linux_qa inherits basenode {
  $relayhost="2.2.2.2"
}

node linux_trunk inherits linux_qa {
  $env = "trunk"
}

class base_linux {
  # no valuables defined here
  <...>
}

node trunk01 inherits linux_trunk {
   $relayhost = "3.3.3.3" # I can override here for single node
   include base_linux
}
    
por 26.06.2011 / 15:24
4

A melhor prática depende do número de nós / sistemas que você gerencia. Modelar dados em manifestos de puppet é suficiente se você puder acompanhar os dados (eu vi isso feito com milhares de sistemas, no entanto, é um desafio se você tiver um grande número de variáveis e herança profunda, especialmente se você começar a fazer referências por escopo como $ value = $ some_class :: some_var). Se você tem uma infraestrutura complexa, faz sentido olhar para separar os dados dos manifestos de puppet usando o extlookup, heira ou um classificador de nó externo (ENC).

A maneira como você fez isso nos manifestos puppet está usando o escopo dinâmico e a herança de nós, e o escopo dinâmico está sendo substituído no Puppet 2.7. Se isso for reescrito no extlookup, seria simplesmente:

# configured globally
# linux_qa is more likely linux_%{env}
$extlookup_precedence = ["%{fqdn}", "linux_trunk", "linux_qa", "common"]

# in the appropriate class
$relayhost = extlookup("relayhost")
    
por 29.06.2011 / 23:46
1

Minha sugestão é não colocar as variáveis nas classes - apenas se essa classe precisar substituir alguma coisa.

Coloque suas variáveis dentro de site.pp (ou algum arquivo importado - eu nomeio o meu globals.pp), coloque as regras para discernir quais os valores que elas devem ter lá - escolha em vez de substituir. Então você pode fazer substituições individuais em nós ou classes como desejar.

    
por 27.06.2011 / 02:07

Tags