Ir para o conteúdo
ou

Software livre Brasil

 Voltar a Blogosfera d...
Tela cheia Sugerir um artigo

Puppet 4 e suas melhores práticas

8 de Setembro de 2015, 19:06 , por PSL-BA Feeds - 0sem comentários ainda | Ninguém está seguindo este artigo ainda.
Visualizado 30 vezes

Com o lançamento do Puppet 4, algumas práticas serão depreciadas e outras são apenas desaconselhadas, sendo assim pretendo nesse texto fazer um resumo delas, afim de indicar quais as melhores práticas para evitar problemas no futuro.

Puppet_Labs_Logo

Esse texto presume que você já sabe usar puppet, caso não saiba nada de puppet,  aconselho que leia um pouco sobre ele antes. Existe um máquina virtual com um ambiente perfeito para aprendizado. Você segue um guia PDF praticando nessa máquina, que foi projetada pra isso. Muito bom. Aconselho!

Vamos as práticas:

Herança de classe

Esse tipo de prática só é aconselhado para módulos do tipo “params”:

Má prática:

class foo {

}

class foo::baz inherits foo {

}

Prática aceitável:

class ssh (

$server = $ssh::params::server,

) inherits ssh::params {

}

class ssh::params {

server => false,

}

Chamada de módulo

Não use mais “import”. Essa função foi depreciada no Puppet 4.

Má prática:

# foo/manifests/init.pp

class foo {

import ‘bar.pp’

}

# foo/manifests/bar.pp

class foo::baz {

}

# foo/manifests/baz.pp

class foo::baz {

}

Qual classe foo::baz será usada?

Boa prática:

Use include ao invés de import

# foo/manifests/init.pp

class foo {

include ‘foo::baz’

}

# foo/manifests/bar.pp

class foo::baz {

}

Agora sabemos exatamente o que será utilizado.

Módulos remotos

Não é aconselhável alterar localmente módulos remotos (Aqueles retirados do forge e outros repositórios externos)! Caso precise modificar algo, use o módulo remoto parametrizável, crie seu próprio módulo com base nesse uso, mas caso seja uma melhoria genérica para todos, submeta sugestões ao upstream. Lembre-se, somos uma comunidade!

Lembre-se  também que você pode precisar atualizar esse módulos depois do upstream!

Variável não local

Pare de usar variável não local sem estabelecimento de escopo! É péssimo para o tratamento de problemas no futuro, pois quando existirem muitos módulos, você não terá ideia de onde esse valor é recebido.

Má prática:

class foo (

$bar = ‘baz’

){

}

class foo::baz {

notify { $bar },

}

Boa prática

class foo (

$bar = ‘baz’

){

}

class foo::baz {

notify { $foo::bar: },

}

Variável de template

Não use variável de template sem escopo, pois algumas delas conflitavam com métodos ruby e a utilização delas sem o “@” como prefixo foi depreciada.

Má prática

key = <%= var %>

Boa prática

key = <%= @var %>

Variável factor

Evite usar variável factor sem escopo superior.

Má prática:

class foo {

notify {“We are on OS: $operatingsystem”:}

}

Boa prática

class foo {

notify {“We are on OS: ${::operatingsystem}”:}

}

A sintaxe “::” especifica que a variável está no escopo superior, assim evitando que alguma variável local de um outro módulo possa afetar o seu valor.

Validação de valor

Sempre faça validação de valor da variáveis, pois dados errados podem impactar seu ambiente.

Má prática

class foo (

$server = hiera(‘server’,’localhost’)

){

notify {“We will use Server: ${server}”:}

}

Use a função “validate_string” do módulo stdlib para verificar se o valor recebido na variável de fato é uma string.

Boa prática

class foo (

$server = hiera(‘server’,’localhost’)

){

validate_string($server)

notify {“We will use Server: ${server}”:}

}

Caso tenha outras sugestões, coloque como comentário! :)

Esse texto foi feito com base nessa apresentação. A minha ideia foi descrever as melhores práticas e explicar um pouco sobre elas.


Fonte: http://techfree.com.br/2015/09/puppet-4-e-suas-melhores-praticas/

0sem comentários ainda

Enviar um comentário

Os campos são obrigatórios.

Se você é um usuário registrado, pode se identificar e ser reconhecido automaticamente.