Već smo razgovarali o , koji vam omogućuje razvoj distribuiranih aplikacija i njihovo pakiranje. Sve što je preostalo je naučiti kako implementirati ove aplikacije i upravljati njima. Ne brinite, mi ćemo sve pokriti! Sastavili smo sve najbolje prakse za rad s Tarantool kasetom i napisali , koji će distribuirati paket na poslužitelje, pokrenuti instance, ujediniti ih u klaster, konfigurirati autorizaciju, bootstrap vshard, omogućiti automatski failover i zakrpati konfiguraciju klastera.
Zanimljiv? Onda, molim vas, ispod kroja, sve ćemo vam reći i pokazati.
Počnimo s primjerom
Pogledat ćemo samo dio funkcionalnosti naše uloge. Ovdje uvijek možete pronaći potpuni opis svih njegovih mogućnosti i ulaznih parametara . Ali bolje je jednom pokušati nego vidjeti stotinu puta, stoga implementirajmo malu aplikaciju.
Tarantool kaseta ima za izradu male aplikacije Cartridge koja pohranjuje informacije o klijentima banke i njihovim računima, a također pruža API za upravljanje podacima putem HTTP-a. Da bi se to postiglo, u dodatku su opisane dvije moguće uloge: api и storage, koji se mogu dodijeliti instancama.
Sam uložak ne govori ništa o tome kako pokrenuti procese, on samo pruža mogućnost konfiguriranja već pokrenutih instanci. Korisnik mora sam učiniti ostalo: urediti konfiguracijske datoteke, pokrenuti usluge i konfigurirati topologiju. Ali mi nećemo sve ovo učiniti; Ansible će to učiniti umjesto nas.
S riječi na djela
Dakle, implementirajmo našu aplikaciju na dva virtualna računala i postavimo jednostavnu topologiju:
- Skup replika
app-1će implementirati uloguapi, što uključuje uloguvshard-router. Ovdje će biti samo jedan primjer. - Skup replika
storage-1provodi ulogustorage(i u isto vrijemevshard-storage), ovdje ćemo dodati dvije instance s različitih strojeva.
Za pokretanje primjera koji nam je potreban и (verzija 2.8 ili starija).
Sama uloga je in . Ovo je spremište koje vam omogućuje dijeljenje vašeg rada i korištenje gotovih uloga.
Klonirajmo spremište s primjerom:
$ git clone https://github.com/dokshina/deploy-tarantool-cartridge-app.git
$ cd deploy-tarantool-cartridge-app && git checkout 1.0.0Podižemo virtualne strojeve:
$ vagrant upInstalirajte Tarantool Cartridge ansible ulogu:
$ ansible-galaxy install tarantool.cartridge,1.0.1Pokrenite instaliranu ulogu:
$ ansible-playbook -i hosts.yml playbook.ymlČekamo da playbook završi izvršenje, idite na i uživajte u rezultatu:
Možete učitati podatke. Cool, zar ne?
Sada shvatimo kako raditi s ovim, au isto vrijeme dodati još jedan skup replika u topologiju.
Počnimo shvaćati
Dakle, što se dogodilo?
Postavili smo dva virtualna računala i pokrenuli ansible playbook koji je konfigurirao naš klaster. Pogledajmo sadržaj datoteke 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.cartridgeOvdje se ne događa ništa zanimljivo, pokrenimo ansible ulogu tzv tarantool.cartridge.
Sve najvažnije stvari (naime konfiguracija klastera) nalaze se u -datoteka 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:Sve što trebamo je naučiti kako upravljati instancama i skupovima replika mijenjanjem sadržaja ove datoteke. Zatim ćemo mu dodati nove odjeljke. Kako se ne biste zabunili gdje ih dodati, možete pogledati konačnu verziju ove datoteke, hosts.updated.yml, koji se nalazi u repozitoriju primjera.
Upravljanje instancom
U smislu Ansiblea, svaka instanca je host (ne treba ga brkati s hardverskim poslužiteljem), tj. infrastrukturni čvor kojim će upravljati Ansible. Za svaki host možemo odrediti parametre veze (kao što je ansible_host и ansible_user), kao i konfiguracija instance. Opis instanci nalazi se u odjeljku hosts.
Pogledajmo konfiguraciju instance storage-1:
all:
vars:
...
# INSTANCES
hosts:
storage-1:
config:
advertise_uri: '172.19.0.2:3301'
http_port: 8181
...U varijabli config naveli smo parametre instance - advertise URI и HTTP port.
Ispod su parametri instance app-1 и storage-1-replica.
Moramo reći Ansibleu parametre veze za svaku instancu. Čini se logičnim grupirati instance u grupe virtualnih strojeva. U tu svrhu, instance se kombiniraju u grupe host1 и host2, te u svakoj skupini u odjeljku vars vrijednosti su naznačene ansible_host и ansible_user za jedan virtualni stroj. I u odjeljku hosts — hostovi (zvani instance) koji su uključeni u ovu grupu:
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:Počinjemo se mijenjati hosts.yml. Dodajmo još dva slučaja, storage-2-replica na prvom virtualnom stroju i storage-2 Na drugom:
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: # <==
...Pokrenite ansible playbook:
$ ansible-playbook -i hosts.yml
--limit storage-2,storage-2-replica
playbook.ymlObratite pažnju na opciju --limit. Budući da je svaka instanca klastera host u terminima Ansiblea, možemo eksplicitno odrediti koje instance treba konfigurirati prilikom izvođenja priručnika.
Vraćamo se na web sučelje i pogledajte naše nove instance:
Nemojmo tu stati i savladajmo upravljanje topologijom.
Upravljanje topologijom
Kombinirajmo naše nove instance u skup replika storage-2. Dodajmo novu grupu replicaset_storage_2 i opisati parametre skupa replika u njegovim varijablama po analogiji s replicaset_storage_1. U odjeljku hosts Naznačimo koje će instance biti uključene u ovu grupu (tj. naš skup replika):
---
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:Počnimo ponovno s knjigom:
$ ansible-playbook -i hosts.yml
--limit replicaset_storage_2
--tags cartridge-replicasets
playbook.ymlU parametru --limit Ovaj put smo proslijedili ime grupe koja odgovara našem skupu replika.
Razmotrimo opciju tags.
Naša uloga uzastopno obavlja različite zadatke koji su označeni sljedećim oznakama:
cartridge-instances: upravljanje instancom (konfiguracija, povezivanje s članstvom);cartridge-replicasets: upravljanje topologijom (upravljanje replikasetom i trajno uklanjanje (izbacivanje) instanci iz klastera);cartridge-config: upravljanje ostalim parametrima klastera (vshard bootstrapping, automatski failover mod, autorizacijski parametri i konfiguracija aplikacije).
Možemo eksplicitno odrediti koji dio posla želimo obaviti, tada će uloga preskočiti ostale zadatke. U našem slučaju, želimo raditi samo s topologijom, tako smo naveli cartridge-replicasets.
Procijenimo rezultat naših napora. Nalazimo novi set replika na .
Hura!
Eksperimentirajte s promjenom konfiguracije instanci i skupova replika i pogledajte kako se mijenja topologija klastera. Možete isprobati različite operativne scenarije, npr. ili povećati memtx_memory. Uloga će to pokušati učiniti bez ponovnog pokretanja instance kako bi se smanjio mogući prekid rada vaše aplikacije.
Ne zaboravi trčati vagrant haltda biste zaustavili virtualne strojeve kada završite s radom s njima.
Što je ispod haube?
Ovdje ću vam reći više o tome što se događalo ispod haube uloge ansibla tijekom naših eksperimenata.
Pogledajmo implementaciju aplikacije Cartridge korak po korak.
Instalacija paketa i pokretanje instanci
Prvo trebate dostaviti paket na poslužitelj i instalirati ga. Trenutačno uloga može raditi s RPM i DEB paketima.
Zatim pokrećemo instance. Ovdje je sve vrlo jednostavno: svaka je instanca zasebna systemd-servis. Dat ću vam primjer:
$ systemctl start myapp@storage-1Ova naredba će pokrenuti instancu storage-1 aplikacije myapp. Pokrenuta instanca tražit će svoju в /etc/tarantool/conf.d/. Dnevnici instanci mogu se pregledati pomoću journald.
Jedinična datoteka /etc/systemd/system/[email protected] za uslugu systemd bit će isporučena zajedno s paketom.
Ansible ima ugrađene module za instaliranje paketa i upravljanje systemd uslugama; ovdje nismo izmislili ništa novo.
Postavljanje topologije klastera
Ovdje počinje zabava. Slažem se, bilo bi čudno zamarati se posebnom Ansible ulogom za instaliranje paketa i pokretanje systemd-usluge.
Klaster možete konfigurirati ručno:
- Prva opcija: otvorite web sučelje i kliknite gumbe. Prilično je prikladan za jednokratno pokretanje nekoliko instanci.
- Druga opcija: možete koristiti GraphQl API. Ovdje već možete nešto automatizirati, na primjer, napisati skriptu u Pythonu.
- Treća opcija (za one jake volje): idite na poslužitelj, povežite se s jednom od instanci pomoću
tarantoolctl connectte izvršiti sve potrebne manipulacije s Lua modulomcartridge.
Glavni zadatak našeg izuma je da umjesto vas obavimo upravo ovaj, najteži dio posla.
Ansible vam omogućuje pisanje vlastitog modula i korištenje u ulozi. Naša uloga koristi takve module za upravljanje različitim komponentama klastera.
Kako radi? Vi opisujete željeno stanje klastera u deklarativnoj konfiguraciji, a uloga daje svakom modulu njegov odjeljak konfiguracije kao ulaz. Modul prima trenutno stanje klastera i uspoređuje ga s onim što je primljeno kao ulaz. Zatim se kroz socket jedne od instanci pokreće kod koji dovodi klaster u željeno stanje.
Rezultati
Danas smo rekli i pokazali kako implementirati svoju aplikaciju na Tarantool kasetu i postaviti jednostavnu topologiju. Da bismo to učinili, koristili smo Ansible - moćan alat koji je jednostavan za korištenje i omogućuje vam da istovremeno konfigurirate mnogo infrastrukturnih čvorova (u našem slučaju, instance klastera).
Gore smo pogledali jedan od mnogih načina za opisivanje konfiguracije klastera pomoću Ansiblea. Jednom kada osjetite da ste spremni krenuti dalje, istražite na pisanje knjiga igrokaza. Možda će vam biti lakše upravljati topologijom pomoću group_vars и host_vars.
Vrlo brzo ćemo vam reći kako trajno izbrisati (izbaciti) instance iz topologije, pokrenuti vshard, upravljati automatskim načinom rada u slučaju greške, konfigurirati autorizaciju i zakrpati konfiguraciju klastera. U međuvremenu možete učiti sami i eksperimentirajte s promjenom parametara klastera.
Ako nešto ne uspije, svakako nas o problemu. Sve ćemo brzo riješiti!
Izvor: www.habr.com