Nous avons déjà parlé de la cartouche Tarantool , qui vous permet de développer des applications distribuées et de les packager . Il ne reste plus qu'à apprendre à déployer ces applications et à les gérer. Ne vous inquiétez pas, nous avons tout prévu! Nous avons rassemblé toutes les meilleures pratiques pour travailler avec Tarantool Cartridge et écrit un rôle ansible qui décompose le package en serveurs, lance les instances, les combine dans un cluster, configure l'autorisation, démarre vshard, active le basculement automatique et corrige la configuration du cluster.

Intéressant? Ensuite je demande une coupe, on va tout raconter et tout montrer.

Commençons par un exemple.

Nous ne considérerons qu'une partie des fonctionnalités de notre rôle. Vous pouvez toujours trouver une description complète de toutes ses fonctionnalités et paramètres d'entrée dans la documentation . Mais il vaut mieux essayer une fois que de voir cent fois, alors installons une petite application.

Tarantool Cartridge propose un didacticiel sur la création d'une petite application Cartridge qui stocke des informations sur les clients des banques et leurs comptes, et fournit également une API pour gérer les données via HTTP. Pour ce faire, l'application décrit deux rôles possibles: api et storage , qui peuvent être attribués à des instances.

La cartouche elle-même ne dit rien sur la façon de démarrer les processus, elle offre uniquement la possibilité de configurer des instances déjà en cours d'exécution. L'utilisateur doit faire le reste: décomposer les fichiers de configuration, démarrer les services et configurer la topologie. Mais nous ne ferons pas tout cela, Ansible le fera pour nous.

Veuillez noter que si vous développez votre application sur OS X, alors la compresser sur une machine locale et ensuite ne pas l'installer sur Centos ou Debian ne fonctionnera pas, car le paquet contiendra des modules rock et des fichiers exécutables spécifiques à OS X. Dans ce cas, vous devrez faire l'emballage sur le système cible.

Des paroles aux actes

Alors, installons notre application sur deux machines virtuelles et configurons une topologie simple:

• Le réplicaet app-1 implémentera le rôle api , qui inclut le rôle vshard-router . Il n'y aura qu'une seule instance.
• Le jeu de réplicas storage-1 implémente le rôle de storage (et en même temps vshard-storage ), ici nous ajoutons deux instances de machines différentes.

Pour exécuter l'exemple, nous avons besoin de Vagrant et Ansible (version 2.8 ou ultérieure).

Le rôle lui-même est dans Ansible Galaxy . Il s'agit d'un référentiel qui vous permet de partager vos meilleures pratiques et d'utiliser des rôles prêts à l'emploi.

Nous 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.0 

Augmentez les machines virtuelles:

 $ vagrant up 

Installez le rôle ansible de la cartouche Tarantool:

 $ ansible-galaxy install tarantool.cartridge,1.0.1 

Exécutez le rôle installé:

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

Nous attendons la fin du playbook, allez sur http: // localhost: 8181 / admin / cluster / dashboard et profitez du résultat:

Vous pouvez verser des données. Cool, non?

Voyons maintenant comment travailler avec cela, et en même temps ajoutons un autre jeu de répliques à la topologie.

Commencez à comprendre

Que s'est-il donc passé?

Nous avons récupéré deux machines virtuelles et lancé le 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.cartridge 

Rien d'intéressant ne se passe ici, nous lançons un rôle tarantool.cartridge appelé tarantool.cartridge .

Tout le plus important (à savoir, la configuration du cluster) se trouve dans le fichier d' inventaire 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 que nous devons faire est d'apprendre à gérer les instances et les jeux de réplicas en modifiant le contenu de ce fichier. De plus, nous y ajouterons de nouvelles sections. Afin de ne pas confondre où les ajouter, vous pouvez jeter un œil à la version finale de ce fichier, hosts.updated.yml , qui se trouve dans le référentiel avec un exemple.

Gestion des instances

En termes d'Ansible, chaque instance est un hôte (à ne pas confondre avec un serveur de fer), c'est-à-dire Un nœud d'infrastructure qu'Ansible va gérer. Pour chaque hôte, nous pouvons spécifier les paramètres de connexion (tels que ansible_host et ansible_user ), ainsi que la configuration de l'instance. La description des instances se trouve dans la section des hosts .

Considérez la configuration de l'instance de storage-1 :

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

Dans la variable de config , nous avons spécifié les paramètres d'instance - advertise URI et le HTTP port .
Vous trouverez ci-dessous les paramètres d'instance app-1 et storage-1-replica .

Nous devons fournir des paramètres de connexion Ansible pour chaque instance. Il semble logique de regrouper les instances en groupes de machines virtuelles. Pour ce faire, les instances sont regroupées en host2 host1 et host2 , et dans chaque groupe de la section vars , les valeurs ansible_host et ansible_user pour une vars sont indiquées. Et dans la section des hosts , il y a des hôtes (ce sont des 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 . Ajoutez 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: # <== ... 

Exécutez le livre de jeu ansible:

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

Faites attention à l'option --limit . Étant donné que chaque instance du cluster est un hôte en termes d'Ansible, nous pouvons indiquer explicitement quelles instances doivent être configurées lors de la lecture d'un playbook.

Encore une fois, accédez à l'interface utilisateur Web http: // localhost: 8181 / admin / cluster / dashboard et observez nos nouvelles instances:

Nous ne nous attarderons pas sur ce qui a été réalisé et ne maîtriserons pas la gestion de la topologie.

Gestion de la topologie

Combinez nos nouvelles instances dans storage-2 réplicas de storage-2 . Ajoutez un nouveau groupe replicaset_storage_2 et décrivez les paramètres de replicaset dans ses variables similaires à replicaset_storage_1 . Dans la section des hosts , nous 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: 

Redémarrez le playbook:

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

Cette fois, nous avons passé le nom du groupe qui correspond à notre jeu de répliques au paramètre --limit.

Considérez l'option tags .

Notre rôle effectue régulièrement diverses tâches, marquées par les balises suivantes:

• cartridge-instances : gestion des instances (configuration, connexion à l'appartenance);
• cartridge-replicasets : gestion de la topologie (gestion des jeux de réplicas et suppression permanente (expulsion) des instances du cluster);
• cartridge-config : gestion des paramètres de cluster restants (amorçage vshard, mode de basculement automatique, paramètres d'autorisation et configuration de l'application).

Nous pouvons indiquer explicitement quelle partie du travail nous voulons faire, puis le rôle sautera l'exécution des tâches restantes. Dans notre cas, nous voulons travailler uniquement avec la topologie, c'est pourquoi nous avons indiqué des cartridge-replicasets .

Évaluons le résultat de nos efforts. Recherchez le nouveau jeu de réplicas sur http: // localhost: 8181 / admin / cluster / dashboard .

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 exemple, une mise à jour continue ou augmenter memtx_memory . Le rôle essaiera de le faire sans redémarrer l'instance pour réduire le temps d'arrêt possible de votre application.

N'oubliez pas de démarrer l' vagrant halt pour arrêter vagrant halt lorsque vous avez fini de travailler avec elles.

Et qu'est-ce qui se cache sous le capot?

Ici, je vais vous en dire plus sur ce qui s'est passé sous le capot du rôle ansible lors de nos expériences.

Considérez les étapes de déploiement d'une application de cartouche.

Installation d'un package et démarrage d'instances

Vous devez d'abord livrer le package au serveur et l'installer. Le rôle peut désormais fonctionner avec les packages RPM et DEB.

Ensuite, exécutez les instances. Ici, tout est très simple: chaque instance est un service systemd distinct. Je dis avec un exemple:

 $ systemctl start myapp@storage-1 

Cette commande lancera l'instance de storage-1 de myapp . L'instance en cours d'exécution recherchera sa configuration dans /etc/tarantool/conf.d/ . journald peuvent être consultés à l'aide de journald .

Le fichier d'unité /etc/systemd/system/myapp@.sevice pour le service systemd sera livré avec le package.

Ansible a des modules intégrés pour installer les packages et gérer les services systemd, ici nous n'avons rien inventé de nouveau.

Configurer la topologie de cluster

Et ici, le plaisir commence. D'accord, il serait étrange de s'embêter avec un rôle ansible spécial pour installer les packages et exécuter les services systemd .

Vous pouvez configurer le cluster manuellement:

• La première option: ouvrez l'interface Web et cliquez sur les boutons. Pour un démarrage unique de plusieurs instances, il convient parfaitement.
• Deuxième option: vous pouvez utiliser l'API GraphQl. Ici, vous pouvez déjà automatiser quelque chose, par exemple, écrire un script en Python.
• La troisième option (pour ceux qui sont forts d'esprit): nous allons sur le serveur, nous tarantoolctl connect à l'une des instances en utilisant tarantoolctl connect et effectuons toutes les manipulations nécessaires avec le module de cartridge Lua.

L'objectif principal de notre invention est de faire exactement cela, la partie la plus difficile du travail pour vous.

Ansible vous permet d'écrire votre 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 marche? Vous décrivez l'état souhaité du cluster dans la configuration déclarative et le rôle alimente sa section de configuration à l'entrée de chaque module. Le module reçoit l'état actuel du cluster et le compare avec ce qui est entré. Ensuite, via le socket de l'une des instances, le code est lancé, ce qui amène le cluster à l'état souhaité.

Résumé

Aujourd'hui, nous avons discuté et montré comment déployer votre application sur la cartouche Tarantool et configurer une topologie simple. Pour ce faire, nous avons utilisé Ansible, un outil puissant qui est facile à utiliser et vous permet de configurer simultanément de nombreux nœuds d'infrastructure (dans notre cas, ce sont des instances de cluster).

Ci-dessus, nous avons trouvé l'une des nombreuses façons de décrire la configuration d'un cluster à l'aide d'Ansible. Une fois que vous vous rendez compte que vous êtes prêt à passer à autre chose, découvrez les meilleures pratiques pour écrire des livres de lecture. Il peut être plus pratique de gérer la topologie avec group_vars et host_vars .

Dans la partie suivante, nous apprendrons comment supprimer définitivement (expulser) des instances de la topologie, amorcer vshard, gérer le mode de basculement automatique, configurer l'autorisation et patcher la configuration du cluster. Ne vous arrêtez pas là, continuez à étudier la documentation et à expérimenter la modification des paramètres de cluster.

Si quelque chose ne fonctionne pas, assurez-vous de nous informer du problème. Nous allons tout détruire rapidement!