Att representera infrastruktur som kod i ett repeterbart textformat är en enkel bästa praxis för system som inte kräver att pilla med möss. Denna praxis har ett namn - , och hittills finns det två populära verktyg för att implementera det, särskilt i AWS: и .
Jämför erfarenhet med Terraform och CloudFormation
Innan du kommer till (Aka ) Jag jobbade och använde Terraform i tre år. På det nya stället använde jag även Terraform med all kraft och sedan drev företaget övergången till allt a la Amazon, inklusive CloudFormation. Jag har flitigt utvecklat bästa praxis för båda och har använt båda verktygen i mycket komplexa, organisationsövergripande arbetsflöden. Senare, efter att ha funderat över konsekvenserna av att migrera från Terraform till CloudFormation, blev jag övertygad om att Terraform förmodligen var det bästa valet för organisationen.
Terraform Horrible
Beta programvara
Terraform har inte ens släppt version 1.0 än, vilket är en bra anledning att inte använda den. Det har förändrats mycket sedan jag först provade det själv, men då terraform apply gick ofta sönder efter flera uppdateringar eller helt enkelt efter ett par års användning. Jag skulle säga att "allt är annorlunda nu", men... det är vad alla verkar säga, eller hur? Det finns ändringar som är oförenliga med tidigare versioner, även om de är lämpliga, och det känns till och med som att syntaxen och abstraktionerna i resursbutiker nu är vad vi behöver. Instrumentet verkar verkligen ha blivit bättre, men... :-0
Å andra sidan har AWS gjort ett bra jobb med att upprätthålla bakåtkompatibilitet. Det beror förmodligen på att deras tjänster ofta testas noggrant inom organisationen och först då, bytt namn, publiceras. Så "de försökte hårt" är en underdrift. Att upprätthålla bakåtkompatibilitet med API:er för ett så varierat och komplext system som AWS är otroligt svårt. Alla som har varit tvungna att underhålla offentliga API:er som används så brett som de är borde förstå hur svårt det är att göra det i så många år. Men CloudFormations beteende, i mitt minne, har aldrig förändrats under åren.
Möt benet... det är en kula
Så vitt jag vet, ta bort resursen utomstående CloudFormation-stack från din CF-stack är inte möjligt. Samma sak gäller med Terraform. Det låter dig importera befintliga resurser till din stack. Funktionen kan sägas vara fantastisk, men med stor kraft följer ett stort ansvar. Du behöver bara lägga till en resurs till stacken, och medan du arbetar med din stacken kan du inte ta bort eller ändra den här resursen. En dag slog det tillbaka. En dag på Twitch importerade någon av misstag någon annans AWS-säkerhetsgrupp till sin egen Terraform-stack utan att vara beredd på något bus. Jag skrev in flera kommandon och... säkerhetsgruppen (tillsammans med inkommande trafik) försvann.
Terraform Fantastiskt
Återhämtning från ofullständiga tillstånd
Ibland misslyckas CloudFormation att helt övergå från ett tillstånd till ett annat. Samtidigt kommer han att försöka återgå till den föregående. Det är synd att detta inte alltid är genomförbart. Det kan vara ganska läskigt att felsöka vad som hände senare - man vet aldrig om CloudFormation kommer att vara glad över att det hackas - inte ens bara för att fixa det. Huruvida det kommer att vara möjligt att återgå till det tidigare tillståndet eller inte, han vet verkligen inte hur han ska avgöra och, som standard, hänger han i timmar och väntar på ett mirakel.
Terraform, å andra sidan, tenderar att återhämta sig från misslyckade övergångar mycket mer graciöst och erbjuder avancerade felsökningsverktyg.
Tydligare ändringar av dokumentstatus
"Okej, lastbalanserare, du ändrar dig. Men hur?"
— ängslig ingenjör, redo att trycka på "acceptera"-knappen.
Ibland behöver jag göra några manipulationer med lastbalanseraren i CloudFormation-stacken, som att lägga till ett portnummer eller ändra en säkerhetsgrupp. ClouFormation visar dåliga förändringar. Jag, på nålar, dubbelkollar yaml-filen tio gånger för att se till att jag inte har raderat något nödvändigt och inte lagt till något onödigt.
Terraform är mycket mer transparent i detta avseende. Ibland är han till och med för transparent (läs: tråkig). Lyckligtvis innehåller den senaste versionen förbättrad visning av ändringar så att du nu kan se exakt vad som förändras.
flexibilitet
Skriv mjukvara baklänges.
För att säga det rakt ut är den viktigaste egenskapen hos mjukvara med lång livslängd förmågan att anpassa sig till förändringar. Skriv valfri programvara baklänges. Oftast gjorde jag misstag genom att ta en "enkel" tjänst och sedan börja klämma in allt i en enda CloudFormation- eller Terraform-stack. Och självklart, månader senare avslöjades det att jag hade förstått allt fel, och tjänsten var faktiskt inte enkel! Och nu måste jag på något sätt bryta en stor stapel i små komponenter. När du arbetar med CloudFormation kan detta bara göras genom att först återskapa den befintliga stacken, och jag gör inte detta med mina databaser. Terraform, å andra sidan, gjorde det möjligt att dissekera stapeln och bryta ner den i mer begripliga mindre delar.
Moduler i git
Att dela Terraform-kod över flera stackar är mycket enklare än att dela CloudFormation-kod. Med Terraform kan du lägga din kod i ett git-förråd och komma åt den med hjälp av semantisk versionskontroll. Alla som har tillgång till det här förrådet kan återanvända den delade koden. CloudFormations motsvarighet är S3, men det har inte samma fördelar, och det finns ingen anledning till att vi ska överge git till förmån för S3 överhuvudtaget.
Organisationen växte och förmågan att dela gemensamma stackar nådde en kritisk nivå. Terraform gör allt detta enkelt och naturligt, medan CloudFormation kommer att få dig att hoppa igenom ringar innan du kan få något liknande att fungera.
Operationer som kod
"Låt oss skriva det och okej."
—en ingenjör 3 år innan han uppfann Terraform-cykeln.
När det kommer till mjukvaruutveckling är Go eller ett Java-program inte bara kod.
Koda som kod
Det finns också infrastrukturen som det fungerar på.
Infrastruktur som kod
Men var är hon ifrån? Hur övervakar man det? Var bor din kod? Behöver utvecklare åtkomstbehörighet?
Operationer som kod
Att vara mjukvaruutvecklare betyder inte bara att skriva kod.
AWS är inte den enda: du använder förmodligen andra leverantörer. SignalFx, PagerDuty eller Github. Kanske har du en intern Jenkins-server för CI/CD eller en intern Grafana-dashboard för övervakning. Infra as Code väljs av olika anledningar, och var och en är lika viktig för allt som har med mjukvara att göra.
När jag jobbade på Twitch accelererade vi tjänsterna i Amazons blandade inbäddade och AWS-system. Vi tog fram och stödde många mikrotjänster, vilket ökade driftskostnaderna. Diskussionerna gick ungefär så här:
- Я: Fan, det är många gester för att överklocka en mikrotjänst. Jag måste använda detta skräp för att skapa ett AWS-konto (vi gick till 2 konton på mikrotjänst), sedan den här för att ställa in varningar, den här för ett kodlager, och den här för en e-postlista, och sedan den här...
- Leda: Låt oss skriva det och okej.
- Я: Okej, men själva skriptet kommer att ändras. Vi kommer att behöva ett sätt att kontrollera att alla dessa inbyggda Amazon-prylar är uppdaterade.
- Leda: Låter bra. Och vi kommer att skriva ett manus för detta.
- Я: Bra! Och skriptet kommer förmodligen fortfarande att behöva ställa in parametrar. Kommer han att acceptera dem?
- Leda: Låt honom ta dit han går!
- Я: Processen kan ändras och bakåtkompatibiliteten går förlorad. Någon form av semantisk versionskontroll kommer att krävas.
- Leda: Bra ide!
- Я: Verktyg kan ändras manuellt i användargränssnittet. Vi behöver ett sätt att kontrollera och fixa detta.
…3 år senare:
- Leda: Och vi fick terraform.
Moralen i berättelsen är: även om du pladask i allt Amazon, använder du fortfarande något som inte kommer från AWS, och dessa tjänster har ett tillstånd som använder ett konfigurationsspråk för att hålla det tillståndet synkroniserat.
CloudFormation lambda vs git-moduler terraform
lambda är CloudFormations lösning på problemet med anpassad logik. Med lambda kan du eller . Detta tillvägagångssätt introducerar ytterligare komplexitet som inte finns i Terraforms semantiska versionering av git-moduler. För mig var det mest pressande problemet att hantera behörigheter för alla dessa användarlambdas (och dessa är dussintals AWS-konton). Ett annat viktigt problem var "vad kom först, hönan eller ägget?"-problemet: det var relaterat till lambdakoden. Denna funktion i sig är infrastruktur och kod, och den behöver i sig övervakning och uppdateringar. Den sista spiken i kistan var svårigheten att semantiskt uppdatera lambdakodändringar; vi var också tvungna att se till att stackåtgärderna utan ett direkt kommando inte ändrades mellan körningarna.
Jag minns att jag en gång ville skapa en kanariefågel för miljön Elastic Beanstalk med en klassisk lastbalanserare. Det enklaste att göra skulle vara att göra en andra driftsättning för EB bredvid produktionsmiljön, ta det ett steg längre: att kombinera den automatiskt skalande kanariefågelinstallationsgruppen med distributions-LB i produktionsmiljön. Och eftersom Terraform använder , kommer detta att kräva 4 extra rader kod i Terraform. När jag frågade om det fanns en jämförbar lösning i CloudFormation, pekade de mig på ett helt git-förråd med en distributionspipeline och allt, allt för något som dåliga 4 rader Terraform-kod kunde göra.
Den upptäcker drift bättre
Se till att verkligheten matchar förväntningarna.
är en mycket kraftfull funktion som kodfunktion eftersom den hjälper till att säkerställa att verkligheten matchar förväntningarna. Den är tillgänglig med både CloudFormation och Terraform. Men i takt med att produktionsstacken växte producerade sökningen efter drift i CloudFormation fler och fler falska upptäckter.
Med Terraform har du mycket mer avancerade livscykelkrokar för avdriftsdetektering. Till exempel anger du kommandot direkt i ECS-uppgiftsdefinitionen om du vill ignorera ändringar av en specifik uppgiftsdefinition utan att ignorera ändringar i hela din ECS-distribution.
CDK och framtiden för CloudFormation
CloudFormation är svårt att hantera i stor skala över infrastruktur. Många av dessa svårigheter känns igen och verktyget behöver saker som , ett ramverk för att definiera molninfrastruktur i kod och köra den genom AWS CloudFormation. Det ska bli intressant att se hur framtiden ser ut för aws-cdk, men det kommer att ha svårt att konkurrera med Terraforms andra styrkor; för att uppdatera CloudFormation kommer globala förändringar att krävas.
Så att Terraform inte gör dig besviken
Detta är "infrastruktur som en kod" och inte "som en text".
Mitt första intryck av Terraform var ganska dåligt. Jag tror att jag helt enkelt inte förstod tillvägagångssättet. Nästan alla ingenjörer uppfattar det ofrivilligt som ett textformat som måste konverteras till önskad infrastruktur. GÖR DET INTE SÅ SÄTT.
Sanningen med bra mjukvaruutveckling gäller även Terraform.
Jag har sett många metoder som används för att skapa bra kod ignoreras i Terraform. Du har studerat i flera år för att bli en bra programmerare. Ge inte upp den här erfarenheten bara för att du arbetar med Terraform. Truismerna med bra mjukvaruutveckling gäller Terraform.
Hur kan koden inte dokumenteras?
Jag har sett enorma Terraform-stackar med absolut ingen dokumentation. Hur kan du skriva kod på sidor - helt utan dokumentation? Lägg till dokumentation som förklarar din код Terraform (betoning på ordet "kod"), varför detta avsnitt är så viktigt och vad du gör.
Hur kan vi distribuera tjänster som en gång var en stor main()-funktion?
Jag har sett mycket komplexa Terraform-stackar presenteras som en enda modul. Varför distribuerar vi inte programvara på det här sättet? Varför delar vi upp stora funktioner i mindre? Samma svar gäller Terraform. Om din modul är för stor måste du dela upp den i mindre moduler.
Använder inte ditt företag bibliotek?
Jag har sett hur ingenjörer, som skapade ett nytt projekt med Terraform, dumt kopierade in stora bitar från andra projekt i sina egna och sedan mixtrade med dem tills det började fungera. Skulle du arbeta så här med "combat"-kod i ditt företag? Vi använder inte bara bibliotek. Ja, men var är vi utan delade bibliotek i princip?!
Använder du inte PEP8 eller gofmt?
De flesta språk har ett standard, accepterat formateringsschema. I Python är detta PEP8. I Go - gofmt. Terraform har sin egen: terraform fmt. Njut av det för din hälsa!
Kommer du att använda React utan att kunna JavaScript?
Terraform-moduler kan förenkla en del av den komplexa infrastruktur du skapar, men det betyder inte att du inte kan mixtra med den alls. Vill du använda Terraform korrekt utan att förstå resurser? Du är dömd: tiden kommer att gå och du kommer aldrig att bemästra Terraform.
Kodar du med singlar eller beroendeinjektion?
Beroendeinjektion är en erkänd bästa praxis för mjukvaruutveckling och är att föredra framför singlar. Hur är detta användbart i Terraform? Jag har sett Terraform-moduler som är beroende av fjärrtillstånd. Istället för att skriva moduler som hämtar fjärrtillstånd, skriv en modul som tar parametrar. Och skicka sedan dessa parametrar till modulen.
Gör dina bibliotek tio saker bra eller en sak bra?
Bibliotek som fungerar bäst är de som fokuserar på en uppgift som de gör mycket bra. Istället för att skriva stora Terraform-moduler som försöker göra allt på en gång, bygg delar av dem som gör en sak bra. Och sedan kombinera dem efter behov.
Hur gör man ändringar i bibliotek utan bakåtkompatibilitet?
En vanlig Terraform-modul, som ett vanligt bibliotek, måste på något sätt kommunicera ändringar till användarna utan att vara bakåtkompatibel. Det är irriterande när dessa förändringar sker i bibliotek, och det är lika irriterande när icke-bakåtkompatibla ändringar görs i Terraform-moduler. Det rekommenderas att använda git-taggar och semver när du använder Terraform-moduler.
Körs din produktionstjänst på din bärbara dator eller i ett datacenter?
Hashicorp har verktyg som att köra din terraform. Dessa centraliserade tjänster gör det enkelt att hantera, granska och godkänna terraformändringar.
Skriver du inte prov?
Ingenjörer inser att koden måste testas, men de glömmer ofta själva bort att testa när de arbetar med Terraform. För infrastrukturen är detta fyllt av förrädiska ögonblick. Mitt råd är att "testa" eller "skapa exempel" stackar med hjälp av moduler som kan distribueras korrekt för testning under CI/CD.
Terraform och mikrotjänster
Mikrotjänsteföretagens liv och död beror på hastigheten, innovationen och störningen av nya mikrotjänstarbetsstackar.
Den vanligaste negativa aspekten förknippad med mikrotjänstarkitekturer, och som inte kan elimineras, är relaterad till arbetet, inte koden. Om du tänker på Terraform som bara ett sätt att automatisera enbart infrastruktursidan av en mikrotjänstarkitektur, så går du miste om de verkliga fördelarna med systemet. Nu är det redan .
Källa: will.com