Kas yra „Terraform“ moduliai ir kaip jie veikia?

Keista, kad daugelis pradedančiųjų praleidžia „Terraform“ modulius paprastumo sumetimais arba taip mano.

Vėliau jie patiria šimtus eilučių konfigūracijos kodo.

Manau, kad jūs jau žinote kai kuriuos pagrindinius „Terraform“ pagrindus ir net bandėte juo naudotis anksčiau. Jei ne, prieš tęsdami skaitykite, peržiūrėkite šią „Terraform“ apžvalgą ir šią vaizdo įrašo pamoką.

Atkreipkite dėmesį: nenaudoju tikrų kodų pavyzdžių su tam tikru paslaugų teikėju, pvz., AWS ar „Google“, tik tam, kad būtų paprasčiau.

„Terraform“ moduliai

Jūs jau rašote modulius

Net jei nesukuriate modulio tyčia, jei naudojate „Terraform“, jau rašote modulį - vadinamąjį „ šakninį “ modulį.

Bet .tfkuris kataloge esantis „ Terraform“ konfigūracijos failas ( ), net tik vienas, sudaro modulį.

Ką veikia modulis?

„Terraform“ modulis leidžia sukurti loginę abstrakciją kai kurių išteklių rinkinio viršuje. Kitaip tariant, modulis leidžia grupuoti išteklius ir naudoti šią grupę vėliau, galbūt daug kartų.

Tarkime, kad turime virtualų serverį su kai kuriomis debesyje priglobtomis funkcijomis. Koks išteklių rinkinys gali apibūdinti tą serverį? Pavyzdžiui:

  • pati virtuali mašina, sukurta iš kažkokio vaizdo
  • pridedamą nurodyto dydžio blokinį įtaisą papildomai saugoti
  • statinis viešasis IP, susietas su serverio virtualaus tinklo sąsaja
  • ugniasienės taisyklių rinkinį, kurį reikia pridėti prie serverio
  • kiti dalykai, pvz., kitas blokavimo įrenginys, papildoma tinklo sąsaja ir pan

Tarkime, kad jums reikia daug kartų sukurti šį serverį su išteklių rinkiniu. Čia tikrai naudingi moduliai - ar nenorite kartoti to paties konfigūracijos kodo dar kartą?

Čia yra pavyzdys, iliustruojantis, kaip gali būti vadinamas „serverio“ modulis.

Skambinti moduliui “ reiškia naudoti jį konfigūracijos faile.

Čia sukuriame 5 „serverio“ egzempliorius, naudojant vieną konfigūracijų rinkinį (modulyje):

module "server" { count = 5 source = "./module_server" some_variable = some_value }

Modulio organizavimas: vaikas ir šaknis

Žinoma, tikriausiai norėtumėte sukurti daugiau nei vieną modulį. Štai keli įprasti pavyzdžiai:

  • tinklas kaip virtualus privatus debesis (VPC)
  • statinio turinio talpinimas (ty grupės)
  • apkrovos balansatorius ir su juo susiję ištekliai
  • registravimo konfigūracija
  • ar dar ką nors laikote atskiru loginiu infrastruktūros komponentu

Tarkime, mes turime du skirtingus modulius: „serverio“ ir „tinklo“ modulius. Modulis, vadinamas „tinklu“, yra tas, kur mes apibrėžiame ir sukonfigūruojame savo virtualųjį tinklą ir talpiname jame serverius:

module "server" { source = "./module_server" some_variable = some_value } module "network" { source = "./module_network" some_other_variable = some_other_value }

Turėdami keletą pasirinktinių modulių, galime juos vadinti „antriniais“ moduliais. Konfigūracijos failas, kuriame mes vadiname antrinius modulius, yra susijęs su šakniniu moduliu.

Vaiko modulį galima gauti iš kelių vietų:

  • vietiniai takai
  • oficialus „Terraform“ registras - jei esate susipažinęs su kitais registrais, tokiais kaip „Docker“ registras, jūs jau suprantate idėją
  • „Git“ saugykla (pasirinktinė arba „GitHub“ / „BitBucket“)
  • HTTP URL į .zip archyvą su moduliu

Bet kaip galite perduoti išsamią išteklių informaciją tarp modulių?

Mūsų pavyzdyje serveriai turėtų būti sukurti tinkle. Taigi, kaip mes galime pasakyti „serverio“ moduliui sukurti VM tinkle, kuris buvo sukurtas modulyje, vadinamame „tinklas“?

Čia atsiranda kapsuliavimas .

Modulio kapsuliavimas

„Terraform“ formavimas apima dvi pagrindines sąvokas: modulio taikymo sritį ir aiškų išteklių poveikį.

Modulio apimtis

Visi išteklių egzemplioriai, pavadinimai, taigi ir išteklių matomumas, yra izoliuoti modulio taikymo srityje. Pavyzdžiui, „A“ modulis pagal numatytuosius nustatymus nemato ir nežino apie „B“ modulio išteklius.

Išteklių matomumas, kartais vadinamas išteklių izoliacija, užtikrina, kad ištekliai modulio vardų srityje turės unikalius pavadinimus. Pvz., Su 5 mūsų „serverio“ modulio egzemplioriais:

module.server[0].resource_type.resource_name module.server[1].resource_type.resource_name module.server[2].resource_type.resource_name ...

Kita vertus, mes galime sukurti du to paties modulio egzempliorius su skirtingais pavadinimais:

module "server-alpha" { source = "./module_server" some_variable = some_value } module "server-beta" { source = "./module_server" some_variable = some_value }

Tokiu atveju išteklių pavadinimas arba adresas būtų toks:

module.server-alpha.resource_type.resource_name module.server-beta.resource_type.resource_name

Aiškus išteklių poveikis

Jei norite pasiekti tam tikrą kito modulio išteklių informaciją, turėsite tai aiškiai sukonfigūruoti.

Pagal numatytuosius nustatymus mūsų modulis „serveris“ nežino apie tinklą, kuris buvo sukurtas modulyje „tinklas“.

Taigi mes turime deklaruoti output„tinklo“ modulio vertę, kad galėtume eksportuoti jos išteklius arba išteklių atributus į kitus modulius.

Modulis „serveris“ turi paskelbti, kad variablejis bus naudojamas vėliau kaip įvestis:

This explicit declaration of the output is the way to expose some resource (or information about it) outside — to the scope of the 'root' module, hence to make it available for other modules.

Next, when we call the child module "server" in the root module, we should assign the output from the "network" module to the variable of the "server" module:

network_id = module.network.network_id

Here's what the final code for calling our child modules will look like:

module "server" { count = 5 source = "./module_server" some_variable = some_value network_id = module.network.network_id } module "network" { source = "./module_network" some_other_variable = some_other_value }

This example configuration would create 5 instances of the same server, with all the necessary resources, in the network we created with as a separate module.

Wrapping up

Now you should understand what modules are and what do they do.

If you're at the beginning of your Terraform journey, here are some suggestions for the next steps.

Kviečiu paimti šią trumpą „Terraform“ kūrėjų „HashiCorp“ pamoką apie modulius: „Organizuoti konfigūraciją“.

Taip pat yra puikus išsamus studijų vadovas, apimantis viską nuo pradedančiųjų iki pažengusių „Terraform“ koncepcijų: „Studijų vadovas -„ Terraform Associate “sertifikatas“.

Modulinė kodo struktūra daro jūsų konfigūraciją lankstesnę ir vis dėlto lengvai suprantamą kitiems. Pastarasis ypač naudingas komandai.

Jei jums patiko straipsnis, sekite mane „Twitter“ (@vasylenko), kur aš kartais dalinuosi savo išvadomis ir patarimais apie „Terraform“, AWS, „Ansible“ ir kitas su „DevOps“ susijusias technologijas.