puppet vergleich überarbeitet
This commit is contained in:
parent
787d0ec2ec
commit
c987540949
@ -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
|
||||
ist das Ältere der beiden Projekte. Während das erste Puppetrelease bereits im
|
||||
Jahr 2005 von den Puppet Labs veröffentlicht wurde, erschien Chef erst 4 Jahre
|
||||
später im Jahre 2009. Chef wurde stark beeinflusst von Puppet. Der Erfinder von
|
||||
Chef Adam Jacob war selbst langjähriger Puppetnutzer, bevor er Chef schrieb.
|
||||
Seine damalige Konsultantfirma betreute mehrere Firmen bei der Provisionierung
|
||||
der Infrastruktur bis hin zum Deployment der Anwendung. Dabei kam Puppet zum
|
||||
Einsatz. Mit steigender Anzahl der Kunden, stieg nach Aussagen von Adam Jacob
|
||||
Ein ebenfalls weit verbreitetes Konfigurationsmanagmentsystem ist Puppet. Es ist
|
||||
das Ältere der beiden Projekte. Während das erste Puppetrelease bereits im Jahr
|
||||
2005 von den Puppet Labs veröffentlicht wurde, erschien Chef erst 4 Jahre später
|
||||
im Jahre 2009. Chef wurde stark von Puppet beeinflusst. Der Erfinder von Chef,
|
||||
Adam Jacob, war selbst langjähriger Puppetnutzer, bevor er Chef schrieb. Seine
|
||||
damalige Konsultantfirma betreute mehrere Firmen bei der Provisionierung der
|
||||
Infrastruktur bis hin zum Deployment der Anwendung. Dabei kam Puppet zum
|
||||
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
|
||||
\emph{Marionette}. Dabei verwendete ebenfalls wie schon bei Puppet die
|
||||
Programmiersprache Ruby zur Implementierung des Clients. Ein wichtiges
|
||||
Designziel seines neues System war es, bessere Abstraktionsmöglichkeiten zu
|
||||
schaffen, um so die Wiederverwendbarkeit zu erhöhen (Quelle:
|
||||
\cite{chefhistory}). Anzumerken ist, das seit der damals veröffentlichten
|
||||
begann er an ein neues Deploymentsystem zu schreiben. Damals trug es noch den
|
||||
Namen \emph{Marionette}. Dabei verwendete er ebenfalls, wie schon bei Puppet,
|
||||
die Programmiersprache Ruby zur Implementierung des Clients. Ein wichtiges
|
||||
Designziel seines neuen System war es, bessere Abstraktionsmöglichkeiten zu
|
||||
schaffen, um damit die Wiederverwendbarkeit zu erhöhen (Quelle:
|
||||
\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
|
||||
Problem zu adressieren.
|
||||
(\cite{puppetlanguagechangelog})
|
||||
neue Funktionen und Spracherweiterungen zu Puppet hinzugefügt wurden, um dieses
|
||||
Problem zu adressieren. (\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
|
||||
geschriebene und optimierte Sprache. Sie enthält häufig Elemente und Ausdrücke,
|
||||
welche es erlauben Probleme der Anwendungsdomain effizient zu lösen. Auf der
|
||||
anderen Seite wird auf umfangreiche Standardbibliotheken und Sprachkonstrukte
|
||||
verzichtet, die in General-Purpose-Language üblich sind. Puppets Sprache wurde
|
||||
Domain-Specific-Language (DSL). Eine DSL ist eine speziell für den
|
||||
Anwendungszweck geschriebene und optimierte Sprache. Sie enthält häufig Elemente
|
||||
und Ausdrücke, welche es erlauben, Probleme der Anwendungsdomain effizient zu
|
||||
lösen. Es wird häufig auf umfangreiche Standardbibliotheken und Sprachkonstrukte
|
||||
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
|
||||
\href{https://forge.puppetlabs.com/puppetlabs/stdlib}{Standartbibliothek} von
|
||||
Puppet stellt Funktionen, um auf diesen Datentypen einfache Operationen
|
||||
auszuführen. Allerdings ist es nicht möglich Schleifen auszuführen. (Diese
|
||||
Ausdrücke} und \emph{Hashes}. Diese können in Variablen gespeichert werden. Die
|
||||
\href{https://forge.puppetlabs.com/puppetlabs/stdlib}{Standardbibliothek} von
|
||||
Puppet stellt Funktionen bereit, um auf diesen Datentypen einfache Operationen
|
||||
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
|
||||
Rubykenntnisse in diesem Framework zu schulen. Andere wie bevorzugen die
|
||||
Flexibilität von Ruby. Facebook gab dies als einen der Gründe an, warum sie im
|
||||
Jahre 2013 von \emph{CFEngine2} auf \emph{Chef 11} umgestiegen sind
|
||||
greifen bevorzugt auf Puppet zurück, weil es einfacher ist, neue Mitarbeiter ohne
|
||||
Rubykenntnisse in diesem Framework zu schulen. Andere wiederum bevorzugen die
|
||||
Flexibilität von Ruby. Facebook gab dies als einen der Grund an für einen
|
||||
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
|
||||
Puppet-Module. Diese werden in der Community ausgetauscht und entwickelt. Da
|
||||
Puppet älter ist, ist zu erwarten das hierfür mehr Puppet-Module zu Verfügung
|
||||
stehen als für 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/modules?supported=yes}{Module} zu Verfügung
|
||||
Das strukturelle Gegenstück zu \emph{Cookbooks} in Chef ist das
|
||||
\emph{Puppet-Module} in Puppet. Diese werden in der Community entwickelt. Da
|
||||
Puppet älter ist, ist anzunehmen, dass hierfür mehr Puppet-Module zur Verfügung
|
||||
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/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}
|
||||
Modulen, (Stand: 31.03.2014 - ermittelt über die
|
||||
\href{http://community.opscode.com/}{Community-Seite} mit \textbf{1368} Modulen,
|
||||
(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
|
||||
``Chef'' und ``Puppet'' in der Suchmaschine auf Github herangezogen. Github filtert
|
||||
Forks (Abspaltungen) von Projekten aus den Suchergebnissen heraus und
|
||||
schlüsselt die Ergebnisse nach Programmiersprache auf. Es wurden alle
|
||||
Programmiersprachen in beide Projekte mit weniger als 100 Suchtreffer aus
|
||||
Übersichtlichkeitsgründen nicht in das in Diagramm übernommen (siehe Tabelle).
|
||||
Eine kurze Stichproben der Suchergebnisse, dass die Suchtreffer sich überwiegend
|
||||
mit den eigentlichen Projekten Chef und Puppet beschäftigen. Anzumerken ist, das
|
||||
Zielgruppe von Puppet eher Systemadminstratoren aus besteht, während Chef auch
|
||||
von vielen Entwicklern genutzt wird. Letztere verwenden bevorzugt Github.
|
||||
|
||||
\begin{figure}[H]
|
||||
Vergleich wurde die Anzahl der Suchtreffer für Projekte, die die Begriffe
|
||||
``Chef'' und ``Puppet'' in der Suchmaschine auf Github herangezogen. Github
|
||||
filtert Forks (Abspaltungen) von Projekten aus den Suchergebnissen heraus und
|
||||
schlüsselt die Ergebnisse nach Programmiersprache auf. Es wurden alle Sprachen
|
||||
in beiden Projekte mit weniger als 100 Suchtreffer aus Übersichtlichkeitsgründen
|
||||
nicht in das Diagramm übernommen (siehe Tabelle). Eine Stichproben der
|
||||
Ergebnisse, dass die Suchtreffer sich überwiegend mit den eigentlichen Projekten
|
||||
Chef und Puppet beschäftigen. Anzumerken ist, dass Zielgruppe von Puppet
|
||||
überwiegend Systemadminstratoren aus besteht, während Chef auch von vielen
|
||||
Entwicklern genutzt wird. Letztere verwenden bevorzugt Github.
|
||||
|
||||
\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
|
||||
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 & - & - \\
|
||||
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
|
||||
\textbf{Chef} & 9,902& - & 321 & 148 & 124 & 42 & 56 & 88 & - & 31 & 48& 37 \\\hline
|
||||
\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
|
||||
Subscriber auf den jeweiligen Mailinglisten.
|
||||
Eine weitere wichtige Statistik für Opensourceprojekte ist die Anzahl der
|
||||
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-dev@lists.opscode.com] Entwickler-Mailingliste, 652 Leser, \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[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 Abonnenten, \href{http://lists.opscode.com/sympa/info/chef-dev}{Quelle}, Stand: 31.03.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
|
||||
vergleichen. Sie ist neben dem Bugtracker ein wichtiges Mittel der
|
||||
Kommmunikation.
|
||||
Mailinglisten eignen sich, um qualitiv die aktiven Nutzer beider Projekte zu
|
||||
vergleichen. Neben dem Bugtracker ist stellt die Mailingliste ein wichtiges
|
||||
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
|
||||
Puppet-Module befinden. Jedes Manifest definiert eine \emph{Class} eingeleitet
|
||||
die auf den Suffix .pp enden und sich in dem Ordner \emph{manifests} im
|
||||
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
|
||||
mit Attributes ein vergleichbares Konzept. Allerdings werden Attributes
|
||||
im Kopfteil der Class deklariert und können Standardwerte besitzen. Chef besitzt
|
||||
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
|
||||
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).
|
||||
ebenfalls eingeführt. Class-Parameter werden automatisch in der \emph{Hieradb}
|
||||
gesucht und gegebenfalls überschrieben. Hiera-Attribute können spezifisch für
|
||||
einzelne Nodes oder für die gesamte Organisation gesetzt werden. 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
|
||||
Resources heissen in Puppet Types. Puppet liefert wie Chef bereits eine Reihe
|
||||
von Types mit. Diese werden Core-Types genannt. 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 einer Resource können in Puppet über das
|
||||
Setzen des Parameters \emph{ensure} festgelegt werden (vergleichbar mit \emph{action} in
|
||||
Chef).
|
||||
\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).
|
||||
|
||||
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.
|
||||
Ein weiteres häufig genutztes Pattern, um Resources zu gruppieren, ist der
|
||||
\emph{Defined-Type}. Dieser ist das Äquivalent zur aus Chef bekannte
|
||||
\emph{Definition}. Ein Defined-Type kann im Gegensatz zum Custom-Type auch
|
||||
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
|
||||
auf die Bibliothek \href{http://puppetlabs.com/facter}{Facter} zurückgriffen. In
|
||||
frühen Versionen von Chef wurde die gleiche Bibliothek verwendet, bevor später
|
||||
Vor der eigentlichen Provisionierung werden Informationen über das System zu
|
||||
gesammelt. Dabei wird auf die Bibliothek
|
||||
\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
|
||||
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
|
||||
Chef benutzt die gleiche Template-Syntax wie Puppet (eRuby). Der einzige
|
||||
Unterschied bei Chef ist die Funktion für verschiedene Plattformen und
|
||||
-versionen verschiedene Template-Varianten der gleichen Datei im Cookbook
|
||||
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
|
||||
Konfigurationsmanagment. Da manche Resources voneinander abhängen kann durch
|
||||
die Angabe der Parameter \emph{before} und \emph{require} die Reihenfolge
|
||||
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.
|
||||
Resources um. Bei Puppet spricht man von modelbasiertem Konfigurationsmanagment,
|
||||
während Chef ein \href{http://www.getchef.com/solutions/configuration-management/}{codebasiertes
|
||||
Konfigurationsmanagment} ist. Da manche Resources voneinander abhängen, kann durch die Angabe der
|
||||
Parameter \emph{before} und \emph{require} die Reihenfolge 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 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
|
||||
Mongrel als Applikationsserver empfohlen mit Nginx als Load-Balancer. Ein
|
||||
anderer beliebter Ansatz zum Skalieren größerer Cluster ist das Verwalten der
|
||||
nicht über einen CPU-Core. Für größere Installationen werden Passenger oder
|
||||
Mongrel als Applikationsserver empfohlen, wobei Nginx als Load-Balancer fungiert. Ein
|
||||
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:
|
||||
\cite{chefscale}). Für Puppet wurden keine verlässlichen Zahlen gefunden, wie
|
||||
viele Nodes pro Server betreut werden können. Allerdings ist anzunehmen, dass
|
||||
die Zahl architekturbedingt unter der von Chef liegt.
|
||||
vervierfacht haben und kann somit bis zu 10.000 Nodes bedienen (Quelle:
|
||||
\cite{chefscale}). Für Puppet wurden keine Statistiken gefunden, die eine Aussage
|
||||
darüber treffen, wieviele Nodes pro Server betreut werden können. Allerdings ist
|
||||
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,
|
||||
verschiedene Linuxderivate (Debian, Ubuntu, Redhat\ldots) und Solaris. Puppet
|
||||
Zu den, von offiziell von Chef unterstützten, Plattformen gehören Windows, MacOS X,
|
||||
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
|
||||
Grundkonzepte sind ähnlich, so das Anwender des einen Systems mit wenig Aufwand
|
||||
auch das andere System verstehen. Die beiden Firmen hinter den Produkten, Puppet
|
||||
Labs und Chef, stehen, enwickeln das Produkt stetig weiter und bieten
|
||||
kommerziellen Support. Während Puppet auf den klassischen Systemadminstrator
|
||||
abzielt, ist Chef ein Produkt der
|
||||
Zusammenfassend lässt sich feststellen, dass Chef und Puppet den gleichen
|
||||
Funktionsumfang bieten. Die Grundkonzepte sind ähnlich, so ein Anwender des
|
||||
einen Systems mit wenig Aufwand auch das andere System lernen kann. Die beiden
|
||||
Firmen, Puppet Labs und Chef, enwickeln beide ihr Produkt stetig weiter und
|
||||
bieten kommerziellen Support. Während Puppet auf den klassischen
|
||||
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
|
||||
|
||||
5
bericht/chef/chef-resume.tex
Normal file
5
bericht/chef/chef-resume.tex
Normal file
@ -0,0 +1,5 @@
|
||||
%TODO Resume und Ausblick
|
||||
% welche Erkenntnisse wurden gewonnen
|
||||
% Ansible, Salt.
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -4,5 +4,6 @@
|
||||
\input{chef/chef-comparison}
|
||||
\input{chef/chef-services}
|
||||
\input{chef/chef-tests}
|
||||
\input{chef/chef-resume}
|
||||
|
||||
\pagebreak
|
||||
|
||||
Loading…
Reference in New Issue
Block a user