Next Level Ansible
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 94 | |
| Autor | ||
| Lizenz | CC-Namensnennung 4.0 International: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/45837 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
FrOSCon 201833 / 94
3
7
9
10
13
14
16
19
21
23
25
28
29
30
31
32
33
36
37
39
40
41
43
44
46
48
49
50
53
54
57
67
75
76
77
80
81
85
90
91
92
93
00:00
HTTPCONSULTANT <Datenbank>Apache <Programm>XMLUMLVorlesung/Konferenz
01:08
HypermediaHash-AlgorithmusInformationPerspektiveHardwareOpen SourceLösung <Mathematik>SSHUMLJSONComputeranimationBesprechung/Interview
01:41
PerspektiveHardwareOpen SourceHypermediaHash-AlgorithmusInformationServerBesprechung/InterviewComputeranimationJSON
02:10
SchnittmengeRollbewegungParametersystemRepository <Informatik>Demoszene <Programmierung>Git <Software>Besprechung/Interview
03:36
HypermediaHash-AlgorithmusMomentenproblemRepository <Informatik>Vorlesung/KonferenzComputeranimation
05:34
VariablePlug in
06:04
Jenkins CIXML
06:48
JUnitDefaultMultiplikation
07:57
TaskProvidermakeVersion <Informatik>JUnitCompilerLesen <Datenverarbeitung>PasswortDefaultProgramm/Quellcode
09:55
PasswortJUnitYAML <Framework, Informatik>ProviderTaskVirtuelles privates NetzwerkFehlermeldungProgramm/Quellcode
11:06
JUnitJenkins CIModulTaskComputeranimation
11:53
TINA <Telekommunikation>FBS <Programmiersprache>JUnitDEBUG <Programm>YAML <Framework, Informatik>VariableTaskXML
12:56
JUnitYAML <Framework, Informatik>DEBUG <Programm>TaskVariableTaskBildschirmmaskeBimodul
14:39
TOUR <Programm>Repository <Informatik>HypermediaComputeranimationProgramm/Quellcode
15:05
Repository <Informatik>TemplateDefaultVariableModulComputeranimation
15:35
PasswortDebian GNU/LINUXComputeranimation
16:19
TaskDEBUG <Programm>YAML <Framework, Informatik>TaskDateiTeilmengeComputeranimation
17:32
TaskDEBUG <Programm>VerknüpfungsgliedYAML <Framework, Informatik>TaskSISPLaufzeitRollbewegungDEBUG <Programm>Mechanismus-Design-Theorie
22:05
ProgrammierspracheVariableLaufzeitVersion <Informatik>TupelListe <Informatik>Computeranimation
24:46
DEBUG <Programm>YAML <Framework, Informatik>TaskMAPNichtlineares ZuordnungsproblemListe <Informatik>Computeranimation
25:12
TaskMAPNichtlineares ZuordnungsproblemDEBUG <Programm>ZeichenketteDatenverarbeitungssystemENABLE <Programm>ProviderListe <Informatik>
27:23
KonfigurationsraumDateiENABLE <Programm>Data DictionaryComputeranimation
28:19
TaskMAPYAML <Framework, Informatik>HTTPKernel <Informatik>VerknüpfungsgliedDEBUG <Programm>
28:53
TaskHome location registerYAML <Framework, Informatik>HTTPKernel <Informatik>VerknüpfungsgliedRAMParametersystemDienst <Informatik>
29:27
TaskHTTPKernel <Informatik>VerknüpfungsgliedApache <Programm>Default
30:32
BetriebssystemVerweildauerTemplateOrdnungsbegriffComputeranimation
31:31
KonfigurationsraumHTTPApache <Programm>Kernel <Informatik>SCSIDefaultYAML <Framework, Informatik>TaskTemplateEigenwertproblemTestdatenComputeranimation
32:26
TaskSCSIDefaultYAML <Framework, Informatik>KonfigurationsraumComputeranimation
33:41
openSUSEComputeranimation
Transkript: Deutsch(automatisch erzeugt)
00:08
Gut, also, wer den vorherigen Vortrag gehört hat, der weiß, dass es da ein paar Configuration Management Tools vorgestellt wurden. Puppet, Ansible und Zollstack und der wurde von meinem Kollegen Jonas gehalten und ich
00:24
gehe jetzt auf einen dieser Configuration Management Tools näher drauf ein und zwar Ansible. Kurz zu mir. Ich bin, genau wie der Jonas, der Spieker von vorhin, Consultant bei der Artex AG. Beschäftige mich da hauptsächlich mit Ansible, mit Zollstack, mit Apache Kafka und dem Formen-Projekt,
00:48
von dem wir hier auch einen Stand haben. Wir geben dort Ansible-Schulungen und wir kontributieren ziemlich viel zu dem Formen-Projekt auf GitHub und sind da teilweise Main Contributor bei einigen Repositories.
01:09
Meine kurze Übersicht, was Ansible eigentlich ist, für die die gerade eben nicht da waren, also das ist ein Configurations Management und Orchestrierungstool. Das ist im Gegensatz zu anderen Lösungen basiert rein auf SSH.
01:24
Es gibt dort keinen Master und keinen Client, der irgendwo installiert werden muss, sondern es läuft eben alles über SSH. Und als einzige technische Voraussetzung ist ein integriertes Python und eben funktionierende SSH-Verbindung auf den Nodes, die man bespielen möchte.
01:43
Es verfolgt das Konzept der Idempotenz, also das heißt, dass egal wie oft ich jetzt Ansible aufrufe und auf einem Server ausführe, das Ergebnis ist immer dasselbe, weil einfach immer nur der finale Zustand beschrieben wird.
02:01
Es wird, wie vieles andere in dieser Welt mittlerweile, in Jaml geschrieben. Das ist für einen Menschen eine relativ einfach lesbare Markup-Language. Und weil es unten drunter ziemlich viel, also hauptsächlich auf Python basiert, wird dort auch als Stamp-Baiting-Sprache
02:22
verwendet, was eben hauptsächlich auch für Python verwendet wird. Und ich möchte euch jetzt in diesem Vortrag ein paar Tricks vorstellen, die so ein bisschen über das grundlegende Feature Set von Ansible hinausgehen.
02:40
Mit einer Demo dazu. Als erstes, vielleicht kennen es einige, es gibt das Kommando Ansible-Pull. Das kann man als Parameter ein Versionskontrollsystem-Repository angeben, in der Regel Git.
03:03
Und in diesem Repository liegen Rollen drin und Playbooks und man kann auch ein Playbook angeben, das wird dann ausgeführt. Wenn man das jetzt z.B. kombiniert mit einem Cron-Job, der alle 30 Minuten abläuft, dann könnte man darauf kommen, dass da so ähnlich funktioniert wie z.B. bei Puppet,
03:24
wo ja auch alle 30 Minuten was ausgeführt wird. Das kann ich gleich mal zeigen.
03:42
Also wir haben hier ein Playbook. Ich teste das alles bei mir lokal hier. Und da wird das Cron-Modul aufgerufen, dass ein Cron-Job installiert wird, der als Kommando diesen Ansible-Pull-Befehl hat, wo ein Git-Repository angegeben ist,
04:05
wo ein Playbook drin liegt und es wird auf localhost ausgeführt. Und zu Testzwecken, damit wir es jetzt hier sehen können, wird das alle zwei Minuten ausgeführt. Wir können uns dieses Repository mal anschauen.
04:23
Da liegt ein einziges Playbook drin, das in ein temporäres Verzeichnis am Schluss einfach die aktuelle Uhrzeit der Ausführung hineindrückt. Im Moment ist es leer, also das File gibt es nicht.
04:46
Wenn wir es jetzt mal ausführen, dann ist hier was passiert. Wir können es uns nochmal angucken im Cron-Tab.
05:03
Und da sehen wir, dieser Befehl ist hinterlegt. Und wir können in zwei Minuten mal gucken, ob sich da wirklich was getan hat. Als nächstes, es gibt ein Ansible.
05:23
Also Ansible, wenn man das normal bei sich ausführt, dann wird ein... Okay. Ah, okay.
05:42
Okay, also wenn man jetzt Ansible Playbook bei sich normal ausführt, dann kriegt man so eine Ausgabe, was da gerade passiert ist. Und wenn man sich irgendwelche Variablen ausdruckt, dann werden die da auch einfach auf die Kommandezeile gedruckt. Aber für diese Ausgabe, das ist auch nur ein Plugin.
06:00
Man kann da andere Plugins verwenden, dass diese Ausgabe eben nicht mehr ein menschenlesbares Format ist, sondern zum Beispiel, dass es in einem JUnit-Test-Case-File ausgedruckt wird. Das dann so aussieht, wie als wäre ein JUnit-Test gelaufen. Und das kann man dann wiederum verwenden, wenn man das alles automatisiert, zum Beispiel in einem Jenkins verwendet.
06:26
Dass dann dieses Result-File vom Jenkins gelesen wird und dann schön visualisiert wird. Und dann kann man sehen, dann wird es auch grün angezeigt, wenn es durchgelaufen ist. Und rot und gelb, wenn es irgendwie nicht so optimal durchgelaufen ist.
06:45
Das kann ich auch mal kurz zeigen. Genau, da muss man eine Änderung in seiner Ansible-Config machen.
07:03
Genau, hier kann man dann angeben, in was man es ausgedruckt haben möchte.
07:33
Und man muss, wenn man es ausführt, noch in einer Umgebungsvariable angeben, wo man denn dieses File gerne hin haben möchte.
07:42
In unserem Fall setzen wir uns einfach mal ins aktuelle Verzeichnis rein. Jetzt filmen wir dieses Skript mal aus. Das Skript kann man jetzt mal kurz anschauen. Es druckt einfach nur in Hello World aus.
08:14
Das hat mal besser funktioniert. Schade.
09:39
In der Zwischenzeit können wir mal gucken, ob unser Contab-Modul irgendwas getan hat.
10:26
Ja, genau hier. Sieht dann so aus. Ich kann es jetzt nicht lesen, Jenkins aber schon. Aber es sieht ganz gut aus. Mit Errors ist gleich Null. Ich befürchte fast, dieser Ansible-Pull-Run hat nicht funktioniert, weil dieses GitHub in einem Ort ist, wo ich es nicht ohne VPN erreichen kann.
11:19
Als nächstes, es gibt in Ansible den Befehl omit.
11:27
Wenn man einen Task hat und dort einen Wert einsetzt und dann um mit zu macht,
11:43
ist es für das Modul so, dass dieser Wert überhaupt nicht gesetzt wird. Wenn man es einfach nur so hinschreibt, bringt es jetzt nicht so viel. Aber man kann es jetzt zum Beispiel benutzen, wenn man einen Tasks-File hat, wo einfach nur ein Task drin steht.
12:05
Und man hat in diesem Tasks-File auch noch für den Task verschiedene Variablen definiert. Man hat hier einen Tasks-File, dort fügt man eine Variable ein und diese Variable definiert man hier auch gleich mit einem Wert.
12:36
Und jetzt haben wir hier ein schönes Playbook.
12:44
Das inkludiert diesen Task und wir können es jetzt mal ausführen.
13:14
Dann wird zuerst die Variable genommen, die in diesem Task-File definiert wurde. Also das hier unten. Und im zweiten Durchlauf haben wir hier die Variable überschrieben mit dem Wert um mit.
13:33
Und hier reicht einige Wissen. Wenn beim Debug-Task kein Wert hier gesetzt wird, also keine Message und auch keine Variable,
13:42
dann wird einfach immer Hello World ausgedruckt und genauso war es auch hier. Diese Variable wurde zurückgesetzt einfach, sodass hier dann auch nichts mehr drin stand und entsprechend wurde Hello World ausgedruckt. Das kann man vor allem dafür verwenden, wenn man einen Task mehrfach aufruft.
14:05
Und wir benutzen es zum Beispiel bei den Formen Ansible Modules. Das sind Module, um mit dem Formen zu sprechen. Wenn man dort einen Task mehrfach aufrufen möchte, dass man sich dann eben in diesem Task-File Variable definiert
14:24
und sie dann über die einzelnen Aufrufe einfach nur die einzelnen Variable ändert und nicht jedes Mal alle Werte neu einsetzen muss. Also das sehe ich, ich kann das mal kurz zeigen.
15:04
Hier ein Task-File, das heißt Installation Medium. Hier wird dieses Modul aufgerufen mit vorher, also und hier die einzelnen Parameter, die wir hier als Variable hinterlegt haben.
15:27
Die, also diese Credentials hier, die sind woanders definiert, aber zum Beispiel hier der Installation Medium Name und die Location und das ganze Zeug. Das ist alles hier hinterlegt.
15:43
Und wenn ich das jetzt aufrufe, das passiert in diesem Task, da wird einfach hier dieser Task, den wir gerade eben gesehen haben, included. Und zum Beispiel hier wird ein Wert überschrieben und da kann man dann zum Beispiel auch einfach um mit reinschreiben,
16:08
wenn man das nicht haben möchte, in dem Fall, dass er nicht gesetzt wird, auch wenn man bei allen anderen Fällen gesetzt haben will.
16:31
Dann bei Ensl gibt es ja Tags, damit die kann man an verschiedene, an seine Tasks dranhängen. Und wenn man dann Enslable Playbook aufruft, werden, wenn man Tags gesetzt hat, auf diesem Enslable Playbook-Ruf nur die Tasks ausgeführt,
16:48
wo auch diese Tags gesetzt sind und wenn man jetzt zum Beispiel, wir haben hier gerade eben ein Task included, also ein anderes Datei, wo Tasks drin hinterlegt waren und in dieser Datei mehrere Taste sind, die unterschiedliche Tags drin haben
17:12
und man dann nur Teilmengen aus diesem importierten oder diesem inkludierten File verwenden will, dann kann man das mit dieser include-Tasks-Methode machen.
17:26
Lass' hier mal kurz zeigen. Also wir haben hier ein Playbook, das einmal included ist, ein Task-Datei, einmal importiert es das
17:50
und beide mal ruft es die mit dem Tag Tag 1 auf. Diese sind relativ unspektakulär, also da wird auch einfach nur Debug aufgerufen
18:04
und die haben unterschiedliche Tags einmal, die die ursprüngliche, die importierende Methode hat. Kann man Tags auch in Playbook setzen, also mit einem Z-Fact-ähnlichen Mechanismus
18:22
oder muss ich hier beim Aufruf auf der Kommandozahle vom Enslable Playbook mit annehmen? Du kannst sie hier setzen, indem du sie inkludierst. Was ich meine ist, dynamisch beim Playbook-Aufruf zu entscheiden, ich habe eine Flagg-Datei zum Beispiel, dass ich das schon bereits installiert habe.
18:42
Wenn Registrar und Instart, könnte ich einen Mechanismus bauen, dass ich mich immer wieder neu installiere, wenn ich den Potenzial habe. Gibt es eine Rolle dynamisch, ganz oben einen Tag zu setzen, innerhalb des Playbook-Laufens?
19:07
Also man kann, wenn man Rollen importiert, kann man Tags setzen, aber bei einem Playbook-Aufruf oben nicht. Es gibt ja diese Enslable Facts und die Tags sind leider kein Teil dieser Enslable Facts.
19:23
Das bin ich auch schon darauf gestoßen. Achso, ja, es ging darum, ob man Tags auch während des Playbook-Aufrufs nochmal setzen kann und das geht leider nicht.
19:47
Und hier wird jetzt ein Task-Datei importiert. Sieht genauso aus, auch mit verschiedenen Tags hinten dran. Und wenn ich jetzt das mal ausführe, wenn ich dort Tag 1 anführe, dann werden die inkludierten Tasks,
20:25
die, da wird dann überprüft bei den Einzelnen, ob der gesetzt wird, ob der gesetzt ist oder nicht, also was hier dran steht. Und in dem Fall, wir haben es mit Tag 1 aufgerufen und dieser Task hat nun Tag 2, deswegen wird es nicht aufgerufen.
20:49
Wo? Bei imported, ja, richtig.
21:01
Bei included, also bei import zählt tatsächlich nur das, was bei der import, die Tags, die bei der import-Methode dran stehen. Da ist es wurscht, was drin steht. Aber wenn es include, also es wird halt einfach, bei include wird es dann zur Laufzeit überprüft, was in dieser Teil drin steht.
21:25
Da wird überprüft, ob hier der Tag 1 gesetzt ist bei der Methode. Ja, ist er. Das heißt, es wird hier oben ausgedruckt. Wird hier geguckt, ob der Tag 1 gesetzt ist. Ist er nicht? Wird nicht ausgeführt.
21:45
Weil es imported einfach statisch gerendert wird. Richtig, ja. Genau. Und das include guckt eben dann zur Laufzeit an.
22:21
Ja? Ob es einen Unterschied gibt zwischen dem include-Modul und dem include-tasks-Modul? Ja, gibt es. Das include-tasks ist einfach neuer und das include ist deprecated mittlerweile.
22:43
Einfach nicht mehr empfohlen. Über welche Version von Ansible wir reden. Ich verwende Ansible 2.6 und das include-deprecated ist schon eine Weile her, dass das davon abgeraten wird.
23:07
Also bestimmt schon 2.2 oder so. Ich kann es auch gerne mal nachgucken. Richtig, aber im Grunde die alten import- und include-Methoden, die haben gleich funktioniert wie diese include-tasks und import-tasks.
23:30
Das eine eben statisch gerendert wird und das andere zur Laufzeit dynamisch. Man kennt vielleicht aus anderen Programmiersprachen diese zip-Methode.
23:46
Das ist, wenn man zwei Listen hat und man die kombinieren möchte, dass man dann wie so einen Reißverschluss die ersten Elemente der von beiden Listen nimmt und dann zusammentut in einen Tupel.
24:02
Und dann die zweiten Elemente der beiden zusammenführt. Und das gibt es in Ansible auch. Und da gibt es noch einen Sonderfall. Die zip-longest-Methode, da kann man auch eben zwei Listen zusammenführen. Es müssen nicht zwingend zwei Listen sein, es können auch drei sein.
24:25
Und vor allem sie müssen nicht gleich lang sein. Und da kann man dann zusätzlich auch noch, falls diese Listen ungleichmäßig lang sind, so einen Platzhalter einsetzen, der dann einfach hergenommen wird, wenn die eine Liste schon zu Ende ist, während die andere noch Elemente dafür hat.
24:46
Und das kann man zum Beispiel dafür verwenden. Und hier haben wir ein paar Listen.
25:03
Einmal eine mit drei Elementen, eine mit vier, fünf. Das müssen wir mal ausführen.
25:23
Bei dem ersten werden einfach nur die ersten beiden Listen zusammengesippt, wie man es schon kennt. Und dort, wo die eine zu Ende ist, wird mit diesem Fill-Value, den man hier setzt, das einfach gepaddet.
25:45
Hier sehen wir, wie das aussieht, wenn man es mit drei Listen macht. Dass man dann Elemente von dieser, dieser und dieser Liste einfach zusammenstofft. Und da kann man auch wieder ein Fill-Value ansetzen, der auch mehrfach verwendet werden kann.
26:04
Also wenn jetzt die eine Liste länger ist als die anderen beiden zusammen. Richtig. Und man kann auch nur eine Liste angeben, wie hier in dem Fall diese Provider-Liste.
26:22
Und dann als Fill-Value irgendwas hinsetzen. Das kann man jetzt zum Beispiel dafür verwenden, wenn man in Ansible über so ein, es gibt ja nicht für alles Module leider, wenn man sich da irgendwie ein, so ein paar Strings zusammen konkretinieren möchte. In dem Fall sieht es hier sehr ähnlich aus, wie Parameter, die
26:45
einem Kommando-Zahlen-Programm einfach übergeben werden sollen mit dieser Minus-Minus-Syntax. Und wenn es vorher eine längere String ist, also in dem Fall Enable Compute. Das ist so ein Teil von dem Formel Installer.
27:02
Und wenn man dort viele verschiedene Provider hat und dann nicht jemanden schreiben möchte, dann kann man sich dann hier so ein String damit zusammenbauen, in dem man einfach nur eine Liste übergibt und den Rest einfach dann auffüllt. Sodass dann das hier jedes Mal eingesetzt wird.
27:32
Dann auch nochmal so ein Trick, wenn man jetzt ein Dictionary hat,
27:42
also wenn man irgendwie Konfigurationsfalls für viele verschiedene, zum Beispiel Microservices hat und die immer gleich aufgebaut sind und die sich eigentlich fast alle identisch konfiguriert sind. Also dass man sagen kann, dass man irgendwie eine gewisse Standardkonfiguration hat und nur in Ausnahmefällen das notieren möchte
28:06
und eigentlich sonst als Fallback immer eine gewisse Datei oder eine gewisse Struktur haben möchte. Dann gibt es dafür auch eine Lösung in Enable.
28:39
Also wenn man hier jetzt so eine Default-Konfiguration hat und dann so eine Microservices hier definiert.
28:48
Default-Konfiguration sind halt so Sachen, die standardmäßig einfach so sein sollen, dass immer der Fernsehzimmig mit RAM hat und dass so ein paar Parameter einfach gesetzt sind. Und halt hier dann man nur die Sachen notieren möchte, die wirklich pro Microservices individuell sind.
29:08
Zum Beispiel der Image-Name und der Name von dem Service. Und dass man dann am Schluss irgendwie so eine Liste hat, dass man dann am Schluss auch wieder so eine Liste mit Dictionaries hat,
29:28
wo halt hier das alles aufgefüllt wird, also wo hier kein Pull und kein Memory gesetzt wird, dass es eben dann eingefüllt wird mit diesen Standardwerten dort oben. Es wird hier über so ein bisschen umfangreichere Ginger-Magie zusammengebustelt,
30:03
sodass dann am Schluss das so aussieht, dass hier diese Standardwerte von oben übernommen werden, Pull und State und der Rest aus diesen Konfigurationen übernommen wird. Also hier zum Beispiel kein Memory wird auch hier oben gesetzt, aber hier unten wird überschrieben
30:21
und entsprechend ist er halt hier auch auf diesen Customwert gesetzt und nicht wie hier auf den Defaultwert.
30:40
Und das ist ja auch nochmal so ein kleiner Sonderfall als nächstes, wenn man irgendwie eine Liste hat, die hier Provisioning Templates, in dem Fall Operating Systems zuweist
31:02
und man es eigentlich andersrum haben möchte, dass man die Betriebssysteme den Provisioning Templates zusortiert, also dass es hier einfach dieser Key hier oben ist und der da unten, dass es dann eben so aussieht, dass man dann abfragen kann, welche Provisioning Templates in welchem Betriebssystem,
31:23
also welches Provisioning Template in welchem Betriebssystem verwendet wird und nicht welches Betriebssystem welche Provisioning Templates verwendet. Da gibt es auch Möglichkeiten, das in Ansible zu lösen.
31:51
Hier wird es vorher definiert mit ein paar Testdaten. Dann hier auch wieder über so einen bisschen aufwendigeren Set-Fact-Befehl,
32:06
nicht gebogen und am Schluss nicht mehr nach Operating System sortiert, sondern schön nach seinem eigenen Provisioning Template diese ganze Liste sortiert.
32:26
Das ist auch nichts, was man hier jeden Tag benutzt, aber wenn man das mal brauchen sollte, ist es gut zu wissen, dass so etwas möglich ist.
32:49
Das war es jetzt erstmal so weit. Gibt es Fragen?
33:09
Gibt es die Beispiel irgendwie in Github, weil das war jetzt relativ schnell gezeigt, weil die Filter sind doch etwas länglich gewesen, um sie jetzt mal kurz mitzuschreiben. Ich kann sie gerne auf Github stellen. Noch sind sie nicht dort, aber... Das wäre sehr nett, danke.
33:21
Okay.