Also mein Name ist Benedikt Treftzer, ich werde euch heute etwas über Systemkonfiguration mit Puppet erzählen. Ich bin Schweizer, das hört man, ich weiss es, bitte entschuldigt alle Helvetismen,

wenn ihr irgendwas nicht versteht, dann sagt es mir und ich werde versuchen das zu übersetzen. Auch sonst während des Vortrags, es ist so, dass ich diverse Sachen nur kurz anschneiden werde, ich möchte gerne eine Vogelperspektive einnehmen und euch so verschiedene Hinweise geben, deshalb fragen bitte auch gleich an der Stelle wo

sie auftreten. Beruflich bin ich die Cedax GmbH, wir machen Puppet Trainings, wir machen Puppet Consultancy, Contractwork, haben verschiedene Open Source Puppet Module, die ich

maintaine, außerdem Open Stack Cloud und Linux Open Source etc. Nun, Software Konfigurationsmanagement, wer von euch setzt Puppet schon ein?

Ok, das sind einige, wer setzt auf irgendein anderes Konfigurationsmanagement, wie Ansible, CFEngine, Chef, Salt? Ok, und wer setzt noch überhaupt nichts ein? Ok, doch ein, ja dann ist es ziemlich gemischt. Also, ich habe da schon gesagt, Puppet ist eine Möglichkeit, Ansible das nächst

berühmtere wahrscheinlich, etwas ältere sind CFEngine, Chef, Salt, mittlerweile gibt es noch andere, die sich das auf die Fahne geschrieben haben, um Systeme zu konfigurieren. Aber wir sprechen jetzt von Puppet und ich habe mir erlaubt, auch immer gerade

noch die Definition, die Namen, die Puppet verwendet hinzustreiben. Also, Puppet managt die Konfiguration eines Computers, ein Computer im Puppet-Sinn ist immer ein Node, also wenn ich von einem Node spreche, dann meine ich

eigentlich einfach einen Computer, einen Server, eine virtuelle Maschine etc. Puppet hat eine deklarative Sprache, die beschreibt, was auf dem Computer sein soll. Es beschreibt nicht die Befehle, die notwendig sind, um etwas zu installieren,

sondern es beschreibt, wie das die Konfiguration sein soll. Das Ganze wird gespeichert in Puppet-Manifests, also eigentlich in Code. Oder in Hiera als Datenbank, da kommen wir nachher auch noch drauf.

Wenn ein Puppet dran losgeht, also man muss verstehen, es gibt einen Puppet-Server, es gibt einen Puppet-Agent, wenn ein Puppet dran geht, dann heisst das der Agent, also der dasjenige Teil, das konfiguriert werden soll, das holt sich die Informationen vom Puppet-Server.

Als erstes wird aber der Node, also der Server, der konfiguriert werden soll, wird gewisse Fakten an den Server schicken, beispielsweise, was habe ich für ein Betriebssystem, wer bin ich, wie viel Memory habe ich, und so weiter, so verschiedene Fakten.

Und aufgrund von dem wird der Server nachher ein Manifest zusammenstellen. Das heisst, er wird zusammenstellen, das musst du installiert haben, das ist das, was nachher auf dem Computer rennen soll. Das wird nachher auf das Zielsystem gegeben, also auf den Computer, den ich konfigurieren

wollte, und dann dort ausgeführt. Das Ganze können wir auch grafisch darstellen. Wir haben oben den Node, also das ist der Computer, der eigentlich konfiguriert werden soll, den gibt es im Normalfall mehrfach, nicht in der gleichen Ausführung,

aber in verschiedenen Ausführungen, den gibt es mehrfach. Und wir haben unten den Puppet Server hier, das ist derjenige, der das Ganze verwaltet. Unten seht ihr, der Puppet Server bezieht seine Informationen, was das er machen soll, aus drei verschiedenen Datenbanken.

Das eine ist das Manifest, das ist der Code, dann haben wir die HERA-Daten, und wir haben noch den Report Collector, oder die Puppet DB. Schauen wir nachher alle im Detail genau an, was das die beinhalten und wie das die zusammenspielen.

Wir haben in grün da die verschiedenen Sachen, die ablaufen, wir haben zuerst als erster Schritt die Facts, die der Node an den Puppet Server schickt, wir haben das Query der Konfiguration, also der Puppet Server, der da hier die Konfiguration zusammenstellt, als drittens der Katalog, der zurückgeht, der nachher angewendet wird, und als letzten

Schritt der Report, also der Node, reportiert dann, was er jetzt gemacht hat, was hat er verändert, was war nicht so wie verlangt, der meldet das, und der Puppet Server wird den Report nachher in der Puppet DB abspeichern.

Das ist so grundlegend, was alles abgeht. Ihr seht, ich habe oben diese zwei SSL Schlüssel hingemacht, das heisst alle Kommunikation da ist SSL verschlüsselt, Puppet hat eine Certification Authority, also auch die

Authentifizierung des Nodes auf dem Server, auf dem Server basiert auf Zertifikaten. Das hat den Vorteil, dass man diese Zertifikate auch noch für anderes brauchen kann. Also beispielsweise in meiner Umgebung werde ich damit auch Isinga-Authentifizierung machen,

so dass sich ein Node beim Isinga Server mit dem anmelden kann. Oder auch für das Mail-Verschicken verwende ich auch das Puppet-Zertifikat, dass jeder Node, der ein Puppet-Zertifikat hat, automatisch E-Mails quasi spammen darf, was er sonst nicht dürfte.

Gut, jetzt gehen wir als erstes auf diesen Code ein, also die Puppet-Manifeste. Puppet habe ich bereits gesagt, deklarative Sprache, und beschreibt, wie ein System

am Schluss aussehen soll. Also ihr beschreibt nicht, legen wir einen User an, sondern ihr beschreibt, ich will einen User so haben. Das Ganze geht auf den Server, und dort wird es dann gemacht.

Genau, das habe ich eigentlich schon gesagt. Ein Beispiel, und das ist jetzt wirklich eine Puppet-Resource, ein Stück Code im Puppet, wenn ich jetzt einen Benutzer James Bond anlegen wolle, dann sage ich, der

User dort existiert, also Ensure Present, könnte jetzt hier auch sagen Ensure Absent, dann würde sichergestellt, dass der User nicht besteht, ich habe einen Comment, eine User-ID, eine Shell, eine Home, das ich mit angeben kann.

Und das kann ich jetzt auf jeglichen Betriebssystemen so verwenden, also ich kann es auf einem OpenBSD so laufen lassen, ich kann es auf einem Debian so laufen lassen, ich kann es auf einem Windows so laufen lassen. Der einzige Unterschied, wo man dran denken muss, ist, dass je nachdem die Daten

etwas anders sind, beispielsweise bei einem Windows habe ich vielleicht keinen WinBash, dann muss ich das entsprechend anpassen. Aber das grundlegende Gerüst, das funktioniert so überall. Das ist der Platform-agnostic-Way, das heisst, ich kann den gleichen Code

für alle Plattformen, die Puppet supportet, verwenden. Und ich sage nicht, welches Kommando ausgeführt werden soll.

Genau, und das Ganze, wenn ihr da noch etwas mehr reingeht, was das nachher im Code umgewandelt wird, das nennt sich dann der Provider. Also es gibt einen Provider, die besagen, wie das man etwas ausführen soll.

Ja, das wäre mal der erste Schritt hier bei den Manifests beim Code. Ich komme nachher nochmal hier auf den Code zurück, wenn wir über Module sprechen. Ich möchte jetzt aber zuerst weitergehen hier zu den Jera-Daten und euch mal kurz Jera etwas näher bringen, was das genau ist.

Das hat mittlerweile einen sehr hohen Stellenwert. Das war in den frühen Puppet-Versionen war das noch nicht so wichtig oder es gab es noch gar nicht. Mittlerweile macht man eigentlich fast alles mit dem. Jera ist eigentlich eine Key-Value-Datenbank.

Also ich frage einen Wert von irgendetwas ab. Das ist das Grundlegende. Die Daten sind hierarchisch geordnet. Also ich habe verschiedene Dateien und in diesen Dateien lege ich diese Daten ab.

Die Idee ist, dass sich den Code, also was, das sich alles zusammen frickeln will, trennen kann von wohin oder wie konfiguriere ich es jetzt im Detail. Also das Pfade und Dateinamen etc. Das mache ich im Jera drin und die Logik, die lege ich im Code ab.

Das ist die Idee dahinter, dass ich wirklich Code und Daten trennen kann. Mittlerweile ist Jera vollständig im Puppet drin, also jegliche Versionen nach 5 beinhalten Jera fix drin. Das war vorher nicht so, in der Version 4 und 3 war das ein Addon, dass man

speziell noch dazunehmen musste. Jera ermöglicht auch mit E-Yaml verschlüsselte Daten, da kommen wir nachher noch kurz darauf. Es gibt auch noch verschiedene Merge Behaviors.

Also ich habe jetzt gesagt, man kann eine Wert abfragen. Man kann auch mehrere Werte abfragen, kommen wir auch noch mal darauf zurück. Auch zu den Lookup Options, da gehe ich nicht ins Detail. Und man kann auch manuell auf dem Puppet Server Abfragen machen, um zu

schauen, was würde der Client nachher für Daten erhalten. Ja, jetzt wie funktioniert das? Das war jetzt etwas theoretisch, jetzt machen wir mal da ein Beispiel. Ich habe da eine Infrastruktur mal aufgebaut, wie sie irgendwo sein

könnte. Wir haben auf der obersten Zeile 7 Nodes, also 7 Server-Maschinen und die heißen Node 1, 2, 3, 4, 5, 6, 7. Die sind alle in verschiedenen Domains drin, also es gibt die Domain Production Example, Integration Example und Test Example.

Wir haben Debian und Red Hat Systeme und wir haben so gewisse Daten, die kommen für alle gelten. Und die Idee ist jetzt, wenn ich einen Node habe, beispielsweise der Node 1, dann gibt es so einen Pfad dadurch, der mir sagt, woher ich

die Daten nehmen soll. Also der Node 1, der hat das Domain Production Example CH, ist ein Red Hat System und die kommen da hin. Das heißt, wenn Jero jetzt eine Abfrage macht, dann beginnt er oben beim Node und sagt, ok, ich suche den Wert für x, hast du den?

Wenn er den hat, dann nimmt er den. Wenn er den nicht hat, dann fragt er Production Example CH und schaut in dem Fall nach, gibt es den Wert für x? Gibt es ihn? Ok, nehme ich ihn, gibt es ihn nicht, nehme ich ihn nicht. Weil es ein Red Hat System ist, frage ich als nächstes, Red Hat, wenn ich es

noch nicht gefunden habe, wenn ich es dort auch nicht finde, dann ist es vielleicht im Common, wenn es im Common auch nicht ist, dann gebe ich zurück, ich weiss es nicht. Das ist das grundlegende Vorgehen, wie Jera Daten sucht.

Also für den Node 5, in Integration Example, CH, geht er den Wert, wenn das ein Debian ist und nimmt nachher die Zeit kommen. Es ist keine Hexerei dahinter, aber wichtig, dass ihr das verstanden habt, weil das kann man jetzt noch verkomplizieren.

Jetzt schauen wir mal, woher er denn nimmt, was er isst. Das sind die Facts, ich habe oben in orange Farbe geschrieben, wie das auf dem Node jeweils beschrieben wird, was für ein System ich bin. Das nennt sich Facts, es gibt ein Fact, Trusted Certname, das ist der Name des

Zertifikats, das ich verwendet habe, um mich am Puppet Server anzumelden. Puppet Server ist eine CA, stellt Zertifikate aus, das heisst, dem kann ich auch vertrauen, wenn ich nicht Autosigning mache, aber macht man

normalerweise auch nicht, normalerweise sagt man dann explizit, ja, ich möchte dir dieses Zertifikat geben. Ich habe ein Fact Domain, das besagt mir, in welchem Domain das ist, und ich habe ein Facts OS Family, das mir sagt, was für ein Betriebssystem das ich

am Laufen habe. Das ist das, was auf dem Node quasi vorhanden ist, und mit dem startet der Puppet Server nachher die Abfrage. Ich schreibe dann eine Konfigurationsdatei auf dem Puppet Server, die besagt, wie diese Hierarchie aufgebaut ist.

Und da seht ihr jetzt, in der obersten Zeile habe ich die Per-Node-Data. Das sind diese Daten, die in der obersten Zeile, dort Node 1, 2, 3, 4, 5, 6, 7 sind, und die Abfrage ist dann im Verzeichnis Nodes und das TrustedCertname.yaml.

Das entspricht wieder dem dort oben, dem Trusted-Anführungsnamen-Certname. Das heisst, ich schreibe nachher pro Node eine Datei in das File-System, eine Yaml-Datei, wo ich diese Werte reinschreibe.

Das selbe mit der nächsten Zeile, mit der Domain, mit dem OS, also dem Operating System, mit OS Family, und am Schluss das Common. Das ergibt mir die Dateistruktur, und das ist die Information, wie, dass ich diese Dateistruktur abfrage.

Soweit so klar. Machen wir ein Beispiel. Ich habe jetzt nur drei Optionen mit Nodes, OS, Family und Common. Die Domain habe ich jetzt mal weggenommen und ich habe jedes dieser Kästchen,

ist quasi eine Datei auf dem Dateisystem. Kommentiert seht ihr, wo das abgespeichert wird. Also das oberste, der Node 1, der hat nur einen Wert definiert, Color, die Farbe grün.

Der Node 2 hier, 3, 4, OS, Family und Common. Wenn ich jetzt frage, welche Farbe hat der Node 2, dann gehe ich als erstes hier zum Node 2 und sehe, ah, City, Drinks, ok, das weiss es nicht. Dann schaue ich, ok, es ist ein Red Hat System, ok, der weiss es auch nicht.

Ja gut, dann gehe ich ins Common und sage, also die Farbe ist blau. Und so kann ich jetzt für jeden Wert durchgehen, jede Abfrage so durchspielen. Und bekomme dann den entsprechenden Konfigurationswert zurück.

Soweit so klar. Ja, komme ich gerade dazu. Ja, ich komme gleich zu den Listen, das war die Frage, die Listen.

Ich komme gleich dazu. Das ist wirklich der nächste Satz. Genau, Listen. Also bis jetzt haben wir da nur irgendwelche Stringwerte. Aber ich kann natürlich auch Listen so abfragen. Per Default, also im Standard, funktioniert das genau gleich.

Das heisst, ich habe hier eine Liste Drinks. Wenn ich die Liste Drinks abfrage für den Node 2, dann bekomme ich den Wert vom Node 2 zurück. Also Coffee und Tea.

Und er hat es gefunden, also ist fertig. Das ist der Standardweg. Es gibt aber noch eine Möglichkeit, dass ich im Jera drin Lookup Options für spezielle Werte definieren kann. Da habe ich jetzt kein Beispiel dazu, aber ich kann jetzt hier beispielsweise im Common sagen,

alles was Drinks sind möchte ich nicht, dass er den ersten Wert nimmt, den er gefunden hat, sondern kombiniere mir alle Werte, die du findest in der Hierarchie. Das heisst, in dem Falle würde nachher Drinks für den Node 2 nicht Coffee und Tier geben,

sondern Coffee, Tea, wenn sein Debian Bier und beim Common Water isst. Also dann kombiniert er mir alle in dieser Hierarchie, wo er durchgeht. Dann muss er natürlich auch immer ganz durchgehen. Und so habe ich dann auch verschiedene Möglichkeiten.

Ich kann auch ganze Strukturen abfragen, kann sagen bis in welche Hierarchiestufe, dass er die merchen soll und so weiter. Das macht es sehr kompliziert, je nachdem, aber auch sehr mächtig. Also es gibt dann da verschiedene Merge Behaviors, sagt man dazu.

Es gibt ein Deep Merge, wo er sagt, ich tue nur die oberste. Also es gibt ein Merge, wo ich nur die oberste Stufe jeweils kombiniere von verschiedenen Werten. Oder ein Deep Merge, wo ich dann auch die Unterstufen alle kombiniere und so weiter. Ich kann dann auch sagen, er soll mir gewisse Sachen, wenn noch ein Minus davor steht,

soll er mir es wieder rausnehmen auf dieser Hierarchiestufe und so weiter. Also da gibt es massenhaft Möglichkeiten. Meistens reichen die Möglichkeiten hier aus, die einfachen, aber manchmal ist das andere sehr mächtig.

Frage beantwortet, oder? Gut. Weitere Fragen. Ich mache einen kleinen Einschub, es gibt noch die Möglichkeit auch verschlüsselte Werte abzulegen.

IAML. IAML bedeutet, dass ich hier nicht einen String hinschreibe, sondern dass ich einen entkripteten String hereinschreibe. Es gibt mir die Möglichkeit, das zu verschlüsseln. Wenn ich beispielsweise die IAML-Datei in einem Git-Repository habe,

dann kann nur der Git-Server auf diese zugreifen und natürlich die Administratoren, die das verwenden. Und der Zwischenschritt im Git-Repository sind die Daten verschlüsselt abgelegt. Ich muss mich dann nicht um die Sicherheit dort auch noch kümmern. Was nicht heißt, dass ich das dann öffentlich machen sollte.

Genau. Es gibt da verschiedene Encryption-Plugins. Ich selbst verwende PGP. Das hat die Möglichkeit ergibt, dass man mit seinem eigenen Schlüssel nachher das Ganze für alle anderen verschlüsseln kann und entsprechend die Daten der Puppet-Server wieder entschlüsseln kann.

Ich habe dann auch die Möglichkeit, je nach Dateistruktur nur Gewissen entwickeln oder gewissen Operationsleuten Zugriff darauf zu geben. Und die anderen sehen das nur das verschlüsselte Passwort. Bei einem Kunden habe ich es so, dass ich die verschlüsselten Daten nicht sehe. Da sehe ich nur, was das verschlüsselt ist.

Und ich muss es auch nicht entschlüsselt wissen, weil das Passwort muss ich nicht wissen. Ich muss wissen, wie die Struktur ist und wie das funktioniert. Und so können Sie quasi die Passwörter von mir als externen Consultant auch geheim halten, aber mir den Zugriff auf die Produktionskonfiguration einfach so geben. Das ist der Vorteil von eAML.

Setup ist nicht ganz trivial. Es gibt dann einen speziellen Befehl, den ihr auf eure Maschine konfigurieren müsst, mit eAML, den ihr auch verwendet, dann nachher Dateien zu editieren. Und der Puppet-Server bekommt dann einen eigenen PGP-Key,

damit er auch entschlüsseln kann. Genau. Und die Hierayaml-Datei, die wir vorher gesehen haben, die muss entsprechend angepasst werden.

Ja, das ist diese mittlere Datenbank in Anführungszeichen. Jetzt gehen wir weiter noch zur Puppet-Datenbank. Die ist eigentlich relativ einfach. Die Puppet-DB sammelt eigentlich die Daten, die die Clients verwerten.

Also die Reports werden dort gesammelt, aber auch alle Facts, die sie liefern und gewisse exportierte Ressourcen und solche Sachen, die mir dann ermöglichen, etwas auf einem Node zu exportieren,

das ich nachher auf einem anderen Node wieder importieren kann. Beispiel Überwachung. Ich entscheide dann auf dem Node 1, ja, ich möchte überwacht werden, gebe das Überwachungsmanifest an den Puppet-Server und beim nächsten Run tut der Überwachungs-Server,

der Isinga-Server oder Nagios oder was ihr dann im Einsatz habt, dann das installieren, was ihm der andere gesagt hat. Also die Facts werden gestartet, die Kataloge, also das, was am Schluss rauskommen soll und was am Schluss geändert wurde

und automatischerweise tut er alles nach 14 Tagen löschen. Also alles, was älter ist als 14 Tage. Die Puppet-DB wird vom Puppet-Server verwendet, habe ich bereits gesagt.

Ihr könnt da gewisse Performance-Patterns auch abfragen auf dem Port, wenn ihr das installiert habt. Und es gibt Dashboards, die quasi die Puppet-DB abfragen. Die Open Source sind Puppet-Board oder Pano-Puppet,

wobei das ist glaube ich nicht mehr maintained. Und dann gibt es noch den Puppet-Explorer, den kenne ich auch nicht wirklich gut, die quasi Abfragen an den Puppet-Server machen, wo ihr euch dann grafisch darstellen, mehr oder weniger grafisch auf Webseiten darstellen könnt, was in der Puppet-DB gespeichert wird. Das ist insbesondere zum Schauen, ob die letzten Rans alle erfolgreich sind,

oder wo gab es Probleme und so weiter. Die Puppet-DB, aha ja, es gibt ein Puppet-DB-Modul, zu den Modulen komme ich gleich um die Puppet-DB zu installieren. Puppet-DB ist nicht notwendig, um den Puppet-Server laufen zu lassen.

Also es ist möglich, den Puppet-Server auch ohne Puppet-DB laufen zu lassen. Ihr verliert das Abspeichern der Kataloge und ihr verliert die exportierten Ressourcen. Aber das ist problemlos möglich.

Für eine kleine Installation kann man das auch so machen. Ohne die Puppet-DB. Gut, soweit Fragen. Nicht? Gut. Jetzt fangen wir nochmals von vorne an.

Nein, jetzt gehen wir nochmals zum Code nach vorne, weil ich das vorher etwas schnell gemacht habe, weil ich euch ein Beispiel gesagt habe, wie man beispielsweise den James Bond installiert. Im Normalfall werdet ihr nicht so viel Code und das Einzelliegend

in eine grosse Datei schreiben, sondern es gibt die Möglichkeit, Module zu verwenden. Ein Modul ist ein Konstrukt, das quasi eine Aufgabe übernimmt. Im Normalfall oder in grösseren Installationen wird nachher über Jera gesagt, aus welchen Module, welche Ressourcen

und welche Klassen aufgerufen werden. Also eigentlich kommen alle Manifeste, die ihr schreibt, sollten eigentlich in Modulen sein. Entweder ihr schreibt das als Modul oder jemand anderes hat das bereits geschrieben.

Früher war das etwas anders. Früher hat man viel noch in das Site-PP reingemacht. Das macht man heute eigentlich nicht mehr. Heute ist wirklich ein Modul kapsuliert und der Rest kommt ins Jera. Ja, Module bestehen aus Manifesten,

also Klassen und Defines, also Ressourcen, so wie wir es vorher gesehen haben. Module beinhalten auch einen eigenen Jera-Layer. Ich habe euch vorher gesagt, was Jera ist, wie das funktioniert mit dieser Struktur. Jetzt ist es so, dass jedes Modul

nochmals die Möglichkeit hat, eine eigene Jera-Hierarchie aufzubauen. Das heisst, wenn ihr etwas in der Haupt-Hierarchie nicht findet, dann fragt ihr nachher die entsprechende Modul-Hierarchie. Das ist sehr praktisch, beispielsweise für OS-spezifische Werte.

Wenn ich ein MySQL definieren will und dann muss ich den Parameter für die Version 1 so setzen und für die Version 2 so. Dann macht es mir das einfacher, dass ich das nicht in meine Hauptstruktur reingeben muss, sondern ich gebe das in die Modulstruktur, in das MySQL-Modul rein

und habe dort all diese Parameter drin. Dann weiss ich auch, dass der Installationspfad für das OS-spezifisch dort ist und für das andere OS dort und so weiter. Dann kann ich das dort konfigurieren. Dann habe ich alles, was MySQL betrifft, habe ich dann dort.

Und nur noch, was für mich in meiner Installation spezifisch ist, das gebe ich dann in das übergeordnete Hierar ein. Dann habe ich Templates in den Modulen. Templates sind Texte mit Lückentexte,

die ich nachher mit entsprechenden Parametern auffülle, also nicht speziell. Es gibt zwei Sorten von Templates, Erb und EPP. Das eine ist Embedded Ruby und das andere ist Embedded Puppet, das neue.

Ich habe gedacht, dass der Screensaver nicht dauernd kommt, aber es probiert sich so schlecht aus. Dann habe ich die Möglichkeit, statische Files reinzugeben, die dann einfach vom Puppet-Server ausgeliefert sind, eins zu eins.

Das können sogar Binary's sein, die ich so ausliefere, wenn das gewünscht ist oder notwendig. Und ich habe die Möglichkeit, Tests hinzuzufügen. Die Tests werden vom Puppet-Server selber nicht gebraucht, sondern die werden nur gebraucht in der Modulentwicklung, dass ich Testläufe machen kann über ein Modul und sagen kann,

ob es so funktioniert, wie ich mir das vorgestellt habe. Neuerdings gehören noch mehr Sachen dazu. Das ist eine kurze Auswahl. Genau. Ein Modul, das ist wichtig, das hat eine speziell definierte

Dateistruktur, das heisst, die Verzeichnisse und so, die sind wirklich definiert, da könnt ihr nicht freie Namen wählen. Also das Templates Directory muss Templates heißen, das Manifest Directory für den Code muss Manifest heißen, da könnt ihr nicht frei wählen. Das ist aber dokumentiert, wie genau was.

Dann müssen die Modulnamen gewissen Namenskonventionen entsprechen. Wir müssen mit Kleinbuchstaben beginnen und dürfen nur Buchstaben und Zahlen und Underscoren talten und sonst nichts und keine Resolved Words und so weiter. Das kennt ihr von anderen Programmen her.

Genau. Jetzt, wie komme ich zu einem Modul? Ihr könnt entweder selber Module schreiben oder man kann die auch runterladen und installieren. Installieren ist einfach. Man geht einfach in das Codeverzeichnis vom Papperserver und kopiert das in die Dateistruktur unter Module,

kopiert dort das Modul rein und dann kann es verwendet werden. Punkt. Das ist keine Hexerei. Man kann auch als Alternative Module von PuppetForge direkt installieren, indem man sagt PuppetModule install PuppetLabs

StandardLib. PuppetLabs StandardLib ist der Name des Moduls bzw. ist der Name des Moduls auf PuppetForge. Der Bindestrich wird nachher weggenommen, alles was vorne dran ist und das Modul selber heisst nachher StandardLibs. PuppetLabs ist derjenige,

der das Modul verwaltet. Man kann auch Git verwenden und irgendwelche Submodul Strukturen aufbauen und was mit Submoduls machen, das habe ich früher so gemacht, ist nur halb empfehlenswert. Submodule sind etwas

mühsam in Git, finde ich. Oder man kann eine spezielle Software verwenden, beispielsweise RCNK. Das ist so wie ich es im Einsatz habe und den Workflow möchte ich euch kurz zeigen. In der nächsten Folie, vielleicht vorher noch, wo findet man Module?

Es gibt die PuppetForge Homepage, dort sind mittlerweile eigentlich alle relevanten Module vorhanden, also auch Open Source Module, auch Module die jemand anderes geschrieben hat. Das ist von PuppetLabs quasi das Code Repository für Puppet Code. Viel findet man auch auf GitHub.

Also dort ist viel verfügbar. Die Links findet ihr übrigens immer in der Fußnote unten, da könnt ihr, wenn ihr die Präsentation runterladet, ich habe sie gestern Nacht draufgeladen, ich hoffe sie ist mittlerweile im Ring verfügbar, dann könnt ihr das auch selber nachschauen.

Ja, RCNK, so ein weiterer Reihenschuh wie ich vorher. RCNK ist eine Möglichkeit, wie man Git Repositories in Puppet Verwaltung konvertiert. So kurz gesprochen.

Git hat die Möglichkeit von verschiedenen Branches, Puppet Server hat die Möglichkeit von verschiedenen Environments. Jeder Branch wird automatisch zu einem Environment. Ein Environment, im Normalfall laufen die Server auf Production, aber ich habe auch einen Test Environment, dann kann ich die auf dem Environment

Test laufen lassen. Über den gleichen Puppet Server, also die sind vollständig getrennt und der Client sagt ihm dann, ich bin Production oder ich bin Test, je nachdem welches Environment das er möchte. Im Git mit den Branches habe ich das gleiche, kann ich sagen, ich habe einen Production Branch und ich habe einen Test Branch und das

macht mir nachher auch das Mergen von Test nach Produktion viel einfacher. Weil ich kann dann quasi sagen, ok, ich probiere das im Test Branch aus, wenn es funktioniert auf der Testumgebung ist gut, dann merge ich es einfach in Production, push es und dann habe ich es auf der Produktion genau das gleiche. Das ist die Idee dahinter.

Also ich habe dann einen Git Repository, das mir eigentlich die ganze Infrastruktur konfiguriert. Mit allen Möglichkeiten, die ich mit Git dann auch habe, dass ich sagen kann, ja, in den Production Branch darf nur der und der pushen oder nur nach so vielen Reviews und bla bla bla bla und so weiter.

Alles was da an Möglichkeiten besteht. Jeder Git Branch wird quasi zu einem Puppet Environment. Es gibt ein Puppet File, das auch in diesem Git Repository drin ist,

das heisst Puppet File und das sagt mir, welche Modulversion das er nachladen soll. Und das ist die Stärke von R10k, dass er mir nachher diese Module runterlädt und es entsprechende Verzeichnis gibt. Und weil ich das auch im Test- und in Produktions Branch habe und das nicht unterschiedlich sein muss, kann ich dann sagen,

ok, auf dem Test Branch will ich die Modulversion 1 und auf dem Produktions Branch will ich das Modul in der Version 2 verwenden. Genau. Also die korrekte Modulnummer und Version pro environment. Und ich kann

im Puppet File dann sagen, woher das er das nehmen soll. Ich kann Puppet Forge angeben, ich kann Git Repositories angeben, ich kann SVN angeben, ich kann sogar Torbolls angeben, woher das er die installieren soll. Der Workflow sieht dann folgendermaßen aus.

Ich habe hier meine Workstations vom Entwickler oder wer auch immer. Ich habe hier einen Git Server oder Git Olight Server und ich habe einen Puppet Server. Also die drei Servers sind da beteiligt und von der Workstation aus wird eigentlich nur ein Git Push an den Git Olight Server gemacht,

quasi Branch X. Ich pushe das und der Git Olight Server wird nachher mit einem Hack, mit einem Hook, den Puppet Server verständigen und sagen, hey, da ist was gegangen auf diesem Repository. Der geht sich das von Git Server holen,

Git schickt die Daten zurück an den Puppet Server und der wird dann R10k ausführen und alle Module sicherstellen und so weiter und den Output zurück an den Git Olight Server schicken und der schickt sie dann wieder an die Workstation, sodass ich sehe, welche Module hat er geupdatet,

hat es funktioniert, hat es nicht funktioniert. Das gibt mir als Entwickler jetzt auch als Operations die sehr einfache Möglichkeit vom Interface her, dass ich nur noch etwas reinpushen muss. Fertig. Und so habe ich das ganze System unter Kontrolle,

was das konfiguriert wird. Beim nächsten Puppet dran wird dann das entsprechend sichergestellt, dass dann die Konfiguration auch so auf dem Node ist. Was ich jetzt hier nicht dazu gegeben habe, ist, wenn man da noch Berechtigungen hat, das Produktionsbranche ist anders

als so und so weiter, also da könnte man jetzt auch noch irgendwelche Workflows auf dem Git Server dazugeben, dass jemand noch das approven muss, bevor es zum Puppet Server geht und so weiter. Das habe ich jetzt nicht hier reingenommen. Das ist dann umgebungsspezifisch.

Ein weiterer Vorteil, wenn ihr das so macht, ist, dass ihr natürlich eine Historie habt. Was wurde wann konfiguriert, von wem? Steht im Git drin. Ihr könnt sogar das Git-Commit noch signieren, dann ist es noch signiert von irgendjemandem und dann habt ihr die Sicherheit,

dass eigentlich nichts anderes auf dem Server konfiguriert wurde, als das, was im Git drin ist. Machen wir einen weiteren Reinschub zu den Modulen. Also nein, vielleicht zuerst

gibt es dazu noch Fragen. Nicht? Gut. Puppet Development Kit. PDK. Das ist eine Möglichkeit, wie sich Module relativ einfache Stellen erkannten. Das hilft euch, das Modul

zu erstellen mit den entsprechenden Verzeichnissen und auch mit den... mit Testing und so weiter. Quasi die Puppet Labs Best Practice. Im Puppet Forge seht ihr, welche Module PDK kompiliert sind oder

quasi mit PDK erstellt wurden. Die sind mit einem PDK bezeichnet. Das macht es einfacher, Module zu konfigurieren, also neue Module, Klassen, Defines und so weiter dazu zu geben. Auch Tests werden teilweise automatisch dazu generiert

in einer Basic Version, wo ihr nachher seht, quasi schon mal testen könnt. Bereits existierende Module kann man konvertieren. Installation auf einem Debian Ubuntu mit Abt Install PDK, aber man muss die Puppet Labs

Repositories dazugeben. Und das PDK selbst hat seine eigene Ruby Version mit dabei und die Ruby Library ist mit dabei. Das heisst, es ist ein relativ grosses Paket, das sie da installiert, aber dieses Rubienbein wird sonst nirgends verwendet,

außer für das PDK. Und so sieht dann der Prozess zum Stellen von Modulen aus. Ich mache dann oben einen PDK New oder einen PDK Convert, wenn ich ein bereits bestehendes Modul konvertieren will, habe dann die Möglichkeit, Tests zu fahren mit PDK Validate oder mit PDK

Test Unit, mache Spektests und kann eine neue Klasse generieren, mit PDK New Class oder New Defined Type, New Task, wenn ich Tasks definieren und so weiter.

So, kommen wir langsam zum Schluss. Wieso soll ich Puppet verwenden? Der Vorteil ist Konsistenz. Ich habe die gleiche Konfiguration auf jedem Node. Automation natürlich, ein neuer DNS-Resolver, der

eingetragen werden muss, ein Hierayaml-File, wo ich im Commons reinschreibe, der neue DNS-Server, ist dann so, eine halbe Stunde später haben alle das gewechselt. Dann die Dokumentation. Mit Git weiss ich genau, was wann gemacht wurde, wenn ich Git verwende. Ich habe ein Manifest, das mir genau sagt,

was das gemacht wird. Dann habe ich die Continuous Integration, das heisst, es wird andauernd sichergestellt, dass das, was ich konfiguriert habe, auf den Nodes entsprechend vorhanden ist. Also, alle halbe Stunde läuft das. Ein Platz, eine Konfiguration, klar.

Aber, ich möchte euch zwei Sachen nicht vorenthalten. Das eine Initial Work. Relativ viel Aufwand in der Initialphase. Aber es kann auch Schritt für Schritt gemacht werden. Und Puppet ist etwas schwach im Orchestrieren zwischen

Nodes. Nicht auf einem Node, aber wenn ihr Datenbank-Server und Web-Applikation, dann könnt ihr nicht so einfach sicherstellen, was zuerst gemacht wird, weil Puppet dann einfach alle halbe Stunde geht. Das ist sicher eine Schwäche von Puppet. Puppet hat dort eine Antwort, die heisst

Bolt, da gehe ich jetzt aber nicht im Detail drauf ein, weil ich glaube, die Zeit ist so fortgeschritten, dass wir vielleicht lieber noch eine Frage machen. Ihr habt die Links unten. Bolt ist quasi die Antwort auf Ansible. Ansible, das eigentlich von der anderen Seite her gekommen ist, wo man quasi immer vom

Workstation auf den Node geht und so konfiguriert. Und Bolt macht das eigentlich genau gleich. Gut. Ich glaube, vielleicht haben wir noch zwei Minuten. Eine halbe für eine Frage.

Wenn noch Fragen sind, ja dann gibt es keine Fragen.

Also wenn jemand eine Frage hat, kann ich es auch repetieren, kurz bis die Batterie gewechselt ist. Und sonst glaube ich muss nicht stressen, hast genügend Zeit, weil es gibt keine Fragen. Gut, dann bedanke ich mich.