Terraformer — Infrastruktur till Kod

Jag skulle vilja berätta om det nya CLI-verktyget som jag har skrivit för att lösa ett gammalt problem.

Problemet

Terraform har länge blivit standarden inom DevOps/Cloud/IT-gemenskapen. Det är ett mycket praktiskt och användbart verktyg för att arbeta med infrastruktur som kod. Det finns många fördelar med Terraform, men även många fallgropar.
Med Terraform är det mycket enkelt att skapa nya resurser och sedan hantera, ändra eller ta bort dem. Men vad ska man göra om man har en stor infrastruktur i molnet som inte har skapats med Terraform? Att skriva om och återskapa hela molnet känns både dyrt och osäkert.
Jag har stött på ett sådant problem på två jobb, det enklaste exemplet är när man vill ha allt i git som Terraform-filer, men man har 250+ buckets och det känns som att skriva dem för Terraform för hand är alldeles för mycket.
Det finns problem Redan sedan 2014 har det funnits ett Terraform-problem som stängdes 2016 i hopp om att det skulle bli en importfunktion.

Allt är i princip som på bilden, men från höger till vänster.

Varningar: Författaren har bott större delen av sitt liv utanför Ryssland och skriver sällan på ryska. Var försiktig med stavfel.

Lösningar

1. Det finns gamla och färdiga lösningar för AWS. terraforming. När jag försökte få mina 250+ buckets genom det insåg jag att allt inte fungerade som det skulle. AWS har länge lagt till många nya alternativ, men terraforming är inte medveten om dem och det är dessutom skrivet i Ruby. mallarna ser skrala ut. Efter två kvällar skickade jag Pull request för att lägga till fler möjligheter där och insåg att sådana lösningar inte fungerar överhuvudtaget.
Hur terraforming fungerar är att det hämtar data från AWS SDK och genererar tf och tfstate genom en mall.
Det finns tre problem:
1. Det kommer alltid att finnas en fördröjning i uppdateringarna.
2. tf-filerna blir ibland trasiga.
3. tfstate samlas separat från tf och stämmer inte alltid överens.
Det är generellt svårt att få ett resultat där `terraform plan` säger att det inte finns några ändringar.

2. `terraform import` — ett inbyggt kommando i Terraform. Hur fungerar det?
Du skriver en tom TF-fil med namnet och typen på resursen, sedan kör du `terraform import` och skickar ID:t för resursen. Terraform kontaktar leverantören, får data och skapar en tfstate-fil.
Det finns tre problem:
1. Vi får bara tfstate-filen, medan tf-filen är tom och måste skrivas för hand eller konverteras från tfstate.
2. Kan endast fungera med en resurs i taget och stöder inte alla resurser. Och vad ska jag göra med 250+ buckets?
3. Man måste veta ID:t för resurserna — det innebär att man måste slå in det i kod som hämtar listan över resurser.
Generellt är resultatet delvis och skalas inte bra.

Mina lösningar

Krav:
1. Möjlighet att skapa tf- och tfstate-filer utifrån resurser. Till exempel ladda ner alla buckets/security groups/load balancers och vad `terraform plan` returnerade som inga förändringar.
2. Två moln GCP + AWS
3. En global lösning som är lätt att uppdatera varje gång och som inte kräver tre dagar arbete per resurs.
4. Göra det open source — detta är ett problem som alla har.

Språk Go — därför älskar jag det, och det finns ett bibliotek för att skapa HCL-filer som används i terraform + mycket kod i terraform som kan vara användbar.

Väg

Första försöket
Jag började med en enkel variant. Anrop till molnet via SDK för att hämta den resurs som behövs och konvertera den till fält för terraform. Försöket dog direkt på security group eftersom jag inte gillade att det tog 1,5 dagar att konvertera bara security group (det finns många resurser). Långsamt och sedan kan fälten ändras/läggas till.

Andra försöket
Baserat på idén som beskrivs ). Ett typiskt exempel på användning:. Att helt enkelt ta och konvertera tfstate till tf. Alla data finns där och fälten är desamma. Hur får man en fullständig tfstate för många resurser?? Här kom kommandot `terraform refresh` till hjälp. Terraform hämtar alla resurser i tfstate och drar ut data för dem baserat på ID och skriver allt till tfstate. Så skapa en tom tfstate bara med namn och ID, köra `terraform refresh`, och då får vi fullständiga tfstate. Hurra!
Nu ska vi syssla med den rekursiva pornografin att skriva en konverterare för tfstate till tf. För dem som aldrig har läst tfstate, så är det JSON, men speciellt.
Här är dess viktiga del egenskaper

 "attributes": {
                            "id": "default/backend-logging-load-deployment",
                            "metadata.#": "1",
                            "metadata.0.annotations.%": "0",
                            "metadata.0.generate_name": "",
                            "metadata.0.generation": "24",
                            "metadata.0.labels.%": "1",
                            "metadata.0.labels.app": "backend-logging",
                            "metadata.0.name": "backend-logging-load-deployment",
                            "metadata.0.namespace": "default",
                            "metadata.0.resource_version": "109317427",
                            "metadata.0.self_link": "/apis/apps/v1/namespaces/default/deployments/backend-logging-load-deployment",
                            "metadata.0.uid": "300ecda1-4138-11e9-9d5d-42010a8400b5",
                            "spec.#": "1",
                            "spec.0.min_ready_seconds": "0",
                            "spec.0.paused": "false",
                            "spec.0.progress_deadline_seconds": "600",
                            "spec.0.replicas": "1",
                            "spec.0.revision_history_limit": "10",
                            "spec.0.selector.#": "1",

Här finns:
1. id — string
2. metadata — array av storlek 1 och den innehåller ett objekt med fälten som beskrivs nedan
3. spec — hash av storlek 1 och den innehåller key,value
En kort, underhållande format där allt kan gå djupare, även på flera nivåer.

                   "spec.#": "1",
                            "spec.0.min_ready_seconds": "0",
                            "spec.0.paused": "false",
                            "spec.0.progress_deadline_seconds": "600",
                            "spec.0.replicas": "1",
                            "spec.0.revision_history_limit": "10",
                            "spec.0.selector.#": "1",
                            "spec.0.selector.0.match_expressions.#": "0",
                            "spec.0.selector.0.match_labels.%": "1",
                            "spec.0.selector.0.match_labels.app": "backend-logging-load",
                            "spec.0.strategy.#": "0",
                            "spec.0.template.#": "1",
                            "spec.0.template.0.metadata.#": "1",
                            "spec.0.template.0.metadata.0.annotations.%": "0",
                            "spec.0.template.0.metadata.0.generate_name": "",
                            "spec.0.template.0.metadata.0.generation": "0",
                            "spec.0.template.0.metadata.0.labels.%": "1",
                            "spec.0.template.0.metadata.0.labels.app": "backend-logging-load",
                            "spec.0.template.0.metadata.0.name": "",
                            "spec.0.template.0.metadata.0.namespace": "",
                            "spec.0.template.0.metadata.0.resource_version": "",
                            "spec.0.template.0.metadata.0.self_link": "",
                            "spec.0.template.0.metadata.0.uid": "",
                            "spec.0.template.0.spec.#": "1",
                            "spec.0.template.0.spec.0.active_deadline_seconds": "0",
                            "spec.0.template.0.spec.0.container.#": "1",
                            "spec.0.template.0.spec.0.container.0.args.#": "3",

I allmänhet, den som vill ha en programmeringsuppgift för en intervju kan helt enkelt be om att få skriva en parser för detta 🙂
Efter många försök att skriva en parser utan buggar, hittade jag en del av den i terraform-koden, nämligen den mest kritiska delen. Och allt verkade fungera bra.

Försök tre.
Terraform provider är binärer som innehåller kod med alla resurser och logik för att arbeta med moln-API:er. Varje moln har sin egen provider och terraform anropar dem enbart genom sitt RPC-protokoll mellan två processer.
Nu har jag beslutat att kontakta terraform-providers direkt via RPC-anrop. Det blev vackert och gav möjlighet att byta terraform-providers mot nyare versioner och få nya funktioner utan att ändra koden. Det visade sig också att inte alla fält i tfstate måste vara i tf, men hur vet man detta? Man måste bara fråga provider om det. Sedan började en annan rekursiv process med att bygga regelbundna uttryck och söka efter fält inom tfstate på alla nivåer.

I slutändan blev det ett användbart CLI-verktyg med en gemensam infrastruktur för alla terraform-leverantörer, och det är enkelt att lägga till nya. Dessutom tar tillägg av resurser lite kod. Plus olika finesser som kopplingar mellan resurser. Det fanns förstås många olika problem som inte går att beskriva alla.
Jag döpte lilla djuret till Terrafomer.

Finalen

Med hjälp av Terrafomer genererade vi 500-700 tusen rader tf + tfstate-kod från två moln. Vi kunde ta tag i legacy-grejer och börja arbeta med dem genom terraform som i de bästa idéerna för infrastruktur som kod. Ren magi när man tar ett stort moln och får det som terraform-filer med ett kommando. Och sedan grep/replace/git och så vidare.

Jag räknade ut och organiserade, fick tillstånd. Släppte det på GitHub för alla på torsdag (02.05.19). github.com/GoogleCloudPlatform/terraformer
Har redan fått 600 stjärnor, 2 pull requests för att lägga till stöd för openstack och kubernetes. Bra recensioner. Generellt sett är projektet användbart för människor.
Jag rekommenderar det till alla som vill börja arbeta med Terraform och inte skriva om allt för detta.
Jag ser fram emot pull requests, problem, stjärnor.

Demo


Källa: habr.com