Pri ni jam parolis , kiu permesas vin evoluigi distribuitajn aplikaĵojn kaj paki ilin. Restas nur lerni kiel disfaldi ĉi tiujn aplikojn kaj administri ilin. Ne maltrankviliĝu, ni ĉion kovris! Ni kunigas ĉiujn plej bonajn praktikojn por labori kun Tarantool Cartridge kaj skribis , kiu distribuos la pakaĵon al serviloj, lanĉos petskribojn, kunigos ilin en areton, agordos rajtigon, ekfunkciigos vshardon, ebligos aŭtomatan malsukceson kaj flikigos la agordon de la grapolo.
Interesaj? Tiam bonvolu, sub la tranĉo, ni rakontos al vi kaj montros al vi ĉion.
Ni komencu per ekzemplo
Ni nur rigardos parton de la funkcieco de nia rolo. Vi ĉiam povas trovi kompletan priskribon de ĉiuj ĝiaj kapabloj kaj enigo-parametroj en . Sed estas pli bone provi unufoje ol vidi ĝin cent fojojn, do ni deplojigu malgrandan aplikaĵon.
Tarantool Kartoĉo havas krei malgrandan Cartridge-aplikaĵon kiu stokas informojn pri bankklientoj kaj iliaj kontoj, kaj ankaŭ disponigas API por datumadministrado per HTTP. Por atingi tion, la apendico priskribas du eblajn rolojn: api и storage, kiu povas esti asignita al okazoj.
Kartoĉo mem diras nenion pri kiel lanĉi procezojn, ĝi nur provizas la kapablon agordi jam kurantajn petskribojn. La uzanto devas mem fari la reston: aranĝi agordajn dosierojn, lanĉi servojn kaj agordi la topologion. Sed ni ne faros ĉion ĉi; Ansible faros ĝin por ni.
De vortoj ĝis faroj
Do, ni deplojigu nian aplikaĵon al du virtualaj maŝinoj kaj starigu simplan topologion:
- Replicaset
app-1efektivigos la rolonapi, kiu inkluzivas la rolonvshard-router. Ĉi tie estos nur unu kazo. - Replicaset
storage-1efektivigas la rolonstorage(kaj samtempevshard-storage), ĉi tie ni aldonos du okazojn de malsamaj maŝinoj.
Por ekzekuti la ekzemplon ni bezonas и (versio 2.8 aŭ pli malnova).
La rolo mem estas en . Ĉi tio estas deponejo, kiu permesas vin dividi vian laboron kaj uzi pretajn rolojn.
Ni klonu la deponejon kun ekzemplo:
$ git clone https://github.com/dokshina/deploy-tarantool-cartridge-app.git
$ cd deploy-tarantool-cartridge-app && git checkout 1.0.0Ni levas virtualajn maŝinojn:
$ vagrant upInstalu la Tarantool Cartridge ansible rolon:
$ ansible-galaxy install tarantool.cartridge,1.0.1Lanĉu la instalitan rolon:
$ ansible-playbook -i hosts.yml playbook.ymlNi atendas ke la ludlibro kompletigos la ekzekuton, iru al kaj ĝuu la rezulton:
Vi povas alŝuti datumojn. Bonege, ĉu ne?
Nun ni eltrovu kiel labori kun ĉi tio, kaj samtempe aldonu alian kopian aron al la topologio.
Ni komencu eltrovi ĝin
Kio do okazis?
Ni starigis du virtualajn maŝinojn kaj lanĉis ansible-ludlibron, kiu agordis nian areton. Ni rigardu la enhavon de la dosiero 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.cartridgeNenio interesa okazas ĉi tie, ni lanĉu ansible rolo nomata tarantool.cartridge.
Ĉiuj plej gravaj aferoj (nome, la agordo de grapo) troviĝas en -dosiero 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:Ĉio, kion ni bezonas, estas lerni kiel administri okazojn kaj kopiarojn ŝanĝante la enhavon de ĉi tiu dosiero. Poste ni aldonos novajn sekciojn al ĝi. Por ne konfuziĝi kie aldoni ilin, vi povas rigardi la finan version de ĉi tiu dosiero, hosts.updated.yml, kiu estas en la ekzempla deponejo.
Administrado de petskriboj
En Ansible-esprimoj, ĉiu kazo estas gastiganto (malsama al hardvarservilo), t.e. la infrastruktura nodo, kiun Ansible administros. Por ĉiu gastiganto ni povas specifi konektajn parametrojn (kiel ekzemple ansible_host и ansible_user), same kiel la instanca agordo. Priskribo de kazoj estas en la sekcio hosts.
Ni rigardu la instancon agordon storage-1:
all:
vars:
...
# INSTANCES
hosts:
storage-1:
config:
advertise_uri: '172.19.0.2:3301'
http_port: 8181
...En variablo config ni specifis la ekzemplajn parametrojn - advertise URI и HTTP port.
Malsupre estas la instancparametroj app-1 и storage-1-replica.
Ni devas diri al Ansible la konektajn parametrojn por ĉiu okazo. Ŝajnas logike grupigi okazojn en virtualajn maŝinajn grupojn. Por ĉi tiu celo, kazoj estas kombinitaj en grupojn host1 и host2, kaj en ĉiu grupo en la sekcio vars valoroj estas indikitaj ansible_host и ansible_user por unu virtuala maŝino. Kaj en la sekcio hosts - gastigantoj (alinome okazoj) kiuj estas inkluzivitaj en ĉi tiu grupo:
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:Ni komencas ŝanĝiĝi hosts.yml. Ni aldonu du pliajn okazojn, storage-2-replica sur la unua virtuala maŝino kaj storage-2 Sur la dua:
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: # <==
...Lanĉu la ansible ludlibron:
$ ansible-playbook -i hosts.yml
--limit storage-2,storage-2-replica
playbook.ymlBonvolu noti la opcion --limit. Ĉar ĉiu cluster-instanco estas gastiganto laŭ Ansible-kondiĉoj, ni povas eksplicite specifi, kiuj petskriboj devas esti agorditaj dum plenumado de la ludlibro.
Revenante al la Reta UI kaj vidu niajn novajn okazojn:
Ni ne haltu tie kaj majstru topologian administradon.
Topologia administrado
Ni kombinu niajn novajn okazojn en kopian aron storage-2. Ni aldonu novan grupon replicaset_storage_2 kaj priskribi la replicaset parametroj en ĝiaj variabloj per analogeco kun replicaset_storage_1. En sekcio hosts Ni indiku, kiuj okazoj estos inkluzivitaj en ĉi tiu grupo (tio estas, nia kopiaro):
---
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:Ni rekomencu la ludlibron:
$ ansible-playbook -i hosts.yml
--limit replicaset_storage_2
--tags cartridge-replicasets
playbook.ymlEn parametro --limit Ĉi-foje ni pasis la nomon de la grupo, kiu respondas al nia replicaset.
Ni konsideru la opcion tags.
Nia rolo sinsekve plenumas diversajn taskojn, kiuj estas markitaj per la sekvaj etikedoj:
cartridge-instances: administrado de instancoj (agordo, konekto al membreco);cartridge-replicasets: administrado de topologio (administrado de reproduktado kaj permanenta forigo (forigo) de petskriboj de la areto);cartridge-config: administrado de aliaj cluster-parametroj (vshard bootstrapping, aŭtomata malsukcesa reĝimo, rajtigaj parametroj kaj aplikaĵa agordo).
Ni povas eksplicite specifi kiun parton de la laboro ni volas fari, tiam la rolo preterlasos la ceterajn taskojn. En nia kazo, ni volas labori nur kun la topologio, do ni specifis cartridge-replicasets.
Ni taksu la rezulton de niaj klopodoj. Ni trovas novan reproduktan aron .
Hooray!
Eksperimentu kun ŝanĝado de la agordo de petskriboj kaj kopiaroj kaj vidu kiel la cluster-topologio ŝanĝiĝas. Vi povas provi malsamajn funkciajn scenarojn, ekz. aŭ pligrandigi memtx_memory. La rolo provos fari tion sen rekomenci la petskribon por redukti la eblan malfunkcion de via aplikaĵo.
Ne forgesu kuri vagrant halthaltigi la virtualajn maŝinojn kiam vi finos labori kun ili.
Kio estas sub la kapuĉo?
Ĉi tie mi rakontos al vi pli pri tio, kio okazis sub la kapuĉo de la ansible rolo dum niaj eksperimentoj.
Ni rigardu deploji la aplikaĵon de Kartoĉo paŝon post paŝo.
Instalante la pakaĵon kaj komencante petskribojn
Unue vi devas liveri la pakaĵon al la servilo kaj instali ĝin. Nuntempe la rolo povas funkcii kun RPM kaj DEB-pakaĵoj.
Poste ni lanĉas la petskribojn. Ĉio estas tre simpla ĉi tie: ĉiu kazo estas aparta systemd-servo. Mi donos al vi ekzemplon:
$ systemctl start myapp@storage-1Ĉi tiu komando lanĉos la petskribon storage-1 apps myapp. La lanĉita petskribo serĉos ĝian в /etc/tarantool/conf.d/. Kazaj protokoloj povas esti viditaj uzante journald.
Unua dosiero /etc/systemd/system/[email protected] por systemd servo estos liverita kune kun la pako.
Ansible havas enkonstruitajn modulojn por instali pakaĵojn kaj administri sistemajn servojn; ni ne inventis ion novan ĉi tie.
Starigante grapoltopologion
Ĉi tie komenciĝas la amuzo. Konsentu, estus strange ĝeni kun speciala Ansible-rolo por instali pakojn kaj funkcii systemd-servoj.
Vi povas agordi la areton permane:
- Unua opcio: malfermu la Retan UI kaj alklaku la butonojn. Ĝi estas sufiĉe taŭga por unufoja komenco de pluraj okazoj.
- Dua opcio: vi povas uzi la GraphQl API. Ĉi tie vi jam povas aŭtomatigi ion, ekzemple, skribi skripton en Python.
- Tria opcio (por fortvolaj): iru al la servilo, konektu al unu el la uzantaj petskriboj
tarantoolctl connectkaj plenumi ĉiujn necesajn manipuladojn per la Lua-modulocartridge.
La ĉefa tasko de nia invento estas fari ĝuste ĉi tion, la plej malfacilan parton de la laboro por vi.
Ansible permesas skribi vian propran modulon kaj uzi ĝin en rolo. Nia rolo uzas tiajn modulojn por administri diversajn grapolkomponentojn.
Kiel ĝi funkcias? Vi priskribas la deziratan staton de la areto en deklara agordo, kaj la rolo provizas ĉiun modulon per sia agorda sekcio kiel enigo. La modulo ricevas la nunan staton de la areto kaj komparas ĝin kun tio, kio estis ricevita kiel enigo. Poste, kodo estas lanĉita tra la ingo de unu el la kazoj, kiu alportas la areton al la dezirata stato.
Rezultoj
Hodiaŭ ni rakontis kaj montris kiel disfaldi vian aplikaĵon al Tarantool Cartridge kaj agordi simplan topologion. Por fari tion, ni uzis Ansible - potenca ilo, kiu estas facile uzebla kaj ebligas al vi samtempe agordi multajn infrastrukturajn nodojn (en nia kazo, cluster-instancoj).
Supre ni rigardis unu el la multaj manieroj priskribi cluster-agordon uzante Ansible. Kiam vi sentas vin preta por pluiri, esploru pri verkado de ludlibroj. Vi eble trovos pli facile administri vian topologion uzante group_vars и host_vars.
Tre baldaŭ ni diros al vi kiel konstante forigi (forigi) petskribojn de la topologio, ekfunkciigi vshardon, administri aŭtomatan malsukcesan reĝimon, agordi rajtigon kaj fliki la agordon de la grapolo. Intertempe, vi povas studi memstare kaj eksperimentu kun ŝanĝado de aretparametroj.
Se io ne funkcias, nepre nin pri la problemo. Ni ordigos ĉion rapide!
fonto: www.habr.com