Oleme juba rääkinud Tarantool Cartridge, mis võimaldab arendada ja pakkida jaotatud rakendusi. Jäänud on veel vaid õppida, kuidas neid rakendusi juurutada ja nendega töötada. Ärge muretsege, me oleme kõik ette näinud! Oleme kokku kogunud kõik parimad tavad Tarantool Cartridge'i kasutamiseks ja kirjutanud ansible-rolle, mis paigaldab paketi serveritele, käivitab instantsid, ühendab need klastriks, seadistab autoriseerimise, bootstrab vshard'i, lubab automaatse viivituse ja värskendab klastri konfiguratsiooni.

Huvitav? Siis tulge edasi, räägime ja näitame kõike.

Alustame näitest

Käsitleme ainult osa meie rolli funktsionaalsusest. Täieliku kirjelduse kõikidest selle võimalustest ja sisendparameetritest leiate alati dokumentatsioon. Kuid parem on kord proovida, kui sada korda näha, seega lähme ja juurutame väikese rakenduse.

Tarantool Cartridge'il on tutvustus näide väikese Cartridge-rakenduse loomiseks, mis salvestab teavet panga klientide ja nende kontode kohta ning pakub API-t andmete haldamiseks läbi HTTP. Selleks kirjeldatakse rakenduses kahte võimalikku rolle: api ja salvestusruum, mis võivad omistada instantsidele.

Ise Cartridge ei ütle midagi protsesside käivitamise kohta, ta ainult võimaldab juba käivitatud instantside seadistamist. Ülejäänud peab kasutaja ise tegema: konfigureerimisfailid paigutama, teenuseid käivitama ja topoloogiat seadistama. Kuid me ei pea selle kõigega tegelema, Ansible teeb meie eest.

Tegemist on asjadega

Nii et juurutame meie rakenduse kahele virtuaalmasinale ja seadistame lihtsa topoloogia:

• Replikasett app-1 rakendab rolli api, mis sisaldab rolli vshard-router. Siin on ainult üks instants.
• Replikasett storage-1 rakendab rolli salvestusruum (ja samal ajal vshard-storage), siia lisame kaks instantsit erinevatelt masinatelt.

Näite käivitamiseks vajame Vagrant ja Ansible (versioon 2.8 või vanem).

Ise roll asub Ansible Galaxy. See on hoidla, mis võimaldab jagada oma arengutöid ja kasutada valmis rolle.

Kloonime näidise hoidla:

$ git clone https://github.com/dokshina/deploy-tarantool-cartridge-app.git
$ cd deploy-tarantool-cartridge-app && git checkout 1.0.0

Käivitame virtuaalmasinad:

$ vagrant up

Paigaldame ansible-rolle Tarantool Cartridge:

$ ansible-galaxy install tarantool.cartridge,1.0.1

Käivitame paigaldatud rolli:

$ ansible-playbook -i hosts.yml playbook.yml

Ootame mänguplaani täitmise lõppu, liikume edasi http://localhost:8181/admin/cluster/dashboard ja naudime tulemust:

Saame andmeid voolata. Lahe, eks?

Nüüd hakkame aru saama, kuidas sellega töötada, ja lisame samal ajal veel ühe replikaatsarja topoloogiasse.

Hakkame uurima

Niisiis, mis juhtus?

Me tõstsime üles kaks virtuaalmasinat ja jooksutasime ansiblei mängu, mis seadistab meie klastrit. 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.cartridge

Siin ei toimub midagi huvitavat, käivitame ansiblei rolli, mis nimetatakse tarantool.cartridge.

Kõik tähtsam (nimelt, klastrikonfiguratsioon) asub inventory-failis 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 vajame, on õppida hallata instantsse ja replikaatsarju, muutes selle faili sisu. Edasi lisame sellesse uusi sektsioone. Et mitte segadusse minna, kuhu neid lisada, võite piiluda selle faili lõppversiooni hosts.updated.yml, mis asub näidisrepozitarius.

Instantside haldamine

Ansible'i terminoloogias on iga instants host (mitte segi ajada füüsilise serveriga), st infrastruktuuri sõlme, mida Ansible haldab. Iga hosti puhul saame määrata ühendusparameetrid (nt ansible_host ja ansible_user), ja ka instantsi konfiguratsioon. Instantside kirjeldus asub jaotises hostid.

Vaadakem instantsi konfiguratsiooni storage-1:

kõik:
  muutuja:
    ...

  # INSTANSDID
  hostid:
    storage-1:
      konfiguratsioon:
        advertise_uri: '172.19.0.2:3301'
        http_port: 8181

  ...

Mu variables failist, saadab need andmed serverisse oleme määranud instantsi parameetrid — advertise URI ja HTTP port.
Allpool on instantside parameetrid app-1 ja storage-1-replica.

Peame Ansiblele edastama ühenduse parameetrid iga instantsi jaoks. Tundub loogiline gruppida instantsid virtuaalmasinate kaupa. Selle jaoks on instantsid grupeeritud host1 ja host2, ja igas grupis jaotises muutuja on määratud väärtused ansible_host ja ansible_user ühe virtuaalmasina jaoks. Ja jaotises hostid — hostid (mis on ka instantsid), mis kuuluvad sellesse gruppi:

kõik:
  muutuja:
    ...
  hostid:
    ...
  lapsed:
    # GRUPPEERI INSTANSDID MASINATE KAUPA
    host1:
      muutuja:
        # esimese masina ühendamise võimalused
        ansible_host: 172.19.0.2
        ansible_user: vagrant
       hostid:  # instantsid, mis käivitatakse esimesel masinal
        storage-1:

     host2:
      muutuja:
        # teise masina ühendamise võimalused
        ansible_host: 172.19.0.3
        ansible_user: vagrant
       hostid:  # instantsid, mis käivitatakse teisel masinal
        app-1:
        storage-1-replica:

Alustame muutmist hosts.yml. Lisame veel kaks instantsi, storage-2-replica esimesel virtuaalmasinal ja storage-2 teisel:

kõik:
  muutuja:
    ...

  # INSTANSDID
  hostid:
    ...
    storage-2:  # <==
      konfiguratsioon:
        advertise_uri: '172.19.0.3:3303'
        http_port: 8184

    storage-2-replica:  # <==
      konfiguratsioon:
        advertise_uri: '172.19.0.2:3302'
        http_port: 8185

  lapsed:
    # GRUPPEERI INSTANSDID MASINATE KAUPA
    host1:
      muutuja:
        ...
      hostid:  # instantsid, mis käivitatakse esimesel masinal
        storage-1:
        storage-2-replica:  # <==

    host2:
      muutuja:
        ...
      hostid:  # instantsid, mis käivitatakse teisel masinal
        app-1:
        storage-1-replica:
        storage-2:  # <==
  ...

Käivitage ansible-playbook:

$ ansible-playbook -i hosts.yml 
                   --limit storage-2,storage-2-replica 
                   playbook.yml

Pöörake tähelepanu valikule --limit. Kuna iga klastrite instants on Ansible'i mõisted host, võime selgelt näidata, milliseid instantsse tuleb seadistada playbooki käitamisel.

Siseneme taas Web UI-sse http://localhost:8181/admin/cluster/dashboard ja vaatame meie uusi instantsse:

Ärme jääge saavutatu juurde ja õppigem tutvustama topoloogiat.

Topoloogia haldamine

Kombineerime meie uued instantsid replikakomplekti storage-2. Lisame uue grupi replicaset_storage_2 ja kirjeldame tema muutujates replikakomplekti parameetreid sarnaselt replicaset_storage_1. Sektsioonis hostid määra, millised instantsid kuuluvad sellesse gruppi (st meie replikakomplekti):

---
all:
  vars:
    ...
  hosts:
    ...
  children:
    ...
    # RÜHMA INSTANTSID KLOONIDE KAUDEL
    ...
    replicaset_storage_2:  # <==
      vars:  # replikaseti konfiguratsioon
        replicaset_alias: storage-2
        weight: 2
        failover_priority:
          - storage-2
          - storage-2-replica
        roles:
          - 'storage'

      hosts:   # replikaseti instantsid
        storage-2:
        storage-2-replica:

Käivitame mänguaktiivi uuesti:

$ ansible-playbook -i hosts.yml 
                   --limit replicaset_storage_2 
                   --tags cartridge-replicasets 
                   playbook.yml

Parameeter --limit sellel korral edastame grupi nime, mis vastab meie replikasetile.

Vaatame valikut tags.

Meie roll täidab järjest erinevaid ülesandeid, millel on järgmised sildid:

• cartridge-instances: instantside haldamine (seadistamine, ühendamine membershipiga);
• cartridge-replicasets: topoloogia haldamine (replikasettide haldamine ja instantside pöördumatud eemaldamine (expel) klastrist);
• cartridge-config: teiste klastriparametrite haldamine (vshard bootstrapping, automaatse failoveri režiim, autentimise parameetrid ja rakenduse konfiguratsioon).

Me saame selgesõnaliselt määrata, millist osa tööst tahame teha, siis roll jätab täitmata ülejäänud ülesanded. Meie juhul tahame töötada ainult topoloogiaga, seega määrasime cartridge-replicasets.

Hinnakem meie pingutuste tulemust. Otsime uut replikaseti http://localhost:8181/admin/cluster/dashboard.

Jee!

Katsuge muuta instantside ja replikasettide konfiguratsiooni ja vaadake, kuidas klassi topoloogia muutub. Saate proovida erinevaid operatsiooniskeeme, näiteks rolling update või suurendamine memtx_memory. Roll püüab seda teha ilma instantsi taaskäivitamiseta, et vähendada teie rakenduse võimaliku seisaku aega.

Ärge unustage käivitada vagrant halt, et peatada virtuaalmasinad, kui olete nendega töötamise lõpetanud.

Aga mis on kapoti all?

Siin kirjeldan lähemalt, mis toimus ansible-rolli all meie katsete ajal.

Vaatame samm-sammult, kuidas Cartridge-rakendust paigaldada.

Paketi installimine ja instantside käivitamine

Esiteks tuleb pakett serverisse toimetada ja see installida. Praegu oskab roll töötada RPM- ja DEB-pakettidega.

Seejärel käivitame instantsid. Siin on kõik väga lihtne: iga instants on eraldi systemd-teenus. Selgitan näite abil:

$ systemctl start myapp@storage-1

See käsk käivitab instantsi storage-1 rakenduse myapp. Käivitatud instants otsib oma konfiguratsiooni ja /etc/tarantool/conf.d/. Instantsi logisid saab vaadata abil journald.

Unit-fail /etc/systemd/system/myapp@.sevice systemd-teenuse jaoks toimetatakse koos paketiga.

Ansible'il on integreeritud moodulid pakettide installimiseks ja systemd teenuste haldamiseks, siin me ei ole midagi uut välja mõelnud.

Klastri topoloogia seadistamine

Siit hakkab kõige huvitavam osa pihta. Oli ju kummaline kasutada erilist ansible-rolli pakettide installimiseks ja käivitamiseks systemd-teenustest.

Klastri saab seadistada käsitsi:

• Esimene variant: avame Veebi kasutajaliidese ja vajutame nuppudele. Ühe korraga mitme instantsi käivitamiseks sobib täiesti.
• Teine variant: saate kasutada GraphQl API-d. Siin saab automatiseerida näiteks kirjutada Pythonis skripti.
• Kolmas variant (võimsatele vaimudele): logime sisse serverisse, ühendame ühe instantsiga kasutades tarantoolctl connect ja teeme kõik vajalikud manipulatsioonid Lua mooduliga cartridge.

Meie leiutamise peamine eesmärk on teha just see, kõige keerulisem osa tööst, teie eest.

Ansible võimaldab kirjutada oma mooduli ja kasutada seda rollis. Meie roll kasutab selliseid mooduleid klastrite erinevate komponentide haldamiseks.

Kuidas see töötab? Te kirjeldate soovitud klastriseisundit deklaratiivselt konfigureerimises, ja roll edastab igale moodulile vastava konfiguratsioonisegmendi. Moodul saab klastrist hetkeseisundi ja võrdleb seda selle sisendiga. Seejärel käivitab ühe instantsi socketi kaudu koodi, mis viib klastrit soovitud seisundisse.

Summary

Täna rääkisime ja näitasime, kuidas teie rakendust Tarantool Cartridge'il kasutada ja seadistada lihtne topoloogia. Selleks kasutasime Ansible't - võimekat tööriista, mis on kasutamise poolest lihtne ja võimaldab korraga seadistada palju infrastruktuuri sõlmi (meie puhul on need klastrite instantsid).

Ülal oleme tutvunud ühe paljude viisidega klastrikonfiguratsiooni kirjeldamiseks Ansible abil. Niipea kui olete valmis edasi liikuma, uurige best practices pleikide kirjutamiseks. Võimalik, et teil on mugavam hallata topoloogiat kasutades group_vars ja host_vars.

Käesoleval ajal räägime, kuidas alates klastrist jäädavalt eemaldada (expel) instantsid topoloogiast, bootstrappida vshard, hallata automaatse failover'i režiimi, seadistada autoriseerimist ja patchida klastrikonfi. Ja seni võite iseseisvalt uurida. dokumentatsioon ja katsetada klastriparameetrite muutmist.

Kui midagi ei tööta, kindlasti teatage meile probleemist. Lahendame selle kiiresti!

Allikas: habr.com