We hebben al gesproken over , dat het mogelijk maakt om gedistribueerde toepassingen te ontwikkelen en deze in te pakken. Er is nog maar Ć©Ć©n ding te doen: leren hoe deze toepassingen te implementeren en te beheren. Maak je geen zorgen, we hebben alles al geregeld! We hebben alle best practices voor het werken met Tarantool Cartridge verzameld en geschreven , die het pakket op de servers uitrolt, instanties opstart, ze in een cluster samenvoegt, autorisatie instelt, vshard bootstrap en automatische failover inschakelt, en de clusterconfiguratie patcht.
Interesse? Kom dan verder, we vertellen en laten alles zien.
Laten we beginnen met een voorbeeld
We zullen slechts een deel van de functionaliteit van onze rol bekijken. Een volledige beschrijving van al zijn mogelijkheden en ingangsparameters vind je altijd in . Maar beter Ć©Ć©n keer proberen dan honderd keer zien, laten we dus een kleine applicatie implementeren.
Tarantool Cartridge heeft om een kleine Cartridge-applicatie te maken, die informatie over bankklanten en hun rekeningen opslaat, en een API biedt voor het beheren van gegevens via HTTP. Hiervoor worden in de applicatie twee mogelijke rollen beschreven: api en opslag, die aan instanties kunnen worden toegewezen.
De Cartridge zegt niets over hoe processen te starten; hij biedt alleen de mogelijkheid om al geconfigureerde instanties in te stellen. De gebruiker moet de rest zelf doen: configuratiebestanden uitrollen, services starten en de topologie instellen. Maar we gaan ons daar niet mee bezig houden, dat doet Ansible voor ons.
Van woorden naar daden
Laten we dus onze applicatie op twee virtuele machines implementeren en een simpele topologie instellen:
- Replicaset
app-1zal de rol realiserenapi, die de rol omvatvshard-router. Hier zal er maar Ć©Ć©n instantie zijn. - Replicaset
storage-1realiseert de rolopslag(en tegelijkertijdvshard-storage), hier voegen we twee instanties toe van verschillende machines.
Voor het uitvoeren van het voorbeeld hebben we en (versies 2.8 of hoger).
De rol zelf bevindt zich in . Dit is een opslagplaats waar je je ervaringen kunt delen en kant-en-klare rollen kunt gebruiken.
Laten we de repository met het voorbeeld klonen:
$ git clone https://github.com/dokshina/deploy-tarantool-cartridge-app.git
$ cd deploy-tarantool-cartridge-app && git checkout 1.0.0Laten we de virtuele machines opstarten:
$ vagrant upWe installeren de ansible-rol voor Tarantool Cartridge:
$ ansible-galaxy install tarantool.cartridge,1.0.1We voeren de geĆÆnstalleerde rol uit:
$ ansible-playbook -i hosts.yml playbook.ymlWacht op de voltooiing van de playbook-uitvoering en ga naar en genieten van het resultaat:
Gegevens kunnen worden ingevoerd. Cool, toch?
Laten we nu eens kijken hoe we hiermee kunnen werken en tegelijkertijd een andere replicaset aan de topologie kunnen toevoegen.
Laten we beginnen met begrijpen
Dus, wat is er eigenlijk gebeurd?
We hebben twee virtuele machines opgezet en een Ansible-playbook uitgevoerd dat onze cluster heeft geconfigureerd. Laten we eens kijken naar de inhoud van het bestand playbook.yml:
---
- name: Deploy mijn Tarantool Cartridge app
hosts: all
become: true
become_user: root
tasks:
- name: Importeer Tarantool Cartridge rol
import_role:
name: tarantool.cartridgeHier gebeurt niets bijzonders, we starten de Ansible-rol die tarantool.cartridge.
Alles wat belangrijk is (namelijk, de clusterconfiguratie) bevindt zich in -bestand hosts.yml:
---
all:
vars:
# algemene clustervariabelen
cartridge_app_name: getting-started-app
cartridge_package_path: .\/getting-started-app-1.0.0-0.rpm # pad naar pakket
cartridge_cluster_cookie: app-default-cookie # cluster cookie
# algemene ssh-opties
ansible_ssh_private_key_file: ~\/\.vagrant.d\/insecure_private_key
ansible_ssh_common_args: '-o IdentitiesOnly=yes -o UserKnownHostsFile=\/dev\/null -o StrictHostKeyChecking=no'
# INSTANCIEREN
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:
# GROEP INSTANCIEREN OP MACHINES
host1:
vars:
# verbindingsopties eerste machine
ansible_host: 172.19.0.2
ansible_user: vagrant
hosts: # instanties die op de eerste machine moeten worden gestart
storage-1:
host2:
vars:
# verbindingsopties tweede machine
ansible_host: 172.19.0.3
ansible_user: vagrant
hosts: # instanties die op de tweede machine moeten worden gestart
app-1:
storage-1-replica:
# GROEP INSTANCIEREN OP REPLICASETS
replicaset_app_1:
vars: # replicaset configuratie
replicaset_alias: app-1
failover_priority:
- app-1 # leider
roles:
- 'api'
hosts: # replicaset instanties
app-1:
replicaset_storage_1:
vars: # replicaset configuratie
replicaset_alias: storage-1
weight: 3
failover_priority:
- storage-1 # leider
- storage-1-replica
roles:
- 'storage'
hosts: # replicaset instanties
storage-1:
storage-1-replica:Alles wat we hoeven te leren is hoe we instanties en replicsets kunnen beheren door de inhoud van dit bestand te wijzigen. We zullen er binnenkort nieuwe secties aan toevoegen. Om niet in de war te raken waar ze moeten worden toegevoegd, kun je een kijkje nemen in de finale versie van dit bestand, hosts.updated.yml, die zich in de repository met het voorbeeld bevindt.
Beheer van instanties
In termen van Ansible is elke instantie een host (niet te verwarren met een fysieke server), d.w.z. een infrastructuurknoop waar Ansible de controle over heeft. Voor elke host kunnen we verbindingsparameters opgeven (zoals ansible_host en ansible_user), en de configuratie van de instantie. Beschrijving van instanties is te vinden in de sectie hosts.
Laten we de configuratie van de instantie bekijken storage-1:
all:
vars:
...
# INSTANCES
hosts:
storage-1:
config:
advertise_uri: '172.19.0.2:3301'
http_port: 8181
...In de variabele -bestand, deze gegevens naar de server verzendt we hebben de parameters van de instantie opgegeven ā advertise URI en HTTP poort.
Hieronder staan de parameters van de instanties app-1 en storage-1-replica.
We moeten Ansible de verbindingsparameters voor elke instantie doorgeven. Het lijkt logisch om instanties te groeperen op basis van virtuele machines. Daarom zijn de instanties in groepen samengevoegd host1 en host2, en in elke groep in de sectie vars zijn de waarden opgegeven ansible_host en ansible_user voor Ć©Ć©n virtuele machine. En in de sectie hosts ā hosts (dat zijn ook instanties), die tot deze groep behoren:
all:
vars:
...
hosts:
...
children:
# GROEP INSTANTIES OP BASIS VAN MACHINES
host1:
vars:
# verbindingsopties voor de eerste machine
ansible_host: 172.19.0.2
ansible_user: vagrant
hosts: # instanties die op de eerste machine moeten worden gestart
storage-1:
host2:
vars:
# verbindingsopties voor de tweede machine
ansible_host: 172.19.0.3
ansible_user: vagrant
hosts: # instanties die op de tweede machine moeten worden gestart
app-1:
storage-1-replica:We beginnen met het aanpassen hosts.yml. Laten we nog twee instanties toevoegen, storage-2-replica op de eerste virtuele machine en storage-2 op de tweede:
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:
# GROEP INSTANTIES OP BASIS VAN MACHINES
host1:
vars:
...
hosts: # instanties die op de eerste machine moeten worden gestart
storage-1:
storage-2-replica: # <==
host2:
vars:
...
hosts: # instanties die op de tweede machine moeten worden gestart
app-1:
storage-1-replica:
storage-2: # <==
...We starten de ansible-playbook:
$ ansible-playbook -i hosts.yml
--limit storage-2,storage-2-replica
playbook.ymlLet op de optie --limit. Aangezien elke instantie van het cluster een host is in de termen van Ansible, kunnen we expliciet aangeven welke instanties moeten worden geconfigureerd tijdens het uitvoeren van de playbook.
We gaan weer naar de Web UI en zien onze nieuwe instanties:
Laten we niet stoppen bij wat we hebben bereikt en onze beheertopologie verbeteren.
Beheer van de topologie
Laten we onze nieuwe instanties samenvoegen in een replicaset storage-2. Laten we een nieuwe groep toevoegen replicaset_storage_2 en de parameters van de replicaset beschrijven in zijn variabelen, vergelijkbaar met replicaset_storage_1. In de sectie hosts laten we aangeven welke instanties tot deze groep behoren (dat wil zeggen onze replicaset):
---
all:
vars:
...
hosts:
...
children:
...
# GROEP INSTANCIĆS OP REPLICASETTEN
...
replicaset_storage_2: # <=
vars: # replicaset configuratie
replicaset_alias: opslag-2
weight: 2
failover_priority:
- opslag-2
- opslag-2-replica
roles:
- 'opslag'
hosts: # replicaset instanties
opslag-2:
opslag-2-replica:We starten het playbook opnieuw:
$ ansible-playbook -i hosts.yml
--limit replicaset_storage_2
--tags cartridge-replicasets
playbook.ymlIn de parameter --limit hebben we deze keer de groepsnaam doorgegeven die overeenkomt met onze replicaset.
Laten we de optie bekijken tags.
Onze rol voert verschillende taken uit die zijn gemarkeerd met de volgende tags:
cartridge-instances: beheer van instanties (configuratie, verbinding met lidmaatschap);cartridge-replicasets: beheer van de topologie (beheer van replicasetten en onomkeerbaar verwijderen (expel) van instanties uit de cluster);cartridge-config: beheer van overige clusterparameters (vshard bootstrapping, automatische failover modus, autorisatieparameters en applicatieconfiguratie).
We kunnen expliciet aangeven welk deel van het werk we willen doen, dan zal de rol de uitvoering van de overige taken overslaan. In ons geval willen we alleen met de topologie werken, dus hebben we aangegeven cartridge-replicasets.
Laten we het resultaat van onze inspanningen evalueren. We vinden de nieuwe replicaset op .
Hoera!
Experimenteer met het wijzigen van de configuratie van instanties en replicasets en kijk hoe de topologie van de cluster verandert. U kunt verschillende operationele scenario's uitproberen, zoals of het verhogen van memtx_memory. De rol zal proberen dit zonder het herstarten van de instantie te doen, om de mogelijke downtime van uw applicatie te minimaliseren.
Vergeet niet om vagrant halt, uit te voeren om de virtuele machines te stoppen wanneer u klaar bent met ze te werken.
En wat gebeurt er achter de schermen?
Hier zal ik uitgebreid ingaan op wat er achter de schermen van de ansible-rol gebeurde tijdens onze experimenten.
Laten we de stappen van de implementatie van de Cartridge-applicatie bekijken.
Het installeren van het pakket en het starten van instanties
Eerst moet het pakket op de server worden bezorgd en geĆÆnstalleerd. Momenteel kan de rol werken met RPM- en DEB-pakketten.
Vervolgens starten we de instanties. Dit is heel eenvoudig: elke instantie is een aparte systemd-dienst. Ik zal het uitleggen met een voorbeeld:
$ systemctl start myapp@storage-1Deze opdracht start de instantie. storage-1 applicatie myappDe gestart instantie zal zijn in /etc/tarantool/conf.d/. De logboeken van de instantie kunnen worden bekeken met behulp van journald.
De Unit-bestand /etc/systemd/system/myapp@.sevice voor de systemd-dienst wordt samen met het pakket geleverd.
Ansible heeft ingebouwde modules voor het installeren van pakketten en het beheren van systemd-services, hier hebben we niets nieuws uitgevonden.
Configuratie van de cluster-topologie
En hier begint het interessantste gedeelte. U moet toegeven dat het vreemd zou zijn om een speciale Ansible-rol te maken voor het installeren van pakketten en het starten systemd-services.
U kunt de cluster handmatig configureren:
- Eerste optie: open de Web UI en druk op de knoppen. Voor een eenmalige opstart van enkele instanties is dit heel geschikt.
- Tweede optie: u kunt gebruikmaken van de GraphQL API. Hier kunt u iets automatiseren, bijvoorbeeld een script in Python schrijven.
- Derde optie (voor de sterkeren van geest): ga naar de server, maak verbinding met een van de instanties met behulp van
tarantoolctl connecten voer alle benodigde handelingen uit met de Lua-modulecartridge.
De belangrijkste taak van onze uitvinding is om dit, het moeilijkste deel van het werk, voor u te doen.
Ansible stelt u in staat om uw eigen module te schrijven en deze in een rol te gebruiken. Onze rol maakt gebruik van dergelijke modules voor het beheren van verschillende componenten van de cluster.
Hoe werkt dit? U beschrijft de gewenste toestand van de cluster in een declaratief configuratiebestand, en de rol geeft elke module zijn configuratiesectie door. De module krijgt de huidige toestand van de cluster en vergelijkt deze met wat binnenkomt. Vervolgens wordt via de socket van een van de instanties een code gestart die de cluster naar de gewenste toestand brengt.
Conclusies
Vandaag hebben we laten zien hoe u uw applicatie kunt implementeren op Tarantool Cartridge en een eenvoudige topologie kunt configureren. Hiervoor hebben we Ansible gebruikt - een krachtig hulpmiddel dat zich onderscheidt door gebruiksgemak en dat in staat is om tegelijkertijd veel knooppunten in de infrastructuur in te stellen (in ons geval de clusterinstanties).
Hierboven hebben we een van de vele manieren verkend om de configuratie van de cluster met Ansible te beschrijven. Zodra u begrijpt dat u verder kunt, bestudeer dan voor het schrijven van playbooks. Het kan handiger voor u zijn om de topologie te beheren met behulp van group_vars en host_vars.
Heel binnenkort zullen we uitleggen hoe we instanties onomkeerbaar uit de topologie verwijderen (expel), vshard opstarten, de automatische failovermodus beheren, autorisatie instellen en de clusterconfiguratie patchen. Tot die tijd kunt u zelf verder leren. en experimenteren met het aanpassen van de clusterparameters.
Als iets niet werkt, laat het ons dan zeker weten ons het probleem. We lossen het snel op!
Bron: habr.com
