Como escrever definições de fantoches reutilizáveis?

Question

Gostaria de escrever um manifesto de fantoches para instalar e configurar um aplicativo nos servidores de destino.

Partes deste manifesto serão reutilizáveis. Assim, usei define para definir minha funcionalidade reutilizável. Ao fazer isso, sempre tenho o problema de que há partes da definição que não são reutilizáveis.

Um exemplo simples é um monte de arquivos de configuração a serem criados. Esse arquivo deve ser colocado no mesmo diretório. Este diretório deve ser criado apenas uma vez.

Exemplo:

nodes.pp

node 'myNode.in.a.domain' {
  mymodule::addconfig {'configfile1.xml':
    param => 'somevalue',
  }
  mymodule::addconfig {'configfile2.xml':
    param => 'someothervalue',
  }
}

mymodule.pp

define mymodule::addconfig ($param) {

  $config_dir = "/the/directory/"

  #ensure that directory exits:
  file { $config_dir:
    ensure  => directory,
  }

  #create the configuration file:     
  file { $name:
    path    => "${config_dir}/${name}"
    content => template('a_template.erb'),
    require => File[$config_dir],
  }
}

Este exemplo irá falhar , porque agora o recurso file {$config_dir: é definido duas vezes.

Tanto quanto eu entendi, é necessário extrair essas partes em um class . Então parece com isso:

nodes.pp

node 'myNode.in.a.domain' {

  class { 'mymodule::createConfigurationDirectory':
  }

  mymodule::addconfig {'configfile1.xml':
    param => 'somevalue',
    require => Class ['mymodule::createConfigurationDirectory'],
  }
  mymodule::addconfig {'configfile2.xml':
    param => 'someothervalue',
    require => Class ['mymodule::createConfigurationDirectory'],
  }
}

Mas isso dificulta o uso da minha interface. Cada usuário do meu módulo tem que saber que há uma classe que é adicionalmente necessária. Para este caso de uso simples, a classe adicional pode ser aceitável. Mas com a crescente complexidade dos módulos (muitas definições) estou com um pouco de medo de confundir o usuário dos módulos.

Então, eu gostaria de saber se existe uma maneira melhor de lidar com essas dependências. Idealmente, classes como createConfigurationDirectory estão ocultas do usuário dos módulos api.

Ou existem outras "melhores práticas" / padrões que lidam com essas dependências?

    

Answer 1

Divida todas as funcionalidades em arquivos separados dentro do módulo, cada arquivo contendo uma classe ou tipo definido. Use recurso ordenação para gerenciar recursos na ordem correta.

Na sua definição de nó:

class {'mymodule':
  conffile => 'file_name',
}

No diretório de manifesto do seu módulo:

init.pp:

# This class does basic setup,
# and optionally allows you to define a config file
class mymodule ( $conffile = undef ) {
  include mymodule::confdir

  if $conffile {
    mymodule::conffile { $conffile: }
  }
}

params.pp:

# This class defines variables
class mymodule::params {
  $confdir = '/path/to/dir'
}

confdir.pp:

# This class creates a conf dir
class mymodule::confdir {
  include mymodule::params

  file { $mymodule::params::confdir:
    ensure = directory,
  }
}

conffile.pp:

# This define creates a config file
define mymodule::conffile($file=$title) {
  include mymodule::params

  file { "${mymodule::params::confdir}/${file}":
    ensure  => present,
    require => Class['mymodule::confdir'],
  }
}

    

Answer 2

É melhor se você puder retirar o diretório de configuração do define. Este é um exemplo

class def($config_dir) {
    file { $config_dir:
        ensure => directory
     }   
}

define def::template($file_location) {
     file { $file_location:
         path    => "${def::config_dir}/${file_location}",
         content => 'hi',
         require => Class['def'],
     }   
 }
if $fqdn == 'my_host' {
    class { 'def':
            config_dir => '/tmp/d1'
        }   
    def::template { 'f1.txt':
        file_location => "f1.txt"
    }   
    def::template { 'f2.txt':
        file_location => "f2.txt"
    }   
}

ls  /tmp/d1/
f1.txt  f2.txt