Ja, schönen guten Morgen zusammen. Wir haben die Ehre, den heutigen Vortragstag eindeuten zu dürfen. Freut uns sehr, dass ein paar von euch uns begleiten bei diesem Vortrag. Wir haben als Vortragstitel mitgebracht, mehr als nur

Puppenspieler Formel Catello Hersteller Unabhängig. Da sind ja ein paar Wortwitze gleich mit eingebaut. Wir wollen das Ganze heute am Beispiel Formel Catello mit Solstack auf der einen Seite und Suze als Kleinsystem auf der anderen Seite präsentieren. Und wir haben uns dafür

einen Fahrplan mitgebracht, wie bei den öffentlichen Verkehrsmitteln. Zunächst einmal möchten wir uns und unsere Firma vorstellen, von der wir kommen. Dann die Ziele des heutigen Vortrags, die Bausteine, die wir in der Präsentation bzw. in unserem Setup hergenommen haben. Das Ganze dann an

des praktischen Teils durch exerzieren, einen Ausblick geben und am Schluss dann ein kleines Fazit dazu ziehen. Ja, zunächst einmal, wo kommen wir her? Wir sind beide aus München. Wir kommen von der ATIX. Das ist eine Firma, die sitzt im Landkreis München. Wir beschäftigen uns vorwiegend mit den

Themen Linux und Open Source. Dort ein Schwerpunkt mäßig Rechenzentrums und Automatisierung. Uns gibt es seit über 15 Jahren. Die drei Hauptfelder sind Consulting, Engineering und Support. Und wir betreiben in München auch ein eigenes Schulungscenter. Wir sind mittlerweile auch offizieller

Puppet-Trainingspartner und sind da sehr stolz drauf. Ich habe mitgebracht, den Bernhard Sutner, der leitet bei uns die Softwareentwicklung. Er bringt 17 Jahre Softwareentwicklungs- und Dienungserfahrung mit, mit den verschiedensten Distributionen. Nachdem wir bei uns im Büro

Schwerpunkt mäßig das Thema Automatisierung umsetzen, macht der Bernhard da auch nicht stopp in der Firma, sondern macht daheim auch noch gleich weiter. Er ist ganz begeistert beim Thema Haumautomatisierung und daneben ist er ein ganz begeisterter Läufer und ist bei uns bei den B2 Runs auch immer

ganz vorne mit dabei. Bernhard. Leider nicht ganz vorne. Vielen Dank, Martin, für die Vorstellung. Jetzt darf ich hier meinen Gegenüber vorstellen. Martin Weiß ist zuständig für Business Development bei der ATX AG. Martin hat 16 Jahre

Erfahrung im Rechenzentrum und im Projektmanagement, hat seine Linux-Erfahrungen mit Diskette auch gemacht. Ob er damals ein Linux-System im Rechenzentrum mit Diskette installiert hat, weiß ich nicht. Martin ist auch begeistert in der Feuerwehr und hilft da, wenn es brennt oder wenn es

irgendwo wieder mal einen Sturm gibt, wie jetzt letzten Tage in Süddeutschland. Thema Brennen, er hilft auch bei Support-Themen mit oder bei der Erstinstallation. Genau, ich darf noch ein paar Worte sagen zum Thema Orcarino.

Orcarino ist das Produkt, was die ATX AG entwickelt oder im Endeffekt auf Basis von Formen und Cartello den Kunden zur Verfügung stellt. Orcarino bietet neben Formen und Cartello noch zusätzlich eigene Plugins, Erweiterungen,

die wir in-house entwickeln. Wir fixen Bugs für unsere Kunden, wir bieten professionellen Support an und helfen bei der Erstinstallation. Die Ziele, die wir heute verfolgen bei dem Vortrag sind, wir wollen euch

zeigen, wie man mit Formen und Cartello ein Slash-System provisioniert und im Anschluss daran konfiguriert mit Salt-Stack und am Schluss, wenn man das

ganze System installiert hat, dann auch verwalten kann, sprich RPM-Pakete installieren oder deinstallieren. Wie wir schon gesehen haben, es geht um Hersteller unabhängig, nicht so wie jetzt bei Red Hat, die sagen Red Hat Satellite,

wir verwalten Red Hat-Systeme oder bei SUSE-Manager, da geht es um SUSE, wir sind Hersteller unabhängig, bei uns geht es um SUSE, Red Hat, CentOS, Fedora und allen möglichen Distributionen, genauso wie Formen, Cartello auch Hersteller unabhängig ist, ist da auch unser Fokus.

Warum haben wir uns für Salt-Stack entschieden? Wir wollen den Vortrag mit Salt-Stack machen, weil SUSE auch sehr viel auf Salt-Stack setzt und weil wir zeigen wollen, dass es bei Formen, Cartello nicht nur mit Puppet geht, sondern es geht auch mit Salt-Stack, dass man die

Systeme verwaltet, Konfigurationen schreibt oder Pakete mit Salt-Stack installiert, genauso wie man auch Formen, Cartello mit Ansible oder auch

Formen, Cartello wollen wir dann noch zeigen und dazu wird der Martin ein bisschen mehr erzählen über Formen, Cartello. Vielen Dank. Zu meinem Verständnis, wer von euch hat denn mit Formen, Cartello bisher schon irgendwelche Erfahrungen machen dürfen? Einer? Gut, aber dann

erkläre ich den anderen so ein bisschen, was trotzdem Formen, Cartello ist. Das sind die Upstream-Projekte von Red Hat Satellite und eben auch so Carino. Der Formen hat, das sind die Werte von vorletzter Woche, roundabout 211 Contributors auf GitHub und ein bisschen über 5.900 Cummits und

Cartello, was eigentlich ein Formen-Plugin ist, hat 80 Contributors und 17.000 Cummits. Formen, Cartello, das ist im Endeffekt das Zusammenspiel von verschiedensten eigenständigen Projekten, die zusammengebündelt sind. Formen selber ist vorwiegend dafür zuständig,

Deployment und Lifecycle-Management zu machen. Deployment über, also Formen hatten Plugin oder eine Erweiterung, um mit verschiedenen Hypervisern zu sprechen, vor allem ja Lipvirt, KVM, mittlerweile auch Amazon, Azure und so weiter. Das Deployment läuft dabei entweder über Netzwerkinstallationen,

also TFTP oder aber auch über die entsprechende Library als Golden Image Installation über den Hypervisor. Lifecycle-Management, ich habe die Möglichkeit, im Formen verschiedene Tierstufen aufzubauen. Das Typische,

was man hier hat, ist einfach so eine Dev-Umgebung, eine QA-Umgebung, eine Produktionsumgebung und kann dann die sich Content-Views bilden vom Formen und kann Versionen von Paketen auf die entsprechenden Tierstufen

freigeben. So ein klassisches Beispiel an der Stelle ist das Weihnachtsgeschäft von einem großen Versandhandel. Der hat die Aufgabe, im Jahr über hat er vielleicht zehn Maschinen in der Produktion, im Weihnachtsgeschäft dann irgendwie 30 Maschinen, dann möchte die halt genau auf die gleichen Softwarestände bringen. Kann man mit so einem

Mechanismus sehr einfach realisieren. Der Catello selber hat dann zwei Subprojekte noch mit dabei oder das fasst zwei Projekte noch mit ein, das ist zum einen das Thema Candle Pin. Candle Pin macht die Subskriptionsverwaltung innerhalb von Catello. Gelehr ich dann später an

einem Schaubild noch ein bisschen näher und das Thema Pipe. Pipe kümmert sich darum, die Repositories und Inhaltsverwaltung zu realisieren. Pipe arbeitet asynchron, lädt Pakete runter, legt die auf Platte und den Datenbank ab. Wir sind selber mit dabei, sehr viele Piperwaltungen im Moment

zu realisieren. Zum Thema Debian Ubuntu, da wird der Bernhard ein bisschen später was noch dazu berichten und Formen Catello bringt auch eine eigene CLI mit, das heißt es sind nicht alle Sachen nur über die GUI möglich, sondern eben auch über CLI und die CLI in Formen Catello umfällt,

das heißt Hammer, Hammer CLI. Der ganze Formen Catello ist sehr stark Template und vererbungsbasierend, das heißt ich kann sehr, sehr viele Sachen, die ich realisieren möchte, über Templates voreinstellen. Formen

Catello bringt auch sehr viele Templates mit, zum einen auf der Deployment Seite, die verschiedenen Sachen für Kickstart, für Preseed Files, Outjust Files, da habe ich sehr viel dabei, um tatsächlich relativ schnell durchstarten zu können, aber auch verschiedene Partition Tables,

verschiedene Vordefinierungen und ich kann über die Vererbungen tatsächlich auch mir eine Struktur aufbauen, wie ich meine Serverlandschaft tatsächlich dann realisieren möchte. So ein typisches Beispiel ist, ich lege mir Templates an oder Gruppen für Web Server, für Datenbank Server, für was auch

immer und kann so über Templates tatsächlich schon sehr gradular einstellen, mit welchen Werten diese Maschinen betankt werden sollen und das Ganze dann eben nach unten vererben auf die einzelnen Hosts. Das ist der Formen Catello Part, weiter geht es mit Saltstack.

Ok, ein paar Punkte zu Saltstack. Wer hat schon mal mit Saltstack gearbeitet? Schon ein paar mehr, das ist sehr gut. Wahrscheinlich auch ähnlich genau so viel

bei Ansible. Saltstack, Ansible, Puppet sind glaube ich gerade derzeit die häufigst verwendetsten Configuration Management Tools. Das Saltstack-Projekt gegründet 19. März 2011, circa 80.000 Commits, ist eins der

aktivsten GitHub-Projekte, die es derzeit gibt, hat 1.850 Contributors, Tendenz steigend, sehr viele Contribute oder die Firma Saltstack ist hinter der Firma Saltstack und treibt da die Entwicklung voran. Saltstack ist

Python-basiert und verwendet als Syntax-Yaml. Im Gegensatz zu Puppet oder Ansible gibt es mit Saltstack zwei Möglichkeiten, wie man Konfigurationen

auf den Host bekommt. Das eine ist, man pusht die Konfigurationen, aber man kann sie auch pullen. Und es gibt noch die Möglichkeit bei Saltstack, dass man keinen Client installiert, sondern den Client bei Bedarf PSSH auf den

Host überträgt, dann zieht sich der Client die Konfiguration und spielt sie auf das System ein. Das heißt, man braucht nicht mal ein Client installieren, das ist ähnlich wie bei Ansible, wo alles direkt über SSH passiert. Für die Leute, die schon mal mit Puppet gearbeitet haben,

vielleicht eine kleine Überleitung. Bei Puppet gibt es Facts, das Gleiche bei Saltstack heißt Grains. Pillar-Datner bei Saltstack kann man vergleichen mit

Puppet-Hera und Formulas sind vordefinierte States, die man zum Beispiel bei GitHub findet. Das ist ähnlich zu der Puppet-Forge, wo man vordefinierte Module findet für Puppet. Soviel zu Saltstack. Martin geht

weiter Richtung Infrastruktur und wie geht das praktisch weiter? Jo, wir haben zum Beispiel so ein klassisches Szenario genommen, und zwar ein VMware-Server, den wir als Hypervisor-Plattform hernehmen. Und auf

dieser Hypervisor-Plattform haben wir dann erstmal eine Upstream-Form in installiert. Installation läuft über Repositories, die man vom Formenprojekt entsprechend ziehen kann. Das Ganze ist auf einer CentOS 7-Plattform passiert, braucht dann noch die entsprechenden EPR-Repositories und

zunächst werden dann die ganz normalen Pakete durchinstalliert. Es zieht sich ungefähr 350 Pakete. Dann hat man den Formen-Installer zur Verfügung. Man sieht hier unten, wie das Ganze aussieht, wenn der Formen- Installer mal durchgelaufen ist. Das funktioniert so, dass er sich selber über Puppet installiert. Und wenn er das gemacht hat, legt er sich dann

eine eigene CAA an. Braucht er im Hintergrund für das eingebaute Puppet, was tatsächlich standardmäßig mit daherkommt, und gibt dann eine fertige GUI-Prompte zur Verfügung. Das Ganze in der Erklärung, wie denn

tatsächlich die Ströme jetzt dort funktionieren, sieht jetzt folgendermaßen aus. Wir haben auf der linken Seite den Server-Part Formen-Cartello mit den entsprechenden Unterprojekten. Und auf der rechten Seite dann einen

typischen Client, egal welche Distribution das tatsächlich jetzt ist. Und, das sehe ich doch bei den Laserpointer. Man hat hier auf der kleinen Seite einen Teil, der heißt Subscription Manager. Der spricht mit dem Candle Pin und zieht sich entsprechend die für ihn freigegebenen

Subscriptionen. Das heißt, aus diesem Teil heraus wird dann kleinseitig die Schnittmenge gebildet an Repositores und Paketen, die für den Client eingegeben ist. Man hat auf der kleinen Seite dann noch einen Cartello-Agent, der spricht mit diesem Teil hier. Das ist eine bidirektionale

Kommunikation. Es wird von kleinen Seite an den Server weitergegeben, was für Pakete installiert wurden oder welche Versionsstände sich auf dem Client befinden. Das heißt, ich kann dann später sowohl von Server-Seite

aus Pakete installieren und die kommen am Client an und umgekehrt auch, wenn ich ein Client-Paket installiere, bekommt der Server das über diese Kommunikationsschnittstelle mit. Das ist dann ganz wichtig, um später bei Audits oder dergleichen eben sicherzustellen, welche Versionsstände auf den Servern tatsächlich da sind und um später dann auch beim Thema Release

und Patch Management über die zentrale GUI eben den Einblick zu haben, welche Versionsstände tatsächlich vorhanden sind. Und hier sieht man nochmal die entsprechenden Schnittschmellen. Ich habe eine Subscription, die ich einem Client zuweise. Das ganze passiert technisch über den

Activation Key und ich habe eine Content View. Die Content View ist der Teil Server-Seite, mit dem ich eben Software-Stände einfrieren kann und an eine bestimmte Tierstufe freigeben. Und die Schnittmenge daraus aus Subscription, Activation Key und Content View, das ist genau das hier, ist das,

was der Client dann zur Verfügung hat, um Pakete zu installieren. Das ganze ist aufgeteilt, die Content View in verschiedene Produkte und Repositories. Kann man typischerweise so machen, dass man Produkte wie zum Beispiel CentOS, Red Hat und dergleichen aufbaut und dann Produkte

drunter eben OS-Updates dergleichen oder MySQL oder was auch immer. Das ist der Teil, den wir bereitgestellt haben. Das Anlegen der Produkte haben wir zu dem Zeitpunkt erst mal noch von Hand machen müssen,

auch was das Thema SUSEP betrifft. Wir haben die Installationsmedien klassisch über die HTTP-Schnittstelle bereitgestellt. Wir haben einfach in mounted auf dem Rechner und über Papp bereitgestellt und wir haben eine Standard SUSE-Distribution hergenommen. Das war im Endeffekt das, was Formel

Catello stand Anfang 2017 sowohl Formel Catello-seitig als auch SUSE- Distributionsseitig uns hergegeben hat. Und dann kam das Schlagwort Automatisierung und Hersteller unabhängig eben zum Tragen. Und hat das Ganze dann erst einmal, dass wir auf Serverseite noch Saltstack

bereitstellen mussten. Genau, also wir springen wieder ein bisschen zu Saltstack zurück. Wie kann ich Saltstack bis zum Client bringen? Ich brauche Installationsmedien für SUSE. Das wird in Formen eingebunden und später,

wenn ich dann einen Client mit Saltstack bestücken möchte, dann wird dieses Repository bis zum Client übertragen. Das richte ich in Formen ein und damit ist das gut. Wichtig dabei, der Client und der Server sollten die gleiche Saltstack-Version haben, sonst kann es dazu Probleme kommen. Die

Dokumentation, wie man Saltstack installiert, findet man zum Beispiel bei der Formen-Wiki. Da kann man Schritt für Schritt einfach durchgehen und das machen. Wir haben da ein paar Fehler entdeckt und haben die dann auch

entsprechend korrigiert und die bei uns dokumentiert mit Sphinx benutzen wir da. Das ist auch ein sehr interessantes System. Da kann man nicht viel dazu sagen, Schritt für Schritt die Installationsanleitung durchgehen und die entsprechenden Befehle ausführen beziehungsweise in den

Danach, wenn man mit dem Schritt fertig ist, kann man Saltstack auf den Server direkt auch verwenden und könnte auch schon ein Client mit

Saltstack bedienen und innerhalb von Formen sieht man auch das Saltstack-Modul und kann da weiter konfigurieren. Gut, Martin hat vorher einen Punkt gesagt. Wir haben jetzt zum Stand Frühjahr 2017 die Möglichkeit, dass wir

Produkte über Formen-Cartello ausrollen, alles manuell. Das war uns für unser Kundenprojekt nicht gut genug und wir haben uns überlegt, wie können wir das Ganze verbessern. Dazu haben wir einmal den Subscription-Manager und den

Cartello-Agent. Martin hat vorher ein Bild gezeigt, auf der rechten Seite Subscription-Manager und Cartello-Agent. Die RPMs gibt es für CentOS und für Red Hat und für Fedora, aber es gibt sie nicht für SUSE. Das heißt, wir haben

die Speck-Dateien dafür erstellt, dass man auch den Subscription-Manager und Cartello-Agent und alle Abhängigkeiten für einen Slashclient zur Verfügung hat. Der nächste Schritt war, dass wir zwei Plugins entwickelt haben. Einmal zupasm.by. Wie ihr vielleicht wisst, verwendet

SUSE zupanormalerweise und wenn ich da zupainstall irgendwas eingebe, dann möchte ich nicht, dass er die normalen Repositories benutzt von SUSE, die fest codiert sind, sondern ich möchte, dass er über den Subscription-Manager

auf Formen Cartello zugreift und sich die Liste an zur Verfügung stehenden Repositories zieht und diese Repositories verwendet. Das macht dieses kleine Plugin, gibt es auch auf GitHub. Das weitere Plugin ist package-upload.

Dieses Plugin kümmert sich darum, dass wenn ich ein Paket manuell auf der SUSE-Seite installiert habe, dass der Cartello auf der Server-Seite weiß, ich hab da ein Paket installiert. Sprich, package-upload kümmert sich

darum, diese Synchronisation zwischen Client und Server aufrechtzuerhalten. Die zwei Plugins haben wir dann auch wieder in ein RPM integriert und das wird dann bei der Installation von einer SUSE-Box mitinstalliert.

Man sieht jetzt auch hier einen Screenshot davon, wie das dann ausschaut, wenn man ein Zipper-LR macht. Man sieht jetzt hier in Summe fünf verschiedene Repositories, die angezeigt werden. Das sind tatsächlich jetzt Repositories, die von Formen bereitgestellt werden.

So, schön und gut, wenn man das alles manuell bauen kann. Next Step war für uns, wir müssen das Ganze in Jenkins integrieren. Wir verwenden Jenkins, um Formen-Cartello zu bauen und deswegen war es naheliegend, Jenkins zu verwenden, um die ganzen RPMs und alle

Abhängigkeiten für SUSE zu bauen. So, was wir jetzt machen konnten, war, dass wir ein SUSE-System automatisch ausrollen konnten. Dazu mussten wir aber noch die

Repositories manuell in den Formen-Cartello reinprügeln. Das ist aufwändig, weil ich immer wieder herausfinden muss, wie heißen die Repositories, muss er in den Formen-Cartello in die Produktseite rein und muss das alles manuell eintragen, was fehleranfällig ist und einfach nicht schick ist. Man muss dazu sagen, dass SUSE über das SUSE Customer Center die

entsprechenden Repositories bereitstellt und da ist ungefähr so eine lange, kriptische Well hinten dran, die berechnet wird anhand der User ID und Passwort von dem entsprechenden Account im SCC. Genau. Bei Red Hat funktioniert das etwas eleganter.

Da gibt es ein Manifest, das lädt man sich von der Red Hat-Seite runter, spielt es in den Formen-Cartello ein und wenn man das eingespielt hat, kann man noch auswählen, welche Produkte man integrieren möchte in den Formen-Cartello, wählt die aus, spielt die ein und kann die dann benutzen, baut dann

daraufhin den Content-View. Man sieht jetzt hier die Übersicht-Seite. Das ist jetzt der Zustand, den man hat, wenn man tatsächlich so ein Manifest reingeladen hat. Man kann über die Auswahlboxen sich das zusammenklicken und das, was man auswählt, wird dann tatsächlich im Formen als

Produkt-Report aufgebaut. So wir haben aufgrund dessen, dass es bei Red Hat Center so einfach geht, haben wir ein kleines Plugin entwickelt, Formen-SCC-Manager nennt sich das, funktioniert ähnlich wie das von Red Hat, bloß mit dem Unterschied, dass man die

Credentials zum SUSE Customer Center in dem Plugin direkt angibt, dann gibt es eine entsprechende Schnittstelle zu dem SUSE Customer Center, wo man alle Produkte, die einem zugewiesen sind, herunterladen kann. Hier sieht man auch diese Liste von Produkten und ich wähle

ein Produkt aus oder zwei oder mehrere und wenn ich dann auf Submit klicke, wird automatisch im Hintergrund das Produkt in Formen integriert und ich kann dann einen Content-View bauen oder weitergehen, einen Activation

Key daraus erstellen. Formen-SCC-Manager arbeitet mit sogenannten Formen-Tasks, sprich, dass das Ganze im Hintergrund läuft und der Benutzer weiter die Oberfläche benutzen kann. Wenn man jetzt mitgedrückt hat, sieht man, dass er die

Produkte integriert hat und man sieht, wie lange das gedauert hat und wie viele Pakete im jeweiligen Produkt zur Verfügung stehen. Dieses Plugin, was wir entwickelt haben, ist auch auf

GitHub zur Verfügung gestellt worden und es sieht so aus, als würde es in nächster Zeit auch in Formen-Packaging direkt integriert, weshalb man dann auch Zugriff hat auf fertig gebaute RPMs.

So, jetzt haben wir die Voraussetzung, dass wir tatsächlich unsere Clients ausrollen können. Das Ganze passiert über die entsprechenden Templates. Man sieht jetzt hier so einen Screenshot von der Formen-Oberfläche. Man wählt aus, in welcher Organisation und Location man das Ganze ausbringen möchte.

Man wählt sich eine Hostgruppe aus, die man vordefiniert hat. Man wählt aus, wohin man das deployen möchte, z.B. eben auf dem VMWare. Man wählt sich ein Compute Profile aus. Das ist der Part, in dem man angibt, wie groß oder mit welchen Parametern die entsprechende VMWare-Höhle

gebaut werden soll. Mittlerweile, im aktuellen Entwicklungsstand von Formen-Cartello, kann man das jetzt tatsächlich auch im Nachgang dann über die Quia entsprechend noch ändern. Man wählt aus, in welchem Lifecycle man das ausbringen möchte und mit welcher Content-Fuel. Was eine wirklich schöne Eigenschaft von Formen ist, dass man sich die Konsole der

entsprechenden Hypervisor der VMs in der Quia herholen kann. Man sieht das hier auf der rechten Seite. Das ist ganz praktisch, weil man dann einfach nicht auf eine, wie auch immer geartete, Hypervisor-Plattform, ob das jetzt VMWare oder Lipvirt ist, drüberspringen muss, sondern sieht das tatsächlich alles in der Quia und

sieht dann tatsächlich auch den Installationsstand des Ganzen. Beim Provisionieren ist es so, dass er aus den verschiedenen bereitgestellten Templates das durchrennt. Das heißt, die Partition-Tables, die definiert sind, in dem Fall die Auto-House-Templates, die bereitgestellt werden, die Betriebssystem-

Informationen oder Pakete werden eben zusammengepackt und über TFTP dann bereitgestellt. Das Ganze pro Client mit entsprechenden UUIDs. Und nach Abschluss der Installation meldet er an den Formen dann entsprechend die Fertigstellung.

Man bekommt, das ist jetzt schon das Beispiel von einem Saltclient, man bekommt dann entsprechende Informationen geliefert, wie es dann auf der kleinen Seite ausschaut, ob er installiert wurde, IP-Adressen, die ersten Facts, die zurückgeliefert wurden und kann an der Stelle dann auch einen Saltrun ausführen über die GUI-Anträger.

Des Weiteren auf der Detailseite von dem entsprechenden Host hat man dann die Möglichkeit, nochmal einzustellen, in welchem Environment ich bin. Ich kann tatsächlich die Environments pro Host dann hier hinten nochmal nachträglich ändern und ich kann über die

entsprechende Seite dann auch Pakete hier über die GUI installieren. Ich kann ihm Erathos zuweisen, falls welche vorhanden sind und habe tatsächlich immer die Möglichkeit, mir auch die Summe der Tas, die gelaufen sind, entsprechend im Nachgang anzuschauen, um zu kontrollieren, dass das, was ich

losgetriggert habe, auch wirklich passiert ist. Nachdem jetzt der Host entsprechend fertig installiert wurde und der uns das gemeldet hat, war es dann wichtig, dass wir das ganze System, was jetzt installiert wurde, entsprechend auch konfigurieren

und als Konfigurationsplattform hatten wir uns eben Saltstack ausgesucht und deswegen war es jetzt erforderlich, dass wir mit Salt weitermachen. Genau, die Integration von Saltstack in Formen ist nicht so gut wie

die Integration von Puppet. Ich würde mir sagen, sie ist ein bisschen besser als die von Ansible, aber Puppet ist einfach da noch viel weiter. Trotzdem kann man einige Sachen in Formen-Cartello schon setzen für Saltstack. Wie man hier sieht, gibt es auch

bei Salt wie bei Puppet auch entsprechende Environments. Bei Saltstack gibt es immer das Environment-Base, man kann dann aber auch Environments anlegen, wie Test, Production oder Development. Hier sieht man einen State,

HTPD, State ist bei Saltstack ähnlich wie beim Puppet ein Modul und den State kann ich dann einem Environment zuweisen. Nachdem ich das zugewiesen habe, kann ich hier für die

Hosts entsprechend auswählen, welche States dieser Host bekommen soll. In dem Fall soll der Host den State Mod D bekommen. Wenn ich das Ganze dann ausführe, dann bekommt man auch einen Report, wo dabei steht, State

erfolgreich ausgeführt oder Fehler hier und dort. Auf der Oberfläche haben wir schon gesehen, kann ich einen Salt-Run machen oder man kann das auch direkt in Saltstack konfigurieren. Es gibt einen eingebauten Scheduler, wo dann von Zeit zu

Zeit die Konfiguration automatisch hin zum Host übertragen wird. Die Konfiguration von einem Saltstack sieht dann so aus. Hier ist von einem Saltstack ein Template, wo man

entsprechend Werte setzen kann, wie jetzt Grains, was ähnliches zu Facts oder Pillar-Daten. Und die Pillar-Daten kann man über Formen konfigurieren, zum Beispiel über Global Parameters oder Host Group Parameter oder Host

Parameter, auch wieder von der Hierarchiestufe entsprechend. Hier sieht man Global Parameter, Vendor Name ist und der Host-Parameter ist gesetzt auf Orcherino Artics AG, das heißt der Host-Parameter ist entsprechend wichtiger als

der Global Parameter. Und wenn ich das Ganze dann ausführe und mir die Konfigurationstatei auf dem Host ansehe, dann gibt er hier diese Mod-D-Meldung aus und ersetzt Orcherino Artics AG den Pillar-Wert und den Grain, den

Host-Namen. Ja, was haben wir als uns das Ausblick noch gemacht? Wir wollen das Thema Suse-Integration noch weiter optimieren. Im Moment ist es so, dass wir auf der kleinen Seite noch

die Super-Integration vervollständigen möchten, dass da kleinseitig noch mehr passieren kann in der Kommunikation mit dem Server, was auch noch auf der Agenda steht, ist das Optimieren des Deployments von Slashmaschinen, das heißt dort soll serverseitig noch mehr automatisierbar sein.

Und das Gleiche gilt beim Thema Automatisierung der Solstack-Installation und Konfiguration. Wir sind tatsächlich im Moment dabei, serverseitige Installationen sehr viel über Ansible, Playbox und Scripts zu realisieren. Das ist tatsächlich an der Stelle für uns im Moment

Mittel der Wahl. Und das Thema vollständige Unterstützung von Divion und Ubuntu, damit der Formel Catello eben tatsächlich komplett herstellerunabhängig ist, ist das, was tatsächlich im Moment sehr, sehr hoch im Kurs steht. Und der Bernhard hat den aktuellen Stand mitgebracht.

Genau ähnlich wie bei Suse wollen wir jetzt auch das Thema Divion weiter voranbringen. Da gab es seit, glaube ich, 2015 oder 2016 einen Pull-Request für das Projekt Pulp, um Pulp-Divion-Support zu bieten. Diesen Pull-Request haben wir aufgegriffen

und haben da einige Buckfixes noch gemacht, sodass es jetzt auch rund läuft. Wir sind dabei, das noch weiter zu verbessern, damit auch wirklich der Zustand von einem Divion-Repository in Pulp abgebildet werden kann.

Und Pulp ist irgendwo so eine Back-End-Ebene. Und wir wollen natürlich auch dem User ein entsprechendes Front-End bieten. Wieder natürlich in Formen und Catello. Hier sieht man ein Repository, was man mittlerweile auch anlegen kann.

Auch hierzu im GitHub ein Pull-Request entsprechend. Man kann also ein Produkt anlegen, ein Repository hinzufügen und kann da auch zugreifen darauf, auf dieses fest definierte Repository.

Das sieht man jetzt hier. Wir haben ein ganz kleines Fake-Repository angelegt und haben da ein paar Pakete reingeladen. Zum Beispiel ACL für die Architektur MD64 in dieser Version. Der nächste Schritt,

nachdem man jetzt ein Repository in Debian auch hat, ist ein Content-View auf Basis des Produkts zu bauen und dann weitergehend ein Activation-Key, damit man das Ganze bis zum Client dann auch bekommt. Die Debian-Pakete, die wir jetzt auch wieder brauchen auf der kleinen Seite,

haben wir teilweise schon gebaut, da wir noch nicht Zugriff haben auf den Server. Müssen wir da noch ein bisschen warten, ob das dann auch alles funktioniert. Und es sind guter Dinge, dass wir da in naher Zukunft sagen können, Debian, Ubuntu, auch für Formen und Catello, dass wir da eine Unterstützung haben.

Genau. Ja, ich denke, man kann durchaus sagen, dass der Formen Catello als Plattform für die Verwaltung von unterschiedlichsten Systemen sehr gut geeignet ist. Man sieht, dass das Thema SUSE, so wie wir es jetzt dann auch schon gemacht haben,

hier ist übrigens der GitHub-Account, wo wir die entsprechenden Sachen auch hochgeladen haben, zur Verfügung steht. Man sieht, dass Puppet zwar als Standard- Config-Management-Tool mit Formen Catello um die Ecke kommt, aber das ist mit Solstack und Ansible durchaus

adäquate Ergänzungen oder Erweiterungen oder Alternativen gibt innerhalb von Formen Catello. Am Schluss, bevor wir dann auf Fragen von euch eingehen, wollen wir noch auf eine Veranstaltung von uns hinweisen. Das ist der Open Source Automation Day in München am 19. Oktober.

Und ansonsten würden wir sehr gerne Fragen beantworten, falls es welche aus dem Publikum gibt. Ich wiederhole gerne, ich komme mal hoch. Hi, ich habe gerade diese Konsole gesehen.

Ist die eigentlich dann so ein Teil des Produktes oder zappt die irgendwas ab und an? Angenommen, ich habe jetzt zwei Hypervisor mit libvirt ohne alles, ohne Verwaltung, ohne OpenStack oder sowas. Kann ich damit direkt abzapfen und brauche ich dann so etwas überhaupt noch? Brauchen im Sinne von was? Ich habe diese Konsole in eurem Webfrontet gesehen.

Also kann die das ersetzen? Ersetzt ihr das oder ist sie ein Service, die einen anderen Service abgreift? Die Konsole, also für jede Frage gibt es einen Luftballon. Vielen Dank. Okay, dann bleibe ich oben. Also die Konsole,

die greift im Endeffekt, leitet die VNC oder Spice-Konsole durch. Wie schaut es denn aus mit normaler OpenSuse? Wir haben jetzt zum Beispiel von SLS, also von Suse Linus Enterprise gesehen. Wir haben es tatsächlich im Moment für SLS gebaut.

Bernhard, ich denke, es wäre durch. Wir haben es für OpenSuse getestet. Wir haben es für OpenSuse. Es funktioniert auch soweit. Es gibt bloß ein Problem im Just, weshalb ein Plugin nicht funktioniert. Da haben wir auch einen entsprechenden Bug-Report aufgemacht bei der Suse.

Aber ich glaube, die haben da noch nicht darauf reagiert. Gibt gleich noch ein zweites. Weitere Fragen? Ich bringe schon. Wer sich keiner mehr ein Ballon verdienen? Das ist schade.

Dann bedanken wir uns sehr herzlich für eure Aufmerksamkeit und wünschen euch heute noch einen coolen Tag auf der FrostCon 2017. Dankeschön.