Burattino, impostazione delle dependencies

Sto cominciando a impostare il burattino. Voglio impostare una dipendenza che un agente di trasferimento di posta deve essere installato prima che la class tenta di installare o avviare qualsiasi cosa. Con il burattino, il metodo standard sembra impostare una dipendenza che sembra essere require blah . La sfida è che non utilizzo lo stesso MTA in tutti i miei sisthemes. Alcuni dei sisthemes che sono veri e propri server di posta ho un MTA completo (exim), ma la grande maggioranza dei miei sisthemes ha installato ssmtp. Quello che voglio fare è impostare un requisito in modo che uno di tali MTAs sia installato e funzionale prima che la class foo sia elaborata.

Ecco una configuration che dimostra in qualche modo ciò che sto cercando di fare.

 node default { if $fqdn in ["mail1.example.org", "mail2.example.org", "mail3.example.org"] { include fullmta # mailhub, and so on } else { include ssmtp # really basic send-only mta. } include foo # class that requries an mta be installed } class foo { require MTA # FIXME, A valid mta is required. package { foo: ensure => present, } ... # also a service, and some files, and so on... } 

Quindi, nella mia class foo, come faccio a richiedere che una delle classi MTA possibili sia stata elaborata?

  • Perché le variables pupazze non vengono assegnate dalle opzioni del puppet.facter di Vagrant?
  • come rendere i nostri server consapevoli dei nomi degli altri server nell'ambiente in Puppet
  • Posso utilizzare i caratteri jolly è pacchetto fantoccio assicurarsi di coprire più rilasciamenti
  • Come installare il module burattino da GitHub?
  • Come assicurare che l'istruzione «if» sia parsata prima di una determinata risorsa / class?
  • Come faccio a valutare una class non su each run di fantoccio?
  • L'imprevisto Puppet notifica l'ordine
  • Perché alcuni file di configuration r10k iniziano le loro linee YAML con:?
  • 3 Solutions collect form web for “Burattino, impostazione delle dependencies”

    Se si divide la logica MTA in una class separata, è ansible gestire la logica esistente e le risorse possono richiedere alla class MTA di applicare la relazione di dipendenza.

     node default { include mta include foo # class that requries an mta be installed } class mta { if $fqdn in ["mail1.example.org", "mail2.example.org", "mail3.example.org"] { include fullmta # mailhub, and so on } else { include ssmtp # really basic send-only mta. } } class foo { package { foo: ensure => present, require => Class['mta'], } ... # also a service, and some files, and so on... } 

    Utilizza un alias. Qualcosa come questo:

     service { "ssmtp": ... alias => "MTA", } service { "fullmta": ... alias => "MTA", } class foo { package { foo: ensure => present, require => Service["mta"], ... } ... } 

    È ansible specificare le dependencies require come arrays, nel qual caso Puppet assicurerà che tutte le dependencies siano soddisfatte prima di procedere. In questa situazione generalmente faccio qualcosa come il seguente:

     node default { include mta include foo # class that requries an mta be installed } class mta { if $fqdn in ["mail1.example.org", "mail2.example.org", "mail3.example.org"] { package { "conflicting-package-A": ensure => present, } package { "conflicting-package-B": ensure => absent, } } else { package { "conflicting-package-A": ensure => absent, } package { "conflicting-package-B": ensure => present, } } } class foo { package { foo: ensure => present, require => [Package["conflicting-package-A", "conflicting-package-B"], } ... # also a service, and some files, and so on... } 

    In questo modo, non solo assicurati che il pacchetto foo sia esplicitamente dipendente da entrambi gli altri pacchetti, ma hai impostato le cose in modo che se si rimuove un host dall'elenco di mail*.example.org in futuro, quel "pacchetto in conflitto -A "verrà sostituito automaticamente con" conflitto-pacchetto-B ".

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.