Nuestra empresa está en el proceso de incorporar un equipo de SRE. Entré en toda esta historia desde el lado del desarrollo. En el proceso, se me ocurrieron ideas y conocimientos que quiero compartir con otros desarrolladores. En este artículo de reflexión hablo de lo que está pasando, cómo está pasando y cómo todos podemos seguir viviendo con ello.
Continuación de una serie de artículos escritos a partir de discursos en nuestro evento interno. :
2. Infraestructura como código. (Usted está aquí)
3. Generación de contratos Typecript utilizando modelos C#. (En curso...)
4. Introducción al algoritmo de consenso Raft. (En curso...)
...
Decidimos crear un equipo de SRE, implementando las ideas . Reclutaron programadores entre sus propios desarrolladores y los enviaron a entrenar durante varios meses.
El equipo tenía las siguientes tareas de formación:
- Describa nuestra infraestructura, que se encuentra principalmente en Microsoft Azure en forma de código (Terraform y todo lo demás).
- Enseñe a los desarrolladores cómo trabajar con la infraestructura.
- Prepare a los desarrolladores para el deber.
Introducimos el concepto de Infraestructura como código
En el modelo habitual del mundo (administración clásica), el conocimiento sobre infraestructura se ubica en dos lugares:
- O en forma de conocimiento en la cabeza de los expertos.
- O esta información se encuentra en algunas máquinas de escribir, algunas de las cuales son conocidas por los expertos. Pero no es un hecho que un extraño (en caso de que todo nuestro equipo muera repentinamente) pueda descubrir qué funciona y cómo funciona. Puede haber mucha información en una máquina: accesorios, cronjobs, intimidados (ver. ) disco y simplemente una lista interminable de lo que puede pasar. Es difícil entender lo que realmente está pasando.
En ambos casos, nos encontramos atrapados en volvernos dependientes:
- o de una persona mortal, sujeta a enfermedades, enamoramientos, cambios de humor y despidos simplemente banales;
- o de una máquina que funciona físicamente, que también se cae, se la roban y presenta sorpresas e inconvenientes.
No hace falta decir que, idealmente, todo debería traducirse a un código bien escrito, mantenible y legible por humanos.
Por lo tanto, la infraestructura como código (Incfastructure as Code - IaC) es una descripción de toda la infraestructura existente en forma de código, así como las herramientas relacionadas para trabajar con ella e implementar una infraestructura real a partir de ella.
¿Por qué traducir todo a código?Las personas no son máquinas. No pueden recordarlo todo. La reacción de una persona y de una máquina es diferente. Cualquier cosa automatizada es potencialmente más rápida que cualquier cosa realizada por un humano. Lo más importante es una única fuente de verdad.
¿De dónde vienen los nuevos ingenieros SRE?Entonces decidimos contratar nuevos ingenieros de SRE, pero ¿de dónde sacarlos? Libro con respuestas correctas () nos dice: de los desarrolladores. Después de todo, trabajan con el código y tú logras el estado ideal.
Los buscamos mucho durante mucho tiempo en el mercado de personal fuera de nuestra empresa. Pero tenemos que admitir que no encontramos a nadie que se adaptara a nuestras peticiones. Tuve que buscar entre mi propia gente.
Problemas Infraestructura como código
Ahora veamos ejemplos de cómo la infraestructura se puede codificar en código. El código está bien escrito, de alta calidad, con comentarios y sangrías.
Código de ejemplo de Terraforma.
Código de ejemplo de Ansible.
Señores, ¡si fuera tan sencillo! Estamos en el mundo real y siempre está dispuesto a sorprenderte, presentarte sorpresas y problemas. Aquí tampoco puedo prescindir de ellos.
1. El primer problema es que en la mayoría de los casos, IaC es una especie de dsl.
Y DSL, a su vez, es una descripción de la estructura. Más precisamente, lo que debería tener: Json, Yaml, modificaciones de algunas grandes empresas que crearon su propio dsl (HCL se usa en terraform).
El problema es que es posible que no contenga cosas tan familiares como:
- variables;
- condiciones;
- en algún lugar no hay comentarios, por ejemplo, en Json, no se proporcionan de forma predeterminada;
- funciones;
- y ni siquiera estoy hablando de cosas de tan alto nivel como clases, herencia y todo eso.
2. El segundo problema con este tipo de código es que la mayoría de las veces se trata de un entorno heterogéneo.. Normalmente te sientas y trabajas con C#, es decir. con un idioma, una pila, un ecosistema. Y aquí tienes una enorme variedad de tecnologías.
Es una situación muy real cuando bash con python inicia algún proceso en el que se inserta Json. Lo analizas y luego algún otro generador produce otros 30 archivos. Para todo esto, las variables de entrada se reciben de Azure Key Vault, que se reúnen mediante un complemento para drone.io escrito en Go, y estas variables pasan a través de yaml, que se generó como resultado de la generación desde el 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 solo idioma. Aquí trabajamos con una gran cantidad de idiomas.
3. El tercer problema es el ajuste.. Estamos acostumbrados a editores geniales (Ms Visual Studio, Jetbrains Rider) que hacen todo por nosotros. Y aunque seamos estúpidos, dirán que estamos equivocados. Parece normal y natural.
Pero en algún lugar cercano está VSCode, en el que hay algunos complementos que de alguna manera están instalados, son compatibles o no. Salieron nuevas versiones y no fueron compatibles. Una transición banal hacia 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. Tendrás suerte si coloca lo que necesitas. Por supuesto, hay retroiluminación aquí y allá, hay autocompletar, en algún lugar hay formateo (aunque no funcionó para mí en terraform en Windows).
Al momento de escribir Aún no se han lanzado para admitir la versión 0.12, aunque se lanzó hace 3 meses.
Es hora de olvidarse de...
- Depuración.
- Herramienta de refactorización.
- Finalización automática.
- Detección de errores durante la compilación.
Es curioso, pero esto 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, organizar archivos en carpetas, descomponer, hacer que el código sea mantenible, legible, etc., sino en cómo puedo escribir este comando correctamente, porque de alguna manera lo escribí incorrectamente. .
Como principiante, estás intentando aprender terraformas y el IDE no te ayuda en absoluto. Cuando haya documentación, entra y mira. Pero si estuviera ingresando a un nuevo lenguaje de programación, el IDE le diría que existe tal tipo, pero no existe tal cosa. Al menos a nivel int o string. Esto suele ser útil.
¿Qué pasa con las pruebas?
Usted pregunta: "¿Qué pasa con las pruebas, señores programadores?" Los chicos serios prueban todo en producción y es difícil. Aquí hay un ejemplo de una prueba unitaria para un módulo terraform del sitio web. .
Tienen buena documentación. Siempre me ha gustado Microsoft por su enfoque en la documentación y la formación. Pero no es necesario ser el tío Bob para comprender que este no es un código perfecto. Tenga en cuenta la validación a la derecha.
El problema con una prueba unitaria es que usted y yo podemos verificar la exactitud de la salida Json. Ingresé 5 parámetros y me dieron una calza Json con 2000 líneas. Puedo analizar lo que está pasando aquí, validar el resultado de la prueba...
Es difícil analizar Json en Go. Y necesitas escribir en Go, porque terraform en Go es una buena práctica para realizar pruebas en el idioma en el que escribes. La organización del código en sí es muy débil. Al mismo tiempo, esta es la mejor biblioteca para realizar pruebas.
La propia Microsoft escribe sus módulos, probándolos de esta manera. Por supuesto que es de código abierto. Todo lo que estoy hablando lo puedes venir y arreglar. Puedo sentarme y arreglar todo en una semana, abrir complementos de código VS, terraformar, crear un complemento para el usuario. Tal vez escriba un par de analizadores, agregue linters y contribuya con una biblioteca para realizar pruebas. Puedo hacer todo. Pero eso no es lo que debería estar haciendo.
Mejores prácticas Infraestructura como código
Vamonos. Si no hay pruebas en IaC, el IDE y el ajuste son malos, entonces al menos debería haber mejores prácticas. Acabo de ir a Google Analytics y comparé dos consultas de búsqueda: mejores prácticas de Terraform y mejores prácticas de C#.
¿Qué vemos? Las estadísticas despiadadas no están a nuestro favor. La cantidad de material es la misma. En el desarrollo de C#, simplemente estamos inundados de materiales, tenemos las mejores prácticas, hay libros escritos por expertos y también libros escritos sobre libros por otros expertos que critican esos libros. Un mar de documentación oficial, artículos, cursos de formación y ahora también desarrollo de código abierto.
En cuanto a la solicitud de IaC: aquí se intenta recopilar información poco a poco de informes de alta carga o HashiConf, de documentación oficial y numerosos problemas en Github. ¿Cómo distribuir estos módulos en general, qué hacer con ellos? Parece que esto es un problema real... Hay una comunidad, señores, donde para cualquier duda les darán 10 comentarios en Github. Pero no lo es exactamente.
Desafortunadamente, en este momento los expertos apenas comienzan a surgir. Son muy pocos hasta ahora. Y la comunidad misma se mantiene en un nivel rudimentario.
¿A dónde va todo esto y qué hacer?
Puedes dejar todo y volver a C#, al mundo del ciclista. Pero no. ¿Por qué te molestarías en hacer esto si no puedes encontrar una solución? A continuación presento mis conclusiones subjetivas. Puedes discutir conmigo en los comentarios, será interesante.
Personalmente apuesto por algunas cosas:
- El desarrollo en esta área está ocurriendo muy rápidamente. Aquí hay un cronograma de solicitudes para DevOps.
El tema puede ser exagerado, pero el hecho mismo de que la esfera esté creciendo da cierta esperanza.Si algo crece tan rápido, definitivamente aparecerán personas inteligentes que le dirán qué hacer y qué no hacer. El aumento de popularidad lleva al hecho de que tal vez alguien tenga tiempo de agregar finalmente un complemento a jsonnet para vscode, lo que le permitirá pasar a implementar la función, en lugar de buscarla mediante Ctrl+Shift+F. A medida que las cosas evolucionan, aparecen más materiales. La publicación de un libro de Google sobre SRE es un excelente ejemplo de esto.
- 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, herramientas insuficientes, pero se ha acumulado una gran cantidad de prácticas que pueden resultar útiles y provechosas.
Un ejemplo trivial: colaboración mediante programación en pareja. Ayuda mucho a resolverlo. Cuando tienes un vecino cerca que también está intentando entender algo, juntos entenderéis mejor.
Comprender cómo se realiza la refactorización ayuda a llevarla a cabo incluso en tal situación. Es decir, no puedes cambiar todo a la vez, sino cambiar el nombre, luego cambiar la ubicación, luego puedes resaltar alguna parte, oh, pero no hay suficientes comentarios aquí.
Conclusión
A pesar de que mi razonamiento puede parecer pesimista, miro hacia el futuro con esperanza y espero sinceramente que todo salga bien para nosotros (y para usted).
A continuación se prepara la segunda parte del artículo. En él, hablaré sobre cómo intentamos utilizar prácticas de desarrollo ágiles para mejorar nuestro proceso de aprendizaje y trabajar con la infraestructura.
Fuente: habr.com