Am vorbit deja despre
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
Cartușul Tarantool are api
и storage
care 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-1
va juca rolulapi
care include rolulvshard-router
. Aici va fi o singură instanță. - replicaset
storage-1
implementează 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
Rolul în sine este
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.0
Creștem mașini virtuale:
$ vagrant up
Instalați rolul ansible al cartuşului Tarantool:
$ ansible-galaxy install tarantool.cartridge,1.0.1
Rulați rolul instalat:
$ ansible-playbook -i hosts.yml playbook.yml
Așteptăm sfârșitul execuției playbook-ului, accesați
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.cartridge
Nu 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 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.yml
Acordaț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
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.yml
Pe 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, 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 halt
pentru 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-1
Această 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/[email protected]
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ță 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
Dacă ceva nu funcționează, fii sigur
Sursa: www.habr.com