Zero-Touch Kubernetes: Vollautomatisierte Infrastruktur mit Flatcar Container Linux.
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Untertitel |
| |
| Serientitel | ||
| Anzahl der Teile | 62 | |
| Autor | ||
| Lizenz | CC-Namensnennung 4.0 International: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/59738 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
| |
| Schlagwörter |
FrOSCon 202223 / 62
4
9
12
13
17
18
20
25
28
33
34
39
40
42
44
45
48
54
55
58
60
62
00:00
SoftwareHypermediaLINUXBetriebssystemAnwendungssoftwareKeller <Informatik>Graphische BenutzeroberflächeMicrosoftOpen SourceUpdateLINUXKlasse <Mathematik>Computeranimation
05:06
LINUXBetriebssystemKonfigurationsraumKerndarstellungDesktopRichtungServerVersion <Informatik>BetriebssystemLINUXZurücksetzung <Transaktion>LaufzeitUpdateAnwendungssoftwareIsolation <Informatik>App <Programm>Interface <Schaltung>KonfigurationsraumComputeranimation
13:22
APIKernel <Informatik>KonfigurationsraumProviderDienst <Informatik>Demoszene <Programmierung>CADdyServerACCESS <Programm>HTMLBetriebssystemPartitionsfunktionDownloadingVersion <Informatik>InternetdienstUpdateBetriebssystemKonfigurationsraumWeb ServicesAnwendungssoftwareVersion <Informatik>Klasse <Mathematik>MengeDateiStreuungsdiagrammPartitionsfunktionInternetdienstCapacitated Arc Routing ProblemProviderReiheErzeugendeZurücksetzung <Transaktion>Presentations <Programm>Programm/QuellcodeXMLFlussdiagramm
20:05
BetriebssystemPartitionsfunktionDownloadingVersion <Informatik>InternetdienstZurücksetzung <Transaktion>BetafunktionServerUpdateOpen SourceUpdateVersion <Informatik>Zurücksetzung <Transaktion>FestplattePartitionsfunktionAnwendungssoftwareBetafunktionRandQuelle <Physik>SoftwaretestBetriebssystemNoten <Programm>Physikalische GrößeComputeranimation
26:53
ServerUpdateOpen SourceMicrosoftWindows AzureWeb logLINUXKommunikationOffice <Programm>Chatten <Kommunikation>MatrizenringUpdateRichtungMETAL <Programm>KommunikationBetriebssystemMicrosoftLINUXKanal <Bildverarbeitung>Chatten <Kommunikation>Version <Informatik>Prozess <Physik>LebensdauerGebäude <Mathematik>RechenschieberMatrizenringComputeranimation
33:41
ImplementierungLINUXKernel <Informatik>Machsches PrinzipChatten <Kommunikation>MatrizenringKommunikationDemoszene <Programmierung>KonfigurationsraumErweiterungProgrammfehlerPatch <Software>MengeFedora CoreRepository <Informatik>MatrizenringKonfigurationsraumDemoszene <Programmierung>Git <Software>RechenschieberSoftwareentwicklerImplementierungSoftwaretestComputeranimation
37:58
Demoszene <Programmierung>BewegungsgleichungLINUXKonfigurationsraumUpdateMALAGA <Programm>Demoszene <Programmierung>UpdateInstanz <Informatik>GroßrechnerServerComputeranimation
40:13
UpdateComputeranimation
41:01
UpdateMatroidCADdySpielkonsoleComputeranimationProgramm/Quellcode
42:01
Firefox <Programm>Web logBenutzeroberflächeMultiprotokoll-RouterStrich <Typographie>XMLComputeranimation
44:22
Demoszene <Programmierung>SystemCStochastische MatrixKonfigurationsraumBetriebssystemComputeranimation
45:13
Innerer PunktWEBSoftwareUpdateStochastische MatrixEIBWorld Wide WebUpdateVersion <Informatik>PartitionsfunktionDrahtloses lokales NetzDownloadingLastComputeranimation
47:41
UpdateZellularer AutomatSchnittmengePartitionsfunktionUpdateVersion <Informatik>DateiComputeranimation
48:58
Demoszene <Programmierung>KonfigurationsraumUpdateWorld Wide WebWEBServerVersion <Informatik>RechenschieberUpdateDemoszene <Programmierung>Computeranimation
49:45
Web SiteLINUXOffice <Programm>Machsches PrinzipCOMFreewareQuellcodeInformationChatten <Kommunikation>Sage <Programm>StreuungsdiagrammMicrosoftMETAL <Programm>ComputeranimationVorlesung/Konferenz
51:52
KonfigurationsraumLINUXInformationPunktwolkeUNIXProviderGoogleHausdorff-RaumComputeranimation
52:52
Open SourceFreewareSoftwareBetriebssystemWindows AzureKonfigurationsraumNoten <Programm>TemplateLaufzeitAnwendungssoftwareStreuungsdiagrammMomentenproblemVerweildauerVorlesung/Konferenz
01:02:28
JSONXMLUML
Transkript: Deutsch(automatisch erzeugt)
00:07
Willkommen zum Zero Touch Kubernetes Vortrag auf der FroschCon 2022. Das ist ein Infrastruktur-Talk, es geht um Betriebssystem, Betriebssystem Automatisierungen, war im Abstract.
00:21
Also kein Kubernetes-Talk, er soll aber dafür sorgen, dass ihr Kubernetes vollkommen stressfrei betreiben könnt und euch auf eure Applikationen und eure Controlpläne konzentrieren könnt und nicht mit dem Betriebssystem zu tun habt. Kurz zu mir, ich bin Tilo, ich bin Engineering Manager bei Kinfok gewesen, jetzt bei Microsoft und ich arbeite mit dem Flat Car Container-Liedungsteam bei Microsoft.
00:45
Jetzt mal zu euch, ich bin gespannt, für wen ich den Vortrag halte und möchte euch ein bisschen kennenlernen. Wer von euch hat dann beruflich oder privat mit Clustern zu tun, verteilten Applikationen im kleinen oder im großen bitte um Handzeichen?
01:02
Oh gut, das ist, sorry, verteilte Applikationen, ich glaube verpeilt haben wir alle. Wer managt Container-Workloads oder schreibt und deploit Container-Applikationen?
01:24
Und drei mehr, gut, wir sind bei gut der Hälfte, klasse. Betreibt einer von euch oder maintained einer von euch oder arbeitet einer von euch mit Kubernetes? Alles klar, ja, wir wie im Intro erwähnt gucken ein bisschen auf Container-optimiertes Linux.
01:46
Das soll euch erlauben, euch auf die Workloads zu konzentrieren und euch im Grunde genommen die Schmerzen aus dem Betriebssystem rausnehmen. Bevor wir damit anfangen, habe ich eine Slide, ein bisschen die Geschichte. Der Talk wird sich hauptsächlich um Flat-K Linux drehen, aber Flat-K Linux hat eine Geschichte.
02:06
Die Konzepte und die Ideen, die ich heute vorstelle und bespreche, die sind nicht auf unserem Mist gewachsen. Das ist tatsächlich wie im Open Source üblich eine ganze Historie. Wir warten und entwickeln das Betriebssystem weiter, aber wir stehen auf
02:22
den sprichwörtlichen Schultern von Giganten und dem möchte ich hier gerecht werden. Das ist mir so ganz wichtig, das ist die Rückwärtskaste. Es fing alles an mit einer kleinen Firma namens CoreOS. CoreOS hat Anfang 2010 einen kompletten Stack entwickelt, der skalierbar sein soll, der Cluster-Betrieb ermöglichen soll.
02:45
Da war eine Kubernetes-Distro mit dabei, da war eine Linux-Distribution mit dabei und eine Control-Plane, ein Update-Mechanismus und und und. Der Teil, um den es sich in diesem Talk dreht, ist CoreOS Container Linux, welches sozusagen der untere Teil dieses Stacks war.
03:01
CoreOS Container Linux basiert auf Chrome OS, hat sich da den Update -Mechanismus geborgt, das Update-Protokoll, AB-Partition Scheme, wozu wir später noch kommen. Und Chrome OS seinerseits basiert auf Gentoo, nutzt also Gentoo-Pakete. Das war CoreOS Container Linux, im Oktober 2013 gab es das erste Release.
03:23
Im Mai 2020 wurde es dann eingemottet und das ist deswegen so, weil CoreOS von Red Hat übernommen wurde. Red Hat hat die Philosophie und den Ansatz dann weiterentwickelt, hat die Basis aber sinnvoller und naheliegenderweise geändert von Gentoo auf Fedora. Es gibt jetzt also Fedora CoreOS, das basiert von der Idee her auf CoreOS Container Linux.
03:45
Es gibt eine eingeschränkte Kompetibilität, das heißt, wenn ihr emigriert, dann tut es ein bisschen weh. Ein paar der Mechanismen sind anders und alle Pakete kommen von Fedora. Da wird ständig weiterentwickelt, es ist ein ganz tolles Team, das das macht. Wir haben ein paar Touchpoints mit den Jungs, die fetzen, die sind ganz toll.
04:01
Und was wir also gemacht haben, als KinFork seinerzeit war 2019 ein FriendlyFork von CoreOS Container Linux. Das war also in Absprache und mit vollem Wissen der Leute, die CoreOS Container Linux entwickeln. KinFork hat eine weitreichende Geschichte mit CoreOS. Wir haben also viel zusammengearbeitet mit denen. Wir haben an Rocket und an diversen anderen Sachen für die Jungs weiterentwickelt.
04:22
Und das ist also mehr oder weniger um die Philosophie des Original CoreOS mit Gentoo Base und das ganze Look and Feel zu bewahren. Und haben es dann eigenständig weiterentwickelt. 2020, als CoreOS dann sozusagen in Maintenance Mode ging, haben wir es auf eigene
04:42
Füße gestellt und haben es massiv weiterentwickelt, Pakete geupdatet und so weiter und so fort. Wir sind also näher an der Gentoo-Basis inzwischen dran als an Chromium OS. Das ist ein großes Bestreben von uns. Und das ist also das, wo wir herkommen. Und wie ich gesagt habe, viele der Kernmechanismen sind nicht auf unser Mist gewachsen, sondern kamen also aus dieser Geschichte.
05:08
Aber ganz allgemein, was meinen wir denn mit Container-optimierten Linux, den wir schon ein paar Mal benutzt? Haben wir da am Kern herumgespielt, sodass Container ganz toll laufen? Haben wir da irgendwie Docker ein bisschen glatt gebügelt und schippen das, sodass der Startup gut funktioniert?
05:23
Haben wir da ein paar Schrauben gedreht obendrauf auf generischen Linux-Distros? Was ist das eigentlich? Naja, im Grunde alles oben genannte, aber tatsächlich konsequent von unten nach oben neu aufgezogen.
05:42
Und es folgt so ein bisschen einer anderen Philosophie als die General Purpose Distros, die wir von unseren Desktop und vielleicht auch Servern kennen. Container-optimiertes Linux sieht das Betriebssystem als Teil einer Infrastruktur. Das soll langweilig sein, das soll euch nicht aufregen und man soll sich nicht damit befassen müssen, wenn man nicht will.
06:07
Es ist einfach im Grunde genommen handhabbar, wie jede andere Applikation auch. Das Ziel ist, dass der Ops-Bereich, die Ops-Teams mehr Zeit für die Business-Logic haben, sich auf die Sachen konzentrieren können,
06:23
um die sich das Leben dreht, ohne sich mit dem Betriebssystem zwangsweise befassen zu müssen. Also sehr stark auf Automatisierung, auf Robustheit, auf Einfachheit gefeilt. Die Idee, die wir als Entwickler verfolgen, ist die Philosophie, die wir verfolgen, wir sind der Lichtschalter.
06:41
Wir sind nicht das tolle Heimkino, uns gibt es in verschiedenen Farben, aber wenn eine bestimmte Farbe dazu führt, dass es Licht nicht mehr angeht, das wäre eine Funktion, die aufgrund eines Features beeinflusst werden würde, wir wollen das in dieser Richtung nicht. Die Idee ist, und ich habe ein Heimkino in Covid-Zeiten mir aufgebaut, dass wenn mein Lichtschalter ständig meine Aufmerksamkeit will,
07:08
weil er gewartet werden möchte, weil er nicht das tut, was er tun soll, dann habe ich die Freunde am Heimkino nicht und kann meine Serie nicht zu Ende gucken. Wir erreichen das, indem wir die Isolation, die Container-Apps untereinander
07:24
und, wie ich gleich zeigen möchte, auch dem Betriebssystem gegenüber haben, daraufhin interpretieren, dass das Betriebssystem weniger austauschbar macht, weil die Schnittstellen zwischen Applikation und Betriebssystem überschaubarer werden.
07:41
Wenn man tatsächlich nur mit containerisierten Apps arbeitet. Wie müsst ihr euch das vorstellen? Ihr kennt das aus dem Containerbetrieb, Kubernetes oder anderen Kontrollplänen. Wenn ihr also eine neue App auf dem Knoten deployen möchtet, habt ihr so eine deklarative Konfiguration, die werft ihr auf euren Cluster.
08:03
Die neue App wird instanziert von einem Image, das ist quasi die Instanz, trägt dann die Nutzdaten und die Sache lässt sich betreiben. Das funktioniert, weil die Apps untereinander über klar definierte Interfaces kommunizieren.
08:21
Ein Interface in breiteren Sinnen, wie also Storage, Netzwerk und all das, was ihr quasi in der Deklaration der App mit beschreibt. Und die Container runtime sich dann darum kümmern kann, dass diese Interfaces erschaffen werden und die App also nicht nebenbei umher tut und andere verdeckte Abhängigkeiten an Betriebssystem, an die Knoten oder andere Apps mitbringt.
08:45
Das wird auch benutzt, wenn ihr so eine App updaten wollt. Ihr ändert also den Teil der deklarativen Konfiguration, der die Version der App beschreibt. Im Grunde instanziert ihr das Ding von einem neuen Container Image, von einem abgedateten Container Image. Und das geht auch sauber, weil die Container runtime, wie gesagt, weiß, welche Interfaces benutzt werden, um mit anderen Deployten Apps zu connecten.
09:08
Die App wird, also die Interfaces werden runtergefahren, die App wird runtergefahren, die neue App wird instanziert und die Interfaces werden wieder hergestellt. Das ist jetzt nichts Neues für euch, das kennt ihr, wenn ihr mit Containern arbeitet. Also ich erwarte jetzt keine Applausstürme.
09:21
Der Witz ist, diese Isolation, die wir hier haben, und diese klar beschriebenen Interfaces gibt es tatsächlich auch zwischen den einzelnen Apps, die auf dem Knoten laufen und dem Betriebssystem. Die sehen ein bisschen anders aus, aber nicht viel. Wenn man also einen Schritt zurück macht, die gleiche Philosophie darauf anwendet, dann sieht man, sämtliche Container benutzen relativ schmale Interfaces, bestimmte Kannele APIs und Docker als Container runtime.
09:48
Das kann man als Interface sehen, nichts anderes. Wir haben also keine Abhängigkeiten an Bibliotheken, wir müssen keine anderen Voraussetzungen schaffen und auch nicht bewahren im Betriebssystem, sondern wir können diese Philosophie nutzen, um zum Beispiel das Betriebssystem austauschbar
10:03
zu machen, dass wir eine neue Version, wenn die dann rauskommt, staging können. Die Interfaces, die auf der entsprechenden betroffenen Node existieren, sauber runterfahren, das Betriebssystem recyceln können. Aktivieren können die neue Version und die Interfaces wieder herstellen und die Apps kommen wieder hoch, ohne dass es große Schmerzen ist.
10:26
Update ist nur ein Beispiel dieser Unabhängigkeit, die wir da erreichen, aber das illustriert ganz gut, was wir meinen, mit Container optimiert. Das gleiche ist der Fall, wenn ihr einfach eine neue Node erschaffen
10:40
möchtet. Ihr seht das Betriebssystem als eine weitere Applikation, die deklarativ beschrieben ist, wo also die nicht automatisch konfigurable Teile des Betriebssystems deutlich ausgedrückt werden, die neue Node wird deployed. Möglicherweise braucht man Bootstrap auf der Node, so die Container optimierten Betriebssysteme geben euch da die Möglichkeit,
11:06
auf einem Low-Level eine neue Container zu starten oder was anderes, um eure Kontrollplane hochzubringen und die zieht dann den Rest nach. Was ganz wichtig an dieser Stelle ist, ist, wir versuchen an der Stelle nicht, eine eigene Kontrollplane zu sein. Also die Möglichkeiten, die ihr habt, um Bootstrap-Container hochzuziehen, sind sehr, sehr beschränkt.
11:25
Im Grunde genommen sind es einfach nur System-D-Units, die ihr selber zur Verfügung stellen könnt. Ganz einfach, weil wir keine Kontrollplanes sein wollen. Gut, was meinen wir also, wenn wir von einem Container optimierten Linux reden?
11:41
Vergesst eure Paketmanager, vergesst eure Installationen, geht ganz zurück auf die Basics, stellt euch vor, euer Betriebssystem ist genauso eine stateless App, wie alle Applikationen, die in einem Cluster laufen. Wir nutzen die Isolationen der Applikationen untereinander und vom Betriebssystem, die Containerisierung mit sich bringen, die wohl definierte Schnittstellen
12:01
zwischen OS und Applikationen, um das Betriebssystem austauschbar zu halten. Wir offerieren eine deklarative automatisierbare Installation. Genau wie ihr das von euren Apps kennt, und das ist tatsächlich Jammel, da gucken wir nachher rein. Ihr habt also eine Konfiguration bei der Installation, bei der Provisionierung. Es gibt keine
12:22
dynamischen Änderungen, ihr macht also hinterher nicht am Betriebssystem rum, nachdem es deployed ist. Es gibt andere Philosophien, und die sind großartig. Also ich möchte gar nicht fundamentalistisch erscheinen an der Stelle. In unserem Kontext ist es allerdings so, dass wenn ich eine weitreichende Konfigurierbarkeit zur Laufzeit im Betriebssystem brauche,
12:42
dann habe ich bei der Provisionierungsautomatisierung etwas falsch gemacht. Also unsere Vorstellung ist, alles sollte entweder bei der Provisionierung einstellbar sein oder sich automatisch regeln. Und das hängt damit zusammen, dass wir kein State wollen am Betriebssystem, oder so wenig wie möglich State. Und das ermöglicht uns eine Unabhängigkeit, das ermöglicht uns eine viel leichtere Wartbarkeit.
13:03
Das gibt uns automatische Updates oder kontrollierte Rollbacks. Und das heißt, genau wie eure Applikationen abgedatet werden, ihr tut ein Image hin, ihr aktiviert das Image, und wenn es hinterher irgendwie komisch riecht, dann habt ihr ein automatisiertes Rollback ebenfalls mit drin.
13:21
Noch mal zur Isolation, und ich weiß, ich wiederhole mich hier, das ist aber im Grunde genommen tatsächlich die ganze Basis der Idee. Wir müssen verstehen, dass wir in einer rein Container-basierten Operation keine Abhängigkeiten zwischen dem Betriebssystem und den Applikationen haben.
13:47
Es gibt keine gemeinsamen Bibliotheken, es gibt keine Dienste oder was, was ich irgendwie bereitstellen muss, außer den Kern, mit dem die Applikation der Container redet, und Docker.
14:01
Das gibt mir eine saubere API zwischen dem Betriebssystem und den Applikationen. Die Netzwerks, Storage, CPU, Speicher, Requirements sind in der Konfiguration dokumentiert. Und die Container-Orchestrierung, die kann sich im Grunde genommen automatisiert darum kümmern, dass das zur Verfügung gestellt wird. Mehr braucht es zwischen Applikation und Betriebssystem nicht.
14:24
Das gibt uns Updates und Rollbacks ohne Seiteneffekte. Ich kann zum Beispiel auch ein Canary-Muster etablieren, wenn ich einen größeren Cluster habe, dass ich also eine neue Version des Betriebssystems mal so anteste, gucke, ob es geht, und sauber wieder zurückrollen kann, wenn etwas Komisches passiert.
14:43
Automatisiert Installationen, das ist ganz toll. Das spielt mit rein, wie ihr euer Cluster deploit und auch wie ihr euer Cluster updatet. Wir stellen also eine deklarative Installation bereit, eine Konfiguration. Das geht über ein Konfigurationsmanagement namens Ignition.
15:04
Nachher habe ich ein Beispiel drin, wer mehr über Ignition erfahren möchte. Matthew will have a presentation on Ignition at 3 p.m. So he'll go in depth there. Dinge werden bei der Installation aktiviert, und das ist es dann. Das ist euer State. Das hat den Vorteil, dass beim Rollout und bei der Provisionierung,
15:26
wenn da irgendeine Konfiguration nicht sauber applied, wenn ihr irgendeinen kleinen Teil habt, der nicht will, dann kriegt ihr gemeldet, da riecht was komisch. Zurückrollen, neu provisionieren, Konfiguration mal angucken. Wenn ihr im Nachhinein ändert, ist das viel schwerer.
15:41
Es macht das Rollout vollständig automatisierbar. Wir offerieren für das Betriebssystem eine ganze Reihe Konfigurationsoptionen. Eigentlich sollte alles automatisch funktionieren. Nur die speziellen Sachen, Corner Cases, wenn ihr die habt, sollten konfiguriert werden. Aber Ignition ist tatsächlich sehr umfangreich.
16:04
Die ganze Geschichte ist einfach in bestehende Orchestrierungen zu integrieren. Es gibt Go Bindings für Ignition, es gibt einen Terraform Provider. Wir haben Cluster API Support. Cluster API basiert ursprünglich rein auf Cloud Init.
16:21
Wir haben Ignition mit dazu getan. Es spricht jetzt also beides. Und es kann also auch benutzt werden, um den Carpe Cluster hochzuziehen. Das ist ein Beispiel. Das ist Jaml. Wenn ihr Container-Administratoren seid und auch viel mit Kubernetes macht, dann könnt ihr das lesen.
16:42
Das ist tatsächlich eine Node-Konfiguration. Die wollen wir später dann auch mal demoen. Wir sehen, dass eine Nutzer angelegt wird. Das ist ein Service Nutzer, deswegen kriegt ihr kein Home. Und der wird zusätzlich in die Gruppe Docker gesteckt. Wir sehen hier, dass wir eine Datei erzeugen.
17:02
Die Datei in diesem Fall ist inline. Also das ist alles. Und die wird an besachter Stelle von der Installationslogik erstellt. Eine weitere Datei hängt daran, die ist nicht inline. Die liegt lokal. Das heißt, wenn wir diese Konfiguration kompilieren,
17:22
sodass die Installationslogik, die auch verdauen kann, dann wird die in das Kompilat integriert. Und wir sehen, dass wir quasi Nutzer und Gruppe des Nutzers benutzen, den wir da oben angelegt haben. Das Ganze wird dann verbunden mit einem System D-Unit.
17:40
Die benutzt einfach Caddy, um die beiden entsprechenden abgelegten Dateien zu serven. Das ist eine statische Konfiguration. Die bringt euch einen kleinen Web-Server hoch. Genauso könntet ihr andere Dienste starten. Ihr könntet einen Indie-Container bootstrappen. Oder euch wo anmelden, um einer Orchestrierung zu erlauben, dann die nächsten Schritte zu verfolgen.
18:03
Das ist ein kleines Beispiel. Die Konfigurationssprache ist viel, viel komplexer. Ah ja, die System D-Unit läuft unter dem Nutzer Caddy. Das Betriebssystem, das wir ausliefern, ist imagebasiert. Das erlaubt uns eine zustandslose Installation.
18:22
Das Image ist read-only, nachdem es installiert ist. Ihr könnt keine Beineriesen überschreiben. Das geht so, indem wir nur das USA-Unterverzeichnis benutzen, um unsere Beineries zu lagern. Das braucht ein bisschen Anpassung, wenn das Betriebssystem baut.
18:41
Das hat den Vorteil, dass die Beineries da auf einer anderen Partition liegen können. Bei uns ist tatsächlich die gesamte Betriebssystem-Partition read-only. Es ist nicht nur das Dateisystem, sondern unten die Block-Device. Sie könnt ihr nicht schreiben. Das bewahrt uns von einer ganzen Menge Fehlern. Einerseits Schüsselfehlern, die man machen kann.
19:01
Andererseits gibt es eine ganze Klasse von Betriebssystem-Vulnerabilities, von denen wir nicht betroffen sind, einfach weil du unsere Beineries nicht austauschen kannst. Das macht das Ganze auch verifizierbar und attestierbar, also wer sich ein bisschen mit Conformance beschäftigt oder beschäftigen muss, von Beruf oder auch im Privaten.
19:22
Wenn das Betriebssystem sich nicht ändert, wenn die Beineries sich nicht ändern, dann ist das sehr gut attestierbar. Und wir liefern das tatsächlich auch attestierbar aus. Wir haben eine SLSA-Deklaration mit dem Betriebssystem erhalten. Die Betriebssystem-Partitionen werden mit DMVerity jedes Mal beim Boot überprüft.
19:44
Und das Ganze ist ziemlich ausgehärtet. Updates. Die gleichen Prinzipien ermöglichen uns atomare Updates. Betriebssystem Read-Only. Vielleicht sollten wir vorher einen Blick auf die Partition...
20:03
Das ist eine vereinfachte Darstellung der Partitionierung. Eigentlich haben wir mehr Partitionen. Der Punkt hier aber ist zu erklären, wie die AB-Partitionierung funktioniert. Ihr habt also zwei Partitionen für das Betriebssystem. Die sind jeweils in Gigabyte. Eine ist leer bei der Provisionierung.
20:20
Da kommt dann das Update rein, die andere ist aktiv und Read-Only. Und es gibt einen kleinen Bootbereich. Da liegt der Kanal drin. Und da ist die DMVerity gespeichert für die Betriebssystem-Partition. Bei der Provisionierung wird die Root-Partition angelegt. Die ist in erster Instanz leer.
20:40
Und die wird dann erweitert, sodass der gesamte Restspeicher der Festplatte ausgefüllt wird. Mit dem im Hinterkopf kriegen wir atomare Updates erklärt. Die Sache funktioniert so, dass im Hintergrund überprüft wird. Es gibt einen Dienst auf dem System.
21:00
Es gibt eine neue Version in bestimmten Intervallen. Wenn es eine neue Version gibt, wird das Image, Updates sind auch Images. Wir haben keinen Paketmanager. Runtergeladen, im Hintergrund bereitgestellt. Ein Reboot wechselt in eine neue Version rein. Die Root-Partition ist noch die gleiche. Eure Container bleiben also erhalten.
21:22
Die starten dann wieder neu. Und es gibt in dem Sonne auch konfigurierbare Rollbacks. Der Dienst, der das Update übernimmt, der hat eine Dependency-Chain. Wenn ihr da in diese Dependency-Chain eure wichtigsten Applikationen reinhängt, die auf jeden Fall laufen müssen, damit die Note gesund ist,
21:42
und die failen, dann wird der Update-Mechanismus, der Update-Service nicht starten nach dem Update. Und das wird dazu führen, dass ein Reboot ausgeführt wird. Wenn der Update-Dienst startet nach dem Update, dann wird er feststellen, dass alles in Ordnung ist.
22:01
Dann wird er die abgedatete Partition als die neue Root-Partition, als die neue gültige OS-Partition markieren, nicht vorher. Das ist dieses eingebaute Rollback, das man hat. Es gibt ein gesteuertes und kontrolliertes Ausrollen, was wir mitofferieren, wenn ihr größte Cluster betreibt.
22:21
Es gibt Mechanismen. Die Notes untereinander können sich über LCD auswürfeln, wann sie rebooten, sodass nicht euer Cluster in einem Rutschdown geht. Wenn ihr eine Kontrollplane habt, gibt es einen Kubernetes-Operator namens Fluo, den wir bereitstellen. Fluo koordiniert solche Updates auf Kubernetes-Ebene.
22:41
Er drängt die Notes selektiv mit einer maximalen Note-Anzahl, die zur gleichen Zeit down sind. Er rebootet dann und rejoint dann wieder. Wir supporten auch VForks QOD. QOD macht im Grunde das Gleiche, basiert auf einem Flag-File.
23:04
Das stellt unser Update-Mechanismus zur Verfügung. Wenn ihr eine existierende Lösung mit QOD habt, dann integriert das ganz automatisch. Warum solltet ihr euch darauf verlassen, dass was immer an Updates bei euch reinregnet, tatsächlich auch nichts kaputtmacht?
23:21
Wir haben einen Stabilisierungsprozess in unseren Release-Prozess eingebaut. Das ist im Grunde genommen der CoreOS-Stabilisierungsprozess. Mit unserer Ergänzung, dass wir auch eine LTS haben, die über ein Jahr nur Patch-Updates kriegt. Das hatte CoreOS nicht. Wir haben drei, oder mit LTS zusammen vier,
23:41
dedizierte Channels, die euch neue Versionen zur Verfügung stellen. Alpha ist der Channel, der am stärksten aktualisiert wird. Wir haben Alpha-Releases, neue Major-Versions, alle zwei bis vier Wochen. Alpha durchläuft den vollen Testzyklus, den wir haben.
24:02
Wir haben Szenariotests, das komme ich gleich zu. Und wir releasen Alphas nur, wenn sie alle Tests tatsächlich passiert haben. Allerdings ist Alpha in dem Sinne für Entwickler gedacht, als dass wir halbfertige Features da drin haben, damit wir auch Features iterieren können. Beta ist tatsächlich, so wie wir das sehen, production-ready,
24:25
ist mehrfach durch die vollen Tests gelaufen, über den Alpha-Zyklus. Und an dem Punkt gibt es da nicht mehr viel, was wir also noch testen können, um Stabilität zu garantieren. Beta ist für Canaries. Das heißt, wenn ihr größere Cluster betreibt, empfehlen wir ein paar dieser Knoten auf Beta laufen zu lassen.
24:42
Dann seht ihr, was kommt, könnt quasi die Änderung mit euren Use-Cases überprüfen. Falls ihr in Edge-Cases reinlauft, wo dann doch was kaputt geht, könnt ihr tatsächlich diese Probleme reporten oder auch gleich fixen, den fixen Upstream-Committen und die Stable,
25:01
die dann nach der Beta kommt, hat den fix drin. Ihr könnt euren gesamten Cluster sozusagen auf Stable laufen lassen und könnt euch in den Release-Prozess integrieren, sodass euer Stable-Cluster grundsätzlich immer nur die Version kriegt, die ihr selbst auch mit als gut getestet habt.
25:21
Der Rest der Community macht das auch. Wir haben also einen relativ großen Anteil Beta-User. Das ist ganz nett zu sehen von der Maintainer-Perspektive. Die sorgen also schon so ein bisschen dafür, dass wir die ganz exotischen Fehler relativ früh sehen. Wie gesagt, wir haben weit reichende Testszenarien
25:42
für alle Releases, inklusive Alpha. Das sind was an die 100 Scenario-Tests. Das können einfache Sachen sein, wie geht es eLinux? Die meisten sind aber relativ komplexe Sachen, wie deployment Kubernetes-Cluster mit fünf Nodes macht, dass C&I geht, also Container Network Interface,
26:00
und wir testen also verschiedene C&I-Lösungen auch als Beispiel. Ich habe die LTS kurz am Rande erwähnt. Es gibt tatsächlich Ops und Cluster, die so groß sind, dass tatsächlich jedes Update, jedes bisschen Downtime,
26:22
jedes Reboot-Risiko richtig Geld kostet. Das verstehen wir. Wir haben tatsächlich einige sehr große User, und auf Vorschlag dieser Nutzer haben wir dann seinerzeit als Kinfolk in einem Subscription-Account, aber jetzt komplett open source und frei, eine LTS-Version rausgebracht. Die 2022er Release ist tatsächlich auch für Community.
26:45
Die können sich alle holen. Wobei ich hier genauer sagen muss, die Quellen für LTS, die waren immer open source. Wenn ihr also selber baut und einen eigenen Update-Server betreibt, dann konnte die LTS auch schon zu früheren Zeiten haben.
27:00
Durch das Sponsorship und die Übernahme von Microsoft ist es uns jetzt möglich, uns tatsächlich mehr auf die Community zu konzentrieren. Wir persönlich, also als Ex-Kinfolk, offern auf keine Support-Subscriptions mehr. Wir wollen das als Community-Projekt sehen. Deswegen der Schritt mit der LTS. Wenn ihr also Schmerzen habt bei jedem Kanal-Upgrade,
27:22
was reinkommen könnte, und nur Patch-Level-Updates wollt, dann ist LTS für euch. LTS hat eine Lebenszeit von 18 Monaten. Alle 12 Monate gibt es eine neue LTS-Version. Das heißt, ihr habt 6 Monate Zeit, zur neuen Version zu migrieren. Wir machen das sehr zaghaft. Stable, zum Beispiel, released alle 3 Monate.
27:41
Und da können halt Kanal-Upgrades mit drin sein. Wir haben einen open source Update-Server. Das ist auch was, was uns von CoreOS unterscheidet. Wir hatten einen Update-Server, der war nicht open source. Das heißt, ihr könnt eure Updates selbst hosten. Ihr habt eine sehr feingranulare Konfigurationsmöglichkeit
28:03
über Node-Gruppen und Update-Management. Und habt auch eine gute Übersicht über euren Cluster. Wir sind schon immer sehr nutzergetrieben und sehr community-orientiert. Und jetzt, wo der Zwang der Finanzierung weggefallen ist,
28:23
zu 100 Prozent. Das heißt, ihr könnt euch reinhängen mit uns. Wir sind sehr offen. Wir sind ein relativ kleines Maintainerteam, aber wir machen alle unsere Kommunikation öffentlich. Und einfach mitmachen. Unsere Wurzeln damals,
28:41
ich weiß nicht, ob ihr euch an die 2., 3. Slide noch erinnert, mit der Geschichte, war das so, dass wir zwar sämtliche Repos und alle Builds und alles open source gemacht haben, die verschiedene Support-Subkriptions benutzt haben zu Kindvolk-Zeiten, um das Ganze finanzieren zu können. Das hat auch dazu geführt,
29:02
dass wir das Betriebssystem als Single-Wender geführt haben. Das möchtest du machen, wenn du Support-Subkriptions verkaufst, weil du die Freiheit brauchst, Dinge fixen zu können, wenn es dringend nötig ist. Das hat sich geändert. Jetzt ist es so, dass wir komplett community-getrieben
29:21
und community-fokussiert uns umorientiert haben. Es ist nicht nur so, dass wir Contributions, Bugfixes, Bugreports, Patches wollen. Wir sind tatsächlich auch offen für Stewardship. Das heißt, wenn ihr euch dafür interessiert, mal in die Prozesse einer Linux-Distro reinzugucken,
29:43
da sind wir dafür. Microsoft tritt an der Stelle als Sponsor auf. Es ist also nicht so, dass wir hier von einem Microsoft Linux reden. Es ist ein Community-Linux. Microsoft sponsert das, genau wie wir andere Sponsoren haben. Equinix Metal z.B. sponsert unsere Build-Hardware
30:01
und unsere Update-Server. Microsoft sponsert das Projekt mit Arbeit. Bezahlte Leute, die an dem Betriebssystem arbeiten, das weiterentwickeln. So, wir lesen das jetzt alle mal in Ruhe durch. Nein, nicht wirklich. Das war aber der Kinfok-Übernahme. Und wenn ihr euch an nochmal die History-Slider erinnert,
30:25
als CoreOS von Red Hat übernommen wurde, wurde CoreOS Container Linux so langsam in Maintenance-Modus geschickt und irgendwann abgekündigt. Microsoft hat sich sehr angestrengt und sehr Mühe gegeben, auch in der Kommunikation von Anfang an und auch mit Taten,
30:41
das nicht nochmal passieren zu lassen mit Flat-Car-Linux. Für Red Hat macht es Sinn. Also ich möchte die Entscheidung wirklich gar nicht kritisieren. Die haben Fedora, die haben eine solide Paketbasis in Fedora und die Leute sind auch toll von Fedora Core. Das muss ich ganz ehrlich sagen. Microsoft kommt aus einer ganz anderen Richtung und die möchte gerne Flat-Car-Container-Linux
31:02
als Community-Projekt betreiben und bewahren. Da sind also keine Firmeninteressen dahinter. Sorgt dann auch dafür, dass Microsoft das Produkt als Produkt nicht supportet. Das ist ja sinnvoll, wenn es eine Community-Distro ist.
31:20
Ja, das war ein Blogpost bei der Übernahme, wo sozusagen öffentlich verkündet wurde, wir fördern das Projekt und wir sehen den starken Nutzen für die Community. Ja, ich habe erwähnt, dass wir viel öffentlich arbeiten als Maintainer-Team. Das Tagesgeschäft, also alles, was man so als Team, ihr kennt das von der Arbeit
31:40
und vielleicht auch privat, wenn ihr an einem Open-Source-Projekt zusammen entwickelt. Man tauscht sich über Matrix aus. Wir waren ursprünglich auf IRC und dann ist das IRC-Ding passiert und sind auf Matrix umgezogen. Wir haben auch ein Slack-Channel. Der Grund dafür ist, auf Slack sind tatsächlich die Kubernetes-Leute
32:00
viel stärker unterwegs. Wir sehen Slack und Matrix also jetzt nicht als konkurrierende Chats für uns, sondern es ergänzt sich tatsächlich. Ja. Also wenn ihr irgendwie Fragen habt oder euch melden wollt, droppt einfach in den Matrix-Chat.
32:22
Die gesamte Teamkommunikation läuft da drüber. Also alles, was wir täglich machen, landet da drin. Wir benutzen interne Kanäle tatsächlich nur für Management-Kram und nicht Technisches. Wir haben sehr öffentliche, kurze Langzeitplanungen, öffentliche Feedback-Runden. Wir haben monatliche Office-Hours.
32:41
Das ist so ein Dreiviertelstunden-Call. Da könnt ihr euch reinhängen, wenn ihr was bequatschen wollt. Ab und an haben wir Demos da. Wir haben auch Gäste von anderen Projekten da, die Sachen vorstellen. Wir hatten den Benjamin Gilbert von Core-Rest Red Hat da, der Boutain vorgestellt hat zum Beispiel. Das Gleiche ist bei Release-Plannings.
33:03
Einmal sind Release-Plannings Teil der Office-Hours, weil wir aber zweiwöchentliche Releases verfolgen, reicht die Cadence dafür nicht. Und wir haben dann also nochmal in zwei Wochen Rhythmen, unabhängig davon Release-Plannings. Alle Projektballs, alle unsere Langzeit- und Kurzzeitplanungen sind öffentlich.
33:21
Und wir haben aktuell unregelmäßige, aber doch immer wieder erscheinende Bugsmashing- und Docs-Writing-Tage. Das heißt, das gesamte Team hängt dann in einem Jitsi-Call und macht an Issues rum. Wenn ihr also irgendwas auf dem Herzen habt, ist das auch eine gute Möglichkeit, da sich zu zeigen.
33:43
Boards, wir benutzen GitHub-Boards, sind also eine GitHub-Org, wo wir den Kram pflegen und maintainen. Implementierungs-Boards, also das Tagesgeschäft, das kennt ihr, das ist ein Daily-Kannmann im Grunde genommen. Release-Boards nehmen dann die Dinge, die fertig sind, die aus der Implementierung
34:01
rausfallen und planen die für bestimmte Releases ein. Und die Langzeitpläne, die wir haben, also so Epics und Subtasks und was nicht, da haben wir eine Roten App-Board für. Wir sind sehr stark interessiert, mit unseren Upstreams und Sidestreams zu arbeiten.
34:21
Wir arbeiten also stark mit unseren Roots, mit den Abhängigkeiten, die wir haben. Das offensichtlichste sind Gentoo und Fedora Core OS. Mit Gentoo machen wir also viele Package-Updates, Stabilisierungen. Das ist tatsächlich so, dass wir Latest and Greatest gerne verwenden. Und bei Gentoo diese Pakete manchmal noch als
34:42
instabil markiert werden, also nicht regulär mit gebaut werden. Da wir ein umfangreiches Test- und Stabilisierungskonzept haben, vorhin vorgestellt, nutzen wir das auch gerne, um so eine stabilen Pakete in der Upstream zu reporten. Übrigens, das Ding läuft seit einem halben Jahr in unseren Tests gut und läuft schon in zwei Stables. Es ist vielleicht stabil.
35:03
Wir haben diverse Bug-Fixes bei den Jungs drin und vermehrt jetzt auch Package-Updates, wo wir Upstream helfen, tatsächlich neuere Versionen von Packages, die wir benutzen, mit zu integrieren. Fedora Core ist offensichtlich die Konfiguration der Interpreter Ignition und Botain.
35:21
Wir haben da Erweiterungen drin in Ignition und Botain. In Botain hauptsächlich Jetcar-Support, aber tatsächlich gibt es viele Touchpoints mit den Entwicklern. Und wir schippen auch Bug-Fixes. Dann gibt es so Sachen, auf die man immer wieder stößt, als Distro. Wir haben also diverse Bug-Fixes in anderen
35:41
Projekten. Wir haben eine Sache in dem Linux-Kernel, der hat einen Patch in einer LTS-Serie von einem Linux-Kernel Silium kaputt gemacht, weil sie Virtual Interface Renamings auf einmal mit einem Fehler behandelt haben, das sie vorher nicht gemacht haben, was auch vollkommen in Ordnung ist. Nur in einer
36:01
Stable-Serie macht das Dinge kaputt, wenn es dann nur als Patch-Level kommt. Wir haben da also einen Patch drin, damit Silium gearbeitet. Falco ist eine Introspektions- Suite für Kubernetes. Bei denen haben wir ein Bildsystem und Interop zusammengearbeitet und haben da also Sachen verbessert. Das sind nur Beispiele,
36:22
da gibt es mehr von. Wenn ihr mitmachen wollt, vielleicht schon benutzt und ihr habt eine Aua, sagt es uns bitte. Wir sind sehr daran interessiert und in der Regel kümmern wir uns auch zeitnah um Bugs oder Features. Wenn ihr euch mit reinhängen wollt, wie gesagt, es gibt den Matrix-Chat,
36:41
es gibt Bug-Smashing und Dog-Writing-Tage, es gibt wirklich eine Menge Möglichkeiten, direkt mit dem Team zusammenzuarbeiten. Ob ihr Anfänger oder Pro seid, ist dabei vollkommen egal. Wir haben tatsächlich auch mehrere Beispiele von Leuten, die sich bei uns gemeldet haben, gesagt haben, ich interessiere mich für Betriebssystementwicklung, ich kenne aber Flatcar nicht. Die nehmen wir dann schon so ein bisschen an der Hand und helfen
37:00
denen auch mit rein, sodass die Leute dann so ein bisschen liefern können und auch ein bisschen was lernen dabei. Ihr könnt, wenn ihr wollt, euch um Package-Updates kümmern, ihr könnt das OS-Image erweitern über ein Proposal, ihr könnt Maintainer werden, ihr könnt an das Projekt reinwachsen
37:21
und beim Steward-Chip mitmachen. Wir sind komplett offen für alles. Wie erreicht ihr uns? Wir haben Office-Hours jeden zweiten Dienstag im Monat, 17.30 Uhr. Wir sind täglich auf dem Matrix unterwegs und, wie gesagt, wir haben auch einen Slack-Channel. Die Slides sind online, in die Links könnt ihr klicken und da kommt ihr zu den Details.
37:42
Gut, wir haben nach 25 Minuten für ein Demo. Ich mache mal. Wir haben da die das Demo und die Slides in unserem Git Repo drin. Könnt ihr euch anschauen. Ich schaue mal, ob ich euch
38:00
jetzt ein bisschen was über FlatCut demonstrieren kann. Wir werden eine Node deployen, das wird eine Single-Node sein. Läuft in einem Q-Emo, hier auf meiner Maschine. Also ein ganz kleines Demo. Das nutzt im Grunde die Ignition-Konfig, die wir vorhin schon gesehen haben. So, das ist die. Mit einem kleinen Unterschied. Wir rebooten nicht bei Updates.
38:22
Der Grund dafür ist, ich werde eine alte Alpha-Version von FlatCut benutzen in erster Instanz, damit ich das Update demoen kann. Wenn mir dann die Instanz im Demo rebooted, kann ich es nicht demoen. Also schalte ich Reboot aus. Das Staging ist trotzdem an. Das heißt, wir werden Updates staging können.
38:50
Ich brauche mein Cheatsheet. Gut. Vorbereitungen. Ich habe mir
39:00
vom FlatCut Release Server eine Image runtergeladen. Das Q-Emo-Image. Wir benutzen verschiedene Images für verschiedene Cloud-Plattformen. Q-Emo in dem Sinne ist für uns eine Cloud-Plattform. Da gibt es einen Skript für. Das liegt da auch. Das wird auch mit Release. Wo man die ganze Sache starten kann. Wir sehen die YAML-Datei hier.
39:21
Und das erste, was ich mache, ist die YAML-Datei zu kompilieren in was unsere Deployment-Automatisierung versteht. Das ist JSON. Wenn ihr aus dem Kubernetes-Bereich kommt, dann wisst ihr, das ist Tradition. Alles, was YAML ist, wird in JSON kompiliert.
39:42
Dann starte ich das Image. Ich gebe ihm also mit, dass er eine Ignition-JSON hat, um die er sich bitte kümmern möchte. Und ich sage ihm auch,
40:00
dass er in NoGraphics starten möchte. Und ich vorwarte, das sieht man hier nicht mehr, Port 80 auf Port 8080 vom Host. Was ich vielleicht tun sollte,
40:21
ist... Wir haben kein Netz. Oh nein. Warum haben wir denn kein Netz? Select Network. Das ist doof, wenn wir kein Netz haben, weil wir dann das Update nicht demonen können.
40:41
Wir haben doch Netz. Hilfe. Ich mache mal das, was man nicht machen sollte. 1, 1, 1. 6.
41:06
Vielen lieben Dank. Okay. Wir haben Netz. Aber auf Port 8080 ist nichts los. Logisch.
41:21
Weil wir ja noch nicht gestartet haben. Das machen wir jetzt. Zack. Wir sehen Grab. Flat Car booted. Und wenn es zu Ende gebootet hat, wird Ignition übernehmen und wird den
41:40
Container deployen. Wir sehen eine Ausschrift hier auf der Konsole. Ich gucke mal, noch läuft nichts. Ja, da ist er. Es braucht halt ein bisschen, um Caddy runterzuladen. Caddy ist ein ganz grandioser Webserver, möchte man benutzen, wenn man Static Files surft, bin ich ein großer Fan von.
42:01
Und wenn wir jetzt reloaden, dann werden wir nichts sehen. Aha. Das muss dieser Demo-Effekt sein, von dem sie alle reden.
42:27
No. Did I?
42:42
Wenn ich jetzt ganz paranoid wäre, könnte ich den Container und das Port Forward und den Health Check auch vom Deployment abhängig machen. Dann würde ihr sehen, dass beim Deployment etwas kaputt geht.
43:01
Das Image wird verändert von der Provisionierungslogik. Deswegen habe ich mir ein Pristine Image gesichert. Überschreib das jetzt einfach. Oh, das ist komisch.
43:22
Ach nee, sieht gut aus. Okay. Ich muss das hier mal ein bisschen kleiner machen. Ist auch interessant, warum er
43:44
das nicht mit Port Forwarding gestartet hat. Gut. Okay.
44:03
Ich cheate mal. Ich schaue gleich mal.
44:29
So. Das hier ist lang genug, dass ich einfach... Ja, nee, das ist so. Das ist tatsächlich richtig. Aber es kann
44:41
sein, dass das nicht richtig angekommen ist. Versuchen wir es noch mal. Es bootet. Und das Schöne ist, dadurch, dass ihr die Konfiguration nicht im Betriebssystem habt, sondern wir quasi erzwingen,
45:01
dass ihr die Deklarativ von außen reinreicht, ist das alles reproduzierbar. Das heißt, wenn ich Mist gebaut habe, baue ich immer wieder denselben Mist. Und wenn es funktioniert, funktioniert es auch immer wieder. Es lebt. Die Spannung steigt.
45:24
Okay. Das war der erste Teil. Der zweite ist tatsächlich noch spannender. Das ist das Update. Bleibst du hier? Wir haben also einen Dienst laufen,
45:41
der... der abgefragt werden kann. Wie geht es dir denn? Und liegt denn ein Update vor? Liegt denn ein Update vor? Nö. Last Check Time sagt uns aber auch, dass er noch nie geguckt hat. Was ich jetzt mache... Ach so. Vielleicht zeige ich euch noch ein bisschen was mehr.
46:02
Wer QD kennt und benutzt, der weiß, QD arbeitet mit einem Flagfile, welches euch sagt, welches QD sagt, dass diese Node jetzt ein Reboot braucht. Das Flagfile ist nicht hier, klar, weil wir kein Reboot brauchen. Wir gucken uns das OS-Release an.
46:20
Und wir sehen... Das ist eine relativ alte Version einer Alpha von Flatcar. Das sehen wir da, weil die in meiner Nummer 0 ist. Das ist bei Alphas immer so bei uns. Und ist also Ende Mai diesen Jahres rausgekommen. Ist für eine Alpha relativ alt.
46:40
Gut, wir haben Version 32.55. Was wir jetzt machen können, ist, Update Engine zu sagen, geh doch mal gucken. Update Engine guckt jede Stunde einmal. Die ist jetzt noch nicht um und die wollen wir auch nicht warten. So. Jetzt guckt er also nach Updates. Jetzt kann ich nochmal den Status aufrufen und fragen, wie sieht es denn
47:02
jetzt aus? Und jetzt sagt er, ja, es ist gerade eins am Downloaden. Die Downloadprozente, die seht ihr hier, das geht hoch bis zur 1. Wir sind jetzt also bei 61%. Das ist ein schönes, schnelles WLAN.
47:22
Und das Ganze wird jetzt also in die zweite leere OS-Partition reingeschrieben, sodass es durch einen Reboot aktiviert werden kann. Und was ist jetzt passiert? Wir sehen ja auch paar Shell-Ausschriften, das er also in Partitionen rumgemacht hat. Und wenn ich ihn jetzt nach dem Status frage,
47:40
dann sagt er, jetzt breuen Reboot. Und zwar haben wir hier eine neue Version. 33.05. Feuer was 32, was in die 70. Das hat sich also ein bisschen was getan. Und wenn ich mir jetzt angucke, dann gibt es auch diese Datei. Das heißt QD würde jetzt wissen, aha, die Node, die möchte
48:00
gerne evakuiert werden. Und dann können wir neu starten. Gut. Das machen wir jetzt mal. Sudo Reboot. Das Ganze startet neu. Das startet in die neue Version rein.
48:21
Und auch an dieser Stelle ist es also interessant, würde QD für mich eine, eine quasi lebenswichtige Applikation sein, auf der Node, die unbedingt hochkommen sollte. Sollte ich Update Engine als Dienst über ein System Ddrop in, also auch eine Ignition Konfiguration,
48:41
abhängig machen von QD, wenn QD nicht hochkommt, kommt Update Engine nicht hoch, dann dauert es zehn Minuten, dann Reboot die Node. Die neue Partition ist nicht auf aktiv gesetzt. Wir Rebooten also in das Alte zurück, was funktioniert hat. Das ist hier aber nicht so. Zum einen habe ich nicht die volle Paranoia gebaut und habe QD nicht abhängig
49:01
gemacht. Zum anderen, ob das Update funktioniert. Der Web Server läuft. Und wir können uns irgendwo raus anschauen, dass wir also auf der neuen Version laufen. Keine Version wird sich geändert haben. Diverse Tools werden sich geändert haben.
49:21
Das ist das Update. Der Witz dieser Demo ist, dass es relativ langweilig ist. Das ist der Punkt. Den Update Engine Status? Na klar. Da ist er. Jetzt ist er Eidl.
49:43
Das war's, denke ich. Ich gucke mal in meine Slides. Nicht, dass ich das vergesse. Wenn ihr euch dafür interessiert, was Flatcar ist, wir haben eine Webseite, wir haben ein GitHub Projekt. Da kriegt ihr alle Informationen, die ihr braucht. Wenn euch Informationen fehlen, geht bitte in das GitHub Projekt
50:01
und dieses hier. Das ist unser Issue Trecker Projekt und feiert uns ein Issue. Die Docs sind natürlich auch alle open source. Wenn ihr gerne möchtet, könnt ihr die auch gleich fixen. Wenn ihr mit reinspringen wollt und mitmachen wollt, ich denke, der Matchfix oder der Slack Chat
50:20
sind die besten Einstiegsmöglichkeiten, die wir aktuell haben, weil ihr direkt vom Team da abgeholt werdet und gleich sozusagen mitten im Projekt landet. Ja, das war's. Habt ihr Fragen?
50:43
Ich wiederhole die Frage. Ist gut. Sag ruhig.
51:11
Die Frage ist, wenn man ein einfaches Flatcar Hello World, so wie ich es gezeigt habe, mal hochbringen möchte, ob Images und Anleitungen dafür vorhanden sind. Ja,
51:20
das sind sie, die sind nicht bei Microsoft gehostet, sondern independent. Das Hosting wird gesponsert von Equinix Metal. Also das ist quasi eine weitere Firma. Equinix Metal benutzt Flatcar, ist eine Bare-Metal-Cloud, die man also über eine API Bare-Metal-Server deployen kann und warten kann. Die benutzen Flatcar in deren Control-Plane
51:40
für ihre Cloud und die sponsorn uns. Ganz dufte Jungs übrigens. Die Dokumentation zeigt dir bei der Insta... Also hier im Grunde genommen ganz oben ist das Hello World
52:01
mit der VM tatsächlich mit einem ganz ähnlichen Beispiel über einen Web-Server, wie du einen Web-Server hochkriegst. Wenn du bereits Cloud-Provider nutzt, dann ist es auch so, dass wir von Hause aus diverse
52:21
Cloud-Provider supporten, Deployment da. Wir sind sozusagen auf denen verfügbar. Das heißt, du kannst einfach die entweder Sachen aus dem Marketplace nutzen oder die Images nutzen, die da schon liegen. Und hier wird auch beschrieben, wie da sind auch so Hello World Sachen bei. Und ja, damit ist man dann sozusagen
52:40
nutzerseitig gleich mit dabei. Wir supporten OpenStack inoffiziell. Das ist ein sogenannter Community-Support. Wir suchen nach OpenStack Leute, die das gerne offiziell machen wollen. Oder Leute, die OpenStack benutzen. Es ist nicht viel.
53:01
Wir haben EC2 und wir haben VMware vSphere-Support drin und OpenStack liegt irgendwo dazwischen. Wir haben, glaube ich, sogar ein offizielles OpenStack-Bild. Das liegt auch auf den Image-Servern. Wir haben aktuell nur keine Testumgebung mit OpenStack. Das heißt, wenn du es gerade benutzen möchtest und da Schmerzen spürst, melde dich bitte.
53:22
Das wäre sehr wichtig für uns. Ja, bitte. Das ist eine sehr gute Frage. Soll man den QoS-Ansatz verwenden für Persistency?
53:41
Meine Rückfrage wäre auf Applikation oder auf Betriebssystemseite? Auf Applikationsseite. Dann ist die Antwort ein ganz großes Ja selbstverständlich. In der Tat ist es so, dass dieses Nicht-Requirement von Persistency
54:01
auf Betriebssystem-Ebene uns ermöglicht, In-Place-Updates zu machen. Und wenn du Persistent-Applikationen auf Containern betreibst oder auf Kubernetes betreibst, dann weißt du, Betriebssystem-Updates sind immer das große Aua. Weil viele Kubernetes Kontrollplanes und Distributionen, das schließt Klasse-
54:22
API mit ein. Machen Greengrass-Update, die deleten Instances und dann deployen sie sie komplett neu und dann ist das Betriebssystem abgegradet. Das ist sehr schmerzhaft für Stateful-Applikations, weil die dann ihren State verlieren. Wenn du den State auf lokale Disks machst. Ansonsten wirst du in Netzwerkspeicher reingezwungen,
54:41
was du manchmal nicht möchtest. Aus Kostengründen, aus Effizienzgründen. Mit Flatcar kannst du Stateful-Apps auf ein Node betreiben. Und du kannst das Betriebssystem upgraden und zurückrollen, wenn es Probleme gibt.
55:24
Gut, die Frage geht dahin, ob man die Applikationen, die auf Nodes deployed sind, verändern kann mit Flatcar. Die Antwort ist prinzipiell ja, aber das ist genau der Punkt, wo wir einen Container-Controll-Plan
55:41
quasi im Dienst sehen. Das ist etwas, was wir auf Betriebssystemseite nicht supporten wollen, weil das bedeuten würde, dass wir den State dafür im Betriebssystem halten müssten. Das klingt nach einem guten Use Case für Kubernetes. Das hat halt auch einen verteilten State. Und das gibt dir diese Management-Möglichkeiten, um Applikationen auf verschiedene Nodes zu skalieren
56:02
und zu erweitern. Und das sorgt dann auch auf Orchestrierungsebene dafür, dass alles ganz bleibt, wenn mal eine Node wegbricht. Mhm. Mhm.
56:50
In einem konkreten Fall, in dem Beispiel geht es darum, eine SSH-Config zu aktualisieren, weil die alte Unsicherheit enthält und zumindest für Dauercores empfiehlt, das nicht zu machen.
57:03
Das sehe ich ähnlich, aber ich würde es anders formulieren. Nein, nein, nein. Ich will dein Problem lösen. Kleinen Moment. Wir decken das nicht mehr ab auf der Ignition-Seite, weil sich das auf Provisionierung konzentriert. So die Empfehlung wäre, ja, wenn du eine Ansible-Infrastruktur hast, absolut
57:21
nimm Ansible und aktualisiere diese SSH- Config. Bevor du das machst, aktualisiere bitte deine Deployment Template, sodass alle neuen Knoten quasi die neue Konfiguration bekommen. Existierende Knoten verändern, wie gesagt, da ziehen wir eine Grenze. Und ich meine, da sorgt definitiv die Ansible-Infrastruktur
57:42
dafür. Ich würde das also ein bisschen nutzerfreundlicher formulieren und sagen, wenn du dieses Problem hast und das aktualisieren musst und Ansible schon deployed hast, na klar, nimmst du Ansible und ziehst die existierenden Knoten hoch. Vorher, wie gesagt, dafür sorgen, dass neue Notes mit der richtigen Konfig deployed werden. Das wäre dann wieder unsere Seite.
58:01
Das ist das, wo wir uns verantwortlich führen. Aber bei Laufzeitänderungen da treten wir zurück.
58:34
Du sagst, dass bei Verdauer-QoS Pakete fehlen, dass du Ansible überhaupt benutzen kannst?
58:40
Okay. Und Verdauer-QoS sagt, wir wollen sozusagen klein bleiben und diese Sachen bei uns nicht mehr drin haben. Das geht uns genauso, aber
59:20
Kai verweist auf eine Option, die wir im Notfall ebenfalls mit dokumentiert haben. Wenn ihr die gesamte Konfiguration, die ihr deklarativ habt auf euren Knoten, neu ausführen möchte, die wird normalerweise nur beim ersten Boot ausgeführt, dann könnt ihr so tun, als wenn die Note nie initialisiert wurde,
59:42
ist in den Docs drin, wie es geht, kann zu spannende Nebeneffekte führen, weil es nicht so gedacht ist, aber erlaubt ihr tatsächlich eine Note in den Grundzustand zu resetten und dann sozusagen alles von vorne zu machen. Weiterhin das ist auch etwas, was der Kai vorstellt, und zwar morgen Mittag.
01:00:00
Also genau wie CoreOS, Fedora CoreOS, kämpfen wir so ein bisschen mit der Grenze ziehen zwischen wie viel nehmen wir rein in das Image und wie viel supporten wir einfach nicht mehr und erwarten dann, dass Leute das in Docker-Containern benutzen. Ansible ist eins dieser Beispiele. Verschiedener Plattform-Support ist übrigens ein anderes gutes Beispiel, wenn du dir anguckst, was AWS oder GCE oder Azure heutzutage so wollen.
01:00:25
Auf einer Note, damit das sauber mit der Cloud interfaced, da sind ganz lustige Abhängigkeiten drin und das würde das Image größer machen, das wollen wir nicht. Tatsächlich arbeitet Kai an einem Projekt innerhalb von Flatcar, um das Image so composable zu machen.
01:00:44
Das Grundimage soll viel kleiner werden. Wir sehen nicht mal, warum wir in Zukunft standardmäßig grundsätzlich immer Docker mitschippen sollen, wenn Container die auch tut. Und es soll tatsächlich auch so sein, dass du verschiedene Sachen austauschen kannst, aber eben nicht auf der Granularität von Paketen, sondern auf der Granularität von Features.
01:01:01
Und wenn du dann quasi ein Ansible-Feature hinzufügen wollen würdest, wäre das eine Option, das sauber zu machen. Kai nimmt dazu System-Desis-Ex und darum dreht sich sein Vortrag morgen. Es ist also auch noch was in Zukunft, was dieses Problem wegmachen könnte. Unsere Zeit wird knapp. Eine Frage noch? Ja bitte.
01:01:33
Nicht notwendigerweise. Also ich meine, die Ansible-Geschichte zum Note-Management, die Frage ist, wie der vorgeschriebene Workflow ist, wenn man jetzt tatsächlich mal SSH-Convex austauschen muss.
01:01:45
Du kannst eine Orchestrierung nehmen und ein Konfigurationsmanagement, was Notes zur Laufzeit verändert. Es ist halt nur so, dass wir die nicht ausliefern. Das wäre dann auf der Ops-Seite zu lösen. Ich meine, wir sind userzentrisch und wir empfehlen Leuten nicht, ne, die Lidde
01:02:02
um an den Cluster und deploy mal neu, damit drei Zeilen Konfigänderungen hier werden. Es ist halt immer auch wichtig, dann die Templates zu aktualisieren. Wir hatten schon Fälle, wo das nicht getan wurde und die sind dann halt auch sehr lustig. Aber ich meine, klar, wenn du ein Konfig-Management hast, warum solltest du es nicht nutzen können?
01:02:22
Okay, vielen Dank.