Get best of the week

Portal de entornos de prueba, o guarde nuestros devops



Hace un par de a帽os, nos sentimos en una especie de sue帽o surrealista. Todos los que estaban alrededor acudieron a la nube para realizar pruebas (es conveniente expandir y colapsar los entornos de prueba) e intentamos averiguar qu茅 herramientas se deben entregar de forma inmediata. Para hacer esto, nosotros, junto con los clientes, descubrimos c贸mo funcionan los procesos devops. Y result贸 que solo unas pocas empresas en Rusia usan la automatizaci贸n de manera competente.

Explicar茅 de inmediato que, en su mayor parte, hablamos con quienes est谩n involucrados en el desarrollo de hasta 150-200 personas en la empresa, o con industrias donde la TI es tradicionalmente dif铆cil. Las compa帽铆as m谩s grandes usualmente tienen un proceso y su propia nube, y vienen a nosotros para una implementaci贸n de respaldo.

La producci贸n suele estar bien establecida. Hay un ciclo, un plan de lanzamiento, hay un objetivo, el c贸digo va al objetivo junto con los desarrolladores.

Las pruebas y el control de calidad tambi茅n se depuran con mayor frecuencia.

Y entre ellos hay un abismo. Y DevOps est谩 tratando de llenarlo. Este superhombre debe tomar el lanzamiento (e idealmente ensamblarlo en Jenkins o algo similar), crear un autom贸vil, implementar todo all铆, verificar el trabajo, tal vez pasar un par de pruebas preliminares y entregarlo a QA.

驴Cu谩l es el problema?


Cuando un producto es un tipo peque帽o de aplicaci贸n web, no hay problema. Directamente, el desarrollador o probador toma la base de datos de la copia de seguridad, se conecta a la 煤ltima versi贸n y se ejecuta.

Pero cuando el producto crece un poco, se produce el colapso de la producci贸n.

Devops obtuvo la liberaci贸n, pero la tom贸 y no tuvo la intenci贸n. Luego comienza a buscar el extremo y a clasificar a los desarrolladores. Se puede recopilar un comunicado durante varias horas por la noche, y los desarrolladores generalmente se sientan en la oficina durante el d铆a.

Casi todo se hace a mano. Es decir, las operaciones est谩n sentadas y mirando la barra de progreso de la asamblea. Porque cualquier lugar puede salir mal. Los que tienen m谩s energ铆a unen todo esto con sus propios guiones, y a veces resulta muy bonito y eficiente. Pero con mayor frecuencia vemos que el plan de entrega de liberaci贸n se lleva a cabo en pasos, una persona separada es responsable de cada paso, y es m谩s f谩cil para 茅l repetir el procedimiento veinte veces con las manos, porque de lo contrario resulta que no funciona.

Al mismo tiempo, alguien deber铆a ser responsable del proceso en su conjunto, y este es el principal factor de detenci贸n. Un intento de encontrar a esa persona a menudo termina en un fracaso. A saber, 茅l es responsable de la automatizaci贸n, y es 茅l quien est谩 interesado en ella. Responsable de las secciones individuales y luego transferir las flechas a alguien en desarrollo, por supuesto, siempre es m谩s f谩cil.

La virtualizaci贸n agrega m谩s aspectos del caos. Los entornos virtuales son siempre un desastre. La persona responsable de la agrupaci贸n (servidor, rack), est谩 mal orientada, a qui茅n pertenece, si es necesario o no. Es l贸gico que el administrador del sistema no tenga que preocuparse mucho por lo que sucede con los desarrolladores. Pero los devops deber铆an, pero su papel generalmente no implica tal conocimiento. Y tiene miedo de apagar el exceso, porque no comprende si ser谩 necesario o no.

Entonces es necesario emitir cuentas internas para los acuerdos mutuos de departamentos. Alguien considera el tiempo de actividad, alguien considera el uso del procesador, luego comparten por igual o en alguna proporci贸n los costos como la electricidad y el trabajo de los administradores.

Inesperadamente, pero no hay producto terminado


Parece que todo este transportador deber铆a estar cubierto con alg煤n tipo de producto. Hay muchas buenas soluciones puntuales. El mismo Ansible se implementa perfectamente, pero no sabe c贸mo dirigir m谩quinas virtuales. Y los hipervisores pueden. Existen todas las herramientas para la creaci贸n de scripts de Devops, puede conectar los m贸dulos ... Solo necesita tomar y ensamblar de esta cadena de software, 驴verdad?

No de esta manera. Los bancos y las empresas estatales vinieron con el deseo de realizar pruebas en la nube. Todo buen guardia de seguridad es propenso a la paranoia, a menudo con buenas razones. Para IB Bank, cada nueva instalaci贸n es un factor muy molesto. Conozco un caso cuando las operaciones arrastraron a Jenkins y Terraform a la infraestructura, desplegaron bash detr谩s de 茅l y luego el DBMS que contiene todo esto. Result贸 ser un buen transportador semiautom谩tico, que podr铆a terminarse hasta un despliegue totalmente aut贸nomo. Solo por seguridad de la informaci贸n fue un desastre.

Quer铆an todo en uno. Y para administrar la m谩quina virtual (y varios proveedores, incluido Openstack). El Cliente en una aplicaci贸n puede tener Vmvar e Hyper-in, y algo m谩s viejo y terrible para soportar FreeBSD u OS / 2.

Necesitamos nuestra bicicleta


En general, escribimos nuestra plataforma. Debajo del cap贸 - Ansible, listo para usar - integraci贸n con Jenkins. Puedes escribir tus propios guiones para Ansible. Puede hacer todo, desde la recopilaci贸n de subredes hasta la administraci贸n de versiones.



El portal vive en el paradigma del entorno de prueba. Esta es su esencia principal. Un entorno de prueba = una subred. Adem谩s, si es realmente malo, hay integraci贸n con el RPA en caso de que no haya API, y necesita un robot para emular las acciones del usuario y hacer clic en los botones de la interfaz. Hay facturaci贸n, el tiempo de actividad y la utilizaci贸n se consideran desde la aplicaci贸n a la aplicaci贸n: hasta que se haya escrito la solicitud de destrucci贸n, el dinero gotear谩.

As铆 es como se ve. Crear un entorno utilizando una plantilla:



Agregar una m谩quina virtual:



Secuencias de comandos:



Como result贸 un poco m谩s tarde, las quejas "No quiero ejecutar en 50 sistemas" se escuchan de todas partes. Est谩bamos en un dolor importante. Cualquier cliente grande con pruebas quer铆a algo similar, pero por alguna raz贸n no lo resolvi贸 o lo resolvi贸 organizacionalmente con personas de guiones. Los problemas son muy diferentes, comenzando desde computadoras virtuales sin nombre (lo eliminaron, y luego alguien record贸 que era necesario) y terminando con el hecho de que nadie quiere ser responsable de los scripts continuos. Las secuencias de comandos acumuladas son dif铆ciles de escribir, las regulaciones tambi茅n sufren. En alg煤n momento del ciclo deber铆a haber un anonimato de los datos, y parece que "en alg煤n momento a principios de a帽o hicimos una base de datos an贸nima", y el software cambi贸 seis veces, los datos se actualizaron.

En general, si algo similar te duele de repente, entonces solo ven a mirar. El acceso de demostraci贸n est谩 disponible en Technoserv Cloud .

More articles:


All Articles