{"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":"3-way merge n\u00eb werf: deponim n\u00eb Kubernetes me Helm \u00abn\u00eb steroide\u00bb","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Ndodhi ajo q\u00eb ne (dhe jo vet\u00ebm ne) prisnim prej nj\u00eb kohe t\u00eb gjat\u00eb: <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/\">werf<\/a><\/noindex>, utilitarja jon\u00eb Open Source p\u00ebr nd\u00ebrtimin e aplikacioneve dhe shp\u00ebrndarjen 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 l\u00ebshimet Helm pa rinovimin e k\u00ebtyre burimeve.<\/p>\n<p><img decoding=\"async\" alt=\"3-way merge n\u00eb werf: deponim n\u00eb Kubernetes me Helm \u00abn\u00eb steroide\u00bb\" src=\"\/wp-content\/uploads\/2019\/11\/e5be3544c201f7b2c97fba216a49506d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nN\u00ebse e themi shkurt, vendosim <code>WERF_THREE_WAY_MERGE=enabled<\/code> \u2014 marrim deponim \u00absi n\u00eb <code>kubectl apply<\/code>\u00bb, i pajtuesh\u00ebm me instalimet ekzistuese n\u00eb Helm 2 dhe ndoshta edhe 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 arrit\u00ebn njer\u00ebzit n\u00eb qasjen e gjenerimit t\u00eb tyre dhe pse jan\u00eb t\u00eb r\u00ebnd\u00ebsishme n\u00eb proceset CI\/CD me infrastruktur\u00ebn e bazuar n\u00eb Kubernetes? Pas k\u00ebsaj - do t\u00eb shohim se \u00e7far\u00eb paraqet 3-way-merge n\u00eb werf, cilat modet p\u00ebrdoren si parazgjedhje dhe si t\u00eb menaxhohen ato.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>\u00c7far\u00eb \u00ebsht\u00eb patch 3-way-merge?<\/h2>\n<p>\nK\u00ebshtu, fillojm\u00eb me detyr\u00ebn e nxjerrjes s\u00eb burimeve t\u00eb p\u00ebrshkruara n\u00eb manifestet YAML, n\u00eb Kubernetes.<\/p>\n<p>P\u00ebr t\u00eb punuar me burimet, API i Kubernetes ofron operacionet themelore: create, patch, replace dhe delete. Supozohet se me to duhet t\u00eb nd\u00ebrtohet nj\u00eb nxjerrje e vazhdueshme e burimeve n\u00eb klaster. Si?<\/p>\n<h3>Komandat imperativ kubectl<\/h3>\n<p>\nQasja e par\u00eb p\u00ebr menaxhimin e objekteve n\u00eb Kubernetes \u2014 p\u00ebrdorimi i komandave imperativ kubectl p\u00ebr t\u00eb krijuar, ndryshuar dhe fshir\u00eb k\u00ebto objekte. Thjesht th\u00ebn\u00eb:<\/p>\n<ul>\n<li> n\u00ebp\u00ebrmjet komand\u00ebs. <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> n\u00ebp\u00ebrmjet komand\u00ebs. <code>kubectl scale<\/code> \u2014 ndryshoni 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>\nKjo qasje mund t\u00eb duket e leht\u00eb n\u00eb shikim t\u00eb par\u00eb. Megjithat\u00eb, ka probleme: <\/p>\n<ol>\n<li> \u00cbsht\u00eb e v\u00ebshtir\u00eb <b>t\u00eb automatizohet<\/b>.<\/li>\n<li> Si <b>t\u00eb pasqyrohet konfigurimi<\/b> n\u00eb Git? Si t\u00eb b\u00ebhet rishikimi i ndryshimeve q\u00eb ndodhin me klasterin?<\/li>\n<li> Si t\u00eb sigurohet <b>riprodhueshm\u00ebria<\/b> e konfigurimit gjat\u00eb rinisjes?<\/li>\n<li>\u2026<\/li>\n<\/ol>\n<p>\n\u00cbsht\u00eb e qart\u00eb se kjo qasje nuk p\u00ebrputhet mir\u00eb me ruajtjen e s\u00eb nj\u00ebjt\u00ebs p\u00ebrkrah kodit t\u00eb aplikacionit dhe infrastruktur\u00ebs si kod (IaC; ose madje <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, k\u00ebto komanda nuk pat\u00ebn zhvillim t\u00eb m\u00ebtejsh\u00ebm n\u00eb kubectl.<\/p>\n<h3>Operacionet create, get, replace dhe delete<\/h3>\n<p>\nMe krijimin e par\u00eb <b>gjer\u00ebsisht \u00ebsht\u00eb e thjesht\u00eb: d\u00ebrgojm\u00eb manifestin n\u00eb operacionin<\/b> n\u00eb kube api dhe burimi \u00ebsht\u00eb krijuar. Paraqitja YAML e manifestit mund t\u00eb ruhet n\u00eb Git, dhe p\u00ebr krijim mund t\u00eb p\u00ebrdoret komanda <code>create<\/code> kubectl create -f manifest.yaml <code>fshirja<\/code>.<\/p>\n<p>D <b>po ashtu \u00ebsht\u00eb e thjesht\u00eb: vendosim t\u00eb nj\u00ebjtin<\/b> manifest.yaml <code>manifest.yaml<\/code> nga Git n\u00eb ekip <code>kubectl delete -f manifest.yaml<\/code>.<\/p>\n<p>Operaci\u00f3n <b><code>nd\u00ebrrim<\/code><\/b> lejon z\u00ebvend\u00ebsimin e plot\u00eb t\u00eb konfiguracionit t\u00eb burimit me nj\u00eb t\u00eb ri, pa krijuar p\u00ebrs\u00ebri burimin. Kjo do t\u00eb thot\u00eb se para se t\u00eb b\u00ebni ndryshime n\u00eb burim, \u00ebsht\u00eb logjike t\u00eb k\u00ebrkoni versionin aktual p\u00ebrmes veprimit <code>merr<\/code>, ta ndryshoni at\u00eb dhe ta p\u00ebrdit\u00ebsoni p\u00ebrmes veprimit <code>nd\u00ebrrim<\/code>. N\u00eb kube apiserver \u00ebsht\u00eb e integruar <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Optimistic_concurrency_control\">nd\u00ebrprerja optimiste<\/a><\/noindex> dhe, n\u00ebse objekti \u00ebsht\u00eb ndryshuar pas veprimit <code>merr<\/code> veprimi <code>nd\u00ebrrim<\/code> nuk do t\u00eb kaloj\u00eb.<\/p>\n<p>P\u00ebr t\u00eb ruajtur konfigurimin n\u00eb Git dhe p\u00ebr ta p\u00ebrdit\u00ebsuar me an\u00eb t\u00eb nd\u00ebrrimit, duhet t\u00eb b\u00ebni veprimin <code>merr<\/code>, t\u00eb bashkoni konfigurimin nga Git me at\u00eb q\u00eb kemi marr\u00eb, dhe t\u00eb kryeni <code>nd\u00ebrrim<\/code>. Si standard, kubectl lejon vet\u00ebm p\u00ebrdorimin e komand\u00ebs <code>kubectl replace -f manifest.yaml<\/code>index <code>manifest.yaml<\/code> \u2014 nj\u00eb manifest i p\u00ebrgatitur plot\u00ebsisht (n\u00eb rastin ton\u00eb \u2014 i bashkuar) q\u00eb duhet t\u00eb vendoset. K\u00ebshtu, p\u00ebrdoruesi duhet t\u00eb realizoj\u00eb bashkimin e manifeve, dhe kjo \u00ebsht\u00eb nj\u00eb \u00e7\u00ebshtje jo triviale\u2026<\/p>\n<p>Po ashtu, \u00ebsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb theksohet se megjithat\u00eb <code>manifest.yaml<\/code> n\u00ebse ruhet n\u00eb Git, nuk mund t\u00eb dim\u00eb paraprakisht n\u00ebse duhet t\u00eb krijohet objekti ose ta p\u00ebrdit\u00ebsojm\u00eb \u2014 kjo duhet ta b\u00ebj\u00eb softi i p\u00ebrdoruesit.<\/p>\n<p>Pra, n\u00eb p\u00ebrfundim: <b>mund t\u00eb nd\u00ebrtojm\u00eb nj\u00eb shp\u00ebrndarje t\u00eb vazhdueshme<\/b> vet\u00ebm me an\u00eb t\u00eb krijimit, nd\u00ebrrimit dhe fshirjes, 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 thelb, mundemi\u2026 P\u00ebr k\u00ebt\u00eb <b>do t\u00eb k\u00ebrkohet t\u00eb realizohet veprimi i bashkimit<\/b> t\u00eb manifeve dhe nj\u00eb lloj mb\u00ebshtetjeje q\u00eb:<\/p>\n<ul>\n<li> verifikon n\u00ebse objekti \u00ebsht\u00eb n\u00eb klaster,<\/li>\n<li> krijon burimin fillestar,<\/li>\n<li> e p\u00ebrdit\u00ebson ose e fshin.<\/li>\n<\/ul>\n<p>\nKur p\u00ebrdit\u00ebsohet, duhet pasur parasysh se <i>burimi mund t\u00eb ket\u00eb ndryshuar<\/i> q\u00eb nga hera e fundit <code>merr<\/code> dhe t\u00eb trajtoj\u00eb automatikisht rastin e nd\u00ebrprerjes optimiste \u2014 t\u00eb b\u00ebj\u00eb p\u00ebrpjekje t\u00eb p\u00ebrs\u00ebritura p\u00ebr p\u00ebrdit\u00ebsimin.<\/p>\n<p>Megjithat\u00eb, pse t\u00eb shpikim bi\u00e7iklet\u00ebn, kur kube-apiserver ofron nj\u00eb m\u00ebnyr\u00eb tjet\u00ebr p\u00ebr t\u00eb p\u00ebrdit\u00ebsuar burimet: veprimin <code>patch<\/code>, i cili heq nj\u00eb pjes\u00eb t\u00eb problemeve t\u00eb p\u00ebrshkruara nga p\u00ebrdoruesi?<\/p>\n<h3>Patch<\/h3>\n<p>\nJa erdh\u00ebm te patch-at.<\/p>\n<p>Patch-at jan\u00eb m\u00ebnyra kryesore p\u00ebr t\u00eb aplikuar ndryshime n\u00eb objektet ekzistuese n\u00eb Kubernetes. Veprimi <code>patch<\/code> punon n\u00eb at\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> dhe apiserver do ta kuptoj\u00eb vet\u00eb gjendjen aktuale t\u00eb objektit dhe do ta sjell\u00eb at\u00eb n\u00eb form\u00ebn e k\u00ebrkuar.<\/li>\n<\/ul>\n<p>\nNd\u00ebrprerja optimiste n\u00eb k\u00ebt\u00eb rast nuk \u00ebsht\u00eb e nevojshme. Kjo operacion \u00ebsht\u00eb m\u00eb deklarative n\u00eb krahasim me nd\u00ebrrimin, ndon\u00ebse fillimisht mund t\u00eb duket ndryshe.<\/p>\n<p>K\u00ebshtu:<\/p>\n<ul>\n<li> me an\u00eb t\u00eb veprimit <code>create<\/code> ne krijojm\u00eb objektin sipas manifestit nga Git\u2019i,<\/li>\n<li> n\u00ebp\u00ebrmjet <code>fshij<\/code> \u2014 e fshim\u00eb, n\u00ebse objekti nuk \u00ebsht\u00eb m\u00eb i nevojsh\u00ebm,<\/li>\n<li> n\u00ebp\u00ebrmjet <code>patch<\/code> \u2014 ne p\u00ebrdorim objektin, duke e sjell\u00eb at\u00eb n\u00eb form\u00ebn e p\u00ebrshkruar n\u00eb Git.<\/li>\n<\/ul>\n<p>\nMegjithat\u00eb, p\u00ebr ta b\u00ebr\u00eb k\u00ebt\u00eb, \u00ebsht\u00eb e nevojshme t\u00eb krijohet <i>patch-i i duhur<\/i>!<\/p>\n<h3>Si funksionojn\u00eb patch-et n\u00eb Helm 2: 2-way-merge<\/h3>\n<p>\nN\u00eb instalimin e par\u00eb t\u00eb l\u00ebshimit, Helm kryen operacionin <code>create<\/code> p\u00ebr burimet e chart-it.<\/p>\n<p>Duke p\u00ebrdit\u00ebsuar l\u00ebshimin e Helm, p\u00ebr secil\u00ebn burim:<\/p>\n<ul>\n<li> llogarit patch-in midis versionit t\u00eb burimit nga chart-i i kaluar dhe versionit aktual t\u00eb chart-it,<\/li>\n<li> e aplikon k\u00ebt\u00eb patch.<\/li>\n<\/ul>\n<p>\nK\u00ebt\u00eb patch do ta quajm\u00eb <b>2-way-merge patch<\/b>, sepse n\u00eb krijimin e tij p\u00ebrfshihen 2 manifestime:<\/p>\n<ul>\n<li> manifesti i burimit nga l\u00ebshimi i kaluar,<\/li>\n<li> manifesti i burimit nga burimi aktual.<\/li>\n<\/ul>\n<p>\nKur fshijm\u00eb, operacioni <code>fshij<\/code> n\u00eb kube apiserver thirret p\u00ebr burimet q\u00eb jan\u00eb shpallur n\u00eb l\u00ebshimin e kaluar, por nuk jan\u00eb shpallur n\u00eb at\u00eb aktual.<\/p>\n<p>Qasja me 2-way-merge patch ka nj\u00eb problem: ajo \u00e7on n\u00eb <b>disankronizimin e gjendjes reale t\u00eb burimit n\u00eb klaster dhe manifestin n\u00eb Git.<\/b>.<\/p>\n<h3>Ilustrimi i problemit me nj\u00eb shembull<\/h3>\n<p><\/p>\n<ul>\n<li> N\u00eb Git, n\u00eb chart ruhet nj\u00eb manifest, ku 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> ka ndryshuar vler\u00ebn e k\u00ebsaj fushe n\u00eb <code>ubuntu:19.04<\/code>.<\/li>\n<li> Kur rip\u00ebrdit\u00ebsohet chart-i i Helm <i>nuk gjeneron patch<\/i>, sepse fusha <code>image<\/code> n\u00eb versionin e kaluar t\u00eb l\u00ebshimit dhe n\u00eb chart-in aktual jan\u00eb t\u00eb nj\u00ebjta.<\/li>\n<li> Pas rip\u00ebrdit\u00ebsimit <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>\nKemi marr\u00eb disankronizim 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\u00ebrputhje t\u00eb plot\u00eb<\/i> e manifestit t\u00eb burimit n\u00eb klasterin n\u00eb funksion dhe manifestit nga Git nuk mund t\u00eb arrihet. Sepse n\u00eb manifestin real mund t\u00eb ket\u00eb annotime\/etiketa sh\u00ebrbimi, konteiner\u00eb t\u00eb shtuar dhe t\u00eb tjer\u00eb t\u00eb dh\u00ebna q\u00eb p\u00ebrfshihen dhe hiqen nga burimi dinamkisht nga disa kontroler\u00eb. Ne nuk mund dhe nuk duam t'i mbajm\u00eb k\u00ebto t\u00eb dh\u00ebna n\u00eb Git. Megjithat\u00eb, ne duam q\u00eb gjat\u00eb l\u00ebshimit fushat q\u00eb ne i kemi caktuar qart\u00eb n\u00eb Git t\u00eb pranoni vlerat p\u00ebrkat\u00ebse.<\/p>\n<p>K\u00ebshtu rezulton nj\u00eb rregull i p\u00ebrgjithsh\u00ebm <b>p\u00ebr burimin e sinkronizuar<\/b>: gjat\u00eb l\u00ebshimit t\u00eb burimit mund t\u00eb ndryshohen ose fshihen vet\u00ebm ato fusha q\u00eb jan\u00eb qart\u00eb t\u00eb shkruara n\u00eb manifestin nga Git (ose jan\u00eb shkruar n\u00eb versionin e kaluar dhe tani jan\u00eb fshir\u00eb).<\/p>\n<h3>3-way-merge patch<\/h3>\n<p>\nIdeja kryesore <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Merge_(version_control)#Three-way_merge\">3-way-merge patch<\/a><\/noindex>: gjenerojm\u00eb patch midis versionit m\u00eb 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 n\u00eb funksion. 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 shtuara n\u00eb versionin e synuar, shtohen me an\u00eb t\u00eb nj\u00eb patchi;<\/li>\n<li> Fushat ekzistuese n\u00eb versionin m\u00eb t\u00eb fundit t\u00eb aplikuar dhe q\u00eb nuk ekzistojn\u00eb n\u00eb at\u00eb t\u00eb synuar \u2014 zerohet me an\u00eb t\u00eb nj\u00eb patchi;<\/li>\n<li> Fushat n\u00eb versionin aktual t\u00eb objektit, t\u00eb cilat ndryshojn\u00eb nga versioni i synuar i manifestit, \u2014 p\u00ebrdit\u00ebsohen me an\u00eb t\u00eb nj\u00eb patchi.<\/li>\n<\/ul>\n<p>\nK\u00ebshtu krijohen patch-et <code>kubectl apply<\/code>:<\/p>\n<ul>\n<li> Versioni m\u00eb i fundit i aplikuar i manifestit ruhet n\u00eb annotimin e vet\u00eb objektit, <\/li>\n<li> i synuari \u2014 merret nga skedari YAML i caktuar,<\/li>\n<li> aktuali \u2014 nga klasteri n\u00eb pun\u00eb.<\/li>\n<\/ul>\n<p>\nTani q\u00eb e kuptuam teorin\u00eb, le t\u00eb flasim p\u00ebr at\u00eb q\u00eb kemi b\u00ebr\u00eb n\u00eb werf.<\/p>\n<h2>Aplikimi i ndryshimeve n\u00eb werf<\/h2>\n<p>\nM\u00eb par\u00eb werf, si dhe Helm 2, p\u00ebrdorte patch-e me 2-way-merge.<\/p>\n<h3>Repair patch<\/h3>\n<p>\nP\u00ebr t\u00eb kaluar n\u00eb llojin e ri t\u00eb patch-eve \u2014 3-way-merge, hapi i par\u00eb ishte t\u00eb prezantonim t\u00eb ashtuquajturat <b>repair-patch-e<\/b>.<\/p>\n<p>Gjat\u00eb deploy-it p\u00ebrdoret patch-i standard 2-way-merge, por werf gjeneron gjithashtu nj\u00eb patch t\u00eb till\u00eb, i cili do t\u00eb sinkronizonte gjendjen aktuale t\u00eb burimeve me at\u00eb q\u00eb shkruhet n\u00eb Git (krijohet nj\u00eb patch i till\u00eb duke p\u00ebrdorur t\u00eb nj\u00ebjtat rregulla p\u00ebr burimet e sinkronizuara, t\u00eb p\u00ebrshkruara m\u00eb sip\u00ebr).<\/p>\n<p>N\u00eb rastin e nj\u00eb rrethane t\u00eb sinkronizimit, n\u00eb fund t\u00eb deploy-it, p\u00ebrdoruesi merr nj\u00eb WARNIM me mesazhin p\u00ebrkat\u00ebs dhe patch-in q\u00eb duhet t\u00eb aplikoj\u00eb, p\u00ebr ta sjell\u00eb burimin n\u00eb nj\u00eb pamje 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 n\u00eb m\u00ebnyr\u00eb manuale <b>vet\u00eb<\/b> do ta aplikoj\u00eb k\u00ebt\u00eb patch: werf nuk do ta aplikoj\u00eb at\u00eb p\u00ebr parim.<\/p>\n<p>Gjenerimi i repair-patch-eve \u00ebsht\u00eb nj\u00eb mas\u00eb p\u00ebrkohore, e cila lejon t\u00eb testojm\u00eb n\u00eb praktik\u00eb krijimin e patch-eve sipas parimit 3-way-merge, por t\u00eb mos aplikojm\u00eb automatikisht k\u00ebto patch-e. Tani p\u00ebr tani, ky modalitet pune \u00ebsht\u00eb aktivizuar si parazgjedhje.<\/p>\n<h3>Patch 3-way-merge vet\u00ebm p\u00ebr l\u00ebshimet e reja<\/h3>\n<p>\nDuke filluar nga 1 dhjetori 2019, versionet beta dhe alpha t\u00eb werf fillojn\u00eb <b>si parazgjedhje<\/b> t\u00eb p\u00ebrdorin patch-e t\u00eb plota 3-way-merge p\u00ebr aplikimin e ndryshimeve vet\u00ebm p\u00ebr l\u00ebshimet e reja Helm, t\u00eb shp\u00ebrndara p\u00ebrmes werf. T\u00eb gjitha l\u00ebshimet ekzistuese do t\u00eb vazhdojn\u00eb t\u00eb p\u00ebrdorin qasjen 2-way-merge + repair-patch-e.<\/p>\n<p>Ky modalitet pune mund t\u00eb aktivizohet n\u00eb m\u00ebnyr\u00eb eksplicite me konfigurimin <code>WERF_THREE_WAY_MERGE_MODE=onlyNewReleases<\/code> tani.<\/p>\n<p><i><b>Sh\u00ebnim<\/b>: karakteristika u shfaq n\u00eb werf p\u00ebr disa l\u00ebshime: n\u00eb kanal alfa ajo u b\u00eb funksionale me versionin <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 \u2014 me <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 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 do t\u00eb p\u00ebrdorin automatikisht patch-e 3-way-merge p\u00ebr t\u00eb aplikuar ndryshime p\u00ebr t\u00eb gjitha versionet.<\/p>\n<p>Ky modalitet pune mund t\u00eb aktivizohet n\u00eb m\u00ebnyr\u00eb eksplicite me konfigurimin <code>WERF_THREE_WAY_MERGE_MODE=enabled<\/code> tani.<\/p>\n<h3>Si t\u00eb veprohet me autoskalimin e burimeve?<\/h3>\n<p>\nN\u00eb Kubernetes, ekzistojn\u00eb 2 lloje t\u00eb autoskalimit: HPA (horizontal) dhe VPA (vertikal).<\/p>\n<p>Horizontalja automatikisht zgjidh numrin e replikave, nd\u00ebrsa vertikalja - numrin e burimeve. Si numri i replikave, ashtu edhe k\u00ebrkesat p\u00ebr burime specifikohen n\u00eb manifestin e burimeve (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 konfiguron burimin n\u00eb chart n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb p\u00ebrfshij\u00eb vlera t\u00eb caktuara p\u00ebr burimet ose replikat dhe p\u00ebr k\u00ebt\u00eb burim aktivizohen autoskalera, at\u00ebher\u00eb gjat\u00eb \u00e7do depolimi werf do t\u00eb rikthej\u00eb k\u00ebto vlera n\u00eb at\u00eb q\u00eb \u00ebsht\u00eb regjistruar n\u00eb manifestin e chartit.<\/p>\n<p>Ka dy zgjidhje p\u00ebr k\u00ebt\u00eb problem. E para, m\u00eb e mira \u00ebsht\u00eb t\u00eb flitet p\u00ebr heqjen e qart\u00eb t\u00eb vlerave t\u00eb autoskalueshme n\u00eb manifestin e chartit. N\u00ebse kjo mund\u00ebsi p\u00ebr ndonj\u00eb arsye nuk \u00ebsht\u00eb e p\u00ebrshtatshme (p.sh., sepse n\u00eb chart \u00ebsht\u00eb e p\u00ebrshtatshme t\u00eb caktohen kufizime fillestare t\u00eb burimeve dhe numri i replikave), at\u00ebher\u00eb werf ofron k\u00ebto aneksime:<\/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 nj\u00eb aneksim t\u00eb till\u00eb, werf nuk do t\u00eb rikthej\u00eb vlerat p\u00ebrkat\u00ebse gjat\u00eb \u00e7do depolimi, por do t'i vendos\u00eb ato vet\u00ebm gjat\u00eb krijimit fillestar t\u00eb burimit.<\/p>\n<p>P\u00ebr m\u00eb shum\u00eb, 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 me 3-way-merge<\/h3>\n<p>\nP\u00ebrdoruesi p\u00ebr momentin mund t\u00eb ndaloj\u00eb 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 ky ndalim 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>Adoptoni burimet n\u00eb werf<\/h2>\n<p>\nNisja e metod\u00ebs s\u00eb aplikimit t\u00eb ndryshimeve me patch-e 3-way-merge na lejoi t\u00eb realizonim menj\u00ebher\u00eb nj\u00eb karakteristik\u00eb si adoptimi i burimeve ekzistuese n\u00eb klaster n\u00eb Helm-release.<\/p>\n<p>Helm 2 ka nj\u00eb problem: nuk mund t\u00eb shtohet n\u00eb manifestet e chart-it nj\u00eb burim q\u00eb tashm\u00eb ekziston n\u00eb klaster, pa e ri-krijuar at\u00eb 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 i m\u00ebsuam werf t\u00eb pranoj\u00eb burimet ekzistuese n\u00eb release. P\u00ebr k\u00ebt\u00eb, \u00ebsht\u00eb e nevojshme t\u00eb vendosni n\u00eb versionin aktual t\u00eb burimit nga klasteri i pun\u00ebs nj\u00eb aneksim (p.sh., n\u00ebp\u00ebrmjet <code>kubectl edit<\/code>):<\/p>\n<pre><code class=\"plaintext\">\"werf.io\/allow-adoption-by-release\": RELEASE_NAME<\/code><\/pre>\n<p>\nTani duhet t\u00eb p\u00ebrshkruhet n\u00eb chart dhe me radh\u00ebn tjet\u00ebr q\u00eb do t\u00eb deplojohet ndihm\u00ebsia me emrin e duhur, burimi ekzistues do t\u00eb pranohet n\u00eb k\u00ebt\u00eb ndihm\u00eb dhe do t\u00eb mbetet n\u00ebn menaxhimin e saj. M\u00eb shum\u00eb se kaq, gjat\u00eb procesit t\u00eb pranimit t\u00eb burimit n\u00eb ndihm\u00eb, werf do ta \u00e7oj\u00eb gjendjen aktuale t\u00eb burimit nga klasteri aktiv n\u00eb gjendjen e p\u00ebrshkruar n\u00eb chart, duke p\u00ebrdorur t\u00eb nj\u00ebjtat patch-e 3-way-merge dhe rregullin e burimit t\u00eb sinkronizuar.<\/p>\n<p><i><b>Sh\u00ebnim<\/b>: konfigurimi <code>WERF_THREE_WAY_MERGE_MODE<\/code> nuk ndikon n\u00eb pranimin e burimeve - n\u00eb rastin e pranimit gjithmon\u00eb p\u00ebrdoret patch-i 3-way-merge.<\/i><\/p>\n<p>Detajet - n\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/resources_update_methods_and_adoption.html#resources-adoption\">dokumentacionin<\/a><\/noindex>.<\/p>\n<h2>Konkluzionet dhe planet e ardhshme<\/h2>\n<p>\nShpresoj se pas k\u00ebtij artikulli \u00ebsht\u00eb b\u00ebr\u00eb m\u00eb e qart\u00eb se \u00e7far\u00eb jan\u00eb patch-e 3-way-merge dhe pse kemi arritur k\u00ebshtu. Nga nj\u00eb pik\u00ebpamje praktike p\u00ebr zhvillimin e projektit werf, realizimi i tyre ishte nj\u00eb hap tjet\u00ebr n\u00eb p\u00ebrmir\u00ebsimin e depolimit t\u00eb ngjash\u00ebm 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. Me k\u00ebt\u00eb, \u00ebsht\u00eb shtuar nj\u00eb funksionalitet i ri i dobish\u00ebm p\u00ebr pranimin e burimeve Kubernetes q\u00eb jan\u00eb shkarkuar tashm\u00eb n\u00eb Helm-n\u00eb.<\/p>\n<p>N\u00eb depolimin e ngjash\u00ebm me Helm, ende ka disa probleme dhe v\u00ebshtir\u00ebsi, si p\u00ebrdorimi i template-eve Go, dhe ne do t\u00eb vazhdojm\u00eb t'i zgjidhim ato.<\/p>\n<p>Informacionin mbi metodat e p\u00ebrdit\u00ebsimit t\u00eb burimeve dhe pranimin e tyre mund ta gjeni gjithashtu 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 i takon <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/news\/t\/475722\/\">n\u00eb daljen<\/a><\/noindex> t\u00eb nj\u00eb versioni t\u00eb ri t\u00eb madh Helm - v3, - i cili gjithashtu p\u00ebrdor patch-e 3-way-merge dhe heq Tillerin. Versioni i ri i Helm k\u00ebrkon <noindex><a rel=\"nofollow\" href=\"https:\/\/helm.sh\/docs\/topics\/v2_v3_migration\/\">migrazione<\/a><\/noindex> instalime ekzistuese p\u00ebr t'i konvertuar ato n\u00eb formatin e ri t\u00eb ruajtjes s\u00eb ndihmave.<\/p>\n<p>Werf nga ana e tij deri tani ka hequr dor\u00eb nga p\u00ebrdorimi i Tiller, \u00ebsht\u00eb kaluar 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 t\u00eb tjera<\/a><\/noindex>, duke mbetur k\u00ebshtu i p\u00ebrputhsh\u00ebm me instalimet ekzistuese n\u00eb Helm 2 (nuk ka nevoj\u00eb t\u00eb kryhen skriptet e migrimit). Pra, p\u00ebr sa koh\u00eb q\u00eb werf nuk \u00ebsht\u00eb kalim n\u00eb Helm 3, p\u00ebrdoruesit e werf nuk humbasin avantazhet kryesore t\u00eb Helm 3 p\u00ebrpara Helm 2 (ato jan\u00eb gjithashtu t\u00eb pranishme n\u00eb werf).<\/p>\n<p>Megjithat\u00eb, kalimi i werf n\u00eb baz\u00ebn e kodit t\u00eb Helm 3 \u00ebsht\u00eb i pashmangsh\u00ebm dhe do t\u00eb ndodh\u00eb n\u00eb t\u00eb ardhmen e af\u00ebrt. Pritet q\u00eb kjo t\u00eb jet\u00eb werf 1.1 ose werf 1.2 (n\u00eb k\u00ebt\u00eb moment, versioni kryesor i werf \u00ebsht\u00eb 1.0; m\u00eb shum\u00eb p\u00ebr struktur\u00ebn e versionimit 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 ket\u00eb koh\u00eb p\u00ebr t\u00eb stabilizuar.<\/p>\n<h2>P.S.<\/h2>\n<p>\nLexoni gjithashtu n\u00eb blogun ton\u00eb:<\/p>\n<ul>\n<li> Cikli i sh\u00ebnimeve t\u00eb rinovimeve 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 l\u00ebshimin e Helm-chart-eve komplekse<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465131\/\">Mb\u00ebshtetje p\u00ebr monorepo dhe multirepo n\u00eb werf dhe \u00e7far\u00eb lidhjeje ka kjo me Docker Registry<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/463613\/\">Tani mund t\u00eb nd\u00ebrtosh imazhe Docker n\u00eb werf edhe me 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 - mjeti yn\u00eb p\u00ebr CI\/CD n\u00eb Kubernetes (shqyrtim dhe video prezantimi)<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/469541\/\">Nd\u00ebrtesa dhe deployimi i mikrosh\u00ebrbimeve 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\/\">Hyrje n\u00eb 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.2 - 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.2\" \/>\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\udd47 Bashkimi 3-ve\u00e7 n\u00eb werf: implementimi n\u00eb Kubernetes me Helm \"n\u00eb steroide\" | ProHoster","description":"Ndodhi ajo q\u00eb ne (dhe jo vet\u00ebm ne) e kemi pritur p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb: werf, utilitari yn\u00eb Open Source p\u00ebr nd\u00ebrtimin e aplikacioneve dhe shp\u00ebrndarjen e tyre n\u00eb Kubernetes, tani mb\u00ebshtetet.","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}]}}