Fantoche - Módulo

No Puppet, um módulo pode ser definido como uma coleção de recursos, classes, arquivos, definições e modelos. O Puppet oferece fácil redistribuição de módulos, o que é muito útil na modularidade do código, pois é possível escrever um módulo genérico especificado e usá-lo várias vezes com muito poucas mudanças simples no código. Por exemplo, isso habilitará a configuração do site padrão em / etc / puppet, com módulos enviados pelo Puppet em / etc / share / puppet.

Configuração do Módulo

Em qualquer módulo Puppet, temos duas partições que auxiliam na definição da estrutura do código e no controle dos denominados.

O caminho de pesquisa dos módulos é configurado usando uma lista separada por dois pontos de diretórios no puppetmasterd ou masterd, a seção posterior do arquivo de configuração mestre do Puppet com o modulepath parâmetro.

[puppetmasterd] 
... 
modulepath = /var/lib/puppet/modules:/data/puppet/modules

O caminho de pesquisa pode ser adicionado no tempo de execução definindo a variável de ambiente PUPPETLAB que também deve ser uma lista de variáveis separada por dois pontos.

Nas configurações de controle de acesso para os módulos do servidor de arquivos em fileserver.conf, a configuração do caminho para esse módulo é sempre ignorada e a especificação de um caminho produzirá um aviso.

Fonte de Módulos

O Puppet oferece suporte a um local diferente para armazenar módulos. Qualquer módulo pode ser armazenado em diferentes sistemas de arquivos de qualquer máquina específica. No entanto, todos os caminhos onde os módulos são armazenados devem ser especificados na variável de configuração conhecida comomodulepath que é, em geral, uma variável de caminho onde o Puppet procura todos os diretórios de módulos e os carrega durante a inicialização.

Um caminho padrão razoável pode ser configurado como -

/etc/puppet/modules:/usr/share/puppet:/var/lib/modules.

Alternativamente, o diretório / etc / puppet pode ser estabelecido como um módulo anônimo especial, que é sempre pesquisado primeiro.

Nomenclatura de Módulo

O Puppet segue os mesmos padrões de nomenclatura de um módulo particular em que o nome do módulo deve ser palavras normais, correspondendo a [- \\ w +] (letra, palavra, número, sublinhado e travessões) e não contendo o separador de espaço de nomes:: ou /. Embora possa ser permitido em relação às hierarquias de módulo, para novos módulos não pode ser aninhado.

Organização Interna do Módulo

Quando o usuário cria um novo módulo no Puppet, ele segue a mesma estrutura e contém manifesto, arquivo distribuído, plug-ins e modelos organizados em uma estrutura de diretório específica, conforme mostrado no código a seguir.

MODULE_PATH/ 
   downcased_module_name/ 
      files/ 
      manifests/ 
         init.pp 
      lib/ 
         puppet/ 
            parser/ 
               functions 
            provider/ 
            type/ 
         facter/ 
      templates/ 
      README

Sempre que um módulo é criado, ele contém init.pparquivo de manifesto no local de correção especificado dentro do diretório de manifestos. Este arquivo de manifesto é um arquivo padrão que executa primeiro em qualquer módulo específico e contém uma coleção de todas as classes associadas a esse módulo específico. Adicional.ppO arquivo pode ser adicionado diretamente na pasta de manifestos. Se estivermos adicionando arquivos .pp adicionais, eles devem ter o nome da classe.

Um dos principais recursos obtidos com o uso de módulos é o compartilhamento de código. Um módulo por natureza deve ser autocontido, o que significa que se deve ser capaz de incluir qualquer módulo de qualquer lugar e soltá-lo no caminho do módulo, que é carregado quando o Puppet é inicializado. Com a ajuda de módulos, obtém-se modularidade na codificação da infraestrutura do Puppet.

Exemplo

Considere um módulo autofs que instala um mapa auto.homes fixo e gera o auto.master a partir de modelos.

class autofs { 
   package { autofs: ensure => latest } 
   service { autofs: ensure => running } 
   
   file { "/etc/auto.homes": 
      source => "puppet://$servername/modules/autofs/auto.homes" 
   } 
   file { "/etc/auto.master": 
      content => template("autofs/auto.master.erb") 
   } 
}

O sistema de arquivos terá os seguintes arquivos.

MODULE_PATH/ 
autofs/ 
manifests/ 
init.pp 
files/ 
auto.homes 
templates/ 
auto.master.erb

Consulta de Módulo

O Puppet segue uma estrutura predefinida em que contém vários diretórios e subdiretórios em uma estrutura definida. Esses diretórios contêm diferentes tipos de arquivos que são exigidos por um módulo para executar certas ações. Um pouco de mágica nos bastidores garante que o arquivo certo seja associado ao contexto certo. Todas as pesquisas de módulo estão dentro do modulepath, uma lista de diretórios separada por dois pontos.

Para referências de arquivo no servidor de arquivos, uma referência semelhante é usada para que uma referência a puppet: //$servername/modules/autofs/auto.homes resolva para o arquivo autofs / files / auto.homes no caminho do módulo.

Para tornar um módulo utilizável com o cliente de linha de comando e um fantoche mestre, pode-se usar uma URL do caminho de puppet: ///. ou seja, um URL sem um nome de servidor explícito. Esse URL é tratado ligeiramente diferente porPuppet e puppetd. O Puppet procura por URL sem servidor no sistema de arquivos local.

Os arquivos de modelo são pesquisados de maneira semelhante ao manifesto e aos arquivos: uma menção ao modelo (“autofs / auto.master.erb”) fará com que o puppetmaster procure primeiro um arquivo em $templatedir/autofs/auto.master.erb e depois autofs/templates/auto.master.erbno caminho do módulo. Com versões do Puppet de tudo sob o Puppet, ele está disponível para uso. Isso é chamado de carregamento automático do módulo. O Puppet tentará carregar automaticamente as classes e definições do módulo.