Cómo protegerse del estado chef-cliente de la última ejecución del bloque; no use el file de estado

descargo de responsabilidad : bastante nuevo para el chef y henetworkingé un montón de libros de cocina del chef. Los methods a continuación no son óptimos, pero es con lo que tengo que trabajar por ahora. Sé amable, por favor. 🙂 Además, por favor tengan paciencia conmigo cuando trato de describir lo que necesito.

Tenga en count que estamos utilizando chef-client 11.16.4. La actualización a 12.x, por ahora, no es una opción.

tl; dr ¿Hay alguna manera de especificar un guardia del estado del bloque en ejecución actual?

... only_if { this_block_did_something } notifies :run, 'bash[deploy-custom-docker-container]', :immediately 

DE ACUERDO….

Tome este pedazo de código en una receta que henetworkingé y necesito refactorizar un poco …

 # The identities of the innocent have been changed for their # protection. Please ignore odd things in this example: application app[:name] do path app[:deploy_path] enable_submodules true repository app[:repository] owner OWNER group GROUP symlinks({ "file.py" => "path/file.py" }) revision app[:branch] deploy_key data_bag_item('deployment_keys', 'keyname')['private_key'] end link "/path/to/file.py" do to "/path/to/settings-%s.py" % [file] end # This is where I need some direction...I think. # note that CMD is a valid constant and the custom docker # container does not follow any industry standard docker # conventions due to our strange use-case. So I had to resort # using a bash block to call our custom start/stop/restart script bash 'deploy-custom-docker-container' do code <<-EO #{CMD} restart EO # currently a subscribes but I've tried other methods which # don't achieve what I'm trying to accomplish subscribes :run, 'application[%s]' % [app[:name]] end 

La application app[:name] despliega el código fuente en el nodo de destino siempre que el repository tenga código nuevo para ser sincronizado. El bloque bash reinicia un contenedor acoplable estándar muy personalizado y no industrial que utiliza el código.

En su forma actual, que es indeseable, el bloque bash[deploy-custom-docker-container] siempre se ejecuta independientemente de si la application app[:name] tiene que implementar el código en un repository de git o no (el repository de IE está actualizado vs no actualizado) en el nodo de destino. Estoy seguro de que podría crear algún código que determine si el repository se actualizó, tocar un file de estado / locking y luego guard ejecución del bloque bash comprobando si ese file de locking existe. Para mí, esa sería una forma subóptima para lograr mi objective. Lo que sería óptimo es utilizar el estado de la actualización de chef como el método de configuration de la guardia. ¿¿Es eso posible?? Sigue leyendo …

En otras palabras, cuando se application app[:name] durante el time de ejecución chef-cliente, y se actualiza un repository (y se despliega en el nodo), chef-client informa los pasos de la application app[:name] implementando el nuevo código. Si no fue necesario actualizar el repository, chef-cliente felizmente se salta el bloque con un post "(actualizado)". Si el repository debe actualizarse, chef-cliente muestra los pasos necesarios para implementar el código. Así que chef-cliente conoce el estado del bloque de código que acaba de ejecutar.

Además, mis observaciones de cómo se ejecuta el chef-cliente en nuestro entorno me han demostrado que no importa si pongo un bloque de notifies en la application app[:name] para bash[deploy-custom-docker-container] o uso los subscribes método (pegado arriba); el bloque bash se ejecuta independientemente del estado de la application app[:name] . Preferiría que si la application app[:name] no tiene una actualización que realizar, entonces el bloque bash no se ejecuta.

Lo que me temo es que tendré que usar un file de estado para determinar el estado de la actualización del repository desde el bloque application app[:name] de la application app[:name] . Preferiría simplemente proteger el estado del time de ejecución desde la perspectiva del chef del bloque de la application app[:name] .

CÓDIGO FIJO

Como lo señalaron zts , mis action estaban equivocadas o faltaban. El siguiente código es lo que pude encontrar que resolvió mi problema.

 application app[:name] do ... notifies :run, 'link[%s]' % [filetolink], :immediately end link filetolink do to file notifies :run, 'bash[deploy-custom-docker-container]', :immediately end bash 'deploy-custom-docker-container' do code <<-EO #{CMD} restart EO action :nothing end 

Esto funciona para mí ahora.

Las notifications solo se activan si el recurso de notificación ha cambiado (y viceversa, las suscripciones solo se activan si el recurso al que se está suscribiendo ha cambiado).

La razón por la cual el bloque bash se ejecuta independientemente de la notificación es que, de manera pnetworkingeterminada, se ejecutarán los bloques bash. Si solo desea que se ejecute un recurso cuando se le notifica, asegúrese de include una action :nothing .

es decir:

 bash 'deploy-custom-docker-container' do code <<-EO #{CMD} restart EO action :nothing subscribes :run, 'application[%s]' % [app[:name]] end