Ne abbiamo già parlato , che consente di sviluppare applicazioni distribuite e crearne pacchetti. Non è rimasto nulla: scopri come distribuire e gestire queste applicazioni. Non preoccuparti, abbiamo pensato a tutto! Abbiamo messo insieme tutte le migliori pratiche per lavorare con Tarantool Cartridge e scritto , che scomporrà il pacchetto in server, avvierà le istanze, le combinerà in un cluster, configurerà l'autorizzazione, bootstrap vshard, abiliterà il failover automatico e correggerà la configurazione del cluster.
Interessante? Poi chiedo sotto il taglio, racconteremo e mostreremo tutto.
Iniziamo con un esempio
Copriremo solo una parte della funzionalità del nostro ruolo. Puoi sempre trovare una descrizione completa di tutte le sue caratteristiche e parametri di input in . Ma è meglio provare una volta che vedere cento volte, quindi distribuiamo una piccola applicazione.
Cartuccia Tarantool ha per creare una piccola applicazione Cartridge che memorizzi informazioni sui clienti della banca e sui loro conti e fornisca anche un'API per la gestione dei dati tramite HTTP. Per fare ciò, l'applicazione descrive due possibili ruoli: api и storageche possono essere assegnati alle istanze.
La cartuccia stessa non dice nulla su come avviare i processi, fornisce solo la possibilità di configurare istanze già in esecuzione. L'utente deve fare il resto da solo: decomporre i file di configurazione, avviare i servizi e configurare la topologia. Ma non faremo tutto questo, Ansible lo farà per noi.
Dalle parole ai fatti
Quindi, distribuiamo la nostra applicazione su due macchine virtuali e impostiamo una topologia semplice:
- Set di repliche
app-1interpreterà il ruoloapiche include il ruolovshard-router. Ci sarà solo un'istanza qui. - set di repliche
storage-1implementa il ruolostorage(e allo stesso tempovshard-storage), qui aggiungiamo due istanze da macchine diverse.
Per eseguire l'esempio, abbiamo bisogno di и (versione 2.8 o successiva).
Il ruolo stesso è . Questo è un repository che ti consente di condividere il tuo lavoro e utilizzare ruoli già pronti.
Clonare il repository con un esempio:
$ git clone https://github.com/dokshina/deploy-tarantool-cartridge-app.git
$ cd deploy-tarantool-cartridge-app && git checkout 1.0.0Alleviamo macchine virtuali:
$ vagrant upInstalla il ruolo ansible della cartuccia Tarantool:
$ ansible-galaxy install tarantool.cartridge,1.0.1Esegui il ruolo installato:
$ ansible-playbook -i hosts.yml playbook.ymlStiamo aspettando la fine dell'esecuzione del playbook, vai a e goditi il risultato:
Puoi versare dati. Fantastico, vero?
Ora scopriamo come lavorare con questo e allo stesso tempo aggiungiamo un altro set di repliche alla topologia.
Iniziamo a capire
Allora, cos'è successo?
Abbiamo messo in funzione due VM e un playbook ansible che ha configurato il nostro cluster. Diamo un'occhiata al contenuto del file 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.cartridgeNon succede nulla di interessante qui, iniziamo il ruolo ansible, che si chiama tarantool.cartridge.
Tutto il più importante (ovvero la configurazione del cluster) si trova in -file 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:Tutto ciò di cui abbiamo bisogno è imparare a gestire istanze e set di repliche modificando il contenuto di questo file. Successivamente, aggiungeremo nuove sezioni ad esso. Per non confonderti su dove aggiungerli, puoi sbirciare nella versione finale di questo file, hosts.updated.yml, che si trova nel repository di esempio.
Gestione delle istanze
In termini di Ansible, ogni istanza è un host (da non confondere con un server di ferro), ovvero il nodo dell'infrastruttura che Ansible gestirà. Per ogni host, possiamo specificare i parametri di connessione (come ansible_host и ansible_user), così come la configurazione dell'istanza. La descrizione delle istanze è nella sezione hosts.
Considera la configurazione dell'istanza storage-1:
all:
vars:
...
# INSTANCES
hosts:
storage-1:
config:
advertise_uri: '172.19.0.2:3301'
http_port: 8181
...In una variabile config abbiamo specificato i parametri dell'istanza - advertise URI и HTTP port.
Di seguito sono riportati i parametri dell'istanza app-1 и storage-1-replica.
Dobbiamo comunicare ad Ansible i parametri di connessione per ogni istanza. Sembra logico raggruppare le istanze in gruppi di macchine virtuali. Per fare ciò, le istanze vengono combinate in gruppi. host1 и host2e in ogni gruppo della sezione vars valori ansible_host и ansible_user per una macchina virtuale. E nella sezione hosts - host (sono istanze) inclusi in questo gruppo:
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:Iniziamo a cambiare hosts.yml. Aggiungiamo altre due istanze, storage-2-replica sulla prima macchina virtuale e storage-2 Sul secondo:
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: # <==
...Esegui playbook ansible:
$ ansible-playbook -i hosts.yml
--limit storage-2,storage-2-replica
playbook.ymlPrestare attenzione all'opzione --limit. Poiché ogni istanza del cluster è un host in termini Ansible, possiamo specificare esplicitamente quali istanze devono essere configurate durante l'esecuzione del playbook.
Torna all'interfaccia utente Web e osserva le nostre nuove istanze:
Non riposeremo sugli allori e domineremo il controllo della topologia.
Gestione della topologia
Uniamo le nostre nuove istanze in un set di repliche storage-2. Aggiungi un nuovo gruppo replicaset_storage_2 e descrivere nelle sue variabili i parametri del replicaset per analogia con replicaset_storage_1. Nella sezione hosts specifica quali istanze saranno incluse in questo gruppo (ovvero, il nostro set di repliche):
---
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:Ricominciamo il playbook:
$ ansible-playbook -i hosts.yml
--limit replicaset_storage_2
--tags cartridge-replicasets
playbook.ymlNel parametro --limit questa volta abbiamo passato il nome del gruppo che corrisponde al nostro replicaset.
Considera l'opzione tags.
Il nostro ruolo esegue in sequenza varie attività, contrassegnate dai seguenti tag:
cartridge-instances: gestione dell'istanza (configurazione, connessione all'appartenenza);cartridge-replicasets: gestione della topologia (gestione del replicaset e rimozione permanente (espulsione) delle istanze dal cluster);cartridge-config: gestisce altri parametri del cluster (bootstrapping vshard, modalità di failover automatico, parametri di autorizzazione e configurazione dell'applicazione).
Possiamo specificare esplicitamente quale parte del lavoro vogliamo fare, quindi il ruolo salterà il resto delle attività. Nel nostro caso, vogliamo lavorare solo con la topologia, così abbiamo specificato cartridge-replicasets.
Valutiamo il risultato dei nostri sforzi. Ricerca di un nuovo set di repliche .
Evviva!
Sperimenta con la riconfigurazione di istanze e set di repliche e osserva come cambia la topologia del cluster. Puoi provare diversi scenari operativi, ad esempio, o aumentare memtx_memory. Il ruolo tenterà di eseguire questa operazione senza riavviare l'istanza per ridurre i possibili tempi di inattività dell'applicazione.
Non dimenticare di correre vagrant haltper arrestare le macchine virtuali quando hai finito con loro.
Cosa c'è sotto il cofano?
Qui parlerò di più di ciò che è accaduto sotto il cofano del ruolo ansible durante i nostri esperimenti.
Diamo un'occhiata alla distribuzione di un'applicazione Cartridge passo dopo passo.
Installazione del pacchetto e avvio delle istanze
Per prima cosa devi consegnare il pacchetto al server e installarlo. Ora il ruolo può funzionare con i pacchetti RPM e DEB.
Successivamente, lanciamo le istanze. Tutto è molto semplice qui: ogni istanza è separata systemd-servizio. Sto parlando di un esempio:
$ systemctl start myapp@storage-1Questo comando avvierà l'istanza storage-1 приложения myapp. L'istanza avviata cercherà il suo file в /etc/tarantool/conf.d/. I registri delle istanze possono essere visualizzati utilizzando journald.
Fascicolo unità /etc/systemd/system/[email protected] per un servizio systemd verrà consegnato con il pacchetto.
Ansible ha moduli integrati per l'installazione di pacchetti e la gestione dei servizi systemd, non abbiamo inventato nulla di nuovo qui.
Configurazione della topologia del cluster
E qui inizia il più interessante. D'accordo, sarebbe strano preoccuparsi di uno speciale ruolo ansible per l'installazione e l'esecuzione dei pacchetti systemd-Servizi.
Puoi configurare il cluster manualmente:
- La prima opzione: apri l'interfaccia utente Web e fai clic sui pulsanti. Per un avvio una tantum di più istanze, è abbastanza adatto.
- Seconda opzione: puoi utilizzare l'API GraphQl. Qui puoi già automatizzare qualcosa, ad esempio scrivere uno script in Python.
- La terza opzione (per i forti di spirito): vai al server, connettiti a una delle istanze utilizzando
tarantoolctl connected eseguire tutte le manipolazioni necessarie con il modulo Luacartridge.
Il compito principale della nostra invenzione è fare questo, la parte più difficile del lavoro per te.
Ansible ti consente di scrivere il tuo modulo e utilizzarlo in un ruolo. Il nostro ruolo utilizza questi moduli per gestire i vari componenti del cluster.
Come funziona? Descrivi lo stato desiderato del cluster in una configurazione dichiarativa e il ruolo fornisce a ogni modulo la sua sezione di configurazione come input. Il modulo riceve lo stato corrente del cluster e lo confronta con l'input. Successivamente, viene eseguito un codice attraverso il socket di una delle istanze, che porta il cluster allo stato desiderato.
Risultati di
Oggi abbiamo raccontato e mostrato come distribuire la tua applicazione su Tarantool Cartridge e impostare una topologia semplice. Per farlo abbiamo utilizzato Ansible, uno strumento potente, facile da usare e che permette di configurare contemporaneamente molti nodi dell'infrastruttura (nel nostro caso si tratta di istanze cluster).
Sopra, abbiamo affrontato uno dei tanti modi per descrivere la configurazione del cluster utilizzando Ansible. Una volta che sai di essere pronto per andare avanti, impara per scrivere playbook. Potresti trovare più conveniente gestire la topologia con group_vars и host_vars.
Molto presto ti diremo come rimuovere (espellere) in modo permanente le istanze dalla topologia, eseguire il bootstrap di vshard, gestire la modalità di failover automatico, configurare l'autorizzazione e applicare patch alla configurazione del cluster. Nel frattempo, puoi studiare da solo e sperimentare la modifica dei parametri del cluster.
Se qualcosa non funziona, assicurati noi sul problema. Lo analizzeremo rapidamente!
Fonte: habr.com