Terraform Enterprise?

sub

Hi,

Ugyan mi nem hasznalunk terraform enterprise-ot (netes forrasok alapjan iszonyat draga es nem igazan lattam ertelmet...) de en osszeraktam egy rendszert, ami par napon belul megy production-be. Gondoltam megirom, hogy ez mit tud, hatha kapsz belole egy-ket otletet. Nalunk en terveztem es implementatlatm az egeszet (szerencsere szabad kezem van ilyeneknel es altalaban az admin kollegaim boldogok a vegen amikor hasznaljak ezeket :) )

Leirom, hogy hogy nez ki a rendszer es megemlitem, hogy mit miert csinaltam. Hosszu lesz de sztem tanulsagos :).
Az alapja ket gitlab CI pipeline.

Pipeline 1:
Ahhoz, hogy a terraform mukodjon, kell maga a terraform binary, providerek es a modulok. Ezeknek mindnek sajat life-cycle-je (kulon verzioja van). Ahhoz hogy erdemben le lehessen tesztelni oket es az egymassal valo kompatibilitast, mindegyikbol egy edott verzio kell es ezeket egyutt kell tesztelni. Ezert az elso gitlab CI pipeline-al buildelek egy container imaget, aminek a product-ja egy single, versioned container image a container registry-be, ami tartalmazz az osszes!!! komponenst, amit hasznalunk ahhoz, hogy a kovetkezo pipeline-al configuraljuk a real infrat. Minden komponensnel version pinning van. Ezt manualisan (egy script segitsegevel) update-eljuk uj release-nel. A komponensek a kovetkezok:
* terraform binaris 
* osszes provider (jelenleg kb 8)
* sajat terraform modulok a git repo-bol 
* 3rd party modulok, amiknek egy adott verziojat le-vendoralok a terraform registry-bol xterrafile-al a sajat repoba
* tflint binaris, ez az egyik eleme a static analysys-nek, ami megfog olyan dolgokat is amit terraform validate nem
* tfsec binaris, ez a masik static analysis tool amit hasznalok, ez atnezi a kodot security best practice-t forceolva

Uj image release-nel a kovetkezo tortenik: atirom a verziot (pl 3.2.8) egy version file-ba es be-push-olom a gitlab repoba. A pipeline lebuildel egy image-et. Minden sajat module-nak van sajat tesztje. Lenyegeben egy example konyvtarban osszerakok egy egyszeru terraform configot ami hasznalja a modult es terratest-el letesztelem az uj image-el. Ezeken a modul teszteken felul van egy integracios test, ahol lenyegeben az osszes modult (ebbe bele tartoznak a 3rd party modulok is) hasznalva felepitek egy nagyon hasonlo infrat mint a tenyleges infrank terratest-el. A lenyeg itt, hogy a modulokat ugyanugy hasznalom mint a tenyleges infra-ban de csak egyszer (nem csinalok 30 s3 bucket-et csak 1-et). Ha minden teszt zold, akkor releaselem az uj container i
mage-et egy container registry-be egy uj version tag-gel, ami igy nez ki: ${terraformverzio}-${versiofiletartalma}  (eg. 1.1.2-5.4.3). Neha szukseges manualisan futtatni a terraform-ot debug eseten. Az admin ugyanugy hasznalhatja ezt az image-et mint a pipeline es igy biztosak lehetunk benne hogy mindenbol a jo verzio-t hasznalja...
Ha csak egy adott module-t fejlesztesz, akkor csak az adott module teszt-je fut le az utolso terraform image-el a push utan...
Ez a pipeline iszonyatosan megkonnyiti a day 2 operations-t. Ha megnezed, az AWS proviernek lenyegeben 4 naponta uj verzioja van. Irtam egy scriptet ami megnezi, hogy eppen milyen verziot hasznalunk es hogy van-e ujabb ezekbol (az osszes fent emlitett komponenst tamogatja). Ha van, akkor siman bumpolom a verziojat az adott komponensnek es ha felutnak a tesztek akkor nyugodtan valtok arra a masodik pipeline-ban amivel a real infra-t konfigolom. Eppen 3 hete bizonyitott, amikoris egy uj terraform minor verzio, break-elte az egyik modulomat mert egy olyan feature-t hasznaltam, ami valojaban bug volt ;)

Pipeline 2:
Ezzel a pipeline-al configoljuk a real infrat az elobbivel epitett container image-et hasznalva. Ebben a repo-ban tobb terraform directory van es a pipeline-ba beconfigolt sorrendben futtatom a terraform-ot rajta. Mint best practice, szet
szedtem a dolgokat kisebb terraform configokra igy csokkentve a blast radius-t. Ezen felul termesetesen a test es a prod kulon konyvtarakat kapott. Minden terraform konyvtarhoz prioritast rendelek. Minnel kevesebb a prioritas annal elobb fog az adott konytar lefutni a pipeline-ban. Ha azonos a prioritas akkor parhuzamosan is futhat. Egy pelda: a VPC config van a 30-as prioban, a subnet configok es a subnet sharing a 40-esben es egy adott project config (ami azt a subnet-et hasznalja amit elobb megcsinaltam es megshare-eltem az adott poject accountal) pedig az 50-esben.
A pipeline egy child pipeline-t csinal minden terraform konyvtarhoz. Ebben a child pipeline-ban a kovetkezo tortenik normal futas eseten:
* static analysys a terraform kodra: terraform fmt -check; terraform validate; tfsec; tflint... Ha barmelyiken elhasal a kod akkor megall a pipeline
* terraform plan-el megnezzuk hogy volt-e valtozas
* ha volt, akkor csinalunk egy manualis job-ot terraform apply-ra. Tehat, ez a job csak es kizarolag akkor fut, ha egy admin ranyom az approve button-ra (miutan persze atnezte a terraform plan job kimenetet :) )

A pipeline supportalja az osszes terraform plan mode-ot (destroy, refres-only, normal plan) egy config file-on keresztul adott terraform konyvtarra. Termeszetesen, ha valaki modosit valamit egy adott terraform konyvtarban akkor kizarolag arra a konyvtarra keszul egy child pipeline...
Van egy scheduled run minden reggel 9-kor, amivel drift detectiont csinalok. Minden terraform konyvtarra lefut egy terraform plan es ha van drift akkor csinal egy Jira ticket-et a plan outputtal. (mivel minden config kizarolag terraform-on keresztul tortenik ez fontos szamunkra)
A pipeline supportalja a merge request-ket. Ha egy developer kuld egy merge request-et akkor a pipeline lefuttatja a static analysys-t es a terraform plan-t. Ha mindek ok akkor egy admin merge-li az MR-t aminek hatasara egy uj, normalis pipleine lefut...

Iszonyat sok detail van meg, amit nem irtam le mert mar igyis nagyon hosszu :). Egy tipp: en is S3 + dynamodb remote state-el kezdtem. Minden AWS accountnak es minden terraform directory-nak sajat state-je volt sajat s3 bucketben. En IAM role-okat hasznalok... van egy terraform-plan iam role, ami lenyegeben read-only es van egy terraform apply role, ami admin minden AWS accountban. A terraform s3 remote state kod-ban van egy bug es sokszor rafut egy timeout-ra az STS service-el (ami ugye ahhoz kell hogy assume-olj egy role-t). Neha, amikor az STS service egy picit lassabb volt, hasznalhatatlan lett a pipeline, mert minden masodik terraform futas timeout-ra futott!!!! Van vagy 5 ticket a terraform github-on, ami ugyanezt irja le (egyik az enyem amiben azt kerem hogy csinaljanak mar par retry-t). Bezarjak azzal, hogy lassu a networkod!!!. AWS enterprise supportal probaltunk megoldast talalni a problemara sikertelenul... Ok azt mondjak hogy nem lehet egy API-tol elvarni ho
gy mindig gyors es elerheto legyen... Vegul a megoldas a gitlab remote state lett. Egy bizonyos verziotol felfele a gitlab tamogatja a terrafom remote state-et. Atom stabil. Ezen felul, a child pipeline egy terraform apply utan csinal egy terraform
save-et es at-scp-zem egy backup gepre a state-et. Lenyegeben minden valtozas utan van egy backup-om minden terraform directory state-jerol (arra az esetre ha legyalulna valaki a gitlabunkat :) ).

Ha van kerdes irj. Ha komolyabb segitseg kellene, akkor megemlitem, hogy szamlakepes vagyok, csak nagyon limitalt idom van a full time es a csalad mellett. Ja, es kulfoldi oraberem van, nem MO-ban lakom :)

P.S.: bocs a fele angol fele magyar szovegert. Nekem angol a munkanyelvem 10+ eve es egyszeruen azok a szavak ugranak be elsore