Vi har redan pratat om Tarantool patron, som låter dig utveckla distribuerade applikationer och paketera dem. Det finns ingenting kvar: lär dig hur du distribuerar och hanterar dessa applikationer. Oroa dig inte, vi har tänkt på allt! Vi har sammanställt alla de bästa metoderna för att arbeta med Tarantool Cartridge och skrev ansible-roll, som kommer att dekomponera paketet till servrar, starta instanserna, kombinera dem till ett kluster, konfigurera auktorisering, bootstrap vshard, aktivera automatisk failover och korrigera klusterkonfigurationen.

Intressant? Då frågar jag under klippet, vi ska berätta och visa allt.

Låt oss börja med ett exempel

Vi kommer endast att täcka en del av funktionaliteten i vår roll. Du kan alltid hitta en fullständig beskrivning av alla dess funktioner och ingångsparametrar i dokumentation. Men det är bättre att prova en gång än att se hundra gånger, så låt oss distribuera en liten applikation.

Tarantool Cartridge har handledning att skapa en liten Cartridge-applikation som lagrar information om bankkunder och deras konton, och som även tillhandahåller ett API för att hantera data via HTTP. För att göra detta beskriver applikationen två möjliga roller: api и storagesom kan tilldelas till instanser.

Cartridge i sig säger inget om hur man startar processer, det ger bara möjlighet att konfigurera redan körande instanser. Användaren måste göra resten själv: dekomponera konfigurationsfilerna, starta tjänsterna och ställa in topologin. Men vi kommer inte att göra allt detta, Ansible kommer att göra det åt oss.

Från ord till handling

Så låt oss distribuera vår applikation till två virtuella maskiner och ställa in en enkel topologi:

Replicaset app-1 kommer att spela rollen apisom inkluderar rollen vshard-router. Det kommer bara att finnas en instans här.
replikuppsättning storage-1 implementerar rollen storage (och på samma gång vshard-storage), här lägger vi till två instanser från olika maskiner.

För att köra exemplet behöver vi Luffare и Ansible (version 2.8 eller senare).

Rollen i sig är Ansible Galaxy. Detta är ett arkiv som låter dig dela ditt arbete och använda färdiga roller.

Klona förvaret med ett exempel:

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

Vi tar upp virtuella maskiner:

$ vagrant up

Installera Tarantool Cartridge med följande roll:

$ ansible-galaxy install tarantool.cartridge,1.0.1

Kör den installerade rollen:

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

Vi väntar på slutet av utförandet av spelboken, gå till http://localhost:8181/admin/cluster/dashboard och njut av resultatet:

Du kan hälla data. Coolt, eller hur?

Låt oss nu ta reda på hur man arbetar med detta, och samtidigt lägga till ytterligare en replikuppsättning till topologin.

Vi börjar förstå

Så vad hände?

Vi fick två virtuella datorer igång och kör en lämplig spelbok som satte upp vårt kluster. Låt oss titta på innehållet i filen 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

Inget intressant händer här, vi börjar ansible-rollen, som kallas tarantool.cartridge.

Allt det viktigaste (nämligen klusterkonfigurationen) finns i lager-fil 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 vi behöver är att lära oss hur man hanterar instanser och replikuppsättningar genom att ändra innehållet i den här filen. Därefter kommer vi att lägga till nya sektioner till den. För att inte bli förvirrad var du ska lägga till dem kan du kika in i den slutliga versionen av den här filen, hosts.updated.yml, som finns i exempelarkivet.

Instanshantering

När det gäller Ansible är varje instans en värd (inte att förväxla med en järnserver), d.v.s. infrastrukturnoden som Ansible kommer att hantera. För varje värd kan vi ange anslutningsparametrar (som t.ex ansible_host и ansible_user), såväl som instanskonfigurationen. Beskrivning av instanser finns i avsnittet hosts.

Tänk på instanskonfigurationen storage-1:

all:
  vars:
    ...

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

  ...

I en variabel config vi specificerade instansparametrarna - advertise URI и HTTP port.
Nedan finns instansparametrarna app-1 и storage-1-replica.

Vi måste berätta för Ansible anslutningsparametrarna för varje instans. Det verkar logiskt att gruppera instanser i virtuella maskingrupper. För att göra detta kombineras instanser i grupper. host1 и host2, och i varje grupp i avsnittet vars värden ansible_host и ansible_user för en virtuell maskin. Och i avsnittet hosts - värdar (de är instanser) som ingår i denna grupp:

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 börjar förändras hosts.yml. Låt oss lägga till ytterligare två instanser, storage-2-replica på den första virtuella maskinen och storage-2 På den andra:

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

Kör ansible playbook:

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

Var uppmärksam på alternativet --limit. Eftersom varje klusterinstans är en värd i Ansible-termer, kan vi uttryckligen ange vilka instanser som ska konfigureras när man kör spelboken.

Tillbaka till webbgränssnittet http://localhost:8181/admin/cluster/dashboard och observera våra nya instanser:

Vi kommer inte att vila på våra lagrar och kommer att bemästra topologikontroll.

Topologihantering

Låt oss slå samman våra nya instanser till en replikuppsättning storage-2. Lägg till en ny grupp replicaset_storage_2 och beskriv i sina variabler parametrarna för replikuppsättningen i analogi med replicaset_storage_1. I avsnitt hosts ange vilka instanser som ska inkluderas i den här gruppen (det vill säga vår replikuppsättning):

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

Låt oss börja spelboken igen:

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

Per alternativ --limit vi passerade denna gång namnet på gruppen som motsvarar vår replikuppsättning.

Överväg alternativet tags.

Vår roll utför sekventiellt olika uppgifter, som är markerade med följande taggar:

cartridge-instances: instanshantering (konfiguration, anslutning till medlemskap);
cartridge-replicasets: topologihantering (hantering av replikuppsättningar och permanent borttagning (utvisa) av instanser från klustret);
cartridge-config: hantera andra klusterparametrar (vshard bootstrapping, automatiskt failover-läge, auktoriseringsparametrar och applikationskonfiguration).

Vi kan uttryckligen specificera vilken del av arbetet vi vill göra, sedan hoppar rollen över resten av uppgifterna. I vårt fall vill vi bara arbeta med topologin, så vi specificerade cartridge-replicasets.

Låt oss utvärdera resultatet av våra ansträngningar. Hittar en ny replikuppsättning http://localhost:8181/admin/cluster/dashboard.

Hurra!

Experimentera med att konfigurera om instanser och replikuppsättningar och se hur klustertopologin förändras. Du kan prova olika driftsscenarier, t.ex. rullande uppdatering eller öka memtx_memory. Rollen kommer att försöka göra detta utan att starta om instansen för att minska den eventuella stilleståndstiden för din applikation.

Glöm inte att springa vagrant haltför att stoppa virtuella datorer när du är klar med dem.

Vad finns under huven?

Här kommer jag att prata mer om vad som hände under huven på den ansible rollen under våra experiment.

Låt oss ta en titt på hur du distribuerar en Cartridge-applikation steg för steg.

Installera paketet och starta instanser

Först måste du leverera paketet till servern och installera det. Nu kan rollen fungera med RPM- och DEB-paket.

Därefter startar vi instanserna. Allt är väldigt enkelt här: varje instans är en separat systemd-service. Jag pratar om ett exempel:

$ systemctl start myapp@storage-1

Detta kommando kommer att starta instansen storage-1 appar myapp. Den lanserade instansen kommer att leta efter sin konfiguration в /etc/tarantool/conf.d/. Instansloggar kan ses med journald.

Enhetsfil /etc/systemd/system/[email protected] för en systemd tjänst kommer att levereras med paketet.

Ansible har inbyggda moduler för att installera paket och hantera systemtjänster, vi har inte hittat på något nytt här.

Konfigurera klustertopologin

Och här börjar det mest intressanta. Håller med, det skulle vara konstigt att bry sig om en speciell roll för att installera paket och köra systemd-tjänster.

Du kan ställa in klustret manuellt:

Det första alternativet: öppna webbgränssnittet och klicka på knapparna. För en engångsstart av flera instanser är det ganska lämpligt.
Andra alternativet: du kan använda GraphQl API. Här kan du redan automatisera något, till exempel skriva ett skript i Python.
Det tredje alternativet (för de starka i anden): gå till servern, anslut till en av instanserna som använder tarantoolctl connect och utför alla nödvändiga manipulationer med Lua-modulen cartridge.

Huvuduppgiften för vår uppfinning är att göra detta, den svåraste delen av arbetet för dig.

Ansible låter dig skriva din egen modul och använda den i en roll. Vår roll använder dessa moduler för att hantera de olika komponenterna i klustret.

Hur det fungerar? Du beskriver det önskade tillståndet för klustret i en deklarativ konfiguration, och rollen ger varje modul sin konfigurationssektion som indata. Modulen tar emot det aktuella tillståndet för klustret och jämför det med ingången. Därefter körs en kod genom sockeln på en av instanserna, vilket för klustret till önskat tillstånd.

Resultat av

Idag berättade och visade vi hur du distribuerar din applikation på Tarantool Cartridge och ställer in en enkel topologi. För att göra detta använde vi Ansible, ett kraftfullt verktyg som är lätt att använda och som låter dig konfigurera många infrastrukturnoder samtidigt (i vårt fall är dessa klusterinstanser).

Ovan behandlade vi ett av många sätt att beskriva klusterkonfigurationen med Ansible. När du vet att du är redo att gå vidare, lär dig bästa praxis för att skriva lekböcker. Du kanske tycker att det är bekvämare att hantera topologin med group_vars и host_vars.

Mycket snart kommer vi att berätta hur du permanent tar bort (utvisar) instanser från topologin, bootstrap vshard, hanterar automatiskt failover-läge, konfigurerar auktorisering och korrigerar klusterkonfigurationen. Under tiden kan du studera på egen hand dokumentation och experimentera med att ändra klusterparametrarna.

Om något inte fungerar, var säker underrätta oss om problemet. Vi bryter ner det snabbt!

Källa: will.com

Distribuera applikationer enkelt och naturligt på Tarantool-kassetten (del 1)