chef-lctp/presentation/presentation.md

<a href="#" class="image navigate-down">
  <img src="/img/chef_logo.png" alt="Chef">
</a>

## Konfigurationsmanagement

von Jörg Thalheim, (Gruppe 4, Matrikel 3749175)

Dresden, 22 Januar #TODO aktualisieren


## Inhaltsübersicht

- Was ist Konfigurationsmanagement
- Was ist Chef/Puppet
- Einführung in Chef
- Testing
- Demo


## Was ist Konfigurationsmanagement?

- Konfigurationsmanagement
- Beispiele: Chef, Puppet, Salt, Ansible, CFEngine

<img src="/img/chef_logo.png" height="150" alt="Chef">:
<img src="/img/puppet_logo.png" height="150" alt="Puppet">
<img src="/img/saltstack_logo.jpg" height="150" alt="Salt">
<img src="/img/ansible_logo.png" height="150" alt="Ansible">
<img src="/img/cfengine_logo.jpg" height="150" alt="CFEngine">

Note:
- in der Praxis mehr Knoten
- wechselnde Admins
- Dokumentation veraltet schnell
- sowohl bestehende Knoten müssen aktuell gehalten werden,
  als auch neue eingerichtet
- Komplexe Shell-Skripte sind schlecht maintainbar,
  häufig nicht portable und langsam
- Problem wird durch Konfigurationsmanagements gelöst.
- Grundidee: Infrastruktur wird durch eine Konfigurationsdatei oder Sprache beschrieben
  und das Konfigurationsmanagement, versucht diesen Zustand herzustellen.
- Hier ein paar Beispiele, Im folgenden werde ich näher auf chef und Puppet
  eingehen.


## Was ist Chef/Puppet?

<table class="reveal">
<thead>
  <tr>
    <th>Kriterium</th>
    <th>Chef</th>
    <th>Puppet</th>
  </tr>
</thead>
<tbody>
  <tr>
    <th>Programmiersprache</th>
    <td>Ruby</td>
    <td>Ruby</td>
  </tr>
  <tr>
    <th>Konfigurationsprache</th>
    <td>Ruby</td>
    <td>eigene DSL (Ruby)</td>
  </tr>
  <tr>
    <th>Paradigma</th>
    <td>Prozedural</td>
    <td>Model-Driven</td>
  </tr>
  <tr>
    <th>Codezeilen</th>
    <td>108,726<sup>[1][1]</sup></td>
    <td>353,651<sup>[2][2]</sup></td>
  </tr>
  <tr>
    <th>Community</th>
    <td>11,270 Repositories auf Github<sup>[3][3]</sup></td>
    <td>13.020 Repositories auf Github<sup>[4][4]</sup></td>
  </tr>
  <tr>
    <th>kommerzieller Support</th>
    <td>&#10003;</td>
    <td>&#10003;</td>
  </tr>
</tbody>
</table>

[1]: https://www.ohloh.net/p/puppet
[2]: https://www.ohloh.net/p/chef
[3]: https://github.com/search?q=chef
[4]: https://github.com/search?q=puppet

Note:
- Beide Projekte sind in Ruby geschrieben.
- Chef: Die Konfigurations wird in Ruby geschrieben.
- Puppet: Benutzt eine auf Puppet optimierte, vereinfachte Sprache
  -> Wird von Anfängern und Nicht-Programmieren als einfacher empfunden
  -> Grund warum es von manchen Firmen bevorzugt wird um Umschulung zu sparen (mittlerweile nicht
  mehr komplett wahr, da Teile jetzt auch in Ruby geschrieben werden können)
  -> aber weniger flexible als Ruby (Grund bei Facebook, 10000 Nodes mit Chef
      provisionier)
- 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)
- Puppet: eigene Sprache -> komplexere Codebasis
- Um die Größe der Community abzuschätzen (schwierig): Suchtreffer für Repositories bei Github
- Alter(Puppet) > Alter(Chef)
- Hinter beiden Projekten stehen Firmen, welche das Produkt weiterpflegen,
  Support anbieten und Hosting anbieten


## Einführung in Chef


### Chef-Einführung: Grundbegriffe
  - Node, z.B.: node100.tu-dresden.de
  - Role, z.B.: headnode, ldap
  - Cookbook, z.B. slurm
  - Recipe, slurm::slurmctld oder slurm::slurmd
  - Resource, z.B.: package["slurm"], template["/etc/slurm.conf"], service["slurmctld"]

Note:
- Zunächst ein paar wichtige Begriffe:
- In chef sind viele Begriffe vom Kochen abgeleitet (daher auch chef - Koch)
- Jede Maschine wird in chef Node genannt.
- Nodes können Rollen zugewiesen werden, um welche bestimmte Aufgaben und
  Attribute zusammenfassen.
- Die grundlegende Verwaltungseinheit ist das cookbook. Ein cookbook
  beschreibt alles was eingerichtet und konfiguriert werden muss um eine bestimmte Aufgabe zu erledigen. z.B. dem Einrichten des
  Batchsystems slurm
- In einem cookbook können wiederum mehrere Recipies enthalten sein, um bestimmte
  Unteraufgaben zu erfüllen. So könnte im Falle von slurm, auf der Headnode das
  Recipe für den Slurm-Kontrolldaemon zugewiesen werden, während auf dem
  Computenodes jeweils ein slurmd eingerichtet wird.
- In einem Recipe werden wiederum verschiedene Resourcen beschrieben.
- chef überprüft, bei jeder Resource, ob diese in dem gewünchten Zustand ist.
  Dabei ist für jede Resource definiert, wie man vom aktuellen Zustand in den
  gewünschten Zustand kommt.
- Im Falle des Slurmctld könnten das z.B.:
    - das Packet slurm, welches installiert werden soll
    - die Konfiguration /etc/slurm.conf
    - der Dienst slurmctld, welcher gestartet werden soll.


### Chef-Einführung: Aufbau eines Cookbook
  - Attribute
  - Recipes
  - Templates
  - Definitions
  - Providers
  - Resources


### Chef-Einführung: Code-Beispiel


## Testing


## Demo