Terraformer — Infrastructure To Code

Dëshiroj të flas për një mjet CLI të ri që kam shkruar për të zgjidhur një problem të vjetër.

Problemi

Terraform ka kohë që është bërë standard në komunitetet DevOps/Cloud/IT. Një gjë shumë e përshtatshme dhe e dobishme për të punuar me infrastructure as code. Ka shumë përmirësime në Terraform, por gjithashtu shumë pirgje, thika të mprehta dhe grykëra.
Me Terraform është shumë e lehtë të krijosh gjëra të reja dhe pastaj t'i menaxhosh, të ndryshosh ose të fshish. Por çfarë të bëjnë ata që kanë një infrastrukturë të madhe në cloud dhe nuk është krijuar përmes Terraform? Të ricopatosh dhe rikrijosh të gjithë cloud-in është disi e shtrenjtë dhe e pasigurt.
Kam përballur një problem të tillë në dy vende pune, një shembull shumë i thjeshtë është kur dëshiron që gjithçka të jetë në git në formën e skedave terraform, dhe ti ke 250+ kontejnerë, dhe t'i shkruash për Terraform me duar është shumë.
Ka issue që nga viti 2014 me terrafom që u mbyll në 2016 me shpresën që do të kishte import.

Në përgjithësi, gjithçka është si në figurë, vetëm nga e djathta në të majtë.

Kujdes: Autori ka jetuar gjysmën e jetës jashtë Rusisë dhe shkruan pak në rusisht. Kujdes për gabime në ortografi.

Zgjidhjet

1. Ekzistojnë zgjidhje të gatshme dhe të vjetra për AWS. terraforming. Kur përpiqesha përmes tij për të marrë 250+ kontejnerët e mi, kuptova se gjithçka ishte keq. AWS ka shtuar shumë opsione të reja dhe terraforming nuk i njeh ato dhe për më tepër ka ruby. templatet duket se janë të varfëra.. Pas dy orëve, dërgova Pull request për të shtuar më shumë mundësi aty dhe kuptova se një zgjidhje e tillë nuk përshtatet fare.
Si punon terraforming, ai merr të dhënat nga SDK AWS dhe gjeneron tf dhe tfstate përmes template.
Këtu ka 3 probleme:
1. Gjithmonë do të ketë vonesë në përditësime.
2. Skedarët tf ndonjëherë dalin të prishur.
3. tfstate ndërtohet ndarë nga tf dhe nuk përputhet gjithmonë.
Në përgjithësi, është e vështirë të marrësh një rezultat për të cilin `terraform plan` do të thotë që nuk ka ndryshime.

2. `terraform import` — një komandë e integruar në terraform. Si funksionon?
Shkruan një skedar bosh TF me emrin dhe pamjen e burimit, pastaj e ekzekuton `terraform import` dhe dërgon ID-në e burimit. terraform i drejtohet ofruesit, merr të dhëna dhe krijon skedarin tfstate.
Këtu ka 3 probleme:
1. Merr vetëm skedarin tfstate, ndërsa tf është bosh dhe duhet ta shkruash me duar ose ta konvertosh nga tfstate.
2. Funksionon vetëm me një burim në çdo herë dhe nuk mbështet të gjithë burimet. Dhe çfarë të bëj përsëri me 250+ kontejnerët.
3. Duhet të dish ID e burimeve — pra, duhet ta mbështjellësh në kod që merr listën e burimeve.
Në përgjithësi, rezultati është pjesor dhe nuk shkallëzohet mirë.

Zgjidhja ime

Kërkesat:
1. Mundësi për të krijuar skedarë tf dhe tfstate për resurset. Për shembull, shkarkoni të gjitha bucket-at / grupet e sigurisë / balancuesin e ngarkesës dhe që `terraform plan` të tregojë se nuk ka ndryshime
2. Duhet 2 resurse Cloud GCP + AWS
3. Zgjidhje globale që lehtë përditësohet çdo herë dhe nuk humb kohë për çdo resurset 3 ditë pune
4. Të bëhet Open source — problemi është të gjithë të tillë

Gjuha Go — prandaj unë e dua dhe ka një bibliotekë për krijimin e skedarëve HCL që përdoret në terraform + shumë kod në terraform që mund të jetë i dobishëm

Rruga

Përpjekja e parë
Fillova me një variant të thjeshtë. Thirrje në cloud përmes SDK për resurset e nevojshme dhe konvertimi i saj në fushat për terraform. Përpjekja vdiq menjëherë në grupin e sigurisë sepse nuk më pëlqeu të kaloj 1.5 ditë duke konvertuar vetëm grupin e sigurisë (pasi ka shumë resurse). E gjatë dhe pastaj fushat mund të ndryshojnë / shtohen

Përpjekja e dytë
E bazuar në idenë e përshkruar këtu. Thjesht të marrim dhe të konvertojmë tfstate në tf. Të gjitha të dhënat janë aty dhe fushat janë të njëjta. Si të merrni një tfstate të plotë për shumë resurse?? Këtu ndihmon komanda `terraform refresh`. terraform merr të gjitha resurset në tfstate dhe sipas ID-së nxjerr të dhënat dhe i shkruan të gjitha në tfstate. Pra, krijoni një tfstate bosh vetëm me emrat dhe ID-në, ekzekutoni `terraform refresh` dhe merrni tfstate të plota. Ura!
Tani do të merremi me shkrimin e konvertorëve për tfstate në tf. Për ata që kurrë nuk e kanë lexuar tfstate, kjo është JSON, por e veçantë.
Këtu është pjesa e tij e rëndësishme 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",

Këtu ka:
1. id — varg
2. metadata — array me madhësi 1 dhe në të një objekt me fushat e përshkruara më poshtë
3. spec — hash me madhësi 1 dhe në të çelëse, vlera
Shkurt, një format argëtues, gjithçka mund të jetë shumë nivelar po ashtu

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

Në përgjithësi, kushdo që dëshiron një problem për programim për intervista, thjesht kërkohet të shkruajë një parser për këtë çështje 🙂
Pas përpjekjesh të shumta për të shkruar një parser pa gabime, gjeta një pjesë të tij në kodin terraform, përkatësisht pjesën më të rëndësishme. Dhe gjithçka dukej se punonte mirë.

Përpjekja e tretë
Terraform provider është binarët që kanë kod me të gjitha burimet dhe logjikën për të punuar me API-të e cloudeve. Çdo cloud ka providerin e tij dhe terraform vetëm i thërret ata përmes protokollit të tij RPC midis dy proceseve.
Tani vendosa të drejtoj direkt tek terraform providers përmes thirrjeve RPC. Kështu doli bukur dhe ofroi mundësinë për të ndryshuar terraform providers në më të rinjtë dhe të merrja mundësi të reja pa ndryshuar kodin. Po ashtu, doli se jo të gjitha fushat në tfstate duhet të jenë në tf, dhe si ta di këtë? Vetëm duke i kërkuar provider-it për këtë. Pastaj filloi një tjetër pornografi rekurzive me krijimin e shprehjeve të rregullta për të gjetur fushat brenda tfstate në të gjitha nivelet e thellë.

Në fund doli një vegël CLI e dobishme, e cila ka një infrastrukturë të përbashkët për të gjithë terraform providers dhe është e lehtë për të shtuar të rinj. Po ashtu, shtimi i burimeve kërkon pak kod. Plus, disa gjëra shtesë si lidhjet midis burimeve. Sigurisht që pati shumë probleme të ndryshme që nuk mund të përshkruhen të gjitha.
E quajta krijesën Terrafomer.

Finale

Me përdorimin e Terrafomer, gjeneruam 500-700 mijë rreshta kodi tf + tfstate nga dy nube. Arritëm të merrnim gjëra legjasi dhe të fillonim t'i prekim ato vetëm përmes terraform si në idetë më të mira të infrastruktures si kod. Thjesht magji kur merr një nube të madhe dhe e merr atë në formën e skedave terraform me një komandë. Pastaj grep/replace/git e kështu me radhë.

E diçka dhe e sistemova, mora lejet. E shpalla në GitHub për të gjithë të enjten (02.05.19). github.com/GoogleCloudPlatform/terraformer
Kam marrë tashmë 600 yje, 2 pull requests për shtimin e mbështetjes për openstack dhe kubernetes. Komentet janë të mira. Përgjithësisht, projekti është i dobishëm për njerëzit.
Ju rekomandoj të gjithë ata që dëshirojnë të fillojnë të punojnë me Terraform dhe të mos e shkruajnë gjithçka për këtë.
Do të isha i lumtur për pull requests, issues, stars.

Demo


Burimi: habr.com