Avemu digià parlatu Cartuccia Tarantool, chì vi permette di sviluppà applicazioni distribuite è imballate. Ùn ci hè nunda: amparate cumu implementà è gestisce queste applicazioni. Ùn vi preoccupate, avemu pensatu à tuttu ! Avemu riunitu tutte e migliori pratiche per travaglià cù Tarantool Cartridge è hà scrittu rolu ansible, chì scompone u pacchettu in servitori, avvia l'istanze, combina in un cluster, cunfigurà l'autorizazione, bootstrap vshard, attivà u failover automaticu è patcheghja a cunfigurazione di cluster.

Interessante? Allora dumandu sottu à u tagliu, cuntaremu è mustrà tuttu.

Cuminciamu cù un esempiu

Copremu solu una parte di e funziunalità di u nostru rolu. Pudete sempre truvà una descrizzione cumpleta di tutte e so caratteristiche è i paràmetri di input in ducumentazione. Ma hè megliu à pruvà una volta chè vede centu volte, cusì mettimu una piccula applicazione.

Cartuccia Tarantool hà tutoriale per creà una piccula applicazione Cartuccia chì guarda l'infurmazioni nantu à i clienti bancari è i so cunti, è furnisce ancu una API per a gestione di dati via HTTP. Per fà questu, l'applicazione descrive dui roli pussibuli: api и storagechì pò esse attribuitu à l'istanze.

Cartuccia stessu ùn dice nunda di cumu inizià i prucessi, furnisce solu l'abilità di cunfigurà istanze digià in esecuzione. L'utilizatore deve fà u restu stessu: decompone i schedarii di cunfigurazione, inizià i servizii è stabilisce a topologia. Ma ùn faremu micca tuttu questu, Ansible a farà per noi.

Da e parolle à l'atti

Allora, implementemu a nostra applicazione à duie macchine virtuali è cunfigurà una topologia simplice:

Replicaset app-1 ghjucà u rolu apichì include u rolu vshard-router. Ci sarà solu un esempiu quì.
replicaset storage-1 implementa u rolu storage (è à u listessu tempu vshard-storage), quì aghjunghjemu dui istanze da diverse macchine.

Per fà l'esempiu, avemu bisognu Vagante и Ansible (versione 2.8 o più tardi).

U rolu stessu hè Galassia Ansible. Questu hè un repository chì vi permette di sparte u vostru travagliu è aduprà roli pronti.

Clone u repository cù un esempiu:

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

Creemu macchine virtuali:

$ vagrant up

Installa u rolu ansible di Cartuccia Tarantool:

$ ansible-galaxy install tarantool.cartridge,1.0.1

Eseguite u rolu installatu:

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

Aspittemu a fine di l'esekzione di u playbook, andate à http://localhost:8181/admin/cluster/dashboard è gode u risultatu:

Pudete versà dati. Cool, nò?

Avà capimu cumu travaglià cù questu, è à u stessu tempu aghjunghje una altra replica set à a topologia.

Cuminciamu à capisce

Allora chì hè accadutu ?

Avemu duie VM in esecuzione è un libru di ghjocu ansible chì hà stallatu u nostru cluster. Fighjemu u cuntenutu di u schedariu 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

Nunda interessante succede quì, avemu principiatu u ansible-role, chì hè chjamatu tarantool.cartridge.

Tuttu u più impurtante (vale à dì, a cunfigurazione di cluster) si trova in Invintariu- schedariu 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:

Tuttu ciò chì avemu bisognu hè d'amparà cumu gestisce e istanze è replicasets cambiendu u cuntenutu di stu schedariu. In seguitu, aghjusteremu novi sezioni. Per ùn esse cunfusu induve aghjunghje, pudete spiegà a versione finale di stu schedariu, hosts.updated.yml, chì hè in u repositoriu di esempiu.

Gestione d'istanze

In termini di Ansible, ogni istanza hè un òspite (per ùn esse cunfunditu cù un servitore di ferru), i.e. u node di l'infrastruttura chì Ansible hà da gestisce. Per ogni òspite, pudemu specificà i paràmetri di cunnessione (cum'è ansible_host и ansible_user), è ancu a cunfigurazione di l'istanza. A descrizzione di i casi hè in a sezione hosts.

Cunsiderate a cunfigurazione di l'istanza storage-1:

all:
  vars:
    ...

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

  ...

In una variabile config avemu specificatu i paràmetri di l'istanza - advertise URI и HTTP port.
Sottu sò i paràmetri di istanza app-1 и storage-1-replica.

Avemu bisognu di dì à Ansible i paràmetri di cunnessione per ogni istanza. Sembra logicu di raggruppà istanze in gruppi di macchine virtuali. Per fà questu, i casi sò cumminati in gruppi. host1 и host2, è in ogni gruppu in a rùbbrica vars valori ansible_host и ansible_user per una macchina virtuale. È in a rùbbrica hosts - hosts (sò istanze) chì sò inclusi in stu gruppu:

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:

Cuminciamu à cambià hosts.yml. Aghjunghjemu duie altre istanze, storage-2-replica nantu à a prima macchina virtuale è storage-2 À u sicondu:

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

Eseguite ansible playbook:

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

Attenti à l'opzione --limit. Siccomu ogni istanza di cluster hè un òspite in termini Ansible, pudemu spicificà esplicitamente quale istanze deve esse cunfigurate quandu eseguisce u playbook.

Torna à u Web UI http://localhost:8181/admin/cluster/dashboard è osservate i nostri novi casi:

Ùn avemu micca riposu nantu à i nostri allori è dominaremu u cuntrollu di topulugia.

Gestione di topulugia

Unisce i nostri novi istanze in un replicaset storage-2. Aghjunghjemu un novu gruppu replicaset_storage_2 è descrive in i so variàbili i paràmetri di u replicaset per analogia cù replicaset_storage_1. In rùbbrica hosts specificate quali istanze seranu incluse in stu gruppu (vale à dì, u nostru settore di replica):

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

Cuminciamu di novu u playbook:

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

Per opzione --limit sta volta avemu passatu u nome di u gruppu chì currisponde à a nostra replicaset.

Cunsiderate l'opzione tags.

U nostru rolu in sequenza esegue diverse attività, chì sò marcate cù e seguenti tag:

cartridge-instances: gestione di l'istanza (configurazione, cunnessione à l'appartenenza);
cartridge-replicasets: gestione di topologia (gestione di replicaset è rimozione permanente (espulsione) di istanze da u cluster);
cartridge-config: gestisce altri parametri di cluster (vshard bootstrapping, modalità di failover automaticu, paràmetri d'autorizazione è cunfigurazione di l'applicazione).

Pudemu spicificà esplicitamente quale parte di u travagliu vulemu fà, allora u rolu saltarà u restu di i travaglii. In u nostru casu, vulemu travaglià solu cù a topologia, cusì avemu specificatu cartridge-replicasets.

Evaluemu u risultatu di i nostri sforzi. Truvà una nova replicaset http://localhost:8181/admin/cluster/dashboard.

Chants!

Pruvate cun cunfigurà istanze è replicasets è vede cumu cambia a topologia di cluster. Pudete pruvà diverse scenarii operativi, per esempiu, aghjurnamentu rolling o cresce memtx_memory. U rolu hà da pruvà à fà questu senza riavvia l'istanza per riduce u pussibule downtime di a vostra applicazione.

Ùn vi scurdate di curriri vagrant haltper piantà VMs quandu avete finitu cun elli.

Chì ci hè sottu à u cappucciu?

Quì parraraghju più nantu à ciò chì hè accadutu sottu u cappucciu di u rolu ansible durante i nostri esperimenti.

Fighjemu un ochju à implementà una applicazione Cartuccia passu per passu.

Installazione di u pacchettu è istanze di partenza

Prima vi tocca à purtà u pacchettu à u servitore è stallà lu. Avà u rolu pò travaglià cù i pacchetti RPM è DEB.

In seguitu, lanciamu i casi. Tuttu hè assai simplice quì: ogni istanza hè un separatu systemd- serviziu. Parlu di un esempiu:

$ systemctl start myapp@storage-1

Stu cumanda lanciarà l'istanza storage-1 Apps myapp. L'istanza lanciata cercà u so cunfigurazione в /etc/tarantool/conf.d/. I logs d'istanza ponu esse vistu cù l'usu journald.

File di unità /etc/systemd/system/[email protected] per un serviziu systemd serà furnitu cù u pacchettu.

Ansible hà moduli integrati per installà pacchetti è gestione di servizii di sistema, ùn avemu micca inventatu nunda di novu quì.

Configurazione di a topologia di cluster

E quì principia u più interessante. D'accordu, saria stranu per fastidiu cun un rolu speciale ansible per installà i pacchetti è in esecuzione systemd-servizii.

Pudete cunfigurà u cluster manualmente:

A prima opzione: apre u Web UI è cliccate nantu à i buttoni. Per un principiu una volta di parechji casi, hè abbastanza adattatu.
Siconda opzione: pudete aduprà l'API GraphQl. Quì pudete digià automatizà qualcosa, per esempiu, scrive un script in Python.
A terza opzione (per i forti in spiritu): andate à u servitore, cunnette à una di l'istanze chì utilizanu tarantoolctl connect è eseguisce tutte e manipulazioni necessarie cù u modulu Lua cartridge.

U compitu principale di a nostra invenzione hè di fà questu, a parte più difficiule di u travagliu per voi.

Ansible vi permette di scrive u vostru propiu modulu è l'utilizanu in un rolu. U nostru rolu usa sti moduli per gestisce i diversi cumpunenti di u cluster.

Cumu funziona? Descrive u statu desideratu di u cluster in una cunfigurazione dichjarazione, è u rolu dà à ogni modulu a so sezione di cunfigurazione cum'è input. U modulu riceve u statu attuale di u cluster è paragunà cù l'input. In seguitu, un codice hè eseguitu à traversu u socket di unu di i casi, chì porta u cluster à u statu desideratu.

Risultati

Oghje avemu dettu è dimustratu cumu implementà a vostra applicazione in Tarantool Cartridge è stabilisce una topologia simplice. Per fà questu, avemu usatu Ansible, un strumentu putente chì hè faciule d'utilizà è permette di cunfigurà simultaneamente parechji nodi di l'infrastruttura (in u nostru casu, questi sò casi di cluster).

Sopra, avemu trattatu una di e parechje manere di discrive a cunfigurazione di cluster cù Ansible. Una volta chì sapete chì site prontu à passà, amparà pratichi megghiu per scrive libri di ghjocu. Pudete truvà più còmuda di gestisce a topologia cun group_vars и host_vars.

Moltu prestu vi diciaremu cumu sguassate permanentemente (espulsione) istanze da a topologia, bootstrap vshard, gestisce u modu di failover automaticu, cunfigurà l'autorizazione è patch a cunfigurazione di cluster. Intantu, pudete studià nantu à u vostru propiu documentazione è sperimentà cù cambià i paràmetri di u cluster.

Se qualcosa ùn viaghja micca, assicuratevi informà noi circa u prublema. A sparteremu prestu !

Source: www.habr.com

Implementazione di l'applicazioni facilmente è naturali nantu à a cartuccia Tarantool (Parte 1)