Sziasztok,
"eltunt" egy VM, amelyrol google cloud alatt regebben teszteles celjabol letrehoztam terraformmal egy vm-et es hozza par compute_firewall forrast.
Most megprobaltam terraformmal eltavolitani, de a vm megmaradt - el es virul.
Hogy lehetne koser modon "eltavolitani" ugy, hogy a public ip-je megmaradjon (ez gcloud paranccsal volt letrehozva)?
Kesobb ujra mepgprobalnam letrehozni ugyanabbol a tf fajlbol...
Ardi
- 516 megtekintés
Hozzászólások
Most van tfstate fájl vagy nincs? Ha nincs akkor anélkül nem egyszerű a dolog. Több órás mókára kellene felkészülni, mert ilyenkor nem tudom mennyire működik a tfstate refresh. (Régebben semennyire)
Milyen lépések vannak a Terraform kódban? Biztos, hogy a VM-et is az telepítette?
Terraform plan - ha volt - mit írt ki, mit fog változtatni és hogyan? B opció ugyanez Terraform apply esetére is.
Hibaüzenet volt a terraform apply során?
Jó lenne látni, amit te látsz, de nem osztottál meg velünk eddig.
Ugyanazzal a terraform kóddal volt deployolva a public IP is?
- A hozzászóláshoz be kell jelentkezni
Ezert van az az alapszabaly, hogy a tfstate file-t mindig vmi perzisztens helyen taroljuk (tipikusan S3), nem VM-ekben szerteszet.
- A hozzászóláshoz be kell jelentkezni
S3-ban akkor tároljuk ha több helyről szeretnénk ugyanazt az infrát piszkálni. Akár pl. ci/cd pipeline-ból.
Ezen túl igyekszünk menteni is valahová.
zászló, zászló, szív
- A hozzászóláshoz be kell jelentkezni
"Kesobb ujra mepgprobalnam letrehozni ugyanabbol a tf fajlbol..."
Csak erre a reszre valaszolva remeljuk tanultal az esetbol :) , es a kovetkezo apply elott letrehozol egy S3 bucketet a TF state file-oknak, es beallitod a terraformodat hogy oda mentse oket local helyett.
Opcionalisan bekapcsolhatod a bucketben a verziozast, akkor lesz history-d is ami jol johet barmikor, valamint beallithatod policy-ben hogy csak az utolso 3 vagy 5 verziot tarolja hogy ne hizzon a vegtelensegig.
- A hozzászóláshoz be kell jelentkezni
Szerintem a kérdező tisztában van azzal, hogy a terraform működését tekintve hibázott. Egyébként is teszt cuccról van szó ahogy írja. Szerintem nem ebben kérte a tanácsot, tudja ezt valszeg ő is.
Ha jól érzem, akkor az a kérdés, hogy tudja a web portálon vagy api-n úgy kitörölni a VM gépet terraform nélkül, hogy megmaradjon az ip címe.
Én Googleban nem vagyok otthon, DO-ban speciel van külön menüpont a reserved ip címeknek, ahol az épp futóó dropletek ip címeit le lehet fixálni. Utána törölhető a gép is és az ip megmarad.
Google esetben nincs ilyen? Lehetséges lenne, hogy ha api-val hoztad lére, akkor a webes felületen nem tudod módosítani? Csak nem....
Szóval sztem nyálazzad végig a webes felületet és ott tedd helyre. Itt a lényeg most az ip cím megmentése, ha van rá mód. Itt azért kérdés, hogy a google hogy kezeli az ip címeket, milyen feltételekhez van kötve.
- A hozzászóláshoz be kell jelentkezni
Maga a terraform forráskód megvan? A cloud-ban a resource-ok (VM, public ip stb.) még megvannak?
Ha mindkettő igen, akkor terraform import parancsokkal újra lehet építeni a tfstate file-t. Mondjuk ez úgy nagyjából 10 resource-ig nem vészes, 100 resource-nál, amik mondjuk eléggé szerteágazó típusúak már inkább sírvafakadós.
- A hozzászóláshoz be kell jelentkezni
Igen, az import egész jó, épp nemrég mentette meg a seggemet más jellegű problémából fakadóan.
Ha van valami fájlformátum amibe legyűjthetők a resource-k típusonként, akkor az AI-val lehet olyan scriptet iratni, ami behúzgálja őket a terraformba. Kézzel valószínűleg előbb szecskáznám fel a teljes felhős infrát, gyújtanám fel és utána ugrálnék a hamvakon.
- A hozzászóláshoz be kell jelentkezni