We hebben er al over gesproken , waarmee u gedistribueerde applicaties kunt ontwikkelen en deze kunt verpakken. Het enige dat u nog hoeft te doen, is leren hoe u deze applicaties kunt implementeren en beheren. Maak je geen zorgen, we hebben het allemaal gedekt! We hebben alle best practices voor het werken met Tarantool Cartridge verzameld en geschreven , waarmee het pakket naar servers wordt gedistribueerd, instances worden gestart, in een cluster worden verenigd, autorisatie wordt geconfigureerd, vshard wordt opgestart, automatische failover wordt ingeschakeld en de clusterconfiguratie wordt gepatcht.
Interessant? Dan alsjeblieft, onder de snee, zullen we je alles vertellen en laten zien.
Laten we beginnen met een voorbeeld
We kijken slechts naar een deel van de functionaliteit van onze rol. Een volledige beschrijving van alle mogelijkheden en invoerparameters vindt u altijd in . Maar het is beter om het één keer te proberen dan het honderd keer te zien, dus laten we een kleine applicatie implementeren.
Tarantool-cartridge heeft om een kleine Cartridge-applicatie te maken die informatie over bankklanten en hun rekeningen opslaat, en ook een API biedt voor gegevensbeheer via HTTP. Om dit te bereiken beschrijft de bijlage twee mogelijke rollen: api и storage, die aan exemplaren kan worden toegewezen.
Cartridge zelf zegt niets over het starten van processen, het biedt alleen de mogelijkheid om reeds actieve exemplaren te configureren. De rest moet de gebruiker zelf doen: configuratiebestanden regelen, services starten en de topologie configureren. Maar wij zullen dit niet allemaal doen; Ansible zal het voor ons doen.
Van woorden naar daden
Laten we onze applicatie dus op twee virtuele machines implementeren en een eenvoudige topologie opzetten:
- Replicaset
app-1zal de rol uitvoerenapi, inclusief de rolvshard-router. Er zal hier slechts één exemplaar zijn. - Replicaset
storage-1voert de rol uitstorage(en op hetzelfde momentvshard-storage), hier zullen we twee exemplaren van verschillende machines toevoegen.
Om het voorbeeld uit te voeren hebben we nodig и (versie 2.8 of ouder).
De rol zelf is binnen . Dit is een repository waarmee u uw werk kunt delen en kant-en-klare rollen kunt gebruiken.
Laten we de repository klonen met een voorbeeld:
$ git clone https://github.com/dokshina/deploy-tarantool-cartridge-app.git
$ cd deploy-tarantool-cartridge-app && git checkout 1.0.0We verhogen virtuele machines:
$ vagrant upInstalleer de Anible-rol van Tarantool Cartridge:
$ ansible-galaxy install tarantool.cartridge,1.0.1Start de geïnstalleerde rol:
$ ansible-playbook -i hosts.yml playbook.ymlWe wachten tot het draaiboek volledig is uitgevoerd, ga naar en geniet van het resultaat:
U kunt gegevens uploaden. Cool toch?
Laten we nu eens kijken hoe we hiermee kunnen werken, en tegelijkertijd nog een replicaset aan de topologie toevoegen.
Laten we het beginnen uit te zoeken
Dus wat gebeurde er?
We hebben twee virtuele machines opgezet en een weerbaar playbook gelanceerd dat ons cluster heeft geconfigureerd. Laten we eens kijken naar de inhoud van het bestand playbook.yml:
---
- name: Deploy my Tarantool Cartridge app
hosts: all
become: true
become_user: root
tasks:
- name: Import Tarantool Cartridge role
import_role:
name: tarantool.cartridgeEr gebeurt hier niets interessants, laten we een weerwortrol lanceren genaamd tarantool.cartridge.
Alle belangrijkste zaken (namelijk de clusterconfiguratie) bevinden zich in -bestand hosts.yml:
---
all:
vars:
# common cluster variables
cartridge_app_name: getting-started-app
cartridge_package_path: ./getting-started-app-1.0.0-0.rpm # path to package
cartridge_cluster_cookie: app-default-cookie # cluster cookie
# common ssh options
ansible_ssh_private_key_file: ~/.vagrant.d/insecure_private_key
ansible_ssh_common_args: '-o IdentitiesOnly=yes -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'
# INSTANCES
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:
# GROUP INSTANCES BY MACHINES
host1:
vars:
# first machine connection options
ansible_host: 172.19.0.2
ansible_user: vagrant
hosts: # instances to be started on the first machine
storage-1:
host2:
vars:
# second machine connection options
ansible_host: 172.19.0.3
ansible_user: vagrant
hosts: # instances to be started on the second machine
app-1:
storage-1-replica:
# GROUP INSTANCES BY REPLICA SETS
replicaset_app_1:
vars: # replica set configuration
replicaset_alias: app-1
failover_priority:
- app-1 # leader
roles:
- 'api'
hosts: # replica set instances
app-1:
replicaset_storage_1:
vars: # replica set configuration
replicaset_alias: storage-1
weight: 3
failover_priority:
- storage-1 # leader
- storage-1-replica
roles:
- 'storage'
hosts: # replica set instances
storage-1:
storage-1-replica:Het enige dat we nodig hebben, is leren hoe we instances en replicasets kunnen beheren door de inhoud van dit bestand te wijzigen. Vervolgens zullen we er nieuwe secties aan toevoegen. Om niet in de war te raken waar u ze moet toevoegen, kunt u de definitieve versie van dit bestand bekijken, hosts.updated.yml, die zich in de voorbeeldrepository bevindt.
Instantiebeheer
In Ansible-termen is elke instance een host (niet te verwarren met een hardwareserver), d.w.z. het infrastructuurknooppunt dat Ansible zal beheren. Voor elke host kunnen we verbindingsparameters opgeven (zoals ansible_host и ansible_user), evenals de exemplaarconfiguratie. Beschrijving van exemplaren vindt u in de sectie hosts.
Laten we eens kijken naar de exemplaarconfiguratie storage-1:
all:
vars:
...
# INSTANCES
hosts:
storage-1:
config:
advertise_uri: '172.19.0.2:3301'
http_port: 8181
...Variabel config we hebben de instantieparameters gespecificeerd - advertise URI и HTTP port.
Hieronder vindt u de exemplaarparameters app-1 и storage-1-replica.
We moeten Ansible de verbindingsparameters voor elke instantie doorgeven. Het lijkt logisch om instances te groeperen in virtuele-machinegroepen. Voor dit doel worden instanties gecombineerd in groepen host1 и host2en in elke groep in de sectie vars waarden zijn aangegeven ansible_host и ansible_user voor één virtuele machine. En in de sectie hosts — hosts (ook wel instances genoemd) die in deze groep zijn opgenomen:
all:
vars:
...
hosts:
...
children:
# GROUP INSTANCES BY MACHINES
host1:
vars:
# first machine connection options
ansible_host: 172.19.0.2
ansible_user: vagrant
hosts: # instances to be started on the first machine
storage-1:
host2:
vars:
# second machine connection options
ansible_host: 172.19.0.3
ansible_user: vagrant
hosts: # instances to be started on the second machine
app-1:
storage-1-replica:Wij beginnen te veranderen hosts.yml. Laten we nog twee exemplaren toevoegen, storage-2-replica op de eerste virtuele machine en storage-2 Op de seconde:
all:
vars:
...
# INSTANCES
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:
# GROUP INSTANCES BY MACHINES
host1:
vars:
...
hosts: # instances to be started on the first machine
storage-1:
storage-2-replica: # <==
host2:
vars:
...
hosts: # instances to be started on the second machine
app-1:
storage-1-replica:
storage-2: # <==
...Start het Ansible-speelboek:
$ ansible-playbook -i hosts.yml
--limit storage-2,storage-2-replica
playbook.ymlLet op de optie --limit. Omdat elke clusterinstantie in Ansible-termen een host is, kunnen we expliciet specificeren welke instanties moeten worden geconfigureerd bij het uitvoeren van het playbook.
Teruggaan naar de webinterface en bekijk onze nieuwe exemplaren:
Laten we het daar niet bij laten en het topologiebeheer onder de knie krijgen.
Topologiebeheer
Laten we onze nieuwe exemplaren combineren in een replicaset storage-2. Laten we een nieuwe groep toevoegen replicaset_storage_2 en beschrijf de replicasetparameters in zijn variabelen naar analogie met replicaset_storage_1. In sectie hosts Laten we aangeven welke instanties in deze groep zullen worden opgenomen (dat wil zeggen, onze replicaset):
---
all:
vars:
...
hosts:
...
children:
...
# GROUP INSTANCES BY REPLICA SETS
...
replicaset_storage_2: # <==
vars: # replicaset configuration
replicaset_alias: storage-2
weight: 2
failover_priority:
- storage-2
- storage-2-replica
roles:
- 'storage'
hosts: # replicaset instances
storage-2:
storage-2-replica:Laten we het draaiboek opnieuw starten:
$ ansible-playbook -i hosts.yml
--limit replicaset_storage_2
--tags cartridge-replicasets
playbook.ymlIn parameter --limit Deze keer hebben we de naam doorgegeven van de groep die overeenkomt met onze replicaset.
Laten we de optie overwegen tags.
Onze rol voert achtereenvolgens verschillende taken uit, die zijn gemarkeerd met de volgende tags:
cartridge-instances: instancebeheer (configuratie, koppeling met lidmaatschap);cartridge-replicasets: topologiebeheer (replicasetbeheer en permanente verwijdering (verwijderen) van instances uit het cluster);cartridge-config: beheer van andere clusterparameters (vshard-bootstrapping, automatische failover-modus, autorisatieparameters en applicatieconfiguratie).
We kunnen expliciet specificeren welk deel van het werk we willen doen, waarna de rol de rest van de taken overslaat. In ons geval willen we alleen met de topologie werken, zo hebben we gespecificeerd cartridge-replicasets.
Laten we het resultaat van onze inspanningen evalueren. We vinden een nieuwe replicaset op .
Hoera!
Experimenteer met het wijzigen van de configuratie van instances en replicasets en kijk hoe de clustertopologie verandert. U kunt verschillende operationele scenario's uitproberen, b.v. of verhogen memtx_memory. De rol zal proberen dit te doen zonder het exemplaar opnieuw te starten om de mogelijke downtime van uw applicatie te verminderen.
Vergeet niet te rennen vagrant haltom de virtuele machines te stoppen als u klaar bent met werken.
Wat zit er onder de motorkap?
Hier zal ik je meer vertellen over wat er tijdens onze experimenten onder de motorkap van de weerwortrol gebeurde.
Laten we de implementatie van de Cartridge-applicatie stap voor stap bekijken.
Het pakket installeren en instances starten
Eerst moet u het pakket op de server afleveren en installeren. Momenteel kan de rol werken met RPM- en DEB-pakketten.
Vervolgens lanceren we de instances. Alles is hier heel eenvoudig: elke instantie is een afzonderlijke systemd-dienst. Ik zal je een voorbeeld geven:
$ systemctl start myapp@storage-1Met deze opdracht wordt de instantie gestart storage-1 приложения myapp. Het gelanceerde exemplaar zoekt naar zijn в /etc/tarantool/conf.d/. Instantielogboeken kunnen worden bekeken met journald.
Eenheidsbestand /etc/systemd/system/[email protected] voor systemd-service wordt samen met het pakket geleverd.
Ansible heeft ingebouwde modules voor het installeren van pakketten en het beheren van systeemdiensten; we hebben hier niets nieuws uitgevonden.
Een clustertopologie opzetten
Dit is waar het plezier begint. Mee eens, het zou vreemd zijn om je bezig te houden met een speciale Ansible-rol voor het installeren en uitvoeren van pakketten systemd-Diensten.
U kunt het cluster handmatig configureren:
- Eerste optie: open de webinterface en klik op de knoppen. Het is heel geschikt voor een eenmalige start van meerdere instanties.
- Tweede optie: u kunt de GraphQl API gebruiken. Hier kun je al iets automatiseren, bijvoorbeeld een script schrijven in Python.
- Derde optie (voor mensen met een sterke wil): ga naar de server, maak verbinding met een van de instanties met behulp van
tarantoolctl connecten voer alle noodzakelijke manipulaties uit met de Lua-modulecartridge.
De hoofdtaak van onze uitvinding is om precies dit te doen, het moeilijkste deel van het werk voor u.
Met Ansible kunt u uw eigen module schrijven en deze in een rol gebruiken. Onze rol maakt gebruik van dergelijke modules om verschillende clustercomponenten te beheren.
Hoe het werkt? Je beschrijft de gewenste status van het cluster in een declaratieve configuratie, en de rol voorziet elke module van zijn configuratiesectie als invoer. De module ontvangt de huidige status van het cluster en vergelijkt deze met wat als invoer is ontvangen. Vervolgens wordt er via de socket van één van de instances een code gelanceerd, die het cluster in de gewenste staat brengt.
Resultaten van
Vandaag hebben we verteld en laten zien hoe u uw applicatie op Tarantool Cartridge kunt implementeren en een eenvoudige topologie kunt opzetten. Om dit te doen hebben we Ansible gebruikt: een krachtige tool die gemakkelijk te gebruiken is en waarmee u tegelijkertijd veel infrastructuurknooppunten (in ons geval clusterinstanties) kunt configureren.
Hierboven hebben we gekeken naar een van de vele manieren om een clusterconfiguratie te beschrijven met Ansible. Als je eenmaal klaar bent om verder te gaan, ga dan op onderzoek uit over het schrijven van draaiboeken. Mogelijk vindt u het eenvoudiger om uw topologie te beheren met behulp van group_vars и host_vars.
Binnenkort zullen we u vertellen hoe u instances permanent uit de topologie kunt verwijderen (verwijderen), vshard kunt bootstrappen, de automatische failover-modus kunt beheren, autorisatie kunt configureren en de clusterconfiguratie kunt patchen. In de tussentijd kun je zelfstandig studeren en experimenteer met het veranderen van clusterparameters.
Als iets niet werkt, zorg er dan voor dat je dat doet ons over het probleem. Wij regelen alles snel!
Bron: www.habr.com