Cómo construimos universos paralelos para nuestra (y su) canalización de CI / CD en Octopod

¡Hola, Habr! Mi nombre es Denis, y te contaré cómo nos sugirieron hacer una solución técnica para optimizar el proceso de desarrollo y QA en nuestro Typeable. Comenzó con la sensación general de que estábamos haciendo todo bien, pero aún sería posible avanzar más rápido y de manera más eficiente: aceptar nuevas tareas, probar, sincronizar menos. Todo esto nos llevó a discusiones y experimentos, que dieron como resultado nuestra solución de código abierto, que describiré a continuación y que ahora está disponible para ustedes.



Sin embargo, no vayamos por delante de la locomotora, empecemos desde el principio y comprendamos en detalle de qué estoy hablando. Imaginemos una situación bastante estándar: un proyecto con una arquitectura de tres niveles (almacenamiento, backend, frontend). Existe un proceso de desarrollo y un proceso de garantía de calidad en el que hay varios entornos (a menudo denominados esquemas) para realizar pruebas:

• La producción es el entorno de trabajo principal al que van los usuarios del sistema. 
• Pre-Production – - (, production, ; RC), production, production . Pre-production – , Production .
• Staging – , , , Production, .

Con la preproducción, todo está bastante claro: los candidatos a lanzamiento van allí constantemente, el historial de lanzamiento es el mismo que en producción . Hay matices con Staging :

1. ORGANIZATIVO. La prueba de partes críticas puede requerir un retraso en la publicación de nuevos cambios; los cambios pueden interactuar de formas impredecibles; rastrear errores se vuelve difícil debido a la gran cantidad de actividad en el servidor; a veces hay confusión sobre qué versión se implementa; A veces no está claro cuál de los cambios acumulados causó el problema.
2. . : production , «». staging , . . : , . , QA production , .
   
   
   
3. .
   
   
   
   
   
   
4. . . -. , . , . , .
5. . - , , , , . , , , . , . production , time-to-production time-to-market .

Cada uno de estos puntos se resuelve de una forma u otra, pero todo ello llevó a la pregunta de si será posible simplificar nuestra vida si nos alejamos del concepto de un stand de puesta en escena a su número dinámico. De forma similar a como tenemos comprobaciones de CI para cada rama en git, podemos obtener soportes de pago de QA para cada rama. Lo único que nos detiene de tal movimiento es la falta de infraestructura y herramientas. En términos generales, para aceptar una función, se crea una etapa separada con un nombre de dominio dedicado, QA la prueba, la acepta o la devuelve para su revisión. Algo como esto: 





Con este enfoque, el problema de los diferentes entornos se resuelve de forma natural:





De manera reveladora, después de la discusión, las opiniones del equipo se dividieron en “intentémoslo, quiero más que ahora” y “parece tan normal, no veo problemas monstruosos”, pero volveremos a esto más adelante.

Nuestro camino hacia la solución

Lo primero que probamos fue un prototipo construido por nuestro DevOps: una combinación de docker-compose (orquestación), rundeck (administración) y portainer (introspección), lo que nos permitió probar la dirección general del pensamiento y el enfoque. Hubo problemas de conveniencia:

1. Cualquier cambio requería acceso al código y rundeck, que los desarrolladores tenían, pero no tenían, por ejemplo, los ingenieros de control de calidad.
2. Esto se planteó en una máquina grande, que pronto se volvió insuficiente, y para el siguiente paso, ya se necesitaba Kubernetes o algo similar.
3. Portainer proporcionó información no sobre el estado de una puesta en escena en particular, sino sobre un conjunto de contenedores.
4. Tuve que fusionar constantemente el archivo con la descripción de las etapas, los antiguos stands tuvieron que ser eliminados.

Incluso con todos sus inconvenientes y con algunos inconvenientes de operación, el enfoque entró y comenzó a ahorrar tiempo y esfuerzo al equipo del proyecto. La hipótesis fue probada, y decidimos hacer todo lo mismo, pero de una manera estricta. En la búsqueda del objetivo de optimizar el proceso de desarrollo, recopilamos los requisitos para uno nuevo y entendimos lo que queríamos:

1. Use Kubernetes para escalar a cualquier cantidad de entornos de prueba y tenga un conjunto estándar de herramientas para DevOps moderno.
2. Una solución que sería fácil de integrar en la infraestructura que ya usa Kubernetes.
3. , Product QA-. , . – .
4. , CI/CD , . , Github Actions CI.
5. , DevOps .
6. , , / - .
7. La información completa y una lista de acciones deben estar disponibles para los superusuarios en la persona de los ingenieros de DevOps y los líderes de equipo.

Y comenzamos a desarrollar Octopod . El nombre fue una confusión de varios pensamientos sobre K8S, que usamos para orquestar todo en el proyecto: muchos proyectos en este ecosistema reflejan la estética y los temas marinos, e imaginamos una especie de pulpo orquestando muchos contenedores submarinos con tentáculos. Además, el Pod es una de las entidades fundadoras de Kubernetes.



En la pila técnica, Octopod es Haskell, Rust, FRP, compilación para JS, Nix. Pero, en general, la historia no se trata de esto, así que no me extenderé en esto con más detalle.



El nuevo modelo se conoció como Multi-stage dentro de nuestra empresa. Operar múltiples entornos de puesta en escena simultáneamente es similar a viajar a través de universos y dimensiones paralelas en la ciencia ficción (y no tanto). En él, los universos son similares entre sí, con la excepción de un pequeño detalle: en algún lugar diferentes bandos ganaron la guerra, en algún lugar ocurrió una revolución cultural, en algún lugar un avance tecnológico. La premisa puede ser pequeña, ¡pero a qué cambios puede conducir! En nuestros procesos, este requisito previo es el contenido de cada rama de función separada.





Nuestra implementación se llevó a cabo en varias etapas y comenzó con un proyecto. Esto incluye ajustar la orquestación del proyecto desde el lado de DevOps y reorganizar el proceso de prueba y comunicación desde el gerente del proyecto.



Como resultado de una serie de iteraciones, algunas características del propio Octopod se han eliminado o cambiado más allá del reconocimiento. Por ejemplo, en la primera versión teníamos una página con un registro de implementación para cada circuito, pero aquí está la mala suerte: no todos los equipos aceptan que las credenciales puedan fluir a través de estos registros a todos los empleados involucrados en el desarrollo. Como resultado, decidimos deshacernos de esta funcionalidad y luego la devolvimos en una forma diferente; ahora es personalizable (y por lo tanto opcional) y se implementa a través de la integración con el panel de Kubernetes .



También hay otros puntos: con el nuevo enfoque, usamos más recursos informáticos, discos y nombres de dominio para respaldar la infraestructura, lo que plantea la cuestión de la optimización de costos. Si combina esto con las sutilezas de DevOps, el material se escribirá en una publicación separada, o incluso en dos, por lo que no continuaré sobre esto aquí.



Paralelamente a la resolución de problemas emergentes en un proyecto, comenzamos a integrar esta solución en otro, cuando vimos interés de otro equipo. Esto nos permitió asegurarnos de que nuestra solución fuera lo suficientemente personalizable y flexible para las necesidades de diferentes proyectos. Por el momento, Octopod se ha utilizado ampliamente en nuestro país durante tres meses.

Como resultado

Como resultado, el sistema y los procesos se implementan en varios proyectos, hay interés de uno más. Curiosamente, incluso aquellos colegas que no vieron ningún problema con el antiguo esquema ahora no querrían volver a él. ¡Resultó que para algunos resolvimos problemas que ni siquiera conocían!



Lo más difícil, como de costumbre, fue la primera implementación: la mayoría de los problemas técnicos y problemas quedaron atrapados en ella. Los comentarios de los usuarios permitieron comprender mejor qué es lo que se debe mejorar en primer lugar. En las últimas versiones, la interfaz y el trabajo con Octopod se ven así:





Para nosotros, Octopod se ha convertido en una respuesta a una pregunta de procedimiento, y yo llamaría al estado actual un éxito inequívoco: la flexibilidad y la conveniencia han aumentado claramente. Aún no hay problemas completamente resueltos: arrastramos la autorización del propio Octopod en el clúster a Atlassian oauth para varios proyectos, y este proceso se retrasa. Sin embargo, esto no es más que una cuestión de tiempo, técnicamente el problema ya está resuelto en una primera aproximación.

Fuente abierta

Esperamos que Octopod sea de utilidad no solo para nosotros. Estaremos encantados de recibir sugerencias, solicitudes de extracción e información sobre cómo optimizar procesos similares. Si el proyecto es de interés para la audiencia, escribiremos sobre las características de orquestación y operación con nosotros.



Todo el código fuente con ejemplos de configuración y documentación está disponible en el repositorio de Github .