Norėčiau papasakoti apie naują CLI įrankį, kurį parašiau norėdamas išspręsti seną problemą.
problema
Terraform jau seniai buvo standartas Devops / Cloud / IT bendruomenėje. Daiktas yra labai patogus ir naudingas sprendžiant infrastruktūrą kaip kodą. Terraform yra daug malonumų, taip pat daugybė šakių, aštrių peilių ir grėblių.
Su Terraform labai patogu kurti naujus dalykus, o vėliau juos tvarkyti, keisti ar ištrinti. Ką turėtų daryti tie, kurie debesyje turi didžiulę infrastruktūrą, o ne sukurti per Terraform? Perrašyti ir sukurti visą debesį kažkaip brangu ir nesaugu.
Su šia problema susidūriau 2 darbuose, paprasčiausias pavyzdys, kai nori, kad Git būtų viskas terraformų failų pavidalu, bet turi 250+ kibirų ir labai daug rašyti juos terraforma ranka.
Yra nuo 2014 m. terrafome, kuris buvo uždarytas 2016 m. su viltimi, kad bus importas.
Apskritai viskas kaip nuotraukoje tik iš dešinės į kairę
Įspėjimai: Autorius pusę gyvenimo negyvena Rusijoje ir mažai rašo rusiškai. Saugokitės rašybos klaidų.
Sprendimai
1. Yra paruoštas ir senas AWS sprendimas . Kai pabandžiau per jį išmušti savo 250+ kibirų, supratau, kad ten viskas blogai. AWS jau seniai pristato daugybę naujų parinkčių, tačiau terraforming apie jas nežino ir apskritai tai yra rubinas . Po 2 vakaro išsiunčiau ten pridėti daugiau funkcijų ir suprato, kad toks sprendimas visai netinka.
Kaip veikia terraformavimas: jis paima duomenis iš AWS SDK ir generuoja tf bei tfstate per šabloną.
Čia yra 3 problemos:
1. Visada atsiliks atnaujinimai
2. tf failai kartais pasirodo sugadinti
3. tfstate renkama atskirai nuo tf ir ne visada susilieja
Apskritai sunku gauti rezultatą, kuriame `terraforminiame plane` rašoma, kad pakeitimų nėra
2. „Terraform import“ yra integruota terraform komanda. Kaip tai veikia?
Rašote tuščią TF failą su resurso pavadinimu ir tipu, tada paleidžiate „terraform import“ ir perduodate išteklių ID. terraform susisiekia su teikėju, gauna duomenis ir sukuria tfstate failą.
Čia yra 3 problemos:
1. Mes gauname tik tfstate failą, o tf tuščias, jį reikia parašyti rankiniu būdu arba konvertuoti iš tfstate
2. Vienu metu gali dirbti tik su vienu ištekliu ir nepalaiko visų išteklių. Ir ką turėčiau daryti su daugiau nei 250 kibirų?
3. Turite žinoti išteklių ID – tai yra, turite jį suvynioti į kodą, kuris gauna išteklių sąrašą
Apskritai rezultatas yra dalinis ir netinkamas
Mano sprendimas
reikalavimai:
1. Galimybė kurti tf ir tfstate failus ištekliams. Pavyzdžiui, atsisiųskite visus segmentus / saugos grupę / apkrovos balansavimo priemonę ir „terraform planas“ grąžino, kad nėra jokių pakeitimų.
2. Jums reikia 2 GCP + AWS debesų
3. Globalus sprendimas, kurį lengva kaskart atnaujinti ir negaištama laiko kiekvienam resursui 3 dienų darbui
4. Padarykite jį atviru šaltiniu – visi turi tą pačią problemą
„Go“ kalba man tai patinka, be to, joje yra biblioteka, skirta kurti HCL failus, kurie naudojami terraformoje, + daug terraforminio kodo, kuris gali būti naudingas.
Kelias
Pirmiausia pabandykite
Pradėjau nuo paprastos versijos. Susisiekite su debesiu per SDK, kad gautumėte reikiamus išteklius ir paverstumėte juos terraformos laukais. Bandymas iš karto nutrūko saugos grupėje, nes man nepatiko 1.5 dienos konvertuoti tik apsaugos grupę (o išteklių yra daug). Ilgai ir po to laukus galima keisti/papildyti
Antras bandymas
Remiantis aprašyta idėja . Tiesiog paimkite ir konvertuokite tfstate į tf. Visi duomenys yra, o laukai yra vienodi. Kaip gauti pilną tfstate daugeliui išteklių? Čia į pagalbą atėjo komanda „Terraform refresh“. terraform paima visus išteklius tfstate ir pagal ID ištraukia duomenis apie juos ir viską įrašo į tfstate. Tai yra, sukurkite tuščią tfstate su tik pavadinimais ir ID, paleiskite „terraform refresh“ ir tada gausime visas tfstates. Sveika!
Dabar atlikime rekursinę pornografiją, parašydami konverterį iš tfstate į tf. Tiems, kurie niekada neskaitė tfstate, tai yra JSON, bet ypatingas.
Čia yra svarbios jo dalies atributai
"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",
Yra:
1. id – eilutė
2. metaduomenys – 1 dydžio masyvas ir jame objektas su laukeliais, kurie aprašyti toliau
3. spec - 1 dydžio maiša ir raktas, reikšmė jame
Trumpai tariant, įdomus formatas, viskas gali būti kelių lygių gylio
"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",
Apskritai, jei kas nors nori programavimo problemos interviu, tiesiog paprašykite jų parašyti analizę šiai užduočiai :)
Po daugelio bandymų parašyti analizatorių be klaidų, dalį jo radau terraformo kode, o svarbiausią dalį. Ir viskas atrodė gerai
Trys bandymai
terraform teikėjai yra dvejetainiai failai, kuriuose yra kodas su visais ištekliais ir logika darbui su debesies API. Kiekvienas debesis turi savo teikėją, o pati terraforma juos iškviečia tik per savo RPC protokolą tarp dviejų procesų.
Dabar nusprendžiau susisiekti su terraformų teikėjais tiesiogiai per RPC skambučius. Tai pasirodė gražiai ir leido pakeisti terraformų teikėjus į naujesnius ir gauti naujų funkcijų nekeičiant kodo. Taip pat paaiškėja, kad ne visi tfstate laukai turėtų būti tf, bet kaip tai sužinoti? Tiesiog paklauskite apie tai savo paslaugų teikėjo. Tada prasidėjo kita pasikartojanti pornografija, jungianti reguliarius posakius, ieškant laukų tfstate viduje visuose lygmenyse.
Galų gale gavome naudingą CLI įrankį, kuris turi bendrą infrastruktūrą visiems terraformų teikėjams ir galite lengvai pridėti naują. Be to, norint pridėti išteklių, reikia nedaug kodo. Plius visokios gėrybės, pavyzdžiui, ryšiai tarp išteklių. Žinoma, buvo daug įvairių problemų, kurių visų neįmanoma aprašyti.
Pavadinau gyvūną Terrafomer.
Finalas
Naudodami Terrafomer iš dviejų debesų sugeneravome 500–700 tūkstančių tf + tfstate kodo eilučių. Galėjome paimti paveldėtus daiktus ir pradėti juos liesti tik per terraformą, kaip geriausioje infrastruktūroje kaip kodo idėjas. Tai tiesiog magija, kai paimate didžiulį debesį ir gaunate jį per komandą teraforminių darbuotojų failų pavidalu. Ir tada grep/replace/git ir pan.
Iššukavau ir sutvarkiau, gavau leidimą. Išleistas GitHub visiems ketvirtadienį (02.05.19/XNUMX/XNUMX).
Jau gauta 600 žvaigždučių, 2 atsisiuntimo užklausos dėl openstack ir kubernetes palaikymo pridėjimo. Geri atsiliepimai. Apskritai projektas naudingas žmonėms
Visiems norintiems patariu pradėti dirbti su Terraform ir nerašyti visko dėl to.
Mielai priimsiu prašymus, problemas, žvaigždutes.
Demo
Šaltinis: www.habr.com