Het weergeven van infrastructuur als code in een herhaalbaar tekstformaat is een eenvoudige best practice voor systemen waarbij geen gedoe met muizen nodig is. Deze praktijk heeft een naam - , en tot nu toe zijn er twee populaire tools om het te implementeren, vooral in AWS: и .
Ervaring met Terraform en CloudFormation vergelijken
Voordat u bijkomt (Aka ) Ik werkte en gebruikte Terraform drie jaar. Op de nieuwe plek gebruikte ik ook uit alle macht Terraform, en toen duwde het bedrijf de overstap naar alles a la Amazon, inclusief CloudFormation. Ik heb voor beide ijverig best practices ontwikkeld en beide tools gebruikt in zeer complexe, organisatiebrede workflows. Later, nadat ik de implicaties van de migratie van Terraform naar CloudFormation zorgvuldig had afgewogen, raakte ik ervan overtuigd dat Terraform waarschijnlijk de beste keuze was voor de organisatie.
Terraform verschrikkelijk
Bètasoftware
Terraform heeft versie 1.0 nog niet eens uitgebracht, wat een goede reden is om deze niet te gebruiken. Er is veel veranderd sinds ik het voor het eerst zelf probeerde, maar toen terraform apply ging vaak kapot na verschillende updates of gewoon na een paar jaar gebruik. Ik zou zeggen dat “nu alles anders is”, maar... dat is wat iedereen lijkt te zeggen, nietwaar? Er zijn veranderingen die niet compatibel zijn met eerdere versies, ook al zijn ze passend, en het voelt zelfs alsof de syntaxis en abstracties van de bronnenopslag nu zijn wat we nodig hebben. Het instrument lijkt echt beter te zijn geworden, maar... :-0
Aan de andere kant heeft AWS goed werk geleverd door de achterwaartse compatibiliteit te behouden. Dit komt waarschijnlijk omdat hun diensten vaak grondig worden getest binnen de organisatie en pas daarna, onder de nieuwe naam, worden gepubliceerd. Dus “ze hebben hun best gedaan” is een understatement. Het behouden van achterwaartse compatibiliteit met API’s voor een systeem dat zo gevarieerd en complex is als AWS is ongelooflijk moeilijk. Iedereen die openbare API's heeft moeten onderhouden die zo wijdverspreid worden gebruikt, zou moeten begrijpen hoe moeilijk het is om dit al zoveel jaren te doen. Maar het gedrag van CloudFormation is, in mijn herinnering, door de jaren heen nooit veranderd.
Maak kennis met het been... het is een kogel
Voor zover ik weet, verwijder de bron buitenstaander CloudFormation-stack van uw CF-stack is niet mogelijk. Hetzelfde geldt voor Terraform. Hiermee kunt u bestaande bronnen in uw stapel importeren. De functie kan geweldig genoemd worden, maar met grote kracht komt een grote verantwoordelijkheid. U hoeft alleen maar een hulpbron aan de stapel toe te voegen, en terwijl u met uw stapel werkt, kunt u deze hulpbron niet verwijderen of wijzigen. Op een dag werkte het averechts. Op een dag importeerde iemand op Twitch per ongeluk de AWS-beveiligingsgroep van iemand anders in zijn eigen Terraform-stack, terwijl hij geen kwaad in de zin had. Ik heb verschillende opdrachten ingevoerd en... de beveiligingsgroep (samen met het binnenkomende verkeer) verdween.
Terraform Geweldig
Herstel van onvolledige toestanden
Soms slaagt CloudFormation er niet in om volledig van de ene toestand naar de andere over te gaan. Tegelijkertijd zal hij proberen terug te keren naar de vorige. Jammer dat dit niet altijd haalbaar is. Het kan behoorlijk beangstigend zijn om later te debuggen wat er is gebeurd - je weet nooit of CloudFormation blij zal zijn dat het wordt gehackt - zelfs alleen maar om het te repareren. Of het wel of niet mogelijk zal zijn om terug te keren naar de vorige staat, weet hij echt niet hoe hij moet bepalen en blijft standaard urenlang wachten op een wonder.
Terraform herstelt daarentegen veel vlotter van mislukte transities en biedt geavanceerde debugging-tools.
Duidelijkere wijzigingen in de documentstatus
'Oké, load balancer, je verandert. Maar hoe?"
– bezorgde ingenieur, klaar om op de knop ‘accepteren’ te drukken.
Soms moet ik wat manipulaties uitvoeren met de load balancer in de CloudFormation-stack, zoals het toevoegen van een poortnummer of het wijzigen van een beveiligingsgroep. ClouFormation geeft wijzigingen slecht weer. Ik controleer het yaml-bestand tien keer om er zeker van te zijn dat ik niets noodzakelijks heb gewist en niets onnodigs heb toegevoegd.
Terraform is in dit opzicht veel transparanter. Soms is hij zelfs te transparant (lees: saai). Gelukkig bevat de nieuwste versie een verbeterde weergave van wijzigingen, zodat je nu precies kunt zien wat er verandert.
flexibiliteit
Schrijf software achterstevoren.
Om het bot te zeggen: het belangrijkste kenmerk van software met een lange levensduur is het vermogen om zich aan te passen aan veranderingen. Schrijf alle software achterstevoren. Ik maakte meestal fouten door een “eenvoudige” service te nemen en vervolgens alles in één enkele CloudFormation- of Terraform-stack te proppen. En natuurlijk bleek maanden later dat ik alles verkeerd had begrepen, en de service was eigenlijk niet eenvoudig! En nu moet ik op de een of andere manier een grote stapel in kleine componenten opdelen. Wanneer je met CloudFormation werkt, kan dit alleen door eerst de bestaande stack opnieuw aan te maken, maar dit doe ik niet met mijn databases. Terraform maakte het daarentegen mogelijk om de stapel te ontleden en op te splitsen in begrijpelijkere kleinere delen.
Modules in git
Het delen van Terraform-code over meerdere stapels is veel eenvoudiger dan het delen van CloudFormation-code. Met Terraform kun je je code in een git-repository plaatsen en er toegang toe krijgen met behulp van semantisch versiebeheer. Iedereen met toegang tot deze repository kan de gedeelde code hergebruiken. Het equivalent van CloudFormation is S3, maar het heeft niet dezelfde voordelen, en er is geen reden waarom we git überhaupt zouden moeten verlaten ten gunste van S3.
De organisatie groeide en de mogelijkheid om gemeenschappelijke stapels te delen bereikte een kritiek niveau. Terraform maakt dit allemaal gemakkelijk en natuurlijk, terwijl CloudFormation je door hoepels laat springen voordat je zoiets werkend kunt krijgen.
Bewerkingen als code
"Laten we het script maken en oké."
—een ingenieur drie jaar voordat hij de Terraform-fiets uitvond.
Als het om softwareontwikkeling gaat, is Go of een Java-programma niet alleen maar code.
Codeer als code
Er is ook de infrastructuur waarop het werkt.
Infrastructuur als code
Maar waar komt ze vandaan? Hoe monitoren? Waar staat uw code? Hebben ontwikkelaars toegangsrechten nodig?
Operaties als code
Softwareontwikkelaar zijn betekent niet alleen code schrijven.
AWS is niet de enige: waarschijnlijk maak je gebruik van andere providers. SignalFx, PagerDuty of Github. Misschien heb je een interne Jenkins-server voor CI/CD of een intern Grafana-dashboard voor monitoring. Infra as Code wordt om verschillende redenen gekozen, en elk is even belangrijk voor alles wat met software te maken heeft.
Toen ik bij Twitch werkte, versnelden we de services binnen de gemengde embedded- en AWS-systemen van Amazon. We hebben veel microservices ontwikkeld en ondersteund, waardoor de operationele kosten zijn gestegen. De discussies gingen ongeveer zo:
- Я: Verdomd, dat zijn veel gebaren om één microservice te overklokken. Ik zal deze rommel moeten gebruiken om een AWS-account aan te maken (we gingen naar 2 accounts op microservice), dan deze voor het instellen van waarschuwingen, deze voor een codeopslagplaats, en deze voor een e-maillijst, en dan deze...
- Lood: Laten we het script maken en oké.
- Я: Oké, maar het script zelf zal veranderen. We hebben een manier nodig om te controleren of al deze ingebouwde Amazon-gizmo's up-to-date zijn.
- Lood: Klinkt goed. En we zullen hiervoor een script schrijven.
- Я: Geweldig! En het script zal waarschijnlijk nog steeds parameters moeten instellen. Zal hij ze accepteren?
- Lood: Laat hem nemen waar hij heen gaat!
- Я: Het proces kan veranderen en de achterwaartse compatibiliteit gaat verloren. Er zal een vorm van semantisch versiebeheer nodig zijn.
- Lood: Goed idee!
- Я: Tools kunnen handmatig worden gewijzigd, binnen de gebruikersinterface. We hebben een manier nodig om dit te controleren en op te lossen.
…3 jaar later:
- Lood: En we hebben terraform.
De moraal van het verhaal is: zelfs als je hals over kop in alles Amazon, gebruik je nog steeds iets dat niet van AWS is, en deze services hebben een status die een configuratietaal gebruikt om die status gesynchroniseerd te houden.
CloudFormation lambda versus git-modules terraform
lambda is de oplossing van CloudFormation voor het aangepaste logicaprobleem. Met lambda kan dat of . Deze aanpak introduceert extra complexiteiten die niet aanwezig zijn in Terraform's semantische versiebeheer van git-modules. Voor mij was het meest urgente probleem het beheren van de rechten voor al deze gebruikerslambda's (en dit zijn tientallen AWS-accounts). Een ander belangrijk probleem was het ‘wat was er eerst, de kip of het ei?’-probleem: het had te maken met de lambdacode. Deze functie zelf is infrastructuur en code, en heeft zelf monitoring en updates nodig. De laatste nagel aan de kist was de moeilijkheid bij het semantisch bijwerken van wijzigingen in de lambdacode; we moesten er ook voor zorgen dat de stapelacties zonder een direct commando niet tussen runs veranderden.
Ik herinner me dat ik ooit een kanarie-implementatie wilde maken voor de Elastic Beanstalk-omgeving met een klassieke load balancer. Het gemakkelijkste om te doen zou zijn om naast de productieomgeving een tweede implementatie voor de EB te maken, en nog een stap verder te gaan: het combineren van de automatisch schalende Canary-implementatiegroep met de implementatie-LB in de productieomgeving. En aangezien Terraform gebruik maakt van , vereist dit 4 extra regels code in Terraform. Toen ik vroeg of er een vergelijkbare oplossing was in CloudFormation, wezen ze me op een hele git-repository met een implementatiepijplijn en zo, allemaal ter wille van iets dat arme vier regels Terraform-code zouden kunnen doen.
Het detecteert drift beter
Zorg ervoor dat de werkelijkheid overeenkomt met de verwachtingen.
is een zeer krachtige bewerking als codefunctie omdat het ervoor zorgt dat de werkelijkheid overeenkomt met de verwachtingen. Het is beschikbaar met zowel CloudFormation als Terraform. Maar naarmate de productiestapel groeide, leverde het zoeken naar drift in CloudFormation steeds meer valse detecties op.
Met Terraform beschikt u over veel geavanceerdere levenscyclushaken voor driftdetectie. U voert bijvoorbeeld de opdracht in rechtstreeks in de ECS-taakdefinitie als u wijzigingen in een specifieke taakdefinitie wilt negeren zonder wijzigingen in uw gehele ECS-implementatie te negeren.
CDK en de toekomst van CloudFormation
CloudFormation is moeilijk te beheren op grote, infrastructuuroverschrijdende schaalniveaus. Veel van deze problemen worden onderkend en de tool heeft zaken nodig als: , een raamwerk voor het definiëren van de cloudinfrastructuur in code en het uitvoeren ervan via AWS CloudFormation. Het zal interessant zijn om te zien wat de toekomst in petto heeft voor aws-cdk, maar het zal moeilijk worden om te concurreren met de andere sterke punten van Terraform; om CloudFormation up-to-date te brengen zijn mondiale veranderingen nodig.
Zodat Terraform niet teleurstelt
Dit is ‘infrastructuur als code’, en niet ‘als tekst’.
Mijn eerste indruk van Terraform was nogal slecht. Ik denk dat ik de aanpak gewoon niet begreep. Vrijwel alle ingenieurs zien het onwillekeurig als een tekstformaat dat moet worden omgezet in de gewenste infrastructuur. DOE HET NIET OP DEZE MANIER.
De waarden van goede softwareontwikkeling gelden ook voor Terraform.
Ik heb gezien dat veel praktijken die zijn toegepast om goede code te maken, in Terraform worden genegeerd. Je hebt jaren gestudeerd om een goede programmeur te worden. Geef deze ervaring niet op alleen maar omdat u met Terraform werkt. De waarden van goede softwareontwikkeling zijn van toepassing op Terraform.
Hoe kan de code niet worden gedocumenteerd?
Ik heb enorme Terraform-stacks gezien zonder enige documentatie. Hoe kun je code in pagina's schrijven - zonder enige documentatie? Voeg documentatie toe waarin uw code Terraform (nadruk op het woord "code"), waarom deze sectie zo belangrijk is en wat u doet.
Hoe kunnen we services inzetten die ooit één grote main()-functie waren?
Ik heb zeer complexe Terraform-stacks gezien die als een enkele module werden gepresenteerd. Waarom implementeren we software niet op deze manier? Waarom splitsen we grote functies op in kleinere? Dezelfde antwoorden zijn van toepassing op Terraform. Als uw module te groot is, moet u deze opsplitsen in kleinere modules.
Maakt uw bedrijf geen gebruik van bibliotheken?
Ik heb gezien hoe ingenieurs, die een nieuw project op touw zetten met Terraform, op stomme wijze grote stukken van andere projecten in hun eigen project kopieerden en er vervolgens aan sleutelden totdat het begon te werken. Zou jij in jouw bedrijf ook zo met “combat”-code werken? We gebruiken niet alleen bibliotheken. Ja, maar waar zijn we in principe zonder gedeelde bibliotheken?!
Maak je geen gebruik van PEP8 of gofmt?
De meeste talen hebben een standaard, geaccepteerd opmaakschema. In Python is dit PEP8. In Go-gofmt. Terraform heeft zijn eigen: terraform fmt. Geniet ervan voor uw gezondheid!
Ga je React gebruiken zonder JavaScript te kennen?
Terraform-modules kunnen een deel van de complexe infrastructuur die u creëert vereenvoudigen, maar dit betekent niet dat u er helemaal niet aan kunt sleutelen. Wilt u Terraform correct gebruiken zonder de hulpmiddelen te begrijpen? Je bent gedoemd: de tijd zal verstrijken en je zult Terraform nooit onder de knie krijgen.
Codeert u met alleenstaanden of afhankelijkheidsinjectie?
Afhankelijkheidsinjectie is een erkende best practice voor softwareontwikkeling en verdient de voorkeur boven singletons. Hoe is dit nuttig in Terraform? Ik heb Terraform-modules gezien die afhankelijk zijn van de externe status. In plaats van modules te schrijven die de externe status ophalen, schrijft u een module die parameters opneemt. En geef deze parameters vervolgens door aan de module.
Doen uw bibliotheken tien dingen goed of één ding geweldig?
Bibliotheken die het beste werken, zijn bibliotheken die zich concentreren op één taak die ze heel goed doen. In plaats van grote Terraform-modules te schrijven die alles in één keer proberen te doen, kun je er delen van bouwen die één ding goed doen. En combineer ze vervolgens indien nodig.
Hoe breng je wijzigingen aan in bibliotheken zonder achterwaartse compatibiliteit?
Een algemene Terraform-module moet, net als een gewone bibliotheek, op de een of andere manier wijzigingen aan gebruikers communiceren zonder achterwaarts compatibel te zijn. Het is vervelend als deze veranderingen plaatsvinden in bibliotheken, en het is net zo vervelend als er niet-achterwaarts compatibele wijzigingen worden aangebracht in Terraform-modules. Het wordt aanbevolen om git-tags en semver te gebruiken bij het gebruik van Terraform-modules.
Draait uw productiedienst op uw laptop of in een datacenter?
Hashicorp heeft tools zoals om je terraform te runnen. Deze gecentraliseerde services maken het eenvoudig om terraformwijzigingen te beheren, controleren en goed te keuren.
Schrijf jij geen testen?
Engineers beseffen dat de code getest moet worden, maar zelf vergeten ze vaak het testen als ze met Terraform werken. Voor infrastructuur brengt dit verraderlijke momenten met zich mee. Mijn advies is om stapels te “testen” of “voorbeelden te maken” met behulp van modules die correct kunnen worden ingezet voor testen tijdens CI/CD.
Terraform en microservices
Het leven en de dood van microservicesbedrijven hangt af van de snelheid, innovatie en disruptie van nieuwe microserviceworkstacks.
Het meest voorkomende negatieve aspect dat verband houdt met microservice-architecturen en dat niet kan worden geëlimineerd, heeft te maken met het werk, niet met de code. Als je Terraform beschouwt als slechts een manier om alleen de infrastructuurkant van een microservices-architectuur te automatiseren, dan mis je de echte voordelen van het systeem. Nu is het al zo .
Bron: www.habr.com