A medida que trabaja en TI, comienza a notar que los sistemas tienen su propio carácter. Pueden ser flexibles, silenciosos, excéntricos y severos. Pueden atraer o repeler. De una forma u otra, hay que “negociar” con ellos, maniobrar entre “escollos” y construir cadenas de interacción.
Así que tuvimos el honor de construir una plataforma en la nube y para ello necesitábamos "persuadir" a un par de subsistemas para que trabajaran con nosotros. Afortunadamente tenemos un “lenguaje API”, manos directas y mucho entusiasmo.
Este artículo no será técnicamente complicado, pero describirá los problemas que encontramos al construir la nube. Decidí describir nuestro camino en forma de una ligera fantasía técnica sobre cómo buscábamos un lenguaje común con los sistemas y qué resultó de ello.
Bienvenido al gato.
A partir de un viaje
Hace algún tiempo, a nuestro equipo se le encomendó la tarea de lanzar una plataforma en la nube para nuestros clientes. Teníamos soporte de gestión, recursos, hardware y libertad para elegir tecnologías para implementar la parte de software del servicio.
También había una serie de requisitos:
- el servicio necesita una cuenta personal conveniente;
- la plataforma debe integrarse al sistema de facturación existente;
- software y hardware: OpenStack + Tungsten Fabric (Open Contrail), que nuestros ingenieros han aprendido a “cocinar” bastante bien.
En otro momento le contaremos cómo se formó el equipo, cómo se desarrolló la interfaz de la cuenta personal y cómo se tomaron las decisiones de diseño, si la comunidad de Habra está interesada.
Las herramientas que decidimos utilizar:
- Python + Flask + Swagger + SQLAlchemy: un conjunto de Python completamente estándar;
- Vue.js para interfaz;
- Decidimos realizar la interacción entre componentes y servicios utilizando Celery en lugar de AMQP.
Anticipándome a las preguntas sobre la elección de Python, lo explicaré. El idioma ha encontrado su nicho en nuestra empresa y a su alrededor se ha desarrollado una pequeña pero todavía cultura. Por lo tanto, se decidió comenzar a construir el servicio en él. Además, la velocidad de evolución de estos problemas suele ser decisiva.
Entonces, comencemos a conocernos.
Factura silenciosa - facturación
Conocemos a este tipo desde hace mucho tiempo. Siempre se sentaba a mi lado y contaba algo en silencio. A veces nos enviaba solicitudes de usuarios, emitía facturas de clientes y gestionaba servicios. Un tipo normal y trabajador. Es cierto que hubo dificultades. Está en silencio, a veces pensativo y a menudo en sus propios pensamientos.
La facturación es el primer sistema con el que intentamos hacernos amigos. Y la primera dificultad que encontramos fue a la hora de tramitar los servicios.
Por ejemplo, cuando se crea o se elimina, una tarea pasa a la cola de facturación interna. Así, se implementa un sistema de trabajo asincrónico con servicios. Para procesar nuestros tipos de servicios, necesitábamos "poner" nuestras tareas en esta cola. Y aquí nos topamos con un problema: la falta de documentación.
A juzgar por la descripción de la API del software, todavía es posible resolver este problema, pero no tuvimos tiempo de hacer ingeniería inversa, por lo que sacamos la lógica y organizamos una cola de tareas encima de RabbitMQ. El cliente inicia una operación en un servicio desde su cuenta personal, se convierte en una “tarea” de Celery en el backend y se realiza en el lado de facturación y OpenStack. Apio hace que sea muy conveniente gestionar tareas, organizar repeticiones y controlar el estado. Puedes leer más sobre “apio”, por ejemplo, .
Además, la facturación no detuvo un proyecto que se quedó sin dinero. Al comunicarnos con los desarrolladores, descubrimos que al calcular las estadísticas (y necesitamos implementar exactamente este tipo de lógica), existe una interrelación compleja entre las reglas de detención. Pero estos modelos no encajan bien con nuestras realidades. También lo implementamos a través de tareas en Celery, llevando la lógica de gestión de servicios al backend.
Los dos problemas anteriores hicieron que el código se volviera un poco inflado y en el futuro tendremos que refactorizarlo para trasladar la lógica para trabajar con tareas a un servicio separado. También necesitamos almacenar cierta información sobre los usuarios y sus servicios en nuestras tablas para respaldar esta lógica.
Otro problema es el silencio.
Billy responde silenciosamente "Ok" a algunas solicitudes de API. Este fue el caso, por ejemplo, cuando realizamos los pagos prometidos durante la prueba (más sobre esto más adelante). Las solicitudes se ejecutaron correctamente y no vimos ningún error.
Tuve que estudiar los registros mientras trabajaba con el sistema a través de la interfaz de usuario. Resultó que la propia facturación realiza solicitudes similares, cambiando el alcance a un usuario específico, por ejemplo, administrador, pasándolo en el parámetro su.
En general, a pesar de las lagunas en la documentación y los fallos menores de la API, todo salió bastante bien. Los registros se pueden leer incluso con una carga pesada si comprende cómo están estructurados y qué buscar. La estructura de la base de datos es elaborada, pero bastante lógica y, en algunos aspectos, incluso atractiva.
Entonces, en resumen, los principales problemas que encontramos en la etapa de interacción están relacionados con las características de implementación de un sistema específico:
- “características” indocumentadas que nos afectaron de una forma u otra;
- código cerrado (la facturación está escrita en C++), como resultado, es imposible resolver el problema 1 de otra forma que no sea "prueba y error".
Afortunadamente, el producto cuenta con una API bastante extensa y hemos integrado los siguientes subsistemas en nuestra cuenta personal:
- módulo de soporte técnico: las solicitudes de su cuenta personal se "envían" a la facturación de forma transparente para los clientes del servicio;
- módulo financiero: le permite emitir facturas a clientes actuales, realizar cancelaciones y generar documentos de pago;
- Módulo de control de servicio: para esto tuvimos que implementar nuestro propio controlador. La capacidad de ampliación del sistema jugó a nuestro favor y le "enseñamos" a Billy un nuevo tipo de servicio.
Fue un poco complicado, pero de una manera u otra, creo que Billy y yo nos llevaremos bien.
Caminando por campos de tungsteno – Tungsten Fabric
Campos de tungsteno salpicados de cientos de cables, pasando miles de bits de información a través de ellos. La información se recopila en "paquetes", se analiza y construye rutas complejas, como por arte de magia.
Este es el dominio del segundo sistema con el que tuvimos que hacernos amigos: Tungsten Fabric (TF), anteriormente OpenContrail. Su tarea es gestionar los equipos de red, proporcionándonos una abstracción de software a nosotros como usuarios. TF - SDN, encapsula la compleja lógica de trabajar con equipos de red. Hay un buen artículo sobre la tecnología en sí, por ejemplo, .
El sistema está integrado con OpenStack (que se analiza a continuación) a través del complemento Neutron.
Interacción de servicios OpenStack.
Los chicos del departamento de operaciones nos presentaron este sistema. Usamos la API del sistema para administrar la pila de red de nuestros servicios. No nos ha causado ningún problema o inconveniente grave todavía (no puedo hablar por los chicos del OE), pero ha habido algunas rarezas en la interacción.
El primero se veía así: los comandos que requerían enviar una gran cantidad de datos a la consola de la instancia cuando se conectaban a través de SSH simplemente "colgaban" la conexión, mientras que a través de VNC todo funcionaba correctamente.
Para aquellos que no están familiarizados con el problema, parece bastante divertido: ls /root funciona correctamente, mientras que, por ejemplo, top se “congela” por completo. Afortunadamente, nos hemos encontrado con problemas similares antes. Se decidió ajustando la MTU en la ruta desde los nodos de cómputo a los enrutadores. Por cierto, esto no es un problema de TF.
El siguiente problema estaba a la vuelta de la esquina. En un momento “hermoso”, la magia del enrutamiento desapareció, así como así. TF ha dejado de gestionar el enrutamiento en el equipo.
Trabajamos con Openstack desde el nivel de administrador y luego pasamos al nivel de usuario requerido. SDN parece "secuestrar" el alcance del usuario que realiza las acciones. El hecho es que se utiliza la misma cuenta de administrador para conectar TF y OpenStack. En el paso de cambiar al usuario, la “magia” desapareció. Se decidió crear una cuenta separada para trabajar con el sistema. Esto nos permitió trabajar sin interrumpir la funcionalidad de integración.
Formas de vida de silicio - OpenStack
Una criatura de silicona de forma extraña vive cerca de campos de tungsteno. Sobre todo, parece un niño demasiado grande que puede aplastarnos de un solo golpe, pero no hay ninguna agresión obvia proveniente de él. No causa miedo, pero su tamaño inspira miedo. Al igual que la complejidad de lo que sucede a nuestro alrededor.
OpenStack es el núcleo de nuestra plataforma.
OpenStack tiene varios subsistemas, de los cuales actualmente utilizamos más activamente Nova, Glance y Cinder. Cada uno de ellos tiene su propia API. Nova es responsable de los recursos informáticos y la creación de instancias, Cinder es responsable de administrar volúmenes y sus instantáneas, Glance es un servicio de imágenes que administra plantillas de sistema operativo y metainformación sobre ellas.
Cada servicio se ejecuta en un contenedor y el intermediario de mensajes es el "conejo blanco": RabbitMQ.
Este sistema nos dio el problema más inesperado.
Y el primer problema no se hizo esperar cuando intentamos conectar un volumen adicional al servidor. La API de Cinder se negó rotundamente a realizar esta tarea. Más precisamente, si cree en OpenStack, la conexión está establecida, pero no hay ningún dispositivo de disco dentro del servidor virtual.
Decidimos tomar un desvío y solicitamos la misma acción a la API de Nova. El resultado es que el dispositivo se conecta correctamente y es accesible dentro del servidor. Parece que el problema ocurre cuando el almacenamiento en bloque no responde a Cinder.
Nos esperaba otra dificultad a la hora de trabajar con discos. El volumen del sistema no se pudo desconectar del servidor.
Nuevamente, el propio OpenStack "jura" que destruyó la conexión y ahora puede trabajar correctamente con el volumen por separado. Pero la API categóricamente no quería realizar operaciones en el disco.
Aquí decidimos no luchar especialmente, sino cambiar nuestra visión de la lógica del servicio. Si hay una instancia, también debe haber un volumen del sistema. Por lo tanto, el usuario aún no puede eliminar o desactivar el "disco" del sistema sin eliminar el "servidor".
OpenStack es un conjunto de sistemas bastante complejo con su propia lógica de interacción y API ornamentada. Nos ayuda una documentación bastante detallada y, por supuesto, prueba y error (¿dónde estaríamos sin ella?).
Prueba de funcionamiento
Realizamos un lanzamiento de prueba en diciembre del año pasado. La tarea principal fue probar nuestro proyecto en modo combate desde el punto de vista técnico y desde el lado de UX. Se invitó al público de forma selectiva y se cerró la prueba. No obstante, también hemos dejado la opción de solicitar acceso a las pruebas en nuestra web.
La prueba en sí, por supuesto, no estuvo exenta de momentos divertidos, porque aquí es donde nuestras aventuras apenas comienzan.
En primer lugar, evaluamos de manera algo incorrecta el interés en el proyecto y tuvimos que agregar rápidamente nodos de cómputo durante la prueba. Un caso común para un grupo, pero aquí también había algunos matices. La documentación para una versión específica de TF indica la versión específica del kernel en la que se probó el trabajo con vRouter. Decidimos lanzar nodos con kernels más recientes. Como resultado, TF no recibió rutas de los nodos. Tuve que revertir urgentemente los núcleos.
Otra curiosidad está relacionada con la funcionalidad del botón “cambiar contraseña” en su cuenta personal.
Decidimos utilizar JWT para organizar el acceso a nuestra cuenta personal para no trabajar con sesiones. Dado que los sistemas son diversos y están muy dispersos, administramos nuestro propio token, en el que “encapsulamos” sesiones de facturación y un token de OpenStack. Cuando se cambia la contraseña, el token, por supuesto, "se estropea", ya que los datos del usuario ya no son válidos y es necesario volver a emitirlos.
Perdimos de vista este punto y simplemente no había suficientes recursos para terminar rápidamente esta pieza. Tuvimos que eliminar la funcionalidad justo antes de iniciar la prueba.
Actualmente cerramos la sesión del usuario si se ha cambiado la contraseña.
A pesar de estos matices, las pruebas fueron bien. En un par de semanas, pasaron por allí unas 300 personas. Pudimos observar el producto a través de los ojos de los usuarios, probarlo en acción y recopilar comentarios de alta calidad.
To be continued
Para muchos de nosotros, este es el primer proyecto de esta escala. Aprendimos una serie de lecciones valiosas sobre cómo trabajar en equipo y tomar decisiones arquitectónicas y de diseño. Cómo integrar sistemas complejos con pocos recursos y ponerlos en producción.
Por supuesto, hay algo en lo que trabajar tanto en términos de código como en las interfaces de integración del sistema. El proyecto es bastante joven, pero estamos llenos de ambiciones de convertirlo en un servicio confiable y conveniente.
Ya hemos podido persuadir a los sistemas. Bill maneja diligentemente el conteo, la facturación y las solicitudes de los usuarios en su armario. La "magia" de los campos de tungsteno nos proporciona una comunicación estable. Y sólo OpenStack a veces se vuelve caprichoso y grita algo como "'WSREP aún no ha preparado el nodo para el uso de la aplicación". Pero esa es una historia completamente diferente...
Recientemente lanzamos el servicio.
Puedes conocer todos los detalles en nuestro .
Equipo de desarrollo de CLO
Enlaces de interés
Pila abierta
Tela de tungsteno
Fuente: habr.com