Jag gick från Terraform till CloudFormation - och ångrade mig

Att representera infrastruktur som kod i ett reproducerbart textformat är en enkel, bästa praxis för system som inte behöver knådas. Denna praxis har fått namnet - Infrastructure as Code, och hittills finns det två populära verktyg för att genomföra detta, särskilt i AWS: Terraform och CloudFormation.

Jag jämför erfarenheten av att arbeta med Terraform och CloudFormation

Innan jag kom till Twitch (även känd som Amazon Jr.) arbetade jag på en startup och i tre år använde jag Terraform. På min nya arbetsplats använde jag också Terraform friskt, men senare pressade företaget införandet av allt som liknade Amazon, inklusive CloudFormation. Jag utvecklade noggrant bästa praxis för både och använde båda verktygen i mycket komplexa arbetsflöden på organisationsnivå. Efter att ha övervägt konsekvenserna av att gå från Terraform till CloudFormation insåg jag att Terraform antagligen är det bästa valet för organisationen.

Terraform Skrämmande

Beta-version av mjukvara

Terraform har inte ens lanserat version 1.0 än, och det är en god anledning att inte använda det. Sedan jag först testade det har det förändrats mycket, men då var det fortfarande terraform apply ofta trasigt efter några uppdateringar eller bara efter ett par års användning. Jag skulle säga att 'nu är allt annorlunda', men... så verkar alla säga, eller hur? Det finns förändringar som är inkompatibla med tidigare versioner, även om de är rimliga, och till och med en känsla av att syntax och abstraktioner av resurslagring nu är precis vad de ska vara. Verktyget verkar verkligen ha blivit bättre, men... :-0

Å andra sidan har AWS gjort ett bra jobb med att stödja bakåtkompatibilitet med tidigare versioner. Förmodligen därför att deras tjänster ofta testas ordentligt internt innan de publiceras under ett nytt namn. Så det är en underdrift att säga att de 'gjorde ett bra jobb'. Att upprätthålla bakåtkompatibilitet med tidigare API-versioner för ett så mångfacetterat och komplext system som AWS är otroligt svårt. Alla som har behövt underhålla offentliga API:er som används så brett vet hur svårt detta är att göra under så många år. Men CloudFormations beteende har under min tid aldrig förändrats genom åren.

Hälsning, fot... detta är en kula

Såvitt jag vet går det inte att ta bort en resurs från tredje part Att importera en CloudFormation-stapel från sin egen CF-stapel är omöjligt. Det är i princip samma sak med Terraform. Det tillåter import av befintliga resurser till sin stapel. Funktionen är, kan man säga, fantastisk, men med stor makt kommer stort ansvar. Så fort du lägger en resurs i stapeln, kan du inte ta bort eller ändra den resursen medan du arbetar med din stapel. En gång fick vi känna av konsekvenserna. Någon på Twitch, som inte hade något ont i sinnet, av misstag importerade någon annans AWS-säkerhetsgrupp till sin egen Terraform-stapel. Han skrev några kommandon och… säkerhetsgruppen (tillsammans med den inkommande trafiken) försvann.

Terraform Stor

Återställning från ofullständiga tillstånd

Ibland kan CloudFormation inte helt övergå från ett tillstånd till ett annat. I så fall försöker det återgå till det föregående. Tyvärr är det inte alltid möjligt. Att felsöka det som uppstått kan vara ganska skrämmande — man vet aldrig om CloudFormation kommer att bli glad av att bli 'hackad' — även om det är för reparation. Och om det verkligen går att återgå till det föregående tillståndet vet det inte riktigt, och som standard hänger det i timmar i väntan på ett mirakel.

Terraform tvärt om har en tendens att återhämta sig efter misslyckade övergångar på ett mer elegant sätt och erbjuder ett utökat felsökningsverktyg.

Tydligare ändringar i dokumentets tillstånd

«Okej, lastbalanserare, du förändras. Men hur?»

— orolig ingenjör, redo att trycka på knappen «acceptera».

Ibland behöver jag göra vissa manipulationer med lastbalanseraren i CloudFormation-stapeln — till exempel lägga till ett portnummer eller ändra säkerhetsgruppen. CloudFormation visar förändringar svagt. Jag, å sin sida, går på nålar och dubbelkollar yaml-filen tio gånger för att försäkra mig om att jag inte raderar något nödvändigt eller lägger till något onödigt.

Terraform är mycket mer transparent i detta avseende. Ibland är den till och med för transparent (läs: irriterande). Som tur är, har den senaste versionen förbättrat visningen av ändringar — nu syns det tydligt vad som förändras.

Flexibilitet

Skriv mjukvara baklänges.

Ärligt talat, den viktigaste kännetecknen för långlivat mjukvara är dess förmåga att anpassa sig till förändringar. Skriv alltid programvara baklänges. Jag har oftast kört fast med den 'enkla' tjänsten, bara för att senare försöka pressa allt in i en enda CloudFormation- eller Terraform-stack. Och naturligtvis, efter månader, visade det sig att jag hade förstått allt fel, och tjänsten var faktiskt inte enkel! Nu behöver jag på något sätt dela upp den stora stacken i mindre beståndsdela. När man arbetar med CloudFormation är det möjligt att göra det endast efter att ha återskapat den existerande stacken, vilket jag, med mina databaser, inte gör. Terraform å sin sida gjorde det möjligt att dissekera stacken och dela upp den i mer begripliga mindre delar.

Moduler i git

Att dela Terraform-kod mellan flera stackar är mycket enklare än att dela CloudFormation-kod. Med Terraform kan man placera koden i ett git-repo och referera till den med hjälp av semantisk versionskontroll. Alla som har åtkomst till detta repo kan återanvända den delade koden. Motsvarigheten i CloudFormation är S3, men den har inte samma fördelar, och det finns ingen anledning att överge git till förmån för S3.

Organisationen växte och förmågan att dela gemensamma stackar nådde en kritisk nivå. Med Terraform går detta enkelt och naturligt, medan CloudFormation får dig att hoppa genom ringar innan något liknande fungerar för dig.

Operations som kod

»Låt oss skripta och vara klara.«

—en ingenjör tre år innan han uppfann Terraform.

När det gäller mjukvaruutveckling är Go eller ett program i Java inte bara kod.

Kod som kod

Det finns ju också infrastrukturen där den körs.

Infrastructure as Code

Men var kommer den ifrån? Hur övervakar man den? Var finns din kod? Behöver utvecklarna behörighet för åtkomst?

Operations som kod

Att vara mjukvaruutvecklare handlar inte bara om att skriva kod.

Inte bara AWS: du använder säkert tjänster från andra leverantörer också. SignalFx, PagerDuty eller Github. Kanske har du en intern Jenkins-server för CI/CD eller en intern Grafana-panel för övervakning. Infra som kod väljs av olika anledningar och alla är lika viktiga för allt som har att göra med mjukvara.

När jag arbetade på Twitch, förbättrade vi tjänster inom blandade inbyggda system och AWS-system. Vi skapade och underhöll många mikrotjänster, vilket ökade driftskostnaderna. Diskussionerna handlade ungefär så här:

• Jag: Fan, ganska mycket arbete för att få igång en mikrotjänst. Jag måste använda det här för att skapa ett AWS-konto (vi gick mot 2 konton på mikrotjänst), sedan det här för att konfigurera aviseringarna, det här för kodförrådet, och det här för e-postadresser, och så det här...
• Lead: Låt oss få det skripterat och klart.
• Jag: Okej, men själva skriptet kommer att ändras. Vi behöver ett sätt att verifiera att alla dessa inbyggda Amazon-grejer har aktuellt tillstånd.
• Lead: Låter bra. Så vi får skriva ett skript för det.
• Jag: Utmärkt! Och skriptet behöver säkert också ha parametrar. Kommer det att acceptera dem?
• Lead: Ja, det accepterar de, vad kan det annars göra!
• Jag: Processen kan förändras, bakåtkompatibiliteten kan gå förlorad. Vi kommer att behöva någon form av semantisk versionskontroll.
• Lead: Utmärkt idé!
• Jag: Verktygen kan ändras manuellt i användargränssnittet. Vi behöver ett sätt att kontrollera och åtgärda det.

...3 år senare:

• Lead: Och nu har vi terraform.

Moralen i historien är: även om du är upp över öronen i allt Amazon-relaterat, använder du ändå något som inte är från AWS, och dessa tjänster har ett tillstånd som använder ett språk för konfiguration för att synkronisera det tillståndet.

CloudFormation lambda vs git-moduler terraform

lambda är CloudFormation-lösningen för användarlogik. Med lambda kan man skapa makron eller anpassad resurs. Denna metod medför ytterligare komplexiteter som inte finns i den semantiska versionskontrollen av git-moduler i Terraform. För mig blev den mest akuta frågan hantering av behörigheter för alla dessa användar-lambda (som involverar tiotals AWS-konton). En annan viktig fråga blev problemet med "vad kom först — hönan eller ägget?": det handlade om lambda-koden. Denna funktion är både infrastruktur och kod, och den behöver kontinuerlig övervakning och uppdateringar. Den sista spiken i kistan blev svårigheten i den semantiska uppdateringen av lambda-kodens förändringar; vi behövde också se till att stacken inte förändrades mellan körningar utan direkt kommando.

Jag kommer ihåg en gång när jag ville skapa en kanariedepoy för Elastic Beanstalk-miljön med en klassisk belastningsutjämnare. Det skulle vara enklast att göra en andra distribution för EB bredvid produktionsmiljön, och ta ett steg till genom att koppla samman den automatiskt skalbara gruppen av kanariedepoy med LB-distributionen i produktionsmiljön. Eftersom Terraform använder ASG beantalk som utdata, det skulle kräva 4 extra kodrader i Terraform. När jag frågade om det fanns någon jämförbar lösning i CloudFormation, pekade man mig på ett helt arkiv på git med distributionspipeline och annat: och allt detta bara för att vi skulle kunna göra de eländiga 4 raderna kod i Terraform.

Den upptäcker driftsättning

Se till att verkligheten överensstämmer med förväntningarna.

Upptäckte driftsättning — är en mycket kraftfull funktion för operations as code, eftersom den hjälper till att säkerställa att verkligheten överensstämmer med förväntningarna. Den är tillgänglig både med CloudFormation och med Terraform. Men när arbetsstacken växte visade CloudFormation allt fler falska positiva resultat vid driftupptäckten.

Med Terraform har du mycket mer avancerade livscykelhakar för att upptäcka drift. Till exempel skriver du kommandot ignore_changes direkt i ECS-uppgiftsdefinitionen om du vill ignorera ändringar i definitionen av en specifik uppgift utan att ignorera ändringar i hela ECS-distributionen.

CDK och framtiden för CloudFormation

CloudFormation är svårt att hantera i stora, tvärinfrastrukturiska skala. Många av dessa svårigheter är erkända, och verktyget behöver sådana saker som aws-cdk, en struktur för att definiera molninfrastruktur i kod och föra den genom AWS CloudFormation. Det blir intressant att se vad som väntar aws-cdk i framtiden, men det blir svårt för det att konkurrera med de andra fördelarna med Terraform; för att CloudFormation ska kunna förbättras krävs globala förändringar.

För att Terraform inte ska göra en besviken

Det är ju "infrastruktur som KOD", inte "som text".

Min första upplevelse av Terraform var ganska negativ. Jag tror att jag helt enkelt inte förstod konceptet. Nästan alla ingenjörer upplever det först oavsiktligt som ett textformat som måste omvandlas till önskad infrastruktur. DET ÄR INTE NÖDVÄNDIGT SÅ.

Självklart gäller de grundläggande sanningarna för god programvaruutveckling även för Terraform.

Jag har sett hur många av de metoder som antas för att skapa bra kod ignoreras i Terraform. Du har studerat i åratal för att bli en bra programmerare. Tveka inte att använda den kunskapen bara för att du arbetar med Terraform. Grundläggande principer för bra mjukvaruutveckling gäller även för Terraform.

Hur kan man inte dokumentera koden?

Jag har stött på enorma Terraform-staplar helt utan dokumentation. Hur kan man skriva kod i sidor utan att ha någon dokumentation? Lägg till dokumentation som förklarar din kod Terraform (betoning på ordet "kod"), varför detta avsnitt är så viktigt, och vad du gör.

Hur kan man driftsätta tjänster som tidigare var en stor main()-funktion?

Jag har stött på mycket komplexa Terraform-staplar presenterade som en enda modul. Varför driftsätter vi inte mjukvara så? Varför delar vi upp stora funktioner i mindre? Samma svar gäller för Terraform. Om modulen är för stor, bör vi dela upp den i mindre moduler.

Använder inte ditt företag bibliotek?

Jag har sett ingenjörer som, när de startar ett nytt projekt med Terraform, bara kopierar och klistrar in stora bitar från andra projekt till sina egna, och sedan försökte få dem att fungera. Skulle ni i ert företag arbeta så med "produktions"-kod? Vi använder inte bibliotek utan anledning. Ja, inte allt bör vara ett bibliotek, men hur ska vi klara oss utan gemensamma bibliotek överhuvudtaget?!

Använder ni inte PEP8 eller gofmt?

De flesta språk har ett standardformat som är allmänt accepterat. I Python är det PEP8. I Go är det gofmt. Terraform har sitt: terraform fmt. Använd det gärna!

Kommer du att använda React utan att veta JavaScript?

Terraform-moduler kan förenkla en del av den komplexa infrastruktur som du bygger, men det betyder inte att man helt kan ignorera den. Vill du använda Terraform korrekt utan att förstå resurser? Du är dömd: tiden kommer att gå, och du kommer fortfarande inte att behärska Terraform.

Kodrar du singeltoner, eller injicerar du beroenden?

Dependency injection är en erkänd bästa praxis för programutveckling, föredragen av singeltoner. Hur kommer detta till nytta i Terraform? Jag har stött på Terraform-moduler som är beroende av ett fjärrläge. Istället för att skriva moduler som hämtar från fjärrläget, skriv en modul som tar emot parametrar. Och skicka sedan dessa parametrar till modulen.

Gör dina bibliotek tio saker bra eller en - utmärkt?

Bibliotek fungerar bäst när de fokuserar på en enda uppgift som de utför utmärkt. Istället för att skriva stora Terraform-moduler som försöker göra allt på en gång, bryt ner dem i delar som gör en sak bra. Och kombinera dem sedan på det sätt som behövs.

Hur gör ni förändringar i biblioteken utan att bryta bakåtkompatibiliteten?

En gemensam Terraform-modul, precis som ett vanligt bibliotek, måste på något sätt kommunicera förändringar till användarna utan att bryta bakåtkompatibiliteten. När sådana förändringar inträffar i biblioteken är det frustrerande, och precis lika frustrerande när förändringar utan bakåtkompatibilitet görs i Terraform-moduler. Det rekommenderas att använda git-tags och semver vid användning av Terraform-moduler.

Är produktionsservicen igång på din bärbara dator eller i datacentret?

Hashicorp har verktyg som terraform cloud för att köra din terraform. Dessa centraliserade tjänster förenklar hantering, revision och godkännande av terraform-förändringar.

Skriver du inte tester?

Ingenjörer erkänner att koden måste testas, men de glömmer ofta bort att göra kontroller när de arbetar med Terraform. För infrastrukturen kan detta leda till oväntade problem. Jag rekommenderar att "testa" eller "skapa exempel" på staplar med moduler som kan deployas korrekt för att verifieras under CI/CD.

Terraform och mikrotjänster

Liv och död för företag med mikrotjänster beror på hastighet, uppdateringar och avveckling av nya mikrotjänstarbets staplar.

Det mest utbredda negativa problemet med mikrotjänstarkitekturer, som inte går att undkomma, handlar om arbete, och inte kod. Om man endast ser Terraform som ett sätt att automatisera den infrastrukturella sidan av mikrotjänstarkitekturen, berövar man sig de riktiga fördelarna med detta system. Nu är allt som kod.

Källa: habr.com