Representar la infraestructura com a codi en un format de text repetible és una bona pràctica senzilla per als sistemes que no requereixen jugar amb els ratolins. Aquesta pràctica té un nom: , i fins ara hi ha dues eines populars per implementar-lo, especialment a AWS: и .
Comparant l'experiència amb Terraform i CloudFormation
Abans d'arribar a (Aka ) Vaig treballar i va utilitzar Terraform durant tres anys. Al nou lloc, també vaig utilitzar Terraform amb totes les meves forces, i després l'empresa va impulsar la transició a tot el que era Amazon, inclòs CloudFormation. He desenvolupat amb diligència les millors pràctiques per a tots dos i he utilitzat ambdues eines en fluxos de treball molt complexos a tota l'organització. Més tard, després de sospesar atentament les implicacions de la migració de Terraform a CloudFormation, em vaig convencer que Terraform era probablement la millor opció per a l'organització.
Terraform Horrible
Programari beta
Terraform encara no ha llançat la versió 1.0, que és una bona raó per no utilitzar-la. Ha canviat molt des que el vaig provar per primera vegada, però aleshores terraform apply sovint es va trencar després de diverses actualitzacions o simplement després d'un parell d'anys d'ús. Jo diria que “ara tot és diferent”, però... això és el que sembla dir tothom, no? Hi ha canvis que són incompatibles amb les versions anteriors, tot i que són adequats, i fins i tot sembla que la sintaxi i les abstraccions dels magatzems de recursos són ara el que necessitem. L'instrument sembla haver millorat realment, però... :-0
D'altra banda, AWS ha fet una bona feina mantenint la compatibilitat enrere. Això probablement es deu al fet que els seus serveis sovint es posen a prova a fons dins de l'organització i només aleshores, canviats de nom, es publiquen. Així que "s'han esforçat molt" és un eufemisme. Mantenir la compatibilitat enrere amb les API per a un sistema tan variat i complex com AWS és increïblement difícil. Qualsevol persona que hagi hagut de mantenir API públiques que s'utilitzen tan àmpliament com ho són hauria d'entendre com de difícil és fer-ho durant tants anys. Però el comportament de CloudFormation, a la meva memòria, no ha canviat mai al llarg dels anys.
Coneix la cama... és una bala
Pel que jo sàpiga, suprimiu el recurs foraster La pila de CloudFormation de la vostra pila CF no és possible. El mateix passa amb Terraform. Us permet importar recursos existents a la vostra pila. Es pot dir que la funció és sorprenent, però amb un gran poder comporta una gran responsabilitat. Només heu d'afegir un recurs a la pila i, mentre esteu treballant amb la vostra pila, no podeu suprimir ni canviar aquest recurs. Un dia va ser contraproduent. Un dia a Twitch, algú va importar accidentalment el grup de seguretat AWS d'una altra persona a la seva pròpia pila de Terraform sense fer cap mal. Vaig introduir diverses ordres i... el grup de seguretat (juntament amb el trànsit entrant) va desaparèixer.
Terraform Genial
Recuperació d'estats incomplets
De vegades, CloudFormation no pot passar completament d'un estat a un altre. Al mateix temps, intentarà tornar a l'anterior. És una llàstima que això no sempre sigui factible. Pot ser bastant espantós depurar el que va passar més tard, mai se sap si CloudFormation estarà content que estigui piratejat, ni tan sols per solucionar-ho. Si serà o no possible tornar a l'estat anterior, realment no sap com determinar-ho i, per defecte, es queda pendent durant hores esperant un miracle.
Terraform, d'altra banda, tendeix a recuperar-se de les transicions fallides amb molta més gràcia i ofereix eines de depuració avançades.
Canvis més clars a l'estat del document
"D'acord, equilibrador de càrrega, estàs canviant. Però com?"
—enginyer inquiet, disposat a prémer el botó “acceptar”.
De vegades he de fer algunes manipulacions amb l'equilibrador de càrrega a la pila de CloudFormation, com ara afegir un número de port o canviar un grup de seguretat. ClouFormation mostra els canvis malament. Jo, amb agulles i agulles, comprovo deu vegades el fitxer yaml per assegurar-me que no he esborrat res necessari i que no he afegit res innecessari.
Terraform és molt més transparent en aquest sentit. De vegades fins i tot és massa transparent (llegiu: molest). Afortunadament, l'última versió inclou una visualització millorada dels canvis perquè ara pugueu veure exactament què està canviant.
Flexibilitat
Escriure programari al revés.
Per dir-ho sense embuts, la característica més important del programari de llarga vida és la capacitat d'adaptar-se al canvi. Escriu qualsevol programari al revés. La majoria de vegades vaig cometre errors agafant un servei "simple" i després començant a agrupar-ho tot en una sola pila de CloudFormation o Terraform. I, per descomptat, mesos després es va revelar que ho havia entès tot malament i que el servei no era senzill! I ara necessito trencar d'alguna manera una gran pila en components petits. Quan treballeu amb CloudFormation, això només es pot fer recreant primer la pila existent, i no ho faig amb les meves bases de dades. Terraform, d'altra banda, va permetre disseccionar la pila i dividir-la en parts més petites més comprensibles.
Mòduls en git
Compartir el codi de Terraform entre diverses piles és molt més fàcil que compartir el codi de CloudFormation. Amb Terraform, podeu posar el vostre codi en un repositori git i accedir-hi mitjançant el control semàntic de versions. Qualsevol persona amb accés a aquest repositori pot reutilitzar el codi compartit. L'equivalent de CloudFormation és S3, però no té els mateixos avantatges, i no hi ha cap raó per la qual hauríem d'abandonar git a favor de S3.
L'organització va créixer i la capacitat de compartir piles comunes va assolir un nivell crític. Terraform fa que tot això sigui fàcil i natural, mentre que CloudFormation us farà saltar a través dels cèrcols abans que una cosa com aquesta funcioni.
Operacions com a codi
"Anem a escriure'l i d'acord".
—un enginyer 3 anys abans d'inventar la bicicleta Terraform.
Quan es tracta de desenvolupament de programari, Go o un programa Java no és només codi.
Codi com a codi
També hi ha la infraestructura en què treballa.
La infraestructura com a codi
Però d'on és ella? Com controlar-ho? On viu el teu codi? Els desenvolupadors necessiten permís d'accés?
Operacions com a codi
Ser desenvolupador de programari no vol dir només escriure codi.
AWS no és l'únic: probablement utilitzeu altres proveïdors. SignalFx, PagerDuty o Github. Potser teniu un servidor intern de Jenkins per a CI/CD o un tauler intern de Grafana per al seguiment. Infra as Code s'escull per diferents motius, i cadascun és igual d'important per a tot allò relacionat amb el programari.
Quan treballava a Twitch, vam accelerar els serveis dins dels sistemes integrats i AWS mixts d'Amazon. Vam generar i donar suport a molts microserveis, augmentant els costos operatius. Els debats van anar més o menys així:
- Я: Maleït, són molts gestos per overclockejar un microservei. Hauré d'utilitzar aquesta brossa per crear un compte d'AWS (vam anar a 2 comptes microservei), després aquest per configurar alertes, aquest per a un dipòsit de codi, i aquest per a una llista de correu electrònic, i després aquest...
- Dirigir: Anem a escriure'l i d'acord.
- Я: D'acord, però el guió en si canviarà. Necessitarem una manera de comprovar que tots aquests aparells integrats d'Amazon estiguin actualitzats.
- Dirigir: Sona bé. I escriurem un guió per a això.
- Я: Genial! I probablement l'script encara haurà d'establir paràmetres. Els acceptarà?
- Dirigir: Que porti on va!
- Я: El procés pot canviar i es perdrà la compatibilitat enrere. Es requerirà algun tipus de control semàntic de versions.
- Dirigir: Bona idea!
- Я: Les eines es poden canviar manualment, dins de la interfície d'usuari. Necessitarem una manera de comprovar-ho i solucionar-ho.
… 3 anys després:
- Dirigir: I tenim terraforma.
La moraleja de la història és: encara que tu de cap en tot Amazon, encara esteu utilitzant alguna cosa que no és d'AWS i aquests serveis tenen un estat que utilitza un llenguatge de configuració per mantenir aquest estat sincronitzat.
CloudFormation lambda vs mòduls git terraform
lambda és la solució de CloudFormation al problema de la lògica personalitzada. Amb lambda pots o . Aquest enfocament introdueix complexitats addicionals que no estan presents en la versió semàntica dels mòduls git de Terraform. Per a mi, el problema més urgent va ser gestionar els permisos de totes aquestes lambdas d'usuari (i són desenes de comptes d'AWS). Un altre problema important va ser el problema "què va ser primer, la gallina o l'ou?": estava relacionat amb el codi lambda. Aquesta funció en si és infraestructura i codi, i necessita un seguiment i actualitzacions. El clau final del taüt va ser la dificultat d'actualitzar semànticament els canvis de codi lambda; també ens havíem d'assegurar que les accions de pila sense una ordre directa no canviessin entre execucions.
Recordo que una vegada vaig voler crear un desplegament canari per a l'entorn Elastic Beanstalk amb un equilibrador de càrrega clàssic. El més fàcil de fer seria fer un segon desplegament per a l'EB al costat de l'entorn de producció, fent-ho un pas més enllà: combinar el grup de desplegament canari d'escalat automàtic amb el desplegament LB a l'entorn de producció. I ja que Terraform utilitza , això requerirà 4 línies addicionals de codi a Terraform. Quan vaig preguntar si hi havia una solució comparable a CloudFormation, em van indicar tot un repositori git amb un pipeline de desplegament i tot, tot pel bé d'alguna cosa que podien fer les 4 línies pobres de codi Terraform.
Detecta millor la deriva
Assegureu-vos que la realitat coincideixi amb les expectatives.
és una funció d'operacions molt potent com a codi perquè ajuda a garantir que la realitat coincideixi amb les expectatives. Està disponible tant amb CloudFormation com amb Terraform. Però a mesura que la pila de producció va créixer, la recerca de deriva a CloudFormation va produir cada cop més deteccions falses.
Amb Terraform teniu ganxos de cicle de vida molt més avançats per a la detecció de deriva. Per exemple, introduïu l'ordre directament a la definició de la tasca de l'ECS si voleu ignorar els canvis a una definició de tasca específica sense ignorar els canvis a tota la vostra implementació ECS.
CDK i el futur de CloudFormation
CloudFormation és difícil de gestionar a grans escales d'infraestructura. Moltes d'aquestes dificultats es reconeixen i l'eina necessita coses com , un marc per definir la infraestructura del núvol en codi i executar-la mitjançant AWS CloudFormation. Serà interessant veure què depara el futur per a aws-cdk, però li costarà competir amb els altres punts forts de Terraform; per actualitzar CloudFormation, caldran canvis globals.
Perquè Terraform no defrauda
Això és "infraestructura com a codi" i no "com a text".
La meva primera impressió de Terraform va ser bastant dolenta. Crec que no entenc l'enfocament. Gairebé tots els enginyers el perceben involuntàriament com un format de text que cal convertir en la infraestructura desitjada. NO HO FEU D'AQUESTA MANERA.
Els truismes d'un bon desenvolupament de programari també s'apliquen a Terraform.
He vist que s'adopten moltes pràctiques per crear un bon codi que s'ignoren a Terraform. Has estudiat durant anys per convertir-te en un bon programador. No renunciïs a aquesta experiència només perquè estàs treballant amb Terraform. Els truismes del bon desenvolupament de programari s'apliquen a Terraform.
Com no es pot documentar el codi?
He vist grans piles de Terraform sense absolutament cap documentació. Com es pot escriure codi en pàgines, sense absolutament cap documentació? Afegiu documentació que expliqui el vostre codi Terraform (èmfasi en la paraula "codi"), per què aquesta secció és tan important i què feu.
Com podem implementar serveis que abans eren una gran funció principal ()?
He vist piles de Terraform molt complexes presentades com un únic mòdul. Per què no implementem el programari d'aquesta manera? Per què dividim les funcions grans en altres de més petites? Les mateixes respostes s'apliquen a Terraform. Si el vostre mòdul és massa gran, haureu de dividir-lo en mòduls més petits.
La vostra empresa no utilitza biblioteques?
He vist com els enginyers, creant un nou projecte amb Terraform, van copiar estúpidament grans trossos d'altres projectes al seu propi i després van retocar-los fins que va començar a funcionar. Treballaríeu així amb el codi de "combat" a la vostra empresa? No només fem servir biblioteques. Sí, però on som sense biblioteques compartides en principi?!
No fas servir PEP8 o gofmt?
La majoria dels idiomes tenen un esquema de format estàndard acceptat. A Python això és PEP8. A Go - gofmt. Terraform té el seu propi: terraform fmt. Gaudeix-ho per la teva salut!
Fareu servir React sense conèixer JavaScript?
Els mòduls Terraform poden simplificar alguna part de la complexa infraestructura que creeu, però això no vol dir que no pugueu jugar-hi gens. Voleu utilitzar Terraform correctament sense entendre els recursos? Estàs condemnat: el temps passarà i mai no dominaràs Terraform.
Esteu codificant amb singletons o injecció de dependència?
La injecció de dependència és una pràctica reconeguda per al desenvolupament de programari i es prefereix sobre els singletons. Com és útil això a Terraform? He vist mòduls Terraform que depenen de l'estat remot. En lloc d'escriure mòduls que recuperin l'estat remot, escriviu un mòdul que prengui paràmetres. I després passeu aquests paràmetres al mòdul.
Les vostres biblioteques fan deu coses bé o una cosa genial?
Les biblioteques que funcionen millor són les que se centren en una tasca que fan molt bé. En lloc d'escriure mòduls Terraform grans que intentin fer-ho tot alhora, construïu-ne parts que facin bé una cosa. I després combineu-los segons calgui.
Com es fan canvis a les biblioteques sense compatibilitat enrere?
Un mòdul comú de Terraform, com una biblioteca normal, necessita d'alguna manera comunicar els canvis als usuaris sense ser compatible enrere. És molest quan es produeixen aquests canvis a les biblioteques, i és igual de molest quan es fan canvis no compatibles amb les versions anteriors als mòduls de Terraform. Es recomana utilitzar etiquetes git i semver quan s'utilitzen mòduls Terraform.
El vostre servei de producció funciona al vostre ordinador portàtil o en un centre de dades?
Hashicorp té eines com per executar la teva terraforma. Aquests serveis centralitzats faciliten la gestió, l'auditoria i l'aprovació dels canvis de terraform.
No escrius proves?
Els enginyers reconeixen que el codi s'ha de provar, però ells mateixos sovint s'obliden de provar quan treballen amb Terraform. Per a la infraestructura, això està ple de moments traïdors. El meu consell és "provar" o "crear exemples" de piles utilitzant mòduls que es puguin desplegar correctament per provar durant CI/CD.
Terraform i microserveis
La vida i la mort de les empreses de microserveis depèn de la velocitat, la innovació i la interrupció de les noves piles de treball de microserveis.
L'aspecte negatiu més comú associat a les arquitectures de microserveis, i que no es pot eliminar, està relacionat amb el treball, no amb el codi. Si penseu que Terraform només és una manera d'automatitzar només la part de la infraestructura d'una arquitectura de microserveis, aleshores us perdeu els veritables avantatges del sistema. Ara ja és .
Font: www.habr.com