diff --git a/bericht/chef/chef-comparison.tex b/bericht/chef/chef-comparison.tex index 7cfda2a..435cdca 100644 --- a/bericht/chef/chef-comparison.tex +++ b/bericht/chef/chef-comparison.tex @@ -379,41 +379,89 @@ hat. Anstelle von Recipes werden in Puppet Manifests geschrieben. Das sind Dateien, die auf Endung .pp enden und sich in dem Ordner \emph{manifests} im -Puppet-Module befinden. Jedes Manifest definiert eine \emph{Class}. Der Namen -dieser Klasse wird aus dem Module-Namen und Manifest-Namen gebildet. Wenn Module -``foo'' das Manifest ``bar'' enthält, ist der Name der Class ``foo::bar''. -Außnahme bildet das Manifest \emph{init.pp}, bei dem die Class nur ``bar'' -lauten würde. Diese Benennungskonvention wurde in Chef übernommen, um Recipes zu +Puppet-Module befinden. Jedes Manifest definiert eine \emph{Class} eingeleitet +durch das Schlüsselwort \emph{class}. Der Namen dieser Klasse wird aus dem +Module-Namen und Manifest-Namen gebildet. Wenn das Module ``foo'' das Manifest +``bar'' enthält, ist der Name der Class ``foo::bar''. Außnahme bildet das +Manifest \emph{init.pp}, bei dem die Class nur ``bar'' lauten würde. Diese +Benennungskonvention wurde in Chef übernommen, um Recipes in Cookbooks zu referenzieren (anstelle von \emph{init.rb} lautet die Datei \emph{default.rb}). Allerdings werden in Recipes keine seperaten Objekt definiert und der ganze -Inhalt der Datei bildet das Recipe. Eine Class in Puppet kann über Parameter -konfiguriert werden. Chef besitzt mit Attributes ein vergleichbares Konzept. -(TODO) Resources heissen in Puppet Types. Puppet liefert wie Chef eine Reihe von +Inhalt der Datei bildet das Recipe. + +Eine Class in Puppet kann über Parameter konfiguriert werden. Parameter werden +im Kopfteil der Class deklariert und können Standartwerte besitzen. Chef besitzt +mit Attributes ein vergleichbares Konzept. Allerdings werden Attributes +getrennt von den Recipes definiert und sie werden dem Node-Objekte zugewiesen. +Die Attributes stehen somit allen Recipes zu Verfügung können und können an +verschiedenen Stellen überschrieben werden. In Puppet 3 wurde diese Trennung +von Code und organsationsspezifischen Daten durch die Erweiterung \emph{Hiera} +ebenfalls eingeführt. Class-Parameter werden automatisch in der hieradb gesucht +und gegebenfalls überschrieben. Hiera-Attribute können spezifisch für einzelne +Nodes gesetzt werden oder für die gesamte Organisation. In älteren Versionen von +\emph{Puppet} wurden Attributes und Module für die einzelnen Nodes in der +zentralen \emph{site.pp}-Manifest verwaltet. Hiera ersetzt die \emph{site.pp} +weitest gehend. Durch die Funktion \emph{hiera\_include} können Classes im +Hiera-Backend gesetzt werden (ähnlich der Run-List in Chef). + +Resources heissen in Puppet Types. Puppet liefert wie Chef eine Reihe von Resources/Types, die Core-Types. Wie auch in Chef können Types in Puppet mehrere plattformspezifische Provider besitzen. Es ist möglich eigene Types zu definieren, auch Custom-Types genannt (Ähnlich LRWP in Chef). Die Implementierung der Types/Provider erfolgt in Ruby im Verzeichnis -\emph{lib/puppet}. Die Zustände eine Resources können in Puppet über das -Schlüsselwort \emph{ensure} festgelegt werden (vergleichbar mit \emph{action} +\emph{lib/puppet}. Die Zustände einer Resource können in Puppet über das +Setzen des Parameters \emph{ensure} festgelegt werden (vergleichbar mit \emph{action} in Chef). -%- Definition -%- Parameters -%- Trennung von Daten/Code -%- Chef-Server/Puppetd-Master (masterless-Mode, Erlang) -%- Templates -%- Plattform-Unterstützung +Ein anderes häufig genutztes Pattern, um Resources zu gruppieren, ist die auch +schon aus Chef bekannte \emph{Definition}. Diese kann im Gegensatz zum +Custom-Type auch direkt in der Puppet-Sprache mit Schlüsselwort \emph{define} +definiert werden. +Chef benutzt die gleiche Template-Syntax wie Puppet (eRuby). Einziger +Unterschied bei Chef ist die Funktion für verschiedene +Plattformen/Plattformversionen verschiedene Templatevarianten der selben Datei +im Cookbook vorzuhalten. Die Varianten werden durch Unterordner im +\emph{templates/} unterschieden (z.B. \emph{templates/windows} oder +\emph{templates/ubuntu-12.04}). Falls kein der Plattform entsprechende Order +existiert fällt Chef auf \emph{templates/default} zurück. -%- Während die Regeln und Beschreibung in Chef standartmäßig in der Reihenfolge abgearbeitet -% wird in der sie geladen werden, sortiert Puppet diese um. In beiden kann die -% Reihenfolge durch Spezifikation von Abhängigkeiten umsortiert werden (Später -% ein Beispiel) -% -%Note: -%- Puppet: eigene Sprache -> komplexere Codebasis -%- Chef Enterprise vs Puppet Enterprise: Hinter beiden Projekten stehen Firmen, Weiterentwicklung des Produkt, bieten Support und Hosting an -%- Resume: Ähnliche Projekte, lösen das gleiche Problem auf unterschiedliche -% Weise +Ein wesentlicher Unterschied zwischen Puppet und Chef ist die Reihenfolge der +Ausführung von Resources. Chef überprüft die Resources in der Reihenfolge, in +der sie in der Run-List und in den Recipes geladen werden. Puppet sortiert +Resources um. Bei Puppet deswegen spricht man von modelbasiertem +Konfigurationsmanagment. Da manche Resources voneinander kann durch die Angabe +von Abhängigkeiten mittels der Parameter \emph{before} und \emph{require} +festgelegt werden. Über die Parameter \emph{notify} und \emph{subscribe} können +darüber hinaus Resourcen aktualisiert werden, wenn sich eine Abhängigkeit +geändert hat (z.B. kann ein Dienst neugestartet werden, wenn sich die dazu +gehörige Konfiguration verändert hat). In Chef kann Letzeres über die +Paramether \emph{notifies} und \emph{subscribes} angegeben werden. + +Wie auch Chef bietet Puppet verschiedene Betriebsmodi. Im einfachsten Fall wird +mit dem Befehl \emph{puppet apply} ein lokales Manifest geladen werden +(vergleichbar mit Chef-Solo). Das Äquivalent zu Chef-Server ist der +Puppetmaster, zu welchem sich der Client \emph{Puppetd} verbindet und mittels +SSL-Zertifikaten authentifiziert. In der Standarteinstellung setzt Puppetmaster +auf den verhältnismäßig einfachen Webserver WEBrick. Dieser skaliert allerdings +nicht über einen CPU-Core. Für größere Installationen wird Passenger oder +Mongrel als Applikationsserver empfohlen mit Nginx als Load-Balancer. Ein +anderer beliebter Ansatz zum Skalieren größerer Cluster ist das Verwalten der +Manifeste in einem Git-Repository, wobei Puppet periodisch über einen Cron-Job +aufgerufen wird und die ausgecheckten Manifeste ausführt. Während Chef-Server +bis zur Version 10 wie Puppet-Master in Ruby geschrieben war, wurde der API-Teil von +Chef-Server wurde in Version 11 in der Programmiersprache Erlang neugeschrieben. +Die Zahl der Nodes, die von einem Server bedient werden können soll vervierfacht +haben auf bis zu 10.000 Nodes pro Server (Quelle: \cite{chefscale}). Für Puppet +wurden keine verlässlichen Zahlen gefunden, wieviel Nodes pro Server betreut +werden können. Allerdings ist anzunehmen, dass die Zahl architekturbedingt unter +der von Chef liegt. + +Zu den von offiziell von Chef unterstützt Plattformen gehören Windows, MacOS X, +verschiedene Linuxderivate (Debian, Ubuntu, Redhat...) und Solaris. Puppet +bietet breiteren Support und unterstützt zusätzlich Free- und OpenBSD sowie +HP-UX und AIX. + +%- Resume: Ähnliche Projekte, lösen das gleiche Problem auf unterschiedliche Weise % vim: set spell spelllang=de_de diff --git a/bericht/sources.bib b/bericht/sources.bib index e6edfbb..b2bb9c9 100644 --- a/bericht/sources.bib +++ b/bericht/sources.bib @@ -37,3 +37,11 @@ year = {2014}, month = {März} } + +@misc{chefscale, + author = {chef}, + title = {Opscode Unleashes New Generation of Chef}, + url = {http://www.getchef.com/press-releases/opscode-unleashes-new-generation-of-chef/}, + year = {2013}, + month = {Februar} +}