diff --git a/bericht/chef/chef-comparison.tex b/bericht/chef/chef-comparison.tex index becc796..decf0b5 100644 --- a/bericht/chef/chef-comparison.tex +++ b/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 -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 diff --git a/bericht/chef/chef-resume.tex b/bericht/chef/chef-resume.tex new file mode 100644 index 0000000..c3e12dc --- /dev/null +++ b/bericht/chef/chef-resume.tex @@ -0,0 +1,5 @@ +%TODO Resume und Ausblick +% welche Erkenntnisse wurden gewonnen +% Ansible, Salt. + + diff --git a/bericht/chef/chef-tests.tex b/bericht/chef/chef-tests.tex index 4241ec6..0777a63 100644 --- a/bericht/chef/chef-tests.tex +++ b/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 diff --git a/bericht/chef/chef.tex b/bericht/chef/chef.tex index 5234ea6..38d6caf 100644 --- a/bericht/chef/chef.tex +++ b/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