Automatic Configuration and Deployment of Workshop Environments
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 94 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/45587 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FrOSCon 201990 / 94
7
10
12
14
15
16
17
20
22
23
26
27
28
29
30
31
32
33
36
37
38
39
41
44
45
48
52
53
55
56
57
58
60
61
62
64
66
67
74
76
77
78
79
81
83
84
93
00:00
Lösung <Mathematik>Configuration spaceAutomatonFocus (optics)XMLUMLLecture/Conference
00:32
TOUR <Programm>Operating systemForm (programming)Systems <München>Computer animation
01:35
Server (computing)RobotUser interfaceSource codeLösung <Mathematik>Stack (abstract data type)FES <Programm>Computer animation
02:58
DiagramComputer animation
03:32
Service (economics)Computer animation
04:21
Point cloudLaptopVAX/VMSConfiguration spaceMeeting/Interview
05:17
Point cloudSource codeVAX/VMSPoint cloudLaptopProviderService (economics)WEBPoint cloudCodeMobile appMetric systemSystems <München>CryptanalysisCodeLösung <Mathematik>Computer animationProgram flowchart
07:36
Cache (computing)Coin <Programmiersprache>Source codeScripting languageCodeWindows AzureConfiguration spaceToken ringRollbewegungVAX/VMSTask (computing)Software testingVariable (mathematics)Ende <Graphentheorie>Scheduling (computing)SSHSpeicherbereinigungPoint cloudEigenvalues and eigenvectorsSoftware repositoryWorkstation <Musikinstrument>Run-time systemComputer animation
17:14
Source codeRollbewegungSSHCentOSConfiguration spaceTask (computing)VAX/VMSVirtualizationService (economics)RAMComputer animation
18:43
VAX/VMSFirewall (computing)Computer-generated imageryoutputVAX/VMSMainframe computerConfiguration spaceWEBHand fanIP addressCentOSSource codeTypVariable (mathematics)Debian GNU/LINUXHigh availabilityZugriffSSHDefault (computer science)Computer animation
23:32
VAX/VMSIP addressWEBInstanz <Informatik>Server (computing)Configuration spacePasswordZugriffComputer animationProgram flowchart
25:31
VAX/VMSSource codeVAX/VMSDomain nameTask (computing)Computer animation
26:04
Point cloudSource codeIP addressServer (computing)YAML <Framework, Informatik>Default (computer science)CentOSVAX/VMSConstraint (mathematics)High availabilityWEBTask (computing)Instanz <Informatik>Physical lawIP addressInformationMainframe computerStructural loadHand fanComputer animation
29:33
Source codeInternet forumVAX/VMSTask (computing)Computer fileComputer animation
31:07
TwitterOpen sourceOpen sourceComputer animation
31:45
VAX/VMSEigenvalues and eigenvectorsGit <Software>WINDOWS <Programm>Lecture/Conference
33:35
Scripting languageGastropod shellVariable (mathematics)Statement (computer science)Scripting languageComputer animation
34:39
Variable (mathematics)outputNFSParameter (computer programming)Variable (mathematics)SSLGastropod shellComputer animation
35:32
NFSWEBVAX/VMSGastropod shellWindows RegistryRouter (computing)Computer animationSource code
39:08
IndexComputer filePasswordWEBComputer animation
39:55
NFSopenSUSEDemosceneSource codeComputer animationLecture/ConferenceXML
Transcript: German(auto-generated)
00:07
Hallo, ich begrüße euch zu meinem Vortrag Automatische Konfiguration und Deployment von Workshop-Umgebungen. Ich bin David Saddari, IT Consulting bei der ARTICS AG. Wir haben unseren Fokus auf Rechenzentren, unterstützten Kunden im Cloud-Bereich,
00:25
zum Beispiel in der Nutzung von Lösungen von Google Cloud, AWS und Azure, aber auch im Einsatz von Lösungen wie Docker, Kubernetes, OpenShift, Ansible auf kundeneigenen Infrastrukturen. Wir bieten unsere eigene Lösung an für die Orchestrierung, den Ocarino.
00:44
Damit lässt sich im Gegensatz zu Red Hat Satellite, das auch auf Formen und Kartello Sets Betriebssystem unabhängig Systeme provisionieren, lässt sich die Page- und Lifecycle-Management realisieren.
01:01
Wir unterstützen im Gegensatz zu Satellite auch Debian, Ubuntu-Systeme, SUSE-Systeme und auch Windows-Server und bieten dafür auch Support und haben eine eigene Engineering-Abteilung, die peu à peu neue Features implementiert. Zum Beispiel kommt demnächst die Unterstützung von Windows-Servern per Netzwerkinstallation hinzu.
01:23
Und wir sind auch der Haupt-Maintener des Formen-Salt-Plugins. Wir bieten auch Workshops an, hier im Bereich IT-Automatisierung und Config-Management.
01:43
Ansible, das seit 2015 von Red Hat gepflegt wird, genauso wie Salt, Stack of Python Sets und auch im Puppet-Bereich, das im Gegensatz zu den beiden anderen Lösungen auf Ruby setzt und seit 2005 verfügbar ist.
02:02
Des Weiteren bieten wir Schulungen im Bereich Container- und Orchestrierung an, natürlich Docker, aber auch Kubernetes, mit denen sich Container-Infrastrukturen orchestrieren lassen und skalieren und managen. Und natürlich auch zu unserem eigenen Produkt, dem Ocarino,
02:22
der wie gesagt für dem Server-Deployment, der Konfiguration, dem Release und dem Patch-Management dient. Nun mag manche hinterfragen den Nutzen hinterfragen von Workshops. Man muss aber bedenken, dass die IT-Branche, so wie jede andere Branche, einen steten Wandel unterliegt
02:42
und gewisse Technologien, die einst gefragt waren, wie die Blockchain, die angeblich fürs Bankenwesen gedacht war, dann wieder ins Hintertreffen gelangen und nicht mehr aktuell sind. Aktuelle Themen sind zum Beispiel 5G oder smarte Roboter, die sind zurzeit in aller Munde.
03:06
Was daraus wird, weiß man nicht. Es gibt dann einen Hype, dann verfällt das wieder und vielleicht irgendwann, auf lange Sicht hinweg, wird das dann produktiv genutzt. Man weiß es nicht. Und diese Technologien sind dadurch in einem steten Wandel unterliegen.
03:29
Und die Kunden stehen vor dem Problem. Sie wissen im Grunde nicht, oft nicht, was sie wollen. Sie wissen schon, was sie wollen, aber sie wissen nicht genau, was die Anforderungen sind und wie die realisiert werden sollen.
03:41
Sie können sich nicht vermitteln und können vielleicht auch nicht im Genauen artikulieren, was erforderlich ist, wie das zu lösen ist und so weiter. Dafür bieten wir dann unsere Beraterservices an. Und jetzt in dem Beispiel, das kenne ich aus meiner Informatikzeit noch von den Vorlesungen, hier in dem Beispiel, das beschreibt der Kunde, wer ein Projekt auszusehen hat, der Entwickler implementiert das auf seine eigene Weise.
04:06
Das wird dann nicht dokumentiert. Es wird viel Geld verlangt. Und letztendlich hat der Kunde nicht die Lösung, die er haben will, den Autoreifen, den er am bauen gebunden haben wollte.
04:21
Und dafür bieten wir unsere Workshops ab. Aber das war zu früheren Zeiten nicht zufriedenstellend für uns. Im Grunde sind wir damals da hergegangen und haben einfach Laptops bereitgestellt. Die haben wir per Netzwerkinstallation provisioniert. Und mittels Vagrant haben wir VMs eingerichtet und unter Verwendung von Ansible dann diese konfiguriert.
04:45
Das war sehr fehlerbehaftet. Es waren manuelle Eingriffe erforderlich. Und immer, wo der Mensch mit Handish eingreift und das nicht vorher getestet hat, können Fehler auftreten. Es wird eine Konfiguration gelöscht oder die Musterlösung landet auf dem Laptop.
05:04
Und des Weiteren hat der Teilnehmer da ein Laptop vor sich liegen mit Schminkdisplay oder Tastaturlayout, das er nicht benutzt und eine Auflesung, das er nicht gewohnt ist. Deshalb sind wir da hergegangen und haben uns gedacht, wieso verschieben wir, verlagern wir das nicht alles in der Cloud.
05:21
Im Grunde sind die ganzen VMs, die vorher in Vagrant, mittels Vagrant aufgesetzt wurden, sind dann beim Cloud Provider. Und der Kunde nimmt sein Laptop da her und arbeitet eigentlich mit dem Arbeitsgerät, das er auch während der alltäglichen Arbeit verwendet in der Schulung.
05:44
Und dafür verwenden wir GitLab. Was ist GitLab? GitLab ist eine Web-Applikation, mit der man Git Repositories verwalten kann. Aber es bietet auch einiges mehr. Es ist als privates Projekt gestartet worden vom Dimitri im Jahre 2011. 2013 ist auch aus einem Unternehmen entstanden, das auf GitLab.com eigene Services anbietet.
06:08
Und aber den Kunden auch die Möglichkeit bietet, GitLab selber zu hosten, entweder in der Cloud, auf eigenen Cloud-Instanzen oder on-premise.
06:21
Und dafür gibt es verschiedene Plans, die sich eignen von privaten Projekten und kostenlos zu Lösungen für Enterprise-Kunden. Und darunter, dazu gehören auch der CERN, die Cloud Native Computing Foundation, für die für Kubernetes zum Beispiel verantwortlich ist, die ESA und Goldman Sachs.
06:48
GitLab ermöglicht im Grunde alles, was der DevOps-Engineer benötigt. Damit lassen sich Projekte planen, Codes erstellen, dieser Code kann verifiziert werden. Es wird dann in einer Art und Weise gebündelt, sodass er dann mit dem Release zur Verfügung gestellt werden kann.
07:09
Damit lassen sich Systeme konfigurieren und es werden auch Metriken abgegriffen, sodass Monitoring realisiert werden kann. Und durch das Monitoring kann man dann auf Angriffe reagieren und durch das ständige Release-Management kann man die Systeme auch besser absichern.
07:28
Indem man die Patches peu à peu immer bei Bedarf installiert. Mein Vortrag konzentriert sich aber auf die CI-CD, die benutze ich, um die VM-Infrastruktur aufzuziehen.
07:46
Und was ist die CI-CD? Im Grunde dienen sie dazu, Code auszurollen und zu deployen. Man hat zum einen den eigenen Code und in meinem Fall habe ich auch Programm-Code aus den Ansible-Galaxy-Rollen.
08:08
Die werden committed und dann, je nach Bedarf, automatisch oder durch manuelles Ausführen wird eine Pipeline gestartet, die dann den Programm-Code kompiliert, Tests darauf ausführt.
08:25
Falls sie erfolgreich waren, wird in einem zweiten Schritt dann der Code überprüft und bei Bedarf dann dem Kunden zur Verfügung gestellt. Die CI-CD-Pipeline teile ich auf in Stages und Jobs.
08:45
Stages sind sozusagen Abschnitte einer Pipeline, die nacheinander abgearbeitet werden. In meinem Fall verwende ich die beiden Stages Command und Only After Setup. In Command sind die Jobs hinterlegt, die der Schulungsleiter dann ausführen kann.
09:04
Er kann ein Cleanup ausführen, um die alte Infrastruktur wieder zu löschen. Er kann die Fax aufzeigen, welche VMs existieren, welche FQDNs, was für VM-Größen verwendet werden.
09:21
Mit der Garbage Collection hat der Schulungsleiter im Grunde nichts zu tun. Das läuft im Hintergrund im Idealfall ab und damit wird nach der Schulung automatisch die ganzen VMs gelöscht, die FQDNs werden gelöscht. Besonders wichtig ist das Setup natürlich, das wird dann ausgeführt.
09:41
Das Setup wie die anderen drei Jobs, das sind Ansible Galaxy Rollen, für die ich verantwortlich bin und die ich dem Schulungsleiter zur Verfügung stelle. Der Schulungsleiter selber muss im Grunde selber nur festlegen, wie diese Ansible Galaxy Rollen zu verwenden sind.
10:04
Wie viele VMs zu erstellen sind, in welcher Konstellation sie zueinander stehen. Welche VMs sich mit welcher anderen VM per SSH zu verbinden haben. Das wird zum einen festgelegt und zum anderen werden dann vom Schulungsleiter eigene Ansible Tas specifisch zur eigenen Schulung geschrieben.
10:25
Wir haben letzte Woche eine Kubernetes-Schulung gehabt. Da hat der eine Kollege dann Tas geschrieben für die Kubernetes-Schulung. Die kommende Woche findet ein Ansible-Workshop statt. Da laufen natürlich andere Tas ab.
10:42
Und wie schreibe ich das nieder? Also, dass einmal ich eine Stage habe namens Command und einmal eine Stage namens Only After Setup, die, wie der Name schon sagt, nur ausgeführt wird. Also der Workshop-Job wird nur ausgeführt, soll nur ausgeführt werden, wenn man ein Setup vorher gemacht hat, sonst macht das keinen Sinn.
11:03
Man kann ja keine Tas auf einer nicht existenten VM ausführen. Das mache ich in der GitLabCI.yml. Darin lege ich zuallererst fest, welche Stages ich habe, also Command und Only After Setup. Und ich habe in meinem Fall verzichte ich auf das Caching, damit ich, nachdem die Basisinstallation durchgeführt ist,
11:28
der Schulungsleiter die Möglichkeit hat, Workshop-spezifische Tas auszuführen, falls ein Fehler auftritt, die eigenen Workshop-spezifischen Tas zu korrigieren und dann das wieder auszuführen. Da wird dann die Workshop Ansible-Rolle abgerufen, also die neue, die gepatchte.
11:46
Und dann läuft Ansible wieder durch und vollzieht nur die Änderungen, die notwendig sind. Diese einzelnen Jobs, die in der Command-Stage sind, teilen sich einiges an Code.
12:06
Damit ich nicht immer denselben Code niederschreibe, einmal für Cleanup, denselben Code wie den für Setup, verwende ich YAML Anchors. Darin sind die Settings festgelegt.
12:23
Cleanup, Setup, Fax und der Garbage Collector sind alle Teil der Stage Command. Das muss ich dann nicht bei jedem Job einzeln festlegen. Alle vier sollen die Ansible Playbooks in einer Docker-Umgebung ausführen.
12:41
Es soll ein bestimmter Image verwendet werden und der Entry Point ist bei jedem auch gleich. Bei allen werden Skripte ausgeführt. Zum einen müssen erstmal die Ansible-Galaxy-Rollen abgerufen werden. In GitLab lege ich fest, welche Rollen aus welchen Branchen zu verwenden sind.
13:06
Da sind auch die Tokens festgelegt, damit ich lesend auf die Ansible-Galaxy-Git-Repos zugreifen kann. Das mache ich dann. Ich erstelle erstmal die Requirements.YAML und verwende das für die Ansible Galaxy,
13:20
um dann die Rollen abzurufen. Anschließend wird dann das Playbook ausgeführt. Auf die Basic-Point-YAML folgt die Basisinstallation. Abhängig davon, welchen Job ich verwende, wird ein anderer Name für das CI-Job-Name verwendet.
13:42
Das ist eine vordefinierte Variable in GitLab. Wenn ich Setup ausführe, wird Ansible Playbook mit dem Tag Setup verwendet. Wenn ich den Job Cleanup ausführe, steht natürlich dort Cleanup. Also Ansible Playbook Tags, Cleanup und dann Basic-Point-YAML.
14:01
Je nachdem, welchen Tag ich verwende, werden dann unterschiedliche Ansible-Tasks ausgeführt. Anschließend, da ich das zwei geteilt habe, einmal habe ich den Job Command und anschließend den Job Only After Setup. Da habe ich gewisse Konfigurations-Dateien von der Basisinstallation auf die Workshop-Installation zu übertragen.
14:29
Ich speichere diese Konfiguration. Jetzt habe ich das My-Config genannt, den Ordner. Das speichere ich in einer Tata-Datei, aber nur, wenn ich ein Setup mache. Denn ich führe ja nur die Workshop-spezifischen Tasks aus nach dem Setup, sonst macht das keinen Sinn.
14:47
Also das ist die Vorkonfiguration der Jobs. Und darauf greift dann das Cleanup zurück. Also hier ist es definiert. Der Garbage-Collector und Setup zum Beispiel. Und in meinem Fall wird alles manuell ausgeführt.
15:03
Kurz vor der Schulung, wenn ich einen Code committe und keine Schulung durchführe, dann macht das keinen Sinn, wenn automatisch die VM-Infrastruktur hochgezogen wird. Sondern kurz vor der Schulung wird dann durch Mausklick auf dem Play-Button ein Setup durchgeführt. Der Garbage-Collector speichert dann alles.
15:23
Für den ist dann festgelegt, dass er einen Artifact zu erstellen hat, der eine Woche zu existiert. Im Falle vom Garbage-Collector, da wird nichts manuell ausgeführt. Der wird nur ausgeführt vom Scheduler. Das kann ich im GitLab konfigurieren. Zum Beispiel soll er um 4 Uhr morgens jeden Tag ausgeführt werden
15:42
und nur durchlaufen, wenn die End of Life erreicht ist. Jetzt komme ich zu dem Workshop-spezifischen Teil. Es wurde das Basic Setup durchgeführt. Jetzt wird das Workshop-spezifische Setup durchgeführt. Hier lege ich fest, dass der Workshop-Job zur Stage Only After Setup gehört.
16:08
Unter EDC steht dann einfach derselbe Code zur Docker-Implementation. Also welches Image ich verwenden soll, welches Docker-Image, aus welchen repo usw. Hier lege ich fest, dass der Workshop, der Job, von dem Setup-Job abhängt.
16:27
Der bekommt automatisch diese TAR mitgeliefert. Im Pakti verwendet er die Konfiguration und arbeitet dann weiter. Es werden dann die Workshop-spezifischen NCB-Galaxy-Rollen gezogen und das Playbook ausgeführt.
16:42
Aber nicht auf die Basic-Punkten-Jammel, sondern auf die Workshop-Punkten-Jammel. Und in diesem Fall, also hier sieht man das schon, wir verwenden die Hetzner Cloud. Davor haben wir die Azure Cloud verwendet. Und in diesem Fall wird das Dynamic Inventory von der Hetzner Cloud verwendet.
17:01
Und dieses wiederum läuft alles manuell ab, sodass sichergestellt ist, dass nicht beim Commit dieser Job ausgeführt wird. Im Grunde habe ich dann so einen Aufbau. Ich habe mich nicht um die Infrastruktur zu kümmern, sondern ich kaufe diesen Service beim Cloud-Provider, in unserem Fall der Hetzner Cloud, an.
17:28
Der hat sich um das Datenzentrum zu kümmern, die Bare-Metal-Server. Mich interessiert selber nicht, wie die Virtualisierung realisiert ist, solange ich die VMs in einer bestimmten Konfiguration habe,
17:40
in einem bestimmten Disk-Space, mindestens zwei Gigabyte RAM zum Beispiel, oder auf Basis von CentOS. Und ich brauche auch keine Nameserver einzurichten. Das ist alles Aufgabe des Cloud-Providers. Ich habe mich nur um die Ansible Galaxy Rollen zu kümmern. Es bietet dem Schulungsteilnehmer Galaxy Rollen für das Cleanup, für das Setup und die Fax und zur Erstellung der FQDN, also der DNS-Records.
18:08
Und der Schulungsteilnehmer greift auf diese Galaxy Rollen zu, definiert in einer YAML-Datei, wie die zu nutzen sind, also wie viele VMs zu erstellen sind, wie die VMs miteinander in Relation stehen,
18:23
also welche VM sich mit welcher anderen VM per SSH verbinden darf, welche Ports geöffnet sind und so weiter und so fort. Zusätzlich zu dieser Konfiguration muss er dann natürlich die schwungsspezifischen Tasks selber schreiben, also Ansible Docker Kubernetes.
18:41
Also und wie definiere ich, wie die VMs auszusehen haben? Das ist in der default.slash-main-yaml definiert. Hier habe ich wieder einen YAML-Anker, in der ich schon mal Default-Werte gesetzt habe. Es ist festgelegt, dass zusätzlich zu der Standardkonfiguration der Firewall,
19:01
wie SSH-Port soll offen sein, alle VMs sollen angepinkt werden können und so weiter und so fort, soll jetzt in diesem Fall standardmäßig kein weiterer Port geöffnet sein. Standardmäßig soll Centos verwendet werden und standardmäßig haben alle VMs den Label Web für die Variable Host Type.
19:22
Und es werden VMs in der kleinsten Konfiguration, also CX-11 ist es bei Hetzner, verwendet. Und die VMs standardmäßig dürfen zu den anderen VMs keine Verbindungen aufbauen. Ich lege dann auch noch fest, wie die VMs zu benennen sind.
19:41
Also der gesamte Name besteht aus einem Prefix, in diesem Fall ist es die Gruppe, dann ein Delimiter, also ein Dash in diesem Fall. Und in diesem Fall heißen die VMs Master, Web 1, Web 2 und Web 3. Und der Name, der gesamte Name heißt dann Gruppe 0, Dash, Web Master oder Gruppe 1, Dash, Web 1 zum Beispiel.
20:03
Das lege ich dann in der Default-Manual fest. Und in der Variable VM Group lege ich fest, welche VMs in einer VM-Gruppe zu existieren haben. In diesem Fall ist es der Master, Web 1, Web 2 und Web 3. Und zusätzlich, und hier lege ich auch fest, inwieweit die Konfiguration von der Standard-Konfiguration abzuweichen hat.
20:27
Der Master zum Beispiel hat natürlich den Host-Type Master in unserem Fall. Der darf sich mit Web 1, Web 2, Web 3 verbinden per SSH. Web 1 zum Beispiel hat zusätzlich zu den Standard-Ports, die geöffnet sind, Pink und SSH, noch die Ports für Egg und HTTPS geöffnet.
20:46
Web 2 setzt auf Debian statt CentOS. Und Web 3 hat mehr RAM, mehr Disk Space mit dem Setzen von CX21 für Server-Type. Damit habe ich festgelegt, wie eine VM-Gruppe auszusehen hat.
21:06
Im nächsten Schritt, also in derselben Datei, lege ich auch fest, wie viele VMs zu erstellen sind. Damit ich, das ist aber im Gegensatz zu der bisherigen Konfiguration in GitLab selber festgelegt. In GitLab habe ich eine Variable definiert, Number of VM Groups.
21:23
Da kann ich vor jedem Aufruf einen Integer-Wert anlegen, 10 zum Beispiel. Und das wird dann als Umweltvariable in der Shell verfügbar. Und wird dann mit das Lookup abgerufen und in der Variable Kleingeschrieben Number of VMs abgespeichert.
21:44
Zusätzlich lege ich fest, mit welcher VM sich der Kunde selber mit seinem Laptop, mit seinem Arbeitsgerät verbinden darf. In diesem Fall ist es nur der Master. Und ich lege auch natürlich fest, welche Ports jetzt für Egg und HTTPS geöffnet sind.
22:03
Im Grunde stimmt es 1 zu 1 mit den Optionen überein, die Ansible definiert sind. Aber ich stehe vor dem Problem, dass wenn ich die Source IP nenne, die ich natürlich nicht im Vorhinein weiß. Und dafür habe ich letztlich die Namen. Also das ist der einzige Punkt, wo ich von der DoCo, von Ansible abweiche.
22:26
Und bevor ich die Firewall-Module ausführe, erst mal vom Master auf die IP-Adresse schließe und dann das Firewall-Modul von Ansible ausführe.
22:41
Und bei HTTPS ist definiert, dass der TCP-Port 443 geöffnet sein muss und über die Input-Chain. Und hier in diesem Fall soll Web1 und Web3 wieder Zugriff für Web1 und Web3 freigeschaltet und für diese eigene IP 213.155 usw.
23:12
Damit ist definiert, wie die VMs auszusehen haben, welche VMs in einer Gruppe sind, wie viele ich haben will, wie mit welchen VMs sich der Schulungsteilnehmer verbinden kann und wie die Firewall-Regeln auszusehen haben.
23:29
Das ist in der Main.yml definiert. So sieht das dann aus. Also in diesem Beispiel, ich habe den GitLab CI-CD-Runner.
23:40
Das ist ein Docker-Container, da wird das Ansible-Playbook ausgeführt. Dieser blau umrandete GitLab CI-Runner hat Schreibenzugriff auf die blau hinterlegten VMs oder Server. Er kann auf den Name-Server DNS-Records erstellen, nachdem er die blau hinterlegten VMs erstellt hat.
24:02
Natürlich müssen die erst mal erstellt werden. Es werden dann den IP-Adressen zugeordnet und dann im Anschluss wird dann beim Name-Server ein DNS-Record, ein A-Record zum Beispiel gesetzt. Der Road Warrior hat, der grün umrandete Road Warrior kann auf die grün hinterlegten Instanzen zugreifen, auf den Web-Server und den Master.
24:24
Für die gesamte Schulung habe ich einen Web-Server, auf dem die SSH-Keys bereitgestellt werden. Und da muss, für jede Instanz hier ist ein FQDN abgespeichert auf dem Name-Server. Der Road Warrior ermittelt die IP-Adresse durch Zugriff auf den Name-Server, geht auf den Web-Server, tippt Passwort und Benutzernahme ein,
24:45
lädt die TAR- oder die ZIP-Datei runter, empackt es und führt ein Bash-Script aus, in dem dann der Pfad zur Konfig, zur known-host und zur authorized-keys definiert ist. Und nach Ausführung des Bash-Scripts greift er dann auf den Master zu und
25:04
der Master wiederum, violett umrandet, kann auf Web 1, Web 2 und Web 3 zugreifen. Und je nach Konfiguration habe ich von den gelb hinterlegten Instanzen so und so viele, also wenn ich vier Schulungsteilnehmer habe, habe ich dann vier Road Warriors und vier von den gelb hinterlegten Master, Web 1, Web 2 und Web 3.
25:35
Damit haben wir uns angeschaut, wie die VOMs aufzusehen haben.
25:41
Also im Grunde, wie das Clean-Up zu verwenden ist, das Setup, dass die Facts und die Domains zu erstellen sind, das ist in dieser Main-Yaml definiert. Und im Anschluss muss der Schulungsleiter natürlich die Tasks schreiben, die für seine Schulung relevant sind. Also für die Ansible-Schulung, die Docker-Schule oder die Kubernetes-Schulung.
26:07
Wenn wir uns noch zurückerinnern, es wird in dem zweiten Schritt, in dem Only After Setup Stage, das Ansible Playbook auf die Workshop-Yaml ausgeführt und dafür ein dynamisches Inventory verwendet.
26:22
Und in diesem dynamischen Inventory sind auch Informationen zu den Labels abgelegt. Damit kann ich gewisse Tasks auf VOMs mit dem Host-Type Web anwenden oder mit dem Host-Type Master.
26:44
Dieses Skript, h-cloud-python, ist über dieses Repository verfügbar. Und da beim Ausführen dieses Python-Skrips werden gewisse Informationen bereitgestellt. Die Ansible-Tasks kann ich verwenden, um das Ausführen der Ansible-Tasks auf einen bestimmten Kreis an VOMs zu beschränken.
27:06
Also ich kann sagen, ich möchte es auf alle Hetson-Cloud-Instanzen ausführen. Oder ich möchte es auf VOMs an einen bestimmten Standort wie Falkenstein oder Nürnberg anwenden. Aber auch kann ich festlegen, dass anhand der Gesetze Labels dann bestimmte VOMs konfiguriert werden sollen.
27:26
Des Weiteren liefert mir das Python-Skript gewisse Variablen, wie die IP -Adresse, was sein Server-Type ist, die CX11, die kleineste Instanz von Hetzner, was sein Image verwenden wird, das Debian-Image, das Centos-Image, in
27:42
welchem Datencenter das liegt, also Falkenstein oder Nürnberg, und welche Labels gesetzt sind. Jetzt ein konkretes Beispiel. Die Workshop-Yaml, das habe ich jetzt möglichst einfach gehalten. Da wird die Rolle, die ich hier definiere, auf alle Hetzner-Cloud-Instanzen ausgeführt.
28:06
Und das soll unter dem RemoteUserNonRoot, das ist als Variabel festgelegt. In unserem Fall heißt es Ethics, also man sollte ja nichts als Root ausführen, wenn möglich. Also wird standardmäßig der Benutzer Ethics ausgeführt. Und dann werden die Tasks unter Verwendung der Ansible-Galaxy-Rolle ausgeführt.
28:29
Also für Workshop-Type kann man K8S setzen, dann wird dann die Ansible-Galaxy-Rolle für die Kubernetes-Schulung verwendet. Oder die Workshop-Type ist gleich Ansible, dann werden die Tasks für die Ansible-Schulung verwendet.
28:47
In diesem Fall, ein simples Beispiel, werden dann zunächst auf allen Centos-Hosts EPIL installiert. Es wird im Anschluss auf allen VMs die Editor-Nano-WIM installiert.
29:02
Und dann kann man auch unter Verwendung des dynamischen Inventories, also Edge-Cloud-Labels und Host-Type, kann man dann die Tasks auf einem bestimmten Kreis an VMs beschränken. Das ist das Schöne daran an dem Dynamic Inventory. Man muss nicht im Vorhinein eine statische Inventory erstellen, schreiben, die IP-Adressen eintragen und so weiter und so fort.
29:27
Sondern das wird alles automatisch gemacht mit Ausführung des Python-Scripts. Also wie sieht dann der Aufbau aus? Vom Cloud-Provider bekomme ich dann einfach die Infrastruktur gestellt.
29:42
Mich interessiert im Grunde nicht, wie das auszusehen hat. Das Datencenter interessiert mich nicht, was im Bare-Metal-Server verwendet wird. Also früher mussten wir die Laptops bereitstellen, das interessiert mich mittlerweile nicht. Wie die VMs virtualisiert sind auch nicht. Und Name-Server ist mir auch im Grunde egal. Wir verwenden jetzt die Name-Server von Amazon, aber ob es von Amazon bereitgestellt wird oder von Azure, das ist mir im Grunde egal.
30:07
Und ich bin eigentlich im Grunde nur dafür zuständig, die NCB-Galaxy-Räume zu verwenden. Die sind so gestaltet, dass es für das Basis-Setup, für jede Schulung verwendet werden kann.
30:26
Und da muss nur festgelegt werden, wie die VMs auszusehen haben, in welcher Konstellation sie zueinander stehen. Und zusätzlich muss natürlich dann noch festgelegt werden, wie die wirtschaftsspezifischen Tasks auszusehen haben.
30:41
Und durch diese Aufgabenteilung ist es dann möglich, mit möglichst wenigen Eingriffen eine Schulung hochzuziehen. Im Grunde, wenn man es sich ganz einfach macht, muss man nur zwei Dateien bearbeiten. Einmal festlegen, welche VMs existieren sollen. Und einmal, was zum Beispiel installiert werden soll auf diesen VMs.
31:02
Und dann kann man so eine Schulung realisieren. Ich bedanke mich für die Aufmerksamkeit. Falls es noch Fragen gibt, könnt ihr mich dann nach dem Vortrag ansprechen. Aber wir sind auch auf der OSA, das ist unsere eigene Konferenz.
31:20
Die findet im Oktober statt, vom 15. bis zum 16. Da geht es um Open Source und Automation. Und falls ihr als Speaker dort auftreten wollt, könnt ihr euch an uns wenden. Und das ist, soweit ich weiß, die größte Open Source-Konferenz in Süddeutschland. Und wir würden uns freuen, wenn wir euch dort treffen.
31:43
Am besten trittet ihr dort auch als Speaker auf. Vielen Dank. Wenn ich das richtig verstanden habe, müssen also die Schulungsleiter auch Ansible-Konfiguration schreiben.
32:01
Ist das nicht ein bisschen Overkill? Also wenn ich überlege, jemand will eine Schulung machen, dann hat er ein Schulungsthema und da ist er drin. Aber weil er ja bestimmen muss, was in den VMs sind, muss er ja dann diese Ansible-Konfiguration schreiben. Wenn der Schulungsanteil, wenn das ein Windows-Administrator ist und er sich nicht auskennt
32:21
und eigentlich nur über die Web-Uberfläche arbeitet und die Schulung über die Web-Uberfläche realisiert, dann unterstütze ich ihn natürlich beim Einrichten der Ansible-Konfiguration. Also da werde ich nicht sagen, es ist meine einzige Aufgabe, es ist nur die Ansible-Rollen zu schreiben.
32:40
Wie du die jetzt nutzt, ist mir völlig egal. So bin ich nicht. Hast du irgendwo die Skripte, die du benutzt online? Die sind bei uns im internen Git. Das habe ich gesehen. Was möchtest du sehen? Einfach mal dann zum selber rumspielen.
33:03
Da muss ich mich mit dem Team absprechen. Jetzt möglich wäre das ziemlich cool. Du sagtest, irgendwo werden dann noch mal Shell-Skripte ausgeführt. Also es wird sehr viel mit Ansible gemacht, mit den Playbooks und so was.
33:23
Und dann gab es noch, dass irgendwo noch ein Shell-Skript aufgerufen werden muss. Was macht das noch mal? Die GitLab hat eine besondere Eigenheit. Es ignoriert, was in der Docker-File als Entry-Point festgelegt ist.
33:44
Und da ich hier auf Variablen zugreife, wie CI-Job-Name und jetzt hier eine If-Bedingung habe, führe ich jetzt die Shell aus und zur Verwendung von dem hier. Damit ich jetzt hier in dem Beispiel oder hier ist CI-Job-Name.
34:01
Wenn ich als Entry-Point jetzt nicht das setzen würde, dann könnte ich jetzt bei der Ausführung von Ansible-Black-Playbook jetzt nicht auf CI-Job-Name zurückgreifen als Umweltvariable. Das ist mir aufgefallen. Deshalb habe ich jetzt, das ist das einzige Mal, wo die Shell verwendet wird. Sonst werden die Skripte nur ausgeführt, also die Befehle nacheinander ausgeführt.
34:28
Das heißt, das Shell-Skript wird beim ersten Hochfahren der VM oder des Containers ausgeführt oder zu welchem Zeitpunkt? Also wenn ich jetzt, ich habe es hier.
34:43
Hier lege ich jetzt erstmal fest. Ist das groß genug? Nein, das ist nicht groß genug. So, hier lege ich fest. Number of VM Groups. Sagen wir jetzt, damit es schneller abläuft, 10. Das sind jetzt meine selbst definierten Variablen.
35:02
Und standardmäßig, wir verwenden letzten Skript, also die SSH-Keys werden auf dem Web-Server abgelegt, der mit SSL geschützt ist, unter Verwendung von letzten Skript-Zertifikaten und natürlich passwortgeschützt. Die Frage ist, wann wird dieses Shell-Skript denn ausgeführt?
35:22
Das ist mir nicht klar. Also wenn ich jetzt hier auf Setup klicke, dann wird die Shell ausgeführt mit Parameter dash C
35:45
und dem wird dann der Ansible Playbook Befehl übergeben. Und das mache ich, damit ich auf die Umweltvariablen zugreifen kann. Also wenn ich als Entry Point nur Ansible Playbook setze,
36:05
dann kann ich nicht auf diese Umweltvariablen zurückgreifen. Number of VMs oder den Namen von dem CI-Drop. Deshalb habe ich als Entry Point SH und mit der Option dash C gesetzt.
36:30
Ich denke, wenn du das nicht setzen willst, also wenn du nicht diesen Entry Point als Shell-Skript oder die Bash oder irgendeine Shell als Entry Point hättest, sondern halt Ansible, dann führt er halt Ansible aus. Und dann kannst du auch in dem Skript von dem GitLab Stage
36:47
nicht irgendwelche anderen Kommandos ausführen. Also das ist eigentlich die nötige Voraussetzung dafür, dass überhaupt GitLab CI funktioniert. Also jetzt rührt es ja vor sich hin, arbeitet das durch.
37:02
Hier sieht man schon, da sind Firewall-Regeln festgelegt. Also und so weiter und so fort. Es werden DNS-Records gesetzt für die VMs. Also erstmal werden die VMs erstellt, dann werden jetzt die DNS-Records gesetzt in Amazon Route 53. Und zum Schluss sollte ich einen Web-Server haben.
37:22
Also jetzt werden letzten Kript-Zertifikate erstellt für den Web-Server, den einen Web-Server, auf den die Schulungsteilnehmer dann zugreifen. Ich weiß jetzt nicht, wie lange das dauert. Ich habe jetzt nur eine Gruppe erstellt, aber das ist jetzt auch, glaube ich, nicht so interessant. Gibt es noch weitere Fragen?
37:42
Ja, da hinten. Habt ihr überlegt, einen Docker Swarm zu verwenden? Also zu Beginn gab es nur die Vorgabe, es soll GitLab verwendet werden, die CI-CD und Ansible. Und darüber haben wir uns noch keine Gedanken gemacht.
38:00
Okay, gut. Also was ich meinte ist, man kann ja verschiedene User, man kann verschiedene Docker-Container den Usern zuordnen und dann hätte man quasi für jeden User eine Umgebung,
38:21
woran er arbeiten kann. Und das läuft dann alles über Docker-Container. Und der Swarm generiert eben die verschiedenen Docker-Container für alle User. Darüber haben wir uns noch keine Gedanken gemacht. Was wir vielleicht demnächst machen,
38:42
wir verwenden dann vielleicht die Registry von GitLab. Das müssen wir aber noch anschauen.
39:09
Also dann stehen die Keys, ich weiß nicht, ob der Web-Server läuft, stehen dann hier bereit. Also jetzt habe ich,
39:21
ich habe zwei VM-Gruppen, glaube ich, erstellt. Ich weiß es nicht. Aber der Trainer bekommt Keys gestellt, bei denen er auf alle Vm-Gruppen zugreifen kann. Dann hat der User 0 und der User 1 seine eigenen Keys, mit denen sie auf ihre eigenen Vm-Gruppen zugreifen können. Und das ist dann mit das SSL gesichert.
39:41
Und die Passwörter bekommen die Schulungs-Teilnehmer natürlich. Und dann klicken die drauf, tippen die Benutzernamen und das Passwort ein und laden sich die Dateien dann runter.
40:03
Natürlich Demo. Wenn es keine weiteren Fragen gibt, ihr könnt mich an unserem Stand, der ist gleich hier um die Ecke, vorfinden, auffinden. Und natürlich auf der U-Site. Vielen Dank für die Aufmerksamkeit.