Ya hablamos sobre el cartucho de Tarantool , que le permite desarrollar aplicaciones distribuidas y empacarlas. Todo lo que queda es aprender a implementar estas aplicaciones y administrarlas. No te preocupes, ¡hemos provisto todo! Reunimos todas las mejores prácticas para trabajar con Tarantool Cartridge y escribimos una función responsable que descompone el paquete en servidores, lanza las instancias, las combina en un clúster, configura la autorización, inicia vshard, habilita la conmutación por error automática y parchea la configuración del clúster.

Interesante? Luego pido un corte, le diremos y mostraremos todo.

Comencemos con un ejemplo.

Consideraremos solo una parte de la funcionalidad de nuestro rol. Siempre puede encontrar una descripción completa de todas sus características y parámetros de entrada en la documentación . Pero es mejor intentarlo una vez que ver cientos de veces, así que instalemos una pequeña aplicación.

Tarantool Cartridge tiene un tutorial sobre cómo crear una pequeña aplicación de cartucho que almacena información sobre clientes bancarios y sus cuentas, y también proporciona una API para administrar datos a través de HTTP. Para hacer esto, la aplicación describe dos roles posibles: api y storage , que pueden asignarse a instancias.

El cartucho en sí no dice nada sobre cómo iniciar procesos, solo proporciona la capacidad de configurar instancias que ya se están ejecutando. El usuario debe hacer el resto: descomponer los archivos de configuración, iniciar los servicios y configurar la topología. Pero no haremos todo esto, Ansible lo hará por nosotros.

Tenga en cuenta que si está desarrollando su aplicación en OS X, empacarla en una máquina local y luego no instalarla en Centos o Debian no funcionará, ya que el paquete contendrá módulos de rocas y archivos ejecutables específicos de OS X. En este caso, deberá hacer empaques en el sistema de destino.

De las palabras a los hechos

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

• El replicaet app-1 implementará la función api , que incluye la función vshard-router . Solo habrá una instancia.
• El conjunto storage-1 réplicas storage-1 implementa la función de storage (y al mismo tiempo vshard-storage ), aquí agregamos dos instancias de máquinas diferentes.

Para ejecutar el ejemplo, necesitamos Vagrant y Ansible (versión 2.8 o posterior).

El papel en sí está en Ansible Galaxy . Este es un repositorio que le permite compartir sus mejores prácticas y usar roles listos para usar.

Clonamos el repositorio con un ejemplo:

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

Levantar máquinas virtuales:

 $ vagrant up 

Instale la función ansible del cartucho de Tarantool:

 $ ansible-galaxy install tarantool.cartridge,1.0.1 

Ejecute el rol instalado:

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

Estamos esperando la finalización del libro de jugadas, vaya a http: // localhost: 8181 / admin / cluster / dashboard y disfrute del resultado:

Puedes verter datos. Genial, verdad?

Ahora veamos cómo trabajar con esto y, al mismo tiempo, agreguemos otro conjunto de réplicas a la topología.

Empieza a entender

Entonces que paso?

Recogimos dos máquinas virtuales y lanzamos el libro de jugadas ansible que configuró nuestro clúster. Veamos el contenido del 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 

Aquí no pasa nada interesante, lanzamos una función ansible llamada tarantool.cartridge .

Todo 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 el contenido de este archivo. Además le agregaremos nuevas secciones. Para no confundirse dónde agregarlos, puede echar un vistazo a la versión final de este archivo, hosts.updated.yml , que se encuentra en el repositorio con un ejemplo.

Gestión de instancias

En términos de Ansible, cada instancia es un host (que no debe confundirse con un servidor de hierro), es decir Un nodo de infraestructura que Ansible gestionará. Para cada host, podemos especificar parámetros de conexión (como ansible_host y ansible_user ), así como la configuración de la instancia. La descripción de las instancias se encuentra en la sección de hosts .

Considere 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 instancia de app-1 y storage-1-replica .

Necesitamos proporcionar parámetros de conexión Ansible para cada instancia. Parece lógico agrupar instancias en grupos de máquinas virtuales. Para hacer esto, las instancias se agrupan en host2 host1 y host2 , y en cada grupo en la sección vars se indican los valores ansible_host y ansible_user para una vars . Y en la sección de hosts hay hosts (son instancias) que se incluyen 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: 

Comenzamos a cambiar hosts.yml . Agregue 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: # <== ... 

Ejecute el libro de jugadas ansible:

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

Presta atención a la opción --limit . Dado que cada instancia del clúster es un host en términos de Ansible, podemos indicar explícitamente qué instancias deben configurarse al jugar un libro de jugadas.

Nuevamente, vaya a la interfaz de usuario web http: // localhost: 8181 / admin / cluster / dashboard y observe nuestras nuevas instancias:

No nos detendremos en lo que se ha logrado y dominaremos la gestión de la topología.

Gestión de topología

Combine nuestras nuevas instancias en storage-2 réplicas storage-2 . Agregue un nuevo grupo replicaset_storage_2 y describa los parámetros de replicaset en sus variables, de forma similar a replicaset_storage_1 . En la sección de hosts , indicamos qué instancias se incluirán 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: 

Inicie el libro de jugadas nuevamente:

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

Esta vez, pasamos el nombre del grupo que corresponde a nuestro conjunto de réplicas al parámetro --limit.

Considere la opción de tags .

Nuestro rol realiza constantemente diversas tareas, que están marcadas con las siguientes etiquetas:

• cartridge-instances : gestión de instancias (configuración, conexión a membresía);
• cartridge-replicasets : gestión de topología (gestión de conjuntos de réplicas y eliminación permanente (expulsión) de instancias del clúster);
• cartridge-config : gestión de los parámetros restantes del clúster (vstratamiento inicial dinámico, modo de conmutación por error automática, parámetros de autorización y configuración de la aplicación).

Podemos indicar explícitamente qué parte del trabajo queremos hacer, luego el rol omitirá la ejecución de las tareas restantes. En nuestro caso, queremos trabajar solo con la topología, por lo tanto, indicamos conjuntos cartridge-replicasets .

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

¡Hurra!

Experimente cambiando la configuración de instancias y conjuntos de réplicas y vea cómo cambia la topología del clúster. Puede probar varios escenarios operativos, por ejemplo, actualizar o aumentar memtx_memory . El rol intentará hacer esto sin reiniciar la instancia para reducir el posible tiempo de inactividad de su aplicación.

No se olvide de iniciar la vagrant halt para detener vagrant halt cuando haya terminado de trabajar con ellas.

¿Y qué hay debajo del capó?

Aquí te contaré más sobre lo que sucedió bajo el capó del papel ansible durante nuestros experimentos.

Considere los pasos para implementar una aplicación de cartucho.

Instalar un paquete e iniciar instancias

Primero debe entregar el paquete al servidor e instalarlo. Ahora el rol puede funcionar con paquetes RPM y DEB.

A continuación, ejecute las instancias. Aquí todo es muy simple: cada instancia es un servicio systemd separado. Lo digo con un ejemplo:

 $ systemctl start myapp@storage-1 

Este comando iniciará la instancia de storage-1 de myapp . La instancia en ejecución buscará su configuración en /etc/tarantool/conf.d/ . journald se pueden ver usando journald .

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

Ansible tiene módulos integrados para instalar paquetes y administrar servicios systemd, aquí no hemos inventado nada nuevo.

Configurar la topología de clúster

Y aquí comienza la diversión. De acuerdo, sería extraño molestarse con un rol especial de ansible para instalar paquetes y ejecutar systemd services.

Puede configurar el clúster manualmente:

• La primera opción: abrir la interfaz de usuario web y hacer clic en los botones. Para un inicio único de varias instancias, es bastante adecuado.
• Segunda opción: puede usar la API GraphQl. Aquí ya puede automatizar algo, por ejemplo, escribir un script en Python.
• La tercera opción (para aquellos que son fuertes en espíritu): vamos al servidor, nos tarantoolctl connect a una de las instancias usando tarantoolctl connect y realizamos todas las manipulaciones necesarias con el módulo de cartridge Lua.

El objetivo principal de nuestro invento es hacer exactamente esto, la parte más difícil del trabajo para usted.

Ansible le permite escribir su módulo y usarlo en un rol. Nuestro rol utiliza dichos módulos para administrar varios componentes del clúster.

Como funciona Describe el estado deseado del clúster en la configuración declarativa, y el rol alimenta su sección de configuración a la entrada de cada módulo. El módulo recibe el estado actual del clúster y lo compara con lo que entró. Luego, a través del socket de una de las instancias, se inicia el código, que lleva el clúster al estado deseado.

Resumen

Hoy hablamos y mostramos cómo implementar su aplicación en el 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 simultáneamente muchos nodos de infraestructura (en nuestro caso, estas son instancias de clúster).

Arriba, descubrimos una de las muchas formas de describir la configuración del clúster usando Ansible. Una vez que se dé cuenta de que está listo para seguir adelante, aprenda las mejores prácticas para escribir libros de jugadas. Puede que le resulte más conveniente administrar la topología con group_vars y host_vars .

En la siguiente parte, aprenderemos cómo eliminar permanentemente (expulsar) instancias de la topología, bootstrap vshard, administrar el modo de conmutación por error automática, configurar la autorización y parchear la configuración del clúster. No te detengas allí, continúa estudiando la documentación y experimenta con el cambio de los parámetros del clúster.

Si algo no funciona, asegúrese de informarnos sobre el problema. ¡Rápidamente destruiremos todo!