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.

  • Come faccio a controllare se esiste un utente nel burattino?
  • La saggezza di 'server 127.127.1.0' in ntp.conf per i server virtuali
  • Migrare i clienti del burattino a un nuovo burattinaio
  • Le variables del burattino non sempre funzionano
  • Una stessa class / module / orwhateveritis più volte
  • Aggiornamento rolling con burattino, materiale o tessuto
  •  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?

    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.