Terraform: változók átadása

Azt gondolom feltételezhetjük, hogy a key_vault -ból pont ugyanannyit akarsz, amennyit a resource_group-ból. Akkor valahogy így csinálnám:

module "key_vault" {
  for_each            =  var.customers
  source              =  "./modules/key_vault" 
  location            =  module.resource_group[each.key].resource_group_location
  resource_group_name =  module.resource_group[each.key].resource_group_name
  ...
}

Megjegyzések:

Tipikusan nem jó, ha a customers-ben a key-ek számok, nem tudom most csak a példa kedvéért van-e így, vagy a valóságban is. Jobb valami sztring. De ettől még akár működhet.

A depends_on legtöbb esetben nem kell, ha a key_vault -ban például a resource_group_name= mögött olyan kifejezés van, ami a dependeciát implicit amúgy is kialakítja.

Ha már modulokban szervezed a kódot, akkor célszerűbb és egyszerűbb lehet, ha nem két modult hivatkozol be annyiszor, ahány customered van, hanem csak egy modult hivatkozol be for_each használatával, és azon modulon belül van egymás mellett for_each nélkül egy darab azurerm_resource_group és egy darab azurerm_key_vault.

Ha ilyen tobb szintu fa strukturaban kell definialnod az env-eket akkor tenyleg nezd meg a terragrunt-ot, mert az pont ezt oldja meg. 

En peldaul egyetlen composite modult hasznalok minden ugyfel minden rendszerer, ami behuzza az osszes lehetseges modult. Az hogy egy ugyfel milyen rendszereben minek kell lennie egy tfvar vagy config.yaml donti el, ha definial valamit lesz, ha nem nem lesz. A terragrunt konyvtar meg ugy nez, ki, hogy projects/{ugyfel1, ugyfel2, ...ugyfelx}/{dev, uat, prod, whatever}. Ha valaki csinal egy konyvtarat beledob egy config.yaml-t a schemanak megfeleloen mar fel is epul a rendszere.

Ha kell privatban egyszer megmutatom :D

A mostani struktúra jó irány lehet. Sajnos az üzleti igényt, nem ismert így nem lehet megítélni a dolgot .

Inkább térjünk vissza a konkrét esetre. Ha jól értem a struktúrát,  akkor egy Subscription, egy környezet (dev,test,stg...).

Minden ügyfél kap egy-egy környezetet a Subscription-ökben. Mondjuk egy vagy több resource group formájában.

Tehát jön egy ügyfél akkor az én példámban egy playbook lefedi az összes környezetet, csak akkor ahány környezet,  annyi konfigurációs file kell. Igazából az eltérés csak a könyezet neve adná (dev,test,stg etc....). Ez nem akkora overload így külső szemmel.

Ami problémás lehet, az az ügyfelenkénti költség kimutatása. Ha még ez nem került elő, akkor érdemes észben tartani, mert előbb-utóbb fog érkezni a kérés. Emiatt jobb talán struktúrálisan a Subscription szinten kezelni az ügyfelet. Ezt lehet bontani subscription szinten mondjuk Prod és NonProd környezetekre ügyfelenként. Minden környezetet lehet egy resource group alá rendelni azonos struktúrában. Persze ez csak egy a sok lehetőség közül. Így ha valaki meg fogja kérdezni, hogy mennyi az ügyfél szerinti költség, akkor max. 2 subscription összegéből ez megmondható.

Az Atlantis is jó kiegészítője lehet a Terraform-nak.

A fent említett Terragunt is lehet jó megoldás.

Ha ügyfél szinten szeparálnélnék akkor nem három környezetet kellene definiálnom, hanem annyit ahány customer van (>20).

Minden esetben függetlenül melyik szinten, de szükség van ügyfél szintű szeparációra. A PROD környezetben semmiképp se engednék több ügyfelet egy helyre.

Illetve, itt bejöhet az a probléma, amit fentebb írtak.

A Terraform a listákat ilyen szempontból nem kezeli jól, mikor azzal több dolgot konfigurál.

Példa, hogy van 5 ügyfél.
 

customers:
- 1 (index 0)
- 2 (index 1)
- 3 (index 2)
- 4 (index 3)
- 5 (index 4)

A második úgy dönt, hogy nem kéri a szolgáltatást tovább. Az ügyfél törlésre kerül,  az indexelés megváltozik és a harmadik, lesz a második, a negyedik a harmadik, az ötödik meg a negyedik. Ezeket mind törli és újra létre fogja hozni az összeset, ami utána van.

Terraform ezt fogja látni utána:

customers:
- 1 (index 0)
- 3 (index 1)
- 4 (index 2)
- 5 (index 3)

és nem ezt:

customers:
- 1 (index 0)
- 3 (index 2)
- 4 (index 3)
- 5 (index 4)

Ezért, ami a törölt elem után lesz, ezért lesz újratelepítve. Tehát egy ügyfél távozása nem független a többi ügyfél deployment-jétől. Ezért nem szoktuk az ügyfeleket listaszerűen kezelni.

A fájlok szerinti válogatás pedig pont ezt oldja meg vagy lehet bonyolult tömbökkel játszani, ami addig jó még nem lesz túl nagy a projekt és nem lesz kezelhetetlen. Erre már most érdemes gondolni, odafigyelni.