Applications faciles et faciles à déployer sur la cartouche Tarantool (partie 2)

Plus récemment, nous avons expliqué comment déployer des applications écrites dans Tarantool Cartridge . Mais l'opération ne se termine pas sur le déploiement, nous allons donc aujourd'hui mettre à jour notre application et comprendre comment gérer la topologie, le partage et l'autorisation, ainsi que changer la configuration des rôles.

Curieux, coupez!

Où nous sommes-nous arrêtés

La dernière fois que nous avons configuré la topologie suivante:

L' exemple de référentiel a réussi à changer un peu, de nouveaux fichiers y sont apparus, getting-started-app-2.0.0-0.rpm et hosts.updated.2.yml . Vous n'avez pas à extraire la nouvelle version, vous pouvez simplement télécharger le package à partir du lien , et hosts.updated.2.yml nécessaire uniquement pour que vous puissiez y jeter un coup d'œil en cas de difficultés avec la modification de l'inventaire actuel.

Si vous avez terminé toutes les étapes de la partie précédente de ce tutoriel, alors maintenant dans votre hosts.yml hosts.yml hosts.yml il y a une configuration de cluster avec deux répliques de storage (dans le référentiel, c'est hosts.updated.yml ).

Élevez nos machines virtuelles:

 $ vagrant up 

Installez la nouvelle version de la cartouche Tarantool à rôle Ansible (elle a réussi à changer, bien sûr, pour le mieux):

 $ ansible-galaxy install tarantool.cartridge,1.0.2 

Ainsi, la configuration actuelle du cluster:

 --- 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 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: # first machine connection options ansible_host: 172.19.0.2 ansible_user: vagrant hosts: # instances to be started on the first machine storage-1: storage-2-replica: 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: storage-2: # 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: 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: 

Accédez à http: // localhost: 8181 / admin / cluster / dashboard et assurez-vous que votre cluster est dans le bon état.

Tout est identique à la dernière fois: nous allons progressivement changer ce fichier et observer comment le cluster change. Vous pouvez toujours consulter la version finale dans hosts.updated.2.yml

Alors c'est parti!

Mise à jour de l'application

Pour commencer, mettons à jour notre application. Assurez-vous que le fichier getting-started-app-2.0.0-0.rpm dans le répertoire actuel (sinon, téléchargez- le depuis le référentiel).

Spécifiez le chemin d'accès à la nouvelle version du package:

 --- all: vars: cartridge_app_name: getting-started-app cartridge_package_path: ./getting-started-app-2.0.0-0.rpm # <== cartridge_enable_tarantool_repo: false # <== 

Nous avons spécifié cartridge_enable_tarantool_repo: false pour que le rôle ne connecte pas le référentiel avec le package Tarantool, que nous avons déjà installé la dernière fois. Cela accélérera légèrement le processus de déploiement, mais ce n'est absolument pas nécessaire.

Lancez le playbook avec la balise cartridge-instances :

 $ ansible-playbook -i hosts.yml playbook.yml \ --tags cartridge-instances 

Et nous vérifions que le package a été mis à jour:

 $ vagrant ssh vm1 [vagrant@svm1 ~]$ sudo yum list installed | grep getting-started-app 

Vérifiez que la version est devenue 2.0.0 :

 getting-started-app.x86_64 2.0.0-0 installed 

Vous pouvez maintenant expérimenter en toute sécurité avec la nouvelle version de l'application.

Activer le sharding

Activons le partage afin de pouvoir prendre le contrôle des répliques de storage plus tard. Cela se fait très simplement. Ajoutez la variable cartridge_bootstrap_vshard section all.vars :

 --- all: vars: ... cartridge_cluster_cookie: app-default-cookie # cluster cookie cartridge_bootstrap_vshard: true # <== ... hosts: ... children: ... 

Nous lançons:

 $ ansible-playbook -i hosts.yml playbook.yml \ --tags cartridge-config 

Veuillez noter que nous avons spécifié la balise cartridge-config pour exécuter uniquement les tâches impliquées dans la configuration du cluster.

Ouvrez l'interface utilisateur Web http: // localhost: 8181 / admin / cluster / dashboard et vérifiez que nos compartiments sont répartis sur les jeux de réplicas de stockage dans un rapport 2:3 (nous avons spécifié de tels poids pour nos jeux de répliques, vous vous souvenez?):

Activer le basculement automatique

Et maintenant, nous allons activer le mode de basculement automatique afin que nous puissions comprendre ce que c'est et comment cela fonctionne un peu plus tard.

Ajoutez l'indicateur de cartridge_failover à la configuration:

 --- all: vars: ... cartridge_cluster_cookie: app-default-cookie # cluster cookie cartridge_bootstrap_vshard: true cartridge_failover: true # <== ... hosts: ... children: ... 

Nous recommençons les tâches de gestion du cluster:

 $ ansible-playbook -i hosts.yml playbook.yml \ --tags cartridge-config 

Une fois le playbook terminé, vous pouvez accéder à l'interface utilisateur Web et vous assurer que le commutateur de Failover dans le coin supérieur droit est activé. Pour désactiver le mode de basculement automatique, remplacez simplement la valeur de cartridge_failover par false et réexécutez le playbook.

Il est temps de comprendre de quel type de régime il s'agit et pourquoi nous l'avons activé.

Nous gérons le basculement

Vous avez probablement remarqué la variable failover_priority que nous avons spécifiée pour chaque jeu de réplicas. Voyons voir ce que c'est.

La cartouche Tarantool fournit un mode de basculement automatique. Chaque jeu de réplicas a un leader - l'instance dans laquelle il est enregistré. Si quelque chose arrive au leader, une des remarques prendra son rôle. Lequel? Examinons de plus près le jeu de répliques de storage-2 :

 --- all: ... children: ... replicaset_storage_2: vars: ... failover_priority: - storage-2 - storage-2-replica 

L'instance de storage-2 nous avons spécifiée en premier dans failover_priority . Dans l'interface utilisateur Web, il apparaît en premier dans la liste des instances de jeu de réplicas et est marqué d'une couronne verte. Ceci est le leader - la première instance spécifiée dans failover_priority :

Voyons maintenant ce qui se passe si quelque chose arrive au leader du jeu de répliques. Nous allons dans la machine virtuelle et arrêtons l'instance de storage-2 :

 $ vagrant ssh vm2 [vagrant@vm2 ~]$ sudo systemctl stop getting-started-app@storage-2 

Retour à l'interface utilisateur Web:

La couronne à l'instance de storage-2 devenue rouge - cela signifie que le chef désigné est malsain. Mais le storage-2-replica une couronne verte - cette instance a repris les responsabilités de leadership jusqu'à ce que le storage-2 revienne en service. Il s'agit d'un basculement automatique en action.

Revivons le storage-2 :

 $ vagrant ssh vm2 [vagrant@vm2 ~]$ sudo systemctl start getting-started-app@storage-2 

Tout est revenu à la case départ:

Modifions l'ordre des instances dans la priorité du basculement. Nous allons faire de l'instance de storage-2-replica un leader et supprimer le storage-2 de la liste en général:

 --- all: vars: ... hosts: ... children: ... replicaset_storage_2: vars: # replicaset configuration ... failover_priority: - storage-2-replica # <== ... 

Exécutez les cartridge-replicasets pour les instances du groupe replicaset_storage_2 :

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

Nous allons sur http: // localhost: 8181 / admin / cluster / dashboard et voyons que le leader a changé:

Mais nous avons supprimé l'instance de storage-2 de la configuration, pourquoi est-elle toujours là? Le fait est que Cartridge, recevant une nouvelle valeur de failover_priority organise les instances comme suit: la première instance de la liste devient le leader, les autres instances indiquées suivent. Les instances non mentionnées dans failover_priority seront ordonnées par UUID et ajoutées à la fin.

Instance d'exil

Mais que faire si nous voulons exclure l'instance de la topologie? Tout est très simple: vous devez lui passer le drapeau expelled . Excluons l'instance de storage-2-replica . Il est le leader maintenant, donc Cartridge ne nous permettra pas de le faire. Mais nous n'avons pas peur des difficultés et essayons toujours:

 --- all: vars: ... hosts: storage-2-replica: config: advertise_uri: '172.19.0.2:3302' http_port: 8185 expelled: true # <== ... 

Nous spécifions la cartridge-replicasets , car l'expulsion d'une instance est un changement de topologie:

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

Exécutez le playbook et voyez l'erreur:

Comme nous venons de le voir, Cartridge ne justifie pas de retirer l'actuel leader du jeu de réplicas de la topologie. Cela est assez logique, car la réplication est asynchrone, l'exclusion d'un leader est susceptible d'entraîner une perte de données. Nous devons spécifier un autre leader et seulement après cela exclure l'instance. Le rôle appliquera d'abord la nouvelle configuration de jeu de réplicas, puis traitera l'exception. Par conséquent, nous changeons failover_priority et réexécutons le playbook:

 --- all: vars: ... hosts: ... children: ... replicaset_storage_2: vars: # replicaset configuration ... failover_priority: - storage-2 # <== ... 

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

Voila, l'instance de storage-2-replica a disparu de la topologie!

Notez que l'exil d'instance est vraiment définitif et irrévocable. Après avoir supprimé l'instance de la topologie, notre rôle ansible arrêtera le service systemd et supprimera tous les fichiers de cette instance.

Si vous changez soudain d’avis et décidez que le jeu de réplicas de storage-2 toujours besoin d’une seconde instance, vous ne pourrez pas le restaurer. La cartouche se souvient de l'UUID de toutes les instances qui ont quitté la topologie et ne permettra pas à l'exil de revenir. Vous pouvez créer une nouvelle instance avec le même nom et la même configuration, mais elle aura évidemment un UUID différent, donc Cartridge lui permettra de se joindre.

Suppression de Replicaset

Nous avons déjà découvert que nous ne serons pas autorisés à expulser le chef de la réplique. Mais que faire si nous voulons supprimer définitivement le réplica de storage-2 ? Il y a bien sûr une issue.

Afin de ne pas perdre de données, nous devons d'abord transférer tous les storage-1 vers le storage-1 , pour cela nous avons défini le poids de la réplique du storage-2 sur 0 :

 --- all: vars: ... hosts: ... children: ... replicaset_storage_2: vars: # replicaset configuration replicaset_alias: storage-2 weight: 0 # <== ... ... 

Lancer la gestion de la topologie:

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

Ouvrez l'interface utilisateur Web http: // localhost: 8181 / admin / cluster / dashboard et observez le flux de tous les storage-1 dans storage-1 :

Nous avons placé le leader du storage-2 sur le drapeau expulsé et avons dit au revoir à ce jeu de répliques:

 --- all: vars: ... hosts: ... storage-2: config: advertise_uri: '172.19.0.3:3303' http_port: 8184 expelled: true # <== ... 

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

Veuillez noter que cette fois, nous n'avons pas spécifié l'option de limit , car au moins une instance parmi toutes celles pour lesquelles nous avons lancé le playbook ne doit pas être marquée comme expelled .

Nous sommes donc revenus à la topologie d'origine:

Se connecter

Je propose de me distraire de la gestion des jeux de répliques et de penser à la sécurité. Désormais, tout utilisateur non autorisé peut gérer le cluster via l'interface utilisateur Web. D'accord, ça a l'air moyen.

La cartouche offre la possibilité de connecter votre propre module d'autorisation, tel que LDAP (ou tout ce que vous avez là-bas), et de l'utiliser pour gérer les utilisateurs et leur accès à l'application. Mais nous utiliserons le module d'autorisation intégré, que Cartridge utilise par défaut. Ce module vous permet d'effectuer des opérations de base avec les utilisateurs (supprimer, ajouter, modifier) ​​et implémente la fonction de vérification du mot de passe.
Veuillez noter que notre rôle ansible nécessite le backend d'autorisation pour implémenter toutes ces fonctions.

On passe donc de la théorie à la pratique. Tout d'abord, rendez l'autorisation obligatoire, définissez les paramètres de session et ajoutez un nouvel utilisateur:

 --- all: vars: ... # authorization cartridge_auth: # <== enabled: true # enable authorization cookie_max_age: 1000 cookie_renew_age: 100 users: # cartridge users to set up - username: dokshina password: cartridge-rullez fullname: Elizaveta Dokshina email: dokshina@example.com # deleted: true # uncomment to delete user ... 

La gestion des autorisations est effectuée dans le cadre des tâches de cartridge-config , nous indiquons cette balise:

 $ ansible-playbook -i hosts.yml playbook.yml \ --tags cartridge-config 

Sur http: // localhost: 8181 / admin / cluster / dashboard une surprise nous attend:

Vous pouvez vous connecter avec le username et le password notre nouvel utilisateur ou vous connecter en tant admin - l'utilisateur par défaut. Son mot de passe est un cookie de cluster, nous avons spécifié cette valeur dans la variable cartridge_cluster_cookie (c'est app-default-cookie , vous ne pouvez pas jeter un œil).

Après une connexion réussie, ouvrez l'onglet Users pour vous assurer que tout s'est bien passé:

Essayez d'ajouter de nouveaux utilisateurs et de modifier leurs paramètres. Pour supprimer un utilisateur, spécifiez le drapeau deleted: true pour lui. Les valeurs de email et de nom fullname ne sont en aucun cas utilisées par la cartouche, mais vous pouvez les spécifier pour plus de commodité.

Configuration d'application

Rappelons-nous comment tout a commencé.

Nous avons déployé une petite application qui stocke des données sur les clients et leurs comptes bancaires. Comme vous vous en souvenez, cette application a 2 rôles: api et storage . Le rôle de storage gère le stockage des données et implémente le partitionnement à l'aide du rôle de vshard-storage . Le deuxième rôle, api , implémente un serveur HTTP avec une API pour la gestion des données, et à l'intérieur il est connecté un autre rôle standard, vshard-router , qui contrôle le partage.

Donc, nous faisons la première demande à l'API d'application. Ajoutez un nouveau client:

 $ curl -X POST -H "Content-Type: application/json" \ -d '{"customer_id":1, "name":"Elizaveta", "accounts":[{"account_id": 1}]}' \ http://localhost:8182/storage/customers/create 

En réponse, nous obtenons quelque chose comme ceci:

 {"info":"Successfully created"} 

Veuillez noter que dans l'URL, nous avons spécifié le port d'instance app-1 , 8082 , car il implémente cette API.

Maintenant, mettons à jour le solde de notre nouvel utilisateur:

 $ curl -X POST -H "Content-Type: application/json" \ -d "{\"account_id\": 1, \"amount\": \"1000\"}" \ http://localhost:8182/storage/customers/1/update_balance 

Dans la réponse, nous voyons le solde mis à jour:

 {"balance":"1000.00"} 

Génial, tout fonctionne! L'API est implémentée, Cartridge est engagée dans le partage de données, nous avons déjà configuré la priorité de basculement pour les cas d'urgence et même activé l'autorisation. Il est temps de faire la configuration de l'application.

La configuration actuelle du cluster est stockée dans un fichier de configuration distribué. Chaque instance conserve une copie de ce fichier et Cartridge assure sa synchronisation entre tous les nœuds du cluster. Nous pouvons spécifier la configuration des rôles de notre application dans ce fichier, et Cartridge se chargera de distribuer la nouvelle configuration sur toutes les instances.

Regardons le contenu actuel de ce fichier. Accédez à l'onglet Cofiguration files et cliquez sur le bouton Download :

Dans le config.yml config.yml téléchargé config.yml nous trouvons une table vide. Pas étonnant, car nous n'avons encore spécifié aucun paramètre:

 --- [] ... 

En fait, le fichier de configuration de notre cluster n'est pas vide, il stocke la topologie actuelle, les paramètres d'autorisation et les paramètres de partitionnement. Mais la cartouche ne sera pas si facile à partager ces informations, elle est destinée à un usage interne, et est donc stockée dans des sections système cachées, que nous ne pouvons pas modifier.

Chaque rôle d'application peut utiliser une ou plusieurs sections de configuration. Le téléchargement d'une nouvelle configuration se déroule en deux étapes: tout d'abord, tous les rôles vérifient qu'ils sont prêts à accepter de nouveaux paramètres. S'il n'y a pas d'objection, les modifications sont appliquées, si quelqu'un s'y oppose, un retour en arrière se produit.

Revenons à notre application. Le rôle api utilise la section max-balance , où le solde maximum autorisé est stocké sur un compte client. Configurons cette section, mais, bien sûr, pas manuellement, mais en utilisant notre rôle Ansible.

Donc, maintenant, la configuration de l'application (ou plutôt, une partie de celle-ci à notre disposition) est une table vide. Ajoutez une section max-balance avec une valeur de 100000 . Nous écrivons la variable cartridge_app_config dans notre fichier d'inventaire:

 --- all: vars: ... # cluster-wide config cartridge_app_config: # <== max-balance: # section name body: 1000000 # section body # deleted: true # uncomment to delete section max-balance ... 

Nous avons spécifié le nom de la section, max-balance , et son contenu, body . Le contenu d'une section peut être non seulement un nombre, mais également un tableau ou une ligne selon la façon dont le rôle est écrit et le type de valeur que vous souhaitez utiliser.

Nous lançons:

 $ ansible-playbook -i hosts.yml playbook.yml \ --tags cartridge-config 

Et nous vérifions que le solde maximum autorisé a bien changé:

 $ curl -X POST -H "Content-Type: application/json" \ -d "{\"account_id\": 1, \"amount\": \"1000001\"}" \ http://localhost:8182/storage/customers/1/update_balance 

En réponse, nous obtenons une erreur, comme nous le voulions:

 {"info":"Error","error":"Maximum is 1000000"} 

Vous pouvez télécharger à nouveau le fichier de configuration dans l'onglet Configuraion files pour vous assurer qu'une nouvelle section y apparaît:

 --- max-balance: 1000000 ... 

Essayez d'ajouter de nouvelles sections à la configuration de l'application, modifiez leur contenu ou supprimez-les complètement (pour cela, vous devez définir l'indicateur deleted: true dans la section).

Vous pouvez découvrir comment utiliser une configuration distribuée dans des rôles dans la documentation de Tarantool Cartridge.

N'oubliez pas d'appeler vagrant halt stop pour arrêter les vagrant halt lorsque vous avez fini de travailler avec elles.

En conclusion

La dernière fois, nous avons appris à déployer des applications de cartouche Tarantool distribuées à l'aide d'un rôle Ansible spécial. Aujourd'hui, nous avons mis à jour l'application, et maîtrisé également la gestion de la topologie, le découpage, l'autorisation et la configuration de l'application.

Ne vous arrêtez pas là, apprenez différentes approches pour écrire des playbooks Ansible et utilisez vos applications avec un maximum de confort.

Si quelque chose ne fonctionne pas pour vous ou si vous avez des idées pour améliorer notre rôle ansible, n'hésitez pas à commencer un ticket . Nous vous aiderons toujours avec la solution de votre problème et nous serons heureux des offres intéressantes!