Pakete und Paketmanager für k8s

Wir alle verwenden eine Art Paketmanager, einschließlich der Putzfrau Tante Galya, deren iPhone gerade in ihrer Tasche aktualisiert wird. Es gibt jedoch keine allgemeine Übereinstimmung über die Funktionen von Paketmanagern, und die Standardbetriebssysteme und Buildsysteme für RPM und DPKG werden als Paketmanager bezeichnet. Wir bieten an, über das Thema ihrer Funktionen nachzudenken - was es ist und warum sie in der modernen Welt gebraucht werden. Und dann werden wir in Richtung Kubernetes graben und Helm in Bezug auf diese Funktionen sorgfältig prüfen.


Lassen Sie uns sehen, warum in diesem Diagramm nur die Vorlagenfunktion grün hervorgehoben ist und welche Probleme bei der Montage und Verpackung, der Automatisierung der Umgebung und mehr auftreten. Aber keine Sorge, der Artikel endet nicht damit, dass alles schlecht ist. Die Community konnte sich damit nicht abfinden und bietet alternative Tools und Lösungen an - wir werden uns darum kümmern.

Ivan Glushkov ( gli ) half uns dabei mit seinem Bericht über RIT ++, einer Video- und Textversion dieser detaillierten und detaillierten Präsentation unten.

Videos dieser und anderer DevOps-Reden auf RIT ++ werden veröffentlicht und können kostenlos auf unserem Youtube-Kanal angesehen werden. Suchen Sie nach Antworten auf Ihre Arbeitsfragen.

Über den Sprecher: Ivan Glushkov entwickelt seit 15 Jahren Software. Ich habe es geschafft, in MZ, in Echo auf einer Plattform für Kommentare zu arbeiten und an der Entwicklung von Compilern für den Elbrus-Prozessor in MCST teilzunehmen. Derzeit ist er an Infrastrukturprojekten bei Postmates beteiligt. Ivan ist einer der führenden DevZen- Podcasts, in denen über unsere Konferenzen gesprochen wird: Hier geht es um RIT ++ und hier um HighLoad ++.

Paketmanager

Obwohl jeder eine Art Paketmanager verwendet, gibt es keine einheitliche Vereinbarung darüber, was es ist. Es gibt ein gemeinsames Verständnis, und jedes hat sein eigenes.

Erinnern wir uns, welche Arten von Paketmanagern zuerst in den Sinn kommen:

• Standard-Paketmanager aller Betriebssysteme: U / min, dpkg, portage , ...
• Paketmanager für verschiedene Programmiersprachen: Fracht, Kabale, Bewehrung3, Mix , ...

Ihre Hauptfunktion besteht darin, Befehle zum Installieren eines Pakets, Aktualisieren eines Pakets, Deinstallieren eines Pakets und Verwalten von Abhängigkeiten auszuführen. Bei Paketmanagern in Programmiersprachen sind die Dinge etwas komplizierter. Zum Beispiel gibt es Befehle wie "Paket starten" oder "Release erstellen" (Build / Run / Release). Es stellt sich heraus, dass dies bereits ein Build-System ist, obwohl wir es auch als Paketmanager bezeichnen.


All dies ist nur auf die Tatsache zurückzuführen, dass Sie es nicht einfach nehmen können und ... Haskell-Liebhaber diesen Vergleich verzeihen lassen. Sie können die Binärdatei ausführen, aber Sie können das Programm nicht in Haskell oder C ausführen. Zuerst müssen Sie es irgendwie vorbereiten. Diese Vorbereitung ist ziemlich kompliziert und die Benutzer möchten, dass alles automatisch erledigt wird.

Entwicklung

Derjenige, der mit GNU libtool gearbeitet hat, das für ein großes Projekt gemacht wurde, das aus einer großen Anzahl von Komponenten besteht, lacht nicht über den Zirkus. Dies ist wirklich sehr schwierig und einige Fälle können im Prinzip nicht gelöst, sondern nur umgangen werden.

Im Vergleich dazu sind moderne Paketsprachenmanager wie Cargo for Rust viel bequemer - Sie drücken den Knopf und alles funktioniert. Obwohl tatsächlich unter der Haube eine große Anzahl von Problemen gelöst werden. Darüber hinaus erfordern all diese neuen Funktionen etwas Zusätzliches, insbesondere eine Datenbank. Obwohl es im Paketmanager selbst so genannt werden kann, wie Sie möchten, nenne ich es eine Datenbank, weil Dort werden Daten gespeichert: über installierte Pakete, über deren Versionen, verbundene Repositorys, Versionen in diesen Repositorys. All dies muss irgendwo gespeichert werden, damit es eine interne Datenbank gibt.

Die Entwicklung in dieser Programmiersprache, das Testen dieser Programmiersprache, wird gestartet - all dies ist integriert und befindet sich im Inneren. Die Arbeit wird sehr bequem . Die meisten modernen Sprachen haben diesen Ansatz unterstützt. Sogar diejenigen, die nicht unterstützt haben, beginnen zu unterstützen, weil die Gemeinde drückt und sagt, dass es in der modernen Welt ohne sie unmöglich ist.

Aber jede Lösung hat immer nicht nur Vor-, sondern auch Nachteile . Der Nachteil hierbei ist, dass Sie Wrapper, zusätzliche Dienstprogramme und eine integrierte „Datenbank“ benötigen.

Docker

Denken Sie, Docker ist ein Paketmanager oder nicht?

Egal wie, aber im Wesentlichen ja. Ich kenne kein korrekteres Dienstprogramm, um die Anwendung vollständig mit allen Abhängigkeiten zusammenzusetzen und sie auf Knopfdruck zum Laufen zu bringen. Was ist das, wenn kein Paketmanager? Dies ist ein großartiger Paketmanager!

Maxim Lapshin hat bereits gesagt, dass es mit Docker viel einfacher geworden ist, und das ist auch so. Docker verfügt über ein integriertes Build-System, alle diese Datenbanken, Bindungen und Dienstprogramme.

Was ist der Preis für alle Vorteile? Diejenigen, die mit Docker arbeiten, denken wenig über industrielle Anwendungen nach. Ich habe eine solche Erfahrung und der Preis ist tatsächlich sehr hoch:

• Die Menge an Informationen (Bildgröße), die im Docker-Image gespeichert werden müssen. Sie benötigen alle Abhängigkeiten, Teile von Dienstprogrammen und Bibliotheken, um sie zu packen. Das Image ist groß und Sie müssen in der Lage sein, damit zu arbeiten.
• Es ist viel komplizierter, dass ein Paradigmenwechsel stattfindet.

Zum Beispiel hatte ich die Aufgabe, ein Programm zur Verwendung von Docker zu übertragen. Das Programm wurde im Laufe der Jahre von einem Team entwickelt. Ich komme, wir machen alles, was in Büchern geschrieben steht: Wir malen Benutzergeschichten, Rollen, sehen, was und wie sie tun, ihre Standardroutinen.

Ich sage:

- Docker kann alle Ihre Probleme lösen. Beobachten Sie, wie das gemacht wird.

- Alles wird auf dem Knopf sein - großartig! Wir möchten jedoch, dass SSH in Kubernetes-Containern ausgeführt wird.

- Warten Sie, kein SSH irgendwo.

- Ja, ja, alles ist in Ordnung ... Aber ist SSH möglich?

Um die Wahrnehmung der Benutzer in eine neue Richtung zu lenken, ist viel Zeit, Aufklärungsarbeit und viel Aufwand erforderlich.

Ein weiterer Preisfaktor ist, dass die Docker-Registrierung ein externes Repository für Images ist, das irgendwie installiert und gesteuert werden muss. Es hat seine eigenen Probleme, einen Müllsammler und so weiter, und es kann oft fallen, wenn Sie es nicht befolgen, aber das ist alles gelöst.

Kubernetes

Endlich kamen wir zu Kubernetes. Dies ist ein cooles OpenSource-Anwendungsverwaltungssystem, das von der Community aktiv unterstützt wird. Obwohl Kubernetes ursprünglich ein Unternehmen verlassen hat, hat es jetzt eine riesige Community, und es ist unmöglich, mitzuhalten, es gibt praktisch keine Alternativen.

Interessanterweise arbeiten alle Kubernetes-Knoten in Kubernetes selbst über Container, und alle externen Anwendungen arbeiten über Container - alles funktioniert über Container ! Dies ist sowohl ein Plus als auch ein Minus.

Kubernetes bietet viele nützliche Funktionen und Eigenschaften: Verteilung, Fehlertoleranz, die Fähigkeit, mit verschiedenen Cloud-Diensten zu arbeiten, und die Ausrichtung auf die Microservice-Architektur. Das alles ist interessant und cool, aber wie installiert man die Anwendung in Kubernetes?

Wie installiere ich die App?

Installieren Sie das Docker-Image in der Docker-Registrierung.

Hinter diesem Satz verbirgt sich ein Abgrund. Sie stellen sich vor - Sie haben eine Anwendung, die beispielsweise in Ruby geschrieben wurde, und müssen das Docker-Image in die Docker-Registrierung einfügen. Dies bedeutet, dass Sie:

• Bereiten Sie ein Docker-Image vor
• verstehen, wie es läuft, auf welchen Versionen es basiert;
• in der Lage sein, es zu testen;
• Sammeln Sie, füllen Sie die Docker-Registrierung aus, die Sie übrigens zuvor installiert haben.

In der Tat ist dies ein großer, großer Schmerz in einer Zeile.

Außerdem müssen Sie das Anwendungsmanifest noch in Begriffen (Ressourcen) von k8s beschreiben. Die einfachste Option:

• Beschreiben Sie Bereitstellung + Pod, Service + Eingang (möglicherweise).
• Führen Sie den Befehl kubectl apply -f resources.yaml aus und übertragen Sie alle Ressourcen auf diesen Befehl.

Gandhi reibt seine Hände auf der Folie - anscheinend habe ich den Paketmanager in Kubernetes gefunden. Kubectl ist jedoch kein Paketmanager. Er sagt nur, dass ich einen solchen Endzustand des Systems sehen möchte. Dies bedeutet nicht, ein Paket zu installieren, nicht mit Abhängigkeiten zu arbeiten, nicht zu erstellen - es ist nur "Ich möchte diesen endgültigen Zustand sehen".

Helm

Endlich kamen wir zu Helm. Helm ist ein Mehrzweckdienstprogramm. Nun werden wir uns überlegen, welche Entwicklungsbereiche von Helm sind und damit arbeiten.

Template Engine

Erstens ist Helm eine Template-Engine. Wir haben besprochen, welche Ressourcen vorbereitet werden müssen, und das Problem besteht darin, in Kubernetes (und nicht nur in Yaml) zu schreiben. Das Interessanteste ist, dass dies statische Dateien für Ihre spezifische Anwendung in dieser speziellen Umgebung sind.

Wenn Sie jedoch mit mehreren Umgebungen arbeiten und nicht nur über Produktion, sondern auch Staging, Test, Entwicklung und verschiedene Umgebungen für verschiedene Teams verfügen, müssen Sie über mehrere ähnliche Manifeste verfügen. Zum Beispiel, weil in einem von ihnen mehrere Server vorhanden sind und Sie eine große Anzahl von Replikaten benötigen und in dem anderen nur ein Replikat. Es gibt keine Datenbank, Zugriff auf RDS, und Sie müssen PostgreSQL darin installieren. Und hier haben wir die alte Version, und wir müssen alles ein bisschen umschreiben.

All diese Vielfalt führt dazu, dass Sie Ihr Manifest für Kubernetes nehmen, überall kopieren und überall reparieren müssen: Hier ersetzen Sie eine Ziffer, hier ist etwas anderes. Das wird sehr unangenehm.

Die Lösung ist einfach: Sie müssen Vorlagen eingeben . Das heißt, Sie bilden ein Manifest, definieren darin Variablen und senden dann die extern als Datei definierten Variablen. Die Vorlage erstellt das endgültige Manifest. Es stellt sich heraus, dass für alle Umgebungen dasselbe Manifest wiederverwendet wird, was viel praktischer ist.

Zum Beispiel das Manifest für Helm.

• Der wichtigste Teil in Helm ist Chart.yaml , das beschreibt, welche Art von Manifest es ist, welche Versionen, wie es funktioniert.
• Vorlagen sind nur Kubernetes-Ressourcenvorlagen, die eine Art von Variablen in sich enthalten. Diese Variablen müssen in einer externen Datei oder in der Befehlszeile definiert werden, jedoch immer extern.
• values.yaml ist der Standardname für die Datei mit Variablen für diese Vorlagen.

Der einfachste Startbefehl für die Installation von chart ist helm install ./wordpress (Ordner). Um einige Parameter neu zu definieren, sagen wir: "Ich möchte genau diese Parameter neu definieren und solche und solche Werte festlegen."

Helm bewältigt diese Aufgabe, daher markieren wir sie im Diagramm grün.


Richtig, Nachteile erscheinen:

• Ausführlichkeit . Ressourcen werden vollständig in Bezug auf Kubernetes definiert, Konzepte für zusätzliche Abstraktionsebenen werden nicht eingeführt: Wir schreiben einfach alles, was wir für Kubernetes schreiben möchten, und ersetzen dort Variablen.
• Wiederholen Sie sich nicht - nicht zutreffend. Es ist oft notwendig, dasselbe zu wiederholen. Wenn Sie zwei ähnliche Dienste mit unterschiedlichen Namen haben, müssen Sie den gesamten Ordner vollständig kopieren (meistens tun sie dies) und die erforderlichen Dateien ändern.

Bevor wir uns in Richtung Helm stürzen - einem Paketmanager, für den ich Ihnen das alles erzähle, wollen wir sehen, wie Helm mit Abhängigkeiten arbeitet.

Arbeiten Sie mit Abhängigkeiten

Helm ist schwer mit Abhängigkeiten zu arbeiten. Erstens gibt es eine require.yaml-Datei, die in das passt, wovon wir abhängig sind. Während er mit Anforderungen arbeitet, führt er Anforderungen aus. Lock - Dies ist der aktuelle Status (Nugget) aller Abhängigkeiten. Danach lädt er sie in einen Ordner namens / chart herunter.

Es gibt Tools zum Verwalten: wen, wie, wo eine Verbindung hergestellt werden soll - Tags und Bedingungen , mit denen in welcher Umgebung festgelegt wird, abhängig von welchen externen Parametern, welche Abhängigkeiten verbunden werden sollen oder nicht.

Angenommen, Sie haben PostgreSQL für die Staging-Umgebung (oder RDS für die Produktion oder NoSQL für Tests). Wenn Sie dieses Paket in Production installieren, wird PostgreSQL nicht installiert, da es dort nicht benötigt wird - nur mithilfe von Tags und Bedingungen.

Was ist hier interessant?

• Helm mischt alle Ressourcen aller Abhängigkeiten und Anwendungen.
• sortieren -> installieren / aktualisieren

Nachdem wir alle Abhängigkeiten in / chart heruntergeladen haben (diese Abhängigkeiten können beispielsweise 100 sein), nimmt Helm alle darin enthaltenen Ressourcen und kopiert sie. Nachdem er die Vorlagen gerendert hat, sammelt er alle Ressourcen an einem Ort und sortiert sie in einer eigenen Reihenfolge. Sie können diese Reihenfolge nicht beeinflussen. Sie müssen selbst bestimmen, wovon Ihr Paket abhängt. Wenn das Paket transitive Abhängigkeiten aufweist, müssen Sie alle in die Beschreibung in require.yaml aufnehmen. Dies muss berücksichtigt werden.

Paketmanager

Helm installiert Anwendungen und Abhängigkeiten, und Sie können Helm install mitteilen - und das Paket wird installiert. Das ist also ein Paketmanager.

Wenn Sie über ein externes Repository verfügen, in das Sie das Paket hochladen, können Sie nicht als lokaler Ordner darauf zugreifen, sondern einfach sagen: "Nehmen Sie dieses Paket aus diesem Repository und installieren Sie es mit solchen und solchen Parametern."

Es gibt offene Repositories mit vielen Paketen. Sie können beispielsweise Folgendes ausführen: helm install -f prod / values.yaml Stable / WordPress

Aus dem stabilen Repository nehmen Sie WordPress und installieren es selbst. Sie können alles tun: suchen / aktualisieren / löschen. Es stellt sich wirklich heraus, dass Helm ein Paketmanager ist.

Aber es gibt Nachteile: Alle transitiven Abhängigkeiten müssen darin enthalten sein. Dies ist ein großes Problem, wenn transitive Abhängigkeiten unabhängige Anwendungen sind und Sie zum Testen und Entwickeln separat mit ihnen arbeiten möchten.

Ein weiteres Minus ist die End-to-End-Konfiguration . Wenn Sie eine Datenbank haben und deren Name auf alle Pakete übertragen werden muss, kann dies sein, dies ist jedoch schwierig.



Meistens haben Sie ein kleines Paket installiert und es funktioniert. Die Welt ist komplex: Die Anwendung hängt von der Anwendung ab, was wiederum auch von der Anwendung abhängt - Sie müssen sie irgendwie geschickt konfigurieren. Helm weiß nicht, wie er das unterstützen soll oder unterstützt es bei großen Problemen, und manchmal muss man viel mit einem Tamburin tanzen, damit es funktioniert. Dies ist schlecht, daher wird der "Paketmanager" im Diagramm rot hervorgehoben.

Montage und Verpackung

"Sie können die Anwendung in Kubernetes nicht einfach abrufen und ausführen". Sie müssen es zusammenstellen, dh ein Docker-Image erstellen, es in die Docker-Registrierung schreiben usw. Obwohl die gesamte Paketdefinition in Helm ist. Wir bestimmen, was das Paket ist, welche Funktionen und Felder vorhanden sein sollten, Signaturen und Authentifizierung (das Sicherheitssystem Ihres Unternehmens wird sehr zufrieden sein). Daher scheinen Montage und Verpackung einerseits unterstützt zu werden, andererseits ist die Arbeit mit Docker-Images nicht konfiguriert.

Mit Helm können Sie die Anwendung nicht ohne Docker-Image ausführen. Gleichzeitig ist Helm nicht für die Montage und Verpackung konfiguriert, dh er weiß nicht, wie er mit Docker-Images arbeiten soll.

Dies ist das Gleiche, als würden Sie zum Ausführen einer Upgrade-Installation für eine kleine Bibliothek in einen entfernten Ordner gesendet, um den Compiler auszuführen.

Deshalb sagen wir, dass Helm nicht weiß, wie man mit Bildern arbeitet.

Entwicklung

Der nächste Kopfschmerz ist die Entwicklung. In der Entwicklung möchten wir unseren Code schnell und bequem ändern. Die Zeit ist vergangen, als Sie Löcher in Lochkarten gestanzt haben, und das Ergebnis wurde nach 5 Tagen erhalten. Jeder ist es gewohnt, einen Buchstaben im Editor durch einen anderen zu ersetzen, die Kompilierung zu drücken, und das bereits geänderte Programm funktioniert.

Hier stellt sich heraus, dass beim Ändern des Codes viele zusätzliche Aktionen erforderlich sind: Vorbereiten einer Docker-Datei; Führen Sie Docker so aus, dass das Image erstellt wird. irgendwohin schieben; Bereitstellung im Kubernetes-Cluster. Und nur dann erhalten Sie, was Sie in der Produktion wollen, und Sie können den Code überprüfen.

Es gibt immer noch Unannehmlichkeiten aufgrund des zerstörerischen Upgrades des Update- Helms. Sie haben sich angesehen, wie alles funktioniert. Durch kubectl exec haben Sie in den Container geschaut. Alles ist in Ordnung. Zu diesem Zeitpunkt starten Sie das Update, ein neues Image wird heruntergeladen, neue Ressourcen werden gestartet und die alten werden gelöscht - Sie müssen alles von vorne beginnen.

Der größte Schmerz sind die großen Bilder . Die meisten Unternehmen arbeiten nicht mit kleinen Anwendungen. Oft, wenn nicht ein Supermonolith, dann zumindest ein kleiner Monolith. Mit der Zeit wachsen die Jahresringe, die Codebasis nimmt zu und die Anwendung wird allmählich ziemlich groß. Ich bin wiederholt auf Docker-Bilder gestoßen, die größer als 2 GB sind. Stellen Sie sich jetzt vor, Sie nehmen eine Änderung in einem Byte in Ihrem Programm vor, drücken eine Taste und ein Docker-Image mit zwei Gigabyte beginnt sich zusammenzusetzen. Dann drücken Sie die nächste Taste und die Übertragung von 2 GB zum Server beginnt.

Mit Docker können Sie mit Ebenen arbeiten, d. H. prüft, ob es die eine oder andere Schicht gibt und sendet die fehlende. Aber die Welt ist so, dass es meistens eine große Schicht ist. Während 2 GB an den Server gehen, während sie mit der Docker-Registrierung an Kubernetes gehen, werden sie auf alle Arten ausgerollt, bis Sie endlich anfangen, können Sie sicher Tee trinken.

Helm bietet keine Hilfe bei großen Docker-Bildern. Ich glaube, das sollte nicht sein, aber Helm-Entwickler wissen es besser als alle Benutzer, und Steve Jobs lächelt darüber.



Der Block mit der Entwicklung wurde ebenfalls rot.

Umgebungsautomatisierung

Die letzte Richtung - Automatisierung der Umwelt - ist ein interessanter Bereich. Vor der Welt von Docker (und Kubernetes als verwandtes Modell) gab es keine Möglichkeit zu sagen: "Ich möchte meine Anwendung auf diesem Server oder auf diesen Servern installieren, sodass es n Replikate, 50 Abhängigkeiten gibt und alles automatisch funktioniert!" So könnte man sagen, was war, aber nicht!

Kubernetes bietet dies und es ist logisch, es irgendwie zu verwenden, um beispielsweise zu sagen: "Ich stelle hier eine neue Umgebung bereit und möchte, dass alle Entwicklungsteams, die ihre Anwendungen vorbereitet haben, nur auf eine Schaltfläche klicken können und alle diese Anwendungen automatisch in der neuen Umgebung installiert werden." . Theoretisch sollte Helm dabei helfen, damit die Konfiguration von überall aus einer externen Datenquelle - S3, GitHub - übernommen werden kann.

Es ist ratsam, dass es in Helm einen speziellen Knopf gibt: "Tu mir schon endlich gut!" - und es würde sofort gut werden. Mit Kubernetes können Sie dies tun.

Dies ist besonders praktisch, da Kubernetes überall ausgeführt werden kann und über die API funktioniert. Wenn Sie minikube lokal starten, entweder in AWS oder in der Google Cloud Engine, erhalten Sie Kubernetes sofort und arbeiten überall gleich: Drücken Sie eine Taste und alles ist sofort in Ordnung.

Es scheint, dass Helm Ihnen dies natürlich erlaubt. Denn was war sonst der Sinn der Schaffung von Helm im Allgemeinen?

Aber es stellt sich heraus, nein!


Es gibt keine Automatisierung der Umgebung.

Alternativen

Wenn es eine Anwendung von Kubernetes gibt, die jeder verwendet (es ist jetzt tatsächlich die Lösung Nummer 1), Helm jedoch die oben diskutierten Probleme hat, konnte die Community nicht anders, als zu reagieren. Es begann, alternative Werkzeuge und Lösungen zu schaffen.

Template-Engines

Es scheint, dass Helm als Template-Engine alle Probleme gelöst hat, aber die Community schafft immer noch Alternativen. Ich möchte Sie an die Probleme der Template-Engine erinnern: Ausführlichkeit und Wiederverwendung von Code.

Ein guter Vertreter hier ist Ksonnet. Es verwendet ein grundlegend anderes Modell von Daten und Konzepten und arbeitet nicht mit Kubernetes-Ressourcen, sondern mit eigenen Definitionen:
Prototyp (Parameter) -> Komponente -> Anwendung -> Umgebungen.


Es gibt Teile, aus denen der Prototyp besteht. Der Prototyp wird durch externe Daten parametrisiert und die Komponente wird angezeigt. Eine Anwendung besteht aus mehreren Komponenten, die Sie ausführen können. Es läuft in verschiedenen Umgebungen. Hier gibt es einige klare Links zu Kubernetes-Ressourcen, aber möglicherweise gibt es keine direkte Analogie.

Das Hauptziel von Ksonnet war natürlich die Wiederverwendung von Ressourcen . Sie wollten sicherstellen, dass Sie den Code nach dem Schreiben später überall verwenden können, was die Entwicklungsgeschwindigkeit erhöht. Wenn Sie eine große externe Bibliothek erstellen, können Benutzer ihre Ressourcen dort ständig veröffentlichen, und die gesamte Community kann sie wiederverwenden.

Theoretisch ist dies praktisch. Ich habe es praktisch nicht benutzt.

Paketmanager

, — , , . Ksonnet . Ksonnet Helm , , .. , , , .


, , , , . . , , , 0.1. , .


, — KubePack , .

Entwicklung

:

1. Helm;
   
2. Helm;
   
3. , ;
   
4. , .
   

1. Helm

— Draft . — , , . Draft — Heroku-style:

• (pack);
• , , Python «Hello, world!»;
• , Docker- ( );
• , , docker-registry, ;
• .

, , .

Helm, Draft Helm-, production ready, , Draft Helm-, . .

, Draft , Helm-. Draft — .

2. Helm

Helm Charts Kubernetes-, Helm Charts. :

• GitKube;
• Skaffold;
• Forge.

Helm, . , , command line interface, Chart , git push .

, docker build, docker push kubectl rollout. , Helm, . .

3.

— . — Metaparticle . , Python, Python , .

, , , sysconfig .. .

, , , - Kubernetes-.

: , ; , ; ..


, , , - , Python- Kubernetes-. ?

- , . . , , preinstall , - . Kubernetes-, Metaparticle, .

, , Kubernetes- . , , Metaparticle.



Metaparticle, Helm . , .

Telepresence/Ksync — . , , Helm-, . , - , - , , . , Production-, Production - .

Kubernetes , Docker, registry, Kubernetes. . , .

, , , Development . : , , , , — , , , Helm, , .

, .

4. Kubernetes Kubernetes

, Kubernetes Kubernetes. , Helm- , . , . , Docker-compose .

Docker-compose , , , , Docker, Kubernetes, Docker-compose, . , . , Docker. .

minikube , Docker-compose, . , , Docker-compose — 10 . , .


Docker-compose, , .

, — Helm, , , Helm - . CI/CD, , . — Helm, ? , , .

CI/CD, , docker', set-, , — .

CI/CD — , .

Zusammenfassung

5 Helm . , . , , . , , , .

Helm

, , Helm . , Helm , . , , , Helm.

, Road Map. Kuberneres Helm community , , Helm V3 .

Tiller, cli

, . Helm :

1. , (cmd ..).
   
2. Tiller — , Kubernetes.
   

Tiller , Command Line Interface. : « Chart» — Helm , , Tiller', : «, - ! , Kubernetes-» — .

Helm, Tiller , . , , , , Tiller' — namespace . Tiller namespace, , . , .

V3 Tiller .


? , , Command Line Interface, , Kubernetes. , Kubernetes , Tiller. kubectl cli .

Tiller . , Kubernetes Command Line Interface : , , , pre- post-. .

Lua- Chart

, — , lua- . Chart lua-, . . , . , , , .


Lua , , , - , , .

, , . , . Kubernetes, - , , , , . Mal sehen, was passiert.

Release- + secret

, , Release- , Release . , Release-, , , CRD, , .

namespace

Release- namespace, , - Tiller' namespace — , .

CRD: controller

, CRD-controller Helm , push-. .

, .


, Helm . , , , . , , . Helm — - Kubernetes. - , , .

, CI/CD , . SlackWir haben einen Bot, der meldet, wann ein neuer Build im Master übergeben wurde und dass alle Tests erfolgreich waren. Sie sagen ihm: "Ich möchte dies in Staging installieren" - und er installiert, Sie sagen: "Ich möchte dort einen Test durchführen!" - und er fängt an. Ziemlich bequem.

Verwenden Sie für die Entwicklung Docker-Compose oder Telepresence.

Mehrere Versionen eines Dienstes

Am Ende werden wir die Situation analysieren, wenn es zwei Anwendungen A und B gibt, die von C, aber C unterschiedlicher Versionen abhängen. Müssen Sie dieses Problem lösen:

• für die Entwicklung, weil wir tatsächlich dasselbe entwickeln müssen, aber zwei verschiedene Versionen;
• zur Freilassung;
• Bei einem Namenskonflikt kann die Installation von zwei Paketen unterschiedlicher Versionen in allen Standardpaketmanagern zu Problemen führen.

Tatsächlich entscheidet Kubernetes alles für uns - Sie müssen es nur richtig verwenden.



Ich würde empfehlen, 4 Diagramme in Bezug auf Helm und 3 Repositorys zu erstellen (für das C-Repository sind dies nur zwei verschiedene Zweige). Was am interessantesten ist, alle Installationen für v1 und für v2 sollten in sich Informationen über die Version oder für welchen Dienst sie erstellt wurde. Eine Lösung auf der Folie, Anhang C; Der Versionsname gibt an, dass dies Version v1 für Dienst A ist. Der Dienstname enthält auch die Version. Dies ist das einfachste Beispiel, Sie können es ganz anders machen. Das Wichtigste ist jedoch, dass die Namen eindeutig sind.

Das zweite sind transitive Abhängigkeiten, und hier ist es komplizierter.


Sie entwickeln beispielsweise eine Kette von Diensten und möchten A testen. Dazu müssen Sie alle Abhängigkeiten, von denen A abhängt, einschließlich Transitiv, an die Helmdefinition Ihres Pakets übergeben. Gleichzeitig möchten Sie B entwickeln und auch testen - wie das geht, ist unverständlich, da Sie alle transitiven Abhängigkeiten genauso gut einfügen müssen.

Daher rate ich Ihnen, nicht alle Abhängigkeiten in jedem Paket hinzuzufügen, sondern sie unabhängig zu machen und von außen zu steuern, was ausgeführt wird. Dies ist unpraktisch, aber es ist das kleinere von zwei Übeln.

Nützliche Links

• Entwurf

• GitKube

• Helm

• Ksonnet

• Telegrammaufkleber: eins , zwei

• Sig-Apps

• KubePack

• Metapartikel

• Gerüst

• Helm v3

• Docker-Compose

• Ksync

• Telepräsenz

• Drohne

• Schmieden

Profil des Sprechers Ivan Glushkov auf GitHub , auf Twitter , auf Habr .

Tolle Neuigkeiten

Auf unserem Youtube-Kanal haben wir ein Video aller Berichte über DevOps vom RIT ++ Festival eröffnet . Dies ist eine separate Wiedergabeliste , aber in der vollständigen Liste der Videos gibt es viele nützliche Dinge von anderen Konferenzen.

Besser noch, abonnieren Sie den Kanal und den Newsletter , denn im kommenden Jahr werden wir viele Entwickler haben : im Mai das Framework von RIT ++; im Frühjahr, Sommer und Herbst als Teil von HighLoad ++ und als separater Herbst DevOpsConf Russia .