Vi har allerede talt om Tarantool patron, som giver dig mulighed for at udvikle distribuerede applikationer og pakke dem. Der er intet tilbage: Lær, hvordan du implementerer og administrerer disse applikationer. Bare rolig, vi har tænkt på alt! Vi har samlet alle de bedste fremgangsmåder for at arbejde med Tarantool Cartridge og skrevet ansible-rolle, som vil dekomponere pakken til servere, starte instanserne, kombinere dem til en klynge, konfigurere autorisation, bootstrap vshard, aktivere automatisk failover og patch klyngekonfigurationen.

Interessant? Så spørger jeg under snittet, vi fortæller og viser alt.

Lad os starte med et eksempel

Vi dækker kun en del af funktionaliteten af vores rolle. Du kan altid finde en komplet beskrivelse af alle dens funktioner og inputparametre i dokumentation. Men det er bedre at prøve én gang end at se hundrede gange, så lad os implementere en lille applikation.

Tarantool Cartridge har tutorial at lave en lille Cartridge-applikation, der gemmer oplysninger om bankkunder og deres konti, og som også giver en API til håndtering af data via HTTP. For at gøre dette beskriver applikationen to mulige roller: api и storageder kan tildeles til instanser.

Cartridge selv siger ikke noget om, hvordan man starter processer, det giver kun mulighed for at konfigurere allerede kørende forekomster. Brugeren skal selv klare resten: dekomponere konfigurationsfilerne, starte tjenesterne og opsætte topologien. Men vi vil ikke gøre alt dette, Ansible vil gøre det for os.

Fra ord til handling

Så lad os implementere vores applikation til to virtuelle maskiner og opsætte en simpel topologi:

Repliksæt app-1 vil spille rollen apisom inkluderer rollen vshard-router. Der vil kun være ét tilfælde her.
replikasæt storage-1 implementerer rollen storage (og på samme tid vshard-storage), her tilføjer vi to forekomster fra forskellige maskiner.

For at køre eksemplet har vi brug for vagabond и Ansible (version 2.8 eller nyere).

Selve rollen er Ansible Galaxy. Dette er et lager, der giver dig mulighed for at dele dit arbejde og bruge færdige roller.

Klon depotet med et eksempel:

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

Vi laver virtuelle maskiner:

$ vagrant up

Installer Tarantool-patronen med følgende rolle:

$ ansible-galaxy install tarantool.cartridge,1.0.1

Kør den installerede rolle:

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

Vi venter på slutningen af udførelsen af playbook, gå til http://localhost:8181/admin/cluster/dashboard og nyd resultatet:

Du kan hælde data. Fedt, ikke?

Lad os nu finde ud af, hvordan man arbejder med dette, og samtidig tilføje endnu et replikasæt til topologien.

Vi begynder at forstå

Hvad skete der?

Vi fik to VM'er op at køre en mulig playbook, der satte vores klynge op. Lad os se på indholdet af 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

Der sker ikke noget interessant her, vi starter ansible-rollen, som kaldes tarantool.cartridge.

Alt det vigtigste (nemlig klyngekonfigurationen) er placeret i opgørelse-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:

Alt, hvad vi behøver, er at lære, hvordan man administrerer forekomster og replikasæt ved at ændre indholdet af denne fil. Dernæst vil vi tilføje nye sektioner til det. For ikke at blive forvirret, hvor du skal tilføje dem, kan du kigge ind i den endelige version af denne fil, hosts.updated.yml, som er i eksempellageret.

Forekomststyring

Med hensyn til Ansible er hver instans en vært (ikke at forveksle med en jernserver), dvs. den infrastrukturknude, som Ansible skal administrere. For hver vært kan vi angive forbindelsesparametre (såsom ansible_host и ansible_user), samt instanskonfigurationen. Beskrivelse af instanser findes i afsnittet hosts.

Overvej 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 specificerede instansparametrene - advertise URI и HTTP port.
Nedenfor er instansparametrene app-1 и storage-1-replica.

Vi skal fortælle Ansible forbindelsesparametrene for hver instans. Det virker logisk at gruppere forekomster i virtuelle maskingrupper. For at gøre dette kombineres instanser i grupper. host1 и host2, og i hver gruppe i afsnittet vars værdier ansible_host и ansible_user for én virtuel maskine. Og i afsnittet hosts - værter (de er forekomster), der er inkluderet i denne gruppe:

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 begynder at ændre os hosts.yml. Lad os tilføje yderligere to tilfælde, storage-2-replica på den første virtuelle maskine og storage-2 På den anden:

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 en mulig spillebog:

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

Vær opmærksom på muligheden --limit. Da hver klyngeforekomst er en vært i Ansible-termer, kan vi eksplicit angive, hvilke forekomster der skal konfigureres, når playbooken køres.

Tilbage til Web UI http://localhost:8181/admin/cluster/dashboard og observer vores nye forekomster:

Vi vil ikke hvile på laurbærrene og vil mestre topologikontrol.

Topologistyring

Lad os flette vores nye forekomster sammen til et replikasæt storage-2. Tilføj en ny gruppe replicaset_storage_2 og beskrive i sine variabler parametrene for replikasettet i analogi med replicaset_storage_1. I afsnittet hosts angiv, hvilke forekomster der skal inkluderes i denne gruppe (det vil sige vores replikasæt):

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

Lad os starte spillebogen igen:

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

Per mulighed --limit vi passerede denne gang navnet på den gruppe, der svarer til vores replikasæt.

Overvej muligheden tags.

Vores rolle udfører sekventielt forskellige opgaver, som er markeret med følgende tags:

cartridge-instances: instansstyring (konfiguration, forbindelse til medlemskab);
cartridge-replicasets: topologistyring (administration af replikasæt og permanent fjernelse (udvisning) af forekomster fra klyngen);
cartridge-config: administrer andre klyngeparametre (vshard bootstrapping, automatisk failover-tilstand, autorisationsparametre og applikationskonfiguration).

Vi kan udtrykkeligt angive, hvilken del af arbejdet vi vil udføre, så springer rollen over resten af opgaverne. I vores tilfælde ønsker vi kun at arbejde med topologien, så vi specificerede cartridge-replicasets.

Lad os evaluere resultatet af vores indsats. Finder et nyt repliksæt http://localhost:8181/admin/cluster/dashboard.

Hurra!

Eksperimenter med at omkonfigurere forekomster og replikasæt, og se, hvordan klyngetopologien ændrer sig. Du kan prøve forskellige operationelle scenarier, f.eks. rullende opdatering eller stige memtx_memory. Rollen vil forsøge at gøre dette uden at genstarte instansen for at reducere den mulige nedetid for din applikation.

Glem ikke at løbe vagrant haltat stoppe VM'er, når du er færdig med dem.

Og hvad er der under motorhjelmen?

Her vil jeg fortælle mere om, hvad der skete under hætten af den ansible rolle under vores eksperimenter.

Lad os tage et kig på implementeringen af en Cartridge-applikation trin for trin.

Installation af pakken og startforekomster

Først skal du levere pakken til serveren og installere den. Nu kan rollen arbejde med RPM- og DEB-pakker.

Dernæst starter vi forekomsterne. Alt er meget enkelt her: hver instans er en separat systemd-service. Jeg taler om et eksempel:

$ systemctl start myapp@storage-1

Denne kommando vil starte instansen storage-1 приложения myapp. Den lancerede instans vil lede efter sin konfiguration в /etc/tarantool/conf.d/. Forekomstlogfiler kan ses vha journald.

Enhedsfil /etc/systemd/system/[email protected] for en systemd service vil blive leveret med pakken.

Ansible har indbyggede moduler til at installere pakker og administrere systemd services, vi har ikke opfundet noget nyt her.

Konfiguration af klyngetopologien

Og her begynder det mest interessante. Enig, det ville være mærkeligt at bøvle med en særlig ansible-rolle til at installere pakker og køre systemd-tjenester.

Du kan konfigurere klyngen manuelt:

Den første mulighed: Åbn Web UI og klik på knapperne. Til en engangsstart af flere tilfælde er det ganske velegnet.
Anden mulighed: du kan bruge GraphQl API. Her kan du allerede automatisere noget, for eksempel skrive et script i Python.
Den tredje mulighed (for de stærke i ånden): gå til serveren, opret forbindelse til en af de instanser, der bruger tarantoolctl connect og udfør alle de nødvendige manipulationer med Lua-modulet cartridge.

Hovedopgaven for vores opfindelse er at gøre dette, den sværeste del af arbejdet for dig.

Ansible giver dig mulighed for at skrive dit eget modul og bruge det i en rolle. Vores rolle bruger disse moduler til at styre de forskellige komponenter i klyngen.

Hvordan det virker? Du beskriver den ønskede tilstand for klyngen i en deklarativ konfiguration, og rollen giver hvert modul sin konfigurationssektion som input. Modulet modtager den aktuelle tilstand for klyngen og sammenligner den med inputtet. Dernæst køres en kode gennem soklen på en af instanserne, som bringer klyngen til den ønskede tilstand.

Resultaterne af

I dag fortalte og viste vi, hvordan du implementerer din applikation på Tarantool Cartridge og opsætter en simpel topologi. For at gøre dette brugte vi Ansible, et kraftfuldt værktøj, der er nemt at bruge og giver dig mulighed for samtidigt at konfigurere mange infrastrukturnoder (i vores tilfælde er disse klyngeforekomster).

Ovenfor har vi behandlet en af de mange måder at beskrive klyngekonfigurationen ved hjælp af Ansible. Når du ved, at du er klar til at komme videre, så lær bedste praksis til at skrive spillebøger. Du kan finde det mere bekvemt at styre topologien med group_vars и host_vars.

Meget snart vil vi fortælle dig, hvordan du permanent fjerner (udviser) forekomster fra topologien, bootstrap vshard, administrerer automatisk failover-tilstand, konfigurerer autorisation og patcher klyngekonfigurationen. I mellemtiden kan du studere på egen hånd dokumentation og eksperimentere med at ændre klyngeparametrene.

Hvis noget ikke virker, så vær sikker informere os om problemet. Vi nedbryder det hurtigt!

Kilde: www.habr.com

Implementering af applikationer nemt og naturligt på Tarantool Cartridge (del 1)