Terraformer – Infra struktuur Koodiks

Tahan rääkida uuest CLI tööriistast, mille ma olen loonud ühe vana probleemi lahendamiseks.

Probleem

Terraform on juba pikka aega olnud standard DevOps/Cloud/IT kogukonnas. See on väga mugav ja kasulik tööriist infrastruktuuri kui koodi haldamiseks. Terraformil on palju eeliseid, aga ka palju harusid, teravaid noad ja hunnikuid, millega tuleb arvestada.
Terraformiga on uute asjade loomine ja nende haldamine, muutmine või kustutamine väga mugav. Aga mis teha neil, kellel on suur infrastruktuur pilves, mis ei ole loodud läbi Terraformi? Kõigi asjade ümberkirjutamine ja uuesti loomine on kallis ja ebatervislik.
Olen sellise probleemiga kokku puutunud kahel tööl. Lihtsaim näide on, kui soovid, et kõik oleks Gitis Terraformi failide kujul, aga sul on 250+ ämber ja nende käsitsi kirjutamine Terraformi jaoks on lihtsalt liiga palju.
On probleem Probleem on olnud Terraformis alates 2014. aastast, mille nad sulgesid 2016. aastal lootuses, et lisatakse impordi funktsioon.

Kokkuvõttes on kõik nagu pildil, ainult vasakult paremale.

Hoiatused: Autor on pool elu elanud väljaspool Venemaad ja kirjutab vene keeles harva. Ole ettevaatlikud õigekirja vigade suhtes.

Lahendused

1. On olemas vanad ja töötavad lahendused AWS jaoks. terraforming. Kui ma proovisin sellele ligi pääseda, et saada oma 250+ ämbrit, sain aru, et seal on kõik halvasti. AWS on juba pikka aega lisanud palju uusi valikuid, kuid terraforming ei tea neist ja seda on kirjutatud Ruby's. mallid näevad vaesed välja. Pärast kella 2 õhtul saatsin Pull request , et lisada sinna rohkem võimalusi ja sain aru, et selline lahendus ei sobi üldse.
Kuidas terraforming töötab? Ta võtab AWS SDK-st andmed ja genereerib tf ja tfstate mallide kaudu.
Siin on 3 probleemi:
1. Seal hakkab alati olema ajakohasuse mahajäämus.
2. tf failid tulevad vahel vigased.
3. tfstate koostatakse eraldi tf-st ja need ei sobi alati kokku.
Üldiselt on keeruline saada tulemust, kus `terraform plan` ütleb, et muudatusi ei ole.

2. `terraform import` — sisseehitatud käsk terraformis. Kuidas see töötab?
Sa kirjutad tühja TF faili, millel on ressursi nimi ja tüüp, seejärel käivitad `terraform import` ja edastad ressursi ID. Terraform pöördub pakkuja poole, saadab andmed ja loob tfstate faili.
Siin on 3 probleemi:
1. Saame ainult tfstate faili, samas tf jääb tühjaks, selle tuleb käsitsi kirjutada või konvertida tfstate-st.
2. Suudab töötada ainult ühe ressursiga iga kord ja ei toeta kõiki ressursse. Ja mida ma pean uuesti tegema 250+ ämbri puhul?
3. Peab teada ressursside ID-d — see tähendab, et tuleb kirjutada kood, mis hangib ressursside nimekirja.
Tegelikult on tulemus osaliselt lõplik ja ei skaala hästi.

Minu lahendus.

Nõuded:
1. Võimalus luua tf ja tfstate faile ressurssidest. Näiteks alla laadida kõik bucket'id / turverühmad / koormusbalansseerijad ning mis `terraform plan` tagastab, et muudatusi ei ole.
2. Vaja on kaht pilve: GCP + AWS.
3. Globaalne lahendus, mida on lihtne uuendada iga kord, ja ei pea kulutama iga ressursi puhul kolm päeva tööd.
4. Teha avatud lähtekoodiga — probleem, millega kõik silmitsi seisavad.

Go keel — seetõttu, et ma armastan seda, ja sellel on raamatukogu HCL failide loomiseks, mida kasutatakse terraformis + palju kasulikku koodi terraformis.

Tee.

Esimene katse.
Alustasin lihtsa variandiga. Pöördumine pilve SDK kaudu vajaliku ressursi poole ja selle konverteerimine terraformi väljadeks. Katse suri kohe turverühma tõttu, kuna mulle ei meeldinud 1,5 päeva konverteerida ainult turverühma (ressursse on palju). Liiga pikk ja siis võivad väljad muutuda / lisanduda.

Teine katse.
Põhineb kirjelduse ideel. siin. Lihtsalt võtke ja konverteerige tfstate tf-ks. Kõik andmed on seal olemas ja väljad samad. Kuidas saada täielik tfstate paljude ressursside jaoks?? Siin tuleb appi käsk `terraform refresh`. Terraform võtab kõik ressursid tfstate-st ja tõmbab nende andmed ID järgi ning kirjutab need kõik tfstate-sse. Nii et loome tühja tfstate ainult nimede ja ID-dega, käivitame `terraform refresh` ja saame täielikud tfstate-d. Hurraa!
Nüüd tegeleme rekursiivse pornotööstuse kirjutamisega konverteri jaoks tfstate-st tf-ks. Neile, kes pole kunagi tfstate-d lugenud, on see JSON, aga eriline.
Siin on selle oluline osa atribuudid

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

Siin on:
1. id — string
2. metadata — massiiv, mille suurus on 1 ja milles on objekt alljärgnevas kirjelduses
3. spec — hash, mille suurus on 1 ja milles on key,value
Kokkuvõttes on see tore formaat, kõik võib olla ka mitmel tasemel

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

Kes kokku, kes tahab intervjule programmeerimisülesannet, küsige lihtsalt parseri kirjutamist selle jaoks 🙂
Pärast pikki katseid kirjutada parserit ilma vigadeta leidsin osa sellest terraformi koodist, nimelt kõige olulisema osa. Ja kõik näis töötavat normaalselt.

Katse kolm
terraform provider – need on binaarsed failid, mis sisaldavad koodi kõigi ressursside ja loogika jaoks, et töötada pilve API-dega. Igal pilvel on oma provider ja terraform kutsub neid lihtsalt oma RPC protokolli kaudu kahe protsessi vahel.
Nüüd otsustasin pöörduda otse terraform providerite poole läbi RPC kutsete. See osutus ilusaks ja võimaldas vahetada terraform providerid värskemate vastu, saades uusi võimalusi, ilma koodi muutmata. Samuti selgus, et kõik väljad tfstate'is ei pruugi olla tf-is, aga kuidas seda teada saada? Ainult küsides providerilt selle kohta. Siis algas veel üks rekursiivne pornograafia regulaarsete väljendite koostamisega ja väljade otsimisega tfstate'i sügavamates kihtides.

Lõpuks saime kasuliku CLI tööriista, millel on ühine infrastruktuur kõigi terraformi pakkujate jaoks ja uut saab lihtsasti lisada. Samuti võtavad ressursside lisamine vähe koodi. Pluss erinevad lisafunktsioonid, näiteks ressursside vahelised ühendused. Muidugi oli palju erinevaid probleeme, mida kõiki ei saaks kirjeldada.
Nimeks sai Terrafomer.

Finaal

Kasutades Terrafomerit, genereerisime 500–700 tuhat rida tf + tfstate koodi kahe pilve vahel. Suutsime võtta pärandiga asju ja alustada nende muutmist ainult terraformi kaudu, nagu parimates infrastruktuuri koodi ideedes. Lihtsalt maagia, kui võtad tohutu pilve ja saad käsu abil töötavad terraformi failid. Edasi grep/replace/git ja nii edasi.

Kalkuleerisin ja viisin korda, sain load. Väljastasin reedel (02.05.19) GitHubis kõigile. github.com/GoogleCloudPlatform/terraformer
Sain juba 600 tähte, 2 pull requesti openstacki ja kubernetes'e toe lisamiseks. Häid ülevaateid. Üldiselt on projekt kasulik inimestele.
Soovitan kõigile, kes soovivad alustada Terraformiga töötamist, ilma et peaksid kõike selleks ümber kirjutama.
Olen rõõmus pull requestide, probleemide, ja tähtede üle.

Demos


Allikas: habr.com