Ya hemos presentado el cartucho de Tarantool que le permite desarrollar y empacar aplicaciones distribuidas. Ahora, aprendamos cómo implementar y controlar estas aplicaciones. Sin pánico, ¡todo está bajo control! Hemos reunido todas las mejores prácticas de trabajo con Tarantool Cartridge y escribimos un rol de Ansible , que implementará el paquete en los servidores, iniciará y unirá instancias en conjuntos de réplica, configurará autorización, bootstrap vshard, habilitará la conmutación por error automática y la configuración del clúster de parches.

Interesante, ¿eh? Sumérgete, verifica los detalles debajo del corte.

Comenzando con una muestra

Permítanos guiarlo a través de algunas de las funciones del rol. Siempre puede encontrar una descripción completa de todas sus características y parámetros de entrada en la documentación . Sin embargo, intentar una vez es mejor que verlo cientos de veces, así que desplieguemos una pequeña aplicación.

Tarantool Cartridge tiene un tutorial para crear una pequeña aplicación de cartucho que almacena información sobre clientes bancarios y sus cuentas, además de proporcionar una API para la gestión de datos a través de HTTP. Para este propósito, la aplicación describe dos roles posibles que pueden asignarse a las instancias: api y storage .

Cartridge en sí no dice nada sobre cómo iniciar los procesos, solo brinda la oportunidad de configurar las instancias en ejecución. Por lo tanto, el resto depende del usuario: distribuir archivos de configuración, ejecutar servicios y configurar la topología. Pero no vamos a hacer todo eso: Ansible lo hará por nosotros.

Ponerse en acción

Primero, desplieguemos nuestra aplicación en dos máquinas virtuales y configuremos una topología simple:

• El conjunto de réplicas de la app-1 representará el rol de la api que contiene el vshard-router . Habrá solo una instancia.
• El conjunto de réplicas storage-1 representará la función de storage (incluida la función vshard-storage ); aquí agregaremos dos instancias de máquinas diferentes.

Para ejecutar la muestra, necesitaremos Vagrant y Ansible (versión 2.8 o superior).

El rol en sí está almacenado en Ansible Galaxy , un repositorio que le permite compartir su trabajo y usar los roles listos para usar.

Ahora clone el repositorio de muestras:

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

Luego implemente las máquinas virtuales:

 $ vagrant up 

Después de eso, instale el rol de Tarantool Cartridge Ansible:

 $ ansible-galaxy install tarantool.cartridge,1.0.1 

Y comience el rol instalado:

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

Ahora espere hasta que finalice el proceso del libro de jugadas, vaya a http: // localhost: 8181 / admin / cluster / dashboard y disfrute de los resultados:



Puedes subir los datos ahora. Impresionante, ¿no es así?

Ahora, descubramos cómo trabajar con él, y también podemos agregar otro conjunto de réplicas a la topología.

Profundizando en los detalles

Entonces, ¿qué pasó?

Pusimos en funcionamiento dos máquinas virtuales y lanzamos el libro de jugadas Ansible que configuró nuestro clúster. Ahora echemos un vistazo al archivo 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 

Nada interesante sucede aquí; vamos a lanzar el rol Ansible llamado tarantool.cartridge .

Lo más importante (es decir, la configuración del clúster) está en el archivo de inventario 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: 

Todo lo que tenemos que hacer es aprender a administrar instancias y conjuntos de réplicas modificando este archivo. Más adelante, le agregaremos nuevas secciones. Para evitar confusiones al agregar las secciones, mire la versión final de este archivo, o hosts.updated.yml , que se encuentra en el repositorio de muestras.

Administrar las instancias

En términos de Ansible, cada instancia es un host (que no debe confundirse con un servidor físico), es decir, el nodo de infraestructura que administrará Ansible. Para cada host, podemos especificar parámetros de conexión (como ansible_host y ansible_user ) y la configuración de la instancia. La descripción de la instancia está en la sección de hosts .

Veamos la configuración de la instancia de storage-1 :

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

En la variable de config , especificamos los parámetros de instancia: advertise URI y HTTP port .

A continuación se muestran los parámetros de las instancias de la app-1 y storage-1-replica .

Deberíamos proporcionar Ansible con parámetros de conexión para cada instancia. Parece razonable agrupar las instancias por máquinas virtuales. Para este propósito, las instancias se agrupan en host1 y host2 , y cada grupo en la sección vars contiene los valores de los parámetros ansible_host y ansible_user para una sola máquina virtual. Y la sección de hosts contiene hosts (o instancias) incluidos en este grupo:

 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: 

Comencemos a editar hosts.yml . Ahora agregamos dos instancias más: storage-2-replica en la primera máquina virtual y storage-2 en la segunda:

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

Comience el libro de jugadas Ansible:

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

Tenga en cuenta la opción --limit . Dado que cada instancia de clúster es un host en términos de Ansible, podemos especificar explícitamente qué instancias deben configurarse al ejecutar el libro de jugadas.

Así que volvemos a la interfaz de usuario web en http: // localhost: 8181 / admin / cluster / dashboard y miramos nuestras nuevas instancias:



A continuación, dominemos la gestión de topología.

Administrar la topología

Agrupemos nuestras nuevas instancias en el conjunto de réplicas storage-2 , agreguemos un nuevo grupo de replicaset_storage_2 y describamos los parámetros del conjunto de réplicas en las variables como lo hicimos para replicaset_storage_1 . En la sección de hosts , especificamos qué instancias deben incluirse en este grupo (es decir, nuestro conjunto 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: 

Luego volvemos a ejecutar el libro de jugadas:

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

Esta vez pasamos el nombre del grupo correspondiente a nuestro conjunto de réplicas en el parámetro --limit .

Veamos la opción de tags .

Nuestro rol ejecuta sucesivamente varias tareas marcadas con las siguientes etiquetas:

• cartridge-instances : gestión de instancias (configuración, membresía);
• conjuntos de réplica de cartridge-replicasets : gestión de topología (gestión de conjunto de réplica y eliminación permanente (expulsión) de instancias del clúster);
• cartridge-config : control de otros parámetros del clúster (vstratamiento inicial duro, conmutación por error automática, parámetros de autorización y configuración de la aplicación)

Podemos especificar explícitamente qué parte del trabajo queremos que se haga, y el rol omitirá el resto de las tareas. En este caso, solo queremos trabajar con topología, por lo que especificamos conjuntos cartridge-replicasets .

Permítanos evaluar el resultado de nuestros esfuerzos. Encuentre el nuevo conjunto de réplicas en http: // localhost: 8181 / admin / cluster / dashboard .



Yay

Intente cambiar la configuración de las instancias y los conjuntos de réplicas y vea cómo cambia la topología del clúster. Puede probar diferentes casos de uso, como la actualización continua o el aumento de memtx_memory . El rol intentaría hacer esto sin reiniciar la instancia para reducir el posible tiempo de inactividad de su aplicación.

No olvide ejecutar una vagrant halt para detener las máquinas virtuales cuando haya terminado con ellas.

Que hay adentro

Aquí les contaré más sobre lo que sucedió bajo el capó del rol Ansible durante nuestras pruebas.
Consideremos los pasos para implementar una aplicación Cartridge.

Instalar el paquete e iniciar las instancias

Lo primero que debe hacer es entregar el paquete al servidor e instalarlo. Ahora el rol puede funcionar con paquetes RPM y paquetes DEB.

A continuación, lanzamos las instancias. Es muy simple: cada instancia es un servicio systemd separado. Por ejemplo:

 $ systemctl start myapp@storage-1 

Este comando inicia la instancia de storage-1 de myapp
aplicación La instancia en ejecución busca su configuración en /etc/tarantool/conf.d/ . Puede ver los registros de instancias usando journald .

El archivo de unidad /etc/systemd/systemd/myapp@.sevice para el servicio systemd se entrega con el paquete.

Ansible tiene módulos integrados para instalar paquetes y administrar servicios systemd, por lo que no inventamos nada nuevo aquí.

Configurar la topología del clúster

Las cosas más emocionantes suceden aquí. Estoy seguro de que estaría de acuerdo en que es extraño molestarse con un rol Ansible especial para instalar paquetes y ejecutar servicios systemd .

Puede configurar el clúster manualmente:

• La primera opción es abrir la interfaz de usuario web y hacer clic en los botones. Es muy adecuado para un inicio único de varias instancias.
• La segunda opción es usar GraphQL API. Aquí ya puede automatizar algo, por ejemplo, escribir un script en Python.
• La tercera opción es para los valientes: vaya al servidor, conéctese a una de las instancias con la ayuda de tarantoolctl connect y realice todas las acciones necesarias con el módulo de cartridge Lua.

La tarea principal de nuestro invento es hacer la parte más difícil del trabajo por usted.

Ansible le permite escribir su propio módulo y usarlo en su rol. Nuestro rol utiliza estos módulos para administrar los diversos componentes del clúster.

Como funciona Describe el estado deseado del clúster en una configuración declarativa, y el rol le da a cada módulo su propia sección de configuración como entrada. El módulo recibe el estado actual del clúster y lo compara con la entrada. Luego, el código para el estado de clúster necesario se inicia utilizando el socket de una de las instancias.

Resultados

Hoy le hemos mostrado cómo implementar su aplicación de cartucho de Tarantool y configurar una topología simple. Para hacer esto, utilizamos Ansible, una herramienta poderosa que es fácil de usar y le permite configurar múltiples nodos de infraestructura al mismo tiempo (en nuestro caso, las instancias de clúster).

Arriba repasamos una de las muchas formas de describir la configuración del clúster por medio de Ansible. Una vez que sienta que está listo para más, aprenda las mejores prácticas para escribir libros de jugadas. Puede resultarle más fácil administrar la topología con group_vars y host_vars .

Muy pronto, le diremos cómo eliminar (expulsar) instancias de la topología de forma permanente, bootstrap vshard, administrar la conmutación por error automática, configurar la autorización y configurar el clúster de parches. Mientras tanto, puede revisar la documentación usted mismo e intentar cambiar la configuración del clúster.

Si algo sale mal, asegúrese de informarnos sobre el problema. ¡Haremos todo lo posible para resolver cualquier problema!