Lihtsalt ja muretult juurutame rakendusi Tarantool Cartridge’is (osa 1)

Oleme juba rääkinud Tarantool Cartridge, mis võimaldab arendada ja pakendada jaotatud rakendusi. Jäänud on vaid õppida, kuidas neid rakendusi käitada ja hallata. Ärge muretsege, oleme kõik hoolikalt läbi mõelnud! Oleme kokku kogunud kõik parimad praktikad Tarantool Cartridge’i töötamiseks ja kirjutanud ansible-rol, mis paigaldab paketi serveritele, käivitab instantsid, ühendab need klastriks, seadistab autentimise, bootstrapi vshardi, lubab automaatse failover'i ja uuendab klasterkonfign.

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

Alustame näitest

Kaalume ainult osa meie rolli funktsionaalsusest. Kõiki selle võimalusi ja sisendparameetreid saate alati leida dokumentatsioonis. Kuid parem on kord proovida kui sada korda näha, seega laske meil käitada väike rakendus.

Tarantool Cartridge'il on tutorial näide väikese Cartridge-rakenduse loomisest, mis salvestab panga klientide ja nende kontode teavet ning pakub API-d andmete haldamiseks HTTP kaudu. Selleks kirjeldatakse rakenduses kahte võimalikku rolli: api ja storage, mis võivad instantsidele määratud olla.

Cartridge ei ütle midagi selle kohta, kuidas protsesse käivitada, vaid annab võimaluse juba jooksvaid instantsse konfigureerida. Ülejäänud peab kasutaja ise ära tegema: seadistama konfiguratsioonifailid, käivitama teenused ja seadistama topoloogia. Kuid me ei hakka selle kõigega vaeva nägema, selle teeb meie eest Ansible.

Sõnadest tegu

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

Repliikasett app-1 realiseerib rolli api, mis hõlmab rolli vshard-router. Siin on vaid üks instants.
Repliikasett storage-1 realiseerib rolli storage (ja samal ajal vshard-storage), siia lisame kaks instantsi erinevatelt masinatelt.

Lihtsalt ja muretult juurutame rakendusi Tarantool Cartridge’is (osa 1)

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

Ise roll asub Ansible Galaxy. See on koht, kus saab jagada oma saavutusi ja kasutada olemasolevaid rolle.

Kloonime näidisrepo:

$ 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-rolli Tarantool Cartridge:

$ ansible-galaxy install tarantool.cartridge,1.0.1

Käivitame paigaldatud rolli:

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

Ootame mänguplaadi täitmise lõppemist, liikudes edasi http://localhost:8181/admin/cluster/dashboard ja naudime tulemust:

Lihtsalt ja muretult juurutame rakendusi Tarantool Cartridge’is (osa 1)

Saame andmeid sisestada. Lahe, eks?

Nüüd uurime, kuidas sellega töötada, ja lisame samal ajal süsteemi veel ühe replikasethi.

Alustame uurimist

Nii, mis juhtus?

Oleme käivitanud kaks virtuaalset masinat ja jooksutanud ansible-mänguplaadi, mis seadistab meie klastrit. Vaadakem failide sisu playbook.yml:

---
- name: Paigaldada minu Tarantool Cartridge rakendus
  hosts: kõik
  become: true
  become_user: root
  tasks:
  - name: Import Tarantool Cartridge roll
    import_role:
      name: tarantool.cartridge

Siin ei toimu midagi huvitavat, käivitame ansible-rolli, mis nimetatakse tarantool.cartridge.

Kogu kõige olulisem (nimelt, klastrikonfiguratsioon) asub inventory-failis hosts.yml:

---
all:
  vars:
    # tavalised klastrimuutujad
    cartridge_app_name: getting-started-app
    cartridge_package_path: ./getting-started-app-1.0.0-0.rpm  # paketi tee

    cartridge_cluster_cookie: app-default-cookie  # klastriküpsis

    # tavalised ssh valikud
    ansible_ssh_private_key_file: ~/.vagrant.d/insecure_private_key
    ansible_ssh_common_args: '-o IdentitiesOnly=yes -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'

  # INSTANSSID
  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:
    # RÜHMA INSTANSSID MASINATE JÄRGI
    host1:
      vars:
        # esimese masina ühenduse valikud
        ansible_host: 172.19.0.2
        ansible_user: vagrant

      hosts:  # instansid, mis käivitatakse esimesel masinal
        storage-1:

    host2:
      vars:
        # teise masina ühenduse valikud
        ansible_host: 172.19.0.3
        ansible_user: vagrant

      hosts:  # instansid, mis käivitatakse teisel masinal
        app-1:
        storage-1-replica:

    # RÜHMA INSTANSSID REPLIKA SEADME JÄRGI
    replicaset_app_1:
      vars:  # replika seade konfiguratsioon
        replicaset_alias: app-1
        failover_priority:
          - app-1  # juht
        roles:
          - 'api'

      hosts:  # replika seadme instansid
        app-1:

    replicaset_storage_1:
      vars:  # replika seade konfiguratsioon
        replicaset_alias: storage-1
        weight: 3
        failover_priority:
          - storage-1  # juht
          - storage-1-replica
        roles:
          - 'storage'

      hosts:   # replika seadme instansid
        storage-1:
        storage-1-replica:

Kõik, mida me vajame, on õppida haldama instantsse ja replikasete, muutes selle faili sisu. Edasi lisame sinna uusi sektsioone. Segaduse vältimiseks võite piiluda selle faili lõpliku versiooni sisse. hosts.updated.yml, mis asub näidise hoidlas.

Instantside haldamine

Ansible'i mõistes on iga instants host (ära sega seda füüsilise serveriga), st infrastruktuuri sõlm, mille üle Ansible haldus teeb. Iga hosti jaoks saame määrata ühenduse parameetrid (nt ansible_host ja ansible_user), samuti instantsi konfiguratsiooni. Instantside kirjeldus asub jaotises hosts.

Vaatame instantsi konfiguratsiooni storage-1:

all:
  vars:
    ...

  # INSTANSSID
  hosts:
    storage-1:
      config:
        advertise_uri: '172.19.0.2:3301'
        http_port: 8181

  ...

Muutujas edasi konsolideerimiseks ja aggregeerimiseks. oleme määranud instantsi parameetrid — advertise URI ja HTTP port.
Allpool on instantside parameetrid app-1 ja storage-1-replika.

Peame Ansible'ile edastama ühenduse parameetrid iga instantsi jaoks. Tundub loogiline gruppida instantsid virtuaalmasinate järgi. Selleks on instantsid ühendatud gruppidesse host1 ja host2, ja igas grupis jaotises vars on näidatud väärtused ansible_host ja ansible_user ühe virtuaalmasina jaoks. Ja jaotises hosts — hostid, mis kuuluvad sellesse gruppi:

all:
  vars:
    ...
  hosts:
    ...
  children:
    # GRUPI INSTANSSID MASINATE KAUDEL
    host1:
      vars:
        # esimese masina ühenduse valikud
        ansible_host: 172.19.0.2
        ansible_user: vagrant
       hosts:  # instansid, mis käivitatakse esimesel masinal
        storage-1:

     host2:
      vars:
        # teise masina ühenduse valikud
        ansible_host: 172.19.0.3
        ansible_user: vagrant
       hosts:  # instansid, mis käivitatakse teisel masinal
        app-1:
        storage-1-replica:

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

all:
  vars:
    ...

  # INSTANSSID
  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:
    # GRUPI INSTANSSID MASINATE KAUDEL
    host1:
      vars:
        ...
      hosts:  # instansid, mis käivitatakse esimesel masinal
        storage-1:
        storage-2-replica:  # <==

    host2:
      vars:
        ...
      hosts:  # instansid, mis käivitatakse teisel masinal
        app-1:
        storage-1-replica:
        storage-2:  # <==
  ...

Käivitame ansible-playbooki:

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

Pange tähele valikut --limit. Kuna iga klastri instants on Ansible'i mõistes host, saame selgelt määrata, milliseid instantsse tuleks playbooki käivitamisel seadistada.

Logime uuesti sisse Web UI-sse http://localhost:8181/admin/cluster/dashboard ja jälgime meie uusi instantsi:

Lihtsalt ja muretult juurutame rakendusi Tarantool Cartridge’is (osa 1)

Ärme peatu saavutatu juures, vaid õpime tundma topoloogia haldamist.

Topoloogia haldamine

Kombineerime meie uued instantsid replikasetti storage-2. Lisame uue rühma replicaset_storage_2 ja kirjeldame selle muutujates replikasetti parameetreid analoogia alusel replicaset_storage_1. Jaotises hosts näitame, millised instantsid kuuluvad sellesse rühma (ehk meie replikasetti):

---
all:
  vars:
    ...
  hosts:
    ...
  children:
    ...
    # RÜHMITA INSTANSSID REPLIKA SETIDE ALUSEL
    ...
    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 taas playbooki:

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

Parameeter --limit mille me seekord edastasime grupi nime, mis vastab meie replikasettile.

Vaadakem võimalust tags.

Meie roll täidab järjest erinevaid ülesandeid, mis on märgitud järgmiste siltidega:

cartridge-instances: instantside haldamine (seadistamine, ühendamine membership'iga);
cartridge-replicasets: topoloogia haldamine (replikasettide haldamine ja instantside pöördumatud eemaldamine (expel) klastri seast);
cartridge-config: klastri teiste parameetrite haldamine (vshard bootstrapping, automaatse failover'i režiim, autoriseerimise parameetrid ja rakenduse konfigureerimine).

Me saame selgelt määrata, millist osa tööst soovime teha, siis roll jätab ülejäänud ülesanded vahele. Meie puhul soovime töötada ainult topoloogiaga, seega määrasime cartridge-replicasets.

Hinnatakse meie pingutuste tulemust. Leiame uue replikaseti aadressil http://localhost:8181/admin/cluster/dashboard.

Lihtsalt ja muretult juurutame rakendusi Tarantool Cartridge’is (osa 1)

Hurraa!

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

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

Aga mis toimub taustal?

Siin räägin lähemalt, mis toimus ansible-rolli taustal meie katsete ajal.

Vaadake samm-sammult Cartridge-rakenduse juurutamist.

Paketi installimine ja instantside käivitamine

Esmalt peab paketi serverisse toimetama ja installima. Nüüd 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 varal:

$ systemctl start myapp@storage-1

See käsk käivitab instantsi storage-1 rakendused myapp. Käivitatud instants otsib oma konfiguratsiooni ühes /etc/tarantool/conf.d/. Instantsi logisid saab vaadata kasutades journald.

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

Ansible'il on sisseehitatud moodulid pakettide installimiseks ja systemd-teenuste haldamiseks, siin me midagi uut ei leiutanud.

Klastri topoloogia seadistamine

Siin hakkab kõige huvitavam osa. Nõustuge, et oleks kummaline vaeva näha erilise ansible-rolliga pakettide installimiseks ja systemd-teenuste käivitamiseks.

Klaster saab seadistada käsitsi:

Esimene variant: avame veebiliidese ja vajutame nuppudele. Ühe korra mitme instantsi käivitamiseks sobib see küll.
Teine variant: saab kasutada GraphQl API-d. Siin on juba midagi automatiseerida, näiteks kirjutada Pythonis skript.
Kolmas variant (tõsistele): siseneme serverisse, ühendume ühe instantsiga kasutades tarantoolctl connect ja teeme kõik vajalikud toimingud Lua-mooduliga cartridge.

Meie leiutise peamine eesmärk on teha teie jaoks just see, kõige keerulisem tööosa.

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

Kuidas see töötab? Kirjutate soovitud klastririigi deklaratiivses konfiguratsioonis, ja roll edastab igale moodulile selle konfiguratsiooni osa. Moodul saab klastrite hetkeseisu ja võrdleb seda sisendiks saadud olekuga. Seejärel käivitab üks instantsidest kaudu sokli koodi, mis viib klastrite soovitud seisundisse.

Kokkuvõte

Täna rääkisime ja näitasime, kuidas oma rakendust Tarantool Cartridge'ile juurutada ja seadistada lihtne topoloogia. Selleks kasutasime Ansible'it — võimekat tööriista, mis paistab silma kasutusmugavusega ja võimaldab samal ajal seadistada mitmeid infrastruktuuri sõlmi (meie juhul klastrite instantsid).

Eelnevalt käsitlesime ühte paljusid viise, kuidas Ansible'i abil klastrikonfiguratsiooni kirjeldada. Kui olete valmis edasi liikuma, uurige parimaid tavasid playbookide kirjutamiseks. Võib-olla on teie jaoks mugavam hallata topoloogiat kasutades group_vars ja host_vars.

Varsti räägime, kuidas pöördumatult (expel) eemaldada instantsid topoloogiast, buutida vshard'i, hallata automaatse failover'i režiimi, seadistada autoriseerimist ja patši klastrikonfiguratsiooni. Seni võite iseseisvalt uurida dokumentatsiooni ja katsetada klastriparameetrite muutmist.

Kui midagi ei toimi, andke kindlasti meile probleemist teada. Lahendame kõik kiiresti! teavitage meid probleemist. Lahendame selle kiiresti!

Allikas: habr.com