Wir haben bereits über berichtet, das die Entwicklung verteilter Anwendungen ermöglicht und deren Verpackung. Es bleibt nur noch wenig zu lernen: diese Anwendungen bereitzustellen und zu verwalten. Keine Sorge, wir haben alles vorgesehen! Wir haben alle Best Practices zur Arbeit mit Tarantool Cartridge gesammelt und geschrieben , die das Paket auf Servern verteilt, Instanzen startet, sie in einem Cluster zusammenführt, die Autorisierung einrichtet, vshard bootstrapped, den automatischen Failover aktiviert und die Cluster-Konfiguration patched.
Interessiert? Dann kommen Sie bitte unter den Cut, wir werden alles erzählen und zeigen.
Lassen Sie uns mit einem Beispiel beginnen
Wir werden nur einen Teil der Funktionalität unserer Rolle betrachten. Eine vollständige Beschreibung aller Möglichkeiten und Eingabeparameter finden Sie jederzeit in . Aber besser einmal ausprobieren als hundertmal sehen, also lassen Sie uns eine kleine Anwendung bereitstellen.
Tarantool Cartridge hat die Erstellung einer kleinen Cartridge-Anwendung, die Informationen über Bankkunden und deren Konten speichert und ein API zur Datenverwaltung über HTTP bereitstellt. Dazu werden im Programm zwei mögliche Rollen beschrieben: API und storage, die Instanzen zugewiesen werden können.
Die Cartridge sagt nichts darüber aus, wie Prozesse gestartet werden; sie bietet lediglich die Möglichkeit, bereits gestartete Instanzen zu konfigurieren. Den Rest muss der Benutzer selbst erledigen: Konfigurationsdateien verteilen, Dienste starten und die Topologie einrichten. Aber damit werden wir uns nicht beschäftigen, das wird Ansible für uns übernehmen.
Von den Worten zur Tat
Also, lassen Sie uns unsere Anwendung auf zwei virtuellen Maschinen bereitstellen und eine einfache Topologie einrichten:
- Replikatsatz
app-1wird die Rolle implementierenAPI, die die Rollevshard-router. Hier wird es nur eine Instanz geben. - Replikatsatz
storage-1implementiert die Rollestorage(und gleichzeitigvshard-storage), wir fügen zwei Instanzen von verschiedenen Maschinen hinzu.
Um das Beispiel zu starten, benötigen wir und (Version 2.8 oder höher).
Die Rolle selbst befindet sich in . Das ist ein Repository, das es ermöglicht, eigene Entwicklungen zu teilen und fertige Rollen zu verwenden.
Klonen wir das Repository mit dem Beispiel:
$ git clone https://github.com/dokshina/deploy-tarantool-cartridge-app.git
$ cd deploy-tarantool-cartridge-app && git checkout 1.0.0Heben wir die virtuellen Maschinen an:
$ vagrant upInstallieren wir die ansible-Rolle Tarantool Cartridge:
$ ansible-galaxy install tarantool.cartridge,1.0.1Starten wir die installierte Rolle:
$ ansible-playbook -i hosts.yml playbook.ymlWarten wir, bis die Ausführung des Playbooks abgeschlossen ist, und gehen wir weiter zu und genießen das Ergebnis:
Daten können eingespeist werden. Cool, oder?
Und jetzt lassen Sie uns herausfinden, wie man damit arbeitet, und gleichzeitig fügen wir noch ein weiteres Replika-Set in die Topologie hinzu.
Wir beginnen mit dem Verständnis
Also, was ist passiert?
Wir haben zwei virtuelle Maschinen hochgefahren und ein Ansible-Playbook ausgeführt, das unseren Cluster eingerichtet hat. Lassen Sie uns den Inhalt der Datei ansehen playbook.yml:
---
- name: Deploy meine Tarantool Cartridge-App
hosts: all
become: true
become_user: root
tasks:
- name: Tarantool Cartridge-Rolle importieren
import_role:
name: tarantool.cartridgeHier passiert nichts Interessantes, wir führen die Ansible-Rolle aus, die heißt tarantool.cartridge.
Alles Wichtige (nämlich die Konfiguration des Clusters) befindet sich in -Datei hosts.yml:
---
all:
vars:
# allgemeine Cluster-Variablen
cartridge_app_name: getting-started-app
cartridge_package_path: .\/getting-started-app-1.0.0-0.rpm # Paketpfad
cartridge_cluster_cookie: app-default-cookie # Cluster-Cookie
# allgemeine SSH-Optionen
ansible_ssh_private_key_file: ~\/vagrant.d\/insecure_private_key
ansible_ssh_common_args: '-o IdentitiesOnly=yes -o UserKnownHostsFile=\/dev\/null -o StrictHostKeyChecking=no'
# INSTANZEN
hosts:
storage-1:
config:
advertise_uri: '172.19.0.2:3301'
http_port: 8181
app-1:
config:
advertise_uri: '172.19.0.3:3301'
http_port: 8182
storage-1-replica:
config:
advertise_uri: '172.19.0.3:3302'
http_port: 8183
children:
# INSTANZEN NACH MASCHINEN GRUPPIEREN
host1:
vars:
# Optionen zur Verbindung der ersten Maschine
ansible_host: 172.19.0.2
ansible_user: vagrant
hosts: # Instanzen, die auf der ersten Maschine gestartet werden
storage-1:
host2:
vars:
# Optionen zur Verbindung der zweiten Maschine
ansible_host: 172.19.0.3
ansible_user: vagrant
hosts: # Instanzen, die auf der zweiten Maschine gestartet werden
app-1:
storage-1-replica:
# INSTANZEN NACH REPLIKA-SÄTZEN GRUPPIEREN
replicaset_app_1:
vars: # Konfiguration des Replika-Satzes
replicaset_alias: app-1
failover_priority:
- app-1 # Anführer
roles:
- 'api'
hosts: # Instanzen des Replika-Satzes
app-1:
replicaset_storage_1:
vars: # Konfiguration des Replika-Satzes
replicaset_alias: storage-1
weight: 3
failover_priority:
- storage-1 # Anführer
- storage-1-replica
roles:
- 'storage'
hosts: # Instanzen des Replika-Satzes
storage-1:
storage-1-replica:Alles, was wir brauchen, ist, zu lernen, wie man Instanzen und Replika-Sätze verwaltet, indem wir den Inhalt dieser Datei ändern. Danach werden wir neue Abschnitte hinzufügen. Um nicht durcheinander zu kommen, wo sie hinzugefügt werden sollen, können Sie einen Blick in die endgültige Version dieser Datei werfen, hosts.updated.yml, die sich im Repository mit dem Beispiel befindet.
Verwaltung der Instanzen
In den Begriffen von Ansible ist jede Instanz ein Host (nicht zu verwechseln mit einem physischen Server), d.h. ein Knoten der Infrastruktur, den Ansible verwalten wird. Für jeden Host können wir Verbindungsparameter angeben (wie zum Beispiel ansible_host und ansible_user), sowie die Konfiguration der Instanz. Die Beschreibung der Instanzen befindet sich im Abschnitt hosts.
Betrachten wir die Konfiguration der Instanz storage-1:
all:
vars:
...
# INSTANZEN
hosts:
storage-1:
config:
advertise_uri: '172.19.0.2:3301'
http_port: 8181
...In der Variablen config haben wir die Parameter der Instanz angegeben — advertise URI und HTTP-Port.
Im Folgenden sind die Parameter der Instanzen aufgeführt app-1 und storage-1-replica.
Wir müssen Ansible die Verbindungsparameter für jede Instanz mitteilen. Es ist sinnvoll, die Instanzen in Gruppen nach virtuellen Maschinen zu gliedern. Dazu sind die Instanzen in Gruppen zusammengefasst host1 und host2, und in jeder Gruppe sind im Abschnitt vars die Werte angegeben ansible_host und ansible_user für eine virtuelle Maschine. Und im Abschnitt hosts — die Hosts (d.h. die Instanzen), die zu dieser Gruppe gehören:
all:
vars:
...
hosts:
...
children:
# INSTANZEN NACH MASCHINEN GRUPPIEREN
host1:
vars:
# Verbindungsoptionen für die erste Maschine
ansible_host: 172.19.0.2
ansible_user: vagrant
hosts: # Instanzen, die auf der ersten Maschine gestartet werden sollen
storage-1:
host2:
vars:
# Verbindungsoptionen für die zweite Maschine
ansible_host: 172.19.0.3
ansible_user: vagrant
hosts: # Instanzen, die auf der zweiten Maschine gestartet werden sollen
app-1:
storage-1-replica:Wir beginnen mit den Änderungen hosts.yml. Wir fügen zwei weitere Instanzen hinzu, storage-2-replica auf der ersten virtuellen Maschine und storage-2 auf der zweiten:
all:
vars:
...
# INSTANZEN
hosts:
...
storage-2: # <==
config:
advertise_uri: '172.19.0.3:3303'
http_port: 8184
storage-2-replica: # <==
config:
advertise_uri: '172.19.0.2:3302'
http_port: 8185
children:
# INSTANZEN NACH MASCHINEN GRUPPIEREN
host1:
vars:
...
hosts: # Instanzen, die auf der ersten Maschine gestartet werden sollen
storage-1:
storage-2-replica: # <==
host2:
vars:
...
hosts: # Instanzen, die auf der zweiten Maschine gestartet werden sollen
app-1:
storage-1-replica:
storage-2: # <==
...Wir starten das Ansible-Playbook:
$ ansible-playbook -i hosts.yml
--limit storage-2,storage-2-replica
playbook.ymlBeachten Sie die Option --limit. Da jede Instanz des Clusters in den Begriffen von Ansible ein Host ist, können wir explizit angeben, welche Instanzen bei der Ausführung des Playbooks konfiguriert werden sollen.
Wir gehen erneut in die Web-Benutzeroberfläche und sehen unsere neuen Instanzen:
Lassen Sie uns nicht auf den lorbeeren ausruhen, sondern das Management der Topologie meistern.
Management der Topologie
Wir fassen unsere neuen Instanzen in einem Replikat-Set zusammen storage-2. Wir fügen eine neue Gruppe hinzu replicaset_storage_2 und beschreiben in ihren Variablen die Parameter des Replikats analog zu replicaset_storage_1. Im Abschnitt hosts Wir geben an, welche Instanzen in diese Gruppe gehören (also unser Replikat-Set):
---
all:
vars:
...
hosts:
...
children:
...
# INSTANZEN NACH REPLIKAT-SETS GRUPPIEREN
...
replicaset_storage_2: # <==
vars: # Replikat-Konfiguration
replicaset_alias: storage-2
weight: 2
failover_priority:
- storage-2
- storage-2-replika
roles:
- 'storage'
hosts: # Replikat-Instanzen
storage-2:
storage-2-replika:Wir starten das Playbook erneut:
$ ansible-playbook -i hosts.yml
--limit replicaset_storage_2
--tags cartridge-replicasets
playbook.ymlIm Parameter --limit haben wir dieses Mal den Namen der Gruppe übergeben, die unserem Replikat-Set entspricht.
Betrachten wir die Option tags.
Unsere Rolle führt schrittweise verschiedene Aufgaben aus, die mit den folgenden Tags gekennzeichnet sind:
cartridge-instances: Verwaltung der Instanzen (Konfiguration, Verbindung zur Mitgliedschaft);cartridge-replicasets: Verwaltung der Topologie (Verwaltung von Replikat-Sets und unwiderrufliches Löschen (expel) von Instanzen aus dem Cluster);cartridge-config: Verwaltung der übrigen Clusterparameter (Vshard-Initialisierung, automatischer Failover-Modus, Authentifizierungsparameter und Anwendungs-Konfiguration).
Wir können ausdrücklich angeben, welchen Teil der Arbeit wir erledigen möchten, dann überspringt die Rolle die Ausführung der anderen Aufgaben. In unserem Fall möchten wir nur mit der Topologie arbeiten, daher haben wir angegeben cartridge-replicasets.
Lasst uns das Ergebnis unserer Bemühungen bewerten. Wir finden das neue Replikat-Set unter .
Hurra!
Experimentieren Sie mit der Änderung der Konfiguration der Instanzen und Replikat-Sets und sehen Sie, wie sich die Topologie des Clusters ändert. Sie können verschiedene Betriebsszenarien ausprobieren, zum Beispiel oder eine Erhöhung von memtx_memory. Die Rolle wird versuchen, dies ohne einen Neustart der Instanz zu tun, um die mögliche Ausfallzeit Ihrer Anwendung zu minimieren.
Vergessen Sie nicht, vagrant halt, um die virtuellen Maschinen zu stoppen, wenn Sie mit ihnen fertig sind.
Was steckt darunter?
Hier erkläre ich genauer, was während unserer Experimente unter der Haube der Ansible-Rolle geschah.
Betrachten wir die Schritte zur Bereitstellung einer Cartridge-Anwendung.
Installation des Pakets und Start der Instanzen
Zuerst muss das Paket auf den Server geliefert und installiert werden. Die Rolle kann jetzt mit RPM- und DEB-Paketen arbeiten.
Dann starten wir die Instanzen. Hier ist alles ganz einfach: jede Instanz ist ein eigener systemd-Dienst. Ich erkläre es am Beispiel:
$ systemctl start myapp@storage-1Dieser Befehl startet die Instanz storage-1 der Anwendung myapp. Die gestartete Instanz wird nach ihrer in /etc/tarantool/conf.d/. Die Instanzprotokolle können mit Hilfe von journald.
Unit-Datei /etc/systemd/system/myapp@.sevice für den systemd-Dienst werden zusammen mit dem Paket bereitgestellt.
Ansible verfügt über integrierte Module zur Installation von Paketen und zur Verwaltung von systemd-Diensten, wir haben hier nichts Neues erfunden.
Konfiguration der Cluster-Topologie
Hier beginnt das wirklich Interessante. Es wäre doch seltsam, sich mit einer speziellen Ansible-Rolle für die Installation von Paketen und das Starten systemd-Dienste.
Den Cluster kann man manuell einrichten:
- Erste Möglichkeit: Wir öffnen das Web-UI und drücken die Tasten. Für einen einmaligen Start mehrerer Instanzen ist das durchaus geeignet.
- Zweite Möglichkeit: Man kann die GraphQl API nutzen. Hier kann man etwas automatisieren, zum Beispiel ein Skript in Python schreiben.
- Dritte Möglichkeit (für die Mutigen): Wir gehen auf den Server, verbinden uns mit einer der Instanzen mithilfe von
tarantoolctl connectund führen alle notwendigen Manipulationen mit dem Lua-Modulcartridge.
Die Hauptaufgabe unserer Erfindung besteht darin, diesen, den schwierigsten Teil der Arbeit, für Sie zu erledigen.
Ansible erlaubt es, ein eigenes Modul zu schreiben und in der Rolle zu verwenden. Unsere Rolle verwendet solche Module zur Verwaltung verschiedener Komponenten des Clusters.
Wie funktioniert das? Sie beschreiben den gewünschten Zustand des Clusters in einem deklarativen Config und die Rolle übergibt jedem Modul seinen Konfigurationsabschnitt als Eingabe. Das Modul erhält den aktuellen Zustand des Clusters und vergleicht ihn mit dem, was eingegangen ist. Dann wird über den Socket einer der Instanzen der Code gestartet, der den Cluster in den gewünschten Zustand versetzt.
Ergebnisse
Heute haben wir erklärt und gezeigt, wie man Ihre Anwendung auf Tarantool Cartridge bereitstellt und eine einfache Topologie einrichtet. Dazu haben wir Ansible verwendet – ein leistungsstarkes Werkzeug, das sich durch Benutzerfreundlichkeit auszeichnet und es ermöglicht, gleichzeitig viele Knoten der Infrastruktur (in unserem Fall die Instanzen des Clusters) zu konfigurieren.
Wir haben uns oben mit einer der vielen Möglichkeiten zur Beschreibung der Cluster-Konfiguration mit Ansible beschäftigt. Sobald Sie bereit sind, weiterzugehen, schauen Sie sich die zum Schreiben von Playbooks an. Es könnte einfacher sein, die Topologie mit Hilfe von group_vars und host_vars.
In Kürze werden wir Ihnen erklären, wie Sie Instanzen dauerhaft aus der Topologie entfernen (expel), vshard bootstrappen, den automatischen Failover-Modus verwalten, die Autorisierung einrichten und die Cluster-Konfiguration patchen können. Bis dahin können Sie eigenständig mit der Änderung der Clusterparameter experimentieren.
Wenn etwas nicht funktioniert, informieren Sie bitte Was tun, wenn die Newsletter bereits im „Spam“ gelandet sind: 5 praktische Schritte
Quelle: habr.com
