W marionetce, jak zatrzymać usługę, wykonać jakąś akcję, a następnie uruchomić usługę?

Question

Muszę wykonać pewne działanie (skonfigurować coś) po zatrzymaniu usługi tomcat. Po zakończeniu konfiguracji muszę się upewnić, że usługa tomcat została uruchomiona ponownie. Napisałem następujący kod lalkowy dla tego samego:

Service {'tomcat': ensure => stopped } 
-> 
class {'config':} 
-> 
Service {'tomcat': ensure => running } 

Na lalek zastosować, to narzekają, że

'Error: Duplicate declaration: Service[tomcat] is already declared in file'

Jak rozwiązać ten problem. Jaka jest recepta w marionetce, aby zatrzymać usługę, wykonać jakąś akcję, a następnie przywrócić usługę ponownie?

Answer 1

W marionetce nie można ponownie zgłosić tej samej usługi. to jest błąd, który masz.

Z marionetką nie musisz przejmować się procesami zatrzymywania/uruchamiania tomcat. Dba o ostateczny status (zwany "idemotencją"). Po zdefiniowaniu relacji między pakietem, plikami konfiguracyjnymi i usługami wykona on dla ciebie wszystkie zadania. Na przykład musisz zrozumieć poniższe procesy w lalce i różnice między -> i ~>.

Package['tomcat'] -> File['server.xml'] ~> Service['tomcat'] 

W twoim przypadku można zastosować zmianę w Tomcat pliku konfiguracyjnym i lalek będzie ponowne uruchomienie usługi tomcat automatycznie.

dla odniesienia, tutaj jest copy-paste z Introduction to Puppet blogu wyjaśnić, co to ma znaczyć idempotentność:

One big difference between Puppet and most other tools is that Puppet configurations are idempotent, meaning they can safely be run multiple times. Once you develop your configuration, your machines will apply the configuration often — by default, every 30 minutes — and Puppet will only make any changes to the system if the system state does not match the configured state.

Aktualizacja 2016:

Oto inny urzędnik Lalek blogu na idempotentność: https://puppet.com/blog/idempotence-not-just-a-big-and-scary-word

Answer 2

Nie jest to możliwe bezpośrednio w przypadku Puppet, ponieważ @BMW kończy się poprawnie. Jest jednak jeszcze kilka punktów do zapamiętania.

Istnieje kilka obiecujących work in progress, które dodadzą ograniczoną obsługę deklaracji stanu przejściowego. Jednak nie będzie to (przynajmniej w obecnym stanie alfa) umożliwiać wprowadzenie takiego stanu w ramach przygotowań do całej klasy i podczas jej stosowania.

Typowym sposobem obejścia tego rodzaju problemu jest zarządzanie danym podmiotem przy użyciu dwóch lub więcej zasobów. Typ exec jest dobrym rozwiązaniem, ponieważ może zarządzać praktycznie wszystkim. Oczywistą wadą jest to, że exec będzie musiał być dostosowany do twoich agentów (co wiesz - w końcu istnieje system lalkowy ;-). Zakładając, że manifest będzie dla jednej platformy tylko, to jest prosta:

exec { 
    'stop-tomcat': 
     command => 'service tomcat stop', 
     onlyif => 'service tomcat status', 
     before => [ 
      Class['config'], 
      Service['config'], 
     ], 
} 

zamawiania execprzedService['config'] jest zbędny (bo service wymaga class), ale jest to dobra praktyka, aby wyrazić, że service zasób powinien mieć ostateczny głos.