Ons het reeds gepraat oor Tarantool patroon, wat jou toelaat om verspreide toepassings te ontwikkel en dit te verpak. Daar is niks oor nie: leer hoe om hierdie toepassings te ontplooi en te bestuur. Moenie bekommerd wees nie, ons het aan alles gedink! Ons het al die beste praktyke vir die werk met Tarantool Cartridge saamgestel en geskryf ansible-rol, wat die pakket in bedieners sal ontbind, die gevalle sal begin, hulle in 'n groepering kombineer, magtiging opstel, selflaai vshard, outomatiese failover aktiveer en die groepkonfigurasie regmaak.

Interessant? Dan vra ek onder die snit, ons sal alles vertel en wys.

Kom ons begin met 'n voorbeeld

Ons sal slegs 'n deel van die funksionaliteit van ons rol dek. Jy kan altyd 'n volledige beskrywing van al sy kenmerke en invoerparameters in vind dokumentasie. Maar dit is beter om een keer te probeer as om honderd keer te sien, so kom ons ontplooi 'n klein toepassing.

Tarantool Cartridge het tutoriaal om 'n klein Cartridge-toepassing te skep wat inligting oor bankkliënte en hul rekeninge stoor, en ook 'n API verskaf om data via HTTP te bestuur. Om dit te doen, beskryf die toepassing twee moontlike rolle: api и storagewat aan gevalle toegewys kan word.

Cartridge self sê niks oor hoe om prosesse te begin nie, dit bied net die vermoë om reeds lopende gevalle op te stel. Die gebruiker moet die res self doen: die konfigurasielêers ontbind, die dienste begin en die topologie opstel. Maar ons sal dit nie alles doen nie, Ansible sal dit vir ons doen.

Van woorde tot dade

Dus, laat ons ons toepassing op twee virtuele masjiene ontplooi en 'n eenvoudige topologie opstel:

Replikaset app-1 sal die rol speel apiwat die rol insluit vshard-router. Daar sal net een geval hier wees.
replikaset storage-1 implementeer die rol storage (en terselfdertyd vshard-storage), hier voeg ons twee gevalle van verskillende masjiene by.

Om die voorbeeld uit te voer, het ons nodig swerwer и Ansible (weergawe 2.8 of later).

Die rol self is Ansible Galaxy. Dit is 'n bewaarplek wat jou toelaat om jou werk te deel en klaargemaakte rolle te gebruik.

Kloon die bewaarplek met 'n voorbeeld:

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

Ons verhoog virtuele masjiene:

$ vagrant up

Installeer die Tarantool Cartridge se moontlike rol:

$ ansible-galaxy install tarantool.cartridge,1.0.1

Begin die geïnstalleerde rol:

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

Ons wag vir die einde van die uitvoering van die speelboek, gaan na http://localhost:8181/admin/cluster/dashboard en geniet die resultaat:

Jy kan data gooi. Cool, reg?

Kom ons kyk nou uit hoe om hiermee te werk, en voeg terselfdertyd nog 'n replika-stel by die topologie.

Ons begin verstaan

So wat het gebeur?

Ons het twee VM's aan die gang gekry met 'n moontlike speelboek wat ons groepie opgestel het. Kom ons kyk na die inhoud van die lêer 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

Niks interessants gebeur hier nie, ons begin die ansible-rol, wat genoem word tarantool.cartridge.

Al die belangrikste (naamlik die groepkonfigurasie) is geleë in voorraad-lêer 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:

Al wat ons nodig het, is om te leer hoe om gevalle en replikastelle te bestuur deur die inhoud van hierdie lêer te verander. Vervolgens sal ons nuwe afdelings daarby voeg. Om nie deurmekaar te raak waar om dit by te voeg nie, kan jy in die finale weergawe van hierdie lêer loer, hosts.updated.yml, wat in die voorbeeldbewaarplek is.

Gevalbestuur

In terme van Ansible is elke instansie 'n gasheer (nie te verwar met 'n ysterbediener nie), d.w.s. die infrastruktuurnodus wat Ansible sal bestuur. Vir elke gasheer kan ons verbindingsparameters spesifiseer (soos ansible_host и ansible_user), sowel as die instansiekonfigurasie. Beskrywing van gevalle is in die afdeling hosts.

Oorweeg die instansiekonfigurasie storage-1:

all:
  vars:
    ...

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

  ...

In 'n veranderlike config ons het die instansieparameters gespesifiseer - advertise URI и HTTP port.
Hieronder is die instansie parameters app-1 и storage-1-replica.

Ons moet vir Ansible die verbindingsparameters vir elke geval vertel. Dit lyk logies om gevalle in virtuele masjiengroepe te groepeer. Om dit te doen, word gevalle in groepe gekombineer. host1 и host2, en in elke groep in die afdeling vars waardes ansible_host и ansible_user vir een virtuele masjien. En in die afdeling hosts - leërskare (dit is gevalle) wat by hierdie groep ingesluit is:

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:

Ons begin verander hosts.yml. Kom ons voeg nog twee gevalle by, storage-2-replica op die eerste virtuele masjien en storage-2 Op die tweede:

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

Begin moontlike speelboek:

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

Gee aandag aan die opsie --limit. Aangesien elke groepgeval 'n gasheer is in Ansible-terme, kan ons uitdruklik spesifiseer watter gevalle gekonfigureer moet word wanneer die speelboek uitgevoer word.

Terug na Web UI http://localhost:8181/admin/cluster/dashboard en let op ons nuwe gevalle:

Ons sal nie op ons louere rus nie en sal topologiebeheer bemeester.

Topologiebestuur

Kom ons voeg ons nuwe gevalle saam in 'n replikaset storage-2. Kom ons voeg 'n nuwe groep by replicaset_storage_2 en beskryf in sy veranderlikes die parameters van die replikase na analogie met replicaset_storage_1. In afdeling hosts spesifiseer watter gevalle by hierdie groep ingesluit sal word (dit is ons replika-stel):

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

Kom ons begin weer die speelboek:

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

Per parameter --limit ons het hierdie keer die naam van die groep geslaag wat ooreenstem met ons replikaset.

Oorweeg die opsie tags.

Ons rol voer opeenvolgend verskeie take uit, wat met die volgende etikette gemerk is:

cartridge-instances: instansiebestuur (konfigurasie, verbinding met lidmaatskap);
cartridge-replicasets: topologiebestuur (replikasetbestuur en permanente verwydering (verdryf) van gevalle uit die groepering);
cartridge-config: bestuur ander groepparameters (vshard selflaai, outomatiese failover-modus, magtigingsparameters en toepassingkonfigurasie).

Ons kan uitdruklik spesifiseer watter deel van die werk ons wil doen, dan sal die rol die res van die take oorslaan. In ons geval wil ons net met die topologie werk, daarom het ons gespesifiseer cartridge-replicasets.

Kom ons evalueer die resultaat van ons pogings. Soek 'n nuwe replikaset http://localhost:8181/admin/cluster/dashboard.

Hoera!

Eksperimenteer met die herkonfigurasie van gevalle en replikastelle en kyk hoe die groeptopologie verander. U kan verskillende operasionele scenario's probeer, bv. rollende opdatering of verhoog memtx_memory. Die rol sal probeer om dit te doen sonder om die instansie te herbegin om die moontlike stilstand van jou toepassing te verminder.

Moenie vergeet om te hardloop nie vagrant haltom VM'e te stop wanneer jy daarmee klaar is.

Wat is onder die enjinkap?

Hier sal ek meer praat oor wat gebeur het onder die kap van die moontlike rol tydens ons eksperimente.

Kom ons kyk stap vir stap na die implementering van 'n Cartridge-toepassing.

Installeer die pakket en begin gevalle

Eerstens moet u die pakket by die bediener aflewer en dit installeer. Nou kan die rol met RPM- en DEB-pakkette werk.

Vervolgens begin ons die gevalle. Alles is baie eenvoudig hier: elke geval is 'n aparte systemd-diens. Ek praat van 'n voorbeeld:

$ systemctl start myapp@storage-1

Hierdie opdrag sal die instansie begin storage-1 programme myapp. Die geloodsde instansie sal na sy konfigurasie в /etc/tarantool/conf.d/. Instance logs kan bekyk word met behulp van journald.

Eenheid lêer /etc/systemd/system/[email protected] vir 'n stelseldiens sal saam met die pakket afgelewer word.

Ansible het ingeboude modules vir die installering van pakkette en die bestuur van stelseldienste, ons het niks nuuts hier uitgevind nie.

Die opstel van die trostopologie

En hier begin die interessantste. Stem saam, dit sal vreemd wees om te pla met 'n spesiale moontlike rol vir die installering van pakkette en hardloop systemd-dienste.

U kan die groep handmatig opstel:

Die eerste opsie: maak die web-UI oop en klik op die knoppies. Vir 'n eenmalige begin van verskeie gevalle is dit baie geskik.
Tweede opsie: jy kan die GraphQl API gebruik. Hier kan jy reeds iets outomatiseer, byvoorbeeld, skryf 'n skrif in Python.
Die derde opsie (vir die sterk van gees): gaan na die bediener, koppel aan een van die gevalle wat gebruik word tarantoolctl connect en voer al die nodige manipulasies met die Lua-module uit cartridge.

Die hooftaak van ons uitvinding is om dit te doen, die moeilikste deel van die werk vir jou.

Ansible laat jou toe om jou eie module te skryf en dit in 'n rol te gebruik. Ons rol gebruik hierdie modules om die verskillende komponente van die groepering te bestuur.

Hoe dit werk? Jy beskryf die verlangde toestand van die groepering in 'n verklarende konfigurasie, en die rol gee elke module sy konfigurasie-afdeling as invoer. Die module ontvang die huidige toestand van die groepering en vergelyk dit met die insette. Vervolgens word 'n kode deur die sok van een van die gevalle uitgevoer, wat die groepie na die verlangde toestand bring.

Resultate van

Ons het vandag vertel en gewys hoe om jou toepassing op Tarantool Cartridge te ontplooi en 'n eenvoudige topologie op te stel. Om dit te doen, het ons Ansible gebruik, 'n kragtige instrument wat maklik is om te gebruik en wat jou toelaat om gelyktydig baie infrastruktuur nodusse op te stel (in ons geval is dit groepgevalle).

Hierbo het ons een van die vele maniere behandel om die groepkonfigurasie met behulp van Ansible te beskryf. Sodra jy weet jy is gereed om aan te beweeg, leer beste praktyke vir die skryf van speelboeke. Jy sal dit dalk geriefliker vind om die topologie mee te bestuur group_vars и host_vars.

Ons sal jou binnekort vertel hoe om gevalle permanent uit die topologie te verwyder (verdryf), bootstrap vshard, outomatiese failover-modus te bestuur, magtiging op te stel en die groepkonfigurasie te herstel. Intussen kan jy op jou eie studeer dokumentasie en eksperimenteer met die verandering van die groepparameters.

As iets nie werk nie, maak seker inlig ons oor die probleem. Ons sal dit vinnig afbreek!

Bron: will.com

Ontplooi toepassings maklik en natuurlik op Tarantool-patroon (Deel 1)