Am vorbit deja despre , care vă permite să dezvoltați aplicații distribuite și să le împachetați. Nu a mai rămas nimic: aflați cum să implementați și să gestionați aceste aplicații. Nu vă faceți griji, ne-am gândit la toate! Am reunit toate cele mai bune practici pentru lucrul cu Cartușul Tarantool și am scris , care va descompune pachetul în servere, va porni instanțe, le va combina într-un cluster, va configura autorizarea, va face bootstrap vshard, va activa failover-ul automat și va corecta configurația clusterului.
Interesant? Apoi întreb sub tăietură, vom spune și vom arăta totul.
Să începem cu un exemplu
Vom acoperi doar o parte din funcționalitatea rolului nostru. Puteți găsi întotdeauna o descriere completă a tuturor caracteristicilor și parametrilor de intrare în . Dar este mai bine să încerci o dată decât să vezi de o sută de ori, așa că haideți să implementăm o aplicație mică.
Cartușul Tarantool are pentru a crea o mică aplicație Cartridge care stochează informații despre clienții băncii și conturile acestora și oferă, de asemenea, un API pentru gestionarea datelor prin HTTP. Pentru a face acest lucru, aplicația descrie două roluri posibile: api и storagecare pot fi atribuite instanțelor.
Cartușul în sine nu spune nimic despre cum să pornești procesele, oferă doar posibilitatea de a configura instanțe care rulează deja. Utilizatorul trebuie să facă el însuși restul: să descompună fișierele de configurare, să pornească serviciile și să configureze topologia. Dar nu vom face toate acestea, Ansible le va face pentru noi.
De la cuvinte la fapte
Deci, să implementăm aplicația noastră pe două mașini virtuale și să configuram o topologie simplă:
- Replicaset
app-1va juca rolulapicare include rolulvshard-router. Aici va fi o singură instanță. - replicaset
storage-1implementează rolulstorage(și în același timpvshard-storage), aici adăugăm două instanțe de la mașini diferite.
Pentru a rula exemplul, avem nevoie и (versiunea 2.8 sau o versiune ulterioară).
Rolul în sine este . Acesta este un depozit care vă permite să vă partajați munca și să utilizați roluri gata făcute.
Clonează depozitul cu un exemplu:
$ git clone https://github.com/dokshina/deploy-tarantool-cartridge-app.git
$ cd deploy-tarantool-cartridge-app && git checkout 1.0.0Creștem mașini virtuale:
$ vagrant upInstalați rolul ansible al cartuşului Tarantool:
$ ansible-galaxy install tarantool.cartridge,1.0.1Rulați rolul instalat:
$ ansible-playbook -i hosts.yml playbook.ymlAșteptăm sfârșitul execuției playbook-ului, accesați și bucurați-vă de rezultat:
Puteți turna date. Cool, nu?
Acum să ne dăm seama cum să lucrăm cu aceasta și, în același timp, să adăugăm un alt set de replică la topologie.
Începem să înțelegem
Deci ce s-a întâmplat?
Avem două mașini virtuale în funcțiune și rulează un manual de joc ansible care ne-a configurat clusterul. Să ne uităm la conținutul fișierului 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.cartridgeNu se întâmplă nimic interesant aici, începem rolul ansible, care se numește tarantool.cartridge.
Toate cele mai importante (și anume, configurația clusterului) se află în -fişier 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 ce avem nevoie este să învățăm cum să gestionăm instanțele și seturile de replica prin modificarea conținutului acestui fișier. În continuare, îi vom adăuga noi secțiuni. Pentru a nu fi confuz unde să le adăugați, puteți arunca o privire în versiunea finală a acestui fișier, hosts.updated.yml, care se află în depozitul de exemplu.
Managementul instanțelor
În ceea ce privește Ansible, fiecare instanță este o gazdă (a nu se confunda cu un server de fier), adică. nodul de infrastructură pe care îl va administra Ansible. Pentru fiecare gazdă, putem specifica parametrii de conexiune (cum ar fi ansible_host и ansible_user), precum și configurația instanței. Descrierea cazurilor este în secțiune hosts.
Luați în considerare configurația instanței storage-1:
all:
vars:
...
# INSTANCES
hosts:
storage-1:
config:
advertise_uri: '172.19.0.2:3301'
http_port: 8181
...Într-o variabilă config am specificat parametrii instanței - advertise URI и HTTP port.
Mai jos sunt parametrii instanței app-1 и storage-1-replica.
Trebuie să îi spunem lui Ansible parametrii de conexiune pentru fiecare instanță. Pare logic să grupăm instanțe în grupuri de mașini virtuale. Pentru a face acest lucru, instanțele sunt combinate în grupuri. host1 и host2, și în fiecare grupă din secțiune vars valorile ansible_host и ansible_user pentru o mașină virtuală. Și în secțiune hosts - gazde (sunt instanțe) care sunt incluse în acest 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:Începem să ne schimbăm hosts.yml. Să mai adăugăm două cazuri, storage-2-replica pe prima mașină virtuală și storage-2 Pe al doilea:
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: # <==
...Rulați ansible playbook:
$ ansible-playbook -i hosts.yml
--limit storage-2,storage-2-replica
playbook.ymlAcordați atenție opțiunii --limit. Deoarece fiecare instanță de cluster este o gazdă în termeni Ansible, putem specifica în mod explicit care instanțe ar trebui configurate atunci când rulăm playbook-ul.
Înapoi la interfața de utilizare web și observați noile noastre instanțe:
Nu ne vom odihni pe lauri și vom stăpâni controlul topologiei.
Managementul topologiei
Să îmbinăm noile noastre instanțe într-un set de replică storage-2. Adăugați un grup nou replicaset_storage_2 și descrie în variabilele sale parametrii replicasetului prin analogie cu replicaset_storage_1. In sectiune hosts specificați ce instanțe vor fi incluse în acest grup (adică setul nostru de replică):
---
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:Să începem din nou cartea de joc:
$ ansible-playbook -i hosts.yml
--limit replicaset_storage_2
--tags cartridge-replicasets
playbook.ymlPe opțiune --limit de data aceasta am trecut de numele grupului care corespunde setului nostru de replici.
Luați în considerare opțiunea tags.
Rolul nostru îndeplinește secvenţial diverse sarcini, care sunt marcate cu următoarele etichete:
cartridge-instances: managementul instanțelor (configurare, conectare la apartenență);cartridge-replicasets: managementul topologiei (gestionarea replicasetului și eliminarea permanentă (expulzare) a instanțelor din cluster);cartridge-config: gestionați alți parametri ai clusterului (vshard bootstrapping, modul automat de failover, parametrii de autorizare și configurarea aplicației).
Putem specifica în mod explicit ce parte a muncii dorim să facem, apoi rolul va omite restul sarcinilor. În cazul nostru, dorim să lucrăm doar cu topologia, așa că am specificat cartridge-replicasets.
Să evaluăm rezultatul eforturilor noastre. Găsirea unui nou set de replică .
Ura!
Experimentați cu reconfigurarea instanțelor și replicăseturilor și vedeți cum se modifică topologia clusterului. Puteți încerca diferite scenarii operaționale, de exemplu, sau crește memtx_memory. Rolul va încerca să facă acest lucru fără a reporni instanța pentru a reduce posibilul timp de nefuncționare al aplicației dvs.
Nu uita să alergi vagrant haltpentru a opri VM-urile când ați terminat cu ele.
Ce este sub capotă?
Aici voi vorbi mai multe despre ceea ce s-a întâmplat sub capota rolului ansible în timpul experimentelor noastre.
Să aruncăm o privire la implementarea unei aplicații Cartridge pas cu pas.
Instalarea pachetului și pornirea instanțelor
Mai întâi trebuie să livrați pachetul pe server și să îl instalați. Acum rolul poate funcționa cu pachetele RPM și DEB.
În continuare, lansăm instanțele. Totul este foarte simplu aici: fiecare instanță este separată systemd-serviciu. Eu vorbesc despre un exemplu:
$ systemctl start myapp@storage-1Această comandă va lansa instanța storage-1 aplicaţii myapp. Instanța lansată o va căuta в /etc/tarantool/conf.d/. Jurnalele de instanță pot fi vizualizate folosind journald.
Fișierul unității /etc/systemd/system/myapp@.sevice pentru un serviciu systemd va fi livrat cu pachetul.
Ansible are module încorporate pentru instalarea pachetelor și gestionarea serviciilor systemd, nu am inventat nimic nou aici.
Configurarea topologiei clusterului
Și aici începe cel mai interesant. De acord, ar fi ciudat să te deranjezi cu un rol special ansible pentru instalarea pachetelor și rularea systemd-Servicii.
Puteți configura manual clusterul:
- Prima opțiune: deschideți interfața web și faceți clic pe butoane. Pentru un început unic de mai multe cazuri, este destul de potrivit.
- A doua opțiune: puteți utiliza API-ul GraphQl. Aici puteți deja automatiza ceva, de exemplu, scrieți un script în Python.
- A treia opțiune (pentru cei puternici cu spiritul): mergeți la server, conectați-vă la una dintre instanțe folosind
tarantoolctl connectși efectuați toate manipulările necesare cu modulul Luacartridge.
Sarcina principală a invenției noastre este de a face asta, cea mai dificilă parte a muncii pentru tine.
Ansible vă permite să vă scrieți propriul modul și să-l utilizați într-un rol. Rolul nostru folosește aceste module pentru a gestiona diferitele componente ale clusterului.
Cum functioneaza? Descrieți starea dorită a clusterului într-o configurație declarativă, iar rolul oferă fiecărui modul secțiunea de configurare ca intrare. Modulul primește starea curentă a clusterului și o compară cu intrarea. Apoi, un cod este rulat prin soclul uneia dintre instanțe, ceea ce aduce clusterul în starea dorită.
Rezultatele
Astăzi am spus și am arătat cum să implementați aplicația dvs. pe Tarantool Cartridge și să configurați o topologie simplă. Pentru a face acest lucru, am folosit Ansible, un instrument puternic care este ușor de utilizat și vă permite să configurați simultan mai multe noduri de infrastructură (în cazul nostru, acestea sunt instanțe de cluster).
Mai sus, ne-am ocupat de una dintre numeroasele moduri de a descrie configurația clusterului folosind Ansible. Odată ce știi că ești gata să mergi mai departe, învață pentru scris cărți de joc. S-ar putea să vă fie mai convenabil să gestionați topologia cu group_vars и host_vars.
Foarte curând vă vom spune cum să eliminați definitiv (expulzarea) instanțe din topologie, să faceți bootstrap vshard, să gestionați modul automat de failover, să configurați autorizarea și să corectați configurația clusterului. Între timp, poți studia pe cont propriu și experimentați cu modificarea parametrilor clusterului.
Dacă ceva nu funcționează, fii sigur ne despre problema. O vom descompune repede!
Sursa: www.habr.com
