Vi har allerede snakket om Tarantool-kassett, som lar deg utvikle distribuerte applikasjoner og pakke dem. Alt som gjenstår er å lære hvordan du distribuerer disse applikasjonene og administrerer dem. Ikke bekymre deg, vi har alt! Vi satte sammen alle de beste fremgangsmåtene for å jobbe med Tarantool Cartridge og skrev ansible-rolle, som vil distribuere pakken til servere, starte forekomster, kombinere dem til en klynge, konfigurere autorisasjon, bootstrap vshard, aktivere automatisk failover og lappe klyngekonfigurasjonen.

Interessant? Så vær så snill, under snittet, vil vi fortelle deg og vise deg alt.

La oss starte med et eksempel

Vi skal kun se på en del av funksjonaliteten til rollen vår. Du kan alltid finne en fullstendig beskrivelse av alle funksjonene og inngangsparameterne i dokumentasjon. Men det er bedre å prøve en gang enn å se det hundre ganger, så la oss distribuere en liten applikasjon.

Tarantool Cartridge har opplæringen å lage en liten Cartridge-applikasjon som lagrer informasjon om bankkunder og deres kontoer, og som også gir et API for databehandling via HTTP. For å oppnå dette beskriver vedlegget to mulige roller: api и storage, som kan tilordnes til forekomster.

Cartridge i seg selv sier ikke noe om hvordan man starter prosesser, den gir kun muligheten til å konfigurere allerede kjørende forekomster. Brukeren må gjøre resten selv: ordne konfigurasjonsfiler, starte tjenester og konfigurere topologien. Men vi vil ikke gjøre alt dette; Ansible vil gjøre det for oss.

Fra ord til handling

Så la oss distribuere applikasjonen vår til to virtuelle maskiner og sette opp en enkel topologi:

Replikasett app-1 vil implementere rollen api, som inkluderer rollen vshard-router. Det vil bare være ett tilfelle her.
Replikasett storage-1 implementerer rollen storage (og samtidig vshard-storage), her vil vi legge til to forekomster fra forskjellige maskiner.

For å kjøre eksemplet vi trenger vagrant и Ansible (versjon 2.8 eller eldre).

Selve rollen er inne Ansible Galaxy. Dette er et arkiv som lar deg dele arbeidet ditt og bruke ferdige roller.

La oss klone 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 lager virtuelle maskiner:

$ vagrant up

Installer Tarantool-kassetten med følgende rolle:

$ ansible-galaxy install tarantool.cartridge,1.0.1

Start den installerte rollen:

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

Vi venter på at spilleboken skal fullføre utførelse, gå til http://localhost:8181/admin/cluster/dashboard og nyt resultatet:

Du kan laste opp data. Kult, ikke sant?

La oss nå finne ut hvordan vi jobber med dette, og samtidig legge til et annet replikasett til topologien.

La oss begynne å finne ut av det

Så hva skjedde?

Vi satte opp to virtuelle maskiner og lanserte en mulig spillebok som konfigurerte klyngen vår. La oss se på innholdet 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

Ingenting interessant skjer her, la oss lansere en ansible rolle kalt tarantool.cartridge.

Alle de viktigste tingene (nemlig klyngekonfigurasjonen) er plassert i inventar-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 vi trenger er å lære å administrere forekomster og replikasett ved å endre innholdet i denne filen. Deretter vil vi legge til nye seksjoner til den. For ikke å bli forvirret hvor du skal legge dem til, kan du se på den endelige versjonen av denne filen, hosts.updated.yml, som er i eksempellageret.

Forekomstbehandling

I Ansible-termer er hver instans en vert (ikke å forveksle med en maskinvareserver), dvs. infrastrukturnoden som Ansible skal administrere. For hver vert kan vi spesifisere tilkoblingsparametere (som f.eks ansible_host и ansible_user), samt forekomstkonfigurasjonen. Beskrivelse av instanser er i avsnittet hosts.

La oss se på forekomstkonfigurasjonen storage-1:

all:
  vars:
    ...

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

  ...

I en variabel config vi spesifiserte forekomstparametrene - advertise URI и HTTP port.
Nedenfor er instansparameterne app-1 и storage-1-replica.

Vi må fortelle Ansible tilkoblingsparametrene for hver forekomst. Det virker logisk å gruppere forekomster i virtuelle maskingrupper. For dette formålet kombineres forekomster i grupper host1 и host2, og i hver gruppe i seksjonen vars verdier er angitt ansible_host и ansible_user for én virtuell maskin. Og i seksjonen hosts — verter (aka forekomster) som er inkludert i denne gruppen:

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 begynner å forandre oss hosts.yml. La oss legge til ytterligere to tilfeller, storage-2-replica på den første virtuelle maskinen og storage-2 På den andre:

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

Start den aktuelle lekeboken:

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

Vær oppmerksom på alternativet --limit. Siden hver klyngeforekomst er en vert i Ansible-termer, kan vi eksplisitt spesifisere hvilke forekomster som skal konfigureres når spilleboken kjøres.

Går tilbake til nettgrensesnittet http://localhost:8181/admin/cluster/dashboard og se våre nye forekomster:

La oss ikke stoppe der og mestre topologistyring.

Topologistyring

La oss kombinere våre nye instanser til et replikasett storage-2. La oss legge til en ny gruppe replicaset_storage_2 og beskrive replikasett-parametrene i variablene i analogi med replicaset_storage_1. I seksjon hosts La oss indikere hvilke forekomster som vil bli inkludert i denne gruppen (det vil si replikasettet vårt):

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

La oss starte lekeboken igjen:

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

I parameter --limit Denne gangen passerte vi navnet på gruppen som tilsvarer replikasettet vårt.

La oss vurdere alternativet tags.

Vår rolle utfører sekvensielt ulike oppgaver, som er merket med følgende tagger:

cartridge-instances: instansbehandling (konfigurasjon, tilkobling til medlemskap);
cartridge-replicasets: topologistyring (administrasjon av replikasett og permanent fjerning (utvisning) av forekomster fra klyngen);
cartridge-config: administrasjon av andre klyngeparametere (vshard bootstrapping, automatisk failover-modus, autorisasjonsparametere og applikasjonskonfigurasjon).

Vi kan spesifisere eksplisitt hvilken del av arbeidet vi ønsker å gjøre, så vil rollen hoppe over resten av oppgavene. I vårt tilfelle vil vi kun jobbe med topologien, så vi spesifiserte cartridge-replicasets.

La oss evaluere resultatet av vår innsats. Vi finner et nytt replikasett på http://localhost:8181/admin/cluster/dashboard.

Hurra!

Eksperimenter med å endre konfigurasjonen av forekomster og replikasett og se hvordan klyngetopologien endres. Du kan prøve ut ulike operasjonsscenarier, f.eks. rullerende oppdatering eller øke memtx_memory. Rollen vil prøve å gjøre dette uten å starte instansen på nytt for å redusere mulig nedetid for applikasjonen din.

Ikke glem å løpe vagrant haltfor å stoppe de virtuelle maskinene når du er ferdig med å jobbe med dem.

Hva er under panseret?

Her vil jeg fortelle deg mer om hva som skjedde under panseret til den ansible rollen under våre eksperimenter.

La oss se på distribusjon av Cartridge-applikasjonen trinn for trinn.

Installere pakken og starte forekomster

Først må du levere pakken til serveren og installere den. Foreløpig kan rollen jobbe med RPM- og DEB-pakker.

Deretter starter vi forekomstene. Alt er veldig enkelt her: hver forekomst er en separat systemd-service. Jeg skal gi deg et eksempel:

$ systemctl start myapp@storage-1

Denne kommandoen vil starte forekomsten storage-1 приложения myapp. Den lanserte forekomsten vil se etter sin konfigurasjon в /etc/tarantool/conf.d/. Forekomstlogger kan sees ved hjelp av journald.

Enhetsfil /etc/systemd/system/[email protected] for systemd-tjenesten vil bli levert sammen med pakken.

Ansible har innebygde moduler for å installere pakker og administrere systemtjenester; vi har ikke funnet opp noe nytt her.

Sette opp en klyngetopologi

Det er her moroa begynner. Enig, det ville være rart å bry seg med en spesiell Ansible-rolle for å installere pakker og kjøre systemd-tjenester.

Du kan konfigurere klyngen manuelt:

Første alternativ: åpne nettgrensesnittet og klikk på knappene. Det er ganske egnet for en engangsstart av flere tilfeller.
Andre alternativ: du kan bruke GraphQl API. Her kan du allerede automatisere noe, for eksempel skrive et skript i Python.
Tredje alternativ (for de viljesterke): gå til serveren, koble til en av forekomstene som bruker tarantoolctl connect og utfør alle nødvendige manipulasjoner med Lua-modulen cartridge.

Hovedoppgaven til vår oppfinnelse er å gjøre akkurat dette, den vanskeligste delen av arbeidet for deg.

Ansible lar deg skrive din egen modul og bruke den i en rolle. Vår rolle bruker slike moduler for å administrere ulike klyngekomponenter.

Hvordan det fungerer? Du beskriver ønsket tilstand for klyngen i en deklarativ konfigurasjon, og rollen gir hver modul sin konfigurasjonsseksjon som input. Modulen mottar den nåværende tilstanden til klyngen og sammenligner den med det som ble mottatt som input. Deretter lanseres en kode gjennom kontakten til en av forekomstene, som bringer klyngen til ønsket tilstand.

Resultater av

I dag fortalte vi og viste hvordan du distribuerer applikasjonen din til Tarantool Cartridge og setter opp en enkel topologi. For å gjøre dette brukte vi Ansible - et kraftig verktøy som er enkelt å bruke og lar deg konfigurere mange infrastrukturnoder samtidig (i vårt tilfelle klyngeforekomster).

Ovenfor så vi på en av de mange måtene å beskrive en klyngekonfigurasjon ved å bruke Ansible. Når du føler deg klar til å gå videre, utforske beste praksis på å skrive lekebøker. Du kan finne det lettere å administrere topologien din ved å bruke group_vars и host_vars.

Svært snart vil vi fortelle deg hvordan du permanent sletter (utviser) forekomster fra topologien, bootstrap vshard, administrerer automatisk failover-modus, konfigurerer autorisasjon og lapper klyngekonfigurasjonen. I mellomtiden kan du studere på egenhånd dokumentasjon og eksperimentere med å endre klyngeparametere.

Hvis noe ikke fungerer, sørg for å gjøre det gi meg beskjed oss om problemet. Vi ordner alt raskt!

Kilde: www.habr.com

Distribuer applikasjoner enkelt og naturlig til Tarantool Cartridge (del 1)