Propongo familiarizarme con la decodificación del informe de Denis Yakovlev "Automatización de infraestructura. ¿Por qué estamos haciendo esto?"
El informe de 2016 en sí. El informe fue especialmente descifrado para aquellos que crean máquinas virtuales con sus manos.
Informe sobre cómo nosotros en 2GIS automatizamos el trabajo con infraestructura.
"Necesitas correr tan rápido para mantenerte en su lugar, pero para llegar a algún lado, debes correr al menos el doble de rápido" (Alicia en el país de las maravillas).
¿Qué significa esta frase para nosotros? En un entorno altamente competitivo, las empresas deben esforzarse por entregar sus productos a los usuarios lo más rápido posible. Disminuir el tiempo de comercialización del parámetro es una tarea de varios niveles. Para resolverlo, debe cambiar tanto los procesos de desarrollo como las herramientas. Una base importante para todo el proceso de desarrollo es la infraestructura. Cuanto mayor es la infraestructura, más problemas tiene, casos de uso, etc. Si todas las operaciones con él no están automatizadas, entonces aumenta el número de problemas. Uno de ellos es el tiempo que un desarrollador gasta en problemas de infraestructura en lugar de escribir lógica empresarial.
Hablemos de:
- Qué problemas de infraestructura enfrentaron los equipos;
- Cómo sufrieron esto los procesos de desarrollo y prueba;
- Cómo implementamos OpenStack;
- ¿Cuáles son nuestros escenarios para usar OpenStack?
- Cómo la automatización recibió un impulso adicional en el desarrollo y comenzaron a aparecer nuevos productos internos;
- Los aspectos que nos quedan no están automatizados.
Sobre mi Empresa 2GIS. Llevo dos años trabajando en la empresa.
Equipo de Infraestructura y Operaciones. Apoyamos principalmente la infraestructura interna del departamento web. Recientemente, otros equipos internos de productos se han unido a nosotros. También somos responsables del funcionamiento de los productos web de la compañía en producción. Y también estamos investigando y desarrollando nuevas herramientas para facilitarnos la vida y mejorar la vida de nuestros queridos desarrolladores. Solo somos 9 de nosotros.
Primero entendemos la infraestructura. ¿Por qué estamos hablando de ella? Que es esto ¿Cuándo empezamos a hablar de ella?
Desde los primeros momentos de trabajo en el producto y algún proyecto, tenemos una pregunta: ¿dónde implementaremos? ¿Dónde verificar los resultados? dónde probar y así sucesivamente.
Inmediatamente la primera respuesta es local. Localmente porque es muy simple. Desarrollado en su computadora portátil, lanzado, verificado: todo está bien. Te sientas pensando: ¿por qué comprobar además de tu portátil? Todo funciona para mi.
¿Y si tenemos un sistema operativo en la computadora portátil y otro está girando en producción? ¿O debería nuestro producto soportar varios sistemas operativos?
El caso no está cubierto. Es decir, diferentes sistemas operativos.
Si tenemos la oportunidad y tomamos una decisión decidida, tenemos Linux en todas partes. Por ejemplo, algunos Ubuntu. El resto es todo del maligno. Nos parece que hemos resuelto todos nuestros problemas.
Pero simplemente hacer coincidir el sistema operativo no es suficiente. Necesitamos paquetes de cierta versión.
Pensamos cómo resolver este problema. Y recuerda: tenemos aislamiento. Cosas muy altas. Gracias a Dios hay tantos productos en el mercado. Tomamos virtualbox. Crea una máquina virtual. Hacemos rodar nuestro producto. Hacemos instantáneas. Tenemos el medio ambiente.
Estamos desarrollando Nuestro producto se está volviendo más difícil. Esto ya no es solo una aplicación de base de datos php. La aplicación se ha convertido en un sistema distribuido. Tenemos otros productos por venir.
La empresa se está desarrollando. Y tenemos nuevos casos de uso. Todos estos productos quieren integrarse, para poder trabajar juntos. Tenemos características que pasan por varios productos. Se nos pide constantemente que muestremos lo que ha desarrollado. Vamos a verlo en alguna parte. No tenemos más recursos para pruebas manuales. Recordamos que hay integración continua, autotest. Para hacer esto, necesita un software adicional. El medio ambiente local, incluso con todo el aislamiento, ya no es suficiente. Aquí es donde entra la infraestructura. Necesitamos un lugar donde podamos implementar nuestros productos y mostrarle a alguien los resultados. De alguna manera debemos gestionar todo esto y debería ser conveniente.
Echemos un vistazo a nuestra empresa 2GIS.
Esta es una guía y mapas. Puedes mirar el mapa de la ciudad, buscar organizaciones.
Tenemos: productos web, móviles, aplicaciones de escritorio. Hay alrededor de treinta y cinco equipos diferentes de diferentes tamaños.
¿Qué problemas tuvimos con la infraestructura? A finales de 2013, utilizamos proxmox. Este es un sistema de gestión de virtualización. Utilizándolo, puede crear máquinas virtuales KVM o contenedores OpenVZ. Pero todo esto se hace a mano a través de interfaces. Para un funcionamiento completo, aún necesita ingresar a la máquina virtual y configurar la red, dns.
Por lo tanto, durante algún tiempo, el flujo de nuestro desarrollo fue el siguiente. Como desarrollador, estoy buscando administradores de tickets. Los administradores, cuando tienen tiempo, crean una máquina virtual. Dan una dirección IP, inicio de sesión, contraseña. Pero si necesito volver a implementar esta máquina virtual, vuelvo a los administradores que ya me miran con recelo. Dicen: ¿un chico tanto como sea posible?
No hubo separación de proyectos. Había un conjunto de máquinas virtuales en varios servidores, donde los administradores creaban todo con sus manos. Había una alta probabilidad de error humano. Podría confundir la dirección IP o eliminar la máquina virtual incorrecta. Un muy, muy muchos de estos casos. Y la responsabilidad de la máquina virtual es incomprensible. Los desarrolladores no son responsables, los administradores tampoco toman un baño de vapor. No está claro que alguien más necesite una máquina virtual o que todos lo hayan olvidado y no lo sepan.
Además, hay una API débil. Los complementos son de pago o perl.
Pero además de los problemas, teníamos algo más útil. Teníamos nuestro propio hierro, en el que todo esto giraba. Los administradores de nuestro sistema son excelentes compañeros, saben cómo cocinar esta plancha, cuidarla y comprarla correctamente. Y tenían algo de experiencia con la virtualización.
Comenzamos a pensar: ¿qué solución nos conviene? ¿Cómo debería ser nuestra infraestructura para no interferir con el proceso de desarrollo, sino más bien ayudar?
Obtuvimos la siguiente lista de requisitos como resultado del estudio:
Utilización efectiva del hierro. No queremos tener máquinas virtuales huérfanas. No queremos simplemente calentar el aire en el centro de datos.
Queremos tener recursos del equipo para que el equipo se responsabilice de los recursos que utiliza. Y ella estaba atenta a ellos.
Queremos que la solución sea modular, elija solo los servicios que necesitamos. Y en caso de necesidad, con un mayor desarrollo, poder expandirse.
La solución debe finalizarse fácilmente. Si aparecen nuevos requisitos, podríamos refinar la solución a nuestras necesidades específicas.
No solo necesitamos una interfaz de usuario, necesitamos una API para escribir nuestros enlaces y administrar la infraestructura.
Queremos aislar a los equipos, y especialmente al equipo de prueba de carga. Quería que ella no molestara al resto en absoluto.
¿Cuáles fueron nuestras opciones?
Observamos la nube pública: AWS y más. La opción es atractiva porque abordan casi todos los problemas relacionados con la infraestructura. Era posible llevar y pagar mucho dinero a estas compañías famosas, pero estábamos limitados por la desagradable situación con el dólar (o las sanciones). Realmente no quería obtener ningún bloqueo de proveedor. ¿La tercera opción, en la que analizamos lo que tenemos en el mercado de código abierto? ¿Qué soluciones se ofrecen? Tenemos nuestro propio hardware, queda por elegir algo de estas muchas aplicaciones de código abierto.
Entonces, al final, nuestra investigación y experimentos nos llevaron a un software llamado OpenStack. Softinke, por supuesto, suena demasiado grosero.
OpenStack es un software completo, de hecho, es un conjunto de servicios para construir una nube pública o privada. OpenStack es una solución de código abierto. Todos los servicios están escritos en python. Cada servicio es responsable de su tarea, tiene su propia API.
Y se ve así. Recuerda esta foto. Luego volveremos a ella. Hay servicios compartidos (generales). Hay servicios para este propósito: Computación, Redes, Almacenamiento. Y nuestra aplicación o usuario trabaja con estos servicios.
Solución de código abierto. El lanzamiento se lleva a cabo medio año. El lanzamiento incluye componentes básicos. Cada versión incluye nuevos componentes que aparecen inicialmente en esta incubadora. Pasan algún tiempo allí, reparan errores allí, se estabilizan, etc. Y en algún momento, la comunidad decide que este componente debe incluirse en los componentes básicos de la próxima versión. También hay muchos correos diferentes, reuniones, conferencias. La conferencia más grande es la Cumbre OpenStack. Se celebra todos los años. Y en la última Cumbre OpenStack hubo alrededor de cuatro o cinco mil participantes. Un gran evento Muchos informes.
Muchas personas están contribuyendo a esta decisión. Aquí solo di una lista de tales tops. Esta lista es suficiente para comprender qué tan serio es el proyecto y qué compañías y cuántos recursos invierten en él.
Cómo resolvimos nuestros problemas de infraestructura.
- Uno de los componentes de OpenStack es el planificador, que selecciona el host en el que se creará la máquina virtual.
- El equipo ahora tiene sus propios recursos. Esta es la cantidad de CPU, memoria y más. Nos deshicimos de este escenario para crear un virtual en tiket (aplicación).
- OpenStack es un conjunto de servicios que es. Tomamos solo el kit básico que satisfizo nuestras necesidades.
- Como OpenStack es de código abierto, es posible modificarlo.
- Cada servicio tiene una API. Hay compilaciones de python. Es decir, es bastante simple interactuar con cada servicio y escribir sus propios enlaces.
- Aislamiento Podemos aislar equipos para nosotros en proyectos, en zonas de agregación, en redes, etc.
Los desarrolladores del equipo recibieron infraestructura como servicio. ¿Cómo se ve?
Hay dos conceptos de pila y plantilla. Stack es un conjunto de recursos en la nube: máquinas virtuales, redes, registros dns y más. Una plantilla es una descripción de esta pila. En el caso de OpenStack, este es un archivo YAML normal. Aquí está parte del archivo. Dice que existe una entidad como un servidor con un servidor interno de tipo OS Nova. Para su funcionamiento normal, necesita una dirección IP y un registro DNS. Aquí, los parámetros de nombre se aceptan como entrada, el sabor es una descripción de los recursos que necesita este servidor. Sistema operativo de imagen. nombre_clave: qué clave pública colocar al implementar el servidor. Tenemos todas estas plantillas en el repositorio de cada una en git. Todos tienen acceso. Todos pueden enviar una solicitud de extracción.
Y la creación de Stack es la siguiente. Heat es el componente OpenStack responsable de la orquestación. Decimos esto en este contexto. Esta es una gran utilidad que instalamos para nosotros mismos. Decimos querido calor, créanos una pila con ese nombre, aquí hay una descripción de los recursos que necesitamos para crear esta pila. Y aquí está la entrada que requiere nuestra plantilla, que describe nuestra pila. Lo cargamos en calor. Él susurra allí por un tiempo, crea todos los recursos necesarios para nosotros dentro de sí mismo. Y también en esta plantilla aquí podemos especificar la salida. Cuando Heat creó Stack, puede generar información: dirección IP, acceso y el resto que le pedimos. Además, ya podemos aplicar esta información para una mayor automatización.
Para que no pienses que OpenStack es simple y barato, te diré para qué hardware funciona OpenStack. El panel de control gira en 3 infra-nodos. Estos son servidores de hierro con tales recursos. Esta es la configuración recomendada para la conmutación por error.
También tenemos dos nodos de red KVM que sirven a nuestra red.
Recursos de equipo giramos en 8 nodos de cómputo. Se dividen en 3 zonas de agregación. Se asigna un nodo de cálculo por zona para la prueba de carga. Allí, los servidores se crean solo del equipo de prueba de carga. Para no interferir con el resto. Tenemos una zona de agregación para nuestro proyecto interno de automatización de pruebas de GUI. Él tiene ciertos requisitos. Se encuentra en una zona de agregación separada. Todos los demás entornos de desarrollo, servidores, entornos de prueba están girando en la tercera zona de agregación grande. Nos lleva 6 nodos de cálculo.
Hacemos girar unas 350 máquinas virtuales para todos los equipos.
¿Qué entendimos cuando ya habíamos avanzado? Para implementar y soportar este software, necesita un equipo. Equipo dependiendo de tus recursos.
Los equipos deben tener ciertas competencias.
En primer lugar, es naturalmente Ansible. La implementación de OpenStack está escrita en Ansible. Hay un proyecto OpenStack-Ansible . Si desea agregar OpenStack-Ansible a sus necesidades, las personas que harán esto deben tener Ansible.
Experiencia de virtualización. Necesita poder cocinar la virtualización, necesita sintonizar. Comprende cómo funciona.
La misma red
Lo mismo ocurre con los servicios de back-end que OpenStack utiliza para su trabajo. Esta base de datos es MySQL Galera y RabbitMQ como una cola.
Comprender cómo funciona DNS. Cómo configurarlo
OpenStack está escrito en python. Debes poder leer el código. Idealmente, debe poder parchear. Buscar correcciones en la comunidad. Poder debutar el código. Todo esto es muy útil. Si un equipo tiene ese enfoque, sabe cómo usar un enfoque como Infraestructura como código, como ansible, por ejemplo, todos los cambios se almacenan en el código, entonces no tendrán problemas que surjan al configurar las manos.
Integración continua. La suite de servicios OpenStack incluye un servicio como tempestad . En él, todas las pruebas están escritas en todos los componentes. Si cambiamos la configuración, ejecutamos un diploma por separado en la instalación del dispositivo Todo en Uno y ejecutamos tempestad ; observamos si algo se ha caído con nosotros. CI está configurado y el equipo debe entender esto y debe poder configurar todo esto.
Porque todo parece simple y atractivo dado.
Pero cuando comienzas a profundizar más en eso, entiendes que, de hecho, todo se ve así. Esto puede ser una sorpresa para alguien.
La introducción de OpenStack no es solo una solución técnica. Además, debe poder vender, para poder explicar a los equipos el nuevo paradigma de cómo funcionan ahora, qué beneficios trae. Cómo trabajar con él para obtener ganancias. Escribimos mucha documentación. La documentación tiene la forma de inicio rápido (inicio rápido), primeros pasos (primeros pasos). Es decir, lo que debe hacerse para facilitarle la vida rápidamente y no gastar mucho tiempo en ello.
Llevamos a cabo TechTalk, hablamos, elaboramos temas, mostramos, hablamos, ahora mira, ahora puedes obtener tu producto de la siguiente manera. literalmente aquí estamos escribiendo una plantilla, la estamos lanzando. Todo es bastante simple. Ahora no tiene que ir a los administradores y pedirles algo allí.
En casos especialmente difíciles cuando el proyecto es complejo, tiene muchos casos, llegamos a equipos, trabajamos directamente con los equipos. Es decir, de alguna manera intentaron ayudarlos en la automatización de los procesos. Prepara todos los equipos. Herido algunos errores. Entendieron que no configuramos algo mal allí. En general, trabajo apretado con equipos.
Recibimos un despliegue rápido de productos. Anteriormente, para recibir productos, era necesario realizar muchas acciones manuales, interactuar con muchas personas. Ahora obtenemos la creación de Envinronment (Entorno, servidor) por botón. Y si la implementación está escrita y funciona para el proyecto, la implementamos mediante el botón o el nuevo Envinronment (Entorno, servidores) con el producto instalado.
La falta de una infraestructura normal fue un bloqueo para algunos equipos en términos de implementación del proceso de CI dentro del equipo. Solucionamos los problemas de infraestructura, los equipos creados en el servidor de CI, configuraron la tubería, las máquinas virtuales se crean en la tubería. En general, dieron un impulso al desarrollo de estos procesos.
También ayudaron a algunos productos internos que utilizan la infraestructura para automatizar las pruebas. VM Master es un producto que prueba nuestro en línea. Necesita crear muchas máquinas virtuales para ingresar al sitio desde diferentes navegadores, siga algunos pasos para comprender que en línea funciona en todos los navegadores conocidos. Es decir, lo ayudaron mucho.
Una buena ventaja es que descargaron los administradores (ellos mismos). Porque en algún momento, la actividad de crear una máquina virtual comenzó a ocupar tiempo en el espacio. Y todos comenzaron a ponerse nerviosos. Ahora estamos haciendo cosas interesantes, productos complejos. Nos deshicimos de la tarea de rutina.
Preguntas?
Pregunta: ¿Cuánto tiempo se tardó en implementar OpenStack?
Respuesta: La pregunta es complicada porque tuvimos un proceso que puede acomodar una serie de comedia. Tiene un umbral de entrada alto. Comprendemos toda nuestra infraestructura, buscamos una solución: nos llevó tres meses. Luego, en un mes, implementamos la primera instalación en algún lugar. Agregamos un par de proyectos allí. Ellos vivieron allí. Entonces ocurrió el factor humano: le dispararon a la cabeza de esta instalación. Nos dimos cuenta de que la falta de tolerancia a fallas es mala. Luego esperamos la plancha.
Pregunta: ¿Utiliza el soporte pagado?
Respuesta: no, no lo usamos.
Pregunta: ¿Qué versión de OpenStack estás usando?
Respuesta: Las versiones de OpenStack se llaman palabras. Primero fue Juno, luego pasamos a Liberty.
Pregunta: ¿Las máquinas virtuales se crean en tubería de integración continua?
Respuesta: Construir en Jenkins puede causar calor y crear una máquina virtual.
Pregunta: ¿Ha encontrado problemas con el intercambio de recursos? En términos generales, 2 máquinas virtuales están en el mismo servidor físico. Uno de ellos comienza a cargar un disco, por ejemplo, una base de datos. Si te enfrentaste, ¿cómo decidiste?
Respuesta: No encontramos problemas con el intercambio de recursos. Los productos de cada uno no interfieren mucho. Presentamos los guiones. Si necesita ejecutar un escenario pesado, ejecutar pruebas de carga, debe ir al equipo de prueba de carga y ellos ejecutarán la prueba de carga.
: - ?
: OpenStack . . . .
: . . OpenStack ?
: . OpenStack . .
: OpenStack?
: . proxmox. OpenStack.
: DevOps?
: DevOps , . , , .
PS 2019 OpenStack heat Terraform .