A nosa empresa está en proceso de incorporación a un equipo SRE. Entrei en toda esta historia dende o lado do desenvolvemento. Durante o proceso, decidín ideas e ideas que quero compartir con outros desenvolvedores. Neste artigo de reflexión falo do que está a pasar, de como está a suceder e de como todo o mundo pode seguir vivindo con iso.
Continuación dunha serie de artigos escritos a partir das intervencións do noso evento interno :
2. Infraestrutura como código. (Estás aquí)
3. Xeración de contratos Typescript utilizando modelos C#. (En progreso...)
4. Introdución ao algoritmo de consenso Raft. (En progreso...)
...
Decidimos crear un equipo SRE, implementando as ideas . Reclutaron programadores entre os seus propios desenvolvedores e mandáronos a adestrar durante varios meses.
O equipo tiña as seguintes tarefas de formación:
- Describe a nosa infraestrutura, que está principalmente en Microsoft Azure en forma de código (Terraform e todo o que hai ao redor).
- Ensinar aos desenvolvedores a traballar con infraestrutura.
- Prepara aos desenvolvedores para o deber.
Introducimos o concepto de Infraestrutura como código
No modelo habitual do mundo (administración clásica), o coñecemento sobre infraestruturas sitúase en dous lugares:
- Ou en forma de coñecemento nas cabezas dos expertos.
- Ou esta información está nalgunhas máquinas de escribir, algunhas das cales son coñecidas polos expertos. Pero non é un feito que un alleo (no caso de que todo o noso equipo morra de súpeto) poida descubrir que funciona e como funciona. Pode haber moita información nunha máquina: accesorios, cronjobs, intimidados (ver. ) e só unha lista infinita do que pode pasar. É difícil entender o que realmente está pasando.
En ambos casos, atopámonos atrapados en facernos dependentes:
- ou dunha persoa que é mortal, suxeita a enfermidades, namorados, cambios de humor e simplemente despedimentos banais;
- ou dunha máquina que traballa fisicamente, que tamén cae, rouban e presenta sorpresas e inconvenientes.
Sobra dicir que o ideal sería que todo se traduza a un código lexible, mantible e ben escrito.
Así, a infraestrutura como código (Incfastructure as Code - IaC) é unha descrición de toda a infraestrutura existente en forma de código, así como ferramentas relacionadas para traballar con ela e implementar unha infraestrutura real a partir dela.
Por que traducir todo a código?As persoas non son máquinas. Non poden lembrar todo. A reacción dunha persoa e dunha máquina é diferente. Calquera cousa automatizada é potencialmente máis rápida que calquera cousa que faga un humano. O máis importante é unha única fonte de verdade.
De onde veñen os novos enxeñeiros SRE?Entón, decidimos contratar novos enxeñeiros SRE, pero de onde conseguilos? Libro coas respostas correctas () dinos: dos desenvolvedores. Despois de todo, traballan co código e consegues o estado ideal.
Buscámolos moito durante moito tempo no mercado de persoal alleo á nosa empresa. Pero temos que admitir que non atopamos a ninguén que se adaptase ás nosas solicitudes. Tiven que buscar entre a miña propia xente.
Problemas Infraestrutura como código
Agora vexamos exemplos de como a infraestrutura pode codificarse en código. O código está ben escrito, de alta calidade, con comentarios e sangrías.
Código de exemplo de Terraforma.
Código de exemplo de Ansible.
Señores, se fose tan sinxelo! Estamos no mundo real, e sempre está preparado para sorprenderte, presentarte sorpresas e problemas. Aquí tampouco se pode prescindir deles.
1. O primeiro problema é que na maioría dos casos IaC é algún tipo de dsl.
E DSL, á súa vez, é unha descrición da estrutura. Máis precisamente, o que deberías ter: Json, Yaml, modificacións dalgunhas grandes empresas que crearon o seu propio dsl (HCL úsase en terraform).
O problema é que pode facilmente non conter cousas tan coñecidas como:
- variables;
- condicións;
- nalgún lugar non hai comentarios, por exemplo, en Json, por defecto non se proporcionan;
- funcións;
- e nin sequera falo de cousas tan de alto nivel como as clases, a herdanza e todo iso.
2. O segundo problema con tal código é que a maioría das veces é un ambiente heteroxéneo. Normalmente sentas e traballas con C#, é dicir. cunha lingua, unha pila, un ecosistema. E aquí tes unha gran variedade de tecnoloxías.
É unha situación moi real cando bash con Python inicia algún proceso no que se insire Json. Analizalo, entón algún outro xerador produce outros 30 ficheiros. Por todo isto, as variables de entrada recíbense de Azure Key Vault, que son reunidas por un complemento para drone.io escrito en Go, e estas variables pasan por yaml, que se xerou como resultado da xeración do motor de modelos jsonnet. É bastante difícil ter un código estritamente ben descrito cando tes un ambiente tan diverso.
O desenvolvemento tradicional no marco dunha tarefa vén cunha lingua. Aquí traballamos cunha gran cantidade de linguas.
3. O terceiro problema é a afinación. Estamos afeitos a editores xeniais (Ms Visual Studio, Jetbrains Rider) que fan todo por nós. E aínda que sexamos parvos, dirán que estamos equivocados. Parece normal e natural.
Pero nalgún lugar preto hai VSCode, no que hai algúns complementos que dalgún xeito están instalados, admitidos ou non. As novas versións saíron e non eran compatibles. Unha transición banal para implementar unha función (aínda que exista) convértese nun problema complexo e non trivial. Un simple cambio de nome dunha variable é unha reprodución nun proxecto dunha ducia de ficheiros. Terás sorte se coloca o que necesitas. Por suposto, hai retroiluminación aquí e alí, hai autocompletado, nalgún lugar hai formato (aínda que non me funcionou en terraform en Windows).
No momento de escribir este artigo aínda non se publicaron para admitir a versión 0.12, aínda que leva 3 meses.
É hora de esquecer...
- Depuración.
- Ferramenta de refactorización.
- Autocompletación.
- Detección de erros durante a compilación.
É divertido, pero isto tamén aumenta o tempo de desenvolvemento e aumenta o número de erros que se producen inevitablemente.
O peor é que estamos obrigados a pensar non en como deseñar, organizar ficheiros en cartafoles, descompoñer, facer que o código se poida manter, lexible, etc., senón como podo escribir este comando correctamente, porque dalgunha maneira o escribín incorrectamente. .
Como principiante, estás intentando aprender terraformas e o IDE non che está axudando en absoluto. Cando haxa documentación, entra e mira. Pero se estiveses a introducir unha nova linguaxe de programación, o IDE diríache que existe tal tipo, pero non existe. Polo menos a nivel int ou cadea. Isto adoita ser útil.
E as probas?
Vostede pregunta: "E as probas, señores programadores?" Os rapaces serios proban todo na produción, e é difícil. Aquí tes un exemplo de proba unitaria para un módulo terraform do sitio web .
Teñen boa documentación. Sempre me gustou Microsoft pola súa aproximación á documentación e á formación. Pero non é preciso ser o tío Bob para entender que este non é un código perfecto. Observe a validación á dereita.
O problema cunha proba unitaria é que ti e eu podemos comprobar a corrección da saída Json. Introducín 5 parámetros e déronme un pano Json con 2000 liñas. Podo analizar o que está a pasar aquí, validar o resultado da proba...
É difícil analizar Json en Go. E cómpre escribir en Go, porque terraform en Go é unha boa práctica para probar no idioma no que escribes. A organización do código en si é moi débil. Ao mesmo tempo, esta é a mellor biblioteca para probar.
A propia Microsoft escribe os seus módulos, probándoos deste xeito. Por suposto, é de código aberto. Todo o que estou a falar podes vir arreglar. Podo sentarme e arranxar todo nunha semana, complementos de código VS de código aberto, terraforms, facer un complemento para o piloto. Quizais escriba un par de analizadores, engada linters, aporte unha biblioteca para probar. Podo facer de todo. Pero iso non é o que debería facer.
Mellores prácticas Infraestrutura como código
Sigamos adiante. Se non hai probas en IaC, o IDE e a axuste son malos, entón debería haber polo menos as mellores prácticas. Acabo de ir a Google Analytics e comparei dúas consultas de busca: as mellores prácticas de Terraform e as mellores prácticas de c#.
Que vemos? As estatísticas despiadadas non están ao noso favor. A cantidade de material é a mesma. No desenvolvemento de C#, simplemente estamos inundados de materiais, temos excelentes prácticas, hai libros escritos por expertos e tamén libros escritos en libros por outros expertos que critican eses libros. Un mar de documentación oficial, artigos, cursos de formación e agora tamén desenvolvemento de código aberto.
En canto á solicitude de IaC: aquí estás tentando recoller información pouco a pouco de informes de alta carga ou de HashiConf, de documentación oficial e de numerosos problemas en Github. Como distribuír estes módulos en xeral, que facer con eles? Parece que este é un problema real... Hai unha comunidade, señores, onde para calquera pregunta se lle darán 10 comentarios en Github. Pero non o é exactamente.
Desafortunadamente, neste momento, só comezan a aparecer expertos. Son poucos ata agora. E a propia comunidade está colgando a un nivel rudimentario.
Onde vai todo isto e que facer
Podes deixar todo e volver a C#, ao mundo do piloto. Pero non. Por que te molestaste en facelo se non atopas unha solución. A continuación presento as miñas conclusións subxectivas. Podes discutir comigo nos comentarios, será interesante.
Persoalmente, aposto por algunhas cousas:
- O desenvolvemento nesta área está a suceder moi rápido. Aquí tes un calendario de solicitudes para DevOps.
O tema pode ser bombo, pero o feito de que a esfera estea crecendo dá algo de esperanza.Se algo crece tan rápido, entón aparecerán persoas intelixentes que che dirán que facer e que non. O aumento da popularidade leva ao feito de que quizais alguén teña tempo para engadir finalmente un complemento a jsonnet para vscode, o que lle permitirá pasar á implementación da función, en lugar de buscala mediante ctrl+shift+f. A medida que as cousas evolucionan, aparecen máis materiais. A publicación dun libro de Google sobre SRE é un excelente exemplo diso.
- Existen técnicas e prácticas desenvolvidas no desenvolvemento convencional que podemos aplicar aquí con éxito. Si, hai matices con probas e un ambiente heteroxéneo, ferramentas insuficientes, pero acumuláronse un gran número de prácticas que poden ser útiles e útiles.
Un exemplo trivial: a colaboración a través da programación por parellas. Axuda moito a descifralo. Cando tes un veciño preto que tamén está intentando entender algo, xuntos entenderémolo mellor.
Comprender como se fai a refactorización axuda a levala a cabo mesmo en tal situación. É dicir, non podes cambiar todo á vez, pero cambia o nome, despois cambia a localización e podes destacar algunha parte, oh, pero aquí non hai comentarios suficientes.
Conclusión
A pesar de que o meu razoamento poida parecer pesimista, miro cara ao futuro con esperanza e espero sinceramente que todo funcione para nós (e para ti).
A continuación prepárase a segunda parte do artigo. Nel, falarei de como tentamos utilizar prácticas de desenvolvemento áxiles para mellorar o noso proceso de aprendizaxe e traballar con infraestruturas.
Fonte: www.habr.com