Ja n'hem parlat , que permet desenvolupar aplicacions distribuïdes i empaquetar-les. Tot el que queda és aprendre a implementar aquestes aplicacions i gestionar-les. No et preocupis, ho tenim tot cobert! Vam reunir totes les millors pràctiques per treballar amb Tarantool Cartridge i vam escriure , que distribuirà el paquet als servidors, llançarà instàncies, les unirà en un clúster, configurarà l'autorització, arrencarà vshard, activarà la migració automàtica per error i aplicarà pedaços a la configuració del clúster.
Interessant? Aleshores, si us plau, sota el tall, us ho explicarem i us ho mostrarem tot.
Comencem amb un exemple
Només mirarem una part de la funcionalitat del nostre rol. Sempre podeu trobar una descripció completa de totes les seves capacitats i paràmetres d'entrada . Però és millor provar-ho una vegada que veure-ho cent vegades, així que despleguem una petita aplicació.
El cartutx Tarantool té per crear una petita aplicació Cartridge que emmagatzema informació sobre els clients bancaris i els seus comptes, i també proporciona una API per a la gestió de dades mitjançant HTTP. Per aconseguir-ho, l'annex descriu dos possibles rols: api и storage, que es pot assignar a instàncies.
El propi cartutx no diu res sobre com iniciar processos, només ofereix la possibilitat de configurar instàncies que ja estan en execució. La resta l'ha de fer ell mateix l'usuari: organitzar els fitxers de configuració, iniciar els serveis i configurar la topologia. Però no farem tot això; Ansible ho farà per nosaltres.
De les paraules als fets
Per tant, despleguem la nostra aplicació a dues màquines virtuals i configurem una topologia senzilla:
- Conjunt de rèpliques
app-1posarà en pràctica el paperapi, que inclou el papervshard-router. Aquí només hi haurà una instància. - Conjunt de rèpliques
storage-1implementa el paperstorage(i al mateix tempsvshard-storage), aquí afegirem dues instàncies de màquines diferents.
Per executar l'exemple que necessitem и (versió 2.8 o anterior).
El paper en si és en . Aquest és un repositori que us permet compartir el vostre treball i utilitzar rols ja fets.
Clonem el repositori amb un exemple:
$ git clone https://github.com/dokshina/deploy-tarantool-cartridge-app.git
$ cd deploy-tarantool-cartridge-app && git checkout 1.0.0Creem màquines virtuals:
$ vagrant upInstal·leu el paper ansible del cartutx Tarantool:
$ ansible-galaxy install tarantool.cartridge,1.0.1Inicieu la funció instal·lada:
$ ansible-playbook -i hosts.yml playbook.ymlEsperem que el llibre de jugades finalitzi l'execució, aneu a i gaudeix del resultat:
Podeu carregar dades. Genial, oi?
Ara esbrinem com treballar amb això i, al mateix temps, afegim un altre conjunt de rèpliques a la topologia.
Comencem a esbrinar-ho
Llavors què va passar?
Vam configurar dues màquines virtuals i vam llançar un llibre de jocs ansible que va configurar el nostre clúster. Vegem el contingut del fitxer 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.cartridgeAquí no passa res interessant, anem a llançar un paper ansible anomenat tarantool.cartridge.
Totes les coses més importants (és a dir, la configuració del clúster) es troben -dossier 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:Tot el que necessitem és aprendre a gestionar les instàncies i els conjunts de rèpliques canviant el contingut d'aquest fitxer. A continuació, afegirem noves seccions. Per no confondre's on afegir-los, pots mirar la versió final d'aquest fitxer, hosts.updated.yml, que es troba al repositori d'exemple.
Gestió d'instàncies
En termes d'Ansible, cada instància és un amfitrió (no s'ha de confondre amb un servidor de maquinari), és a dir. el node d'infraestructura que gestionarà Ansible. Per a cada host podem especificar paràmetres de connexió (com ara ansible_host и ansible_user), així com la configuració de la instància. La descripció dels casos es troba a la secció hosts.
Vegem la configuració de la instància storage-1:
all:
vars:
...
# INSTANCES
hosts:
storage-1:
config:
advertise_uri: '172.19.0.2:3301'
http_port: 8181
...En una variable config hem especificat els paràmetres de la instància - advertise URI и HTTP port.
A continuació es mostren els paràmetres de la instància app-1 и storage-1-replica.
Hem d'indicar a Ansible els paràmetres de connexió de cada instància. Sembla lògic agrupar les instàncies en grups de màquines virtuals. Amb aquesta finalitat, les instàncies es combinen en grups host1 и host2, i en cada grup de l'apartat vars s'indiquen els valors ansible_host и ansible_user per a una màquina virtual. I a la secció hosts — amfitrions (també coneguts com instàncies) que s'inclouen en aquest grup:
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:Comencem a canviar hosts.yml. Afegim dos casos més, storage-2-replica a la primera màquina virtual i storage-2 A la segona:
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: # <==
...Inicieu el llibre de jugades ansible:
$ ansible-playbook -i hosts.yml
--limit storage-2,storage-2-replica
playbook.ymlTingueu en compte l'opció --limit. Com que cada instància del clúster és un amfitrió en termes d'Ansible, podem especificar explícitament quines instàncies s'han de configurar quan s'executa el llibre de jocs.
Tornant a la interfície d'usuari web i veure les nostres noves instàncies:
No ens aturem aquí i dominem la gestió de la topologia.
Gestió de topologia
Combinem les nostres noves instàncies en un conjunt de rèpliques storage-2. Afegim un grup nou replicaset_storage_2 i descriure els paràmetres replicaset en les seves variables per analogia amb replicaset_storage_1. En secció hosts Indiquem quines instàncies s'inclouran en aquest grup (és a dir, el nostre conjunt de rèpliques):
---
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:Comencem de nou el llibre de jugades:
$ ansible-playbook -i hosts.yml
--limit replicaset_storage_2
--tags cartridge-replicasets
playbook.ymlEn paràmetre --limit Aquesta vegada hem passat el nom del grup que correspon al nostre replicaset.
Considerem l'opció tags.
La nostra funció realitza seqüencialment diverses tasques, que estan marcades amb les etiquetes següents:
cartridge-instances: gestió d'instàncies (configuració, connexió a membres);cartridge-replicasets: gestió de topologia (gestió de rèplicaset i eliminació permanent (expulsió) d'instàncies del clúster);cartridge-config: gestió d'altres paràmetres del clúster (arrencada vshard, mode de failover automàtic, paràmetres d'autorització i configuració de l'aplicació).
Podem especificar de manera explícita quina part de la feina volem fer, aleshores el rol s'ometrà la resta de tasques. En el nostre cas, volem treballar només amb la topologia, així que hem especificat cartridge-replicasets.
Avaluem el resultat dels nostres esforços. Trobem un nou joc de rèpliques .
Hooray!
Experimenteu amb el canvi de la configuració de les instàncies i els conjunts de rèpliques i comproveu com canvia la topologia del clúster. Podeu provar diferents escenaris operatius, p. o augmentar memtx_memory. El rol intentarà fer-ho sense reiniciar la instància per tal de reduir el possible temps d'inactivitat de la vostra aplicació.
No t'oblidis de córrer vagrant haltper aturar les màquines virtuals quan acabeu de treballar-hi.
Què hi ha sota el capó?
Aquí us explicaré més sobre el que estava passant sota el capó del paper ansible durant els nostres experiments.
Vegem el desplegament de l'aplicació Cartridge pas a pas.
Instal·lació del paquet i inici de les instàncies
Primer heu de lliurar el paquet al servidor i instal·lar-lo. Actualment el rol pot funcionar amb paquets RPM i DEB.
A continuació iniciem les instàncies. Aquí tot és molt senzill: cada instància és separada systemd-servei. Et posaré un exemple:
$ systemctl start myapp@storage-1Aquesta ordre iniciarà la instància storage-1 aplicacions myapp. La instància llançada en buscarà в /etc/tarantool/conf.d/. Els registres d'instàncies es poden veure mitjançant journald.
Fitxa unitat /etc/systemd/system/[email protected] per al servei de systemd es lliurarà juntament amb el paquet.
Ansible té mòduls integrats per instal·lar paquets i gestionar serveis de sistema; no hem inventat res de nou aquí.
Configuració d'una topologia de clúster
Aquí és on comença la diversió. D'acord, seria estrany molestar-se amb un rol especial d'Ansible per instal·lar paquets i executar-los systemd-serveis.
Podeu configurar el clúster manualment:
- Primera opció: obriu la interfície d'usuari web i feu clic als botons. És molt adequat per a un inici únic de diverses instàncies.
- Segona opció: podeu utilitzar l'API GraphQl. Aquí ja podeu automatitzar alguna cosa, per exemple, escriure un script en Python.
- Tercera opció (per a persones de voluntat forta): aneu al servidor, connecteu-vos a una de les instàncies utilitzant
tarantoolctl connecti realitzar totes les manipulacions necessàries amb el mòdul Luacartridge.
La tasca principal del nostre invent és fer exactament això, la part més difícil del treball per a vostè.
Ansible us permet escriure el vostre propi mòdul i utilitzar-lo en un paper. La nostra funció utilitza aquests mòduls per gestionar diversos components del clúster.
Com funciona? Descriu l'estat desitjat del clúster en una configuració declarativa i el rol proporciona a cada mòdul la seva secció de configuració com a entrada. El mòdul rep l'estat actual del clúster i el compara amb el que s'ha rebut com a entrada. A continuació, es llança un codi a través del sòcol d'una de les instàncies, que porta el clúster a l'estat desitjat.
Resultats de
Avui hem explicat i mostrat com implementar la vostra aplicació a Tarantool Cartridge i configurar una topologia senzilla. Per fer-ho, hem utilitzat Ansible, una eina potent que és fàcil d'utilitzar i que us permet configurar simultàniament molts nodes d'infraestructura (en el nostre cas, instàncies de clúster).
Més amunt vam veure una de les moltes maneres de descriure una configuració de clúster mitjançant Ansible. Quan us sentiu preparat per seguir endavant, explora en escriure llibres de jugades. Pot ser que us resulti més fàcil gestionar la vostra topologia amb group_vars и host_vars.
Molt aviat us explicarem com suprimir (expulsar) permanentment les instàncies de la topologia, arrencar vshard, gestionar el mode de failover automàtic, configurar l'autorització i aplicar pedaços a la configuració del clúster. Mentrestant, pots estudiar pel teu compte i experimentar amb el canvi de paràmetres del clúster.
Si alguna cosa no funciona, assegureu-vos de fer-ho ens sobre el problema. Ho arreglarem tot ràpidament!
Font: www.habr.com