Terraformer — Infrastruktur til kode

Jeg vil gerne fortælle om et nyt CLI-værktøj, jeg har skrevet for at løse et gammelt problem.

Problemet

Terraform er længe blevet standarden i DevOps/Cloud/IT fællesskabet. Det er en meget praktisk og nyttig ting til at arbejde med infrastruktur som kode. Der er mange fordele ved Terraform, såvel som mange forhindringer, skarpe knive og fælder.
Med Terraform er det meget nemt at lave nye ting og derefter administrere, ændre eller slette dem. Men hvad skal man gøre, hvis man har en enorm infrastruktur i skyen, der ikke er oprettet via Terraform? At omskrive og genskabe hele skyen føles både dyrt og usikkert.
Jeg har været ude for dette problem på to arbejdspladser, den mest enkle situation er, når man ønsker, at alt skal være i Git som Terraform-filer, men man har 250+ buckets, og at skrive dem til Terraform manuelt virker bare som for meget.
Der er issue Siden 2014 har der været et værktøj som Terraform, der blev lukket i 2016, med håbet om, at importfunktionaliteten ville blive tilføjet.

Generelt ser alt ud som på billedet, men fra højre mod venstre.

Advarsel: Forfatteren har ikke boet i Rusland i halvdelen af sit liv og skriver sjældent på russisk. Vær forsigtig med stavefejl.

Løsninger

1. Der findes gamle og færdige løsninger til AWS. terraforming. Da jeg forsøgte at bruge det til at hente mine 250+ buckets, indså jeg, at der var mange problemer. AWS har længe tilføjet mange nye muligheder, som terraforming ikke kender til, og det er generelt baseret på Ruby. Templates ser kedelige ud.. Efter kl. 2 sendte jeg Pull request for at tilføje flere funktioner der, og jeg indså, at en sådan løsning ikke fungerer overhovedet.
Hvordan fungerer terraforming? Det henter data fra AWS SDK og genererer tf og tfstate gennem en template.
Her er tre problemer:
1. Der vil altid være forsinkelse i opdateringerne.
2. tf-filerne bliver nogle gange beskadigede.
3. tfstate genereres separat fra tf og stemmer ikke altid overens.
Det er generelt svært at få et resultat, hvor `terraform plan` siger, at der ikke er nogen ændringer.

2. `terraform import` — en indbygget kommando i Terraform. Hvordan fungerer det?
Du skriver en tom TF-fil med navnet og arten af ressourcen, derefter kører du `terraform import` og sender ressourcens ID. Terraform kommunikerer med udbyderen, får data og opretter en tfstate-fil.
Her er tre problemer:
1. Du får kun tfstate-filen, og tf er tom, så den skal skrives manuelt eller konverteres fra tfstate.
2. Det kan kun arbejde med én ressource ad gangen og understøtter ikke alle ressourcer. Hvad skal jeg så gøre med 250+ buckets?
3. Du skal kende ressourcens ID — det vil sige, at du skal indpakke det i kode, der henter ressourcelisten.
Generelt er resultatet delvist og skalerer ikke godt.

Min løsning.

Krav:
1. Mulighed for at oprette tf- og tfstate-filer baseret på ressourcer. For eksempel at downloade alle buckets/security group/load balancer og hvad `terraform plan` returnerede om, at der ikke er ændringer.
2. To skyer GCP + AWS
3. En global løsning, der nemt kan opdateres hver gang, uden at bruge tid på hver ressource i tre dage.
4. Gøre det Open source — alle har det samme problem.

Programmeringssproget Go — derfor elsker jeg det, og der findes et bibliotek til oprettelse af HCL-filer, som bruges i terraform + en masse kode i terraform, der kan være nyttig.

Sti

Første forsøg
Jeg startede med en simpel version. Adgang til skyen gennem SDK for at hente den nødvendige ressource og konvertere den til felter til terraform. Forsøget døde straks på security group, fordi jeg ikke kunne lide at bruge 1,5 dag på kun at konvertere security group (for der er mange ressourcer). Det er for lang tid, og derefter kan felterne ændre sig eller tilføjes.

Andet forsøg
Baseret på ideen beskrevet her. Bare tage og konvertere tfstate til tf. Alle data er der, og felterne er de samme. Hvordan får man fuld tfstate for mange ressourcer? Her kom kommandoen `terraform refresh` til hjælp. Terraform tager alle ressourcer i tfstate og henter data ved at bruge ID og skriver alt tilbage i tfstate. Sådan kan man oprette en tom tfstate kun med navne og ID, køre `terraform refresh`, og så får vi komplette tfstate. Hurra!
Lad os nu arbejde med den rekursive pornostof: skrive en converter for tfstate til tf. For dem, der aldrig har læst tfstate, er det JSON, men særligt.
Her er dens vigtige del attributes

 "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",

Her har vi:
1. id — string
2. metadata — array på størrelse 1, indeholdende et objekt med felterne beskrevet nedenfor
3. spec — hash på størrelse 1, indeholdende key,value
Kort sagt, en sjov format, alt kan også være dybt ind i flere niveauer.

                   "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",

Generelt, hvis nogen ønsker en programmeringsopgave til et interview, så spørg bare om at skrive en parser til dette 🙂
Efter mange forsøg på at skrive en parser uden fejl, fandt jeg en del af den i terraform-koden, nemlig den mest essentielle del. Og alt fungerede tilsyneladende fint.

Forsøg tre
Terraform provider er binære filer, der indeholder kode med alle ressourcer og logik til at arbejde med cloud-API'er. Hver cloud har sin egen provider, og terraform kalder dem bare gennem sin RPC-protokol mellem to processer.
Nu besluttede jeg at interagere direkte med terraform providers gennem RPC-kald. Det viste sig at være pænt og gav mig mulighed for at opgradere terraform providers til nyere versioner og få nye funktioner uden at ændre koden. Det viste sig også, at ikke alle felter i tfstate behøver at være i tf, men hvordan finder man det ud? Man må spørge provider om det. Så begyndte endnu en rekursiv proces med at samle regulære udtryk til at finde felter inde i tfstate på alle niveauer.

I slutningen endte jeg med et nyttigt CLI-værktøj, som har en fælles infrastruktur for alle terraform providers, og det er let at tilføje nye. Desuden kræver tilføjelsen af ressourcer lidt kode. Plus forskellige funktioner som forbindelser mellem ressourcer. Der var selvfølgelig mange forskellige problemer, som ikke kan beskrives alle sammen.
Jeg kaldte skabningen Terrafomer.

Finale

Vi har genereret 500–700.000 linjer tf + tfstate kode med Terraform i to forskellige skyder. Vi kunne tage legacy-ting og begynde at ændre dem ned gennem Terraform, som i bedste praksis for infrastruktur som kode. Det er ren magi, når man tager en stor sky og får den i form af Terraform-filer via en kommando. Derefter grep/replace/git og så videre.

Jeg har renset og systematiseret det, og fået tilladelser. Udgivet på GitHub til alle torsdag (02.05.19). github.com/GoogleCloudPlatform/terraformer
Jeg har allerede fået 600 stjerner, 2 pull requests for at tilføje support til OpenStack og Kubernetes. Gode anmeldelser. Generelt et nyttigt projekt for folk.
Jeg anbefaler det til alle, der ønsker at begynde at arbejde med Terraform og ikke vil omskrive alt for dette.
Jeg ser frem til pull requests, issues, stjerner.

Demo


Kilde: habr.com