Inzwischen arbeite ich über ein halbes Jahr mit Opscode Chef und mag den Chef gar nicht mehr missen. Für den DevOp von Welt sind solche Automatisierungstools einfach dermaßen hilfreich. Selbstverständlich kann man da auch vieles verkehrt machen, aber mit etwas Gangnam Style als Best Practice bekommt man das mit den wiederverwendbaren Cookbooks gut hin. Eine Sache ist mir aber neulich auf die Füße gefallen, nämlich ein vorhandenes Template in einem Cookbook, das ich nicht verwenden wollte. Leider waren auch keine Möglichkeiten vorgesehen, das Verhalten durch das Setzen von Attributen zu verändern.
Wirklich schade – was nun? Das Template einfach durch Definition einer eigenen Datei zu übersteuern hat den unschönen Nebeneffekt, dass die Konfigdatei bei jedem Chef Lauf 2x neu geschrieben wird und der betreffende Dienst neu startet. Das Cookbook zu forken ist auch eher unschön. Auf Stackoverflow habe ich dann aber etwas gefunden, das einem erlaubt, die Definition der Templatedatei zu übersteuern – auch nicht schön, aber übergangsweise eine Möglichkeit, bis der Autor hoffentlich entsprechende Anpassungen am Cookbook vornimmt.
Das ganze funktioniert dann (hier mit dem Elasticsearch Cookbook) so:
#include elasticsearch include_recipe 'elasticsearch::default' # override logging.yml template... dirty HACK :) begin r = resources(:template => "logging.yml") r.source "elasticsearch/logging.yml.erb" r.cookbook "esc" rescue Chef::Exceptions::ResourceNotFound Chef::Log.warn "could not find template logging.yml to override!" end
Hinweis: „esc“ ist das eigene Cookbook in dem dann in templates/default/elasticsearch eine angepasste logging.yml.erb liegt…
Warum will man dies denn überhaupt tun? In unserem Fall ist es so, dass wir Logfiles mit logrotate rotieren und die logging.yml dieses Cookbooks die Elasticsearch Logs nachts nur umbennent, aber weder packt noch löscht. Daher wollten wir ganz normale Logfiles die wir selbst rotieren können, und dafür musste die logging.yml angepasst werden.
