chef: Vergleich abgeschlossen

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

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}
+}