{"id":53120,"date":"2019-11-24T00:00:00","date_gmt":"2019-11-23T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/3-way-merge-v-werf-deploj-v-kubernetes-s-helm-na-steroidah"},"modified":"2020-02-18T14:00:59","modified_gmt":"2020-02-18T11:00:59","slug":"3-way-merge-v-werf-deploj-v-kubernetes-s-helm-na-steroidah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/3-way-merge-v-werf-deploj-v-kubernetes-s-helm-na-steroidah","title":{"rendered":"3-tee sulandumine werf-is: Kubernetesesse juurutamine Helmiga \"steroidide peal\"","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Toimus see, mida me (ja mitte ainult meie) oleme kaua oodanud: <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/\">werf<\/a><\/noindex>, meie avatud l\u00e4htekoodiga t\u00f6\u00f6riist rakenduste koostamiseks ja nende edastamiseks Kubernetesesse toetab n\u00fc\u00fcd muudatuste rakendamist 3-way-merge-patchide abil! Lisaks on n\u00fc\u00fcd v\u00f5imalik olemasolevate K8s-resursside v\u00f5tmine Helm-releasidesse ilma nende ressursside uuesti loomata.<\/p>\n<p><img decoding=\"async\" alt=\"3-tee sulandumine werf-is: Kubernetesesse juurutamine Helmiga &quot;steroidide peal&quot;\" src=\"\/wp-content\/uploads\/2019\/11\/e5be3544c201f7b2c97fba216a49506d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nL\u00fchidalt \u00f6eldes, seadistame <code>WERF_THREE_WAY_MERGE=enabled<\/code> \u2014 saame \u201enagu <code>kubectl apply<\/code>\u201c, mis on \u00fchilduv olemasolevate Helm 2 installatsioonidega ja isegi veidi rohkem.<\/p>\n<p>Aga alustame teooriast: mis on 3-way-merge-patchid, kuidas inimesed on j\u00f5udnud selle l\u00e4henemiseni ja miks need on olulised CI\/CD-protsessides, mis p\u00f5hinevad Kubernetesel? Seej\u00e4rel vaatame, mis on 3-way-merge werfis, milliseid re\u017eiime kasutatakse vaikimisi ja kuidas sellega hallata.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Mis on 3-way-merge-patch?<\/h2>\n<p>\nSeega alustame ressursside v\u00e4ljastamise \u00fclesandest, mis on kirjeldatud YAML-manifestides Kuberneteses.<\/p>\n<p>Kubernetes API pakub ressursside haldamiseks selliseid p\u00f5hitegevusi nagu create, patch, replace ja delete. Eeldatakse, et nende abil tuleb luua mugav j\u00e4rjepidev ressursside v\u00e4ljastamine klastrisse. Kuidas?<\/p>\n<h3>Implisiitilised kubectl k\u00e4sklused<\/h3>\n<p>\nEsimene l\u00e4henemine Kubernetesese objektide haldamiseks on implitseeritud kubectl k\u00e4skluste kasutamine nende objektide loomiseks, muutmiseks ja kustutamiseks. Lihtsalt \u00f6eldes:<\/p>\n<ul>\n<li> k\u00e4sklusega <code>kubectl run<\/code> saab k\u00e4ivitada Deploymenti v\u00f5i T\u00f6\u00f6:\n<pre><code class=\"bash\">kubectl run --generator=deployment\/apps.v1 DEPLOYMENT_NAME --image=IMAGE<\/code><\/pre>\n<\/li>\n<li> k\u00e4sklusega <code>kubectl scale<\/code> \u2014 muuta repliikide arvu:\n<pre><code class=\"bash\">kubectl scale --replicas=3 deployment\/mysql<\/code><\/pre>\n<\/li>\n<li>jne.<\/li>\n<\/ul>\n<p>\nSee l\u00e4henemine v\u00f5ib esialgu tunduda mugav. Kuid on probleeme: <\/p>\n<ol>\n<li> Seda on raske <b>automatiseerida<\/b>.<\/li>\n<li> Kuidas <b>peegeldada konfiguratsioonis<\/b> Git'is? Kuidas teha \u00fclevaadet muudatustest, mis toimuvad klastris?<\/li>\n<li> Kuidas tagada <b>konfiguratsiooni korduvus<\/b> taask\u00e4ivitamisel?<\/li>\n<li>\u2026<\/li>\n<\/ol>\n<p>\nOn selge, et selline l\u00e4henemine ei sobi h\u00e4sti koos rakenduse koodiga ja infrastruktuurina koodina (IaC; v\u00f5i isegi <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/458878\/\">GitOps<\/a><\/noindex> nagu t\u00e4nap\u00e4evane variant, mis saavutanud populaarsust Kubernetes-\u00f6kos\u00fcsteemis). Seet\u00f5ttu ei saanud need k\u00e4sklused kubectl-s edasist arengut.<\/p>\n<h3>Tegevused create, get, replace ja delete<\/h3>\n<p>\nEsialgse <b>loomisega<\/b> on k\u00f5ik lihtne: saadame manifesti kube API operatsiooni ja ressurss on loodud. YAML-esitus manifestist saab hoida Git'is ning loomise jaoks kasutada k\u00e4sku <code>create<\/code> kubectl create -f manifest.yaml <code>kustutamine<\/code>.<\/p>\n<p>A <b>on samuti lihtne: asendame sama<\/b> manifest.yaml <code>Git'ist k\u00e4sus<\/code> kubectl delete -f manifest.yaml <code>kubectl delete -f manifest.yaml<\/code>.<\/p>\n<p>Tehe <b><code>replace<\/code><\/b> v\u00f5imaldab t\u00e4ielikult asendada ressursi konfiguratsiooni uuega, ilma et oleks vaja ressursi uuesti luua. See t\u00e4hendab, et enne muudatuste tegemist ressursil on m\u00f5istlik k\u00fcsida praegust versiooni operatsiooniga <code>get<\/code>, muuta see ja uuendada operatsiooniga <code>replace<\/code>. Kube API serverisse on sisse ehitatud <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Optimistic_concurrency_control\">optimistlik lukustus<\/a><\/noindex> ja, kui objekti p\u00e4rast operatsiooni <code>get<\/code> olek muutub, siis operatsioon <code>replace<\/code> ei \u00f5nnestu.<\/p>\n<p>Kuna konfiguratsiooni tuleb salvestada Git'i ja uuendada kasutades replace'i, tuleb teha operatsioon <code>get<\/code>, sulandada konfigureerimine Git'ist saadud andmetega ning teostada <code>replace<\/code>. Kubectl v\u00f5imaldab vaid kasutada k\u00e4sku <code>kubectl replace -f manifest.yaml<\/code>, kus <code>Git'ist k\u00e4sus<\/code> \u2014 juba t\u00e4ielikult ette valmistatud (meie puhul \u2014 sulandatud) manifest, mille tuleb installida. Tulemuseks on see, et kasutajal tuleb implementeerida manifestide sulandumine, mis pole sugugi triviaalne\u2026<\/p>\n<p>Samuti on oluline m\u00e4rkida, et kuigi <code>Git'ist k\u00e4sus<\/code> see on salvestatud Git'i, ei saa me ette teada, kas objekt tuleb luua v\u00f5i uuendada \u2014 seda peab tegema kasutaja tarkvara.<\/p>\n<p>Kokkuv\u00f5tteks: <b>Kas saame ehitada pideva v\u00e4ljalaset<\/b> ainult create, replace ja delete abil, tagades infrastruktuuri konfiguratsiooni salvestamise Git'isse koos koodiga ning mugava CI\/CD?<\/p>\n<p>P\u00f5him\u00f5tteliselt saame\u2026 Selleks <b>on vaja teostada manifestide sulandumise operatsioon<\/b> ja mingi \u00fcmberprojekteerimine, mis:<\/p>\n<ul>\n<li> kontrollib objekti olemasolu klastris,<\/li>\n<li> teostab objekti esialgse loomise,<\/li>\n<li> uuendab v\u00f5i kustutab selle.<\/li>\n<\/ul>\n<p>\nUuendamisel tuleb arvesse v\u00f5tta, et <i>ressurss on v\u00f5inud muutuda<\/i> alates viimast <code>get<\/code> ja automaatselt k\u00e4ituda optimistliku lukustuse olukorras \u2014 teha uuendamise katseid.<\/p>\n<p>Kuid miks leiutada jalgratast, kui kube-apiserver pakub teistsugust viisi ressursside uuendamiseks: operatsiooni <code>patch<\/code>, mis vabastab kasutajat m\u00f5nedest eespool kirjeldatud probleemidest?<\/p>\n<h3>Patch<\/h3>\n<p>\nN\u00fc\u00fcd oleme j\u00f5udnud pat\u0161ide juurde.<\/p>\n<p>Pat\u0161id on peamine viis rakenduste muudatuste tegemiseks olemasolevatele objektidele Kuberneteses. Operatsioon <code>patch<\/code> t\u00f6\u00f6tleb nii, et:<\/p>\n<ul>\n<li> kube-apiserveri kasutajal on vaja saata pat\u0161 JSON-vormingus ja n\u00e4idata objekti,<\/li>\n<li> ja api server m\u00f5istab ise objekti praegust seisu ning viib selle n\u00f5utud olekusse.<\/li>\n<\/ul>\n<p>\nOptimistlik lukustus ei ole sel juhul vajalik. See operatsioon on dekreetiivsem v\u00f5rreldes replace'iga, kuigi alguses v\u00f5ib see tunduda vastupidine.<\/p>\n<p>Seega:<\/p>\n<ul>\n<li> kasutades operatsiooni <code>create<\/code> loome objekti Git\u2019i manifestist,<\/li>\n<li> kasutades <code>delete<\/code> \u2014 eemaldame, kui objekt ei ole enam vajalik,<\/li>\n<li> kasutades <code>patch<\/code> \u2014 muudame objekti, viies selle Git'is kirjeldatud olekusse.<\/li>\n<\/ul>\n<p>\nKuid selleks, et seda teha, on vajalik luua <i>\u00f5ige patch<\/i>!<\/p>\n<h3>Kuidas Helm 2 patchid t\u00f6\u00f6tavad: 2-way-merge<\/h3>\n<p>\nHelmi v\u00e4lja esmakordsel installimisel toimub <code>create<\/code> chart'i ressursside jaoks.<\/p>\n<p>Helmi v\u00e4lja v\u00e4rskendamisel iga ressursi jaoks:<\/p>\n<ul>\n<li> loob patchi eelneva chart'i ressursi versiooni ja praeguse chart'i versiooni vahel,<\/li>\n<li> rakendab selle patchi.<\/li>\n<\/ul>\n<p>\nSeda patchi nimetatakse <b>2-way-merge patch<\/b>, kuna selle loomisel osaleb 2 manifesti:<\/p>\n<ul>\n<li> eelneva v\u00e4lja ressursi manifest,<\/li>\n<li> praeguse ressursi manifest.<\/li>\n<\/ul>\n<p>\nKustutamise korral toimub operatsioon <code>delete<\/code> kube apiserveris, mis kutsub esile ressursid, mis olid kuulutatud eelnevas versioonis, kuid ei ole kuulutatud praeguses.<\/p>\n<p>2-way-merge patch l\u00e4henemine omab probleemi: see viib <b>ressursi tegeliku oleku ja Git'i manifesti des\u00fcnkroniseerimiseni.<\/b>.<\/p>\n<h3>Probleemi illustreerimine n\u00e4ite abil<\/h3>\n<p><\/p>\n<ul>\n<li> Git'is, chart'is on manifest, mille v\u00e4li <code>image<\/code> Deployment'il on v\u00e4\u00e4rtus <code>ubuntu:18.04<\/code>.<\/li>\n<li> Kasutaja on <code>kubectl edit<\/code> muutnud selle v\u00e4lja v\u00e4\u00e4rtust <code>ubuntu:19.04<\/code>.<\/li>\n<li> Helmi chart'i uuesti v\u00e4ljalaskmisel <i>ei genereeri patchi<\/i>, kuna v\u00e4li <code>image<\/code> eelneva versiooni vabanemises ja praeguses chart'is on identsed.<\/li>\n<li> P\u00e4rast uuesti v\u00e4ljalaset j\u00e4\u00e4b <code>image<\/code> , kuigi chart'is on kirjas <code>ubuntu:19.04<\/code>Oleme saanud des\u00fcnkroniseerimise ja kaotanud deklaratiivsuse. <code>ubuntu:18.04<\/code>.<\/li>\n<\/ul>\n<p>\nMis on s\u00fcnkroniseeritud ressurs?<\/p>\n<h3>t\u00e4ielik<\/h3>\n<p>\n\u00dcldiselt <i>vastavus t\u00f6\u00f6tava klastri ressursi manifesti ja Git'ist saadud manifesti vahel on v\u00f5imatu. Kuna tegelikus manifestis v\u00f5ivad olla teenuse annotatsioonid\/kleebised, t\u00e4iendavad konteinerid ja muud andmed, mida m\u00f5ni kontrollija d\u00fcnaamiliselt ressurssi lisab ja eemaldab. Me ei saa ja ei soovi neid andmeid Git'is hoida. Siiski tahame, et v\u00e4ljalaske korral v\u00e4\u00e4rtustavad need v\u00e4lja, mida me selgelt Git'is m\u00e4\u00e4ratlesime, vastavaid v\u00e4\u00e4rtusi.<\/i> Tekib selline \u00fcldine<\/p>\n<p>s\u00fcnkroniseeritud ressursi reegel <b>: ressursi v\u00e4ljalaskmisel v\u00f5ib muutuda v\u00f5i kustuda ainult need v\u00e4ljad, mis on selgelt m\u00e4\u00e4ratletud Git'i manifestis (v\u00f5i olid m\u00e4\u00e4ratletud eelnevas versioonis ja n\u00fc\u00fcd eemaldatud).<\/b>3-way-merge patch<\/p>\n<h3>: genereerib patchi viimase rakendatud manifesti versiooni ja sihitud manifesti versiooni vahel, arvestades praegust t\u00f6\u00f6tava klastri manifesti versiooni. L\u00f5pptulemus peab vastama s\u00fcnkroniseeritud ressursi reeglile:<\/h3>\n<p>\nP\u00f5him\u00f5te <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Merge_(version_control)#Three-way_merge\">: genereerib patchi viimase rakendatud manifesti versiooni ja sihitud manifesti versiooni vahel, arvestades praegust t\u00f6\u00f6tava klastri manifesti versiooni. L\u00f5pptulemus peab vastama s\u00fcnkroniseeritud ressursi reeglile:<\/a><\/noindex>uusid v\u00e4lju, mis on lisatud sihitud versioonile, lisatakse patchi abil;<\/p>\n<ul>\n<li> Uued v\u00e4ljaanded, mis on lisatud sihtversiooni, lisatakse patch'i kaudu;<\/li>\n<li> Eelmised v\u00e4ljaandmed, mis ei ole olemas sihtversioonis, nullitakse viimase rakendatud versiooni abil patchi kaudu;<\/li>\n<li> Praeguseid objekti v\u00e4lju, mis erinevad sihtversioonist, uuendatakse patchi kaudu.<\/li>\n<\/ul>\n<p>\nJust selle p\u00f5him\u00f5tte kohaselt genereeritakse pat\u0161e. <code>kubectl apply<\/code>:<\/p>\n<ul>\n<li> Viimane rakendatud versioon s\u00e4ilitatakse objekti enda annotatsioonis, <\/li>\n<li> sihtversioon v\u00f5etakse m\u00e4\u00e4ratud YAML-failist,<\/li>\n<li> praegune versioon on t\u00f6\u00f6tavast klastrist.<\/li>\n<\/ul>\n<p>\nN\u00fc\u00fcd, kui oleme teooria selgeks teinud, on aeg r\u00e4\u00e4kida, mida me werf-is tegime.<\/p>\n<h2>Muudatuste rakendamine werf-is<\/h2>\n<p>\nVarem kasutas werf, nagu ka Helm 2, 2-way-merge pat\u0161e.<\/p>\n<h3>Repair patch<\/h3>\n<p>\nEt liikuda uue pat\u0161i t\u00fc\u00fcbi \u2014 3-way-merge \u2014 juurde, on esimene samm sisse viia nn <b>repair-patchid.<\/b>.<\/p>\n<p>Deployimise ajal kasutatakse standardset 2-way-merge pat\u0161i, kuid werf genereerib lisaks sellise pat\u0161i, mis s\u00fcnkroniseerib ressursi reaalse seisundi sellega, mis on kirjutatud Git-i (see pat\u0161 luuakse \u00fclesande s\u00fcnkroniseeritud ressursi reeglite j\u00e4rgi, nagu eespool kirjeldatud).<\/p>\n<p>S\u00fcnkroonimise probleemi korral saab kasutaja deployimise l\u00f5puks WARNING-i koos vastava s\u00f5numi ja pat\u0161iga, mida tuleb rakendada, et tuua ressurss s\u00fcnkroniseeritud seisu. Samuti salvestatakse see pat\u0161 spetsiaalsesse annotatsiooni <code>werf.io\/repair-patch<\/code>. Eeldatakse, et kasutaja rakendab selle pat\u0161i k\u00e4sitsi: <b>kasutaja<\/b> rakendab selle pat\u0161i: werf ei rakenda seda p\u00f5him\u00f5tteliselt.<\/p>\n<p>Repair-patchide genereerimine on ajutine meetod, mis v\u00f5imaldab proovida 3-way-merge p\u00f5him\u00f5ttel pat\u0161ide loomist, kuid neid pat\u0161e ei rakendata automaatselt. Praegu on see t\u00f6\u00f6re\u017eiim vaikimisi sisse l\u00fclitatud.<\/p>\n<h3>3-way-merge patch ainult uutele v\u00e4ljaannetele<\/h3>\n<p>\nAlates 1. detsembrist 2019 hakkavad werf-i beetaversioonid ja alpha-versioonid <b>vaikimisi<\/b> k\u00e4sitlema t\u00e4ielikult 3-way-merge pat\u0161e muudatuste rakendamiseks ainult uute Helm-i v\u00e4ljaannetega, mis v\u00e4ljastatakse l\u00e4bi werf. Juba olemasolevad v\u00e4ljaanded j\u00e4tkavad 2-way-merge + repair-pat\u0161ide l\u00e4henemise kasutamist.<\/p>\n<p>Seda t\u00f6\u00f6re\u017eiimi saab selges\u00f5naliselt lubada seadistusega <code>WERF_THREE_WAY_MERGE_MODE=onlyNewReleases<\/code> juba praegu.<\/p>\n<p><i><b>M\u00e4rkus<\/b>: see funktsioon ilmus werf-is mitme v\u00e4ljaande jooksul: alpha-kanalis oli see valmis versiooniga <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/releases\/tag\/v1.0.5-alpha.19\">v1.0.5-alpha.19<\/a><\/noindex>, ja beetakanalis \u2014 versiooniga <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/releases\/tag\/v1.0.4-beta.20\">v1.0.4-beta.20<\/a><\/noindex>.<\/i><\/p>\n<h3>3-way-merge patch k\u00f5ikide v\u00e4ljaannete jaoks<\/h3>\n<p>\nAlates 15. detsembrist 2019 hakkavad werf'i beetaversioonid ja alphasid vaikimisi kasutama t\u00e4ielikke 3-way-merge-patch'e muudatuste rakendamiseks k\u00f5igis v\u00e4ljaannetes.<\/p>\n<p>Seda t\u00f6\u00f6re\u017eiimi saab selges\u00f5naliselt lubada seadistusega <code>WERF_THREE_WAY_MERGE_MODE=enabled<\/code> juba praegu.<\/p>\n<h3>Kuidas on lood ressursside automaatse skaleerimisega?<\/h3>\n<p>\nKuberneteses on kaks t\u00fc\u00fcpi automaatset skaleerimist: HPA (horisontaalne) ja VPA (vertikaalne).<\/p>\n<p>Horisontaalne skaleerimine valib automaatselt koopiate arvu, vertikaalne \u2013 ressursside arvu. Nii koopiate arv kui ka ressursside n\u00f5udmised on m\u00e4\u00e4ratud ressursi manifestis (vt. <code>spec.replicas<\/code> v\u00f5i <code>spec.containers[].resources.limits.cpu<\/code>, <code>spec.containers[].resources.limits.memory<\/code> ja <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/configuration\/manage-compute-resources-container\/#resource-requests-and-limits-of-pod-and-container\">muud<\/a><\/noindex>).<\/p>\n<p>Probleem: kui kasutaja konfigureerib ressursi chart'is nii, et seal on m\u00e4\u00e4ratud kindlad ressursi v\u00f5i koopiate v\u00e4\u00e4rtused ja sellele ressursile on lubatud automaatne skaleerimine, siis iga werf'i juurutamisega taastatakse need v\u00e4\u00e4rtused selliseks, nagu need on m\u00e4\u00e4ratud chart'i manifestis.<\/p>\n<p>Probleemi lahendamiseks on kaks v\u00f5imalust. Esiteks on parem loobuda automaatsete v\u00e4\u00e4rtuste selges\u00f5nalisest m\u00e4\u00e4ratlemisest chart'i manifestis. Kui see valik mingil p\u00f5hjusel ei sobi (n\u00e4iteks seet\u00f5ttu, et chart'is on mugav seada algseid ressursi piiranguid ja koopiate arvu), pakub werf j\u00e4rgmisi annotatsioone:<\/p>\n<ul>\n<li> <code>werf.io\/set-replicas-only-on-creation=true<\/code><\/li>\n<li> <code>werf.io\/set-resources-only-on-creation=true<\/code><\/li>\n<\/ul>\n<p>\nKui selline annotatsioon on olemas, ei l\u00e4htestata werf vastavaid v\u00e4\u00e4rtusi iga juurutamise ajal, vaid seadistatakse need ainult ressursi esmakordsel loomisel.<\/p>\n<p>Lisateabe jaoks vt projekti dokumentatsioonist <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/resources_update_methods_and_adoption.html#deal-with-hpa\">HPA<\/a><\/noindex> ja <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/resources_update_methods_and_adoption.html#deal-with-vpa\">VPA<\/a><\/noindex>.<\/p>\n<h3>Keelata 3-way-merge patch'i kasutamine<\/h3>\n<p>\nKasutaja saab praegu keelata uusimate patch'ide kasutamise werf'is keskkonnamuutuja abil <code>WERF_THREE_WAY_MERGE_MODE=disabled<\/code>. Kuid alates <b>1. m\u00e4rtsist 2020 kaotab see keeld kehtivuse<\/b> ja v\u00f5imalik on kasutada ainult 3-way-merge-patch'e.<\/p>\n<h2>Ressursside vastuv\u00f5tmine werf'is<\/h2>\n<p>\n3-way-merge-patch'ide muutmisviisi omaksv\u00f5tmine v\u00f5imaldas meil kohe rakendada sellist funktsiooni nagu klastris olemasolevate ressursside vastuv\u00f5tmine Helm'i v\u00e4ljaande.<\/p>\n<p>Helm 2-l on probleem: ei saa lisada chart'i manifestidesse ressurssi, mis juba eksisteerib klastris, ilma seda ressurssi t\u00e4iesti uuesti loomata (vt. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/issues\/6031#issuecomment-531579500\">#6031<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/issues\/3275\">#3275<\/a><\/noindex>). Oleme \u00f5petanud werf'i aktsepteerima olemasolevaid ressursse v\u00e4ljaandes. Selleks tuleb seadistada klastris t\u00f6\u00f6tava ressursi praegusele versioonile annotatsioon (n\u00e4iteks koos <code>kubectl edit<\/code>):<\/p>\n<pre><code class=\"plaintext\">\"werf.io\/allow-adoption-by-release\": RELEASE_NAME<\/code><\/pre>\n<p>\nN\u00fc\u00fcd tuleb ressurss kirjeldada chart'is ja j\u00e4rgmisel korral, kui werf'iga versioon juurutatakse, v\u00f5etakse olemasolev ressurss sellesse versiooni vastu ning j\u00e4\u00e4b selle haldusse. Veelgi enam, ressurssi versiooni vastuv\u00f5tmise protsessis viib werf t\u00f6\u00f6klastri praeguse oleku chart'is kirjeldatud olekusse, kasutades samu 3-way-merge-patch'e ja s\u00fcnkroniseeritud ressursi reeglit.<\/p>\n<p><i><b>M\u00e4rkus<\/b>: seadistus <code>WERF_THREE_WAY_MERGE_MODE<\/code> ei m\u00f5juta ressursside vastuv\u00f5ttu \u2014 vastuv\u00f5tu korral kasutatakse alati 3-way-merge-patch'i.<\/i><\/p>\n<p>Detailid \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/resources_update_methods_and_adoption.html#resources-adoption\">dokumentatsioon<\/a><\/noindex>.<\/p>\n<h2>J\u00e4reldused ja tulevikuplaanid<\/h2>\n<p>\nLoodan, et p\u00e4rast seda artiklit on selgem, mis on 3-way-merge-patch'id ja miks nendeni j\u00f5uti. Praktikas werf projekti arendamise m\u00f5ttes on nende rakendamine veel \u00fcks samm Helm'i sarnase juurutuse t\u00e4iustamise teel. N\u00fc\u00fcd saab unustada konfigureerimise s\u00fcnkroonimise probleemid, mis sageli tekkisid Helm 2 kasutamise ajal. Samuti on lisatud uus kasulik funktsioon juba saadud Kubernetes-resursside vastuv\u00f5tu (adoption) jaoks Helm versioonis.<\/p>\n<p>Helm'i sarnases juurutuses on siiski alles m\u00f5ned probleemid ja raskused, nagu Go-mallide kasutamine, ning me j\u00e4tkame nende lahendamist.<\/p>\n<p>Teavet ressursside uuendamise meetodite ja vastuv\u00f5tu kohta leiab samuti <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/resources_update_methods_and_adoption.html\">sellelt dokumentatsiooni lehelt<\/a><\/noindex>.<\/p>\n<h3>Helm 3<\/h3>\n<p>\nErilist t\u00e4helepanu v\u00e4\u00e4rib <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/news\/t\/475722\/\">hiljuti ilmunud<\/a><\/noindex> sel n\u00e4dalal uus peamine versioon Helm \u2014 v3, \u2014 mis kasutab samuti 3-way-merge-patch'e ja vabaneb Tiller'ist. Uus versioon Helm n\u00f5uab <noindex><a rel=\"nofollow\" href=\"https:\/\/helm.sh\/docs\/topics\/v2_v3_migration\/\">migreerimise<\/a><\/noindex> juba olemasolevate paigalduste konverteerimist uue versiooni salvestusformaadi jaoks.<\/p>\n<p>Werf on oma osa pealt juba loobunud Tiller'i kasutamisest, l\u00fclitunud 3-way-merge peale ja lisanud <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/differences_with_helm.html\">palju muud<\/a><\/noindex>, olles samal ajal \u00fchilduv juba olemasolevate Helm 2 paigaldustega (migratsiooniskeeme ei ole vaja k\u00e4ivitada). Seega, kuni werf ei ole l\u00fclitatud Helm 3 peale, ei kaota werf kasutajad olulisi eeliseid, mida Helm 3 pakub v\u00f5rreldes Helm 2-ga (samuti on need werf'is olemas).<\/p>\n<p>Kuid werf'i \u00fcleminek Helm 3 koodibaasile on v\u00e4ltimatu ja toimub l\u00e4hitulevikus. Eeldatavasti on see werf 1.1 v\u00f5i werf 1.2 (praegu on werf'i peamine versioon \u2014 1.0; lisainfot werf'i versioonihaldusest leiate <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">siin<\/a><\/noindex>). Selle aja jooksul j\u00f5uab Helm 3 stabiliseeruda.<\/p>\n<h2>P.S.<\/h2>\n<p>\nLugege ka meie blogist:<\/p>\n<ul>\n<li> Uuenduste m\u00e4rkmete ts\u00fckkel werf-is:\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468049\/\">werf-i kasutamine keerukate Helm-chartide jaoks<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465131\/\">Toetamine monorepo ja multirepo werf-is ning kuidas see on seotud Docker Registryga<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/463613\/\">Saate n\u00fc\u00fcd Docker-pilte werf-is ehitada ka tavalise Dockerfile'i abil<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/460351\/\">werf \u2014 meie t\u00f6\u00f6riist CI\/CD jaoks Kuberneteses (\u00fclevaade ja video ettekandest)<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/469541\/\">\u00dchtsete mikroteenuste ehitamine ja juurutamine werf'i ja GitLab CI abil<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/453734\/\">Tutvumine Helm 3-ga<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Allikas: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/476646\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0421\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c \u0442\u043e, \u0447\u0435\u0433\u043e \u043c\u044b (\u0438 \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u043c\u044b) \u0434\u043e\u043b\u0433\u043e \u0436\u0434\u0430\u043b\u0438: werf, \u043d\u0430\u0448\u0430 Open Source-\u0443\u0442\u0438\u043b\u0438\u0442\u0430 \u0434\u043b\u044f \u0441\u0431\u043e\u0440\u043a\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0438 \u0438\u0445 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 \u0432 Kubernetes, \u0442\u0435\u043f\u0435\u0440\u044c \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442 \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u0435 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439 \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e 3-way-merge-\u043f\u0430\u0442\u0447\u0435\u0439! \u0412 \u0434\u043e\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u0435 \u043a \u044d\u0442\u043e\u043c\u0443, \u043f\u043e\u044f\u0432\u0438\u043b\u0430\u0441\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c adoption\u2019\u0430 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 K8s-\u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432 \u0432 Helm-\u0440\u0435\u043b\u0438\u0437\u044b \u0431\u0435\u0437 \u043f\u0435\u0440\u0435\u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f \u044d\u0442\u0438\u0445 \u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432. \u0415\u0441\u043b\u0438 \u0441\u043e\u0432\u0441\u0435\u043c \u043a\u043e\u0440\u043e\u0442\u043a\u043e, \u0442\u043e \u0441\u0442\u0430\u0432\u0438\u043c WERF_THREE_WAY_MERGE=enabled \u2014 \u043f\u043e\u043b\u0443\u0447\u0430\u0435\u043c \u0434\u0435\u043f\u043b\u043e\u0439 \u00ab\u043a\u0430\u043a \u0432 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":53121,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-53120","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0421\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c \u0442\u043e, \u0447\u0435\u0433\u043e \u043c\u044b (\u0438 \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u043c\u044b) \u0434\u043e\u043b\u0433\u043e \u0436\u0434\u0430\u043b\u0438: werf, \u043d\u0430\u0448\u0430 Open Source-\u0443\u0442\u0438\u043b\u0438\u0442\u0430 \u0434\u043b\u044f \u0441\u0431\u043e\u0440\u043a\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0438 \u0438\u0445 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 \u0432 Kubernetes, \u0442\u0435\u043f\u0435\u0440\u044c \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/3-way-merge-v-werf-deploj-v-kubernetes-s-helm-na-steroidah\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd473-way merge \u0432 werf: \u0434\u0435\u043f\u043b\u043e\u0439 \u0432 Kubernetes \u0441 Helm \u00ab\u043d\u0430 \u0441\u0442\u0435\u0440\u043e\u0438\u0434\u0430\u0445\u00bb | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0421\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c \u0442\u043e, \u0447\u0435\u0433\u043e \u043c\u044b (\u0438 \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u043c\u044b) \u0434\u043e\u043b\u0433\u043e \u0436\u0434\u0430\u043b\u0438: werf, \u043d\u0430\u0448\u0430 Open Source-\u0443\u0442\u0438\u043b\u0438\u0442\u0430 \u0434\u043b\u044f \u0441\u0431\u043e\u0440\u043a\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0438 \u0438\u0445 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 \u0432 Kubernetes, \u0442\u0435\u043f\u0435\u0440\u044c \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/3-way-merge-v-werf-deploj-v-kubernetes-s-helm-na-steroidah\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-11-23T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T11:00:59+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd473-viisiline liitmine werfis: Kubernetesesse kasutusele v\u00f5tmine Helmi \u201esteroididega\u201c | ProHoster","description":"Juhtus see, mida me (ja mitte ainult meie) pikka aega ootasime: werf, meie avatud l\u00e4htekoodiga t\u00f6\u00f6riist rakenduste koostamiseks ja nende toimetamiseks Kubernetesesse, toetab n\u00fc\u00fcd.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/3-way-merge-v-werf-deploj-v-kubernetes-s-helm-na-steroidah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd473-way merge \u0432 werf: \u0434\u0435\u043f\u043b\u043e\u0439 \u0432 Kubernetes \u0441 Helm \u00ab\u043d\u0430 \u0441\u0442\u0435\u0440\u043e\u0438\u0434\u0430\u0445\u00bb | ProHoster","og:description":"\u0421\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c \u0442\u043e, \u0447\u0435\u0433\u043e \u043c\u044b (\u0438 \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u043c\u044b) \u0434\u043e\u043b\u0433\u043e \u0436\u0434\u0430\u043b\u0438: werf, \u043d\u0430\u0448\u0430 Open Source-\u0443\u0442\u0438\u043b\u0438\u0442\u0430 \u0434\u043b\u044f \u0441\u0431\u043e\u0440\u043a\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0438 \u0438\u0445 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 \u0432 Kubernetes, \u0442\u0435\u043f\u0435\u0440\u044c \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442.","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/3-way-merge-v-werf-deploj-v-kubernetes-s-helm-na-steroidah","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-11-23T21:00:00+00:00","article:modified_time":"2020-02-18T11:00:59+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"53120","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 06:11:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:31:28","updated":"2026-01-24 06:11:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/53120","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=53120"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/53120\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/53121"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=53120"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=53120"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=53120"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}