Við höfum þegar talað um Tarantool skothylki, sem gerir þér kleift að þróa dreifð forrit og pakka þeim. Allt sem er eftir er að læra hvernig á að dreifa þessum forritum og stjórna þeim. Hafðu engar áhyggjur, við erum með þetta allt! Við settum saman allar bestu starfsvenjur til að vinna með Tarantool hylki og skrifuðum ansible-hlutverk, sem mun dreifa pakkanum á netþjóna, ræsa tilvik, sameina þá í þyrping, stilla heimild, ræsa vshard, virkja sjálfvirka bilun og plástra þyrpingastillingu.

Áhugavert? Þá vinsamlegast, undir skurðinum, munum við segja þér og sýna þér allt.

Við skulum byrja á dæmi

Við munum aðeins skoða hluta af virkni hlutverks okkar. Þú getur alltaf fundið fullkomna lýsingu á öllum getu þess og inntaksbreytum í skjöl. En það er betra að prófa einu sinni en að sjá það hundrað sinnum, svo við skulum setja inn lítið forrit.

Tarantool hylki hefur kennsluefni að búa til lítið Cartridge forrit sem geymir upplýsingar um viðskiptavini banka og reikninga þeirra, og veitir einnig API fyrir gagnastjórnun í gegnum HTTP. Til að ná þessu, lýsir viðaukinn tveimur mögulegum hlutverkum: api и storage, sem hægt er að úthluta til tilvika.

Hylkið sjálft segir ekkert um hvernig eigi að ræsa ferla, það veitir aðeins möguleika á að stilla tilvik sem þegar eru í gangi. Notandinn verður að gera restina sjálfur: raða uppstillingarskrám, hefja þjónustu og stilla staðfræði. En við munum ekki gera allt þetta; Ansible mun gera það fyrir okkur.

Frá orðum til athafna

Svo skulum við dreifa forritinu okkar á tvær sýndarvélar og setja upp einfalda staðfræði:

Eftirlíkingarsett app-1 mun útfæra hlutverkið api, sem felur í sér hlutverkið vshard-router. Hér verður aðeins eitt tilvik.
Eftirlíkingarsett storage-1 útfærir hlutverkið storage (og á sama tíma vshard-storage), hér munum við bæta við tveimur tilfellum frá mismunandi vélum.

Til að keyra dæmið sem við þurfum Vagrant и Ansible (útgáfa 2.8 eða eldri).

Hlutverkið sjálft er í Ansible Galaxy. Þetta er geymsla sem gerir þér kleift að deila vinnu þinni og nota tilbúin hlutverk.

Við skulum klóna geymsluna með dæmi:

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

Við ræktum sýndarvélar:

$ vagrant up

Settu upp Tarantool hylki sem hægt er að nota:

$ ansible-galaxy install tarantool.cartridge,1.0.1

Ræstu uppsett hlutverk:

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

Við bíðum eftir að leikbókin ljúki framkvæmd, farðu til http://localhost:8181/admin/cluster/dashboard og njóttu niðurstöðunnar:

Þú getur hlaðið upp gögnum. Flott, ekki satt?

Nú skulum við reikna út hvernig á að vinna með þetta og á sama tíma bæta við öðru eftirmyndarsetti við staðfræðina.

Við skulum byrja að átta okkur á því

Hvað gerðist?

Við settum upp tvær sýndarvélar og settum á markað leikbók sem stillti klasann okkar. Við skulum skoða innihald skrárinnar 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

Ekkert áhugavert gerist hér, við skulum ráðast í hlutverk sem heitir tarantool.cartridge.

Allir mikilvægustu hlutir (þ.e. þyrpingarstillingar) eru staðsettir í skrá-skrá 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:

Allt sem við þurfum er að læra hvernig á að stjórna tilvikum og afritum með því að breyta innihaldi þessarar skráar. Næst munum við bæta nýjum köflum við það. Til þess að ruglast ekki á því hvar á að bæta þeim við geturðu skoðað lokaútgáfu þessarar skráar, hosts.updated.yml, sem er í dæmi geymslunni.

Tilviksstjórnun

Í Ansible skilmálum er hvert tilvik gestgjafi (ekki að rugla saman við vélbúnaðarþjón), þ.e. innviðahnútinn sem Ansible mun stjórna. Fyrir hvern gestgjafa getum við tilgreint tengibreytur (svo sem ansible_host и ansible_user), sem og tilviksstillingu. Lýsing á tilvikum er í kaflanum hosts.

Við skulum skoða tilviksstillinguna storage-1:

all:
  vars:
    ...

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

  ...

Í breytilegu config við tilgreindum tilviksfæribreyturnar - advertise URI и HTTP port.
Hér að neðan eru tilviksfæribreytur app-1 и storage-1-replica.

Við þurfum að segja Ansible tengingarbreyturnar fyrir hvert tilvik. Það virðist rökrétt að flokka tilvik í sýndarvélahópa. Í þessu skyni eru tilvik sameinuð í hópa host1 и host2, og í hverjum hópi í hlutanum vars gildi eru tilgreind ansible_host и ansible_user fyrir eina sýndarvél. Og í kaflanum hosts — vélar (aka tilvik) sem eru með í þessum hópi:

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:

Við byrjum að breytast hosts.yml. Við skulum bæta við tveimur tilvikum í viðbót, storage-2-replica á fyrstu sýndarvélinni og storage-2 Á seinni:

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:  # <==
  ...

Ræstu leikbókina sem hægt er að gera:

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

Vinsamlegast athugaðu möguleikann --limit. Þar sem hvert klasatilvik er gestgjafi í Ansible skilmálum, getum við sérstaklega tilgreint hvaða tilvik ætti að stilla þegar leikbókin er keyrð.

Farið aftur í vefviðmótið http://localhost:8181/admin/cluster/dashboard og sjáðu nýju dæmin okkar:

Við skulum ekki hætta þar og ná tökum á stjórnun staðfræði.

Topology stjórnun

Við skulum sameina nýju tilvikin okkar í eftirmyndarsett storage-2. Bætum nýjum hópi við replicaset_storage_2 og lýsið eftirmyndarbreytum í breytum sínum á hliðstæðan hátt við replicaset_storage_1. Í kafla hosts Við skulum gefa til kynna hvaða tilvik verða með í þessum hópi (þ.e. eftirmyndarsettið okkar):

---
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:

Byrjum leikbókina aftur:

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

Á færibreytu --limit Að þessu sinni fórum við framhjá nafni hópsins sem samsvarar eftirlíkingunni okkar.

Við skulum íhuga möguleikann tags.

Hlutverk okkar sinnir ýmsum verkefnum í röð, sem eru merkt með eftirfarandi merkjum:

cartridge-instances: tilviksstjórnun (stillingar, tenging við aðild);
cartridge-replicasets: stjórnun svæðisfræði (eftirritastjórnun og varanleg fjarlæging (rekinn) tilvika úr klasanum);
cartridge-config: stjórnun annarra þyrpingarfæribreyta (vshard ræsing, sjálfvirk bilunarstilling, heimildarfæribreytur og forritastillingar).

Við getum sérstaklega tilgreint hvaða hluta vinnunnar við viljum vinna, þá mun hlutverkið sleppa restinni af verkefnum. Í okkar tilviki viljum við vinna aðeins með staðfræði, svo við tilgreindum cartridge-replicasets.

Við skulum meta árangur viðleitni okkar. Við finnum nýtt eftirlíkingarsett á http://localhost:8181/admin/cluster/dashboard.

Húrra!

Gerðu tilraunir með að breyta stillingum tilvika og eftirmyndasetta og sjáðu hvernig staðfræði klasans breytist. Þú getur prófað mismunandi rekstrarsviðsmyndir, t.d. rúllandi uppfærsla eða hækka memtx_memory. Hlutverkið mun reyna að gera þetta án þess að endurræsa tilvikið til að draga úr mögulegri niður í miðbæ forritsins þíns.

Ekki gleyma að hlaupa vagrant halttil að stöðva sýndarvélarnar þegar þú ert búinn að vinna með þær.

Hvað er undir hettunni?

Hér mun ég segja þér meira frá því sem var að gerast undir hettunni á ansible hlutverkinu meðan á tilraunum okkar stóð.

Við skulum skoða hvernig hægt er að nota Cartridge forritið skref fyrir skref.

Uppsetning pakkans og byrjunartilvik

Fyrst þarftu að afhenda pakkann á netþjóninn og setja hann upp. Eins og er getur hlutverkið unnið með RPM og DEB pakka.

Næst ræsum við tilvikin. Allt er mjög einfalt hér: hvert tilvik er aðskilið systemd-þjónusta. Ég skal gefa þér dæmi:

$ systemctl start myapp@storage-1

Þessi skipun mun ræsa tilvikið storage-1 приложения myapp. Hleypt af stokkunum tilviki mun leita að því uppsetningu в /etc/tarantool/conf.d/. Hægt er að skoða tilviksskrár með því að nota journald.

Einingaskrá /etc/systemd/system/[email protected] fyrir systemd þjónustu verður afhent ásamt pakkanum.

Ansible er með innbyggðar einingar til að setja upp pakka og stjórna kerfisþjónustu; við höfum ekki fundið upp neitt nýtt hér.

Að setja upp þyrpingastórfræði

Hér byrjar fjörið. Sammála, það væri skrítið að skipta sér af sérstöku Ansible hlutverki til að setja upp pakka og keyra systemd-þjónusta.

Þú getur stillt þyrpinguna handvirkt:

Fyrsti valkosturinn: opnaðu vefviðmótið og smelltu á hnappana. Það er alveg hentugur fyrir einu sinni byrjun í nokkrum tilvikum.
Annar valkostur: þú getur notað GraphQl API. Hér geturðu nú þegar gert eitthvað sjálfvirkt, til dæmis skrifað handrit í Python.
Þriðji valkosturinn (fyrir viljasterka): farðu á netþjóninn, tengdu við eitt af tilvikunum sem nota tarantoolctl connect og framkvæma allar nauðsynlegar meðhöndlun með Lua einingunni cartridge.

Meginverkefni uppfinningar okkar er að gera nákvæmlega þetta, erfiðasta hluta verksins fyrir þig.

Ansible gerir þér kleift að skrifa þína eigin einingu og nota hana í hlutverki. Hlutverk okkar notar slíkar einingar til að stjórna ýmsum klasahlutum.

Hvernig það virkar? Þú lýsir æskilegu ástandi klasans í yfirlýsandi stillingu og hlutverkið veitir hverri einingu stillingarhlutann sem inntak. Einingin tekur við núverandi ástandi klasans og ber það saman við það sem var móttekið sem inntak. Næst er kóði ræstur í gegnum fals eins tilvikanna, sem færir þyrpinguna í æskilegt ástand.

Niðurstöður

Í dag sögðum við og sýndum hvernig á að dreifa forritinu þínu á Tarantool hylki og setja upp einfalda staðfræði. Til að gera þetta notuðum við Ansible - öflugt tól sem er auðvelt í notkun og gerir þér kleift að stilla marga innviðahnúta samtímis (í okkar tilviki, klasatilvik).

Hér að ofan skoðuðum við eina af mörgum leiðum til að lýsa klasauppsetningu með Ansible. Þegar þú telur þig vera tilbúinn til að halda áfram skaltu kanna bestu starfsvenjur um að skrifa leikrit. Þú gætir átt auðveldara með að stjórna staðfræðinni þinni með því að nota group_vars и host_vars.

Mjög fljótlega munum við segja þér hvernig á að eyða (rekna) tilfellum varanlega úr staðfræðinni, ræsa vshard, stjórna sjálfvirkri bilunarstillingu, stilla heimild og plástra þyrpingastillingu. Í millitíðinni geturðu lært á eigin spýtur skjöl og gera tilraunir með að breyta klasabreytum.

Ef eitthvað virkar ekki, vertu viss um að gera það Láttu mig vita okkur um vandamálið. Við reddum öllu fljótt!

Heimild: www.habr.com

Sendu forritum auðveldlega og náttúrulega í Tarantool hylki (hluti 1)