{"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-kordne liitumine werf-ga: Kubernetes'is kasutamine Helm-iga \"steroidide peal\"","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Juhtus see, mida me (ja mitte ainult meie) pikalt ootasime: <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/\">werf<\/a><\/noindex>, meie Open Source-i t\u00f6\u00f6riist rakenduste ehitamiseks ja nende toimetamiseks Kubernetesesse toetab n\u00fc\u00fcd muudatuste rakendamist 3-way-merge-patchide abil! Lisaks on tekkinud v\u00f5imalus olemasolevate K8s-resursside edastamise viimine Helm-release'idesse ilma nende ressursside uuesti loomata.<\/p>\n<p><img decoding=\"async\" alt=\"3-kordne liitumine werf-ga: Kubernetes&#039;is kasutamine Helm-iga &quot;steroidide peal&quot;\" src=\"\/wp-content\/uploads\/2019\/11\/e5be3544c201f7b2c97fba216a49506d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nL\u00fchidalt \u00f6eldes, paneme <code>WERF_THREE_WAY_MERGE=enabled<\/code> \u2014 saame deploida \"nagu <code>kubectl apply<\/code>\", mis on \u00fchilduv olemasolevate Helm 2 installatsioonidega ja isegi natuke rohkem.<\/p>\n<p>Aga alustame teooriast: mis on 3-way-merge-patchid, kuidas inimesed j\u00f5udsid nende genereerimise l\u00e4henemiseni ja miks need on olulised CI\/CD protsessides, mille infrastruktuuri baasiks on Kubernetes? P\u00e4rast seda vaatame, mis 3-way-merge werf'is endast kujutab, milliseid re\u017eiime vaikimisi kasutatakse ja kuidas sellega juhtida.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Mis on 3-way-merge-patch?<\/h2>\n<p>\nAlustame Kubernetesesse YAML-manifestide kaudu ressurside juurutamise \u00fclesandega.<\/p>\n<p>Kubernetes API abil on sellised p\u00f5hitoimingud nagu create, patch, replace ja delete. Eeldatakse, et nende abil tuleb luua mugav pidev ressursside juurutamine klastrisse. Kuidas?<\/p>\n<h3>Imperatiivsed kommandod kubectl<\/h3>\n<p>\nEsimene l\u00e4henemine Kubernetes'e objektide haldamisele on imperatiivsete kubectl k\u00e4skude kasutamine nende objektide loomiseks, muutmiseks ja kustutamiseks. Lihtsalt \u00f6eldes:<\/p>\n<ul>\n<li> k\u00e4sku <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\u00e4sku <code>kubectl scale<\/code> \u2014 muuda replikate arvu:\n<pre><code class=\"bash\">kubectl scale --replicas=3 deployment\/mysql<\/code><\/pre>\n<\/li>\n<li>Kui kaua aega kulub v\u00e4ljastamiseks?<\/li>\n<\/ul>\n<p>\nSee l\u00e4henemine v\u00f5ib alguses tunduda mugav. Kuid probleeme on: <\/p>\n<ol>\n<li> Sellel on raske <b>saab automatiseerida<\/b>.<\/li>\n<li> Kuidas <b>peegeldada konfiguratsiooni<\/b> Git'is? Kuidas teha muudatuste \u00fclevaatamist, mis toimuvad klastris?<\/li>\n<li> Kuidas tagada <b>uuendatavus<\/b> konfiguratsioonide j\u00e4rjepidevus taask\u00e4ivitamisel?<\/li>\n<li>\u2026<\/li>\n<\/ol>\n<p>\nOn selge, et see l\u00e4henemine ei sobi h\u00e4sti koos rakenduse koodi ja infrastruktuuri koodina salvestamisega (IaC; v\u00f5i isegi <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/458878\/\">GitOps<\/a><\/noindex> nagu kaasaegsem variant, mis saab populaarsust Kubernetes'i \u00f6kos\u00fcsteemis). Seet\u00f5ttu ei saanud need k\u00e4sklused kubectl-s edasist arengut.<\/p>\n<h3>Toimingud create, get, replace ja delete<\/h3>\n<p>\nEsmaste <b>loomise<\/b> juhul on k\u00f5ik lihtne: saadame manifesti <code>create<\/code> kube API-sse ja ressurss on loodud. YAML-esitus manifestist saab salvestada Git'i ja loomise jaoks kasutada k\u00e4sku <code>kubectl create -f manifest.yaml<\/code>.<\/p>\n<p>C <b>kustutamine<\/b> on samuti lihtne: sisestame sama <code>manifest.yaml<\/code> Git'ist k\u00e4sku <code>kubectl delete -f manifest.yaml<\/code>.<\/p>\n<p>Operatsioon <b><code>asenda<\/code><\/b> v\u00f5imaldab t\u00e4ielikult asendada ressursi konfiguratsiooni uuega, ilma et ressursi uuesti looma peaks. See t\u00e4hendab, et enne ressursi muutmist on loogiline k\u00fcsida praegust versiooni toimingu <code>get<\/code>, muuta see ja uuendada toiminguga <code>asenda<\/code>. Kube apiserveris on sisse ehitatud <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Optimistic_concurrency_control\">optimistlik lukustus<\/a><\/noindex> ja kui p\u00e4rast toimingut <code>get<\/code> objekt on muutunud, siis toiming <code>asenda<\/code> ei toimi.<\/p>\n<p>Et salvestada konfiguratsioon Git'is ja uuendada seda replace kaudu, tuleb teha toiming <code>get<\/code>, liita Git'i konfiig sellega, mida me saime, ja teha <code>asenda<\/code>. Vaikimisi v\u00f5imaldab kubectl kasutada ainult k\u00e4sku <code>kubectl replace -f manifest.yaml<\/code>, kus <code>manifest.yaml<\/code> \u2014 juba t\u00e4ielikult ettevalmistatud (meie puhul \u2014 \u00fchendatud) manifest, mille n\u00f5utakse paigaldus. Seega peab kasutaja rakendama manifestide \u00fchinemist, mis on keeruline \u00fclesanne ...<\/p>\n<p>Samuti tasub m\u00e4rkida, et kuigi <code>manifest.yaml<\/code> salvestatakse Git'is, ei saa me ette teada, kas on vajalik objekti loomine v\u00f5i uuendamine \u2014 selle peab tegema kasutaja tarkvara.<\/p>\n<p>Kokku: <b>Kas saame ehitada pideva juurutamise<\/b> ainult create, replace ja delete kaudu, tagades infrastruktuuri konfiguratsiooni salvestamise Git'is koos koodiga ja mugava CI\/CD-ga?<\/p>\n<p>P\u00f5him\u00f5tteliselt saame\u2026 Selleks <b>peab olema rakendatud manifestide \u00fchendamise operatsioon<\/b> ja mingi \u00fcmbrus, mis:<\/p>\n<ul>\n<li> kontrollib objekti olemasolu klastris,<\/li>\n<li> teeb esialgse ressursi loomise,<\/li>\n<li> uuendab v\u00f5i kustutab selle.<\/li>\n<\/ul>\n<p>\nUuendamisel tuleb arvestada, et <i>ressurss v\u00f5is olla muutunud<\/i> viimase <code>get<\/code> ja automaatselt k\u00e4sitleda optimistliku lukustuse juhtumit \u2014 teha korduvad uuendamise katsetused.<\/p>\n<p>Kuid miks leiutada ratast, kui kube-apiserver pakub teisi vahendeid ressursside uuendamiseks: toimingu <code>patch<\/code>, mis vabastab kasutaja osadest kirjeldatud probleemidest?<\/p>\n<h3>Patch<\/h3>\n<p>\nN\u00fc\u00fcd olemegi j\u00f5udnud pat\u0161ideni.<\/p>\n<p>Pat\u0161id on peamine viis muudatuste rakendamiseks olemasolevatele objektidele Kuberneteses. Toiming <code>patch<\/code> t\u00f6\u00f6tavad nii, et:<\/p>\n<ul>\n<li> kasutaja kube-apiserver peab saatma pat\u0161i JSON-vormingus ja n\u00e4itama objekti,<\/li>\n<li> samuti apiserver m\u00f5istab objekti praegust seisundit ja viib selle soovitud kujule.<\/li>\n<\/ul>\n<p>\nSellisel juhul ei ole optimistlik lukustus vajalik. See operatsioon on deklaratiivsem v\u00f5rreldes replace'iga, kuigi alguses v\u00f5idakse tunduda vastupidi.<\/p>\n<p>Seega:<\/p>\n<ul>\n<li> toimingu abil <code>create<\/code> loome objekti Git'i manifesti p\u00f5hjal,<\/li>\n<li> kasutades <code>kustuta<\/code> \u2014 kustutame, kui objekti enam ei vajata,<\/li>\n<li> kasutades <code>patch<\/code> \u2014 muudame objekti, viies selle kujule, mis on kirja pandud Git'is.<\/li>\n<\/ul>\n<p>\nKuid selleks, et seda teha, on vajalik luua <i>\u00f5ige pat\u0161<\/i>!<\/p>\n<h3>Kuidas t\u00f6\u00f6tavad Helm 2 patch'id: 2-way-merge<\/h3>\n<p>\nHelmi versiooni esmakordsel installimisel teeb Helm toimingu <code>create<\/code> chart'i ressurside jaoks.<\/p>\n<p>Versiooni uuendamise puhul teeb Helm iga ressursi jaoks:<\/p>\n<ul>\n<li> v\u00f5rdleb eelmise chart'i ressursi versiooni ja praeguse chart'i versiooni vahel olevat patch'i,<\/li>\n<li> rakendab selle patch'i.<\/li>\n<\/ul>\n<p>\nSeda patch'i nimetame <b>2-way-merge patch<\/b>, kuna selle loomises osalevad 2 manifesti:<\/p>\n<ul>\n<li> eelneva versiooni ressursi manifest,<\/li>\n<li> praeguse ressursi manifest.<\/li>\n<\/ul>\n<p>\nKustutamisel toimub toiming <code>kustuta<\/code> kube apiserveris ressurside jaoks, mis olid eelmises versioonis deklareeritud, kuid ei ole praeguses.<\/p>\n<p>2-way merge patch l\u00e4henemisviisil on probleem: see toob kaasa <b>ressursi tegeliku seisundi ja manifesti vahelise mittes\u00fcnkroonimise Git'is<\/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>pilt<\/code> Deployment'il on v\u00e4\u00e4rtus <code>ubuntu:18.04<\/code>.<\/li>\n<li> Kasutaja on l\u00e4bi <code>kubectl edit<\/code> muutanud selle v\u00e4lja v\u00e4\u00e4rtuseks <code>ubuntu:19.04<\/code>.<\/li>\n<li> Helm'i chart'i kordusel ei genereerita patch'i <i>, sest v\u00e4li<\/i>eelmises versioonis ja praeguses chart'is on samad. <code>pilt<\/code> P\u00e4rast korduvat deploimentimist<\/li>\n<li> P\u00e4rast korduvat juurutamist <code>pilt<\/code> j\u00e4\u00e4b alles <code>ubuntu:19.04<\/code>, kuigi chart'is on kirjutatud <code>ubuntu:18.04<\/code>.<\/li>\n<\/ul>\n<p>\nOleme saanud mittes\u00fcnkroonimise ja kaotanud deklaratiivsuse.<\/p>\n<h3>Mis on s\u00fcnkroonitud ressurss?<\/h3>\n<p>\n\u00dcldiselt peab <i>t\u00e4ielik<\/i> vastavus toimiva klastriga ressurssi manifesti ja Git'ist saadud manifesti vahel on v\u00f5imatu saavutada. Sest tegelikus manifestis v\u00f5ivad olla teenuse annotatsioonid \/ sildid, lisakonteinerid ja muud andmed, mille d\u00fcnaamiliselt lisavad ja eemaldavad m\u00f5ned kontrollijad. Need andmed ei saa ja me ei soovi neid hoida Git'is. Siiski soovime, et nende v\u00e4ljade v\u00e4\u00e4rtused, mille oleme selgelt Git'is m\u00e4\u00e4ranud, vastaksid.<\/p>\n<p>Saades seej\u00e4rel selline \u00fcldine <b>s\u00fcnkroonitud ressursi reegel<\/b>: ressursi v\u00e4lja k\u00e4imisel v\u00f5ib muuta v\u00f5i eemaldada ainult need v\u00e4ljad, mis on selgelt m\u00e4\u00e4ratud Git'i manifestis (v\u00f5i kirjutati eelnevas versioonis, kuid n\u00fc\u00fcd on eemaldatud).<\/p>\n<h3>3-way-merge patch<\/h3>\n<p>\nPeamine idee <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Merge_(version_control)#Three-way_merge\">3-way-merge patch<\/a><\/noindex>: genereeritakse patch viimase rakendatud versiooni manifestist Git'ist ja sihtversiooni manifestist Git'ist, arvestades praegust versiooni toimivas klastris. L\u00f5pppatch peab vastama s\u00fcnkroonitud ressursi reeglile:<\/p>\n<ul>\n<li> uusid v\u00e4lju, mis on lisatud sihtversioonile, lisatakse patch'i kaudu;<\/li>\n<li> varasemad v\u00e4ljad viimases rakendatud versioonis ja sihtversioonis, mis ei eksisteeri \u2014 nullitakse patch'i kaudu;<\/li>\n<li> praeguse objekti versioonis olevad v\u00e4ljad, mis erinevad sihtversiooni manifestist, \u2014 uuendatakse patch'i kaudu.<\/li>\n<\/ul>\n<p>\nJust selle p\u00f5him\u00f5tte j\u00e4rgi genereeritakse patch'id <code>kubectl apply<\/code>:<\/p>\n<ul>\n<li> viimane rakendatud versioon manifestist s\u00e4ilitatakse objekti enda annotatsioonis, <\/li>\n<li> siht \u2014 v\u00f5etakse m\u00e4\u00e4ratud YAML-failist,<\/li>\n<li> praegune \u2014 toimivast klastrist.<\/li>\n<\/ul>\n<p>\nN\u00fc\u00fcd, kui me oleme teooriat selgitanud, on aeg r\u00e4\u00e4kida, mida me werf'is tegime.<\/p>\n<h2>Muudatuste kohaldamine werf'is<\/h2>\n<p>\nVarem kasutas werf, nagu ka Helm 2, 2-way-merge-patch'e.<\/p>\n<h3>Repair patch<\/h3>\n<p>\nUue patch'i t\u00fc\u00fcbi, 3-way-merge, juurutamiseks, esimeseks sammuks tutvustasime nn <b>repair-patch'e<\/b>.<\/p>\n<p>K\u00e4ivitamisel kasutatakse standardset 2-way-merge-patch'i, kuid werf genereerib t\u00e4iendavalt sellise patch'i, mis s\u00fcnkroniseerib ressursi tegeliku seisundi sellekohasega Git'is (loodud patch s\u00fcnkroonitud ressursi reegli j\u00e4rgi, nagu eespool kirjeldatud).<\/p>\n<p>Kui tekib mittes\u00fcnkroonimine, saab kasutaja deploimentimise l\u00f5pus WARNING'i vastava s\u00f5numiga ja patch'i, mida tuleb rakendada, et tuua ressurss s\u00fcnkroniseeritud v\u00e4limusele. Samuti salvestatakse see patch spetsiaalsesse annotatsiooni <code>werf.io\/repair-patch.<\/code>Eeldatakse, et kasutaja rakendab selle patch'i k\u00e4sitsi: werf ei rakenda seda p\u00f5him\u00f5tteliselt. <b>Repair-patch'ide genereerimine on ajutine lahendus, mis v\u00f5imaldab proovida 3-way-merge p\u00f5him\u00f5tte alusel patch'ide loomist, kuid neid patch'e automaatselt ei rakendata. Praegu on see t\u00f6\u00f6re\u017eiim vaikimisi sisse l\u00fclitatud.<\/b> rakendab selle plaastri: werf ei rakenda seda p\u00f5him\u00f5tteliselt.<\/p>\n<p>Repair-plaastrite genereerimine on ajutine meede, mis v\u00f5imaldab praktikas katsetada plaastrite loomist 3-way-merge p\u00f5him\u00f5ttel, kuid neid plaastreid ei rakendata automaatselt. Praegu on see t\u00f6\u00f6re\u017eiim vaikimisi sisse l\u00fclitatud.<\/p>\n<h3>3-way-merge patch ainult uutele v\u00e4ljaandele<\/h3>\n<p>\nAlates 1. detsembrist 2019 alustavad werf'i beta- ja alpha-versioonid <b>vaikimisi<\/b> rakendada t\u00e4ie\u00f5iguslikke 3-way-merge-patsh'e muutuste rakendamiseks ainult uutele Helm'i v\u00e4ljaannetele, mis on werf'i kaudu v\u00e4lja antud. Juba olemasolevad v\u00e4ljaanded j\u00e4tkavad 2-way-merge ja repair-patch'ide l\u00e4henemist.<\/p>\n<p>Seda t\u00f6\u00f6re\u017eiimi saab selgelt lubada seadistusega <code>WERF_THREE_WAY_MERGE_MODE=onlyNewReleases<\/code> Seda v\u00f5ib juba praegu kasutada.<\/p>\n<p><i><b>M\u00e4rkus<\/b>: funktsiooni arendamine toimus werf'is mitme v\u00e4ljaande jooksul: alpha-kanalis sai 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>beta-kanalis \u2014 alates <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\u00f5igile v\u00e4ljaannetele<\/h3>\n<p>\nAlates 15. detsembrist 2019 alustavad werf'i beta- ja alpha-versioonid vaikimisi rakendada t\u00e4ie\u00f5iguslikke 3-way-merge-patsh'e muutuste rakendamiseks k\u00f5igile v\u00e4ljaannetele.<\/p>\n<p>Seda t\u00f6\u00f6re\u017eiimi saab selgelt lubada seadistusega <code>WERF_THREE_WAY_MERGE_MODE=enabled<\/code> Seda v\u00f5ib juba praegu kasutada.<\/p>\n<h3>Kuidas on automaatse ressursside skaleerimisega?<\/h3>\n<p>\nKuberneteses on 2 t\u00fc\u00fcpi automaatm\u00f5\u00f5tmisel: HPA (horisontaalne) ja VPA (vertikaalne).<\/p>\n<p>Horisontaalne valib automaatselt koopiate arvu, vertikaalne m\u00e4\u00e4rab ressursse. Nii koopiate arv kui ka ressursin\u00f5uded on m\u00e4rgitud 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\">teised<\/a><\/noindex>).<\/p>\n<p>Probleem: kui kasutaja konfigureerib ressursi chartis nii, et seal on m\u00e4\u00e4ratud kindlad ressursid v\u00f5i koopiad, ja selle ressursi jaoks on lubatud automaatm\u00f5\u00f5tjad, siis igal deploy'il k\u00e4tkeb werf neid v\u00e4\u00e4rtusi tagasi manifestis loetletud v\u00e4\u00e4rtustele.<\/p>\n<p>Probleemi lahendamiseks on kaks v\u00f5imalust. Esiteks on parem loobuda automaatm\u00f5\u00f5tmisv\u00e4\u00e4rtuste selges\u00f5nalisest m\u00e4\u00e4ramisest charti manifestis. Kui see variant mingil p\u00f5hjusel ei sobi (n\u00e4iteks kuna chartis on mugav m\u00e4\u00e4rata algseid ressursipiiranguid ja koopiate arvu), siis 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>\nKuna selline annotatsioon on olemas, ei reseti werf vastavaid v\u00e4\u00e4rtusi igal deploy'il, vaid need m\u00e4\u00e4ratakse ainult ressursi esmakordsel loomisel.<\/p>\n<p>T\u00e4psemalt vt projekti dokumentatsioonis <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>Keela 3-way-merge patch'i kasutamine<\/h3>\n<p>\nKasutaja saab hetkel keelduda uute patchide kasutamisest werfis keskkonnamuutuja abil <code>WERF_THREE_WAY_MERGE_MODE=disabled<\/code>. Kuid alates <b>1. m\u00e4rtsist 2020 kaotab see keeld kehtivuse<\/b> ja v\u00f5imalikuks j\u00e4\u00e4b vaid 3-way-merge patch'ide kasutamine.<\/p>\n<h2>Ressursside adopteerimine werfis<\/h2>\n<p>\n3-way-merge patch'ide kasutuselev\u00f5tt v\u00f5imaldas kohe rakendada sellise funktsiooni nagu klastris olemasolevate ressursside adopteerimine Helm'i v\u00e4ljaande sisse.<\/p>\n<p>Helm 2-l on probleem: juba klastris olemasolevat ressursi ei saa chartide manifestidesse lisada ilma ressursi nulli t\u00e4iendamiseta (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 werfi aktsepteerima olemasolevaid ressursse v\u00e4ljaandes. Selleks tuleb praeguse ressursi versiooni annotatsioon asetada t\u00f6\u00f6tavas klastris (n\u00e4iteks kasutades <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 chartis kirjeldada ja j\u00e4rgmise werf'iga selle nimega v\u00e4ljaande deploy'imisel v\u00f5etakse olemasolev ressurss sellesse v\u00e4ljaandesse ja j\u00e4\u00e4b selle juhtimise alla. Veelgi enam, ressursi vastuv\u00f5tmise protsessis toob werf ressursi praeguse oleku t\u00f6\u00f6tavast klastrist vastavaks chartis kirjeldatud olekule, kasutades samu 3-way-merge patch'e ja ressurssi s\u00fcnkroniseerimise reeglit.<\/p>\n<p><i><b>M\u00e4rkus<\/b>: seade <code>WERF_THREE_WAY_MERGE_MODE<\/code> ei m\u00f5juta ressurside adopteerimist \u2014 adopteerimisel kasutatakse alati 3-way-merge patch'i.<\/i><\/p>\n<p>T\u00e4psemalt vt <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/resources_update_methods_and_adoption.html#resources-adoption\">dokumentatsioonis<\/a><\/noindex>.<\/p>\n<h2>Kokkuv\u00f5tted ja edasised plaanid<\/h2>\n<p>\nLoodan, et p\u00e4rast seda artiklit sai selgemaks, mis on 3-way-merge patch'id ja miks need sisse viidi. Projekti werf arendamise praktilises vaates on nende rakendamine veel \u00fcks samm Helm'i sarnaste deploy'ide parandamiseks. N\u00fc\u00fcd v\u00f5ib unustada konfigureerimise s\u00fcnkroniseerimisega seotud probleemid, millega tihti seoses Helm 2 kasutamisel kokku puututi. Samuti on lisatud uus kasulik funktsioon juba kasutusele v\u00f5etud Kubernetes'i ressursside adopteerimiseks Helm'i v\u00e4ljaandesse.<\/p>\n<p>Helm'i sarnases deploy's on endiselt m\u00f5ned probleemid ja raskused, nagu Go-mallide kasutamine, ja me j\u00e4tkame nende lahendamist.<\/p>\n<p>Teavet ressursside uuendamise meetodite ja adopteerimise kohta v\u00f5ib leida ka <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/resources_update_methods_and_adoption.html\">sellest dokumentatsioonilehelt<\/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 v\u00e4lja antud<\/a><\/noindex> uus peamine versioon Helm \u2014 v3, \u2014 mis samuti kasutab 3-way-merge patch'e ja loob Tilleri. Uus versioon Helm n\u00f5uab <noindex><a rel=\"nofollow\" href=\"https:\/\/helm.sh\/docs\/topics\/v2_v3_migration\/\">migreerimise<\/a><\/noindex> juba olemasolevate installatsioonide konverteerimist uude v\u00e4ljaande salvestamise formaati.<\/p>\n<p>Werf on enda poolt juba eemaldanud Tilleri kasutamise, l\u00e4inud \u00fcle 3-way-merge'ile ja lisanud <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/differences_with_helm.html\">palju muud<\/a><\/noindex>, olles samas \u00fchilduv olemasolevate Helm 2 installatsioonidega (migratsiooni skripte ei ole vaja teostada). Seet\u00f5ttu, kuni werf ei ole \u00fcle l\u00e4inud Helm 3-le, ei kaota werfi kasutajad Helm 3 peamisi eeliseid v\u00f5rreldes Helm 2-ga (need on olemas ka werfis).<\/p>\n<p>Siiski on werfi \u00fcleminek Helm 3 koodibaasi ja tuleb l\u00e4hiajal. Eeldatavasti on see werf 1.1 v\u00f5i werf 1.2 (hetkel on werfi peamine versioon 1.0; lisainfot werfi versioonimise struktuuri kohta vt. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">siit<\/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> Werfi uuenduste ring:\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468049\/\">Werfi kasutamine keerukate Helm-chart'ide v\u00e4lja toomiseks<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465131\/\">Monorepo ja multirepo tugi werf'is ja kuidas siia sobib Docker Registry<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/463613\/\">Docker-iltide kogumist werfis saab n\u00fc\u00fcd teha 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 CI\/CD t\u00f6\u00f6riist Kubernetesis (\u00fclevaade ja videoettekanne)<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/469541\/\">\u00dchesuguste mikroteenuste kogumine ja juurutamine werfi ja GitLab CI-ga.<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/453734\/\">Tutvustame Helm 3<\/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.0.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.0.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-teine \u00fchinemine werf-is: Kubernetes'i juurutamine Helmiga \u00absteroidide peal\u00bb | ProHoster","description":"Juhtus see, mida me (ja mitte ainult meie) pikka aega ootasime: werf, meie Open Source t\u00f6\u00f6riist rakenduste ehitamiseks 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}]}}