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.