Infraestructura como código: primer conocido

Nuestra empresa está en proceso de incorporar al equipo SRE. Entré en toda esta historia desde el lado del desarrollo. En el proceso, tuve pensamientos e ideas que quiero compartir con otros desarrolladores. En este artículo de meditación, hablo sobre lo que sucede, cómo sucede y cómo todos los demás pueden vivir con él.

Continuación de una serie de artículos basados ​​en discursos en nuestro evento interno DevForum :

1. Gato Schrodinger sin caja: el problema del consenso en sistemas distribuidos.
2. Infraestructura como código. (Estas aqui)
3. Generación de contratos mecanografiados para modelos de C #. (En progreso ...)
4. Cómo los servidores están de acuerdo entre sí: algoritmo de consenso distribuido en balsa.
5. Infraestructura como código: cómo superar los problemas con XP.
...

Decidimos hacer que el equipo de SRE implementara ideas de google sre . Reclutamos programadores de sus propios desarrolladores y los enviamos a estudiar durante varios meses.

El equipo enfrentó las siguientes tareas de capacitación:

• Describa nuestra infraestructura, que se encuentra principalmente en Microsoft Azure en forma de código (Terraform y todo lo que existe).
• Enseñe a los desarrolladores cómo trabajar con infraestructura.
• Prepare a los desarrolladores para el deber.

Introduciendo el concepto de Infraestructura como código

En el modelo habitual del mundo (administración clásica), el conocimiento sobre infraestructura se encuentra en dos lugares:

1. O en forma de conocimiento en la mente de los expertos.
2. O esta información está en algunas máquinas de escribir, algunas de las cuales los expertos conocen. Pero no es un hecho que una persona del exterior (en caso de que todo nuestro equipo muera repentinamente) pueda descubrir qué funciona y cómo. Puede haber mucha información sobre la máquina: accesorios, tapones de corona, una unidad (ver montaje en disco ) y solo una lista interminable de lo que puede suceder. Es difícil entender lo que está sucediendo en la realidad.

En ambos casos, estamos atrapados y nos volvemos dependientes:

• o de una persona que es mortal, propensa a la enfermedad, se enamora, cambia de humor y simplemente despidos banales;
• o de una máquina que funciona físicamente y que también se cae, roba, presenta imprevistos e inconvenientes.

No hace falta decir que, idealmente, todo debería traducirse en código escrito de alta calidad, legible y compatible con humanos.

Por lo tanto, la infraestructura como código (Incfastructure as Code - IaC) es una descripción de toda la infraestructura disponible en forma de código, así como las herramientas relacionadas para trabajar con ella y obtener la infraestructura real a partir de ella.

Infraestructura como problemas de código

Ahora veamos ejemplos de cómo la infraestructura puede conectarse al código. El código está bien escrito, de alta calidad, con comentarios y sangrías.

Código de muestra de Terraforma.



Código de muestra de Ansible.



Señores, pero si todo fuera tan simple! Estamos contigo en el mundo real, y él siempre está listo para sorprenderte, para presentarte sorpresas, problemas. No sin ellos aquí.

1. El primer problema es que, en la mayoría de los casos, IaC es algún tipo de dsl.

Y DSL, a su vez, es una descripción de la estructura. Más precisamente, lo que debe tener: Json, Yaml, modificaciones de algunas grandes empresas que crearon su propio dsl (HCL se usa en la terraforma).

El problema es que en él fácilmente no puede haber cosas tan familiares para nosotros como:

• Variables
• condiciones;
• en algún lugar no hay comentarios, por ejemplo, en Json, por defecto no se proporcionan;
• funciones
• y no estoy hablando de cosas de tan alto nivel como clases, herencia y todo eso.

2. El segundo problema con este código suele ser un entorno heterogéneo . Por lo general, te sientas y trabajas con C #, es decir con un idioma, una pila, un ecosistema. Y aquí tienes una gran variedad de tecnologías.

Es una situación muy real cuando un bash con python inicia un proceso en el que Json se resbala. Lo analiza, luego otro generador genera otros 30 archivos. Por todo esto, entran las variables de entrada de Azure Key Vault, que se unen mediante el complemento para drone.io escrito en Go, y estas variables pasan a través de yaml, que se obtuvo como resultado de la generación del motor de plantillas jsonnet. Es bastante difícil tener un código estrictamente bien descrito cuando se tiene un entorno tan diverso.

El desarrollo tradicional en el marco de una tarea viene con un idioma. Aquí trabajamos con una gran cantidad de idiomas.

3. El tercer problema es tuling . Estamos acostumbrados a editores geniales (Sra. Visual Studio, Jetbrains Rider) que hacen todo por nosotros. E incluso si estamos aburridos, dirán que estamos equivocados. Parece ser normal y natural.

Pero en algún lugar cercano hay un VSCode, en el que hay algunos complementos que de alguna manera están instalados, admitidos o no. Se lanzaron nuevas versiones y no fueron compatibles. Una transición banal a la implementación de una función (incluso si existe) se convierte en un problema complejo y no trivial. Un simple cambio de nombre de una variable es una repetición en un proyecto de una docena de archivos. Es una suerte si es algo que necesita ser reparado. Por supuesto, hay retroiluminación en algunos lugares, hay compilación automática, en algún lugar hay formato (aunque no comencé las ventanas en la terraforma).

En el momento de la escritura, el complemento vscode-terraform aún no se ha lanzado para admitir la versión 0.12, aunque ya se ha lanzado durante 3 meses.

Es hora de olvidarse de ...

1. Depuración
2. Herramienta de refactorización.
3. Autocompletado.
4. Detecta errores de compilación.

Es divertido, pero también aumenta el tiempo de desarrollo y aumenta la cantidad de errores que inevitablemente ocurren.

Lo peor es que nos vemos obligados a pensar no en cómo diseñar, descomponer archivos en carpetas, descomponer, hacer que el código sea compatible, legible, etc., sino en cómo escribiría este comando correctamente, porque de alguna manera lo escribí incorrectamente .

Como principiante, estás tratando de aprender terraformas, y el IDE no te ayuda en esto en absoluto. Cuando hay documentación, entraron, miraron. Pero si tuviera que ingresar un nuevo lenguaje de programación, entonces el IDE sugeriría que existe ese tipo, pero no lo hay. Al menos a nivel int o de cadena. Esto a menudo es útil.

¿Pero qué hay de las pruebas?

Usted pregunta: "¿Qué pasa con las pruebas, caballeros programadores?" Los chicos serios están probando todo en la producción, y es difícil. Aquí hay un ejemplo de la prueba unitaria para el módulo terraform del sitio web de Microsoft .



Tienen buena documentación. Siempre me ha gustado Microsoft por su enfoque de documentación y capacitación. Pero no necesita ser tío Bob para comprender que este no es un código ideal. Tenga en cuenta la validación presentada a la derecha.

El problema con la prueba de la unidad es que usted y yo podemos verificar la exactitud de la salida de Json. Lancé 5 parámetros, me dieron una plantilla Json para 2000 líneas. Puedo analizar lo que sucede aquí, validar el resultado de la prueba ...

Es difícil analizar a Json en Go. Y debe escribir en Go, porque las terraformas en Go son una buena práctica de lo que prueba en el idioma en el que escribe. La organización misma del código es muy débil. Al mismo tiempo, es la mejor biblioteca para realizar pruebas.

Microsoft mismo escribe sus módulos, probándolos de esta manera. Por supuesto, esto es de código abierto. Todo lo que hablo de ti puede venir y reparar. Puedo sentarme y arreglar todo en una semana, abrir complementos de código VS, terraformas, hacer un complemento de piloto. Tal vez escriba un par de analizadores, linters de rosca, copie la biblioteca para probar. Puedo hacer todo Pero no tengo que hacer esto.

Infraestructura de mejores prácticas como código

Vamos más lejos Si no hay pruebas en IaC, mal con IDE y ajuste, entonces debería haber al menos mejores prácticas. Acabo de ir a google analytics y comparé dos consultas de búsqueda: las mejores prácticas de Terraform y las mejores prácticas de c #.



Que vemos Las estadísticas despiadadas no están a nuestro favor. Por la cantidad de material, lo mismo. En el desarrollo de C #, solo nos bañamos en materiales, tenemos las mejores prácticas, hay libros escritos por expertos y también libros escritos en libros de otros expertos que critican esos libros. El mar de documentación oficial, artículos, cursos de capacitación, ahora también desarrollo de código abierto.

En cuanto a la solicitud de IaC: aquí, poco a poco, está tratando de recopilar la información de los informes de la alta carga o HashiConf, de la documentación oficial y numerosos problemas en el github. ¿Cómo se distribuyen estos módulos, qué hacer con ellos? Parece que este es un problema real ... Hay una comunidad, caballeros, donde recibirán 10 comentarios en un github para cualquier pregunta. Pero esto no es exacto.

Desafortunadamente, en este momento, los expertos apenas comienzan a aparecer. Si bien hay muy pocos de ellos. Y la comunidad misma se cuelga al nivel de los primordios.

¿A dónde va todo y qué hacer?

Puedes soltar todo y volver a C #, al mundo de un piloto. Pero no ¿Por qué harías esto si no encontraras una solución? A continuación, doy mis conclusiones subjetivas. Puedes discutir conmigo en los comentarios, será interesante.

Personalmente, me puse algunas cosas:

1. El desarrollo en esta área es muy rápido. Doy el calendario de solicitudes de DevOps.
   
   
   
   Quizás el tema sea exagerado, pero el hecho de que la esfera esté creciendo nos da algo de esperanza.
   
   Si algo crece tan rápido, seguramente aparecerán personas inteligentes que dirán cómo hacerlo y cómo no hacerlo. El aumento de la popularidad lleva al hecho de que tal vez alguien tenga tiempo de agregar finalmente el complemento jsonnet para vscode, lo que nos permitirá proceder a la implementación de la función, en lugar de buscarla a través de ctrl + shift + f. Cuando todo se desarrolla, aparecen más materiales. El mismo libro de Google sobre SRE es un gran ejemplo.
2. Existen técnicas y prácticas desarrolladas en el desarrollo convencional que podemos aplicar con éxito aquí. Sí, hay matices con las pruebas y un entorno heterogéneo, sintonización insuficiente, pero se ha acumulado una gran cantidad de prácticas que pueden ser útiles y útiles.
   
   Un ejemplo trivial: colaboración a través de la programación en pareja. Ayuda mucho resolverlo. Cuando tienes un vecino cerca que también está tratando de entender algo, juntos lo entenderán mejor.
   
   Comprender cómo se realiza la refactorización ayuda a producirlo incluso en tal situación. Es decir, puede cambiar no todo a la vez, sino cambiar el nombre, luego cambiar la ubicación, luego puede resaltar alguna parte, oh, pero no hay suficientes comentarios.

Conclusión

A pesar de que mi razonamiento puede parecer pesimista, espero con ansias el futuro y espero sinceramente que nosotros (y usted) tengamos éxito.

Luego viene la segunda parte del artículo . En él, hablo sobre cómo usamos prácticas de programación extremas para mejorar nuestro proceso de aprendizaje y trabajar con la infraestructura.