{"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\/sq\/blog\/administrirovanie\/3-way-merge-v-werf-deploj-v-kubernetes-s-helm-na-steroidah","title":{"rendered":"Spojimi 3-way n\u00eb werf: instalim n\u00eb Kubernetes me Helm \"n\u00eb steroid\u00eb\"","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Ishte nj\u00eb ngjarje q\u00eb ne (dhe jo vet\u00ebm ne) e prisnim prej koh\u00ebsh: <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/\">werf<\/a><\/noindex>, mjeti yn\u00eb Open Source p\u00ebr nd\u00ebrtimin e aplikacioneve dhe dor\u00ebzimin e tyre n\u00eb Kubernetes, tani mb\u00ebshtet aplikimin e ndryshimeve p\u00ebrmes patch-eve 3-way-merge! P\u00ebrve\u00e7 k\u00ebsaj, \u00ebsht\u00eb b\u00ebr\u00eb e mundur adoptimi i burimeve ekzistuese K8s n\u00eb helm-release pa ri-krijimin e k\u00ebtyre burimeve.<\/p>\n<p><img decoding=\"async\" alt=\"Spojimi 3-way n\u00eb werf: instalim n\u00eb Kubernetes me Helm &quot;n\u00eb steroid\u00eb&quot;\" src=\"\/wp-content\/uploads\/2019\/11\/e5be3544c201f7b2c97fba216a49506d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nN\u00ebse ta themi shum\u00eb shkurt, ne vendosim <code>WERF_THREE_WAY_MERGE=enabled<\/code> \u2014 marrim nj\u00eb deploy \u00absi n\u00eb <code>kubectl aplikoni<\/code>\u00bb, i cili \u00ebsht\u00eb i p\u00ebrshtatsh\u00ebm me instalimet ekzistuese n\u00eb Helm 2 dhe madje pak m\u00eb shum\u00eb.<\/p>\n<p>Por le t\u00eb fillojm\u00eb me teorin\u00eb: \u00e7far\u00eb jan\u00eb patch-et 3-way-merge, si erdh\u00ebn njer\u00ebzit n\u00eb k\u00ebt\u00eb qasje dhe pse jan\u00eb t\u00eb r\u00ebnd\u00ebsishme n\u00eb proceset CI\/CD me infrastruktur\u00eb bazuar n\u00eb Kubernetes? Pas k\u00ebsaj, do t\u00eb shohim se \u00e7far\u00eb p\u00ebrfaq\u00ebson 3-way-merge n\u00eb werf, cilat moda p\u00ebrdoren si parazgjedhje dhe si t'i menaxhojm\u00eb ato.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>\u00c7far\u00eb \u00ebsht\u00eb patch-i 3-way-merge?<\/h2>\n<p>\nPra, le t\u00eb fillojm\u00eb me detyr\u00ebn e nisjes s\u00eb burimeve, t\u00eb p\u00ebrshkruara n\u00eb manifestet YAML, n\u00eb Kubernetes.<\/p>\n<p>P\u00ebr t\u00eb punuar me burimet, Kubernetes API ofron operacionet kryesore: create, patch, replace dhe delete. Supozohet q\u00eb me to duhet t\u00eb nd\u00ebrtohet nj\u00eb deploy i p\u00ebrshtatsh\u00ebm i burimeve n\u00eb klaster. Si?<\/p>\n<h3>Komandat imperativ\u00eb kubectl<\/h3>\n<p>\nAfrohet metoda e par\u00eb p\u00ebr menaxhimin e objekteve n\u00eb Kubernetes \u2014 p\u00ebrdorimi i komandave imperativ\u00eb kubectl p\u00ebr krijimin, ndryshimin dhe fshirjen e k\u00ebtyre objekteve. N\u00eb terma t\u00eb thjesht\u00eb:<\/p>\n<ul>\n<li> me komand\u00ebn <code>kubectl run<\/code> mund t\u00eb nis\u00eb nj\u00eb Deployment ose Job:\n<pre><code class=\"bash\">kubectl run --generator=deployment\/apps.v1 EMRI_I_DEPLOYMENTIT --image=IMAZHI<\/code><\/pre>\n<\/li>\n<li> me komand\u00ebn <code>kubectl scale<\/code> \u2014 ndryshon numrin e replikave:\n<pre><code class=\"bash\">kubectl scale --replicas=3 deployment\/mysql<\/code><\/pre>\n<\/li>\n<li>etj.<\/li>\n<\/ul>\n<p>\nKy qasje mund t\u00eb duket e p\u00ebrshtatshme n\u00eb shikim t\u00eb par\u00eb. Megjithat\u00eb, ka probleme: <\/p>\n<ol>\n<li> \u00cbsht\u00eb e v\u00ebshtir\u00eb <b>p\u00ebr ta automatizuar<\/b>.<\/li>\n<li> Si <b>p\u00ebr t\u00eb reflektuar konfiguracionin<\/b> n\u00eb Git? Si t\u00eb b\u00ebjm\u00eb review t\u00eb ndryshimeve q\u00eb ndodhin me klasterin?<\/li>\n<li> Si t\u00eb sigurojm\u00eb <b>riprodhueshm\u00ebria<\/b> konfigurimin n\u00eb rishkaktim?<\/li>\n<li>\u2026<\/li>\n<\/ol>\n<p>\n\u00cbsht\u00eb e qart\u00eb se ky qasje i p\u00ebrshtatet dob\u00ebt ruajtjes s\u00eb s\u00eb bashku me kodin e aplikacionit dhe infrastruktur\u00ebs si kod (IaC; ose edhe <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/458878\/\">GitOps<\/a><\/noindex> si nj\u00eb variant m\u00eb modern, q\u00eb po fiton popullaritet n\u00eb ekosistemin Kubernetes). Prandaj, zhvillimi i m\u00ebtejsh\u00ebm i k\u00ebtyre komandave n\u00eb kubectl nuk mori prioritet.<\/p>\n<h3>Operacionet create, get, replace dhe delete<\/h3>\n<p>\nMe krijimin <b>n\u00eb fillim<\/b> \u00ebsht\u00eb shum\u00eb e thjesht\u00eb: ne d\u00ebrgojm\u00eb manifestin n\u00eb operacionin <code>krijo<\/code> n\u00eb kube API dhe burimi \u00ebsht\u00eb krijuar. P\u00ebrfaq\u00ebsimi YAML i manifestit mund t\u00eb ruhet n\u00eb Git, dhe p\u00ebr t\u00eb krijuar \u2014 p\u00ebrdorim komand\u00ebn <code>kubectl create -f manifest.yaml<\/code>.<\/p>\n<p>Me <b>fshirja<\/b> po ashtu \u00ebsht\u00eb e thjesht\u00eb: ne mund t\u00eb p\u00ebrdorim t\u00eb nj\u00ebjtin <code>manifest.yaml<\/code> nga Git n\u00eb komand\u00ebn <code>kubectl delete -f manifest.yaml<\/code>.<\/p>\n<p>Operacioni <b><code>z\u00ebvend\u00ebso<\/code><\/b> lejon plot\u00ebsisht t\u00eb z\u00ebvend\u00ebsojm\u00eb konfiguracionin e burimit me nj\u00eb t\u00eb re, pa e rikrijuar burimin. Kjo do t\u00eb thot\u00eb se para se t\u00eb b\u00ebjm\u00eb nj\u00eb ndryshim n\u00eb burim, \u00ebsht\u00eb logjike t\u00eb k\u00ebrkojm\u00eb versionin aktual me operacionin <code>merr<\/code>, ta ndryshojm\u00eb at\u00eb dhe ta azhurnojm\u00eb me operacionin <code>z\u00ebvend\u00ebso<\/code>. N\u00eb kube apiserver \u00ebsht\u00eb nd\u00ebrtuar <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Optimistic_concurrency_control\">optimistic locking<\/a><\/noindex> dhe, n\u00ebse objekti ka ndryshuar pas operacionit, at\u00ebher\u00eb operacioni <code>merr<\/code> nuk do t\u00eb kaloj\u00eb. <code>z\u00ebvend\u00ebso<\/code> nuk nuk kalon.<\/p>\n<p>P\u00ebr t\u00eb ruajtur konfiguracionin n\u00eb Git dhe p\u00ebr ta azhurnuar me z\u00ebvend\u00ebsim, duhet t\u00eb kryejm\u00eb operacionin <code>merr<\/code>, t\u00eb bashkojm\u00eb konfigurimin nga Git me at\u00eb q\u00eb kemi marr\u00eb, dhe t\u00eb ekzekutojm\u00eb <code>z\u00ebvend\u00ebso<\/code>. N\u00eb m\u00ebnyr\u00eb t\u00eb natyrshme, kubectl vet\u00ebm lejon p\u00ebrdorimin e komand\u00ebs <code>kubectl replace -f manifest.yaml<\/code>, ku <code>manifest.yaml<\/code> \u2014 tashm\u00eb nj\u00eb manifest i plot\u00ebsisht i p\u00ebrgatitur (n\u00eb rastin ton\u00eb \u2014 i bashkuar) q\u00eb k\u00ebrkohet t\u00eb vendoset. K\u00ebshtu, p\u00ebrdoruesi duhet t\u00eb zgjidh\u00eb bashkimin e manifest\u00ebve, nj\u00eb detyr\u00eb q\u00eb nuk \u00ebsht\u00eb e thjesht\u00eb\u2026<\/p>\n<p>Po ashtu, duhet t\u00eb theksohet se ndon\u00ebse <code>manifest.yaml<\/code> ruhet n\u00eb Git, ne nuk mund ta dim\u00eb paraprakisht n\u00ebse duhet t\u00eb krijojm\u00eb objektin apo ta azhurnojm\u00eb at\u00eb \u2014 kjo duhet t\u00eb b\u00ebhet nga softi i p\u00ebrdoruesit.<\/p>\n<p>N\u00eb p\u00ebrmbledhje: <b>a mund t\u00eb nd\u00ebrtojm\u00eb nj\u00eb deploy t\u00eb vazhduesh\u00ebm<\/b> vet\u00ebm me ndihm\u00ebn e create, replace dhe delete, duke siguruar ruajtjen e konfiguracionit t\u00eb infrastruktur\u00ebs n\u00eb Git s\u00eb bashku me kodin dhe nj\u00eb CI\/CD t\u00eb p\u00ebrshtatsh\u00ebm?<\/p>\n<p>N\u00eb parim, po\u2026 P\u00ebr k\u00ebt\u00eb <b>do t\u00eb k\u00ebrkoj\u00eb implementimin e operacionit t\u00eb bashkimit<\/b> t\u00eb manifest\u00ebve dhe ndonj\u00eb mb\u00ebshtetje q\u00eb:<\/p>\n<ul>\n<li> kontrollon n\u00ebse objekti \u00ebsht\u00eb n\u00eb klaster,<\/li>\n<li> ekzekuton krijimin fillestar t\u00eb burimit,<\/li>\n<li> azhornohet ose fshihet.<\/li>\n<\/ul>\n<p>\nDuke azhurnuar, duhet t\u00eb kemi parasysh se <i>burimi mund t\u00eb ket\u00eb ndryshuar<\/i> q\u00eb nga hera e fundit <code>merr<\/code> dhe t\u00eb trajtojm\u00eb automatikisht rastin e optimistic locking \u2014 t\u00eb b\u00ebjm\u00eb p\u00ebrpjekje t\u00eb p\u00ebrs\u00ebritura p\u00ebr azhurnimin.<\/p>\n<p>Megjithat\u00eb, pse t\u00eb shpikim biciklet\u00ebn, kur kube-apiserver ofron nj\u00eb m\u00ebnyr\u00eb tjet\u00ebr p\u00ebr t\u00eb azhurnuar burimet: operacionin <code>patch<\/code>, i cili heq disa nga problemet e p\u00ebrshkruara nga p\u00ebrdoruesi?<\/p>\n<h3>Patch<\/h3>\n<p>\nJa ku arrit\u00ebm te patch-et.<\/p>\n<p>Patch-et jan\u00eb m\u00ebnyra kryesore p\u00ebr t\u00eb aplikuar ndryshime n\u00eb objektet ekzistuese n\u00eb Kubernetes. Operacioni <code>patch<\/code> funksionon n\u00eb m\u00ebnyr\u00eb q\u00eb:<\/p>\n<ul>\n<li> p\u00ebrdoruesi i kube-apiserver k\u00ebrkon t\u00eb d\u00ebrgoj\u00eb nj\u00eb patch n\u00eb format JSON dhe t\u00eb specifikoj\u00eb objektin,<\/li>\n<li> nd\u00ebrsa apiserver vet\u00eb do t\u00eb merret me gjendjen aktuale t\u00eb objektit dhe do ta sjell\u00eb at\u00eb n\u00eb form\u00ebn e k\u00ebrkuar.<\/li>\n<\/ul>\n<p>\nOptimistic locking n\u00eb k\u00ebt\u00eb rast nuk k\u00ebrkohet. Ky operacion \u00ebsht\u00eb m\u00eb deklarativ n\u00eb krahasim me z\u00ebvend\u00ebsimin, megjith\u00ebse fillimisht mund t\u00eb duket ndryshe.<\/p>\n<p>Pra:<\/p>\n<ul>\n<li> n\u00ebp\u00ebrmjet operacionit <code>krijo<\/code> krijojm\u00eb objektin sipas manifestit nga Git,<\/li>\n<li> me an\u00eb t\u00eb <code>fshi<\/code> \u2014 e fshijm\u00eb, n\u00ebse objekti nuk \u00ebsht\u00eb m\u00eb i nevojsh\u00ebm,<\/li>\n<li> me an\u00eb t\u00eb <code>patch<\/code> \u2014 e ndryshojm\u00eb objektin, duke e sjell\u00eb at\u00eb n\u00eb form\u00ebn q\u00eb \u00ebsht\u00eb p\u00ebrshkruar n\u00eb Git.<\/li>\n<\/ul>\n<p>\nMegjithat\u00eb, p\u00ebr t\u00eb b\u00ebr\u00eb k\u00ebt\u00eb, \u00ebsht\u00eb e nevojshme t\u00eb krijohet <i>patch i sakt\u00eb<\/i>!<\/p>\n<h3>Si funksionojn\u00eb patch-at n\u00eb Helm 2: 2-way-merge<\/h3>\n<p>\nKur p\u00ebrcaktoni nj\u00eb version t\u00eb ri, Helm kryen nj\u00eb operacion <code>krijo<\/code> p\u00ebr burimet e chart-it.<\/p>\n<p>Kur p\u00ebrdit\u00ebsoni versionin Helm p\u00ebr secil\u00ebn burim:<\/p>\n<ul>\n<li> krijon nj\u00eb patch midis versionit t\u00eb burimit nga chart-i i kaluar dhe versionit aktual t\u00eb chart-it,<\/li>\n<li> aplikon k\u00ebt\u00eb patch.<\/li>\n<\/ul>\n<p>\nPatch-i i till\u00eb do ta quajm\u00eb <b>patch 2-way-merge<\/b>, sepse n\u00eb krijimin e tij p\u00ebrfshihen 2 manifesete:<\/p>\n<ul>\n<li> manifesti i burimit nga versioni i kaluar,<\/li>\n<li> manifesti i burimit nga burimi aktual.<\/li>\n<\/ul>\n<p>\nKur fshini, operacioni <code>fshi<\/code> n\u00eb kube apiserver thirret p\u00ebr burimet q\u00eb ishin t\u00eb shpallura n\u00eb versionin e kaluar, por nuk jan\u00eb shpallur n\u00eb at\u00eb aktual.<\/p>\n<p>Qasja me patch 2-way merge ka nj\u00eb problem: ajo \u00e7on n\u00eb <b>asinkronizimin e gjendjes reale t\u00eb burimit n\u00eb klaster dhe manifestin n\u00eb Git<\/b>.<\/p>\n<h3>Illustrimi i problemit me shembuj<\/h3>\n<p><\/p>\n<ul>\n<li> N\u00eb Git, n\u00eb chart ruhet nj\u00eb manifest, n\u00eb t\u00eb cilin fusha <code>image<\/code> n\u00eb Deployment ka vler\u00ebn <code>ubuntu:18.04<\/code>.<\/li>\n<li> P\u00ebrdoruesi p\u00ebrmes <code>kubectl edit<\/code> ndryshoi vler\u00ebn e k\u00ebsaj fushe n\u00eb <code>ubuntu:19.04<\/code>.<\/li>\n<li> Kur ri-deploy gjenje chart-i Helm <i>nuk gjeneron patch<\/i>, sepse fusha <code>image<\/code> n\u00eb versionin e kaluar dhe n\u00eb chart-in e tanish\u00ebm jan\u00eb t\u00eb nj\u00ebjtat.<\/li>\n<li> Pas ri-deploy, <code>image<\/code> mbetet <code>ubuntu:19.04<\/code>, ndon\u00ebse n\u00eb chart shkruhet <code>ubuntu:18.04<\/code>.<\/li>\n<\/ul>\n<p>\nK\u00ebshtu kemi pasur asinkronizim dhe humb\u00ebm deklarativitetin.<\/p>\n<h3>\u00c7far\u00eb \u00ebsht\u00eb nj\u00eb burim i sinkronizuar?<\/h3>\n<p>\nN\u00eb p\u00ebrgjith\u00ebsi, <i>p\u00ebrputhja e plot\u00eb<\/i> e manifestit t\u00eb burimit n\u00eb klasterin e pun\u00ebs dhe manifestit nga Git nuk \u00ebsht\u00eb e mundur. Sepse n\u00eb manifestin e v\u00ebrtet\u00eb mund t\u00eb ket\u00eb annotime\/etiketa t\u00eb sh\u00ebrbimit, kontejner\u00eb shtes\u00eb dhe t\u00eb dh\u00ebna t\u00eb tjera q\u00eb shtohen dhe fshihen nga burimi dinamikisht nga disa kontroler\u00eb. K\u00ebto t\u00eb dh\u00ebna ne nuk mund dhe nuk duam t'i mbajm\u00eb n\u00eb Git. Megjithat\u00eb, ne duam q\u00eb kur t\u00eb publikojm\u00eb, fushat e caktuara q\u00eb kemi specifikuar n\u00eb Git t\u00eb pranojn\u00eb vlerat p\u00ebrkat\u00ebse.<\/p>\n<p>Pra, kemi nj\u00eb rregull t\u00eb p\u00ebrgjithsh\u00ebm <b>t\u00eb burimit t\u00eb sinkronizuar<\/b>: gjat\u00eb publikimit t\u00eb burimit mund t\u00eb ndryshohen ose fshihen vet\u00ebm ato fusha q\u00eb jan\u00eb qart\u00ebsisht t\u00eb shkruara n\u00eb manifestin nga Git (ose ishin sh\u00ebnuar n\u00eb versionin e kaluar dhe tani jan\u00eb fshir\u00eb).<\/p>\n<h3>patch 3-way-merge<\/h3>\n<p>\nIdeja kryesore <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Merge_(version_control)#Three-way_merge\">patch 3-way-merge<\/a><\/noindex>: gjeneron nj\u00eb patch midis versionit t\u00eb fundit t\u00eb aplikuar t\u00eb manifestit nga Git dhe versionit t\u00eb synuar t\u00eb manifestit nga Git duke marr\u00eb parasysh versionin aktual t\u00eb manifestit nga klasteri i pun\u00ebs. Patch-i p\u00ebrfundimtar duhet t\u00eb p\u00ebrputhet me rregullin e burimit t\u00eb sinkronizuar:<\/p>\n<ul>\n<li> fushat e reja, t\u00eb shtuar n\u00eb versionin e synuar, shtohen me an\u00eb t\u00eb patch-it;<\/li>\n<li> fushat q\u00eb ekzistonin m\u00eb par\u00eb n\u00eb versionin e fundit t\u00eb aplikuar dhe nuk ekzistojn\u00eb n\u00eb versionin e synuar - nullohen me an\u00eb t\u00eb patch-it;<\/li>\n<li> fushat n\u00eb versionin aktual t\u00eb objektit, q\u00eb dallohet nga versioni i synuar i manifestit, - p\u00ebrdit\u00ebsohen me an\u00eb t\u00eb patch-it.<\/li>\n<\/ul>\n<p>\nN\u00eb k\u00ebt\u00eb m\u00ebnyr\u00eb, patch-et gjenerohen <code>kubectl aplikoni<\/code>:<\/p>\n<ul>\n<li> versioni i fundit i aplikuar i manifestit ruhet n\u00eb annotimin e vet\u00eb objektit, <\/li>\n<li> versioni i synuar merret nga skedari YAML i caktuar,<\/li>\n<li> versioni aktual - nga klasteri i pun\u00ebs.<\/li>\n<\/ul>\n<p>\nTani, pasi i kuptuam teorit\u00eb, \u00ebsht\u00eb koha t\u00eb flasim p\u00ebr at\u00eb q\u00eb kemi b\u00ebr\u00eb n\u00eb werf.<\/p>\n<h2>Raportimi i ndryshimeve n\u00eb werf<\/h2>\n<p>\nM\u00eb par\u00eb, werf, ashtu si Helm 2, p\u00ebrdorte patch-at 2-way-merge.<\/p>\n<h3>Patch-i i Riparimit<\/h3>\n<p>\nP\u00ebr t\u00eb kaluar n\u00eb llojin e ri t\u00eb patch-it - 3-way-merge, hapi i par\u00eb q\u00eb kemi marr\u00eb \u00ebsht\u00eb prezantimi i ashtuquajtur <b>patch i riparimit<\/b>.<\/p>\n<p>Gjat\u00eb publikimit p\u00ebrdoret standardi 2-way-merge patch, por werf gjithashtu krijon nj\u00eb patch q\u00eb sinkronizon gjendjen reale t\u00eb burimit me at\u00eb q\u00eb \u00ebsht\u00eb shkruar n\u00eb Git (n\u00eb krijimin e k\u00ebtij patch-i p\u00ebrdoret rregulli i sinkronizimit t\u00eb burimeve, si\u00e7 u p\u00ebrmend m\u00eb lart).<\/p>\n<p>N\u00eb rast se ndodh nj\u00eb asinkronizim, n\u00eb fund t\u00eb publikimit p\u00ebrdoruesi merr nj\u00eb WARNING me mesazhin dhe patch-in p\u00ebrkat\u00ebs q\u00eb duhet t\u00eb aplikohet p\u00ebr t\u00eb sjell\u00eb burimin n\u00eb nj\u00eb gjendje t\u00eb sinkronizuar. Gjithashtu, ky patch regjistrohet n\u00eb nj\u00eb annotim t\u00eb ve\u00e7ant\u00eb <code>werf.io\/repair-patch<\/code>. Supozohet se p\u00ebrdoruesi manualisht <b>vet\u00eb<\/b> do ta aplikoj\u00eb k\u00ebt\u00eb patch: werf nuk do ta aplikoj\u00eb.<\/p>\n<p>Gjenerimi i repair-patch-eve \u00ebsht\u00eb nj\u00eb mas\u00eb e p\u00ebrkohshme q\u00eb lejon testimin e realizimit t\u00eb patch-eve sipas parimit t\u00eb 3-way-merge, por patch-et k\u00ebto nuk aplikohen automatikisht. Aktualisht, ky mod \u00ebsht\u00eb aktivizuar me parazgjedhje.<\/p>\n<h3>Patch i 3-way-merge vet\u00ebm p\u00ebr l\u00ebshime t\u00eb reja<\/h3>\n<p>\nDeri m\u00eb 1 dhjetor 2019, versionet beta dhe alpha t\u00eb werf fillojn\u00eb <b>n\u00eb m\u00ebnyr\u00eb default<\/b> t\u00eb p\u00ebrdorin patch-et e plota 3-way-merge p\u00ebr t\u00eb kryer ndryshime vet\u00ebm p\u00ebr l\u00ebshime t\u00eb reja Helm t\u00eb publikuara n\u00ebp\u00ebrmjet werf. L\u00ebshimet ekzistuese do t\u00eb vazhdojn\u00eb t\u00eb p\u00ebrdorin qasjen me 2-way-merge + repair-patch-e.<\/p>\n<p>Ky mod funksionimi mund t\u00eb aktivizohet qart\u00eb duke e konfiguruar <code>WERF_THREE_WAY_MERGE_MODE=onlyNewReleases<\/code> t\u00eb shkarkohet tashm\u00eb.<\/p>\n<p><i><b>Sh\u00ebnim<\/b>: funksionaliteti \u00ebsht\u00eb shfaqur n\u00eb werf p\u00ebr gjat\u00eb disa l\u00ebshimeve: n\u00eb kanal alpha ka qen\u00eb i gatsh\u00ebm q\u00eb nga versioni <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/releases\/tag\/v1.0.5-alpha.19\">v1.0.5-alpha.19<\/a><\/noindex>, nd\u00ebrsa n\u00eb kanal beta - nga <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>Patch i 3-way-merge p\u00ebr t\u00eb gjitha l\u00ebshimet<\/h3>\n<p>\nDeri m\u00eb 15 dhjetor 2019, versionet beta dhe alpha t\u00eb werf fillojn\u00eb t\u00eb p\u00ebrdorin automatikisht patch-et e plota 3-way-merge p\u00ebr t\u00eb kryer ndryshime p\u00ebr t\u00eb gjitha l\u00ebshimet.<\/p>\n<p>Ky mod funksionimi mund t\u00eb aktivizohet qart\u00eb duke e konfiguruar <code>WERF_THREE_WAY_MERGE_MODE=enabled<\/code> t\u00eb shkarkohet tashm\u00eb.<\/p>\n<h3>Si t\u00eb menaxhojm\u00eb automatizimin e burimeve?<\/h3>\n<p>\nN\u00eb Kubernetes ekzistojn\u00eb 2 lloje automatizimi: HPA (horizontal) dhe VPA (vertical).<\/p>\n<p>Horizontalja p\u00ebrzgjedh automatikisht numrin e kopjeve, nd\u00ebrsa vertikalia \u2014 sasin\u00eb e burimeve. Si numri i kopjeve ashtu edhe k\u00ebrkesat p\u00ebr burimet specifikohen n\u00eb manifestin e burimit (shih. <code>spec.replicas<\/code> ose <code>spec.containers[].resources.limits.cpu<\/code>, <code>spec.containers[].resources.limits.memory<\/code> dhe <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/configuration\/manage-compute-resources-container\/#resource-requests-and-limits-of-pod-and-container\">t\u00eb tjera<\/a><\/noindex>).<\/p>\n<p>Problemi: n\u00ebse p\u00ebrdoruesi konfigurion burimin n\u00eb chart duke specifikuar vlera t\u00eb caktuara p\u00ebr burimet ose kopjet dhe p\u00ebr k\u00ebt\u00eb burim aktivizohen automatizuesit, at\u00ebher\u00eb n\u00eb \u00e7do shp\u00ebrndarje werf do t\u00eb rikthej\u00eb k\u00ebto vlera n\u00eb ato q\u00eb jan\u00eb t\u00eb regjistruara n\u00eb manifestin e chartit.<\/p>\n<p>Ka dy zgjidhje p\u00ebr k\u00ebt\u00eb problem. Fillimisht, \u00ebsht\u00eb m\u00eb mir\u00eb t\u00eb heqim dor\u00eb nga specifikimi i qart\u00eb t\u00eb vlerave t\u00eb automatizueshme n\u00eb manifestin e chartit. N\u00ebse kjo opsion p\u00ebr disa arsye nuk \u00ebsht\u00eb i p\u00ebrshtatsh\u00ebm (p\u00ebr shembull, sepse n\u00eb chart \u00ebsht\u00eb e leht\u00eb t\u00eb vendos\u00ebsh kufij fillestar\u00eb p\u00ebr burimet dhe numrin e kopjeve), at\u00ebher\u00eb werf ofron k\u00ebto anotacione:<\/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>\nMe pasjen e nj\u00eb anotacioni t\u00eb till\u00eb, werf nuk do t\u00eb rikthej\u00eb vlerat p\u00ebrkat\u00ebse n\u00eb \u00e7do shp\u00ebrndarje, por vet\u00ebm do t'i vendos\u00eb ato gjat\u00eb krijimit t\u00eb par\u00eb t\u00eb burimit.<\/p>\n<p>P\u00ebr m\u00eb shum\u00eb informacione \u2013 shih n\u00eb dokumentacionin e projektit p\u00ebr <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/resources_update_methods_and_adoption.html#deal-with-hpa\">HPA<\/a><\/noindex> dhe <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>Ndalo p\u00ebrdorimin e patch-it 3-way-merge<\/h3>\n<p>\nP\u00ebrdoruesi mund t\u00eb ndaloj\u00eb p\u00ebr momentin p\u00ebrdorimin e patch-eve t\u00eb reja n\u00eb werf p\u00ebrmes variabl\u00ebs s\u00eb mjedisit <code>WERF_THREE_WAY_MERGE_MODE=disabled<\/code>. Megjithat\u00eb, duke filluar nga <b>1 mars 2020, kjo ndales\u00eb do t\u00eb ndaloj\u00eb s\u00eb funksionuari<\/b> dhe do t\u00eb jet\u00eb e mundur vet\u00ebm p\u00ebrdorimi i patch-eve 3-way-merge.<\/p>\n<h2>Adoptimi i burimeve n\u00eb werf<\/h2>\n<p>\nZhvillimi i metod\u00ebs s\u00eb zbatimit t\u00eb ndryshimeve me patch-e 3-way-merge na lejojn\u00eb t\u00eb implementojm\u00eb nj\u00eb karakteristik\u00eb t\u00eb till\u00eb si adoptimi i burimeve ekzistuese n\u00eb klaster n\u00eb Helm-release.<\/p>\n<p>Helm 2 ka nj\u00eb problem: nuk \u00ebsht\u00eb e mundur t\u00eb shtosh n\u00eb manifestet e chartit nj\u00eb burim q\u00eb ekziston tashm\u00eb n\u00eb klaster pa e rind\u00ebrtuar k\u00ebt\u00eb burim nga e para (shih. <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>). Ne m\u00ebsuam werf t\u00eb pranoj\u00eb burimet ekzistuese n\u00eb release. P\u00ebr k\u00ebt\u00eb, duhet t\u00eb vendosni n\u00eb versionin aktual t\u00eb burimit nga klasteri aktiv nj\u00eb anotacion (p\u00ebr shembull, p\u00ebrmes <code>kubectl edit<\/code>):<\/p>\n<pre><code class=\"plaintext\">\"werf.io\/allow-adoption-by-release\": RELEASE_NAME<\/code><\/pre>\n<p>\nTani burimi duhet t\u00eb p\u00ebrshkruhet n\u00eb chart dhe gjat\u00eb shp\u00ebrndarjes tjet\u00ebr t\u00eb werf-it t\u00eb release me emrin p\u00ebrkat\u00ebs, burimi ekzistues do t\u00eb pranohet n\u00eb k\u00ebt\u00eb release dhe do t\u00eb mbetet n\u00ebn menaxhimin e tij. M\u00eb shum\u00eb se kaq, n\u00eb procesin e pranimit t\u00eb burimit n\u00eb release, werf do t\u00eb sjell\u00eb gjendjen aktuale t\u00eb burimit nga klasteri aktiv n\u00eb gjendjen, si\u00e7 p\u00ebrshkruhet n\u00eb chart, duke p\u00ebrdorur t\u00eb nj\u00ebjtat patch-e 3-way-merge dhe rregullin e burimeve t\u00eb sinkronizuara.<\/p>\n<p><i><b>Sh\u00ebnim<\/b>: konfigurimi <code>WERF_THREE_WAY_MERGE_MODE<\/code> nuk ndikon n\u00eb adoptimin e burimeve \u2014 n\u00eb rastin e adoptimit gjithmon\u00eb p\u00ebrdoret patch-i 3-way-merge.<\/i><\/p>\n<p>Detajet \u2013 n\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/resources_update_methods_and_adoption.html#resources-adoption\">dokumentacion<\/a><\/noindex>.<\/p>\n<h2>Konkluzionet dhe planet e ardhshme<\/h2>\n<p>\nShpresoj, pas k\u00ebtij artikulli ka shkuar m\u00eb qart\u00eb se \u00e7far\u00eb jan\u00eb patch-et 3-way-merge dhe pse arrit\u00ebm k\u00ebtu. Nga nj\u00eb pik\u00ebpamje praktike e zhvillimit t\u00eb projektit werf, implementimi i tyre u b\u00eb nj\u00eb hap tjet\u00ebr n\u00eb p\u00ebrmir\u00ebsimin e shp\u00ebrndarjes s\u00eb ngjashme me Helm. Tani mund t\u00eb harrojm\u00eb problemet me sinkronizimin e konfiguracionit q\u00eb shpesh shfaqeshin gjat\u00eb p\u00ebrdorimit t\u00eb Helm 2. Gjithashtu, u shtua nj\u00eb karakteristik\u00eb e re e dobishme t\u00eb adoptimit t\u00eb burimeve Kubernetes t\u00eb shkarkuara.<\/p>\n<p>N\u00eb shp\u00ebrndarjen e ngjashme me Helm vazhdojn\u00eb t\u00eb mbeten disa probleme dhe v\u00ebshtir\u00ebsi, si\u00e7 jan\u00eb p\u00ebrdorimi i templating-ve Go, dhe ne do t\u00eb vazhdojm\u00eb t'i zgjidhim ato.<\/p>\n<p>Informacion p\u00ebr metodat e p\u00ebrdit\u00ebsimit t\u00eb burimeve dhe adoptimit gjithashtu mund t\u00eb gjendet n\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/resources_update_methods_and_adoption.html\">k\u00ebt\u00eb faqe dokumentacioni<\/a><\/noindex>.<\/p>\n<h3>Helm 3<\/h3>\n<p>\nNj\u00eb v\u00ebrejtje e ve\u00e7ant\u00eb meriton <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/news\/t\/475722\/\">versioni i ri i r\u00ebnd\u00ebsish\u00ebm<\/a><\/noindex> i l\u00ebshuar para disa dit\u00ebsh Helm \u2014 v3, \u2014 i cili gjithashtu p\u00ebrdor patch-e 3-way-merge dhe heq Tiller. Versioni i ri i Helm k\u00ebrkon <noindex><a rel=\"nofollow\" href=\"https:\/\/helm.sh\/docs\/topics\/v2_v3_migration\/\">migrimi<\/a><\/noindex> instalimet ekzistuese q\u00eb t'i konvertojn\u00eb ato n\u00eb formatin e ri t\u00eb ruajtjes s\u00eb releases.<\/p>\n<p>Werf nga ana e tij p\u00ebr momentin nuk e p\u00ebrdor m\u00eb Tiller, \u00ebsht\u00eb nd\u00ebrruar n\u00eb 3-way-merge dhe ka shtuar <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/differences_with_helm.html\">shum\u00eb m\u00eb tep\u00ebr<\/a><\/noindex>, duke q\u00ebndruar n\u00eb p\u00ebrputhje me instalimet ekzistuese n\u00eb Helm 2 (nuk nevojiten skripte migrimi). Prandaj, sa her\u00eb q\u00eb werf nuk \u00ebsht\u00eb kaluar n\u00eb Helm 3, p\u00ebrdoruesit e werf nuk humbasin p\u00ebrfitimet kryesore t\u00eb Helm 3 n\u00eb krahasim me Helm 2 (ato jan\u00eb gjithashtu t\u00eb pranishme n\u00eb werf).<\/p>\n<p>Megjithat\u00eb, kalimi i werf n\u00eb kodin baz\u00eb t\u00eb Helm 3 \u00ebsht\u00eb i pashmangsh\u00ebm dhe do t\u00eb ndodh\u00eb n\u00eb t\u00eb ardhmen e af\u00ebrt. Supozohet se kjo do t\u00eb jet\u00eb werf 1.1 ose werf 1.2 (p\u00ebr momentin, versioni kryesor i werf \u00ebsht\u00eb 1.0; p\u00ebr m\u00eb shum\u00eb rreth nd\u00ebrtimit t\u00eb versioneve t\u00eb werf shih. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">k\u00ebtu<\/a><\/noindex>). Gjat\u00eb k\u00ebsaj kohe, Helm 3 do t\u00eb stabilizohet.<\/p>\n<h2>P.S.<\/h2>\n<p>\nLexoni gjithashtu n\u00eb blogun ton\u00eb:<\/p>\n<ul>\n<li> Cikli i sh\u00ebnimeve mbi risit\u00eb n\u00eb werf:\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468049\/\">P\u00ebrdorimi i werf p\u00ebr shp\u00ebrndarjen e chart-eve komplekse t\u00eb Helm<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465131\/\">P\u00ebrkrahja e monorepo dhe multirepo n\u00eb werf dhe \u00e7far\u00eb lidhje ka me Docker Registry<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/463613\/\">Tani \u00ebsht\u00eb e mundur t\u00eb nd\u00ebrtosh imazhe Docker n\u00eb werf edhe p\u00ebrmes Dockerfile standard<\/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 mjeti yn\u00eb p\u00ebr CI\/CD n\u00eb Kubernetes (p\u00ebrmbledhje dhe video k\u00ebrkese)<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/469541\/\">Nd\u00ebrtimi dhe implementimi i mikrosherbimeve t\u00eb ngjashme me werf dhe GitLab CI<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/453734\/\">Njohja me Helm 3<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Burimi: <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\/sq\/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=\"sq_AL\" \/>\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\/sq\/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-way merge n\u00eb werf: d\u00ebrgim n\u00eb Kubernetes me Helm \u00abn\u00eb steroide\u00bb | ProHoster","description":"Ndodhi ajo q\u00eb ne (dhe jo vet\u00ebm ne) e prisnim prej koh\u00ebsh: werf, utiliteti yn\u00eb Open Source p\u00ebr nd\u00ebrtimin e aplikacioneve dhe dor\u00ebzimin e tyre n\u00eb Kubernetes, tani mb\u00ebshtet.","canonical_url":"https:\/\/prohoster.info\/sq\/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":"sq_AL","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\/sq\/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\/sq\/wp-json\/wp\/v2\/posts\/53120","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/comments?post=53120"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/53120\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media\/53121"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media?parent=53120"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/categories?post=53120"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/tags?post=53120"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}