Automatisierte Linux-Wartungsarbeiten mit katprep
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/45588 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FrOSCon 201989 / 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
LINUXHTTPSystem administratorAutomatonVirtualizationXMLUMLMeeting/Interview
00:27
Enterprise architectureGoogle BloggerPoint cloudSAP <Marke>Mainframe computerApple <Marke>Run-time systemHypercubeTelecommunicationAlgebraic closureSystem administratorFocus (optics)XMLUML
03:00
SAP <Marke>InternetdienstMainframe computerService (economics)InformationDesktopPoint cloudBackupData recoveryServer (computing)SoftwareSAP Solution ManagerComputer hardwareIBMEnterprise architectureVirtualizationSingle-precision floating-point formatLINUXPhysikDistribution (mathematics)Product (category theory)Service (economics)SAP <Marke>Data centerStandard deviationRoute of administrationDistribution (mathematics)Ubuntu <Programm>Hyper-VHigh availabilityRun time (program lifecycle phase)Process (computing)Single-precision floating-point formatPhysikProgram flowchart
08:13
High availabilityBackupPhysikDistribution (mathematics)Single-precision floating-point formatLINUXEnterprise architectureSystems <München>Computer animation
09:11
LINUXBruchteilPatch (Unix)Systems <München>BruchteilXMLUML
10:06
System administratorInterface (computing)AutomationPatch (Unix)Form (programming)Statement (computer science)Systems <München>Interface (computing)Lecture/ConferenceMeeting/InterviewXMLJSON
11:09
AutomationNeWSInformationTask (computing)Patch (Unix)Greatest elementFile formatHTMLInformationChecklistIP addressComputer animationXML
11:40
Task (computing)Computer wormPatch (Unix)TypService PackXML
12:20
Greatest elementInformationTask (computing)Patch (Unix)Kernel (computing)InformationIP addressFactorizationPDF <Dateiformat>Template (C++)Bus (computing)Operating systemMAKROSComputer animationDiagramMeeting/Interview
13:01
Data centerHyper-VNagiosSoftware development kitComputer animation
13:48
Mainframe computerParameter (computer programming)FORTRANZahlForm (programming)Systems <München>Mobile appCodeDirection (geometry)Component-based software engineeringVAX/VMSDisintegrationComputer animationLecture/ConferenceMeeting/Interview
14:55
Open sourceMainframe computerPatch (Unix)
15:22
Patch (Unix)Plane (geometry)Client (computing)InternetdienstGraph (mathematics)Mainframe computerBefehlsprozessorInvertible matrixQuantum stateSystem administratorSystems <München>Patch (Unix)DemosceneVAX/VMSExplosionInternet forumComputer animation
17:18
Open source
17:50
Object (grammar)Aktion <Informatik>Computer animation
18:35
Client (computing)IMSUser interfaceWorld Wide WebServer (computing)POWER <Computerarchitektur>InformationLocal area networkWebsitePOWER <Computerarchitektur>Computer animation
19:03
Computer wormSimulationIMPMenu (computing)IMSMono-FrameworkService (economics)DemoscenePasswordPlane (geometry)Computer animation
19:32
Mainframe computerPasswordRollbewegungTask (computing)Large eddy simulationSystems <München>InformationForm (programming)IP addressPatch (Unix)Computer animation
20:53
InformationMainframe computerMechanism designComputer animation
21:20
SSLUniform resource locatorEckeSound effectInformationSource codeJSON
22:23
Set (mathematics)SQLParameter (computer programming)UpdateUMLCapability Maturity ModelMilan <Programmiersprache>Form (programming)InformationVAX/VMSUniform resource locatorTypDemosceneMobile appSource codeComputer animation
23:18
TypHTTPUser interfaceRevision controlInformationSystems <München>Parameter (computer programming)Form (programming)Server (computing)AutomatonSSLComputer animationSource code
25:15
Task (computing)UpdateLINUXMach's principleComputer animationSource code
25:42
Invertible matrixComputer musicForm (programming)ExplosionHTMLFile formatInformationTemplate (C++)Patch (Unix)PDF <Dateiformat>Computer fileComputer animationSource codeJSON
27:17
Task (computing)InternetdienstGraph (mathematics)Transport Layer SecurityContent (media)APIComputer animation
27:50
Workstation <Musikinstrument>Mechanism designRun-time systemPatch (Unix)APIScripting languageContent (media)Electronic visual displayUbuntu <Programm>DemosceneDebian GNU/LINUX
31:21
APILimitierungsverfahrenOpen sourceLecture/ConferenceMeeting/InterviewComputer animation
32:09
Direction (geometry)CodeWEBForm (programming)Function (mathematics)Patch (Unix)Computer animationMeeting/InterviewLecture/Conference
33:51
WalkthroughSoftware bugCodeComputer animationXML
Transcript: German(auto-generated)
00:08
Ja, wunderbar. Schönen guten Abend. Willkommen zu meinem Vortrag automatischer Linux-Systemverwaltung mit CADBREP. Sorry, dass es jetzt noch fünf Minuten länger gedauert hat, aber jetzt können wir auch loslegen.
00:21
Mein Name ist Christian Stankovic. Ich bin System Engineer bei der SVA und beschäftige mich dort mit den Themengebieten Virtualisierung, Enterprise, Linux, weswegen wir hier auch inhaltlich ganz gut aufeinandertreffen, Monitoring und den ganzen Hype-DevOps-Themen, also GITS, Scrum, Agiles Gedöns, Infrastructure,
00:42
S-Codes und so die Themen, die ich da bei uns betreue. Und heute geht es um automatische Linux-Systemverwaltung. Deswegen schlage ich vor, werfen wir mal einen kurzen Blick auf die Agenda. Zuerst würde ich euch kurz etwas über die SVA erzählen. Das halte ich sehr kurz, das verspreche ich euch. Das soll ja keine Marketingveranstaltung werden, sondern wir sind hier Praktiker.
01:02
Deswegen soll es mehr um die Technik gehen. Danach schauen wir uns mal den Status Quo der Systemverwaltung an und wie Cutprep hier eben unterstützend helfen kann. Dann schauen wir uns die Architektur von Cutprep an. Dann habe ich zwei Demos vorbereitet, die ich euch gerne zeigen möchte. Und zum Abschluss würde ich euch gerne einen kleinen Ausblick geben,
01:22
was für die Zukunft so geplant ist und auch gerne eure Fragen beantworten. Gut, dann ganz kurz zur Firma. SVA steht für Systemvertrieb Alexander GmbH. Und wir sind Deutschlands größtes Inhaber geführtes und nicht Investor getriebenes Systemhaus.
01:40
Und haben mit mehr als 1100 Mitarbeitern ein sehr starkes Wachstum. Und unsere Überlegung ist es eben, die Kunden langfristig in allen Prozessschritten zu begleiten. Das heißt, das beginnt mit der Entwicklung einer Idee, also einer Anfrage, geht über die Betreuung des Kunden bis hin zur Lieferung. Und zu unseren unternehmerischen Zielen gehört eben,
02:02
dass wir eine motivierende Umgebung für Mitarbeiter und Partner zur Verfügung stellen wollen, eine Wertschätzung des Kunden bekommen wollen und Qualität und Integrität sind unsere beiden Hauptmerkmale. Und unser Hauptmantra ist im Prinzip, dass wir Qualität statt Quantität liefern wollen. Also dadurch, dass wir auch nicht Investor getrieben sind, können wir da eben unseren Fokus auch nochmal selbst ein bisschen besser kontrollieren.
02:25
Wir sind, unsere Hauptzentrale ist in Wiesbaden, zu der ich auch angehöre. Aber wir haben mittlerweile 18 Standorte deutschlandweit und sind in sechs Top-Branchen unterwegs, zum Beispiel Automotive, Retail, Public, Maschinen- und Anlagenbau, Finance und Telekommunikation.
02:42
Und wir kommen eigentlich ganz klassisch aus dem Mainframe- und Datacenter-Infrastructure-Bereich, also so ganz typische Themen wie Backup, Storage, sind so Themen, die wir betreuen, haben aber auch im Laufe der letzten Jahre sehr viele neue Themen für uns herausgefunden und sind jetzt zum Beispiel im End-User-Computing unterwegs, Big Data, SAP, Service Management, Security
03:03
und wir vertreiben auch eigene Produkte. Aber das nur am Rande, soll ja kein Marketing werden, sondern wir wollen hier über die Technik reden. Deswegen lasst uns doch mal einen Blick auf den Status quo der IT werfen, also nicht auf die Erwartung, sondern den Unterschied zwischen
03:21
Marketing und wie es in der Realität aussieht. Also die ideale Welt, wie wir sie uns vorstellen, wäre ja eher so das hier, so ein schickes Rack, das sauber verkabelt ist, alles auch farblich sehr schön, irgendwie klar, wohin die Leitungen gehen. Wer von euch hat sowas schon mal gesehen,
03:40
in echt und jetzt mal wirklich ehrlich, oh, da gehen echt viele Hände hoch, in welchem Kontext, wenn ich fragen darf. Also ihr macht das alles sehr strukturiert und sehr ordentlich?
04:01
Okay, alles klar. Gut, also wer von euch hat das selbst schon mal bei seinem eigenen Arbeitgeber, der selbst verkabelt, vorgefunden? Warum? Okay, du warst bei der Bundeswehr und hast dann Ordnung und Prozesse gelernt.
04:22
Okay, gut. Das klingt nachvollziehbar. Die Antwort war, dass einer der Anwesenden hier bei der Bundeswehr war und da eben Prozesse gelernt hat und deswegen alles sehr akkurat verkabelt wurde,
04:42
aber meistens sieht es eher nicht so aus. Aber so wünschen wir das uns, dass alles schön strukturiert ist, alles klar. Wir wollen so Dinge wie globale Standards oder um mal so ein paar Marketing Bullshit-Buzzwords mit reinzubringen, die wir alle schon gelesen haben und sie scheuert finden, Single-Pane-of-Glass oder Automation
05:03
oder Self-Driven-Operation-Self-Healing-Apps sind ja so die Buzzwords, die man immer so findet, wenn man so tolle Hersteller-PDFs liest, Cloud-Native-Infrastructure-as-Code und so weiter. Das könnten wir jetzt stundenlang fortführen, irgendwann Bingo schreien, wenn man fünf Bullshit-Wörter zusammen hat, aber das wäre ja viel zu einfach.
05:21
Also, wo wäre denn da die Herausforderung, wenn wir mit so einer halben Welt zu tun hätten? Das ist ja eher so die Realität. Hier alles schön querfällt ein, gar kein Konzept. Wer hat das schon mal bei so einem Arbeitgeber gesehen? Okay, da gehen deutlich mehr Hände hoch. Genau. Genau, also das ist ja eher die Realität.
05:41
Sowas sieht man eher. Das heißt, wenn wir jetzt nochmal vergleichen, wir haben hier keine Automation, wir haben hier manuelle Prozesse, wir haben keine Standards, viele Tools oder mehrere Monitorung-Lösungen, mehrere Hypervisor, kein Konzept dahinter. Und was ich ja ganz schön finde,
06:01
das ist historisch bedingt. Also, wenn ich jedes Mal einen Euro kriegen würde, wenn ich diesen Satz vom Arbeitgeber oder vom Kunden gehört habe, dann müsste ich vermutlich nicht mehr arbeiten gehen. Und ja, legacy-Applikation. Oder Single Pain of Glass. Nicht Pains, sondern Pain. Also, das ist eher so das, womit man sich rumschlagen muss.
06:22
Da kennen wir uns aus. Damit schlagen wir uns jeden Tag rum. Gut, also fassen wir es mal zusammen. Schlussendlich ist es so eine Single-Render-Strategie, die ist auch in Berlin relativ selten anzutreffen. Zum Beispiel, wer mit Enterprise-Applikationen zu tun hat, der kennt das. Also, als Beispiel SAP. SAP auf Ubuntu zu betreiben,
06:41
mag technisch vielleicht machbar sein, in der Realität aber eher nicht so häufig anzutreffen. Und deswegen reicht es meistens nicht aus, eine Distribution in der Rechenzeitung zu betreiben. Man braucht da mehrere. Und im Prinzip ist es so, dass M-zu-N-Beziehungen die Standardisierung verhindern. Das heißt, wir haben eine oder mehrere Applikationen.
07:02
Die laufen entweder auf Physik oder auf Hypervisor, können auch mehrere sein. Vielleicht mal ein VM-Ware, vielleicht mal ein Hyper-V. Da haben wir verschiedene Distributionen. Für SAP haben wir vielleicht einen Slash. Für andere Web-Geschichten haben wir vielleicht einen Ubuntu. Das ist bunt gemischt. Wir haben mehrere Major-Releases. So ein SAP-System installiert man ja auch nicht, alles vor Jahren neu,
07:20
bloß weil ein neues Red Hat oder ein neues SUSE rauskommt. Und das Toolset ist halt auch nochmal in unterschiedlichen Konstellationen. Ich habe vielleicht mehrere Backup-Lösungen, mehrere Monitoring-Lösungen. Auch das kann vorkommen. Die eigentliche Systemwartung wird dann aber noch erschwert, weil häufig ist es so, dass man feste Wartungsfenster geringer Größe hat.
07:41
Zum Beispiel ein Wochenende im Monat oder vielleicht nur ein paar Stunden. Je nachdem, was für eine Verfügbarkeit man dem Kunden zur Verfügung stellen muss. Dann ist auch immer so ein Thema Verfügbarkeit gegenüber dem Design. Man hat irgendeine kleine Gammel-Anwendung. Die soll nur zum Test benutzt werden. Dann geht die live. Man will die patchen und merkt, hoppla, die ist ja live gegangen.
08:00
Auch das ist bestimmt dem einen oder anderen von euch schon passiert. Live-Patching ist jetzt ja auch wieder so ein relativ neues Thema. Wobei eigentlich auch nicht, aber so ein Hype, dass man sagt, okay, wir machen jetzt Kern-Live-Patching, weil dann muss ich mein System ja nie wieder rebooten. Ist halt auch ein falscher Druckschluss an der Stelle. Ein weiterer Klassiker ist Testsysteme.
08:21
Häufig ist es so, dass es heißt, ein Testsystem, das machen wir jetzt mal nicht, weil da brauchen wir ja wieder mehr Hardware, mehr Systeme. Wir müssen unter Umständen mehr Lizenzen erwerben. Da ist man häufig als Manager ein bisschen geizig und sagt, nein, das wird schon passen, kauft es nicht und stellt dann fest, das wäre ganz gut gewesen, wenn man ein Testsystem gehabt hätte, dann hätte man Dinge eben
08:41
vorher ausprobieren können. Je nachdem, wie das Unternehmen zertifiziert ist, für das man arbeitet, also Schlagwort an der Stelle ist ISO IEC 27001 in verschiedenen Ausprägungen. Da muss ich das Ganze ja auch TÜV-konform dokumentieren. Ist das Thema für einen von euch relevant, ISO 27001?
09:01
Okay, gut. Kann halt eben auch eine Anforderung sein, dann die Dinge da entsprechend zu dokumentieren. Also schlussendlich ist es halt extrem chaotisch. Man muss irgendwie her dieser Lage werden. Und das ist nicht immer so einfach. Im Prinzip ist es so, Wartungsarbeiten sind recht komplex, wobei das
09:21
eigentliche Doing, also das eigentliche Patchen der Systeme ist ja nur ein Bruchteil der Arbeit. Also ein Jam-Update zu machen oder ein Update-Upgrade ist jetzt nicht so die Herausforderungen, das Vorqualifizieren und das übliche Vor- und Nachgeplänkeln nehmen die meiste Zeit den Anspruch. Also ich muss erstmal in irgendeine Art und Weise Snapshots oder Backups der Systeme
09:41
erstellen. Dann muss ich mein Monitoring ausplanen, dass die Viralschaft vielleicht nachts nicht aus dem Bett geklingelt wird. Dann muss ich meine Benutzer in irgendeine Art und Weise vorher informieren, dass Wartungsarbeiten stattfinden und die eigentliche Wartung ausführen und anschließend das Ganze dann auch noch in irgendeine Art und Weise dokumentieren. Und diese ganzen Teilschritte
10:01
die könnte man halt automatisieren, um sich Zeit und vor allen Dingen Nerven zu sparen, habe ich mir gedacht. Was dabei rausgekommen ist, ist eben dieses Tool Cut Prep. Der Beispiel der Namensgebung ist extrem kreativ, wie ich finde. Das steht nämlich für Catello Patch Preparation. Und ist ein Python Kommandozahlen Tool, was eben diese
10:20
Teilschritte automatisieren kann. Und ist im Prinzip eine zentrale Schnittstelle für Formen und Catello, beziehungsweise die Hypervisor und die Monitoring Lösungen, die ich eben verwende. Und das Resultat daraus ist eben, dass ich große Systemlandschaften mit geringerem Aufwand verwalten kann. Denn im Endeffekt, egal ob ich ein System oder tausend Systeme habe,
10:40
ich kann die mit vier Befehlen vollständig patchen. Das bedeutet, um nochmal auf das Thema der Teilschritte zurückzukommen, was Cut Prep machen kann, ist, wenn es um die Vorbereitung geht, es kann Snapshots erstellen und kann man Monitoring entsprechend ausplanen. Es kann danach in der Wartung die Software-Aktualisierung installieren und die betroffenen Systeme, wenn es denn benötigt
11:00
ist, auch neu starten. Und abschließend beim Thema Dokumentation kann es eben auch die tierfähige Wartungsberichte mir rauspurzeln lassen und das Ganze, die ganzen Snapshots auch wieder aufräumen. Sodass ich dann nicht im Nachhinein alles manuell wieder machen muss. Diese Wartungsberichte, diesen Modular, also da verwende ich ein Framework, das ich Pandoc nennt, kennt vielleicht der eine oder andere von euch.
11:22
Da kann ich eben verschiedene Formate auswählen, wie mein Bericht aussehen soll. Hier mal ein kleines Beispiel, das ist hier ein ganz einfacher HTML Report. Da kann man dann irgendein Logo einbinden, sieht dann so Informationen wie IP-Adresse, Datum, Uhrzeit, wem gehört das System. Dann so eine Art Checklist. Also das ist ein Dokument, das haben wir zusammen mit dem TÜV mal
11:42
erarbeitet, dass zum Beispiel ein Snapshot erstellt wurde, dass mein Monitoring deaktiviert wurde, dass ich das System rebooted habe, wie der Monitoring-Status ist und ob mein Monitoring wieder aktiviert wurde, sodass ich so einen Vorher-Nachher-Zustand habe und unten eben nochmal aufgeschlüsselt die einzelnen Patches, die installiert wurden, klassifiziert in was für ein Typ war, Bugfix oder Feature Enhancement,
12:02
auch nochmal der offizielle Name des Distributors, wie der Patch heißt, eine Beschreibung, was eigentlich genau gemacht wurde und schlussendlich ob ein Reboot benötigt wurde. Das Ganze ist natürlich modular, das kann man sich gestalten, wie man möchte. Ich finde zum Beispiel folgendes ganz ansprechend.
12:21
Dann hat das Ganze, das langweilige Dokumentieren auch einen leicht spaßigen Faktor, das nehme ich ganz gerne, aber man kann auch die Art und Weise, wie das aussieht, also das Format, kann man auch noch ändern. Also man kann hier zum Beispiel andere Felder mit reinnehmen, sieht man vielleicht, dass hier noch ein paar andere Informationen drin sind, eben nicht nur IP-Adresse und die ganze Metainformation, aber auch so Sachen wie
12:43
Puppet-Environment, wenn ich das eben einsetze, auch die Location, wo sich das System befindet, welches Betriebssystem installiert ist. Also all die Metainformation, die mir Format und Kartello über ein System liefern, die kann ich hier referenzieren in Form von Makros. Also ich kann mir mein eigenes Temp-Bait bauen, das kann auch gerne irgendwie ein PDF sein oder Markdown, je nachdem,
13:03
was ich eben gerade brauche. Zu den Integrationen, ich hatte ja erwähnt, dass sich das Ganze in Halberweisse und Monitorunglösungen integriert, das sieht es aktuell so aus, dass wir einmal eine tiefe Python-VSphere-Integration haben mit dem offiziellen SDK von VMware und dann wird LibVirt angesteuert und über LibVirt
13:22
kann ich ja verschiedene Halberweisse ansteuern, also zum Beispiel KVM, Xen, Chemo sind so die gängigen, aber auch so Dinge wie Hyper-V oder Virtual Box sollten prinzipiell unterstützt sein. Bezüglich des Monitorings ist aktuell Nagios bzw. Isingar 2 integriert und kann dann eben nativ angesteuert
13:40
werden. Und was Cardprep eben auch liefert, ist, wenn ich mir das mal vorstelle, ich habe ein Rechenzentrum mit 500 Servern, die ich irgendwie patche, dann will ich ja nicht manuell zuordnen diese VM auf dem Host, dem Monitorungssystem. Das kann Cardprep automatisch erkennen, da gibt es eine Auto-Discovery-Funktion, das heißt, Cardprep kann dann eben die einzelnen
14:01
Systeme durchsuchen und findet dann aufgrund von Name und IP raus, was zusammengehört und speichert das dann innerhalb Formen als Puppet-Parameter. Für die Zukunft haben wir noch ein paar weitere Integration geplant. Was relativ schnell gefordert wurde, war Check-MK bzw. Live-Status und Spacewalk bzw.
14:20
OUni wäre auch noch eine Option, die häufig gefragt wurde. Splunk und Zappix wurden auch schon mehrfach genannt. Da habe ich auch schon entsprechende Github-Issues mal aufgemacht, mal gucken, wann der Code da folgt. Gut, dann zur Architektur. Das Ganze ist relativ simpel gehalten, keine Datenbanken, keine Container, kein Backend, was man braucht. Das ist einfach nur ein ganz einfaches Python-Tool,
14:42
das eben API-Calls macht in Richtung Formen und Kartello, in Richtung der Hyperweise, auf dem die VMs ausgeführt werden und in Richtung Monitoring. Also relativ simpel, ich kann das einfach installieren, brauche keine weiteren Komponenten wie Datenbanken, kann loslegen. Der Workflow sieht wie folgt aus.
15:01
Der erste Schritt ist es, ein sogenanntes Inventory zu erstellen mit dem Cut Prep Snapshot-Commando. Das ist halt eine vollständige Ist-Aufnahme. Das heißt, da guckt das Tool, welche Hosts habe ich, in welchen Zuständen, welche Patches stehen aus, wo läuft das System, auf welchem Hyperweise, wo wird das überwacht. Dann habe ich meinen Ist-Zustand quasi. Und dann kann ich mit Cut Prep Maintenance
15:22
die einzelnen Aufgaben steuern. Das heißt, meine Vorbereitungen, das Erstellen der Snapshots, Ausplanung des Monitorings über Installation der Patcher, Rebooten der Systeme und Aufräumen der Snapshots und des Monitorings. Und wenn ich das gemacht habe, würde ich eben nochmal eine Ist-Aufnahme des Zustands machen, nach der Systemverwaltung.
15:42
Dann habe ich ja zwei Zustände. Und die werden dann von dem Cut Prep Report Commando ausgewertet, um Delta zu generieren. Und dann ist eben klar, was passiert ist. Und dann werden pro System entsprechende Reports erstellt, sodass ich die dann TÜV-konform ablegen kann. So, dann zum Thema Demo. Ich habe mir gedacht,
16:02
ich bin schon viel zu lange in der IT unterwegs und weiß, dass Live-Demos nie funktionieren. Deswegen habe ich da mal zwei Demos für euch aufgenommen. Und zwar das eine ist eben das Auto-Discovery mit dem Hypervisor und dem Monitoring-System. Dass man eben sieht, wie da das Auto-Discovery funktioniert. Und das zweite, was ich euch gerne zeigen möchte, ist eben das Patchen eines Systems
16:22
mit einer anschließenden Berichterstattung. Vielleicht kurz zur Umgebung, wo das Ganze aufgenommen wurde. Das ist so eine kleine Home-Lab-Umgebung, so ein kleiner Vis-Fir 6.5-Cluster, bestehend aus zwei Knoten, mit ein paar VMs, die da halt eben laufen. Und das sind alles CentOS-Maschinen.
16:41
Und auf der anderen Seite sind ja zwei Installationen, wo eben besagte VMs überwacht werden. Und das gilt es jetzt eben mit Hilfe von Cut Prep zu analysieren und aufzunehmen. So, jetzt hoffe ich, dass das mit dem Video hier funktioniert. Nein, das war es nicht.
17:25
Na gut. Dann machen wir das eben schnell so.
18:14
Gut. So, was wir hier sehen, ist einmal da wird ein Service-User auf der Isingar 2-Umgebung erstellt.
18:22
Das wird gemäß der Dokumentation eben gemacht. Benutzername, Passwort, der bekommt die Berechtigung, um eben Objekte auszulesen und Aktionen zu trickern. Also das Ausplanen von Benachrichtigungen eben. Das gleiche wird jetzt auch auf der v4-Seite gemacht. Da wird eine Rolle eingerichtet.
18:44
Das ist auch alles in der offiziellen Cut Prep-Dokumentation zu finden, welche Berechtigungen gebraucht werden. Also eben Power On, Power Off, Reset, erstellen und löschen von Snapshots und wiederherstellen von Snapshots. Denn Cut Prep ist auch in der Lage, wenn eine Erwartung fehlerhaft war, den Snapshot wiederherzustellen, sodass mein System wieder in einem funktionalen Zustand ist.
19:01
Das heißt, diese Rolle wird hier eben hinterlegt. Anschließend wird ein Service Benutzer angelegt für Cut Prep, der jetzt in dem Fall Demo Cut Prep heißt, ein Passwort bekommt, Vorname, Nachname, das übliche Szenario eben. Und bekommt dann auf globaler vCenter-Ebene eben die Berechtigung zugewiesen, sodass er
19:21
dann jede VM entsprechend über diese Rolle steuern kann. Das kann man natürlich auch nur auf Ordnerebene machen, je nachdem wie es nach dem eigenen Konzept am besten passt. Das gleiche machen wir jetzt auch nochmal auf der v4-Main-Seite. Das heißt, auch hier legen wir einen Benutzer an. Ich vergebe also wieder Benutzername, Vorname, Nachname, eine E-Mail-Adresse
19:41
und ein Passwort. Und unter Rollen wird hier benötigt einmal Hosts auslesen, Tasks auslesen und generelle Leserechte. Denn ich muss ja Informationen wie IP-Adressen und Hostnames und Patches auslesen können. Dann gibt es ein Tool Cut Prep Auth-Config. Das ist im Prinzip eine Passwort- Container-Lösung. Denn es wäre ja
20:02
wichtig, wenn man ein System oder ein System, wo System und wo Monitoring immer den Benutzername eingeben müsste. Der Sinn des Ganzen soll ja sein, dass das automatisiert stattfindet. Das heißt, ich hinterlege jetzt für meine ganzen Systeme halberweise Monitoring, Formen, hinterlege ich die Service-Benutzer, die wir gerade angelegt haben. Und dann kann ich mir eben das Eingeben der Zugangsdaten sparen.
20:22
Den Passwort-Container, das ist eine JSON-Datei, wo das eben alles drin liegt, das kann ich auch verschlüsseln. Sodass man dann, wenn man den Passwort-Container verwendet, eine Art Master-Passwort eingeben muss, um den benutzen zu können. So, und hier sieht man jetzt, hier wurde jetzt für Formen schon ein Benutzer angelegt. Mit dem List sieht man, dass eben für das System Benutzername und Passwort
20:41
vergeben wurde. Und jetzt hier werden eben die Zugangsdaten noch für das V-Center hinterlegt, für das Monitoring, sodass jetzt alle Informationen vorliegen. Genau, mit dem Master-Passwort. So, und was man dann sieht, wenn man zwischen Hosts auf Formen-Seite anguckt, oder was wir gleich sehen werden, ist, hier unten
21:01
gibt es ja diesen Reiter Host-Parameters. Da sind im Prinzip Informationen, die hinterlegt werden, die den Host betreffen. Und Cutprep nutzt eben diesen Mechanismus, um die Informationen über den Hypervisor und das Monitoring zu hinterlegen. Das heißt, Pro System kann ja an andere Hypervisor oder an eine andere Monitoring-Lösung verwendet werden. Und das wird dann hier gleich eingetragen.
21:29
So, und da gibt es eben dieses Populate-Kommando. Das eben dann dieses Auto-Discovery macht. Dem gebe ich einmal diesen Passwort-Container. Mit Insecure kann ich die SSL-Überprüfung skippen.
21:40
Da es eine Lab-Umgebung ist, habe ich keine CA. Dann übergebe ich hier einmal den Formen-Server. Übergebe dann die URL des Hypervisors, was in dem Fall das V-Center ist. Übergebe dann noch die URL für das Monitoring-System, was ja in dem Fall eine Isingar-2-Installation ist.
22:06
Und mit "-n", das ist so der Schalter für Cutprep, der halt immer so einen Dry-Run gemacht. Und den sollte man auch wirklich nutzen, immer mal gucken, was würde denn jetzt passieren, sodass ich da dann keine unerwarteten Effekte habe. Und, na, das wird jetzt hier gemacht. Das heißt, hier wird erstmal geschaut,
22:22
welche Informationen sind denn zu finden im V-Center und in der Isingar-Installation. Und hier zum Beispiel sieht man, dass jetzt Pro-System gefunden wurde, auf welchem V-Center das liegt, wie die VM heißt. Weil das VM-Objekt kann ja einen anderen Namen haben als im Formen. Also zum Beispiel hat man keine Lust, einen FQDN im V-Center einzugeben.
22:42
So war es in dem Fall auch. Und dann sieht man hier an der Stelle die ganzen Informationen zusammengetragen. Das heißt, das Monitoring-System habe ich hier, den Typ, die URL zum Hypervisor, wie das Objekt heißt im Hypervisor und was für ein Typ das ist. Das heißt, jetzt ist für Formen klar, welche Monitoring- lösung und welche Hypervisor für ein System
23:02
zuständig ist. Das kann ich auch beliebig oft ausführen. Also wenn ich jetzt in meine ganzen VMs migriere, kann ich das einfach nochmal ausführen. Und dann werden diese Informationen entsprechend nachgetragen, beziehungsweise aktualisiert. Gut, dann mal zur zweiten Demo. Da geht es jetzt darum, wie ein System gepatcht wird. Nee, ich möchte die ab jetzt nicht bewerten.
23:24
Hier hatten wir ja diese Informationen vorhin gesehen, aber hier fehlt noch ein Schalter, nämlich ob eine VM mit einem Snapshot gesichert werden soll. Das ist ja nicht ersichtlich aus nur der Tatsache, dass es gemonitert wird und dass es auf dem Hypervisor läuft. Dafür gibt es den Parameter. Den könnte man entweder manuell setzen oder man kann den auch auf
23:41
Hausgruppenebene setzen lassen, sodass ich sage, ich habe eine Gruppe Prot und alles, was in Prot drin ist, bekomme diesen Parameter automatisch. Und dann muss ich das nicht manuell machen. Hier machen wir jetzt so eine Bestandsaufnahme gerade. Hier geht da jetzt eben die ganzen Systeme durch. Und dann kann ich anschließend mit Maintenance die einzelnen Kommandos
24:00
ausführen. Also prepare für vorbereiten, execute wir ausführen, status, um mir den Fortschritt anzeigen zu lassen oder revert, um es wieder herzustellen und clean up, um es aufzuräumen. Das heißt auch hier wieder SSL wird geskippt, Password-Datei wird angegeben, mein Format Server und hier gebe ich quasi den Snapshot an,
24:20
also die Bestandsaufnahme und mit minus n kann ich es auch wieder skippen. Jetzt sieht man hier zum Beispiel, dass er hier jetzt sagt, er würde jetzt von dem System eine Downtime einplanen, weil er eben weiß, das System bekommt einen Patch, wo ein Reboot benötigt wird. Dann wäre es schon klug, wenn die Kiste gebootet werden muss, dass dann das Monitoring ausgeplant wird. Würde jetzt kein Reboot benötigt werden,
24:40
würde er das nicht machen. Und bei Systemen, die eben mit einem Snapshot gesichert werden sollen, würde er dann hier auch einen Snapshot erstellen. Also das sieht soweit gut aus. Dann kann ich das Ganze gleich nochmal
25:00
filtern, kann nur bestimmte Systeme mit reinnehmen oder kann bestimmte Hausgruppen filtern. Da kann ich alles nutzen, was mir Formen anbietet. Hier zum Beispiel jetzt nur zwei Systeme, die einbezogen werden sollen. Und durch das Weglassen von minus n, wird dann eben im vSender einen Snapshot erstellt und im Monitoring
25:20
System entsprechende Downtime eingerichtet. Mit Execute würde ich dann die Wartung ausführen. Und da kann ich eben Errata und ganz einfach mit dem Schalter eben steuern. In dem Fall würden eben Fedora, Apple, Errata installiert werden und normale Paketupgrades.
25:40
Und dann sieht man hier, die Aufgabe wurde gestartet. Das sehe ich dann ja auch im Formen. Durch die Aufgabenengine sehe ich ja, was gerade ausgeführt wird. Diese Informationen kann ich natürlich auch auf der Kommandozeile mir anzeigen lassen. So, und wenn wir das gemacht haben, machen wir nochmal einen Snapshot. Und haben dann ja den Nachherzustand. Und wenn ich in den Ordnertemplates reingucke, also was mitgeliefert wird, ist einmal
26:02
ein Template für HTML und einmal für Markdown. Wie gesagt, Pandoc unterstützt da verschiedene Formate. Man könnte sich auch ein PDF-Template bauen oder ein OpenOffice-Template, je nachdem, was man benötigt. dann mit Hilfe von Cut Prep Report und der Vorlagendatei
26:24
und Angabe der beiden Reports wird dann automatisch das Delta berechnet. Und dann kann ich mir diesen Report angucken. Also das ist jetzt hier in Markdown. Man erkennt es vielleicht so ein bisschen. Das ist im Prinzip das, was wir vorhin als HTML gesehen haben, nur als Markdown. Das heißt
26:40
auch hier wieder die Meta-Informationen, IP, Datum, Uhrzeit, Owner, meine Checkliste, meine Patchliste und eine Beschreibung der einzelnen Patches. Das kann ich dann eben ablegen oder
27:00
ausdrücken, je nachdem, was die Anforderung im Unternehmen ist, wie mit diesen Patches umzugehen ist. Und dann kann ich mit Cleanup im Prinzip das Ganze wieder aufräumen, also meinen Snapshot entfernen und die Downtime wieder ausplanen. Und wenn ich das dann absetze, sehe ich eben auch, dass der Snapshot automatisiert
27:20
gelöscht wird im vCenter und im Monitorungssystem eben auch die Downtime wieder ausgeplant wurde. Und so habe ich im Prinzip, wenn ich mir das vorstelle, das wäre jetzt nicht nur ein System gewesen, sondern sagen wir mal 100, 200 Systeme, dann ist der Aufwander doch beträchtlich geringer, weil ich eben über die Kommandozeile das Zentral steuern kann. Gerne,
27:47
ich wiederhole die Frage gerne. Die Frage war, ob das jetzt vorhin ohne
28:07
Catello war. Also das war mit Catello. Das war Catello 3.5, glaube ich. Also die Demo habe ich irgendwann Ende letzten Jahres aufgenommen. Die Frage war, ob
28:21
dann das Durchreichen der Softwarestände in die einzelnen Umgebungen. Da gibt es ja in Catello den Mechanismus, dass ich mir meine Lifecycle Environments baue, zum Beispiel ganz typisch wäre ja Dev-QA-Prot beispielsweise, dass man eben sagt, ich beginne mit meiner Entwicklungsumgebung, gehe dann weiter an QA und dann an Prot. Das ist in dem Tool nicht mit drin, sondern da muss man natürlich vorher gucken, dass die Systeme,
28:42
dass ich die schon vorher gruppiert habe, dass die in der richtigen Umgebung sind und dann eben die Patches bekommen, die sie bekommen sollten. Also dann automatisch das nach dem Boot gucken, ist meine Monitorung okay und dann weiter reichen an die Produktion beispielsweise, ist da nicht mit drin, weil das sehe ich auch im Prinzip nicht in dem Tool eigentlich, weil das muss ich ja vorher,
29:02
als Admin muss ich mehr Gedanken darum gemacht haben und will es ja auch eigentlich mal eine Zeit lang testen. Also wenn du jetzt zum Beispiel heute auf dein Entwicklungssystem Patches installierst, dann würdest du ja nicht sofort dir auch auf der QA und auf der Prot installieren, sondern üblich ist es ja, dass man sagt, ich teste das in der Testumgebung, guck mir das mal so ein, zwei Wochen an und wenn das schick ist und läuft, dann mache ich das auf der QA und dann
29:21
auf der Prot Umgebung. Die Frage war gerade, ob das
29:41
Durchstaging der einzelnen Lifecycle Environments, ob man das vielleicht in dem Tool auch noch sehen würde. Also technisch wäre das machbar. Ich weiß nicht, sagt dir das Tool Catello CV Manager was? Das ist ein Tool, das Red Hat geschrieben hat, das findet man auch auf deren offiziellen Github Account. Das macht genau das, das ist ein kleines Ruby Tool,
30:01
da gibst du in der Config an, welcher Content Fuse du hast oder welcher Composite Content Fuse und da kannst du eben sagen, dass er z.B. jede Nacht, nachdem er die Patches runtergeladen hat, die automatisch an die Dev Stage gibt, z.B. sodass du immer dann auf Dev deine aktuellen Patches hast und dann z.B. per Grun Shop einmal im Monat
30:21
das automatisiert auf QA weitergibst. Also das wäre in der Art und Weise möglich. Ja, das wäre glaube ich, wenn man das dann erst nochmal nachprogrammiert, das gibt es ja schon. Aber eine Integration darin wäre vielleicht cool, dass man sagt, dass das Tool automatisch dann nach dem Ausführen von der Stage einen Script ausführt, was dann Catello CV Manager
30:40
triggert. Das ist ein guter Einwand, finde ich gut. Gut, die Videos haben wir jetzt ja gesehen, jetzt sind wir auch bei der Q&A Session. Habt ihr denn irgendwelche Fragen? Irgendwelche Einwände? Hat das Sinn gemacht oder eher nicht so? Du hast eine Frage.
31:00
Die Frage war, welche Pakete unterstützt werden, da hier einfach nur die Format und Catello API getriggert wird. Alles, was dein Format und Catello unterstützt. Das heißt, wenn du ein aktuelles Catello hast, gibt es ja auch einen Debian Package Support, den du für Debian oder Ubuntu nutzen kannst.
31:21
Suse ist mit drin und generell eigentlich alles, was er RPM kann. Da habe ich keinerlei Limitierungen, da nehme ich einfach nur die offizielle API. Deswegen alles, was da mit drin ist, wird da auch unterstützt. Noch weitere Fragen oder Ideen, Anregungen?
31:41
Nicht? Gut, dann würde ich euch noch einen kleinen Ausblick geben. Das Ganze ist eine Open Source Software, wie ich es ja schon angekündigt hatte, die ich hauptsächlich alleine pflege, wenn ich mal Zeit finde zwischen den ganzen Projekten beim Kunden. Das heißt, da ist der Entwicklungsfortschritt nicht so schnell, wie ich es gerne hätte. Das heißt, wenn einer
32:00
von euch Python programmieren kann und Bock hat, an einem Projekt mitzuarbeiten, würde ich mich da sehr freuen, wenn ihr euch diese UL vielleicht merkt oder mal anklickt. Aktuell gibt es da einige To Do's, die auf der Liste stehen. Ich habe da auch schon ein paar Releases geplant, aber wie gesagt, im Alleingang ist das nicht so easy. Zunächst mal habe ich mir vorgestellt, dass einfach weitere Integration stattfinden sollten,
32:22
z.B. in Richtung Spacewalk Uyuni oder Checkmk, Zuprex und was vorhin eben schon erwähnt wurde, um das eben einfach auch noch mehr Usern anbieten zu können, weil eben nicht jeder unbedingt Narcos, Isingas und Vmware benutzt. Ansonsten bin ich gerade drauf und dran, Uyuni-Tests zu schreiben und Testumgebungen für Entwickler
32:40
bereitzustellen, weil nicht jeder hat unbedingt ein Homelab oder will das beim Kunden produktiv so testen. Das heißt, da ist mein Gedanke, dass man einfach Vagrant-Boxes oder Docker-Images bereitstellt, die man einfach mal hochfahren kann und dann seinen Code einfach mal ausführen und testen kann. Ansonsten, auch wenn viele Freunde der Kommandozeile sind,
33:00
wäre es auch ganz schick, das vielleicht in die Formen Web-Urfläche zu integrieren, habe ich mir gedacht, dass man eben einfach nicht immer auf der Kommandozeile seine 4-5 Kommandos absetzen muss, sondern dass man einfach eine Hostgruppe auswählt und auf Patch Automation oder sowas klickt und das dann eben über die Web-Urfläche gesteuert werden kann. Und ansonsten, die Kommandos sollen ein bisschen vereinfacht werden. Ihr habt ja gesehen, es gibt Cut Prep, Snap Short,
33:22
Auth Config Maintenance, das sind schon mal drei Befehle, die ich mir merken muss. Ich meine, sie fangen alle mit Cut Prep an, das sollte irgendwie gehen, aber vielleicht die Kommandos ein bisschen sprechender zu machen steht auf der Liste und Bug Fixes. Also Formen und Cartello sind ja extrem agile Projekte, da gibt es gefühlt jeden Monat eine neue Version, was einerseits cool ist, aber
33:41
auf der anderen Seite stelle ich dann immer wieder mit Schrecken und erschrecken fest, dass dann viele Funktionen dann doch irgendwie angepasst werden müssen. Und wenn ich mal so einen Bug gefunden habe und mir so denke, jawoll, jetzt fixe ich den Bug, zack, dann stelle ich fest, na toll, dafür sind fünf andere reingekommen. Das heißt, wenn einer von euch gerne Code Review macht oder gerne
34:00
Bugs fixet, dann sollten wir uns mal näher unterhalten. Das wäre, glaube ich, ganz cool. Ansonsten bedanke ich mich sehr für eure Aufmerksamkeit, dass ihr zu der Uhrzeit noch so aufmerksam durchgehalten habt. Vielen Dank.
Recommendations
Series of 2 media