chef-lctp/presentation/presentation.md

279 lines
8.4 KiB
Markdown
Raw Normal View History

2014-01-22 09:30:19 +00:00
<a href="#" class="image navigate-down">
<img src="/img/chef_logo.png" alt="Chef">
</a>
2014-02-03 21:59:11 +00:00
## Konfigurationsmanagement
2014-01-22 09:30:19 +00:00
von Jörg Thalheim, (Gruppe 4, Matrikel 3749175)
2014-02-03 21:59:11 +00:00
Dresden, 22 Januar #TODO aktualisieren
2014-01-22 09:30:19 +00:00
## Inhaltsübersicht
- Was ist Konfigurationsmanagement
2014-02-03 21:59:11 +00:00
- Was ist Chef/Puppet
2014-01-27 15:08:01 +00:00
- Einführung in Chef
- Testing
2014-01-22 09:30:19 +00:00
- Demo
2014-01-27 15:08:01 +00:00
## Was ist Konfigurationsmanagement?
2014-01-27 15:08:01 +00:00
2014-02-03 21:59:11 +00:00
- Konfigurationsmanagement
- Beispiele: Chef, Puppet, Salt, Ansible, CFEngine
2014-02-11 19:33:32 +00:00
<img src="/img/chef_logo.png" height="150" alt="Chef">:
2014-02-03 21:59:11 +00:00
<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?
2014-02-03 21:59:11 +00:00
<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>
2014-02-03 21:59:11 +00:00
</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
2014-02-11 19:33:32 +00:00
### Chef-Einführung: Grundbegriffe
- Node, z.B.: node100.tu-dresden.de
2014-02-11 19:33:32 +00:00
- 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"]
2014-02-11 19:33:32 +00:00
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
```bash
▾ modules-0.2.0/
▾ attributes/
default.rb
▾ files/
▾ default/
modules-load.conf
modules-load_header
▸ libraries/
▾ providers/
default.rb
multi.rb
▾ recipes/
config.rb
default.rb
install_attributes.rb
▾ resources/
default.rb
multi.rb
▾ templates/
▾ default/
modules.conf.erb
metadata.json
metadata.rb
Rakefile
README.md
```
Note:
- Hier ein Beispiel, wie ein cookbook aufgebaut ist.
- modules cookbook: Linux Kernel Module nachladen, maintained auf github
- Verzeichnisstruktur vorgeben - Vorteil man findet sich in neuen Cookbooks
sofort zu recht
- Für das entwickeln: Editor mit Verzeichnisfunktion empfohlen
- hier nochmal kurz ein paar wichtige Verzeichnisse:
- attributes: setzt Standartwerte für das Cookbook, können von Roles/Nodes
oder anderen Cookbooks überschrieben werden
- resourcen & providers: Chef liefert schon eine Menge sinnvoller Resourcen
mit, man kann in seinem cookbooks weitere erstellen, in diesem Fall -
modules resource mit der man in anderen cookbooks bestimmte kernel module laden
kann
2014-02-15 19:14:07 +00:00
- recipies: enthält die genannten Recipies, wenn man nichts an gibt wird die
default.rb geladen
2014-02-15 19:14:07 +00:00
- files: Im files-Verzeichnis können statische Konfigurations-Dateien abgelegt werden
- templates: meistens jedoch will Konfigurationsdateien dynamisch
2014-02-15 19:14:07 +00:00
generieren - dazu mit Templates man mithilfe mit der Markupsprache ERB generieren,
vergleichbar mit erzeugen von Webseiten, gleich ein Beispiel dazu
2014-02-11 19:33:32 +00:00
### Chef-Einführung: Code-Beispiel
2014-02-15 19:14:07 +00:00
```ruby
# attributes/default.rb
default.ntp.server = "de.pool.ntp.org"
2014-02-16 19:22:16 +00:00
default.ntp.subnets = ["::1", "127.0.0.1"]
2014-02-15 19:14:07 +00:00
```
```ruby
# recipies/default.rb
package 'ntp'
template "/etc/ntp.conf" do
owner "root"
group "root"
source "ntp.conf.erb"
notifies :restart, "service[ntp]"
end
2014-02-16 19:22:16 +00:00
service "ntp" do
action [:enable, :start]
end
2014-02-15 19:14:07 +00:00
```
```ruby
# templates/default/ntp.conf.erb
# Crontab for <%= @node.name %> managed by Chef. Changes will be overwritten.
server <%= @node.ntp.server %>
restrict default noquery nopeer
<% @node.ntp.subnets.each do |net| -%>
restrict <%= net %>
<% end -%>
driftfile /var/lib/ntp/ntp.drift
```
2014-02-11 19:33:32 +00:00
2014-02-16 19:22:16 +00:00
Note:
- das beliebte Hello-World für Provisionierungssysteme: Einrichten eines
NTP-Servers
- Hier ein Beispiel, welches ich für die Abschlussaufgabe geschrieben habe
- attribute: In der Attribute-Datei - Standwerte für ntp: upstream server,
subnets auf dem ntp lauscht
- recipe:
- package: Packet per apt installieren
- template: Konfiguration aus template generieren - hier Abhängigkeiten
zwischen Resourcen, wenn Template sich ändert -> NTP neustarten
- zum Schluss den Dienst aktivieren und starten
- template:
- Beispiel für ERB-Template
- Tags -> Ruby-Code, wird interpoliert
- Verzweigungen und Schleifen möglich
2014-02-11 19:33:32 +00:00
## Testing
2014-02-16 19:22:16 +00:00
```
require_relative '../spec_helper'
describe 'ntp::default' do
let(:chef_run) do
ChefSpec::Runner.new do |node|
node.set["ntp"]["subnets"] = ["::1", "127.0.0.1", "172.28.128.0 mask 255.255.255.0 nomodify notrap nopeer"]
end.converge(described_recipe)
end
it "should setup ntp" do
chef_run.should install_package("ntp")
chef_run.should render_file("/etc/ntp.conf").with_content("172.28.128.0")
end
end
```
Note:
- Infrastruktur: schwierig zu testen, viele externe Abhängigkeiten, langsam
- Ruby: dynamische Programmiersprache -> Tippfehler, keine Compilerwarnung beim
Refactoring
2014-02-11 19:33:32 +00:00
## Demo