{"id":76769,"date":"2020-04-04T13:42:27","date_gmt":"2020-04-04T11:42:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet"},"modified":"2020-04-04T13:42:27","modified_gmt":"2020-04-04T11:42:27","slug":"content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet","title":{"rendered":"Ozna\u010devanje vsebine v zbiralniku werf: zakaj in kako deluje?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Ozna\u010devanje vsebine v zbiralniku werf: zakaj in kako deluje?\" src=\"\/wp-content\/uploads\/2020\/04\/494346bbee96cc2b6c838491ba1c67fb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/\">werf<\/a><\/noindex> \u2014 na\u0161 GitOps CLI alat za izgradnju i isporuku aplikacija u Kubernetes s otvorenim kodom. U <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/493170\/\">izdanju v1.1<\/a><\/noindex> predstavljena je nova zna\u010dajka u alatu za izgradnju: ozna\u010davanje slika prema sadr\u017eaju ili <i>ozna\u010davanje zasnovano na sadr\u017eaju<\/i>. Do sada je tipi\u010dna shema ozna\u010davanja u werf pretpostavljala ozna\u010davanje Docker slika prema Git oznakama, Git granama ili Git commitovima. No, sve te sheme imaju nedostatke koji se potpuno rje\u0161avaju novom strategijom ozna\u010davanja. Detalji o tome i za\u0161to je to tako dobro \u2014 u nastavku.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Izdavanje skupa mikroservisa iz jednog Git repozitorija<\/h2>\n<p>\n\u010cesto se doga\u0111a da je aplikacija razdvojena na vi\u0161e manje neovisnih servisa. Izdavanja tih servisa mogu se odvijati neovisno: u jednom trenutku mo\u017ee biti izdano jedan ili vi\u0161e servisa, dok ostali moraju nastaviti raditi bez ikakvih promjena. No, s obzirom na pohranu koda i upravljanje projektom, prakti\u010dnije je takve servise aplikacije dr\u017eati u jedinstvenom repozitoriju.<\/p>\n<p>Postoje situacije kada su servisi zaista neovisni i nisu povezani s jednom aplikacijom. U tom slu\u010daju bit \u0107e smje\u0161teni u odvojenim projektima i njihovo \u0107e se izdavanje provoditi putem odvojenih CI\/CD procesa u svakom projektu.<\/p>\n<p>Me\u0111utim, u stvarnosti programeri \u010desto razdvajaju jedinstvenu aplikaciju na nekoliko mikroservisa, ali otvaranje svakog zasebnog repozitorija i projekta\u2026 \u2014 o\u010diti je overkill. O ovoj situaciji bit \u0107e rije\u010d dalje: nekoliko takvih mikroservisa nalazi se u jedinstvenom repozitoriju projekta, a izdanja se odvijaju putem jedinstvenog procesa u CI\/CD.<\/p>\n<h3>Ozna\u010davanje prema Git grani i Git oznaci<\/h3>\n<p>\nPretpostavimo da se koristi najra\u0161irenija strategija ozna\u010davanja \u2014 <i>tag-or-branch<\/i>. Za Git grane, slike se ozna\u010davaju imenom grane, za jednu granu u jednom trenutku postoji samo jedna objavljena slika pod imenom te grane. Za Git oznake, slike se ozna\u010davaju odgovaraju\u0107e imenom oznake.<\/p>\n<p>Pri stvaranju nove Git oznake \u2014 na primjer, pri izlasku nove verzije \u2014 za sve slike projekta u Docker Registry \u0107e biti stvorena nova Docker oznaka:<\/p>\n<ul>\n<li> <code>myregistry.org\/myproject\/frontend:v1.1.10<\/code><\/li>\n<li> <code>myregistry.org\/myproject\/myservice1:v1.1.10<\/code><\/li>\n<li> <code>myregistry.org\/myproject\/myservice2:v1.1.10<\/code><\/li>\n<li> <code>myregistry.org\/myproject\/myservice3:v1.1.10<\/code><\/li>\n<li> <code>myregistry.org\/myproject\/myservice4:v1.1.10<\/code><\/li>\n<li> <code>myregistry.org\/myproject\/myservice5:v1.1.10<\/code><\/li>\n<li> <code>myregistry.org\/myproject\/database:v1.1.10<\/code><\/li>\n<\/ul>\n<p>\nTa nova imena slik prihajajo preko Helm predlog v konfiguracijo Kubernetes. Pri zagonu implementacije z ukazom <code>werf deploy<\/code> pride do posodobitve polja <code>image<\/code> v manifestih virov Kubernetes in ponovnem zagonu ustreznih virov zaradi spremenjenega imena slike.<\/p>\n<p><b>Te\u017eava<\/b>: v primeru, ko se dejansko od prej\u0161njega izpustitve (Git oznake) ni spremenila vsebina slike, temve\u010d le njen Docker oznaka, pride do <i>odve\u010dnega<\/i> ponovnega zagona te aplikacije in zato je lahko prisotna neka preprosta. \u010ceprav ni bilo nobenih pravih razlogov za izvedbo tega ponovnega zagona.<\/p>\n<p>Kot posledica trenutne sheme ozna\u010devanja je treba ustvariti ve\u010d lo\u010denih Git repozitorijev in se pojavi problem organizacije izpustov teh ve\u010d repozitorijev. Na splo\u0161no se ta shema izka\u017ee za prenatrpano in zapleteno. Bolje je povezati veliko storitev v en sam repozitorij in ustvariti tak\u0161ne Docker oznake, da ni odve\u010dnih ponovnih zagonov.<\/p>\n<h3>Ozna\u010devanje glede na Git commit<\/h3>\n<p>\nV werf je prav tako prisotna strategija ozna\u010devanja, povezana z Git commit.<\/p>\n<p>Git commit je identifikator vsebine Git repozitorija in je odvisen od zgodovine sprememb datotek v Git repozitoriju, zato se zdi smiselno, da ga uporabimo za ozna\u010devanje slik v Docker Registry.<\/p>\n<p>Vendar pa ozna\u010devanje glede na Git commit ima enake pomanjkljivosti kot ozna\u010devanje glede na Git veje ali Git oznake:<\/p>\n<ul>\n<li> Lahko je bil ustvarjen prazen commit, ki ne spreminja datotek, medtem ko bo Docker oznaka slike spremenjena.<\/li>\n<li> Lahko je bil ustvarjen merge commit, ki ne spreminja datotek, medtem ko bo Docker oznaka slike spremenjena.<\/li>\n<li> Lahko je bil ustvarjen commit, ki spreminja tiste datoteke v Git, ki niso vklju\u010dene v sliko, medtem ko bo Docker oznaka slike ponovno spremenjena.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Ozna\u010devanje po imenu Git veje ne odra\u017ea razli\u010dice slike<\/h2>\n<p>\nObstaja \u0161e en problem, povezan s strategijo ozna\u010devanja po Git vejah.<\/p>\n<p>Ozna\u010devanje po imenu veje deluje, dokler se commiti te veje zaporedoma zbirajo v kronolo\u0161kem vrstnem redu.<\/p>\n<p>\u010ce v trenutni shemi uporabnik za\u017eene ponovno sestavljanje starega commit-a, povezanega z dolo\u010deno vejo, bo werf prepisal sliko s pripadajo\u010dim Docker-ozna\u010devalcem z znova sestavljeno razli\u010dico slike za starega commit-a. Uporabniki, ki uporabljajo ta ozna\u010devalec, imajo od tega trenutka naprej tveganje, da se med ponovnim zagonom pod-ov prenese druga razli\u010dica slike, kar lahko povzro\u010di, da na\u0161a aplikacija izgubi povezavo s CI-sistemom in se razsynchronizira.<\/p>\n<p>Poleg tega, pri zaporednih push razli\u010dnih komitov v eno vejo z malo \u010dasa med njimi, lahko starej\u0161i komit zgradi kasneje kot novej\u0161i: starej\u0161a razli\u010dica slike lahko prepi\u0161e novej\u0161o pod oznako Git-veje. Tak\u0161ne te\u017eave lahko re\u0161i CI\/CD sistem (na primer, v GitLab CI se za serijo komitov spro\u017ei pipeline za zadnji). Vendar to ne podpira vsak sistem, zato bi moral obstajati bolj zanesljiv na\u010din za prepre\u010devanje te temeljne te\u017eave.<\/p>\n<h2>Kaj je ozna\u010devanje na podlagi vsebine?<\/h2>\n<p>\nTorej, kaj sploh je ozna\u010devanje na podlagi vsebine \u2014 ozna\u010devanje slik glede na vsebino.<\/p>\n<p>Za ustvarjanje Docker-ozna\u010devalcev se ne uporabljajo primitivni Git-ovi (Git-veja, Git-ozna\u010devalec\u2026), temve\u010d kontrolna vsota, povezana z:<\/p>\n<ul>\n<li> <i>vsebino slike<\/i>. Identifikator-oznaka slike odra\u017ea njeno vsebino. Pri ustvarjanju nove razli\u010dice ta identifikator ne bo spremenjen, \u010de v sliki niso bile spremenjene datoteke;<\/li>\n<li> <i>zgodovino ustvarjanja te slike v Gitu<\/i>. Obrazi, povezani z razli\u010dnimi Git-vejami in razli\u010dno zgodovino gradnje preko werf, bodo imeli razli\u010dne oznake-identifikatorje.<\/li>\n<\/ul>\n<p>\nKot tak identifikator-oznaka deluje tako imenovana <b>podpis stopenj slike<\/b>.<\/p>\n<p>Vsaka slika se sestoji iz niza stopenj: <code>from<\/code>, <code>before-install<\/code>, <code>git-archive<\/code>, <code>install<\/code>, <code>imports-after-install<\/code>, <code>before-setup<\/code>,\u2026 <code>git-latest-patch<\/code> itd. Vsaka stopnja ima identifikator, ki odra\u017ea njeno vsebino, \u2014 <b>podpis stopnje<\/b> <i>(stage signature)<\/i>.<\/p>\n<p>Kon\u010dna slika, ki je sestavljena iz teh stopenj, je ozna\u010dena s tako imenovanim podpisom niza teh stopenj \u2014 <b>stages signature<\/b>, \u2014 ki je poenostavljajo\u010d za vse stopnje slike.<\/p>\n<p>Vsaka slika iz konfiguracije <code>werf.yaml<\/code> bo v splo\u0161nem imela svoj tak podpis in posledi\u010dno Docker-oznako.<\/p>\n<p>Podpis stopenj re\u0161uje vse navedene te\u017eave:<\/p>\n<ul>\n<li> Ustvarja se zavarovan proti praznim Git-komitom.<\/li>\n<li> Ustvarja se zavarovan proti Git-komitom, ki spreminjajo datoteke, ki niso relevantne za sliko.<\/li>\n<li> Ne povzro\u010da te\u017eav pri prepisovanju aktualne razli\u010dice slike pri ponovnem zagonu gradnje za stare Git-komite veje.<\/li>\n<\/ul>\n<p>\nSedaj je to priporo\u010dena strategija ozna\u010devanja in se privzeto uporablja v werf za vse CI-sisteme.<\/p>\n<h2>Kako omogo\u010diti in uporabljati v werf<\/h2>\n<p>\nUstrezna mo\u017enost je bila dodana ekipi <code>werf publish<\/code>: <code>--tag-by-stages-signature=true|false<\/code><\/p>\n<p>V CI-sistemu strategijo ozna\u010devanja dolo\u010da ukaz <code>werf ci-env<\/code>. Prej je bil za to dolo\u010den parameter <code>werf ci-env --tagging-strategy=tag-or-branch<\/code>. Zdaj, \u010de navedete <code>werf ci-env --tagging-strategy=stages-signature<\/code> ali ne navedete te mo\u017enosti, bo werf privzeto uporabil strategijo ozna\u010devanja <code>stages-signature<\/code>. Ukaz <code>werf ci-env<\/code> samodejno nastavi potrebne zastavice za ukaz <code>werf build-and-publish<\/code> (ali <code>werf publish<\/code>), zato dodatnih mo\u017enosti za te ukaze ni treba navajati.<\/p>\n<p>Na primer, ukaz:<\/p>\n<pre><code class=\"plaintext\">werf publish --stages-storage :local --images-repo registry.hello.com\/web\/core\/system --tag-by-stages-signature<\/code><\/pre>\n<p>\n\u2026 lahko ustvari naslednje slike:<\/p>\n<ul>\n<li> <code>registry.hello.com\/web\/core\/system\/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d<\/code><\/li>\n<li> <code>registry.hello.com\/web\/core\/system\/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6<\/code><\/li>\n<\/ul>\n<p>\nTukaj <code>4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d<\/code> \u2014 to je podpis faze slike <code>backend<\/code>, a <code>f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6<\/code> \u2014 podpis faze slike <code>frontend<\/code>.<\/p>\n<p>Pri uporabi posebnih funkcij <code>werf_container_image<\/code> in <code>werf_container_env<\/code> v predlogah Helm ni treba ni\u010desar spreminjati: te funkcije bodo samodejno generirale pravilna imena slik.<\/p>\n<p>Primer konfiguracije v CI-sistemu:<\/p>\n<pre><code class=\"plaintext\">type multiwerf &amp;&amp; source &lt;(multiwerf use 1.1 beta)\ntype werf &amp;&amp; source &lt;(werf ci-env gitlab)\nwerf build-and-publish|deploy<\/code><\/pre>\n<p>\nVe\u010d informacij o nastavitvi je na voljo v dokumentaciji:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/reference\/publish_process.html#%D1%82%D0%B5%D0%B3%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BE%D0%B1%D1%80%D0%B0%D0%B7%D0%BE%D0%B2-%D0%BF%D0%BE-%D1%81%D0%BE%D0%B4%D0%B5%D1%80%D0%B6%D0%B8%D0%BC%D0%BE%D0%BC%D1%83\">Imenska oznaka \u2192 Objavljanje (publish)<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/reference\/plugging_into_cicd\/overview.html#stages-signature\">Delo z CI\/CD \u2192 Splo\u0161ne informacije \u2192 stages-signature<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/guides\/gitlab_ci_cd_integration.html#gitlab-ciyml\">Integracija z GitLab CI\/CD \u2192 .gitlab-ci.yml<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Ukupno<\/h2>\n<p><\/p>\n<ul>\n<li> Nova mo\u017enost <code>werf publish --tag-by-stages-signature=true|false<\/code>.<\/li>\n<li> Nova vrednost mo\u017enosti <code>werf ci-env --tagging-strategy=stages-signature|tag-or-branch<\/code> (\u010de ne navedete, bo privzeto <code>stages-signature<\/code>).<\/li>\n<li> \u010ce so prej uporabljali mo\u017enosti ozna\u010devanja po Git-commitih (<code>WERF_TAG_GIT_COMMIT<\/code> ali mo\u017enost <code>werf publish --tag-git-commit COMMIT<\/code>), je nujno preklopiti na strategijo ozna\u010devanja <i>stages-signature<\/i>.<\/li>\n<li> Nove projekte je najbolje takoj preklopiti na novo shemo ozna\u010devanja.<\/li>\n<li> Stare projekte je pri prehodu na werf 1.1 za\u017eeleno preklopiti na novo shemo ozna\u010devanja, vendar stara <i>tag-or-branch<\/i> \u0161e vedno ostaja podprta.<\/li>\n<\/ul>\n<p>\nOzna\u010devanje, ki temelji na vsebini, re\u0161uje vse v \u010dlanku obravnavane te\u017eave:<\/p>\n<ul>\n<li> Odpornost imena Docker-oznake na prazne Git-commite.<\/li>\n<li> Odpornost imena Docker-oznake na Git-commite, ki spreminjajo nerelevantne datoteke za sliko.<\/li>\n<li> Ne vodi do problema s prepisovanjem aktualne verzije slike pri ponovnem zagonu graditev za stare Git-commit-e za Git-vejice.<\/li>\n<\/ul>\n<p>\nU\u017eivajte! In ne pozabite obiskati nas na <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, da ustvarite te\u017eavo ali poi\u0161\u010dete \u017ee obstoje\u010do, ji dodate glas, ustvarite PR ali samo opazujete razvoj projekta.<\/p>\n<h2>P.S.<\/h2>\n<p>\nPreberite tudi na na\u0161em blogu:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/493170\/\">Izdanje werf 1.1: pobolj\u0161anja u skladu danas i planovi za budu\u0107nost<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">Predstavljamo werf 1.0 stable: kak\u0161na je povezava z GitOps, status in na\u010drti<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/460351\/\">werf \u2014 na\u0161 orodje za CI\/CD v Kubernetes (pregled in video poro\u010dila)<\/a><\/noindex>\u00bb;<\/li>\n<li> Cikel opomb o novostih v werfu:\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/476646\/\">3-way merge v werfu: namestitev v Kubernetes s Helm 'na steroidih'<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468049\/\">Uporaba werfa za izdajanje kompleksnih Helm-chart-ov<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465131\/\">Podpora za monorepo in multirepo pri werf in kak\u0161na je povezava z Docker Registry<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/463613\/\">Sestavljanje Docker-slik v werfu je zdaj mogo\u010de tudi po navadnem Dockerfile-u<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Izvor: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/495112\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>werf \u2014 \u043d\u0430\u0448\u0430 GitOps CLI-\u0443\u0442\u0438\u043b\u0438\u0442\u0430 \u0441 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u043c \u043a\u043e\u0434\u043e\u043c \u0434\u043b\u044f \u0441\u0431\u043e\u0440\u043a\u0438 \u0438 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0432 Kubernetes. \u0412 \u0440\u0435\u043b\u0438\u0437\u0435 v1.1 \u0431\u044b\u043b\u0430 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u0435\u043d\u0430 \u043d\u043e\u0432\u0430\u044f \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u0432 \u0441\u0431\u043e\u0440\u0449\u0438\u043a\u0435 \u043e\u0431\u0440\u0430\u0437\u043e\u0432: \u0442\u0435\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u043e\u0431\u0440\u0430\u0437\u043e\u0432 \u043f\u043e \u0441\u043e\u0434\u0435\u0440\u0436\u0438\u043c\u043e\u043c\u0443 \u0438\u043b\u0438 content-based tagging. \u0414\u043e \u0441\u0438\u0445 \u043f\u043e\u0440 \u0442\u0438\u043f\u0438\u0447\u043d\u0430\u044f \u0441\u0445\u0435\u043c\u0430 \u0442\u0435\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0432 werf \u043f\u0440\u0435\u0434\u043f\u043e\u043b\u0430\u0433\u0430\u043b\u0430 \u0442\u0435\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 Docker-\u043e\u0431\u0440\u0430\u0437\u043e\u0432 \u043f\u043e Git-\u0442\u0435\u0433\u0443, Git-\u0432\u0435\u0442\u043a\u0435 \u0438\u043b\u0438 Git-\u043a\u043e\u043c\u043c\u0438\u0442\u0443. \u041d\u043e \u0443 \u0432\u0441\u0435\u0445 \u044d\u0442\u0438\u0445 \u0441\u0445\u0435\u043c \u0435\u0441\u0442\u044c \u043d\u0435\u0434\u043e\u0441\u0442\u0430\u0442\u043a\u0438, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":76770,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-76769","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.4 - aioseo.com -->\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\/sl\/blog\/administrirovanie\/content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sl_SI\" \/>\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\udd47Content-based tagging \u0432 \u0441\u0431\u043e\u0440\u0449\u0438\u043a\u0435 werf: \u0437\u0430\u0447\u0435\u043c \u0438 \u043a\u0430\u043a \u044d\u0442\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442? | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet\" \/>\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=\"2020-04-04T11:42:27+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-04-04T11:42:27+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\udd47Oznaka na osnovi vsebine v zbiralcu werf: zakaj in kako to deluje? | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sl_SI","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\udd47Content-based tagging \u0432 \u0441\u0431\u043e\u0440\u0449\u0438\u043a\u0435 werf: \u0437\u0430\u0447\u0435\u043c \u0438 \u043a\u0430\u043a \u044d\u0442\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442? | ProHoster","og:url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet","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":"2020-04-04T11:42:27+00:00","article:modified_time":"2020-04-04T11:42:27+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"76769","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":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 17:30:22","updated":"2022-09-28 05:59:33","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/76769","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=76769"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/76769\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media\/76770"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=76769"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=76769"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=76769"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}