{"id":36754,"date":"2019-10-31T22:13:37","date_gmt":"2019-10-31T19:13:37","guid":{"rendered":"https:\/\/prohoster.info\/blog\/werf-nash-instrument-dlya-ci-cd-v-kubernetes-obzor-i-video-doklada\/"},"modified":"2019-10-31T22:13:37","modified_gmt":"2019-10-31T19:13:37","slug":"werf-nash-instrument-dlya-ci-cd-v-kubernetes-obzor-i-video-doklada","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/werf-nash-instrument-dlya-ci-cd-v-kubernetes-obzor-i-video-doklada","title":{"rendered":"werf \u2014 az eszk\u00f6z\u00fcnk CI\/CD-hez Kubernetes-ben (\u00e1ttekint\u00e9s \u00e9s a besz\u00e1mol\u00f3 vide\u00f3ja)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>2019. m\u00e1jus 27-\u00e9n, a DevOpsConf 2019 f\u0151term\u00e9ben, amely a fesztiv\u00e1l keretein bel\u00fcl zajlik, <noindex><a rel=\"nofollow\" href=\"http:\/\/ritfest.ru\/2019\/\">RIT++ 2019<\/a><\/noindex>, a \"Folyamatos sz\u00e1ll\u00edt\u00e1s\" szekci\u00f3 keret\u00e9ben elhangzott a \"werf \u2014 eszk\u00f6z\u00fcnk a CI\/CD sz\u00e1m\u00e1ra Kubernetesben\" c\u00edm\u0171 el\u0151ad\u00e1s. Ebben a <b>Kubernetesbe t\u00f6rt\u00e9n\u0151 telep\u00edt\u00e9sekkel kapcsolatos probl\u00e9m\u00e1kr\u00f3l \u00e9s kih\u00edv\u00e1sokr\u00f3l besz\u00e9l\u00fcnk,<\/b>valamint azokr\u00f3l a finoms\u00e1gokr\u00f3l, amelyek nem mindig nyilv\u00e1nval\u00f3ak. A lehets\u00e9ges megold\u00e1sok elemz\u00e9sekor megmutatjuk, hogyan val\u00f3sul meg ez az Open Source eszk\u00f6zben, <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">werf<\/a><\/noindex>.<\/p>\n<p>Az el\u0151ad\u00e1s \u00f3ta eszk\u00f6z\u00fcnk (kor\u00e1bban dapp n\u00e9ven ismert) \u00e1tt\u00f6rte a <b>1000 csillagot a GitHub-on,<\/b> \u00e9s rem\u00e9lj\u00fck, hogy a n\u00f6vekv\u0151 felhaszn\u00e1l\u00f3i k\u00f6z\u00f6ss\u00e9g sok DevOps m\u00e9rn\u00f6k \u00e9let\u00e9t megk\u00f6nny\u00edti.<\/p>\n<p><img decoding=\"async\" alt=\"werf \u2014 az eszk\u00f6z\u00fcnk CI\/CD-hez Kubernetes-ben (\u00e1ttekint\u00e9s \u00e9s a besz\u00e1mol\u00f3 vide\u00f3ja)\" src=\"\/wp-content\/uploads\/2019\/08\/c2d1ad5133c0de944b60ae37e3dbe598.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTeh\u00e1t bemutatjuk a <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=cK3ackGUTLw\"><b>vide\u00f3t az el\u0151ad\u00e1sr\u00f3l,<\/b><\/a><\/noindex> (kb. 47 perc, sokkal informat\u00edvabb, mint a cikk) \u00e9s a f\u0151bb \u00f6sszefoglal\u00f3t sz\u00f6veges form\u00e1ban. Induljon!<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>K\u00f3d sz\u00e1ll\u00edt\u00e1sa Kubernetesben<\/h2>\n<p>\nAz el\u0151ad\u00e1sban m\u00e1r nem a werf-r\u0151l lesz sz\u00f3, hanem a CI\/CD-r\u0151l Kubernetesben, felt\u00e9telezve, hogy szoftver\u00fcnk Docker kont\u00e9nerekbe van csomagolva. <i>(err\u0151l a <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/322686\/\">2016-os el\u0151ad\u00e1somban<\/a><\/noindex>)<\/i>besz\u00e9ltem, \u00e9s a K8s-t a produkci\u00f3s k\u00f6rnyezetben t\u00f6rt\u00e9n\u0151 futtat\u00e1s\u00e1hoz fogjuk haszn\u00e1lni, <i>(err\u0151l - a <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/331188\/\">2017-es \u00e9vben.<\/a><\/noindex>)<\/i>.<\/p>\n<p>Hogyan n\u00e9z ki a sz\u00e1ll\u00edt\u00e1s Kubernetesben?<\/p>\n<ul>\n<li> Van egy Git-t\u00e1rhely, amely tartalmazza a k\u00f3dot \u00e9s a build utas\u00edt\u00e1sokat. Az alkalmaz\u00e1s Docker k\u00e9pbe ker\u00fcl, \u00e9s k\u00f6zz\u00e9teszik a Docker Registry-n.<\/li>\n<li> Ugyanebben a t\u00e1rhelyben vannak utas\u00edt\u00e1sok arra is, hogyan lehet az alkalmaz\u00e1st telep\u00edteni \u00e9s elind\u00edtani. A telep\u00edt\u00e9si szakaszban ezek az utas\u00edt\u00e1sok a Kubernetesbe ker\u00fclnek, amely megkapja a sz\u00fcks\u00e9ges k\u00e9pet a registry-b\u0151l \u00e9s elind\u00edtja azt.<\/li>\n<li> Plusz \u00e1ltal\u00e1ban vannak tesztek. Ezek k\u00f6z\u00fcl n\u00e9h\u00e1nyat a k\u00e9p k\u00f6zz\u00e9t\u00e9telekor lehet v\u00e9grehajtani. Az (ugyanazon utas\u00edt\u00e1sok alapj\u00e1n) az alkalmaz\u00e1s egy p\u00e9ld\u00e1ny\u00e1t is telep\u00edthetj\u00fck (k\u00fcl\u00f6n n\u00e9vt\u00e9rben K8s-ben vagy k\u00fcl\u00f6n klaszterben), \u00e9s ott futtathatjuk a teszteket.<\/li>\n<li> V\u00e9gre is sz\u00fcks\u00e9g van egy CI-rendszerre, amely esem\u00e9nyeket kap a Gitb\u0151l (vagy gombnyom\u00e1sb\u00f3l) \u00e9s megh\u00edvja az \u00f6sszes kijel\u00f6lt szakaszt: build, publish, deploy, test.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"werf \u2014 az eszk\u00f6z\u00fcnk CI\/CD-hez Kubernetes-ben (\u00e1ttekint\u00e9s \u00e9s a besz\u00e1mol\u00f3 vide\u00f3ja)\" src=\"\/wp-content\/uploads\/2019\/08\/ec0d1fd1bf1a68cca92badf7cf1affe1.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nItt n\u00e9h\u00e1ny fontos megjegyz\u00e9s van:<\/p>\n<ol>\n<li> Mivel sz\u00e1munkra a megv\u00e1ltoztathatatlan infrastrukt\u00fara <i>(immutable infrastructure),<\/i>az alkalmaz\u00e1s k\u00e9pe, amit minden l\u00e9p\u00e9sben (staging, production stb.) haszn\u00e1lunk, <b>egys\u00e9ges kell legyen.<\/b>. <i>Err\u0151l r\u00e9szletesebben \u00e9s p\u00e9ld\u00e1kkal besz\u00e9ltem, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/324274\/\">itt<\/a><\/noindex>.<\/i><\/li>\n<li> Mivel k\u00f6vetj\u00fck az infrastrukt\u00fara mint k\u00f3d megk\u00f6zel\u00edt\u00e9st <i>(IaC),<\/i>az alkalmaz\u00e1s k\u00f3dj\u00e1t, a build \u00e9s futtat\u00e1si utas\u00edt\u00e1sokat <b>ugyanabban a repo-ban kell t\u00e1rolni.<\/b>. <i>Err\u0151l r\u00e9szletesebben l\u00e1sd a <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/324274\/\">ugyanazon el\u0151ad\u00e1sban.<\/a><\/noindex>.<\/i><\/li>\n<li> A sz\u00e1ll\u00edt\u00e1s l\u00e1nca <i>(delivery)<\/i> \u00c1ltal\u00e1ban \u00edgy l\u00e1tjuk: az alkalmaz\u00e1st \u00f6sszegy\u0171jt\u00f6tt\u00fck, tesztelt\u00fck, kiadtuk <i>(kiad\u00e1si szakasz)<\/i> \u00e9s ennyi \u2014 a sz\u00e1ll\u00edt\u00e1s megt\u00f6rt\u00e9nt. De val\u00f3j\u00e1ban a felhaszn\u00e1l\u00f3 azt kapja, amit kiadt\u00e1l, <b>nem<\/b> amikor azt a production k\u00f6rnyezetbe sz\u00e1ll\u00edtottad, \u00e9s amikor \u0151 hozz\u00e1f\u00e9rt \u00e9s ez a production m\u0171k\u00f6d\u00f6tt. Ez\u00e9rt azt gondolom, hogy a sz\u00e1ll\u00edt\u00e1si l\u00e1nc csak <b>az \u00fczemeltet\u00e9si szakaszban \u00e9r v\u00e9get<\/b> <i>(fut\u00e1s)<\/i>, s\u0151t, ha pontosabbak akarunk lenni, akkor abban a pillanatban, amikor a k\u00f3dot elt\u00e1vol\u00edtott\u00e1k a productionb\u00f3l (kicser\u00e9lve egy \u00fajra).<\/li>\n<\/ol>\n<p>\nVisszat\u00e9rve a fent eml\u00edtett sz\u00e1ll\u00edt\u00e1si s\u00e9m\u00e1ra Kubernetesben: ezt nemcsak mi tal\u00e1ltuk ki, hanem gyakorlatilag mindenki, aki foglalkozott ezzel a probl\u00e9m\u00e1val. Tulajdonk\u00e9ppen ezt a mint\u00e1t most GitOps-nak nevezik <i>(t\u00f6bb inform\u00e1ci\u00f3t a kifejez\u00e9sr\u0151l \u00e9s az azt k\u00f6r\u00fclvev\u0151 \u00f6tletekr\u0151l itt olvashatsz <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/458878\/\">itt<\/a><\/noindex>)<\/i>. N\u00e9zz\u00fck meg a s\u00e9m\u00e1k l\u00e9p\u00e9seit.<\/p>\n<h2>\u00d6sszegy\u0171jt\u00e9si szakasz<\/h2>\n<p>\n\u00dagy t\u0171nik, hogy mit lehet mondani 2019-ben a Docker-k\u00e9pek \u00f6ssze\u00e1ll\u00edt\u00e1s\u00e1r\u00f3l, amikor mindenki tud Dockerfile-t \u00edrni \u00e9s futtatni. <code>docker build<\/code>?.. \u0412\u043e\u0442 \u043d\u044e\u0430\u043d\u0441\u044b, \u043d\u0430 \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0445\u043e\u0442\u0435\u043b\u043e\u0441\u044c \u0431\u044b \u043e\u0431\u0440\u0430\u0442\u0438\u0442\u044c \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u0435:<\/p>\n<ol>\n<li> <b>A k\u00e9p m\u00e9rete<\/b> fontos, ez\u00e9rt haszn\u00e1lj <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.docker.com\/develop\/develop-images\/multistage-build\/\">multi-stage<\/a><\/noindex>, hogy csak a sz\u00fcks\u00e9ges dolgokat hagyd a k\u00e9pen az alkalmaz\u00e1s m\u0171k\u00f6d\u00e9s\u00e9hez.<\/li>\n<li> <b>A r\u00e9tegek sz\u00e1m\u00e1t<\/b> minimaliz\u00e1lni kell, egym\u00e1ssal \u00f6sszef\u00fcgg\u0151 parancsok l\u00e1ncol\u00e1s\u00e1val. <code>RUN<\/code>-ban.<\/li>\n<li> Ez azonban \u00faj probl\u00e9m\u00e1kat gener\u00e1l <b>a hibakeres\u00e9s sor\u00e1n<\/b>, mert hiba eset\u00e9n meg kell keresni azt a parancsot a l\u00e1ncban, amelyik a probl\u00e9m\u00e1t okozta.<\/li>\n<li> <b>Az \u00f6sszegy\u0171jt\u00e9s sebess\u00e9ge<\/b> fontos, mert gyorsan szeretn\u00e9nk kiadni a v\u00e1ltoztat\u00e1sokat \u00e9s l\u00e1tni az eredm\u00e9nyt. P\u00e9ld\u00e1ul nem szeretn\u00e9nk minden alkalmaz\u00e1s\u00e9p\u00edt\u00e9sn\u00e9l \u00e1tkonfigur\u00e1lni a k\u00f6nyvt\u00e1rak f\u00fcgg\u0151s\u00e9geit.<\/li>\n<li> Gyakran egy Git-reposit\u00f3riumb\u00f3l <b>sok k\u00e9p sz\u00fcks\u00e9ges<\/b>, amit egy Dockerfile-okb\u00f3l (vagy egy f\u00e1jlban l\u00e9v\u0151 nevezett szakaszokb\u00f3l) \u00e9s egy Bash-skripttel a sorozatos \u00f6ssze\u00e1ll\u00edt\u00e1shoz lehet megoldani.<\/li>\n<\/ol>\n<p>\nEz csak a j\u00e9ghegy cs\u00facsa, amellyel mindenki tal\u00e1lkozik. De vannak m\u00e1s probl\u00e9m\u00e1k is, k\u00fcl\u00f6n\u00f6sen:<\/p>\n<ol>\n<li> Gyakran az \u00f6sszegy\u0171jt\u00e9si szakaszban sz\u00fcks\u00e9g\u00fcnk van valamire <b>csatol\u00e1sra<\/b> (p\u00e9ld\u00e1ul a apt parancs eredm\u00e9ny\u00e9nek gyors\u00edt\u00f3t\u00e1raz\u00e1sa egy k\u00fcls\u0151 k\u00f6nyvt\u00e1rba).<\/li>\n<li> Azt szeretn\u00e9nk, hogy <b>Ansible<\/b> ahelyett, hogy shell-ben \u00edrn\u00e1nk.<\/li>\n<li> Azt szeretn\u00e9nk, hogy <b>n\u00e9lk\u00fcl \u00e9p\u00edteni Dockerrel<\/b> (mi\u00e9rt lenne sz\u00fcks\u00e9g\u00fcnk egy plusz virtu\u00e1lis g\u00e9pre, amit mindennek be kell \u00e1ll\u00edtani, amikor m\u00e1r l\u00e9tezik egy Kubernetes klaszter, amiben t\u00e1rol\u00f3kat futtathatunk?).<\/li>\n<li> <b>P\u00e1rhuzamos \u00e9p\u00edt\u00e9s<\/b>, amit k\u00fcl\u00f6nb\u00f6z\u0151k\u00e9ppen lehet \u00e9rteni: k\u00fcl\u00f6nb\u00f6z\u0151 parancsok Dockerfile-b\u00f3l (ha multi-stage-t haszn\u00e1lnak), t\u00f6bb commit az egyetlen t\u00e1rol\u00f3b\u00f3l, t\u00f6bb Dockerfile.<\/li>\n<li> <b>Elosztott build<\/b>: mi szeretn\u00e9nk valamit \u00f6ssze\u00e1ll\u00edtani pod-okban, amelyek \u201eefemerek\u201d, mivel elveszik a cache, \u00edgy ezt k\u00fcl\u00f6n kell t\u00e1rolni.<\/li>\n<li> V\u00e9g\u00fcl a k\u00edv\u00e1ns\u00e1gok cs\u00facs\u00e1t megneveztem <b>autom\u00e1gi\u00e1nak<\/b>: t\u00f6k\u00e9letes lenne bel\u00e9pni a repozit\u00f3rium\u00e1ba, be\u00edrni egy parancsot, \u00e9s megkapni a k\u00e9sz k\u00e9pet, amelyet \u00fagy \u00e1ll\u00edtottak \u00f6ssze, hogy tudja, hogyan \u00e9s mit kell helyesen csin\u00e1lni. Azonban szem\u00e9ly szerint nem vagyok biztos abban, hogy minden \u00e1rnyalatot \u00edgy le lehet fedni.<\/li>\n<\/ol>\n<p>\n\u00c9s itt vannak a projektek:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/moby\/buildkit\">moby\/buildkit<\/a><\/noindex> \u2014 a Docker Inc. buildere (m\u00e1r integr\u00e1lva a legfrissebb Docker verzi\u00f3kba), amely pr\u00f3b\u00e1lja megoldani ezeket a probl\u00e9m\u00e1kat;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/GoogleContainerTools\/kaniko\">kaniko<\/a><\/noindex> \u2014 a Google buildere, amely lehet\u0151v\u00e9 teszi a buildel\u00e9st Docker n\u00e9lk\u00fcl;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/buildpacks.io\/\">Buildpacks.io<\/a><\/noindex> \u2014 a CNCF k\u00eds\u00e9rlete az autom\u00e1gi\u00e1val, k\u00fcl\u00f6n\u00f6sen egy \u00e9rdekes megold\u00e1s a layer rebase-hez;<\/li>\n<li> \u00e9s m\u00e9g sok m\u00e1s hasznos eszk\u00f6z, mint p\u00e9ld\u00e1ul <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/containers\/buildah\">buildah<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/genuinetools\/img\">genuinetools\/img<\/a><\/noindex>\u2026<\/li>\n<\/ul>\n<p>\n\u2026 \u00e9s n\u00e9zd meg, h\u00e1ny csillagjuk van GitHub-on. Teh\u00e1t, egyr\u00e9szt, <code>docker build<\/code> van, \u00e9s tud valamit csin\u00e1lni, de a val\u00f3s\u00e1gban <b>a k\u00e9rd\u00e9s nem megoldott teljesen<\/b> \u2014 ezt bizony\u00edtja a p\u00e1rhuzamosan fejl\u0151d\u0151 alternat\u00edv builderek l\u00e9tez\u00e9se, amelyek mindegyike egy bizonyos r\u00e9sz\u00e9t pr\u00f3b\u00e1lja megoldani a probl\u00e9m\u00e1knak.<\/p>\n<h2>Buildel\u00e9s a werf-ben<\/h2>\n<p>\n\u00cdgy eljutottunk <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">werf<\/a><\/noindex> <i>(kor\u00e1bban <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/333682\/\">h\u00edres<\/a><\/noindex> mint dapp)<\/i> \u2014 a Flant c\u00e9g Open Source eszk\u00f6ze, amelyet m\u00e1r sok \u00e9ve fejleszt\u00fcnk. \u00d6t \u00e9vvel ezel\u0151tt kezd\u0151d\u00f6tt Bash-skriptek k\u00e9sz\u00edt\u00e9s\u00e9vel, amelyek optimaliz\u00e1lt\u00e1k a Dockerfile-k \u00f6ssze\u00e1ll\u00edt\u00e1s\u00e1t, az utols\u00f3 h\u00e1rom \u00e9ve pedig egy teljes projekt keretein bel\u00fcl zajlik, saj\u00e1t Git-t\u00e1rol\u00f3val. <i>(el\u0151sz\u00f6r Ruby-ban, majd <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/437044\/\">\u00e1t\u00edrtuk<\/a><\/noindex> Go-ra, \u00e9s egy\u00fattal \u00e1tnevezt\u00fck)<\/i>. Milyen buildel\u00e9si k\u00e9rd\u00e9seket old meg a werf?<\/p>\n<p><img decoding=\"async\" alt=\"werf \u2014 az eszk\u00f6z\u00fcnk CI\/CD-hez Kubernetes-ben (\u00e1ttekint\u00e9s \u00e9s a besz\u00e1mol\u00f3 vide\u00f3ja)\" src=\"\/wp-content\/uploads\/2019\/08\/ab6aa8831b49977a419fd4cc3543eb83.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA k\u00e9kkel jel\u00f6lt probl\u00e9m\u00e1k m\u00e1r megval\u00f3sultak, a p\u00e1rhuzamos build egy hoszton bel\u00fcl megval\u00f3sult, a s\u00e1rg\u00e1val kiemelt k\u00e9rd\u00e9seket pedig a ny\u00e1r v\u00e9g\u00e9re tervezz\u00fck befejezni.<\/p>\n<h2>Registry-be val\u00f3 publik\u00e1l\u00e1s szakasza<\/h2>\n<p>\nMegadtuk <code>docker push<\/code>\u2026 \u2014 mi lehet olyan bonyolult abban, hogy felt\u00f6lts\u00fck a k\u00e9pet a registry-be? \u00c9s itt felmer\u00fcl a k\u00e9rd\u00e9s: \u201eMilyen c\u00edmk\u00e9t adjunk a k\u00e9pnek?\u201d Ez a k\u00e9rd\u00e9s abb\u00f3l fakad, hogy van nek\u00fcnk <b>Gitflow<\/b> (vagy m\u00e1sik Git-strat\u00e9gia) \u00e9s Kubernetes, \u00e9s az ipar arra t\u00f6rekszik, hogy ami a Kubernetesben t\u00f6rt\u00e9nik, k\u00f6vesse azt, ami a Git-ben t\u00f6rt\u00e9nik. Mert a Git az egyetlen igaz forr\u00e1sunk.<\/p>\n<p>Mi ebben a neh\u00e9z? <b>A reproduk\u00e1lhat\u00f3s\u00e1g garant\u00e1l\u00e1sa<\/b>: a GIT commit, which is inherently immutable <i>(immutable)<\/i>, to a Docker image that must be preserved in the same way.<\/p>\n<p>It is also important for us <b>to determine the origin<\/b>, mert szeretn\u00e9nk \u00e9rteni, hogy melyik committal k\u00e9sz\u00fclt a Kubernetesben fut\u00f3 alkalmaz\u00e1s (akkor tudunk diffeket csin\u00e1lni \u00e9s hasonl\u00f3 dolgokat).<\/p>\n<h3>Tagging Strategies<\/h3>\n<p>\nThe first is a simple <b>git tag<\/b>. We have a registry with an image tagged as <code>1.0<\/code>. In Kubernetes there is a stage and production where this image is deployed. In Git we make commits and at some point we put a tag <code>2.0<\/code>. We build it according to the instructions from the repository and place it in the registry with the tag <code>2.0<\/code>. We roll it out to stage and, if everything is fine, then to production.<\/p>\n<p><img decoding=\"async\" alt=\"werf \u2014 az eszk\u00f6z\u00fcnk CI\/CD-hez Kubernetes-ben (\u00e1ttekint\u00e9s \u00e9s a besz\u00e1mol\u00f3 vide\u00f3ja)\" src=\"\/wp-content\/uploads\/2019\/08\/8545b84bfa63a91773f0d7dc1c2bd49f.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nThe problem with this approach is that we tagged first, and only then tested and rolled out. Why? First, it is just illogical: we issue a version of the software that we haven\u2019t even checked yet (we can\u2019t do otherwise, as a tag needs to be applied to verify). Second, this approach doesn\u2019t align with Gitflow.<\/p>\n<p>The second option is <b>git commit + tag<\/b>. In the master branch there is a tag <code>1.0<\/code>; for it in the registry is the image deployed in production. In addition, there are preview and staging environments in the Kubernetes cluster. Then we follow Gitflow: in the main branch for development (<code>develop<\/code>) we create new features, resulting in a commit with the ID <code>#c1<\/code>. We build it and publish it in the registry using this ID (<code>#c1<\/code>). With the same ID we roll it out to preview. Similarly, we do with the commits <code>#c2<\/code> \u00e9s <code>#c3<\/code>.<\/p>\n<p>Once we understand that there are enough features, we start stabilizing everything. In Git, we create a branch <code>release_1.1<\/code> (based on <code>#c3<\/code> a <code>develop<\/code>). This release doesn\u2019t need to be built, as it was done in the previous step. Therefore, we can just roll it out to staging. We fix bugs in <code>#c4<\/code> and similarly roll it out to staging. Meanwhile, development is taking place in <code>develop<\/code>, where changes from <code>release_1.1<\/code>are periodically merged. At some point, we obtain a built and deployed commit on staging that we are satisfied with (<code>#c25<\/code>).<\/p>\n<p>Akkor csin\u00e1lunk egy merge-t (fast-forward-dal) a release \u00e1gb\u00f3l (<code>release_1.1<\/code>) into master. We put a tag with the new version on this commit (<code>1.1<\/code>). But this image has already been built in the registry, so to avoid building it again, we simply add a second tag to the existing image (now it has tags <code>#c25<\/code> \u00e9s <code>1.1<\/code>). After this, we roll it out to production.<\/p>\n<p>There is a downside that one image is deployed on staging (<code>#c25<\/code>), while production has another one (<code>1.1<\/code>), de tudjuk, hogy fizikailag ez ugyanaz a k\u00e9p a registryb\u0151l.<\/p>\n<p><img decoding=\"async\" alt=\"werf \u2014 az eszk\u00f6z\u00fcnk CI\/CD-hez Kubernetes-ben (\u00e1ttekint\u00e9s \u00e9s a besz\u00e1mol\u00f3 vide\u00f3ja)\" src=\"\/wp-content\/uploads\/2019\/08\/b3fa2c34442aa401d1e7b30eb593be9a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA t\u00e9nyleg h\u00e1tr\u00e1ny az, hogy nincs t\u00e1mogat\u00e1s a merge commit-okhoz, csak fast-forwardot kell csin\u00e1lni.<\/p>\n<p>Elmehet\u00fcnk tov\u00e1bb, \u00e9s megcsin\u00e1lhatunk egy tr\u00fckk\u00f6t\u2026 N\u00e9zz\u00fcnk meg egy egyszer\u0171 Dockerfile-t:<\/p>\n<pre><code class=\"plaintext\">FROM ruby:2.3 as assets\nRUN mkdir -p \/app\nWORKDIR \/app\nCOPY . .\/\nRUN gem install bundler &amp;&amp; bundle install\nRUN bundle exec rake assets:precompile\nCMD bundle exec puma -C config\/puma.rb\n\nFROM nginx:alpine\nCOPY --from=assets \/app\/public \/usr\/share\/nginx\/www\/public<\/code><\/pre>\n<p>\nL\u00e9trehozunk egy f\u00e1jlt az al\u00e1bbi elv alapj\u00e1n, hogy vesz\u00fcnk:<\/p>\n<ul>\n<li> SHA256-ot az haszn\u00e1lt k\u00e9pek azonos\u00edt\u00f3ib\u00f3l (<code>ruby:2.3<\/code> \u00e9s <code>nginx:alpine<\/code>), amelyek az tartalom ellen\u0151rz\u0151 \u00f6sszegei;<\/li>\n<li> minden parancs (<code>RUN<\/code>, <code>CMD<\/code> igazs\u00e1g szerint.<\/li>\n<li> SHA256-ot a hozz\u00e1adott f\u00e1jlokr\u00f3l.<\/li>\n<\/ul>\n<p>\n\u2026 \u00e9s vegy\u00fck az ellen\u0151rz\u0151 \u00f6sszeget (ism\u00e9t SHA256) err\u0151l a f\u00e1jlr\u00f3l. Ez egy <b>al\u00e1\u00edr\u00e1s<\/b> minden, ami a Docker-k\u00e9p tartalm\u00e1t meghat\u00e1rozza.<\/p>\n<p><img decoding=\"async\" alt=\"werf \u2014 az eszk\u00f6z\u00fcnk CI\/CD-hez Kubernetes-ben (\u00e1ttekint\u00e9s \u00e9s a besz\u00e1mol\u00f3 vide\u00f3ja)\" src=\"\/wp-content\/uploads\/2019\/08\/b2af0b7952eefe26ddbb145955e778e8.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nT\u00e9rj\u00fcnk vissza a s\u00e9m\u00e1hoz, \u00e9s <b>a commitok helyett haszn\u00e1ljunk ilyen al\u00e1\u00edr\u00e1sokat,<\/b>, azaz az al\u00e1\u00edr\u00e1sokkal c\u00edmk\u00e9zz\u00fck a k\u00e9peket.<\/p>\n<p><img decoding=\"async\" alt=\"werf \u2014 az eszk\u00f6z\u00fcnk CI\/CD-hez Kubernetes-ben (\u00e1ttekint\u00e9s \u00e9s a besz\u00e1mol\u00f3 vide\u00f3ja)\" src=\"\/wp-content\/uploads\/2019\/08\/115f290bd5951614c041b3d510fae38e.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMost, amikor p\u00e9ld\u00e1ul \u00f6ssze kell vonnunk a v\u00e1ltoztat\u00e1sokat a release-b\u0151l a master-be, tudunk igazi merge commit-ot csin\u00e1lni: m\u00e1s az azonos\u00edt\u00f3ja, de ugyanaz a jel.<\/p>\n<p>A h\u00e1tr\u00e1nya, hogy most m\u00e1r nem tudjuk meghat\u00e1rozni, hogy melyik commit ker\u00fclt a production-ra \u2014 az ellen\u0151rz\u0151 \u00f6sszegek csak egy ir\u00e1nyba m\u0171k\u00f6dnek. Ezt a probl\u00e9m\u00e1t egy kieg\u00e9sz\u00edt\u0151 r\u00e9teggel oldjuk meg metadat\u00e1kkal \u2014 err\u0151l k\u00e9s\u0151bb r\u00e9szletesebben besz\u00e9lek.<\/p>\n<h3>C\u00edmk\u00e9z\u00e9s a werf-ben<\/h3>\n<p>\nA werf-ben m\u00e9g tov\u00e1bb ment\u00fcnk, \u00e9s k\u00e9sz\u00fcl\u00fcnk egy elosztott \u00e9p\u00edt\u00e9sre \u00fagy, hogy a cache nem egy g\u00e9pen t\u00e1rol\u00f3dik\u2026 Teh\u00e1t, k\u00e9tf\u00e9le Docker-k\u00e9pet k\u00e9sz\u00edt\u00fcnk, amelyeket <i>stage<\/i> \u00e9s <i>k\u00e9p<\/i>.<\/p>\n<p>A werf Git-t\u00e1rol\u00f3j\u00e1ban specifikus \u00e9p\u00edt\u00e9si utas\u00edt\u00e1sok tal\u00e1lhat\u00f3k, amelyek a k\u00fcl\u00f6nb\u00f6z\u0151 \u00e9p\u00edt\u00e9si l\u00e9p\u00e9seket \u00edrj\u00e1k le (<i>beforeInstall<\/i>, <i>install<\/i>, <i>beforeSetup<\/i>, <i>setup<\/i>). Az els\u0151 stage-k\u00e9pet azzal az al\u00e1\u00edr\u00e1ssal k\u00e9sz\u00edtj\u00fck el, amelyet az els\u0151 l\u00e9p\u00e9sek ellen\u0151rz\u0151 \u00f6sszegek\u00e9nt hat\u00e1rozunk meg. Ezut\u00e1n hozz\u00e1adjuk a forr\u00e1st, az \u00faj stage-k\u00e9phez kisz\u00e1m\u00edtjuk a kontrollt\u2026 Ezek a m\u0171veletek minden egyes l\u00e9p\u00e9sn\u00e9l megism\u00e9tl\u0151dnek, aminek eredm\u00e9nyek\u00e9nt egy stage-k\u00e9pekb\u0151l \u00e1ll\u00f3 halmazt kapunk. Ezut\u00e1n l\u00e9trehozzuk az utols\u00f3 image-k\u00e9pet, amely tartalmazza az eredet\u00e9r\u0151l sz\u00f3l\u00f3 metadat\u00e1kat is. Ezt a k\u00e9pet k\u00fcl\u00f6nb\u00f6z\u0151 m\u00f3dokon c\u00edmk\u00e9zz\u00fck (r\u00e9szletek k\u00e9s\u0151bb).<\/p>\n<p><img decoding=\"async\" alt=\"werf \u2014 az eszk\u00f6z\u00fcnk CI\/CD-hez Kubernetes-ben (\u00e1ttekint\u00e9s \u00e9s a besz\u00e1mol\u00f3 vide\u00f3ja)\" src=\"\/wp-content\/uploads\/2019\/08\/22df8b6347b45be19ecb889c102b92b5.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHadd el j\u00f6n egy \u00faj commit, amelyben csak az alkalmaz\u00e1s k\u00f3dj\u00e1t m\u00f3dos\u00edtott\u00e1k. Mi t\u00f6rt\u00e9nik? A k\u00f3dm\u00f3dos\u00edt\u00e1sokhoz patch k\u00e9sz\u00fcl, amihez \u00faj stage-image j\u00f6n l\u00e9tre. Ennek az al\u00e1\u00edr\u00e1sa az old\u00f3szer k\u00e9p (stage-image) r\u00e9gi ellen\u0151rz\u0151\u00f6sszeg \u00e9s az \u00faj patch ellen\u0151rz\u0151\u00f6sszeg\u00e9nek \u00f6sszegz\u00e9s\u00e9re lesz meghat\u00e1rozva. Ebb\u0151l az image-b\u0151l fog form\u00e1l\u00f3dni az \u00faj v\u00e9gs\u0151 image.<\/p>\n<p>\u00cdgy a stage-images olyan cache, amelyet elosztva lehet t\u00e1rolni, \u00e9s az abb\u00f3l l\u00e9trej\u00f6v\u0151 image-ek a Docker Registry-be ker\u00fclnek.<\/p>\n<p><img decoding=\"async\" alt=\"werf \u2014 az eszk\u00f6z\u00fcnk CI\/CD-hez Kubernetes-ben (\u00e1ttekint\u00e9s \u00e9s a besz\u00e1mol\u00f3 vide\u00f3ja)\" src=\"\/wp-content\/uploads\/2019\/08\/35805eca81605bd64c6910b7965b567e.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>A registry tiszt\u00edt\u00e1sa<\/h3>\n<p>\nNem a r\u00e9gi tagek ut\u00e1n megmaradt r\u00e9tegek elt\u00e1vol\u00edt\u00e1s\u00e1r\u00f3l van sz\u00f3 \u2014 ez a Docker Registry alap\u00e9rtelmezett k\u00e9pess\u00e9ge. Azzal a helyzettel fogunk foglalkozni, amikor rengeteg Docker-taget halmozunk fel, \u00e9s felmer\u00fcl, hogy ezek egy r\u00e9sze m\u00e1r nem sz\u00fcks\u00e9ges, \u00e9s helyet foglal (\u00e9s\/vagy ez\u00e9rt fizet\u00fcnk).<\/p>\n<p>Milyen tiszt\u00edt\u00e1si strat\u00e9gi\u00e1k l\u00e9teznek?<\/p>\n<ol>\n<li> Egyszer\u0171en nem csin\u00e1lni semmit <b>nem tiszt\u00edtani<\/b>. N\u00e9ha val\u00f3ban egyszer\u0171bb egy kicsit t\u00f6bbet fizetni a felesleges hely\u00e9rt, mint kibogozni egy hatalmas gubancot a tagekb\u0151l. De ez csak egy bizonyos pontig m\u0171k\u00f6dik.<\/li>\n<li> <b>Teljes reset<\/b>. Ha minden k\u00e9pet t\u00f6rl\u00fcnk, \u00e9s csak az aktu\u00e1lisakat \u00e9p\u00edtj\u00fck \u00fajra a CI-rendszerben, akkor probl\u00e9m\u00e1k mer\u00fclhetnek fel. Ha a production-on \u00fajraindul egy kont\u00e9ner, akkor \u00faj k\u00e9p fog bet\u00f6lt\u0151dni, amelyet m\u00e9g senki sem tesztelt. Ez meg\u00f6li az immutable infrastructure \u00f6tlet\u00e9t.<\/li>\n<li> <b>Blue-green<\/b>. Ha az egyik registry kezd megtelni \u2014 k\u00e9peket t\u00f6lt\u00fcnk fel a m\u00e1sikba. Ugyanez a probl\u00e9ma a kor\u00e1bbi m\u00f3dszerrel: mikor tiszt\u00edthatjuk meg a registry-t, ami megtelt?<\/li>\n<li> <b>Id\u0151ben<\/b>. T\u00f6r\u00f6lj\u00fck az \u00f6sszes 1 h\u00f3napn\u00e1l r\u00e9gebbi k\u00e9pet? De biztosan lesz egy szolg\u00e1ltat\u00e1s, ami m\u00e1r egy h\u00f3napja nem friss\u00fclt...<\/li>\n<li> <b>K\u00e9zi<\/b> meghat\u00e1rozni, mi az, ami m\u00e1r elt\u00e1vol\u00edthat\u00f3.<\/li>\n<\/ol>\n<p>\nVal\u00f3j\u00e1ban k\u00e9t \u00e9letk\u00e9pes opci\u00f3 van: nem takar\u00edtani vagy egy kombin\u00e1ci\u00f3 a blue-green + manu\u00e1lis. Az ut\u00f3bbin\u00e1l arr\u00f3l van sz\u00f3, hogy amikor tudod, hogy itt az ideje a registry takar\u00edt\u00e1s\u00e1nak, l\u00e9trehozol egy \u00fajat, \u00e9s az \u00f6sszes \u00faj k\u00e9pet arra adod hozz\u00e1, p\u00e9ld\u00e1ul egy h\u00f3napon kereszt\u00fcl. Egy h\u00f3nap m\u00falva megn\u00e9zed, hogy mely pod-ok haszn\u00e1lj\u00e1k m\u00e9g az \u00f6reg registry-t a Kubernetesben, \u00e9s azokat is \u00e1thelyezed az \u00faj registry-be.<\/p>\n<p>Hova jutottunk <b>werf<\/b>? \u041c\u044b \u0441\u043e\u0431\u0438\u0440\u0430\u0435\u043c:<\/p>\n<ol>\n<li> Git fej: minden c\u00edmke, minden \u00e1g \u2013 felt\u00e9telezve, hogy mindent, ami Gitben c\u00edmk\u00e9zve van, sz\u00fcks\u00e9g\u00fcnk van az image-eken is (ha nem, akkor azt a Git-ben kell elt\u00e1vol\u00edtani);<\/li>\n<li> minden pod, amely jelenleg let\u00f6lt\u00e9sre ker\u00fclt a Kubernetesben;<\/li>\n<li> r\u00e9gi ReplicaSet-ek (amik nemr\u00e9g lettek let\u00f6ltve), \u00e9s tervezz\u00fck, hogy beolvassuk a Helm kiad\u00e1sokat, hogy kiv\u00e1lasszuk a legfrissebb image-eket ott.<\/li>\n<\/ol>\n<p>\n\u2026 \u00e9s ebb\u0151l a k\u00e9szletb\u0151l whitelistet k\u00e9sz\u00edt\u00fcnk - azoknak a k\u00e9peknek a list\u00e1ja, amelyeket nem fogunk t\u00f6r\u00f6lni. Minden m\u00e1s, amely nem szerepel a list\u00e1ban, t\u00f6rl\u00e9sre ker\u00fcl, majd megtal\u00e1ljuk az \u00e1rv\u00e1n maradt stage-k\u00e9peket \u00e9s azokat is elt\u00e1vol\u00edtjuk.<\/p>\n<h2>Kibocs\u00e1t\u00e1si szakasz (deploy)<\/h2>\n<p><\/p>\n<h3>Megb\u00edzhat\u00f3 deklarativit\u00e1s<\/h3>\n<p>\nAz els\u0151 dolog, amit figyelembe kell venni a kibocs\u00e1t\u00e1s sor\u00e1n, az a friss\u00edtett er\u0151forr\u00e1s-konfigur\u00e1ci\u00f3 kiad\u00e1sa, amelyet deklarat\u00edvan hirdetnek. Az eredeti YAML-dokumentum, amely a Kubernetes-er\u0151forr\u00e1sokat \u00edrja le, mindig jelent\u0151sen elt\u00e9r a klaszterben val\u00f3 t\u00e9nyleges m\u0171k\u00f6d\u00e9st\u0151l. Mivel a Kubernetes hozz\u00e1ad a konfigur\u00e1ci\u00f3hoz:<\/p>\n<ol>\n<li> azonos\u00edt\u00f3k;<\/li>\n<li> seg\u00e9dinform\u00e1ci\u00f3k;<\/li>\n<li> sz\u00e1mos alap\u00e9rtelmezett \u00e9rt\u00e9k;<\/li>\n<li> szakasz a jelenlegi st\u00e1tuszr\u00f3l;<\/li>\n<li> v\u00e1ltoztat\u00e1sok, amelyeket az admission webhook haszn\u00e1latakor hajtottak v\u00e9gre;<\/li>\n<li> k\u00fcl\u00f6nb\u00f6z\u0151 vez\u00e9rl\u0151k (\u00e9s \u00fctemez\u0151k) munk\u00e1j\u00e1nak eredm\u00e9nye.<\/li>\n<\/ol>\n<p>\nEz\u00e9rt, amikor \u00faj er\u0151forr\u00e1s-konfigur\u00e1ci\u00f3 jelenik meg (<i>new<\/i>), nem tudjuk egyszer\u0171en fel\u00fcl\u00edrni a jelenlegi, \u201e\u00e9leth\u0171\u201d konfigur\u00e1ci\u00f3t (<i>live<\/i>). Ehhez \u00f6ssze kell hasonl\u00edtanunk <i>new<\/i> a m\u00faltban alkalmazott konfigur\u00e1ci\u00f3val (<i>last-applied<\/i>) \u00e9s alkalmaznunk kell <i>live<\/i> a kapott jav\u00edt\u00e1st.<\/p>\n<p>Ezt a megk\u00f6zel\u00edt\u00e9st <b>2-way merge<\/b>-nak h\u00edvj\u00e1k. P\u00e9ld\u00e1ul a Helm haszn\u00e1lja.<\/p>\n<p>Van egy m\u00e1sik is, <b>3-way merge<\/b>, amely abban k\u00fcl\u00f6nb\u00f6zik, hogy:<\/p>\n<ul>\n<li> a hasonl\u00edt\u00e1s sor\u00e1n megn\u00e9zz\u00fck, mi lett elt\u00e1vol\u00edtva; <i>last-applied<\/i> \u00e9s <i>new<\/i>megn\u00e9zz\u00fck, mi lett hozz\u00e1adva vagy megv\u00e1ltoztatva;<\/li>\n<li> a hasonl\u00edt\u00e1s sor\u00e1n megn\u00e9zz\u00fck, mi lett elt\u00e1vol\u00edtva; <i>new<\/i> \u00e9s <i>live<\/i>a szintetiz\u00e1lt jav\u00edt\u00e1st a megfelel\u0151 helyre alkalmazzuk.<\/li>\n<li> T\u00f6bb mint 1000 alkalmaz\u00e1st telep\u00edt\u00fcnk Helm haszn\u00e1lat\u00e1val, ez\u00e9rt val\u00f3j\u00e1ban \u00e9lethosszig 2-way merge m\u00f3dszerrel \u00e9l\u00fcnk. Azonban ennek sz\u00e1mos probl\u00e9m\u00e1ja van, amelyeket saj\u00e1t jav\u00edt\u00e1sainkkal oldottunk meg, hogy a Helm megfelel\u0151en m\u0171k\u00f6dj\u00f6n. <i>live<\/i>.<\/li>\n<\/ul>\n<p>\nT\u00f6bb mint 1000 alkalmaz\u00e1st telep\u00edt\u00fcnk Helmmel, \u00edgy val\u00f3j\u00e1ban 2-way merge m\u00f3dban \u00e9l\u00fcnk. Ennek azonban vannak probl\u00e9m\u00e1i, amelyeket a saj\u00e1t jav\u00edt\u00e1sainkkal oldottunk meg, hogy a Helm megfelel\u0151en m\u0171k\u00f6dj\u00f6n.<\/p>\n<h3>Miut\u00e1n a CI-rendszer\u00fcnk egy \u00faj konfigur\u00e1ci\u00f3t gener\u00e1lt a Kubernetes sz\u00e1m\u00e1ra, azt alkalmaz\u00e1sra k\u00fcldi<\/h3>\n<p>\n(apply) <i>a klaszterre - Helm seg\u00edts\u00e9g\u00e9vel vagy<\/i> . Ezut\u00e1n m\u00e1r a m\u00e1r le\u00edrt N-way merge zajlik, amire a Kubernetes API j\u00f3v\u00e1hagy\u00f3lag v\u00e1laszol a CI-rendszernek, amely ezut\u00e1n a felhaszn\u00e1l\u00f3j\u00e1nak. <code>kubectl apply<\/code>De van egy hatalmas probl\u00e9ma: a<\/p>\n<p><img decoding=\"async\" alt=\"werf \u2014 az eszk\u00f6z\u00fcnk CI\/CD-hez Kubernetes-ben (\u00e1ttekint\u00e9s \u00e9s a besz\u00e1mol\u00f3 vide\u00f3ja)\" src=\"\/wp-content\/uploads\/2019\/08\/fcc8251525f32c913f30fbcdc4296198.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nsikeres alkalmaz\u00e1s nem jelenti azt, hogy a kiad\u00e1s is sikeres <b>. Ha a Kubernetes meg\u00e9rtette, hogy milyen v\u00e1ltoztat\u00e1sokat kell alkalmazni, alkalmazza \u0151ket - m\u00e9g mindig nem tudjuk, mi lesz ennek az eredm\u00e9nye. P\u00e9ld\u00e1ul a frontenden a podok friss\u00edt\u00e9se \u00e9s \u00fajraind\u00edt\u00e1sa sikeresen v\u00e9gbemegy, de a backendben nem, \u00e9s elt\u00e9r\u0151 verzi\u00f3kat kapunk az ind\u00edtott alkalmaz\u00e1sk\u00e9p verzi\u00f3kb\u00f3l.<\/b>. Ha a Kubernetes \u00e9szleli, hogy milyen v\u00e1ltoztat\u00e1sokat kell alkalmazni, v\u00e9grehajtja azokat \u2013 m\u00e9g nem tudjuk, mi lesz az eredm\u00e9ny. P\u00e9ld\u00e1ul a frontend pod-ok friss\u00edt\u00e9se \u00e9s \u00fajraind\u00edt\u00e1sa sikeresen v\u00e9gbe mehet, m\u00edg a backendben nem, \u00e9s k\u00fcl\u00f6nb\u00f6z\u0151 verzi\u00f3it kaphatjuk az alkalmaz\u00e1s fut\u00f3 image-einek.<\/p>\n<p>Ahhoz, hogy mindent helyesen csin\u00e1ljunk, ebbe a s\u00e9m\u00e1ba egy tov\u00e1bbi l\u00e1ncszem sz\u00fcks\u00e9ges \u2013 egy speci\u00e1lis tracker, amely a Kubernetes API-t\u00f3l kap inform\u00e1ci\u00f3t az \u00e1llapotr\u00f3l \u00e9s azt tov\u00e1bb\u00edtja a val\u00f3s helyzet tov\u00e1bbi elemz\u00e9s\u00e9re. L\u00e9trehoztunk egy Open Source k\u00f6nyvt\u00e1rat Go nyelven \u2013 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/kubedog\"><b>kubedog<\/b><\/a><\/noindex> <i>(l\u00e1sd a bejelent\u00e9s\u00e9t <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/434160\/\">itt<\/a><\/noindex>)<\/i>, \u2013 amely ezt a probl\u00e9m\u00e1t megoldja, \u00e9s be\u00e9p\u00edtve van a werf-be.<\/p>\n<p>Ennek a trackernek a m\u0171k\u00f6d\u00e9se a werf szintj\u00e9n annot\u00e1ci\u00f3k seg\u00edts\u00e9g\u00e9vel konfigur\u00e1lhat\u00f3, amelyeket a Deploymentekre vagy StatefulSetekre helyeznek el. A f\u0151 annot\u00e1ci\u00f3 \u2013 <code>fail-mode<\/code> \u2013 a k\u00f6vetkez\u0151 \u00e9rt\u00e9keket \u00e9rti:<\/p>\n<ul>\n<li> <code>IgnoreAndContinueDeployProcess<\/code> \u2013 figyelmen k\u00edv\u00fcl hagyjuk a komponens telep\u00edt\u00e9si probl\u00e9m\u00e1it, \u00e9s folytatjuk a telep\u00edt\u00e9st;<\/li>\n<li> <code>FailWholeDeployProcessImmediately<\/code> \u2013 egy hiba ebben a komponensben le\u00e1ll\u00edtja a telep\u00edt\u00e9si folyamatot;<\/li>\n<li> <code>HopeUntilEndOfDeployProcess<\/code> \u2013 rem\u00e9lj\u00fck, hogy ez a komponens m\u0171k\u00f6dni fog a telep\u00edt\u00e9s v\u00e9g\u00e9re.<\/li>\n<\/ul>\n<p>\nP\u00e9ld\u00e1ul, egy ilyen kombin\u00e1ci\u00f3 a forr\u00e1sok \u00e9s annot\u00e1ci\u00f3k \u00e9rt\u00e9keib\u0151l <code>fail-mode<\/code>:<\/p>\n<p><img decoding=\"async\" alt=\"werf \u2014 az eszk\u00f6z\u00fcnk CI\/CD-hez Kubernetes-ben (\u00e1ttekint\u00e9s \u00e9s a besz\u00e1mol\u00f3 vide\u00f3ja)\" src=\"\/wp-content\/uploads\/2019\/08\/40e161710e8a535cd95f1eb66ca8407b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAmikor el\u0151sz\u00f6r telep\u00edtj\u00fck, az adatb\u00e1zis (MongoDB) m\u00e9g nem lehet k\u00e9szen \u2013 a Deployment-ek meghi\u00fasulhatnak. De v\u00e1rhatunk, hogy elinduljon, \u00e9s a telep\u00edt\u00e9s m\u00e9gis siker\u00fclhet.<\/p>\n<p>Van m\u00e9g k\u00e9t annot\u00e1ci\u00f3 a kubedog sz\u00e1m\u00e1ra a werf-ben:<\/p>\n<ul>\n<li> <code>failures-allowed-per-replica<\/code> \u2013 az egyes replik\u00e1kra enged\u00e9lyezett buk\u00e1sok sz\u00e1ma;<\/li>\n<li> <code>show-logs-until<\/code> \u2013 szab\u00e1lyozza azt az id\u0151pontot, ameddig a werf megjelen\u00edti (stdout-on) az \u00f6sszes kib\u0151v\u00edtett pod napl\u00f3it. Alap\u00e9rtelmez\u00e9s szerint ez <code>PodIsReady<\/code> (hogy figyelmen k\u00edv\u00fcl hagyjuk az \u00fczeneteket, amelyek val\u00f3sz\u00edn\u0171leg nem sz\u00fcks\u00e9gesek, amikor a pod elkezd traffikot kapni), azonban megengedettek az al\u00e1bbi \u00e9rt\u00e9kek is: <code>ControllerIsReady<\/code> \u00e9s <code>EndOfDeploy<\/code>.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Mit szeretn\u00e9nk m\u00e9g a telep\u00edt\u00e9st\u0151l?<\/h3>\n<p>\nA m\u00e1r eml\u00edtett k\u00e9t ponton k\u00edv\u00fcl szeretn\u00e9nk:<\/p>\n<ul>\n<li> l\u00e1tni <b>napl\u00f3kat<\/b> \u2013 csak a sz\u00fcks\u00e9geseket, nem mindent;<\/li>\n<li> nyomon k\u00f6vetni <b>a halad\u00e1st,<\/b>mert ha a feladat \"csendben\" l\u00f3g n\u00e9h\u00e1ny percig, fontos meg\u00e9rteni, mi t\u00f6rt\u00e9nik ott;<\/li>\n<li> rendelkezni <b>automatikus visszag\u00f6rget\u00e9ssel<\/b> arra az esetre, ha valami rosszul s\u00fclne el (ez\u00e9rt kritikus tudni a telep\u00edt\u00e9s val\u00f3s \u00e1llapot\u00e1t). A telep\u00edt\u00e9snek atom\u00e1risnak kell lennie: vagy v\u00e9gigmegy, vagy minden visszat\u00e9r az el\u0151z\u0151 \u00e1llapotba.<\/li>\n<\/ul>\n<p><\/p>\n<h2>\u00d6sszegz\u00e9s<\/h2>\n<p>\nC\u00e9gk\u00e9nt, hogy megval\u00f3s\u00edtsuk az \u00f6sszes eml\u00edtett r\u00e9szletet a k\u00fcl\u00f6nb\u00f6z\u0151 sz\u00e1ll\u00edt\u00e1si f\u00e1zisokban (build, publish, deploy), elegend\u0151 egy CI-rendszer \u00e9s egy eszk\u00f6z. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">werf<\/a><\/noindex>.<\/p>\n<p>\u00d6sszegz\u00e9s\u00fcl:<\/p>\n<p><img decoding=\"async\" alt=\"werf \u2014 az eszk\u00f6z\u00fcnk CI\/CD-hez Kubernetes-ben (\u00e1ttekint\u00e9s \u00e9s a besz\u00e1mol\u00f3 vide\u00f3ja)\" src=\"\/wp-content\/uploads\/2019\/08\/bafba54f2df8740a1a12c93b3476e49a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA werf seg\u00edts\u00e9g\u00e9vel jelent\u0151s el\u0151rel\u00e9p\u00e9st tett\u00fcnk a DevOps m\u00e9rn\u00f6k\u00f6k sz\u00e1mos probl\u00e9m\u00e1j\u00e1nak megold\u00e1s\u00e1ban, \u00e9s \u00f6r\u00fcln\u00e9nk, ha egy sz\u00e9lesebb k\u00f6z\u00f6ss\u00e9g legal\u00e1bb kipr\u00f3b\u00e1ln\u00e1 ezt az eszk\u00f6zt a gyakorlatban. K\u00f6z\u00f6sen k\u00f6nnyebb j\u00f3 eredm\u00e9nyeket el\u00e9rni.<\/p>\n<h2>Vide\u00f3k \u00e9s di\u00e1k<\/h2>\n<p>\nEl\u0151ad\u00e1s vide\u00f3 (~47 perc):<\/p>\n<p><center><div class=\"youtube-placeholder\" data-id=\"cK3ackGUTLw\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/cK3ackGUTLw\/hqdefault.jpg\" alt=\"Vide\u00f3 lej\u00e1tsz\u00e1sa\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><\/p>\n<p>El\u0151ad\u00e1s bemutat\u00e1sa:<\/p>\n<p><center><iframe loading=\"lazy\" width=\"560\" height=\"315\" src=\"\/\/speakerdeck.com\/player\/2033277984c04900b18940588edf1161\" frameborder=\"0\" allowfullscreen><\/iframe><\/center><\/p>\n<h2>P.S.<\/h2>\n<p>\nTov\u00e1bbi el\u0151ad\u00e1sok a Kubernetesr\u0151l blogunkban:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/459326\/\">Automatikus m\u00e9retez\u00e9s \u00e9s er\u0151forr\u00e1s-menedzsment a Kubernetes-ben<\/a><\/noindex>\u00bb <i>(Dmitrij Stoljarov; 2019. \u00e1prilis 27. a \u201eStachki\u201d rendezv\u00e9nyen)<\/i>;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/449096\/\">A Kubernetes b\u0151v\u00edt\u00e9se \u00e9s kieg\u00e9sz\u00edt\u00e9se<\/a><\/noindex>\u00bb <i>(Andrej Polovov; 2019. \u00e1prilis 8. a Saint HighLoad++ rendezv\u00e9nyen)<\/i>;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/431500\/\">Adatb\u00e1zisok \u00e9s Kubernetes<\/a><\/noindex>\u00bb <i>(Dmitrij Stoljarov; 2018. november 8. a HighLoad++ rendezv\u00e9nyen)<\/i>;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/412901\/\">Monitoroz\u00e1s \u00e9s Kubernetes<\/a><\/noindex>\u00bb <i>(Dmitrij Stoljarov; 2018. m\u00e1jus 28. a RootConf rendezv\u00e9nyen)<\/i>;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/345116\/\">A Kubernetes \u00e9s a GitLab legjobb CI\/CD gyakorlatai<\/a><\/noindex>\u00bb <i>(Dmitrij Stoljarov; 2017. november 7. a HighLoad++ rendezv\u00e9nyen)<\/i>;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/331188\/\">Tapasztalataink a Kubernetes haszn\u00e1lat\u00e1r\u00f3l kisebb projektekben<\/a><\/noindex>\u00bb <i>(Dmitrij Stoljarov; 2017. j\u00fanius 6. a RootConf rendezv\u00e9nyen)<\/i>.<\/li>\n<\/ul>\n<p>Forr\u00e1s: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/460351\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>27 \u043c\u0430\u044f \u0432 \u0433\u043b\u0430\u0432\u043d\u043e\u043c \u0437\u0430\u043b\u0435 \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u0438 DevOpsConf 2019, \u043f\u0440\u043e\u0445\u043e\u0434\u044f\u0449\u0435\u0439 \u0432 \u0440\u0430\u043c\u043a\u0430\u0445 \u0444\u0435\u0441\u0442\u0438\u0432\u0430\u043b\u044f \u0420\u0418\u0422++ 2019, \u0432 \u0440\u0430\u043c\u043a\u0430\u0445 \u0441\u0435\u043a\u0446\u0438\u0438 \u00ab\u041d\u0435\u043f\u0440\u0435\u0440\u044b\u0432\u043d\u0430\u044f \u043f\u043e\u0441\u0442\u0430\u0432\u043a\u0430\u00bb, \u043f\u0440\u043e\u0437\u0432\u0443\u0447\u0430\u043b \u0434\u043e\u043a\u043b\u0430\u0434 \u00abwerf \u2014 \u043d\u0430\u0448 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 \u0434\u043b\u044f CI\/CD \u0432 Kubernetes\u00bb. \u0412 \u043d\u0451\u043c \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043e \u0442\u0435\u0445 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u0445 \u0438 \u0432\u044b\u0437\u043e\u0432\u0430\u0445, \u0441 \u043a\u043e\u0442\u043e\u0440\u044b\u043c\u0438 \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u043a\u0430\u0436\u0434\u044b\u0439 \u043f\u0440\u0438 \u0434\u0435\u043f\u043b\u043e\u0435 \u0432 Kubernetes, \u0430 \u0442\u0430\u043a\u0436\u0435 \u043e \u043d\u044e\u0430\u043d\u0441\u0430\u0445, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043e\u0433\u0443\u0442 \u0431\u044b\u0442\u044c \u0437\u0430\u043c\u0435\u0442\u043d\u044b \u043d\u0435 \u0441\u0440\u0430\u0437\u0443. [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27531,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36754","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.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"27 \u043c\u0430\u044f \u0432 \u0433\u043b\u0430\u0432\u043d\u043e\u043c \u0437\u0430\u043b\u0435 \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u0438 DevOpsConf 2019, \u043f\u0440\u043e\u0445\u043e\u0434\u044f\u0449\u0435\u0439 \u0432 \u0440\u0430\u043c\u043a\u0430\u0445 \u0444\u0435\u0441\u0442\u0438\u0432\u0430\u043b\u044f \u0420\u0418\u0422++ 2019, \u0432 \u0440\u0430\u043c\u043a\u0430\u0445 \u0441\u0435\u043a\u0446\u0438\u0438 \u00ab\u041d\u0435\u043f\u0440\u0435\u0440\u044b\u0432\u043d\u0430\u044f \u043f\u043e\u0441\u0442\u0430\u0432\u043a\u0430\u00bb, \u043f\u0440\u043e\u0437\u0432\u0443\u0447\u0430\u043b.\" \/>\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\/hu\/blog\/administrirovanie\/werf-nash-instrument-dlya-ci-cd-v-kubernetes-obzor-i-video-doklada\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"hu_HU\" \/>\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\udd47werf \u2014 \u043d\u0430\u0448 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 \u0434\u043b\u044f CI\/CD \u0432 Kubernetes (\u043e\u0431\u0437\u043e\u0440 \u0438 \u0432\u0438\u0434\u0435\u043e \u0434\u043e\u043a\u043b\u0430\u0434\u0430) | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"27 \u043c\u0430\u044f \u0432 \u0433\u043b\u0430\u0432\u043d\u043e\u043c \u0437\u0430\u043b\u0435 \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u0438 DevOpsConf 2019, \u043f\u0440\u043e\u0445\u043e\u0434\u044f\u0449\u0435\u0439 \u0432 \u0440\u0430\u043c\u043a\u0430\u0445 \u0444\u0435\u0441\u0442\u0438\u0432\u0430\u043b\u044f \u0420\u0418\u0422++ 2019, \u0432 \u0440\u0430\u043c\u043a\u0430\u0445 \u0441\u0435\u043a\u0446\u0438\u0438 \u00ab\u041d\u0435\u043f\u0440\u0435\u0440\u044b\u0432\u043d\u0430\u044f \u043f\u043e\u0441\u0442\u0430\u0432\u043a\u0430\u00bb, \u043f\u0440\u043e\u0437\u0432\u0443\u0447\u0430\u043b.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/werf-nash-instrument-dlya-ci-cd-v-kubernetes-obzor-i-video-doklada\" \/>\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-10-31T19:13:37+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:13:37+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\udd47werf \u2014 eszk\u00f6z\u00fcnk a CI\/CD-hez a Kubernetesben (\u00e1ttekint\u00e9s \u00e9s el\u0151ad\u00e1s vide\u00f3) | ProHoster","description":"2019. m\u00e1jus 27-\u00e9n a DevOpsConf 2019 f\u0151term\u00e9ben, a RIT++ 2019 fesztiv\u00e1l keret\u00e9ben, a \u201eFolyamatos sz\u00e1ll\u00edt\u00e1s\u201d szekci\u00f3ban hangzott el.","canonical_url":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/werf-nash-instrument-dlya-ci-cd-v-kubernetes-obzor-i-video-doklada","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hu_HU","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\udd47werf \u2014 \u043d\u0430\u0448 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 \u0434\u043b\u044f CI\/CD \u0432 Kubernetes (\u043e\u0431\u0437\u043e\u0440 \u0438 \u0432\u0438\u0434\u0435\u043e \u0434\u043e\u043a\u043b\u0430\u0434\u0430) | ProHoster","og:description":"27 \u043c\u0430\u044f \u0432 \u0433\u043b\u0430\u0432\u043d\u043e\u043c \u0437\u0430\u043b\u0435 \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u0438 DevOpsConf 2019, \u043f\u0440\u043e\u0445\u043e\u0434\u044f\u0449\u0435\u0439 \u0432 \u0440\u0430\u043c\u043a\u0430\u0445 \u0444\u0435\u0441\u0442\u0438\u0432\u0430\u043b\u044f \u0420\u0418\u0422++ 2019, \u0432 \u0440\u0430\u043c\u043a\u0430\u0445 \u0441\u0435\u043a\u0446\u0438\u0438 \u00ab\u041d\u0435\u043f\u0440\u0435\u0440\u044b\u0432\u043d\u0430\u044f \u043f\u043e\u0441\u0442\u0430\u0432\u043a\u0430\u00bb, \u043f\u0440\u043e\u0437\u0432\u0443\u0447\u0430\u043b.","og:url":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/werf-nash-instrument-dlya-ci-cd-v-kubernetes-obzor-i-video-doklada","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-10-31T19:13:37+00:00","article:modified_time":"2019-10-31T19:13:37+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"36754","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-22 04:44:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:39:23","updated":"2026-01-22 04:44:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts\/36754","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/comments?post=36754"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts\/36754\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/media\/27531"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/media?parent=36754"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/categories?post=36754"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/tags?post=36754"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}