En nuestra empresa se está llevando a cabo el proceso de incorporación del equipo SRE. Yo entré en toda esta historia desde el lado del desarrollo. Durante el proceso, surgieron pensamientos e ideas que quiero compartir con otros desarrolladores. En este artículo reflexivo, hablo sobre lo que está sucediendo, cómo está sucediendo y cómo todos pueden seguir con esto.
Continuación de la serie de artículos escritos a partir de las presentaciones en nuestro evento interno. :
2. Infrastructure as code. (Estás aquí)
3. Generación de contratos Typescript a partir de modelos C#. (En progreso…)
4. Introducción al algoritmo de consenso Raft. (En progreso…)
…
Decidimos formar un equipo SRE, implementando las ideas de . Contratamos a programadores de nuestros propios desarrolladores y los enviamos a capacitaciones durante varios meses.
El equipo enfrentó las siguientes tareas de capacitación:
- Describir nuestra infraestructura, que en su mayoría se encuentra en Microsoft Azure, en forma de código (Terraform y todo lo relacionado).
- Enseñar a los desarrolladores a trabajar con la infraestructura.
- Preparar a los desarrolladores para turnos de guardia.
Introducimos el concepto de Infrastructure as code.
En el modelo habitual (administración clásica), el conocimiento sobre la infraestructura se encuentra en dos lugares:
- O bien en la mente de los expertos.
- O bien, esta información se encuentra en algunas máquinas, de las cuales solo una parte son conocidas por los expertos. Pero no es seguro que una persona externa (en caso de que nuestro equipo entero muera repentinamente) pueda entender qué y cómo funciona. En la máquina puede haber mucha información: accesos, trabajos programados, un disco montado (ver ) y simplemente una lista interminable de lo que puede estar sucediendo. Es difícil entender qué está sucediendo realmente.
En ambos casos, nos encontramos atrapados, volviéndonos dependientes:
- ya sea de una persona, que es mortal, susceptible a enfermedades, enamoramientos, cambios de humor y, simplemente, despidos;
- o de una máquina física que también puede fallar, ser robada, presentar sorpresas y generar inconvenientes.
Por supuesto, surge la solución de que, idealmente, todo debe ser trasladado a un código legible, mantenible y bien escrito.
La infraestructura como código (Infrastructure as Code – IaC) es la descripción de toda la infraestructura disponible en forma de código, así como las herramientas asociadas para trabajar con ella y materializarla en infraestructura real.
¿Por qué traducir todo a código?Las personas no son máquinas. No pueden recordar todo. La reacción de un ser humano y una máquina es diferente. Todo lo que está automatizado tiene el potencial de funcionar más rápido que cualquier cosa que haga un humano. Lo más importante es tener una única fuente de verdad (single source of truth).
¿De dónde provienen los nuevos ingenieros SRE?Así que decidimos incorporar nuevos ingenieros SRE, ¿pero de dónde los conseguimos? El libro con las respuestas correctas () nos dice: de los desarrolladores. Ellos ya trabajan con código, y tú logras alcanzar el estado ideal.
Buscamos intensamente y durante mucho tiempo en el mercado laboral fuera de nuestra empresa. Pero hemos de reconocer que no encontramos a nadie que cumpliera con nuestros requisitos. Tuvimos que buscar entre nuestros propios empleados.
Problemas de la infraestructura como código
Ahora veamos ejemplos de cómo la infraestructura puede estar incorporada en el código. El código está bien escrito, de calidad, con comentarios y sangrías.
Ejemplo de código de Terraform.
Ejemplo de código de Ansible.
Señores, pero si todo fuera así de simple. Estamos en el mundo real, y siempre está listo para sorprenderte, presentarte sorpresas y problemas. No se puede evitar eso aquí.
1. El primer problema es que en la mayoría de los casos, IaC es algún tipo de DSL.
Y un DSL, por su parte, es una descripción de la estructura. Más precisamente, de lo que debes tener: Json, Yaml, modificaciones de algunas grandes empresas que han creado su propio DSL (en Terraform se utiliza HCL).
El problema es que puede fácilmente no incluir cosas tan familiares como:
- variables;
- condiciones;
- a veces faltan comentarios, por ejemplo, en Json no están previstos por defecto;
- funciones;
- y ni siquiera he mencionado cosas de alto nivel como clases, herencia y todo eso.
2. El segundo problema de este código es que a menudo se trata de un entorno heterogéneo.Por lo general, trabajas con C#, es decir, con un solo lenguaje, un solo stack, un solo ecosistema. Y aquí tienes una gran diversidad de tecnologías.
Es una situación bastante real cuando un bash con Python ejecuta un proceso en el que se inyecta un JSON. Lo analizas, luego otro generador produce 30 archivos más. Para todo esto, se reciben variables de entrada desde Azure Key Vault, que son extraídas por un plugin de drone.io, escrito en Go, y estas variables pasan por un YAML, el cual fue generado a partir de un template de jsonnet. Es bastante complicado tener un código estrictamente bien descrito cuando tienes un entorno tan diverso.
El desarrollo tradicional para una única tarea se realiza con un solo idioma. Aquí, sin embargo, trabajamos con muchos idiomas.
3. El tercer problema es la herramienta. Estamos acostumbrados a editores excelentes (Ms Visual Studio, Jetbrains Rider) que hacen todo por nosotros. Y incluso si cometemos un error, ellos nos lo dirán. Parece que esto es normal y natural.
Pero está ahí VSCode, que tiene algunos plugins que se instalan, son mantenidos o no. Salen nuevas versiones y no son soportadas. Una transición banal a la implementación de una función (incluso si existe) se convierte en un problema complicado y no trivial. Un simple cambio de nombre de una variable implica un reemplazo en el proyecto de una decena de archivos. Tendrás suerte si reemplaza lo que se necesita. Por supuesto, hay iluminación en algún lugar, hay autocompletado, y en algunos casos hay formateo (aunque en mi Terraform en Windows no funciona).
En el momento de escribir este artículo no han lanzado aún para soportar la versión 0.12, aunque ya se ha publicado hace 3 meses.
Ha llegado el momento de olvidar…
- La depuración.
- Herramienta de refactorización.
- Autocompletado.
- Detección de errores en la compilación.
Es gracioso, pero esto aumenta el tiempo de desarrollo y también incrementa la cantidad de errores que inevitablemente ocurren.
Lo más aterrador es que estamos obligados a pensar no en cómo diseñar, organizar los archivos en carpetas, descomponer, hacer el código mantenible, legible, etc., sino en cómo escribir correctamente este comando, porque lo escribí de manera incorrecta.
Como novato, intentas comprender Terraform, y el IDE no te ayuda en absoluto. Cuando hay documentación, entras y miras. Pero si estuvieras aprendiendo un nuevo lenguaje de programación, el IDE te sugeriría que hay un tipo así, y que otro no. Al menos, a nivel de int o string. Esto puede ser muy útil.
¿Y qué pasa con las pruebas?
Usted puede preguntar: "¿Cómo están las pruebas, señores programadores?" Los tipos serios lo prueban todo en producción, y es contundente. Aquí hay un ejemplo de una prueba unitaria para un módulo de Terraform desde el sitio. .
Tienen buena documentación. A Microsoft siempre le he apreciado su enfoque hacia la documentación y la enseñanza. Pero no hay que ser tío Bob para darse cuenta de que aquí no hay código perfecto. Fíjese en la validación, que se ha llevado a la derecha.
El problema de la prueba unitaria es que nosotros podemos verificar la corrección del Json en la salida. Introduje 5 parámetros y obtuve un montón de Json de 2000 líneas. Puedo analizar lo que está sucediendo aquí, validar el resultado de la prueba...
Es complicado analizar Json en Go. Y hay que escribir en Go, porque Terraform en Go es una buena práctica de probar en el mismo lenguaje en el que se escribe. La organización del código es muy débil. Sin embargo, esta es la mejor biblioteca para pruebas.
Microsoft mismo escribe sus módulos probándolos de esta manera. Por supuesto, esto es Open Source. Todo lo que menciono puede ser sometido a reparación. Puedo sentarme y arreglar todo en una semana, open source los plugins de VS Code, Terraform, hacer un plugin para Rider. Tal vez, escribir un par de analizadores, agregar linters, contribuir a la biblioteca de pruebas. Puedo hacerlo todo. Pero no debería estar ocupado con eso.
Mejores prácticas de Infrastructure as Code
Sigamos adelante. Si no hay pruebas en IaC, la IDE y las herramientas son deficientes, al menos deben existir las mejores prácticas. Simplemente fui a Google Analytics y comparé dos búsquedas: Terraform best practices y c# best practices.
¿Qué vemos? Estadísticas implacables en nuestra contra. En términos de cantidad de material, es lo mismo. En el desarrollo de C#, simplemente estamos bañados en materiales, tenemos super mejores prácticas, hay libros escritos por expertos, y también libros escritos sobre esos libros por otros expertos que critican esos libros. Un mar de documentación oficial, artículos, cursos de formación, y ahora incluso desarrollo open source.
En cuanto a la búsqueda sobre IaC: aquí está intentando reunir la información fragmentariamente a partir de conferencias de high load o HashiConf, de la documentación oficial y numerosos problemas en GitHub. ¿Cómo se supone que debemos distribuir estos módulos, qué debemos hacer con ellos? Parece un problema real... Sin embargo, hay una comunidad, señores, donde a cualquier pregunta le darán 10 comentarios en GitHub. Pero eso no es seguro.
Desafortunadamente, en este momento los expertos apenas están empezando a aparecer. Por ahora son demasiado pocos. Y la comunidad se encuentra en un nivel inicial.
¿Hacia dónde se dirige todo esto y qué hacer?
Se podría abandonar todo y volver a C#, al mundo de Rider. Pero no. ¿Por qué harías eso si no es para encontrar una solución? A continuación, presento mis conclusiones subjetivas. Puedes debatir conmigo en los comentarios, será interesante.
Personalmente, apuesto por varias cosas:
- El desarrollo en este campo avanza muy rápido. Presento un gráfico de búsquedas sobre DevOps.
Puede que sea un tema de moda, pero el hecho de que el área esté en crecimiento ofrece cierta esperanza.Si algo crece tan rápido, definitivamente aparecerán personas inteligentes que nos dirán cómo hacerlo correctamente y cómo no. El aumento de la popularidad lleva a que tal vez alguien tenga el tiempo de finalmente escribir un plugin para jsonnet para vscode, que permita ir directamente a la implementación de una función, en lugar de buscarla a través de ctrl+shift+f. Cuando todo avanza, hay más materiales. La reciente publicación de un libro de Google sobre SRE es un excelente ejemplo de esto.
- Existen metodologías y prácticas en el desarrollo tradicional que podemos aplicar con éxito aquí. Sí, hay matices en las pruebas y un entorno heterogéneo, falta de herramientas, pero se han acumulado una gran cantidad de prácticas útiles que pueden servir y ayudar.
Un ejemplo simple: el trabajo colaborativo a través de pair programming. Esto ayuda mucho a aclarar las cosas. Cuando tienes un compañero al lado que también está tratando de entender algo, juntos comprenderán mejor.
Entender cómo se realiza el refactoring ayuda incluso en situaciones como esta. Es decir, puedes no cambiar todo de una vez, sino cambiar el nombramiento, luego cambiar la ubicación, y quizás luego destacar una parte; oh, aquí faltan comentarios.
Conclusión
A pesar de que mis reflexiones pueden parecer pesimistas, miro al futuro con esperanza y sinceramente deseo que todos (incluyéndonos) tengamos éxito.
Pronto se publicará la segunda parte del artículo. En ella contaré cómo intentamos aplicar prácticas de desarrollo ágil para mejorar nuestro proceso de aprendizaje y trabajo con la infraestructura.
Fuente: habr.com
