Hookien poistokäytännöt

Yleisin valinta on hook-succeeded. Helm poistaa hook-resurssin heti, kun se on suoritettu onnistuneesti, joten nimiavaruus pysyy siistinä.

Kun käytätte hook-succeeded-käytäntöä, epäonnistunut hook jätetään tarkoituksella paikoilleen. Voitte lukea sen lokit ja selvittää, miksi migraatio epäonnistui, ennen kuin siivoatte resurssin itse. 🔍

Vastakkainen käytäntö on hook-failed. Helm poistaa hook-resurssin vain, kun se epäonnistuu. Tämä sopii hookeille, joita ette halua jättää rikkoutuneina paikoilleen.

Kolmas vaihtoehto on before-hook-creation. Helm poistaa edellisen instanssin juuri ennen uuden luomista ja välttää näin muuttumattomien nimien aiheuttamat ristiriidat.

Jos ette määritä mitään käytäntöä, Helm käyttää oletusarvoisesti käytäntöä before-hook-creation. Vanha hook poistetaan juuri ennen kuin seuraava ajo luo sen uudelleen.

Käytäntöjä voi yhdistää pilkuilla erotelluksi luetteloksi. Kun yhdistätte käytännöt before-hook-creation ja hook-succeeded, vanhat ajot poistetaan ja onnistuneen suorituksen jälkeen tehdään siivous.

Jobin määritystä ei voi muuttaa luomisen jälkeen. before-hook-creation kiertää tämän ongelman poistamalla vanhan Jobin ensin, joten jokainen päivitys saa uuden Jobin.

Valitkaa tavoitettanne vastaava käytäntö: siivotkaa onnistumisen jälkeen, säilyttäkää epäonnistumisten todisteet tai aloittakaa aina puhtaalta pöydältä. Kukin annotaatio määrittää vain sen, milloin resurssi poistetaan.

Nämä käytännöt koskevat vain resursseja, jotka Helm on luonut hookeina. Helm seuraa niitä ja poistaa ne puolestanne, joten vältätte manuaalisen kubectl deleten jokaisen julkaisun jälkeen.

hook-delete-policy määrittää, milloin Helm poistaa hookin: onnistumisen jälkeen, epäonnistumisen jälkeen tai ennen seuraavaa luomista. Oletusarvo on before-hook-creation. 🧹