Juju auf einen Blick

Neulich bin ich auf ein Canonical Juju Tool gestoßen.


Aus dem Internet geht hervor, dass es sich um ein Konfigurationsmanagement-Tool wie Chef, Ansible oder Puppet handelt.


Ich las schräg die Docks darauf, schaute in die Repositories mit Charms-Modulen (analog zu Kochbüchern oder Spielbüchern) und argumentierte, dass dies nicht so ist.


Juju ähnelt eher einem VM-agnostischen Orchester (wie Nomad oder Kubernetes). Darauf können Sie die Infrastrukturkonfiguration der Anwendung deklarativ beschreiben: Welche Anwendungen führen wir aus, auf welchen Computern, in wie vielen Kopien, wie sind sie mit anderen Diensten verbunden.
Im Gegensatz zu Kubernetes kann es jedoch nicht nur mit Docker, sondern auch mit jeder Art von virtuellen Maschinen funktionieren.


Sie sagen, dass der Kernel, der Agent und der Client in Golang geschrieben sind - und ich habe sie nicht angesehen.


Der Teil, der sich auf die Konfiguration selbst bezieht, wird normalerweise in einer Kombination aus YAML und Python beschrieben (die Docks besagen, dass Sie neben Python auch andere Sprachen verwenden können).


Wie funktioniert das alles?


Haftungsausschluss : Dieser Artikel erhebt keinen Anspruch auf vollständige und genaue Beschreibung. Ich sehe ihn eher als eine Möglichkeit, die Eintrittsschwelle für diejenigen zu senken, die sich Juju ansehen und beim Navigieren in der Dokumentation helfen möchten.


Die vollständige Dokumentation finden Sie hier: https://docs.jujucharms.com/


Wie bereits oben geschrieben, gibt es in Juju mehrere Komponenten:


  • Der Controller ist der Serverteil, der virtuelle Maschinen zuweist. Jeder [Cloud] -Anbieter verfügt über einen eigenen Controller (auch für nicht ganz Cloud-Anbieter wie lokales LXD oder Metal as a Service ).
    Die Steuerung ist eine monolithische Anwendung aus einer Komponente. In jedem Anbieter muss mindestens eine Controller-Kopie ausgeführt werden. Es gibt einige HA, aber ich habe mich nicht damit befasst.
  • Agent - Schalten Sie jede virtuelle Maschine ein. Es gibt zwei Arten von Agenten - für die Maschine und für die Einheit. Es scheint, dass einer von ihnen auf dem Host-Computer und einer auf der virtuellen Maschine gespeichert ist - ich habe auch nicht im Detail darauf eingegangen.
  • Der Client ist ein CLI-Tool zur Verwaltung dieser gesamten Wirtschaft.
  • GUI
  • Eine deklarative Beschreibung aller Benutzerkomponenten (Anwendungen, Maschinen usw.)
  • Benutzerdefinierter Code zum Einrichten einer separaten virtuellen Maschine heißt Charms

(Eigentlich gibt es einen größeren Baum von Komponenten, aber für diese Geschichte werden wir ihn vereinfachen, damit es einfacher ist zu verstehen, was was ist.)


In einer deklarativen Beschreibung können Sie ungefähr die folgenden Strukturen von Komponenten erstellen (Diagramme werden automatisch von der GUI gezeichnet):
Bild


Der Serverteil erstellt dort irgendwie virtuelle Maschinen, zieht Abhängigkeiten, stellt Beziehungen zwischen ihnen her, verfolgt die auftretenden Signale - dort scheint alles ziemlich normal zu sein, wie bei anderen Orchestratoren.


Und hier sind die Module zum Konfigurieren von virtuellen Maschinen, die als Charms (Einheit - Charm) bezeichnet werden. Schauen wir uns das genauer an.


Es scheint, dass ich Chef, Ansible und Puppet kenne, wahrscheinlich gibt es hier nichts Neues, aber das ist nicht so. Die Entwickler von Juju haben kein DSL erstellt, um die Ressourcen im System deklarativ zu beschreiben. Stattdessen erstellten sie ein Framework, mit dem ganz normaler Python- oder Bash-Code idempotent sein und einem Juju-Controller zugeordnet werden kann.


Charm Gerät


Die Reize selbst sind nicht sehr einfach. Durch strukturelle Komplexität erinnern sie an Kochbücher des Küchenchefs oder an die Rolle des Ansible. Tatsächlich sind sie eher ein Analogon von Ressourcen als Kochbücher.


Sie bestehen aus Metadaten / deklarativen Teilen, Peremptory Hooks (Reaktion auf Ereignisse) und allen Arten von Datendateien wie zusätzlichen Skripten, Dokumentationen oder typischen Konfigurationen.


Der deklarative Teil beschreibt die Charm-Abhängigkeitsschnittstellen (zum Beispiel hängt der WordPress-Charm von MySQL ab und der MySQL-Charm bietet diese Schnittstelle), die Systemkompatibilität, Tags, Konfigurationsparameter (wie Cookie-Attribute) und Programmebenen in Abhängigkeit von anderen Charms ( Zum Beispiel enthalten die meisten Charms eine layer:basic ).


In imperativen Hooks wird eine Reaktion auf alle Arten von externen Ereignissen beschrieben. Beispielsweise install wir install erforderliche Paket für das install , configure es für das configure und start Dienst für das Startereignis.


Dies alles ist auf einer gewöhnlichen Python mit Dekorateuren geschrieben (irgendwo habe ich die Aussage gelesen, dass man auf alles schreiben kann, auch auf eine Bash, aber ich habe keine Beispiele gesehen).


Ein klassisches Beispiel ist NTP: https://github.com/lampkicking/charm-ntp


Interessanterweise wird beim Kompilieren des Charms anscheinend eine vollständig eigenständige Anwendung erhalten, die ohne zusätzliche Abhängigkeiten auf dem Server ausgeführt werden kann. In der kompilierten Version habe ich gesehen, dass sie den Inhalt aller von ihr verwendeten Ebenen sowie die Tarballs aller verwendeten Python-Module enthält.


Beispiel für NTP: https://jaas.ai/ntp/32 (siehe Liste der Dateien auf der rechten Seite).


Zusammenfassung


Juju hat einen sehr interessanten und ungewöhnlichen Ansatz zur Beschreibung und Einrichtung der Infrastruktur.


Höchstwahrscheinlich hat Juju eine höhere Einstiegsschwelle als der Koch, höchstwahrscheinlich entwickeln sich Reize langsamer als Kochbücher und Spielbücher und erfordern mehr Programmierkenntnisse.


Andererseits nehme ich an, dass ein Modell mit Ereignis-Hooks Sie dazu ermutigt, korrekteren Code zu schreiben.


Es schien mir, dass Juju sich eher an Infrastrukturprogrammierer richtet (diejenigen, die vor 5-7 Jahren viele CLI-Tools auf Python unter Linux geschrieben haben), die jetzt Server konfigurieren müssen, während Chef / Ansible - an Administratoren, die statt eines - Zwei müssen jetzt hundert oder zwei Server konfigurieren.


Soll ich Juju 2019 verwenden?
Nicht sicher:


  • Sie werden neue (Cloud-native) Anwendungen in Docker in Docker einbinden und auf dem Cuber oder ECS starten
  • Für "alte" Anwendungen haben Sie wahrscheinlich bereits Bereitstellungsskripte für das Ensemble oder den Chef geschrieben
  • Für neue Projekte mit "alter" Architektur - vielleicht. ABER :
  • Fast niemand kennt Juju in RuNet. Dies ist der erste Artikel auf Russisch, der ein wenig beschreibt, was es ist

Wenn Sie mit Juju arbeiten, schreiben Sie in die Kommentare, in denen ich einen Fehler gemacht habe - schließlich habe ich die Docks für sie nur 2-3 Stunden lang gelesen.

Source: https://habr.com/ru/post/de457816/


All Articles