Szeretnék mesélni az új CLI eszközről, amelyet egy régi probléma megoldására írtam.
probléma
A Terraform régóta szabvány a Devops/Cloud/IT közösségben. A dolog nagyon kényelmes és hasznos az infrastruktúra kódként való kezeléséhez. A Terraformban sok finomság található, valamint sok villa, éles kés és gereblye.
A Terraform segítségével nagyon kényelmes új dolgokat létrehozni, majd kezelni, módosítani vagy törölni. Mit tegyenek azok, akik hatalmas infrastruktúrával rendelkeznek a felhőben, és nem a Terraformon keresztül jöttek létre? A teljes felhő újraírása és újralétrehozása valahogy drága és nem biztonságos.
2 munkahelyen találkoztam ezzel a problémával, a legegyszerűbb példa az, amikor azt akarod, hogy minden a Gitben legyen terraform fájlok formájában, de van 250+ vödör, és nagyon sok kézzel írni terraformban.
Van 2014 óta a terrafomban, amelyet 2016-ban zártak be, abban a reményben, hogy lesz import.
Általában minden olyan, mint a képen csak jobbról balra
Figyelmeztetések: A szerző nem él fél életét Oroszországban, és keveset ír oroszul. Óvakodjon a helyesírási hibáktól.
Решения
1. Vannak kész és régi megoldások az AWS-hez . Amikor megpróbáltam átvinni rajta a 250+ vödrömet, rájöttem, hogy ott minden rossz. Az AWS már régóta sok új lehetőséget vezet be, de a terraforming nem tud róluk, és általában ez a rubin . Este 2 után küldtem hogy további funkciókat adjon hozzá, és rájött, hogy egy ilyen megoldás egyáltalán nem megfelelő.
A terraformálás működése: adatokat vesz az AWS SDK-ból, és egy sablonon keresztül generálja a tf és tfstate értékeket.
3 probléma van itt:
1. Mindig lesz késés a frissítésekben
2. A tf fájlok néha törve jönnek ki
3. A tfstate a tf-től elkülönítve kerül összegyűjtésre, és nem mindig konvergál
Általánosságban elmondható, hogy nehéz olyan eredményt elérni, amelyben a "terraform terv" szerint nincs változás
2. A `terraform import` egy beépített parancs a terraformban. Hogyan működik?
Ír egy üres TF-fájlt az erőforrás nevével és típusával, majd futtatja a `terraform import' parancsot, és átadja az erőforrás-azonosítót. A terraform felveszi a kapcsolatot a szolgáltatóval, megkapja az adatokat, és létrehoz egy tfstate fájlt.
3 probléma van itt:
1. Csak egy tfstate fájlt kapunk, és a tf üres, manuálisan kell írni vagy konvertálni a tfstate-ből
2. Egyszerre csak egy erőforrással tud dolgozni, és nem támogatja az összes erőforrást. És mit csináljak megint 250+ vödörrel?
3. Ismernie kell az erőforrások azonosítóját – vagyis olyan kódba kell csomagolnia, amely megkapja az erőforrások listáját
Általában az eredmény részleges, és nem skálázódik jól
A dontesem
követelmények:
1. Lehetőség tf és tfstate fájlok létrehozására az erőforrásokhoz. Például töltse le az összes tárolót/biztonsági csoportot/terheléselosztót, és azt a „terraform tervet” adja vissza, hogy nincsenek változások
2. 2 GCP + AWS felhő kell
3. Globális megoldás, amely minden alkalommal könnyen frissíthető, és nem vesztegeti az időt az egyes erőforrásokra 3 napos munkával
4. Legyen nyílt forráskódú – mindenkinek ugyanaz a problémája
A Go nyelv ezért szeretem, és van egy könyvtára a terraformban használt HCL-fájlok létrehozásához + sok terraform kód, ami hasznos lehet
Ösvény
Első kísérlet
Egy egyszerű változattal kezdtem. Lépjen kapcsolatba a felhővel az SDK-n keresztül a szükséges erőforrásért, és konvertálja azt terraform mezőkké. A kísérlet azonnal elhalt a biztonsági csoporton, mert nem tetszett a 1.5 nap, hogy csak a biztonsági csoportot konvertáljam (és rengeteg erőforrás van). Hosszú ideig, majd mezőket lehet módosítani/felvenni
Második próbálkozás
A leírt ötlet alapján . Csak vedd és alakítsd át a tfstate-et tf-re. Minden adat ott van, és a mezők ugyanazok. Hogyan lehet teljes tfstate-et szerezni sok erőforráshoz?? Itt jött a `terraform refresh` parancs segítségére. A terraform a tfstate-ben lévő összes erőforrást elveszi, és azonosítója alapján adatokat gyűjt róluk, és mindent a tfstate-be ír. Vagyis hozzunk létre egy üres tfstate-et csak nevekkel és azonosítókkal, futtassuk le a `terraform refresh` parancsot, majd teljes tfstate-okat kapunk. Hurrá!
Most végezzük el a rekurzív pornográfiát, és írjunk egy konvertálót a tfstate to tf számára. Azok számára, akik soha nem olvasták a tfstate-et, az JSON, de különleges.
Itt vannak a fontos részei tulajdonságai
"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",
Van:
1. id - string
2. metaadatok - egy 1-es méretű tömb és benne egy objektum mezőkkel, amelyet az alábbiakban ismertetünk
3. spec - 1-es méretű hash és kulcs, érték benne
Röviden, szórakoztató formátum, minden több szint mélységű lehet
"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",
Általában, ha valaki programozási problémát szeretne egy interjúhoz, csak kérje meg, hogy írjon értelmezőt ehhez a feladathoz :)
Sok próbálkozás után hibamentes értelmezőt írni, egy részét megtaláltam a terraform kódban, és a legfontosabbat. És úgy tűnt, minden jól működik
Három kísérlet
A terraform szolgáltatók olyan binárisok, amelyek a felhő API-val való együttműködéshez szükséges összes erőforrást és logikát tartalmazó kódot tartalmaznak. Minden felhőnek megvan a maga szolgáltatója, és maga a terraform csak az RPC protokollján keresztül hívja meg őket két folyamat között.
Most úgy döntöttem, hogy RPC-hívásokon keresztül közvetlenül felveszem a kapcsolatot a terraform szolgáltatókkal. Gyönyörűen sikerült, és lehetővé tette a terraform szolgáltatók újabbra cseréjét és az új funkciók elérését a kód megváltoztatása nélkül. Az is kiderült, hogy a tfstate-ban nem kell minden mezőnek tf-ben lennie, de honnan lehet ezt megtudni? Csak kérdezze meg erről a szolgáltatóját. Aztán elkezdődött egy újabb rekurzív pornográfia a reguláris kifejezések összeállításáról, a tfstate-en belüli mezők keresése minden szinten.
Végül kaptunk egy hasznos CLI eszközt, amely minden terraform szolgáltató számára közös infrastruktúrával rendelkezik, és könnyen hozzáadhat egy újat. Ezenkívül az erőforrások hozzáadása kevés kódot igényel. Plusz mindenféle finomság, mint például az erőforrások közötti kapcsolatok. Természetesen sok különböző probléma volt, amelyeket nem lehet leírni.
Az állatot Terrafomernek neveztem el.
finálé
A Terrafomer segítségével 500-700 ezer sornyi tf + tfstate kódot generáltunk két felhőből. Az örökölt dolgokat csak terraformon keresztül tudtuk átvenni, és csak a legjobb infrastruktúrában, kódötletként kezdhettük el hozzájuk nyúlni. Egyszerűen varázslatos, amikor veszünk egy hatalmas felhőt, és egy csapaton keresztül megkapjuk terraform worker-fájlok formájában. Aztán grep/replace/git és így tovább.
Kifésültem és rendbe tettem, megkaptam az engedélyt. Megjelent a GitHubon mindenki számára csütörtökön (02.05.19/XNUMX/XNUMX).
Már 600 csillagot kapott, 2 lehívási kérelem az openstack és a kubernetes támogatás hozzáadására. Jó visszajelzés. Általában véve a projekt hasznos az emberek számára
Azt tanácsolom mindenkinek, aki szeretne elkezdeni a Terraformmal dolgozni, és ne írjon át ehhez mindent.
Szívesen fogadok kéréseket, kérdéseket, csillagokat.
Demó
Forrás: will.com