Rád bych vám řekl o novém nástroji CLI, který jsem napsal k vyřešení starého problému.
problém
Terraform je již dlouho standardem v komunitě Devops/Cloud/IT. Věc je velmi pohodlná a užitečná pro řešení infrastruktury jako kódu. V Terraformu je mnoho potěšení, stejně jako mnoho vidliček, ostrých nožů a hrábí.
S Terraformem je velmi pohodlné vytvářet nové věci a následně je spravovat, měnit nebo mazat. Co by měli dělat ti, kteří mají obrovskou infrastrukturu v cloudu a nevytvořenou přes Terraform? Přepsání a opětovné vytvoření celého cloudu je nějak drahé a nebezpečné.
Narazil jsem na tento problém u 2 úloh, nejjednodušší příklad je, když chcete, aby vše bylo v Gitu ve formě souborů terraform, ale máte 250+ bucketů a je hodně psát je v terraform ručně.
K dispozici je od roku 2014 v terrafom, který byl v roce 2016 uzavřen s nadějí, že dojde k dovozu.
Obecně je vše jako na obrázku pouze zprava doleva
Upozornění: Autor nežije v Rusku polovinu života a málo píše rusky. Pozor na pravopisné chyby.
Řešení
1. Pro AWS existují již hotová a stará řešení . Když jsem se tím snažil protáhnout svých 250+ kbelíků, uvědomil jsem si, že je tam všechno špatně. AWS již dlouho zavádí spoustu nových možností, ale terraforming o nich neví a obecně je to rubín . Po 2 večer jsem odeslal přidat tam další funkce a uvědomili si, že takové řešení není vůbec vhodné.
Jak funguje terraforming: bere data z AWS SDK a generuje tf a tfstate prostřednictvím šablony.
Jsou zde 3 problémy:
1. Aktualizace budou vždy zpožďovat
2. tf soubory někdy vyjdou poškozené
3. tfstate se shromažďuje odděleně od tf a ne vždy konverguje
Obecně je obtížné získat výsledek, ve kterém „plán terraform“ říká, že neexistují žádné změny
2. `terraform import` je vestavěný příkaz v terraformu. Jak to funguje?
Zapíšete prázdný soubor TF s názvem a typem zdroje, poté spustíte `terraform import` a předáte ID prostředku. terraform kontaktuje poskytovatele, přijme data a vytvoří soubor tfstate.
Jsou zde 3 problémy:
1. Dostaneme pouze soubor tfstate a tf je prázdný, musíte ho napsat ručně nebo převést z tfstate
2. Může pracovat pouze s jedním zdrojem najednou a nepodporuje všechny zdroje. A co mám zase dělat s 250+ kbelíky?
3. Potřebujete znát ID zdrojů – to znamená, že je musíte zabalit do kódu, který získá seznam zdrojů
Obecně je výsledek částečný a špatně se měří
Mé rozhodnutí
Požadavky:
1. Schopnost vytvářet soubory tf a tfstate pro zdroje. Například si stáhněte všechny buckety/skupinu zabezpečení/nástroj pro vyrovnávání zatížení a ten „plán terraform“ vrátil, že nedošlo k žádným změnám
2. Potřebujete 2 cloudy GCP + AWS
3. Globální řešení, které se snadno aktualizuje pokaždé a neztrácí čas na každém zdroji po dobu 3 dnů práce
4. Make it Open Source – všichni mají stejný problém
Jazyk Go je důvod, proč ho miluji, a má knihovnu pro vytváření souborů HCL, která se používá v terraformu + spoustu kódu v terraformu, který může být užitečný
Cesta
První pokus
Začal jsem s jednoduchou verzí. Kontaktování cloudu přes SDK pro požadovaný zdroj a jeho převod na pole pro terraform. Pokus u skupiny zabezpečení okamžitě skončil, protože se mi nelíbilo 1.5 dne na převod pouze skupiny zabezpečení (a existuje spousta zdrojů). Po dlouhou dobu a poté lze pole měnit/přidávat
Druhý pokus
Na základě popsané myšlenky . Stačí vzít a převést tfstate na tf. Jsou tam všechna data a pole jsou stejná. Jak získat plný tfstate pro mnoho zdrojů? Zde přišel na pomoc příkaz `terraform refresh`. terraform vezme všechny zdroje v tfstate a podle ID z nich vytáhne data a vše zapíše do tfstate. To znamená, že vytvořte prázdný tfstate pouze se jmény a ID, spusťte `terraform refresh` a pak dostaneme plné tfstates. Hurá!
Nyní pojďme udělat rekurzivní pornografii psaní konvertoru pro tfstate na tf. Pro ty, kteří nikdy nečetli tfstate, je to JSON, ale speciální.
Zde jsou atributy jeho důležité části
"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",
Tady je:
1. id - řetězec
2. metadata - pole velikosti 1 a v něm objekt s poli, který je popsán níže
3. spec - hash velikosti 1 a klíč, hodnota v něm
Zkrátka zábavný formát, vše může mít několik úrovní
"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",
Obecně platí, že pokud někdo chce problém s programováním na pohovor, požádejte ho, aby pro tento úkol napsal analyzátor :)
Po mnoha pokusech napsat parser bez chyb jsem našel jeho část v kódu terraform a to nejdůležitější. A zdálo se, že vše funguje dobře
Pokus tři
poskytovatelé terraform jsou binární soubory, které obsahují kód se všemi prostředky a logikou pro práci s cloudovým API. Každý cloud má svého poskytovatele a sám terraform je pouze volá přes svůj RPC protokol mezi dvěma procesy.
Nyní jsem se rozhodl kontaktovat poskytovatele terraform přímo prostřednictvím volání RPC. Ukázalo se to krásně a umožnilo změnit poskytovatele terraform na novější a získat nové funkce bez změny kódu. Také se ukazuje, že ne všechna pole v tfstate by měla být v tf, ale jak to můžete zjistit? Stačí se na to zeptat svého poskytovatele. Pak začala další rekurzivní pornografie sestavování regulárních výrazů, hledání polí uvnitř tfstate na všech úrovních do hloubky.
Nakonec jsme získali užitečný nástroj CLI, který má společnou infrastrukturu pro všechny poskytovatele terraform a můžete snadno přidat novou. Také přidávání zdrojů vyžaduje málo kódu. Plus všemožné vychytávky jako propojení mezi zdroji. Samozřejmě bylo mnoho různých problémů, které nelze všechny popsat.
Zvíře jsem pojmenoval Terrafomer.
Konečný
Pomocí Terrafomeru jsme ze dvou cloudů vygenerovali 500-700 tisíc řádků kódu tf + tfstate. Byli jsme schopni vzít starší věci a začít se jich dotýkat pouze prostřednictvím terraformu, stejně jako v nejlepší infrastruktuře, jako jsou nápady na kódy. Je to prostě kouzlo, když vezmete obrovský cloud a obdržíte jej prostřednictvím týmu ve formě souborů terraform worker. A pak grep/replace/git a tak dále.
Vyčesal jsem to a dal do pořádku, dostal jsem povolení. Vydáno na GitHubu pro všechny ve čtvrtek (02.05.19/XNUMX/XNUMX).
Již obdržel 600 hvězdiček, 2 pull requesty na přidání podpory pro openstack a kubernetes. Dobrá zpětná vazba. Obecně je projekt pro lidi užitečný
Všem, kteří chtějí začít pracovat s Terraformem, radím a nepřepisovat na tohle všechno.
Rád vytáhnu požadavky, problémy, hvězdičky.
Demonstrace
Zdroj: www.habr.com