Oleme juba rääkinud , mis võimaldab arendada hajutatud rakendusi ja neid pakendada. Jääb üle vaid õppida, kuidas neid rakendusi juurutada ja neid hallata. Ärge muretsege, meil on see kõik olemas! Panime kokku kõik parimad tavad Tarantool Cartridge'iga töötamiseks ja kirjutasime , mis levitab paketti serveritele, käivitab eksemplare, ühendab need klastriks, konfigureerib autoriseerimise, käivitab vshardi, lubab automaatse tõrkesiirde ja parandab klastri konfiguratsiooni.
Huvitav? Siis palun, lõike all, me räägime teile ja näitame teile kõike.
Alustame näitega
Vaatleme ainult osa oma rolli funktsionaalsusest. Saate alati leida kõigi selle võimaluste ja sisendparameetrite täieliku kirjelduse . Kuid parem on üks kord proovida kui sada korda näha, nii et võtame kasutusele väikese rakenduse.
Tarantooli kassetil on luua väike Kasseti rakendus, mis salvestab infot pangaklientide ja nende kontode kohta ning pakub ka API-d andmete haldamiseks HTTP kaudu. Selle saavutamiseks kirjeldatakse lisas kahte võimalikku rolli: api и storage, mida saab eksemplaridele määrata.
Kassett ise ei ütle midagi protsesside käivitamise kohta, see annab ainult võimaluse konfigureerida juba töötavaid eksemplare. Ülejäänu peab kasutaja ise tegema: korraldama konfiguratsioonifailid, käivitama teenused ja seadistama topoloogia. Kuid me ei tee seda kõike; Ansible teeb seda meie eest.
Sõnadest tegudeni
Niisiis, juurutame oma rakenduse kahele virtuaalsele masinale ja seadistame lihtsa topoloogia:
- Replicaset
app-1hakkab rolli ellu viimaapi, mis sisaldab rollivshard-router. Siin on ainult üks juhtum. - Replicaset
storage-1rakendab rollistorage(ja samal ajalvshard-storage), lisame siia kaks eksemplari erinevatest masinatest.
Vajaliku näite käivitamiseks и (versioon 2.8 või vanem).
Roll ise on sees . See on hoidla, mis võimaldab teil oma tööd jagada ja kasutada valmis rolle.
Kloonime hoidla näitega:
$ git clone https://github.com/dokshina/deploy-tarantool-cartridge-app.git
$ cd deploy-tarantool-cartridge-app && git checkout 1.0.0Me tõstame virtuaalseid masinaid:
$ vagrant upPaigaldage Tarantooli kasseti sobiv roll:
$ ansible-galaxy install tarantool.cartridge,1.0.1Käivitage installitud roll:
$ ansible-playbook -i hosts.yml playbook.ymlOotame, kuni mänguraamat lõpetab täitmise, minge aadressile ja naudi tulemust:
Saate andmeid üles laadida. Lahe, eks?
Nüüd mõtleme välja, kuidas sellega töötada, ja lisame samal ajal topoloogiasse teise koopiakomplekti.
Hakkame seda välja mõtlema
Mis juhtus?
Seadistasime kaks virtuaalset masinat ja käivitasime võimaliku mänguraamatu, mis konfigureeris meie klastri. Vaatame faili sisu 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.cartridgeMidagi huvitavat siin ei juhtu, käivitame asjaliku rolli nimega tarantool.cartridge.
Kõik kõige olulisemad asjad (nimelt klastri konfiguratsioon) asuvad - fail 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:Kõik, mida me vajame, on õppida selle faili sisu muutes eksemplare ja replikaate haldama. Järgmisena lisame sellele uued jaotised. Et mitte sattuda segadusse, kuhu need lisada, võite vaadata selle faili lõplikku versiooni, hosts.updated.yml, mis on näidishoidlas.
Eksemplari juhtimine
Ansible terminites on iga eksemplar host (mitte segi ajada riistvaraserveriga), st. infrastruktuuri sõlm, mida Ansible haldab. Iga hosti jaoks saame määrata ühenduse parameetrid (nt ansible_host и ansible_user), samuti eksemplari konfiguratsiooni. Juhtumite kirjeldus on jaotises hosts.
Vaatame eksemplari konfiguratsiooni storage-1:
all:
vars:
...
# INSTANCES
hosts:
storage-1:
config:
advertise_uri: '172.19.0.2:3301'
http_port: 8181
...Muutuvas config määrasime eksemplari parameetrid - advertise URI и HTTP port.
Allpool on eksemplari parameetrid app-1 и storage-1-replica.
Peame Ansible'ile ütlema iga eksemplari ühenduse parameetrid. Tundub loogiline rühmitada eksemplarid virtuaalse masina rühmadesse. Sel eesmärgil ühendatakse eksemplarid rühmadesse host1 и host2ja jaotise igas rühmas vars väärtused on näidatud ansible_host и ansible_user ühe virtuaalmasina jaoks. Ja sektsioonis hosts — sellesse rühma kuuluvad hostid (teise nimega eksemplarid):
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:Me hakkame muutuma hosts.yml. Lisame veel kaks juhtumit, storage-2-replica esimeses virtuaalmasinas ja storage-2 Teisel:
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: # <==
...Käivitage võimalik mänguraamat:
$ ansible-playbook -i hosts.yml
--limit storage-2,storage-2-replica
playbook.ymlPange tähele valikut --limit. Kuna iga klastri eksemplar on Ansible terminites host, saame selgesõnaliselt määrata, millised eksemplarid tuleks esitusraamatu käivitamisel konfigureerida.
Tagasi veebi kasutajaliidese juurde ja vaadake meie uusi juhtumeid:
Ärgem lõpetagem sellega ja omandame topoloogiahalduse.
Topoloogia haldamine
Kombineerime oma uued eksemplarid koopiakomplektiks storage-2. Lisame uue grupi replicaset_storage_2 ja kirjeldage selle muutujate replikaseti parameetreid analoogselt replicaset_storage_1. Jaotises hosts Näidame, millised eksemplarid sellesse rühma kaasatakse (st meie koopiakomplekti):
---
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:Alustame mänguraamatuga uuesti:
$ ansible-playbook -i hosts.yml
--limit replicaset_storage_2
--tags cartridge-replicasets
playbook.ymlParameetris --limit Seekord edastasime selle rühma nime, mis vastab meie replikaadile.
Kaalume varianti tags.
Meie roll täidab järjestikku erinevaid ülesandeid, mis on tähistatud järgmiste siltidega:
cartridge-instances: eksemplaride haldamine (konfigureerimine, liikmelisusega ühendamine);cartridge-replicasets: topoloogiahaldus (replikaatide haldamine ja eksemplaride lõplik eemaldamine (väljasaatmine) klastrist);cartridge-config: muude klastri parameetrite haldamine (vshardi alglaadimine, automaatne tõrkevahetusrežiim, autoriseerimisparameetrid ja rakenduse konfiguratsioon).
Saame selgesõnaliselt määrata, millist osa tööst tahame teha, siis jätab roll ülejäänud ülesanded vahele. Meie puhul tahame töötada ainult topoloogiaga, seega täpsustasime cartridge-replicasets.
Hindame oma pingutuste tulemust. Leiame uue replikaadi .
Hurraa!
Katsetage eksemplaride ja koopiakomplektide konfiguratsiooni muutmist ning vaadake, kuidas klastri topoloogia muutub. Proovida saab erinevaid tööstsenaariume, nt. või suurendada memtx_memory. Roll proovib seda teha eksemplari taaskäivitamata, et vähendada teie rakenduse võimalikku seisakuaega.
Ärge unustage joosta vagrant haltvirtuaalmasinate peatamiseks, kui olete nendega töötamise lõpetanud.
Mis on kapoti all?
Siin räägin teile lähemalt, mis meie katsete ajal ansible rolli kapoti all toimus.
Vaatame kassetirakenduse juurutamist samm-sammult.
Paketi installimine ja eksemplaride käivitamine
Kõigepealt peate paketi serverisse toimetama ja installima. Praegu saab roll töötada RPM- ja DEB-pakettidega.
Järgmisena käivitame eksemplarid. Siin on kõik väga lihtne: iga eksemplar on eraldi systemd-teenus. Toon teile näite:
$ systemctl start myapp@storage-1See käsk käivitab eksemplari storage-1 rakendused myapp. Käivitatud eksemplar otsib selle üles в /etc/tarantool/conf.d/. Eksemplaride logisid saab vaadata kasutades journald.
Ühikufail /etc/systemd/system/[email protected] süsteemne teenus tarnitakse koos pakiga.
Ansiblel on sisseehitatud moodulid pakettide installimiseks ja süsteemsete teenuste haldamiseks; me pole siin midagi uut leiutanud.
Klastri topoloogia seadistamine
Siit saab alguse lõbus. Nõus, imelik oleks jännata spetsiaalse Ansible rolliga pakettide installimisel ja käivitamisel systemd-teenused.
Saate klastri käsitsi konfigureerida:
- Esimene võimalus: avage veebi kasutajaliides ja klõpsake nuppudel. See on üsna sobiv mitme juhtumi ühekordseks alustamiseks.
- Teine võimalus: saate kasutada GraphQl API-t. Siin saab juba midagi automatiseerida, näiteks Pythonis skripti kirjutada.
- Kolmas võimalus (tahtejõuliste jaoks): minge serverisse, looge ühendus ühe kasutatava eksemplariga
tarantoolctl connectja tehke kõik vajalikud manipulatsioonid Lua mooduligacartridge.
Meie leiutise põhiülesanne on teha just see, töö kõige raskem osa teie jaoks.
Ansible võimaldab teil kirjutada oma mooduli ja kasutada seda rollis. Meie roll kasutab selliseid mooduleid erinevate klastri komponentide haldamiseks.
Kuidas see töötab? Kirjeldate klastri soovitud olekut deklaratiivses konfiguratsioonis ja roll annab igale moodulile oma konfiguratsiooniosa sisendiks. Moodul võtab vastu klastri hetkeseisu ja võrdleb seda sisendina saaduga. Järgmisena käivitatakse ühe eksemplari pesa kaudu kood, mis viib klastri soovitud olekusse.
Tulemused
Täna rääkisime ja näitasime, kuidas rakendust Tarantool Cartridge'is juurutada ja lihtsat topoloogiat seadistada. Selleks kasutasime Ansible - võimsat tööriista, mida on lihtne kasutada ja mis võimaldab korraga konfigureerida paljusid infrastruktuuri sõlmpunkte (meie puhul klastri eksemplare).
Eespool vaatlesime ühte paljudest viisidest klastri konfiguratsiooni kirjeldamiseks Ansible abil. Kui tunnete, et olete valmis edasi liikuma, uurige mänguraamatute kirjutamise kohta. Teil võib olla lihtsam oma topoloogiat hallata kasutades group_vars и host_vars.
Peagi räägime teile, kuidas topoloogiast eksemplare jäädavalt kustutada (väljutada), bootstrap vshard, hallata automaatset tõrkevahetusrežiimi, konfigureerida autoriseerimist ja parandada klastri konfiguratsiooni. Vahepeal saab õppida iseseisvalt ja katsetage klastri parameetrite muutmist.
Kui midagi ei tööta, tehke seda kindlasti meile probleemist. Teeme kõik kiiresti korda!
Allikas: www.habr.com