Nous en avons déjà parlé , qui vous permet de développer des applications distribuées et de les empaqueter. Il ne reste plus qu’à apprendre à déployer ces applications et à les gérer. Ne vous inquiétez pas, nous avons tout couvert ! Nous avons rassemblé toutes les meilleures pratiques pour travailler avec Tarantool Cartouche et écrit , qui distribuera le package aux serveurs, lancera les instances, les unira dans un cluster, configurera l'autorisation, amorcera vshard, activera le basculement automatique et corrigera la configuration du cluster.
Intéressant? Alors s'il vous plaît, sous la coupe, nous vous dirons et vous montrerons tout.
Commençons par un exemple
Nous n'examinerons qu'une partie des fonctionnalités de notre rôle. Vous pouvez toujours trouver une description complète de toutes ses capacités et paramètres d'entrée dans . Mais il vaut mieux essayer une fois que de le voir cent fois, alors déployons une petite application.
La cartouche Tarantool a pour créer une petite application Cartouche qui stocke des informations sur les clients de la banque et leurs comptes, et fournit également une API pour la gestion des données via HTTP. Pour y parvenir, l’annexe décrit deux rôles possibles : api и storage, qui peut être attribué aux instances.
La cartouche elle-même ne dit rien sur la façon de lancer des processus, elle offre uniquement la possibilité de configurer des instances déjà en cours d'exécution. L'utilisateur doit faire le reste lui-même : organiser les fichiers de configuration, démarrer les services et configurer la topologie. Mais nous ne ferons pas tout cela ; Ansible le fera à notre place.
Des mots aux actes
Alors, déployons notre application sur deux machines virtuelles et mettons en place une topologie simple :
- Jeu de réplicas
app-1mettra en œuvre le rôleapi, qui inclut le rôlevshard-router. Il n'y aura qu'un seul exemple ici. - Jeu de réplicas
storage-1met en œuvre le rôlestorage(et en même tempsvshard-storage), nous ajouterons ici deux instances provenant de machines différentes.
Pour exécuter l'exemple dont nous avons besoin и (version 2.8 ou antérieure).
Le rôle lui-même est dans . Il s'agit d'un référentiel qui vous permet de partager votre travail et d'utiliser des rôles prêts à l'emploi.
Clonons le référentiel avec un exemple :
$ git clone https://github.com/dokshina/deploy-tarantool-cartridge-app.git
$ cd deploy-tarantool-cartridge-app && git checkout 1.0.0Nous élevons des machines virtuelles :
$ vagrant upInstallez le rôle ansible de la cartouche Tarantool :
$ ansible-galaxy install tarantool.cartridge,1.0.1Lancez le rôle installé :
$ ansible-playbook -i hosts.yml playbook.ymlNous attendons que le playbook termine son exécution, accédez à et profitez du résultat :
Vous pouvez télécharger des données. Cool, non ?
Voyons maintenant comment utiliser cela tout en ajoutant un autre jeu de réplicas à la topologie.
Commençons à comprendre
Alors, qu'est-ce-qu'il s'est passé?
Nous avons configuré deux machines virtuelles et lancé un playbook ansible qui a configuré notre cluster. Regardons le contenu du fichier 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.cartridgeRien d'intéressant ne se passe ici, lançons un rôle ansible appelé tarantool.cartridge.
Toutes les choses les plus importantes (à savoir la configuration du cluster) se trouvent dans -déposer 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:Tout ce dont nous avons besoin est d'apprendre à gérer les instances et les jeux de réplicas en modifiant le contenu de ce fichier. Ensuite, nous y ajouterons de nouvelles sections. Afin de ne pas savoir où les ajouter, vous pouvez consulter la version finale de ce fichier, hosts.updated.yml, qui se trouve dans le référentiel d'exemple.
Gestion des instances
En termes Ansible, chaque instance est un hôte (à ne pas confondre avec un serveur matériel), c'est-à-dire le nœud d'infrastructure qu'Ansible gérera. Pour chaque hôte, nous pouvons spécifier des paramètres de connexion (tels que ansible_host и ansible_user), ainsi que la configuration de l'instance. La description des instances est dans la section hosts.
Regardons la configuration de l'instance storage-1:
all:
vars:
...
# INSTANCES
hosts:
storage-1:
config:
advertise_uri: '172.19.0.2:3301'
http_port: 8181
...En variable config nous avons spécifié les paramètres de l'instance - advertise URI и HTTP port.
Ci-dessous les paramètres de l'instance app-1 и storage-1-replica.
Nous devons indiquer à Ansible les paramètres de connexion pour chaque instance. Il semble logique de regrouper les instances en groupes de machines virtuelles. A cet effet, les instances sont regroupées en groupes host1 и host2, et dans chaque groupe de la section vars les valeurs sont indiquées ansible_host и ansible_user pour une machine virtuelle. Et dans la rubrique hosts — les hôtes (c'est-à-dire les instances) qui sont inclus dans ce groupe :
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:Nous commençons à changer hosts.yml. Ajoutons deux autres instances, storage-2-replica sur la première machine virtuelle et storage-2 Sur la seconde :
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: # <==
...Lancez le playbook ansible :
$ ansible-playbook -i hosts.yml
--limit storage-2,storage-2-replica
playbook.ymlVeuillez noter l'option --limit. Étant donné que chaque instance de cluster est un hôte en termes Ansible, nous pouvons spécifier explicitement quelles instances doivent être configurées lors de l'exécution du playbook.
Revenir à l'interface utilisateur Web et découvrez nos nouvelles instances :
Ne nous arrêtons pas là et maîtrisons la gestion de la topologie.
Gestion de la topologie
Combinons nos nouvelles instances dans un jeu de répliques storage-2. Ajoutons un nouveau groupe replicaset_storage_2 et décrire les paramètres du réplicaset dans ses variables par analogie avec replicaset_storage_1. Dans la section hosts Indiquons quelles instances seront incluses dans ce groupe (c'est-à-dire notre jeu de réplicas) :
---
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:Reprenons le playbook :
$ ansible-playbook -i hosts.yml
--limit replicaset_storage_2
--tags cartridge-replicasets
playbook.ymlEn paramètre --limit Cette fois nous avons passé le nom du groupe qui correspond à notre réplicaset.
Considérons l'option tags.
Notre rôle effectue séquentiellement diverses tâches, qui sont marquées par les balises suivantes :
cartridge-instances: gestion des instances (configuration, connexion à l'adhésion) ;cartridge-replicasets: gestion de la topologie (gestion des réplicasets et suppression définitive (expel) des instances du cluster) ;cartridge-config: gestion des autres paramètres du cluster (vshard bootstrapping, mode de basculement automatique, paramètres d'autorisation et configuration de l'application).
Nous pouvons spécifier explicitement quelle partie du travail nous voulons effectuer, le rôle ignorera alors le reste des tâches. Dans notre cas, nous souhaitons travailler uniquement avec la topologie, nous avons donc précisé cartridge-replicasets.
Évaluons le résultat de nos efforts. Nous trouvons un nouveau jeu de répliques sur .
Hourra!
Essayez de modifier la configuration des instances et des jeux de réplicas et voyez comment la topologie du cluster change. Vous pouvez essayer différents scénarios opérationnels, par ex. ou augmenter memtx_memory. Le rôle tentera de le faire sans redémarrer l'instance afin de réduire les éventuels temps d'arrêt de votre application.
N'oublie pas de courir vagrant haltpour arrêter les machines virtuelles lorsque vous avez fini de travailler avec elles.
Qu'y a-t-il sous le capot?
Ici, je vais vous en dire plus sur ce qui se passait sous le capot du rôle ansible lors de nos expériences.
Examinons le déploiement de l'application Cartouche étape par étape.
Installation du package et démarrage des instances
Vous devez d’abord livrer le package au serveur et l’installer. Actuellement, le rôle peut fonctionner avec les packages RPM et DEB.
Ensuite, nous lançons les instances. Tout est très simple ici : chaque instance est une instance distincte systemd-service. Je vais vous donner un exemple :
$ systemctl start myapp@storage-1Cette commande lancera l'instance storage-1 приложения myapp. L'instance lancée recherchera son в /etc/tarantool/conf.d/. Les journaux d'instance peuvent être consultés à l'aide de journald.
Fichier unité /etc/systemd/system/[email protected] pour le service systemd sera livré avec le package.
Ansible a des modules intégrés pour installer des packages et gérer les services systemd ; nous n'avons rien inventé de nouveau ici.
Configuration d'une topologie de cluster
C'est là que le plaisir commence. D'accord, il serait étrange de s'embêter avec un rôle Ansible spécial pour installer des packages et exécuter systemd-prestations de service.
Vous pouvez configurer le cluster manuellement :
- Première option : ouvrez l'interface Web et cliquez sur les boutons. C’est tout à fait adapté au démarrage ponctuel de plusieurs instances.
- Deuxième option : vous pouvez utiliser l'API GraphQl. Ici, vous pouvez déjà automatiser quelque chose, par exemple écrire un script en Python.
- Troisième option (pour les volontaires) : allez sur le serveur, connectez-vous à l'une des instances en utilisant
tarantoolctl connectet effectuez toutes les manipulations nécessaires avec le module Luacartridge.
La tâche principale de notre invention est de faire exactement cela, la partie la plus difficile du travail pour vous.
Ansible vous permet d'écrire votre propre module et de l'utiliser dans un rôle. Notre rôle utilise de tels modules pour gérer divers composants du cluster.
Comment ça fonctionne? Vous décrivez l'état souhaité du cluster dans une configuration déclarative, et le rôle fournit à chaque module sa section de configuration en entrée. Le module reçoit l'état actuel du cluster et le compare avec ce qui a été reçu en entrée. Ensuite, un code est lancé via le socket de l'une des instances, ce qui amène le cluster à l'état souhaité.
Les résultats de
Aujourd'hui, nous avons expliqué et montré comment déployer votre application sur Tarantool Cartouche et mettre en place une topologie simple. Pour ce faire, nous avons utilisé Ansible - un outil puissant, simple à utiliser et permettant de configurer simultanément de nombreux nœuds d'infrastructure (dans notre cas, des instances de cluster).
Ci-dessus, nous avons examiné l'une des nombreuses façons de décrire une configuration de cluster à l'aide d'Ansible. Une fois que vous vous sentez prêt à passer à autre chose, explorez sur l'écriture de playbooks. Il vous sera peut-être plus facile de gérer votre topologie en utilisant group_vars и host_vars.
Très prochainement, nous vous expliquerons comment supprimer (expulser) définitivement des instances de la topologie, amorcer vshard, gérer le mode de basculement automatique, configurer l'autorisation et corriger la configuration du cluster. En attendant, vous pouvez étudier seul et expérimentez la modification des paramètres du cluster.
Si quelque chose ne fonctionne pas, assurez-vous de nous au sujet du problème. Nous allons tout régler rapidement !
Source: habr.com