Haluaisin kertoa sinulle uudesta CLI-työkalusta, jonka kirjoitin ratkaistaksesi vanhan ongelman.
ongelma
Terraform on pitkään ollut standardi Devops/Cloud/IT-yhteisössä. Asia on erittäin kätevä ja hyödyllinen infrastruktuurin käsittelemiseksi koodina. Terraformissa on monia herkkuja sekä monia haarukoita, teräviä veitsiä ja haravoja.
Terraformilla on erittäin kätevää luoda uusia asioita ja sitten hallita, muuttaa tai poistaa niitä. Mitä pitäisi tehdä niiden, joilla on valtava pilviinfrastruktuuri, jota ei ole luotu Terraformin kautta? Koko pilven uudelleen kirjoittaminen ja luominen on jotenkin kallista ja vaarallista.
Törmäsin tähän ongelmaan kahdessa työssä, yksinkertaisin esimerkki on, kun haluat kaiken olevan Gitissä terraform-tiedostoina, mutta sinulla on yli 2 ämpäriä ja on paljon kirjoittaa ne terraformissa käsin.
On
Yleensä kaikki on kuten kuvassa vain oikealta vasemmalle
Varoitukset: Kirjoittaja ei asu Venäjällä puolta elämästään ja kirjoittaa vähän venäjäksi. Varo kirjoitusvirheitä.
Ratkaisut
1. AWS:lle on olemassa valmiita ja vanhoja ratkaisuja
Terraformointi toimii: se ottaa tiedot AWS SDK:sta ja luo tf- ja tfstate-tiedot mallin kautta.
Tässä on 3 ongelmaa:
1. Päivityksissä on aina viive
2. tf-tiedostot tulevat joskus rikki
3. tfstate kerätään erillään tf:stä, eikä se aina konvergoi
Yleensä on vaikea saada tulosta, jossa "terraform-suunnitelma" sanoo, että muutoksia ei ole
2. "Terraform import" on terraformin sisäänrakennettu komento. Kuinka se toimii?
Kirjoitat tyhjän TF-tiedoston, jossa on resurssin nimi ja tyyppi, suoritat sitten "terraform import" ja välität resurssin tunnuksen. terraform ottaa yhteyttä palveluntarjoajaan, vastaanottaa tiedot ja tekee tfstate-tiedoston.
Tässä on 3 ongelmaa:
1. Saamme vain tfstate-tiedoston, ja tf on tyhjä, sinun on kirjoitettava se manuaalisesti tai muutettava se tfstate-tiedostosta
2. Voi työskennellä vain yhden resurssin kanssa kerrallaan eikä tue kaikkia resursseja. Ja mitä minun pitäisi tehdä uudelleen yli 250 kauhalla?
3. Sinun on tiedettävä resurssien tunnus - eli sinun on käärittävä se koodiin, joka saa luettelon resursseista
Yleensä tulos on osittainen eikä skaalaudu hyvin
Minun päätökseni
vaatimukset:
1. Kyky luoda tf- ja tfstate-tiedostoja resursseja varten. Lataa esimerkiksi kaikki kauhat/turvaryhmä/kuormituksen tasapainottaja ja se "terraform plan" palautti, ettei muutoksia ole
2. Tarvitset 2 GCP + AWS-pilviä
3. Maailmanlaajuinen ratkaisu, joka on helppo päivittää joka kerta ja joka ei tuhlaa aikaa jokaiseen resurssiin 3 päivän työssä
4. Tee siitä avoin lähdekoodi - kaikilla on sama ongelma
Go-kieli on syy miksi rakastan sitä, ja siinä on kirjasto HCL-tiedostojen luomiseen, joita käytetään terraformissa + paljon terraformissa olevaa koodia, josta voi olla hyötyä
Polku
Ensimmäinen yritys
Aloitin yksinkertaisella versiolla. Yhteydenotto pilveen SDK:n kautta tarvittavan resurssin saamiseksi ja sen muuntaminen terraformin kentäksi. Yritys kuoli välittömästi suojausryhmässä, koska en pitänyt 1.5 päivästä muuntaa vain turvaryhmä (ja resursseja on paljon). Pitkään ja sitten kenttiä voidaan muuttaa/lisätä
Toinen yritys
Kuvatun idean perusteella
Tehdään nyt rekursiivinen pornografia, jossa kirjoitetaan tfstate to tf -muunnin. Niille, jotka eivät ole koskaan lukeneet tfstatea, se on JSON, mutta erityinen.
Tässä on sen tärkeät osa-attribuutit
"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",
On:
1. id - merkkijono
2. metatiedot - taulukko, jonka koko on 1 ja siinä objekti kenttiä, joka on kuvattu alla
3. spec - hash kokoa 1 ja avain, arvo siinä
Lyhyesti sanottuna hauska formaatti, kaikki voi olla useita tasoja syvä
"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",
Yleensä, jos joku haluaa ohjelmointiongelman haastatteluun, pyydä häntä kirjoittamaan jäsennys tähän tehtävään :)
Useiden yritysten jälkeen kirjoittaa jäsentäjä ilman bugeja, löysin osan siitä terraform-koodista ja tärkeimmän osan. Ja kaikki näytti toimivan hyvin
Yritä kolme
terraform-palveluntarjoajat ovat binaareja, jotka sisältävät koodin, jossa on kaikki resurssit ja logiikka pilvisovellusliittymän kanssa työskentelyyn. Jokaisella pilvellä on oma palveluntarjoajansa, ja terraform itse kutsuu niitä vain RPC-protokollansa kautta kahden prosessin välillä.
Nyt päätin ottaa yhteyttä terraformin tarjoajiin suoraan RPC-puheluiden kautta. Se onnistui kauniisti ja mahdollisti terraformin tarjoajien vaihtamisen uudempiin ja uusien ominaisuuksien saamisen ilman koodia vaihtamatta. Osoittautuu myös, että kaikkien tfstate-kenttien ei pitäisi olla tf:ssä, mutta miten voit selvittää? Kysy vain palveluntarjoajaltasi tästä. Sitten alkoi toinen rekursiivinen pornografia säännöllisten lausekkeiden kokoamisesta, jossa etsittiin kenttiä tfstaten sisältä kaikilla tasoilla.
Lopulta saimme hyödyllisen CLI-työkalun, jolla on yhteinen infrastruktuuri kaikille terraform-tarjoajille ja voit helposti lisätä uuden. Myös resurssien lisääminen vie vähän koodia. Lisäksi kaikenlaisia herkkuja, kuten resurssien välisiä yhteyksiä. Tietenkin oli monia erilaisia ongelmia, joita ei voida kuvailla kaikkia.
Nimesin eläimelle Terrafomer.
finaali
Terrafomeria käyttämällä loimme 500-700 tuhatta riviä tf + tfstate -koodia kahdesta pilvestä. Pystyimme ottamaan perintöasioita ja alkamaan koskea niihin vain terraformin kautta, kuten parhaassa infrastruktuurissa koodiideoina. Se on vain taikuutta, kun otat valtavan pilven ja vastaanotat sen tiimin kautta terraform worker -tiedostoina. Ja sitten grep/replace/git ja niin edelleen.
Kampasin sen ulos ja laitoin sen kuntoon, sain luvan. Julkaistu GitHubissa kaikille torstaina (02.05.19/XNUMX/XNUMX).
Saatu jo 600 tähteä, 2 vetopyyntöä openstack- ja kubernetes-tuen lisäämisestä. Hyvää palautetta. Yleisesti ottaen hanke on hyödyllinen ihmisille
Suosittelen kaikkia, jotka haluavat aloittaa työskentelyn Terraformin kanssa ja olemaan kirjoittamatta kaikkea uudelleen tätä varten.
Otan mielelläni vastaan pyyntöjä, kysymyksiä, tähtiä.
esittely
Lähde: will.com