Selitev na OpenTofu začnite pri listih: napačen vrstni red ogrozi stanje

Pri prehodu s Terraform na OpenTofu najprej popišite stanja in naredite varnostne kopije. Če konfiguracije prek terraform_remote_state berejo izhode drugih konfiguracij, preselite najprej odvisne liste, konfiguracije, ki jim zagotavljajo izhode, pa pozneje. Navodilo OpenTofu za povezana stanja pojasnjuje razlog: OpenTofu lahko bere stanje Terraform, obratna smer pa ni zanesljivo zagotovljena.

Pred vsakim prehodom primerjajte načrt obstoječe konfiguracije z načrtom OpenTofu pri istem stanju, delovnem prostoru in vhodnih podatkih. Nepričakovano ustvarjanje, zamenjava ali brisanje vira je razlog za ustavitev pred ukazom tofu apply. Samostojna konfiguracija ne potrebuje vrstnega reda med stanji, še vedno pa potrebuje kopijo stanja in pregled načrta.

Narišite graf stanj, ne le seznama projektov

Enota selitve je korenska konfiguracija s svojim stanjem. Poiščite uporabe terraform_remote_state in za vsako zabeležite, katero stanje bere, kje je shranjeno, kateri delovni prostor uporablja ter katere izhode potrebuje. Če si konfiguracije izhode posredujejo še drugače, zabeležite tudi te odvisnosti; pri načrtovanju prehoda je pomembno, kdo potrebuje rezultat čigavega stanja.

V pogojnem primeru aplikacija bere izhode podomrežij, podomrežja pa izhode omrežja. Zapis »aplikacija → podomrežja → omrežje« pomeni »bere stanje«. Aplikacija je list, ker nobena od preostalih konfiguracij ne bere njenega stanja, čeprav sama bere stanje podomrežij. Vrstni red selitve je aplikacija, nato podomrežja in nazadnje omrežje.

Pri več vejah lahko preselite vse liste, preden se pomaknete proti konfiguracijam, ki jim zagotavljajo izhode. Pred prehodom posamezne konfiguracije preverite, ali njeno stanje še bere katera konfiguracija, ki bo ostala na Terraform. Če ga bere, najprej preselite tega porabnika. Sicer bi Terraform lahko moral brati stanje, ki ga je že zapisal OpenTofu.

Zavarujte stanje in zabeležite izhodiščni načrt

Pred prvo inicializacijo z OpenTofu shranite kodo vseh prizadetih konfiguracij in kopije vseh njihovih stanj, tudi tistih, ki jih nameravate preseliti šele pozneje. Zabeležite različico Terraform, različice ponudnikov, zaledje in delovni prostor vsake konfiguracije. Pri lokalnem stanju kopirajte datoteki terraform.tfstate in terraform.tfstate_backup, če obstajata; pri oddaljenem uporabite postopek varnostnega kopiranja svojega zaledja in preverite možnost obnove.

Dodaten izvoz lahko naredite z ukazom terraform state pull > stanje-pred-selitvijo.tfstate v imeniku ustrezne konfiguracije. HashiCorpov opis ukaza state pull določa, da ukaz izpiše stanje na standardni izhod in lokalno kopijo pretvori v različico zapisa, združljivo z nameščenim Terraform. Zato izvoz dopolnjuje posnetek zaledja, ni pa nujno njegova povsem enaka kopija. Datoteko hranite zunaj repozitorija in ji omejite dostop, saj lahko stanje vsebuje občutljive vrednosti.

Za vsako konfiguracijo nato zaženite terraform plan z običajnimi spremenljivkami, poverilnicami in delovnim prostorom. Rezultat shranite kot izhodišče za primerjavo. Če načrt že kaže nepojasnjene spremembe, najprej ugotovite, ali izvirajo iz kode, stanja ali dejanske infrastrukture; sicer enake razlike po zamenjavi izvajalnika ne boste mogli zanesljivo pripisati prehodu.

Samostojno konfiguracijo preselite po pregledu načrta

Pri konfiguraciji, ki ni del grafa povezanih stanj, osnovni postopek OpenTofu predvideva varnostno kopijo, preverjanje namestitve z tofu --version, inicializacijo s tofu init in pregled s tofu plan. Inicializacija pripravi delovni imenik, ponudnike in zaledje; načrt pokaže predlagane posege, ne da bi jih uveljavil.

Pri nespremenjeni konfiguraciji pričakujte »No changes« oziroma enak, že pojasnjen rezultat kot pri terraform plan. Če se pojavi nova sprememba, primerjajte različice ponudnikov, nastavitve zaledja, delovni prostor in vhodne spremenljivke. Ne uporabite tofu apply kot poskusa odpravljanja nejasne razlike: ta ukaz lahko zapiše stanje tudi tedaj, ko infrastruktura ostane nespremenjena.

Ko je načrt razumljiv in odobren, izvedite tofu apply ter ponovno preglejte stanje in načrt. Šele nato je smiselna majhna, nekritična sprememba konfiguracije z ločenim pregledom načrta pred uveljavitvijo. Ta preizkus pokaže, ali lahko OpenTofu po začetnem prehodu upravlja vire, namesto da bi preverjali samo branje obstoječega stanja.

Povezane konfiguracije premikajte po ravneh

Pri povezanih stanjih ponovite isti postopek za posamezen list in šele nato za naslednjo raven grafa. Po prehodu preverite njegov načrt in stanje. Ko pozneje preselite konfiguracijo, ki listu zagotavlja izhode, v že preseljenem porabniku znova zaženite tofu plan. Tako preverite, ali še vedno bere pričakovane izhode in ali sprememba zapisovalca stanja povzroča predlagane posege.

V pogojnem primeru najprej preselite aplikacijo. Ko preselite podomrežja, aplikacija z OpenTofu bere njihovo stanje, zato njen ponovni načrt razkrije težavo v tej povezavi, preden se lotite omrežja. Omrežje pride na vrsto šele, ko so preseljeni vsi porabniki njegovih izhodov. V času mešanega delovanja je koristno ob vsaki konfiguraciji zapisati, kateri izvajalnik je zadnji pisal njeno stanje.

Pred posameznim zapisom izključite hkratne zagone avtomatizacije nad istim stanjem in preverite, da uporabljate predvideno zaledje ter delovni prostor. Vrstni red zmanjša tveganje nezdružljivega branja, sam po sebi pa ne razkrije napačnih spremenljivk, razlik v ponudnikih ali nepojasnjenih sprememb virov. Zato je pregled načrta potreben pri vsakem prehodu, ne samo pri prvem listu.

Ustavitev in vrnitev

Prehod ustavite ob napaki pri branju stanja, manjkajočem izhodu, nepričakovani spremembi vira ali razliki med načrtoma, ki je ne znate pojasniti. Naslednje ravni grafa ne preselite, dokler ne ugotovite, katera konfiguracija je zadnja zapisala prizadeto stanje. Pred odpravljanjem napake shranite še trenutno stanje, da ohranite tudi sled vmesnih zapisov.

Če OpenTofu stanja še ni zapisal, se vrnite na prejšnjo kodo in izvajalnik ter preverite terraform init in terraform plan. Če je stanje že zapisal, uporabite preverjeno kopijo po postopku svojega zaledja in ponovno preglejte načrt Terraform. Kadar je tofu apply spremenil tudi dejanske vire, najprej ugotovite, katere spremembe so bile izvedene: slepa obnova starega stanja bi lahko pustila zapis, ki se ne ujema več z infrastrukturo.

Preberite tudi:

• DMARC začnite z nadzorom: prehiter »reject« lahko ustavi legitimno pošto
• Vdrt Instagram: obnovitev začnite na znani napravi
• Selitev podkasta: spremenjen GUID lahko podvoji celoten arhiv