La nostra empresa està en procés d'incorporar un equip SRE. Vaig entrar en tota aquesta història des del vessant del desenvolupament. Durant el procés, vaig tenir idees i idees que vull compartir amb altres desenvolupadors. En aquest article de reflexió parlo del que està passant, de com està passant i de com tothom hi pot seguir vivint.
Continuació d'una sèrie d'articles escrits a partir de les ponències del nostre acte intern :
2. Infraestructura com a codi. (Estàs aquí)
3. Generació de contractes Typescript mitjançant models C#. (En progrés...)
4. Introducció a l'algorisme de consens Raft. (En progrés...)
...
Vam decidir crear un equip SRE, implementant les idees . Van reclutar programadors entre els seus propis desenvolupadors i els van enviar a formar-se durant diversos mesos.
L'equip tenia les següents tasques formatives:
- Descriu la nostra infraestructura, que es troba principalment a Microsoft Azure en forma de codi (Terraform i tot el que l'envolta).
- Ensenyeu als desenvolupadors a treballar amb infraestructura.
- Preparar els desenvolupadors per al seu deure.
Introduïm el concepte d'Infraestructura com a codi
En el model habitual del món (administració clàssica), el coneixement sobre infraestructures es localitza en dos llocs:
- O en forma de coneixement en els caps dels experts.
- O aquesta informació es troba en algunes màquines d'escriure, algunes de les quals són conegudes pels experts. Però no és un fet que un foraster (en cas que tot el nostre equip mor de sobte) pugui esbrinar què funciona i com funciona. Hi pot haver molta informació sobre una màquina: accessoris, cronjobs, intimidat (vegeu. ) i només una llista infinita del que pot passar. És difícil entendre què està passant realment.
En tots dos casos, ens trobem atrapats a convertir-nos en dependents:
- o d'una persona mortal, subjecta a malaltia, enamorament, canvis d'humor i acomiadaments senzillament banals;
- o d'una màquina que funciona físicament, que també cau, es roba i presenta sorpreses i inconvenients.
No cal dir que, idealment, tot s'hauria de traduir en codi llegible per l'home, mantenible i ben escrit.
Així, la infraestructura com a codi (Incfastructure as Code - IaC) és una descripció de tota la infraestructura existent en forma de codi, així com les eines relacionades per treballar-hi i implementar-hi una infraestructura real.
Per què traduir-ho tot en codi?Les persones no som màquines. No poden recordar-ho tot. La reacció d'una persona i d'una màquina és diferent. Qualsevol cosa automatitzada és potencialment més ràpida que qualsevol cosa feta per un humà. El més important és una única font de veritat.
D'on provenen els nous enginyers SRE?Així doncs, vam decidir contractar nous enginyers SRE, però d'on aconseguir-los? Llibre amb respostes correctes () ens diu: dels desenvolupadors. Després de tot, funcionen amb el codi i aconsegueixes l'estat ideal.
Els vam buscar molt durant molt de temps al mercat de personal fora de la nostra empresa. Però hem d'admetre que no hem trobat ningú que s'adapti a les nostres peticions. Vaig haver de buscar entre la meva pròpia gent.
Problemes Infraestructura com a codi
Ara mirem exemples de com la infraestructura es pot codificar en codi. El codi està ben escrit, d'alta qualitat, amb comentaris i sagnats.
Exemple de codi de Terraforma.
Exemple de codi d'Ansible.
Senyors, si fos tan senzill! Estem al món real, i sempre està preparat per sorprendre't, presentar-te sorpreses i problemes. Aquí tampoc es pot prescindir d'ells.
1. El primer problema és que en la majoria dels casos IaC és una mena de dsl.
I DSL, al seu torn, és una descripció de l'estructura. Més precisament, el que hauríeu de tenir: Json, Yaml, modificacions d'algunes grans empreses que van crear el seu propi dsl (HCL s'utilitza a terraform).
El problema és que fàcilment pot no contenir coses tan familiars com:
- les variables;
- condicions;
- en algun lloc no hi ha comentaris, per exemple, en Json, per defecte no es proporcionen;
- funcions;
- i ni tan sols parlo de coses tan alts com les classes, l'herència i tot això.
2. El segon problema d'aquest codi és que la majoria de vegades és un entorn heterogeni. Normalment us asseieu i treballeu amb C#, és a dir. amb una llengua, una pila, un ecosistema. I aquí teniu una gran varietat de tecnologies.
És una situació molt real quan bash amb Python llança algun procés en el qual s'insereix Json. L'analitzeu, després un altre generador produeix 30 fitxers més. Per tot això, les variables d'entrada es reben d'Azure Key Vault, que s'ajunten mitjançant un connector per a drone.io escrit a Go, i aquestes variables passen per Yaml, que es va generar com a resultat de la generació des del motor de plantilles jsonnet. És bastant difícil tenir un codi estrictament ben descrit quan tens un entorn tan divers.
El desenvolupament tradicional en el marc d'una tasca ve amb una llengua. Aquí treballem amb un gran nombre d'idiomes.
3. El tercer problema és l'afinació. Estem acostumats als editors genials (Ms Visual Studio, Jetbrains Rider) que ho fan tot per nosaltres. I encara que siguem estúpids, diran que ens equivoquem. Sembla normal i natural.
Però a prop hi ha VSCode, en el qual hi ha alguns connectors que d'alguna manera estan instal·lats, compatibles o no. Van sortir noves versions i no eren compatibles. Una transició banal a la implementació d'una funció (encara que existeixi) es converteix en un problema complex i no trivial. Un simple canvi de nom d'una variable és una reproducció en un projecte d'una dotzena de fitxers. Tindràs sort si posa el que necessites. Per descomptat, hi ha retroil·luminació aquí i allà, hi ha autocompleció, en algun lloc hi ha formatació (tot i que no em va funcionar en terraform a Windows).
En el moment d'escriure aquest article encara no s'han publicat per donar suport a la versió 0.12, tot i que fa 3 mesos que s'ha llançat.
És hora d'oblidar-se de...
- Depuració.
- Eina de refactorització.
- Completament automàtic.
- Detecció d'errors durant la compilació.
És divertit, però això també augmenta el temps de desenvolupament i augmenta el nombre d'errors que es produeixen inevitablement.
El pitjor és que ens veiem obligats a pensar no en com dissenyar, organitzar fitxers en carpetes, descompondre, fer que el codi es pugui mantenir, llegible, etc., sinó com puc escriure aquesta ordre correctament, perquè d'alguna manera l'he escrit incorrectament. .
Com a principiant, esteu intentant aprendre terraformes i l'IDE no us ajuda gens. Quan hi hagi documentació, entra i mira. Però si esteu introduint un llenguatge de programació nou, l'IDE us diria que n'hi ha, però no n'hi ha. Almenys a nivell int o cadena. Això sovint és útil.
Què passa amb les proves?
Pregunteu: "Què passa amb les proves, senyors programadors?" Els nois seriosos ho posen a prova tot en producció, i és difícil. Aquí teniu un exemple de prova d'unitat per a un mòdul terraform del lloc web .
Tenen una bona documentació. Sempre m'ha agradat Microsoft pel seu enfocament a la documentació i la formació. Però no cal que siguis l'oncle Bob per entendre que aquest no és un codi perfecte. Observeu la validació a la dreta.
El problema amb una prova d'unitat és que tu i jo podem comprovar la correcció de la sortida Json. Vaig introduir 5 paràmetres i em van donar una tovallola Json amb 2000 línies. Puc analitzar què està passant aquí, validar el resultat de la prova...
És difícil analitzar Json a Go. I cal escriure a Go, perquè terraform a Go és una bona pràctica per provar en l'idioma en què escrius. L'organització del codi en si és molt feble. Al mateix temps, aquesta és la millor biblioteca per fer proves.
Microsoft mateix escriu els seus mòduls, provant-los d'aquesta manera. Per descomptat, és de codi obert. Tot el que et parlo pots venir a arreglar. Em puc asseure i arreglar-ho tot en una setmana, connectors de codi VS de codi obert, terraforms, fer un connector per al genet. Potser escriure un parell d'analitzadors, afegir linters, aportar una biblioteca per fer proves. Ho puc fer tot. Però això no és el que hauria de fer.
Bones pràctiques Infraestructura com a codi
Posem-nos en marxa. Si no hi ha proves a IaC, l'IDE i l'ajustament són dolents, almenys hi hauria d'haver bones pràctiques. Acabo d'anar a Google Analytics i comparar dues consultes de cerca: pràctiques recomanades de Terraform i pràctiques recomanades de c#.
Què veiem? Les estadístiques despietades no estan a favor nostre. La quantitat de material és la mateixa. En el desenvolupament de C#, simplement estem inundats de materials, tenim bones pràctiques, hi ha llibres escrits per experts i també llibres escrits sobre llibres per altres experts que critiquen aquests llibres. Un mar de documentació oficial, articles, cursos de formació i ara també desenvolupament de codi obert.
Pel que fa a la sol·licitud d'IaC: aquí esteu intentant recollir informació a poc a poc d'informes de càrrega alta o HashiConf, de documentació oficial i de nombrosos problemes a Github. Com distribuir aquests mòduls en general, què fer amb ells? Sembla que això és un problema real... Hi ha una comunitat, senyors, on per a qualsevol pregunta se us donaran 10 comentaris a Github. Però no ho és exactament.
Malauradament, en aquest moment, tot just comencen a sorgir experts. De moment n'hi ha massa pocs. I la pròpia comunitat es troba a un nivell rudimentari.
On va tot això i què fer
Pots deixar-ho tot i tornar a C#, al món del genet. Però no. Per què us molesteu en fer això si no trobeu una solució? A continuació presento les meves conclusions subjectives. Podeu discutir amb mi als comentaris, serà interessant.
Personalment, aposto per algunes coses:
- El desenvolupament en aquest àmbit s'està produint molt ràpidament. Aquí teniu un calendari de sol·licituds per a DevOps.
El tema pot ser bombo, però el fet que l'esfera estigui creixent dóna certa esperança.Si alguna cosa creix tan ràpidament, llavors apareixeran persones intel·ligents que us diran què heu de fer i què no. L'augment de la popularitat porta al fet que potser algú tindrà temps per afegir finalment un connector a jsonnet per a vscode, que us permetrà passar a implementar la funció, en lloc de cercar-la mitjançant ctrl+shift+f. A mesura que les coses evolucionen, apareixen més materials. La publicació d'un llibre de Google sobre SRE és un excel·lent exemple d'això.
- Hi ha tècniques i pràctiques desenvolupades en desenvolupament convencional que podem aplicar amb èxit aquí. Sí, hi ha matisos amb les proves i un entorn heterogeni, eines insuficients, però s'han acumulat un gran nombre de pràctiques que poden ser útils i útils.
Un exemple trivial: la col·laboració mitjançant la programació per parelles. Ajuda molt a esbrinar-ho. Quan tens un veí a prop que també està intentant entendre alguna cosa, junts ho entendràs millor.
Entendre com es fa la refactorització ajuda a dur-la a terme fins i tot en una situació així. És a dir, no podeu canviar-ho tot alhora, però canvieu el nom, després canvieu la ubicació, després podeu destacar alguna part, oh, però aquí no hi ha prou comentaris.
Conclusió
Malgrat que el meu raonament pugui semblar pessimista, miro el futur amb esperança i espero sincerament que tot surti bé per a nosaltres (i per a tu).
A continuació s'està preparant la segona part de l'article. En ell, parlaré de com hem intentat utilitzar pràctiques de desenvolupament àgil per millorar el nostre procés d'aprenentatge i treballar amb infraestructura.
Font: www.habr.com