puppet vergleich überarbeitet

bericht/chef/chef-comparison.tex

@@ -228,82 +228,80 @@ Mechanismus genutzt um Tests auszuführen.
 
 \subsubsection{Vergleich mit puppet}
 \label{vergleich_mit_puppet}
-Ein anderes weiteres verbreitetes Konfigurationsmanagmentsystem ist Puppet. Es
+Ein ebenfalls weit verbreitetes Konfigurationsmanagmentsystem ist Puppet. Es ist
-ist das Ältere der beiden Projekte. Während das erste Puppetrelease bereits im
+das Ältere der beiden Projekte. Während das erste Puppetrelease bereits im Jahr
-Jahr 2005 von den Puppet Labs veröffentlicht wurde, erschien Chef erst 4 Jahre
+2005 von den Puppet Labs veröffentlicht wurde, erschien Chef erst 4 Jahre später
-später im Jahre 2009. Chef wurde stark beeinflusst von Puppet. Der Erfinder von
+im Jahre 2009. Chef wurde stark von Puppet beeinflusst. Der Erfinder von Chef,
-Chef Adam Jacob war selbst langjähriger Puppetnutzer, bevor er Chef schrieb.
+Adam Jacob, war selbst langjähriger Puppetnutzer, bevor er Chef schrieb.  Seine
-Seine damalige Konsultantfirma betreute mehrere Firmen bei der Provisionierung
+damalige Konsultantfirma betreute mehrere Firmen bei der Provisionierung der
-der Infrastruktur bis hin zum Deployment der Anwendung. Dabei kam Puppet zum
+Infrastruktur bis hin zum Deployment der Anwendung. Dabei kam Puppet zum
-Einsatz. Mit steigender Anzahl der Kunden, stieg nach Aussagen von Adam Jacob
+Einsatz. Mit steigender Anzahl der Kunden, wuchs nach Aussagen von Adam Jacob
 der Aufwand bei der Verwaltung der Puppet-Konfiguration. Diese mussten häufig
 für jeden Kunden stark angepasst oder neugeschrieben werden. Aus diesem Grund
-began er an ein neues Deploymentsystem zu schreiben, damals unter dem Namen
+begann er an ein neues Deploymentsystem zu schreiben. Damals trug es noch den
-\emph{Marionette}. Dabei verwendete ebenfalls wie schon bei Puppet die
+Namen \emph{Marionette}. Dabei verwendete er ebenfalls, wie schon bei Puppet,
-Programmiersprache Ruby zur Implementierung des Clients. Ein wichtiges
+die Programmiersprache Ruby zur Implementierung des Clients. Ein wichtiges
-Designziel seines neues System war es, bessere Abstraktionsmöglichkeiten zu
+Designziel seines neuen System war es, bessere Abstraktionsmöglichkeiten zu
-schaffen, um so die Wiederverwendbarkeit zu erhöhen (Quelle:
+schaffen, um damit die Wiederverwendbarkeit zu erhöhen (Quelle:
-\cite{chefhistory}). Anzumerken ist, das seit der damals veröffentlichten
+\cite{chefhistory}). Anzumerken ist, dass seit der damals veröffentlichten
 Puppetversion
 (\href{https://github.com/puppetlabs/puppet/commit/ce964ecb6d6a38cb7fb9f0b13a7e6b2eb4c381c3}{0.24.5})
-neue Funktionen und Spracherweiterungen zu Puppet hinzugefügt wurden um dieses
+neue Funktionen und Spracherweiterungen zu Puppet hinzugefügt wurden, um dieses
-Problem zu adressieren.
+Problem zu adressieren. (\cite{puppetlanguagechangelog})
-(\cite{puppetlanguagechangelog})
 
 Während bei Chef die Konfiguration in Ruby geschrieben wird, besitzt Puppet
 seine eigene Konfigurationssprache. Puppets Sprache ist im Gegensatz zu
 General-Purpose-Languages wie Ruby, Java oder C/C++ eine
-Domain-Specific-Language (DSL). Eine DSL ist eine eigens für den Anwendungszweck
+Domain-Specific-Language (DSL). Eine DSL ist eine speziell für den
-geschriebene und optimierte Sprache. Sie enthält häufig Elemente und Ausdrücke,
+Anwendungszweck geschriebene und optimierte Sprache. Sie enthält häufig Elemente
-welche es erlauben Probleme der Anwendungsdomain effizient zu lösen. Auf der
+und Ausdrücke, welche es erlauben, Probleme der Anwendungsdomain effizient zu
-anderen Seite wird auf umfangreiche Standardbibliotheken und Sprachkonstrukte
+lösen. Es wird häufig auf umfangreiche Standardbibliotheken und Sprachkonstrukte
-verzichtet, die in General-Purpose-Language üblich sind. Puppets Sprache wurde
+verzichtet, die in General-Purpose-Languages üblich sind. Puppets Sprache wurde
 an das Konfigurationsformat der Überwachungssoftware Nagios angelehnt
 (\cite{puppetlanguage}). Sie ist deklarativ gehalten und soll möglichst einfach
 erlernbar für Administratoren, auch ohne programmiertechnischen Hintergrund,
 sein. Der Schwerpunkt liegt auf der Beschreibung von \emph{Resources}. Die
 Sprache besitzt Kontrollstrukturen wie Case- und If-Statements. Es gibt
 Datentypen wie \emph{Strings}, \emph{Booleans}, \emph{Arrays}, \emph{Reguläre
-Ausdrücke} und \emph{Hashes}, welche Variablen zugewiesen werden können. Die
+Ausdrücke} und \emph{Hashes}. Diese können in Variablen gespeichert werden. Die
-\href{https://forge.puppetlabs.com/puppetlabs/stdlib}{Standartbibliothek} von
+\href{https://forge.puppetlabs.com/puppetlabs/stdlib}{Standardbibliothek} von
-Puppet stellt Funktionen, um auf diesen Datentypen einfache Operationen
+Puppet stellt Funktionen bereit, um auf diesen Datentypen einfache Operationen
-auszuführen.  Allerdings ist es nicht möglich Schleifen auszuführen. (Diese
+auszuführen.  Allerdings ist es nicht möglich, Schleifen auszuführen. (Diese
 \href{http://docs.puppetlabs.com/puppet/latest/reference/experiments_lambdas.html}{Funktion}
-ist momentan als experimental markiert). Funktionen können nicht direkt in
+ist momentan als \emph{experimental} markiert). Funktionen können nicht direkt in
 Puppets Sprache definiert werden. Stattdessen werden diese als Erweiterung des
-Parsers in Ruby implementiert, was wiederum den den Nachteil hat, dass dafür
+Parsers in Ruby implementiert, was wiederum den Nachteil hat, dass dafür
 eine weitere Sprachen erlernt werden muss. Manche Unternehmen und Organisationen
-greifen bevorzugt auf Puppet zurück, weil es einfacher ist neue Mitarbeiter ohne
+greifen bevorzugt auf Puppet zurück, weil es einfacher ist, neue Mitarbeiter ohne
-Rubykenntnisse in diesem Framework zu schulen. Andere wie bevorzugen die
+Rubykenntnisse in diesem Framework zu schulen. Andere wiederum bevorzugen die
-Flexibilität von Ruby. Facebook gab dies als einen der Gründe an, warum sie im
+Flexibilität von Ruby. Facebook gab dies als einen der Grund an für einen
-Jahre 2013 von \emph{CFEngine2} auf \emph{Chef 11} umgestiegen sind
+Umstieg im Jahre 2013 von \emph{CFEngine2} auf \emph{Chef 11}
 \cite{facebooklikeschef}.
 
-Das strukturelle Äquivalent zu \emph{Cookbooks} in Chef ist in Puppet das
+Das strukturelle Gegenstück zu \emph{Cookbooks} in Chef ist das
-Puppet-Module. Diese werden in der Community ausgetauscht und entwickelt. Da
+\emph{Puppet-Module} in Puppet. Diese werden in der Community entwickelt. Da
-Puppet älter ist, ist zu erwarten das hierfür mehr Puppet-Module zu Verfügung
+Puppet älter ist, ist anzunehmen, dass hierfür mehr Puppet-Module zur Verfügung
-stehen als für Cookbooks für Chef. Die primäre Distributionsquelle ist
+stehen, als Cookbooks für Chef. Die primäre Distributionsquelle ist
-\href{https://forge.puppetlabs.com/}{Puppet Forge} in dem \textbf{2206}
+\href{https://forge.puppetlabs.com/}{Puppet-Forge}, in dem \textbf{2206}
-\href{https://forge.puppetlabs.com/modules?supported=yes}{Module} zu Verfügung
+\href{https://forge.puppetlabs.com/modules?supported=yes}{Module} zur Verfügung
 stehen (Stand: 31.03.2014). Für Chef gibt es eine ähnliche
-\href{http://community.opscode.com/}{Community-Seite} mit \textbf{1368}
+\href{http://community.opscode.com/}{Community-Seite} mit \textbf{1368} Modulen,
-Modulen, (Stand: 31.03.2014 - ermittelt über die
+(Stand: 31.03.2014 - ermittelt über die
 \href{https://cookbooks.opscode.com/api/v1/cookbooks?start}{API}). Zu einer
 weiteren wichtigen Quelle hat sich die Plattform
 \href{https://github.com}{Github} für beide Projekte entwickelt. Für einen
-Vergleich wurde die Anzahl der Suchtreffer für Projekte, die die Suchbegriffe
+Vergleich wurde die Anzahl der Suchtreffer für Projekte, die die Begriffe
-``Chef'' und ``Puppet'' in der Suchmaschine auf Github herangezogen. Github filtert
+``Chef'' und ``Puppet'' in der Suchmaschine auf Github herangezogen. Github
-Forks (Abspaltungen) von Projekten aus den Suchergebnissen heraus und
+filtert Forks (Abspaltungen) von Projekten aus den Suchergebnissen heraus und
-schlüsselt die Ergebnisse nach Programmiersprache auf. Es wurden alle
+schlüsselt die Ergebnisse nach Programmiersprache auf. Es wurden alle Sprachen
-Programmiersprachen in beide Projekte mit weniger als 100 Suchtreffer aus
+in beiden Projekte mit weniger als 100 Suchtreffer aus Übersichtlichkeitsgründen
-Übersichtlichkeitsgründen nicht in das in Diagramm übernommen (siehe Tabelle).
+nicht in das Diagramm übernommen (siehe Tabelle).  Eine Stichproben der
-Eine kurze Stichproben der Suchergebnisse, dass die Suchtreffer sich überwiegend
+Ergebnisse, dass die Suchtreffer sich überwiegend mit den eigentlichen Projekten
-mit den eigentlichen Projekten Chef und Puppet beschäftigen. Anzumerken ist, das
+Chef und Puppet beschäftigen. Anzumerken ist, dass Zielgruppe von Puppet
-Zielgruppe von Puppet eher Systemadminstratoren aus besteht, während Chef auch
+überwiegend Systemadminstratoren aus besteht, während Chef auch von vielen
-von vielen Entwicklern genutzt wird. Letztere verwenden bevorzugt Github.
+Entwicklern genutzt wird. Letztere verwenden bevorzugt Github.
-
-\begin{figure}[H]
 
+\begin{figure}[h]
 \pgfplotstableread{
   %Gesamt Puppet   Ruby   Shell  Python Javascript Perl
 12661   0        9902   321    148    124        42
@@ -317,7 +315,7 @@ von vielen Entwicklern genutzt wird. Letztere verwenden bevorzugt Github.
 \begin{axis}[ybar,
         width=\textwidth,
         enlarge x limits=0.5,
-        height=15cm,
+        height=10cm,
         ymin=0,
         ymax=17000,
         scaled x ticks = false,
@@ -350,100 +348,105 @@ von vielen Entwicklern genutzt wird. Letztere verwenden bevorzugt Github.
 \end{axis}
 \end{tikzpicture}
 \caption{Anzahl der Suchtreffer auf Github aufgeschlüsselt nach
-Programmiersprache für die Begriffe ``Chef'' und ``Puppet''}
+Programmiersprache für die Begriffe ``Chef'' und ``Puppet''.}
 \end{figure}
 
-Rohdaten für das Diagramm
+\begin{table}[h]
-
+\caption{Rohdaten für das Diagramm}
 \begin{tabular}{l|c|c|c|c|c|c|c|c|c|c|c|c}
-Sprache  & Ruby & Puppet & Shell & Python & Javascript & Perl & PHP & Java & VimL & CSS & C & C++ \\\hline
+  Sprache & \textbf{Ruby} & \textbf{Puppet} & \textbf{Shell} & \textbf{Python} & \textbf{Javascript} & \textbf{Perl} & \textbf{PHP} & \textbf{Java} & \textbf{VimL} & \textbf{CSS} & \textbf{C} & \textbf{C++} \\\hline 
-  Chef   & 9,902&    -   & 321   & 148    & 124        & 42   & 56  & 88   & -    & 31  & 48& 37  \\\hline
+  \textbf{Chef}  & 9,902&    -   & 321   & 148    & 124        & 42   & 56  & 88   & -    & 31  & 48& 37  \\\hline
-  Puppet & 3,108& 7,315  & 751   & 207    & 157        & 137  & 82  & 42   & 64   & 23  & - & -   \\
+  \textbf{Puppet} & 3,108& 7,315  & 751   & 207    & 157        & 137  & 82  & 42   & 64   & 23  & - & -   \\
 \end{tabular}
+\end{table}
 
 \vspace{0.5cm}
 
-Eine andere wichtige Statistik für Opensourceprojekte ist die Anzahl der
+Eine weitere wichtige Statistik für Opensourceprojekte ist die Anzahl der
-Subscriber auf den jeweiligen Mailinglisten.
+Abonnenten auf den jeweiligen Mailinglisten.
 
 \begin{description}
-  \item[chef@lists.opscode.com] Community-Mailingliste, 1620 Leser, \href{http://lists.opscode.com/sympa/info/chef}{Quelle}, Stand: 31.03.2014
+  \item[chef@lists.opscode.com] Community-Mailingliste, 1620 Abonnenten, \href{http://lists.opscode.com/sympa/info/chef}{Quelle}, Stand: 31.03.2014
-  \item[chef-dev@lists.opscode.com] Entwickler-Mailingliste, 652 Leser, \href{http://lists.opscode.com/sympa/info/chef-dev}{Quelle}, Stand: 31.03.2014
+  \item[chef-dev@lists.opscode.com] Entwickler-Mailingliste, 652 Abonnenten, \href{http://lists.opscode.com/sympa/info/chef-dev}{Quelle}, Stand: 31.03.2014
-  \item[puppet-users@googlegroups.com] Community-Mailingliste, \textasciitilde{}7000 Leser, Quelle: \href{https://twitter.com/puppetlabs/status/450760644329881600}{Anfrage per Twitter}, Stand: 01.04.2014
+  \item[puppet-users@googlegroups.com] Community-Mailingliste,
+    \textasciitilde{}7000 Abonnenten, Quelle: \href{https://twitter.com/puppetlabs/status/450760644329881600}{Anfrage per Twitter}, Stand: 01.04.2014
 \end{description}
 
-Mailinglisten eigenen sich um qualitiv die aktive Nutzer beider Projekte zu
+Mailinglisten eignen sich, um qualitiv die aktiven Nutzer beider Projekte zu
-vergleichen. Sie ist neben dem Bugtracker ein wichtiges Mittel der
+vergleichen.  Neben dem Bugtracker ist stellt die Mailingliste ein wichtiges
-Kommmunikation.
+Kommunikationsmittel dar.
 
 Die Zahlen weisen darauf hin, dass Puppet nach wie vor eine größere Community
 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
+die auf den Suffix .pp enden und sich in dem Ordner \emph{manifests} im
-Puppet-Module befinden. Jedes Manifest definiert eine \emph{Class} eingeleitet
+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
+``bar'' enthält, ist der Name der Class ``foo::bar''. Eine Ausnahme 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}).
+referenzieren (anstelle von \emph{init.pp} lautet die Datei \emph{default.rb}).
 Allerdings werden in Recipes keine separaten Objekt definiert und der ganze
 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
+im Kopfteil der Class deklariert und können Standardwerte besitzen. Chef besitzt
-mit Attributes ein vergleichbares Konzept.  Allerdings werden Attributes
+mit \emph{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
+Die Attributes stehen somit allen Recipes zu Verfügung 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
+ebenfalls eingeführt. Class-Parameter werden automatisch in der \emph{Hieradb}
-und gegebenfalls überschrieben.  Hiera-Attribute können spezifisch für einzelne
+gesucht und gegebenfalls überschrieben.  Hiera-Attribute können spezifisch für
-Nodes gesetzt werden oder für die gesamte Organisation. In älteren Versionen von
+einzelne Nodes oder für die gesamte Organisation gesetzt werden. In älteren
-\emph{Puppet} wurden Attributes und Module für die einzelnen Nodes in der
+Versionen von \emph{Puppet} wurden Attributes und Module für die einzelnen Nodes
-zentralen \emph{site.pp}-Manifest verwaltet. Hiera ersetzt die \emph{site.pp}
+in der zentralen \emph{site.pp}-Manifest verwaltet. Hiera ersetzt die
-weitest gehend. Durch die Funktion \emph{hiera\_include} können Classes im
+\emph{site.pp} weitest gehend. Durch die Funktion \emph{hiera\_include} können
-Hiera-Backend gesetzt werden (ähnlich der Run-List in Chef).
+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 heissen in Puppet Types. Puppet liefert wie Chef bereits eine Reihe
-Resources/Types, die Core-Types. Wie auch in Chef können Types in Puppet mehrere
+von Types mit. Diese werden Core-Types genannt. Wie auch in Chef können Types in
-plattformspezifische Provider besitzen. Es ist möglich eigene Types zu
+Puppet mehrere plattformspezifische Provider besitzen. Es ist möglich, eigene
-definieren, auch Custom-Types genannt (Ähnlich LRWP in Chef). Die
+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 einer Resource können in Puppet über das
+\emph{lib/puppet}. Die Zustände einer Resource können in Puppet über das Setzen
-Setzen des Parameters \emph{ensure} festgelegt werden (vergleichbar mit \emph{action} in
+des Parameters \emph{ensure} festgelegt werden (vergleichbar mit \emph{action}
-Chef).
+in Chef).
 
-Ein anderes häufig genutztes Pattern, um Resources zu gruppieren, ist die auch
+Ein weiteres häufig genutztes Pattern, um Resources zu gruppieren, ist der
-schon aus Chef bekannte \emph{Definition}. Diese kann im Gegensatz zum
+\emph{Defined-Type}. Dieser ist das Äquivalent zur aus Chef bekannte
-Custom-Type auch direkt in der Puppet-Sprache mit Schlüsselwort \emph{define}
+\emph{Definition}. Ein Defined-Type kann im Gegensatz zum Custom-Type auch
-definiert werden.
+direkt in der Puppet-Sprache mit dem Schlüsselwort \emph{define} erstellt
+werden.
 
-Um zu Beginn Informationen über das zu provisionierende System zu sammeln, wird
+Vor der eigentlichen Provisionierung werden Informationen über das System zu
-auf die Bibliothek \href{http://puppetlabs.com/facter}{Facter} zurückgriffen. In
+gesammelt. Dabei wird auf die Bibliothek
-frühen Versionen von Chef wurde die gleiche Bibliothek verwendet, bevor später
+\href{http://puppetlabs.com/facter}{Facter} zurückgegriffen. In frühen Versionen
+von Chef wurde die gleiche Bibliothek verwendet, bevor später
 \href{http://docs.opscode.com/ohai.html}{Ohai} integriert wurde.
 
-Chef benutzt die gleiche Template-Syntax wie Puppet (eRuby). Einziger
+Chef benutzt die gleiche Template-Syntax wie Puppet (eRuby). Der einzige
-Unterschied bei Chef ist die Funktion für verschiedene
+Unterschied bei Chef ist die Funktion für verschiedene Plattformen und
-Plattformen/Plattformversionen verschiedene Templatevarianten der selben Datei
+-versionen verschiedene Template-Varianten der gleichen Datei im Cookbook
-im Cookbook vorzuhalten. Die Varianten werden durch Unterordner im
+vorzuhalten. Die Varianten werden durch Unterordner im Verzeichnis
 \emph{templates/} unterschieden (z.B. \emph{templates/windows} oder
 \emph{templates/ubuntu-12.04}). Falls kein der Plattform entsprechende Ordner
-existiert fällt Chef auf \emph{templates/default} zurück.
+existiert sucht Chef im Verzeichnis \emph{templates/default}.
 
 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
+Resources um. Bei Puppet spricht man von modelbasiertem Konfigurationsmanagment,
-Konfigurationsmanagment.  Da manche Resources voneinander abhängen kann durch
+während Chef ein \href{http://www.getchef.com/solutions/configuration-management/}{codebasiertes
-die Angabe der Parameter \emph{before} und \emph{require} die Reihenfolge
+Konfigurationsmanagment} ist. Da manche Resources voneinander abhängen, kann durch die Angabe der
-festgelegt werden. Über die Parameter \emph{notify} und \emph{subscribe} können
+Parameter \emph{before} und \emph{require} die Reihenfolge festgelegt werden.
-darüber hinaus Resourcen aktualisiert werden, wenn sich eine Abhängigkeit
+Über die Parameter \emph{notify} und \emph{subscribe} können darüber hinaus
-geändert hat (z.B. kann ein Dienst neugestartet werden, wenn sich die dazu
+Resourcen aktualisiert werden, wenn sich eine Abhängigkeit geändert hat (z.B.
-gehörige Konfiguration verändert hat). In Chef kann Letzeres über die Paramether
+kann ein Dienst neugestartet werden, wenn sich die dazu gehörige Konfiguration
-\emph{notifies} und \emph{subscribes} angegeben werden.
+verändert hat). In Chef kann Letzeres über die Parameter \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
@@ -451,31 +454,33 @@ mit dem Befehl \emph{puppet apply} ein lokales Manifest geladen werden
 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
+nicht über einen CPU-Core. Für größere Installationen werden Passenger oder
-Mongrel als Applikationsserver empfohlen mit Nginx als Load-Balancer. Ein
+Mongrel als Applikationsserver empfohlen, wobei Nginx als Load-Balancer fungiert. Ein
-anderer beliebter Ansatz zum Skalieren größerer Cluster ist das Verwalten der
+ 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, soll sich dabei
-vervierfacht haben auf bis zu 10.000 Nodes pro Server (Quelle:
+vervierfacht haben und kann somit bis zu 10.000 Nodes bedienen (Quelle:
-\cite{chefscale}). Für Puppet wurden keine verlässlichen Zahlen gefunden, wie
+\cite{chefscale}). Für Puppet wurden keine Statistiken gefunden, die eine Aussage
-viele Nodes pro Server betreut werden können. Allerdings ist anzunehmen, dass
+darüber treffen, wieviele Nodes pro Server betreut werden können. Allerdings ist
-die Zahl architekturbedingt unter der von Chef liegt.
+anzunehmen, dass die Anzahl der  Server, bedingt durch die genutzte Architektur,
+kleiner ist als bei Chef.
 
-Zu den von offiziell von Chef unterstützt Plattformen gehören Windows, MacOS X,
+Zu den, von offiziell von Chef unterstützten, Plattformen gehören Windows, MacOS X,
-verschiedene Linuxderivate (Debian, Ubuntu, Redhat\ldots) und Solaris. Puppet
+verschiedene Linuxderivate (Debian, Ubuntu, Redhat, \ldots) und Solaris. Puppet
 bietet breiteren Support und unterstützt zusätzlich Free- und OpenBSD sowie
 HP-UX und AIX.
 
-Chef und Puppet bieten den gleichen Funktionsumfang. Die darunter liegenden
+Zusammenfassend lässt sich feststellen, dass Chef und Puppet den gleichen
-Grundkonzepte sind ähnlich, so das Anwender des einen Systems mit wenig Aufwand
+Funktionsumfang bieten. Die Grundkonzepte sind ähnlich, so ein Anwender des
-auch das andere System verstehen. Die beiden Firmen hinter den Produkten, Puppet
+einen Systems mit wenig Aufwand auch das andere System lernen kann. Die beiden
-Labs und Chef, stehen, enwickeln das Produkt stetig weiter und bieten
+Firmen, Puppet Labs und Chef, enwickeln beide ihr Produkt stetig weiter und
-kommerziellen Support. Während Puppet auf den klassischen Systemadminstrator
+bieten kommerziellen Support. Während Puppet auf den klassischen
-abzielt, ist Chef ein Produkt der
+Systemadminstrator abzielt, ist Chef ein Produkt der
 \href{http://www.getchef.com/solutions/devops/}{DevOps}-Bewegung, bei welcher
-adminstrative Teil einer Organisation stärker Entwicklung verzahnt wird.
+der (operative) adminstrative Teil einer Organisation stärker mit der
+Entwicklung verzahnt wird.
 
 % vim: set spell spelllang=de_de

bericht/chef/chef-resume.tex

@@ -0,0 +1,5 @@
+%TODO Resume und Ausblick
+% welche Erkenntnisse wurden gewonnen
+% Ansible, Salt.
+
+

bericht/chef/chef-tests.tex

@@ -139,6 +139,4 @@ Fehler werden in der Regel schon von den Provider erkannt und festgestellt.
 Minitest-Handler kann dies Erweitern um protokollspezifische Tests durchzuführen
 oder das Testen von Funktionalität bestimmter Dienste.
 
-TODO Resume und Ausblick
-
 % vim: set spell spelllang=de_de

bericht/chef/chef.tex

@@ -4,5 +4,6 @@
 \input{chef/chef-comparison}
 \input{chef/chef-services}
 \input{chef/chef-tests}
+\input{chef/chef-resume}
 
 \pagebreak