Mentres traballas en TI, comezas a notar que os sistemas teñen o seu propio carácter. Poden ser flexibles, silenciosos, excéntricos e severos. Poden atraer ou repeler. Dun xeito ou doutro, hai que "negociar" con eles, manobrar entre "trampas" e construír cadeas da súa interacción.
Así que tivemos a honra de construír unha plataforma na nube, e para iso necesitabamos "persuadir" a un par de subsistemas para que traballasen connosco. Afortunadamente, temos unha “idioma API”, mans directas e moito entusiasmo.
Este artigo non será tecnicamente duro, pero describirá os problemas que atopamos ao construír a nube. Decidín describir o noso camiño en forma dunha lixeira fantasía técnica sobre como buscabamos unha linguaxe común con sistemas e o que saía dela.
Benvido ao gato.
Inicio dunha xornada
Hai tempo, o noso equipo encargouse de lanzar unha plataforma na nube para os nosos clientes. Tivemos soporte de xestión, recursos, pila de hardware e liberdade para escoller tecnoloxías para implementar a parte de software do servizo.
Tamén había unha serie de requisitos:
- o servizo necesita unha conta persoal conveniente;
- a plataforma debe estar integrada no sistema de facturación existente;
- software e hardware: OpenStack + Tungsten Fabric (Open Contrail), que os nosos enxeñeiros aprenderon a "cociñar" bastante ben.
Contarémosche noutra ocasión sobre como se creou o equipo, como se desenvolveu a interface da conta persoal e se tomaron decisións de deseño, se a comunidade de Habra está interesada.
As ferramentas que decidimos utilizar:
- Python + Flask + Swagger + SQLAlchemy - un conxunto de Python completamente estándar;
- Vue.js para frontend;
- Decidimos facer a interacción entre compoñentes e servizos usando Celery sobre AMQP.
Anticipando preguntas sobre a elección de Python, explicarei. A lingua atopou o seu oco na nosa empresa e arredor dela desenvolveuse unha pequena, pero aínda cultura. Por iso, decidiuse comezar a construír o servizo nel. Ademais, a velocidade de desenvolvemento nestes problemas adoita ser decisiva.
Entón, imos comezar o noso coñecemento.
Silent Bill - facturación
Coñecémolo desde hai moito tempo. Sempre sentaba ao meu lado e en silencio contaba algo. Ás veces, remitiunos solicitudes de usuarios, emitía facturas de clientes e xestionaba servizos. Un mozo común e traballador. É certo, houbo dificultades. Está en silencio, ás veces pensativo e moitas veces na súa propia mente.
A facturación é o primeiro sistema co que tentamos facer amigos. E a primeira dificultade que atopamos foi á hora de tramitar os servizos.
Por exemplo, cando se crea ou se elimina, unha tarefa pasa á cola de facturación interna. Así, implícase un sistema de traballo asíncrono cos servizos. Para procesar os nosos tipos de servizos, necesitabamos "poñer" as nosas tarefas nesta cola. E aquí atopamos un problema: falta de documentación.
A xulgar pola descrición da API do software, aínda é posible resolver este problema, pero non tivemos tempo para facer enxeñaría inversa, polo que sacamos a lóxica e organizamos unha cola de tarefas enriba de RabbitMQ. Unha operación nun servizo é iniciada polo cliente desde a súa conta persoal, convértese nunha "tarefa" de Celery no backend e realízase no lado de facturación e OpenStack. O apio fai que sexa moi cómodo xestionar tarefas, organizar repeticións e controlar o estado. Podes ler máis sobre "apio", por exemplo, .
Ademais, a facturación non detivo un proxecto que quedou sen cartos. Ao comunicarnos cos desenvolvedores, descubrimos que ao calcular estatísticas (e necesitamos implementar exactamente este tipo de lóxica), hai unha complexa interrelación de regras de parada. Pero estes modelos non encaixan ben coas nosas realidades. Tamén o implementamos mediante tarefas en Celery, levando a lóxica de xestión do servizo ao backend.
Os dous problemas anteriores levaron a que o código se incharse un pouco e no futuro teremos que refactorizar para mover a lóxica para traballar con tarefas a un servizo separado. Tamén necesitamos almacenar algunha información sobre os usuarios e os seus servizos nas nosas táboas para soportar esta lóxica.
Outro problema é o silencio.
Billy responde en silencio "Ok" a algunhas solicitudes da API. Este foi o caso, por exemplo, cando realizamos os pagos dos pagos prometidos durante a proba (máis sobre iso máis adiante). As solicitudes executáronse correctamente e non vimos ningún erro.
Tiven que estudar os rexistros mentres traballaba co sistema a través da IU. Resultou que a propia facturación realiza solicitudes similares, cambiando o ámbito a un usuario específico, por exemplo, administrador, pasándoo no parámetro su.
En xeral, a pesar das lagoas na documentación e os pequenos fallos da API, todo foi bastante ben. Os rexistros pódense ler mesmo con carga pesada se entendes como están estruturados e que buscar. A estrutura da base de datos é ornamentada, pero bastante lóxica e nalgúns aspectos ata atractiva.
Entón, para resumir, os principais problemas que atopamos na fase de interacción están relacionados coas características de implementación dun sistema específico:
- “características” non documentadas que nos afectaron dun xeito ou doutro;
- fonte pechada (a facturación está escrita en C++), como resultado, é imposible resolver o problema 1 doutra forma que non sexa "ensaio e erro".
Afortunadamente, o produto ten unha API bastante extensa e integramos os seguintes subsistemas na nosa conta persoal:
- Módulo de soporte técnico: as solicitudes da túa conta persoal son "proxied" para facturar de forma transparente para os clientes do servizo;
- módulo financeiro: permítelle emitir facturas aos clientes actuais, facer baixas e xerar documentos de pago;
- módulo de control de servizos: para iso tivemos que implementar o noso propio controlador. A ampliabilidade do sistema xogou nas nosas mans e "ensinamos" a Billy un novo tipo de servizo.
Foi un pouco complicado, pero dun xeito ou doutro, creo que Billy e eu imos levarnos ben.
Camiñando polos campos de tungsteno – Tecido de tungsteno
Campos de wolframio salpicados de centos de fíos, que pasan por eles miles de bits de información. A información recóllese en "paquetes", analízase, construíndo rutas complexas, coma por arte de maxia.
Este é o dominio do segundo sistema co que tivemos que facer amigos: Tungsten Fabric (TF), antes OpenContrail. O seu cometido é xestionar os equipos de rede, proporcionándonos como usuarios unha abstracción de software. TF - SDN, encapsula a complexa lóxica de traballar con equipos de rede. Hai un bo artigo sobre a tecnoloxía en si, por exemplo, .
O sistema está integrado con OpenStack (que se comenta a continuación) mediante o complemento Neutron.
Interacción dos servizos OpenStack.
Os rapaces do departamento de operacións presentáronnos este sistema. Usamos a API do sistema para xestionar a pila de rede dos nosos servizos. Aínda non nos causou ningún problema ou inconveniente grave (non podo falar polos mozos do OE), pero houbo algunhas rarezas na interacción.
O primeiro tiña o seguinte aspecto: os comandos que requirían enviar unha gran cantidade de datos á consola da instancia ao conectarse mediante SSH simplemente "colgaban" a conexión, mentres que a través de VNC todo funcionaba correctamente.
Para aqueles que non están familiarizados co problema, parece bastante divertido: ls /root funciona correctamente, mentres que, por exemplo, a parte superior "conxela" por completo. Afortunadamente, xa atopamos problemas similares antes. Decidiuse axustando o MTU na ruta desde os nodos de cálculo ata os enrutadores. Por certo, este non é un problema de TF.
O seguinte problema estaba á volta da esquina. Nun momento "fermosísimo", a maxia do enrutamento desapareceu, así mesmo. TF deixou de xestionar o enrutamento no equipo.
Traballamos con Openstack desde o nivel de administrador e despois pasamos ao nivel de usuario necesario. SDN parece "secuestrar" o ámbito do usuario polo que se realizan as accións. O feito é que se usa a mesma conta de administrador para conectar TF e OpenStack. No paso de cambiar ao usuario, a "maxia" desapareceu. Decidiuse crear unha conta separada para traballar co sistema. Isto permitiunos traballar sen romper a funcionalidade de integración.
Silicon Lifeforms - OpenStack
Unha criatura de silicona de formas estrañas vive preto dos campos de tungsteno. Sobre todo, parece un neno superado que pode esmagarnos cun só golpe, pero non hai unha agresión evidente que vén del. Non causa medo, pero o seu tamaño inspira medo. Igual que a complexidade do que está a suceder ao redor.
OpenStack é o núcleo da nosa plataforma.
OpenStack ten varios subsistemas, dos que actualmente usamos Nova, Glance e Cinder de forma máis activa. Cada un deles ten a súa propia API. Nova é responsable dos recursos informáticos e da creación de instancias, Cinder encárgase de xestionar os volumes e as súas instantáneas, Glance é un servizo de imaxes que xestiona os modelos de SO e a metainformación sobre eles.
Cada servizo execútase nun contedor e o corredor de mensaxes é o "coello branco" - RabbitMQ.
Este sistema deunos o problema máis inesperado.
E o primeiro problema non se fixo esperar cando tentamos conectar un volume adicional ao servidor. A API de Cinder negouse rotundamente a realizar esta tarefa. Máis precisamente, se cres no propio OpenStack, a conexión está establecida, pero non hai ningún dispositivo de disco dentro do servidor virtual.
Decidimos dar un desvío e solicitamos a mesma acción á API de Nova. O resultado é que o dispositivo se conecta correctamente e é accesible dentro do servidor. Parece que o problema ocorre cando o almacenamento en bloque non responde a Cinder.
Outra dificultade esperábanos cando traballabamos con discos. O volume do sistema non se puido desconectar do servidor.
De novo, o propio OpenStack "xura" que destruíu a conexión e agora pode traballar correctamente co volume por separado. Pero a API categoricamente non quería realizar operacións no disco.
Aquí decidimos non loitar especialmente, senón cambiar a nosa visión da lóxica do servizo. Se hai unha instancia, tamén debe haber un volume do sistema. Polo tanto, o usuario aínda non pode eliminar ou desactivar o "disco" do sistema sen eliminar o "servidor".
OpenStack é un conxunto bastante complexo de sistemas coa súa propia lóxica de interacción e unha API ornamentada. Axúdanos documentación bastante detallada e, por suposto, proba e erro (onde estaríamos sen ela).
Execución da proba
Realizamos un lanzamento de proba en decembro do ano pasado. A tarefa principal foi probar o noso proxecto en modo combate desde o lado técnico e desde o lado UX. O público foi convidado selectivamente e a proba pechouse. Non obstante, tamén deixamos a opción de solicitar acceso ás probas no noso sitio web.
A proba en si, por suposto, non estivo exenta de momentos divertidos, porque aí é onde comezan as nosas aventuras.
En primeiro lugar, avaliamos de forma algo incorrecta o interese polo proxecto e tivemos que engadir rapidamente nodos de cálculo xusto durante a proba. Un caso común para un clúster, pero aquí tamén houbo algúns matices. A documentación dunha versión específica de TF indica a versión específica do núcleo na que se probou o traballo con vRouter. Decidimos lanzar nós con núcleos máis recentes. Como resultado, TF non recibiu rutas dos nodos. Tiven que facer retroceder urxentemente os núcleos.
Outra curiosidade está relacionada coa funcionalidade do botón "cambiar contrasinal" na túa conta persoal.
Decidimos usar JWT para organizar o acceso á nosa conta persoal para non traballar coas sesións. Dado que os sistemas son diversos e moi dispersos, xestionamos o noso propio token, no que "envolvemos" as sesións da facturación e un token de OpenStack. Cando se cambia o contrasinal, o token, por suposto, "vai mal", xa que os datos do usuario xa non son válidos e hai que volver a emitilo.
Perdemos este punto de vista e simplemente non había recursos suficientes para rematar rapidamente esta peza. Tivemos que cortar a funcionalidade xusto antes de lanzar a proba.
Actualmente pechamos sesión do usuario se o contrasinal foi modificado.
A pesar destes matices, as probas saíron ben. Nun par de semanas pasaron por alí unhas 300 persoas. Puidemos mirar o produto a través dos ollos dos usuarios, probalo en acción e recoller comentarios de alta calidade.
Continuar
Para moitos de nós, este é o primeiro proxecto desta escala. Aprendemos unha serie de leccións valiosas sobre como traballar en equipo e tomar decisións arquitectónicas e de deseño. Como integrar sistemas complexos con poucos recursos e incorporalos á produción.
Por suposto, hai algo no que traballar tanto en termos de código como nas interfaces de integración do sistema. O proxecto é bastante novo, pero estamos cheos de ambicións para convertelo nun servizo fiable e cómodo.
Xa puidemos persuadir os sistemas. Bill xestiona debidamente o reconto, a facturación e as solicitudes dos usuarios no seu armario. A "maxia" dos campos de wolframio proporciónanos unha comunicación estable. E só OpenStack ás veces se fai caprichoso, gritando algo así como "'WSREP aínda non preparou o nodo para o uso da aplicación". Pero esa é unha historia completamente diferente...
Lanzamos recentemente o servizo.
Podes coñecer todos os detalles na nosa web .
Equipo de Desenvolvemento CLO
Ligazóns útiles
OpenStack
Tecido de tungsteno
Fonte: www.habr.com