{"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\/et\/blog\/administrirovanie\/content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet","title":{"rendered":"Sisu p\u00f5hine m\u00e4rgistamine werf'i kogujas: miks ja kuidas see t\u00f6\u00f6tab?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Sisu p\u00f5hine m\u00e4rgistamine werf&#039;i kogujas: miks ja kuidas see t\u00f6\u00f6tab?\" 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 meie avatud l\u00e4htekoodiga GitOps CLI t\u00f6\u00f6riist rakenduste ehitamiseks ja tarnimiseks Kubernetesesse. V <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/493170\/\">v\u00e4ljaandes v1.1<\/a><\/noindex> kasutusele v\u00f5etud uus v\u00f5imalus piltide kogujas: piltide m\u00e4rgistamine sisu p\u00f5hjal v\u00f5i <i>sisu p\u00f5hine m\u00e4rgistamine<\/i>. Seni on werf'is t\u00fc\u00fcpiline m\u00e4rgistamisstrateegia h\u00f5lmanud Docker-piltide m\u00e4rgistamist Git-t\u00e4gi, Git-haru v\u00f5i Git-commit'i j\u00e4rgi. Kuid k\u00f5igil neil skeemidel on puudused, mida uus m\u00e4rgistamisstrateegia t\u00e4ielikult lahendab. \u00dcksikasjad selle kohta ja miks see nii hea on \u2014 allpool.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Mikroteenuste komplekti v\u00e4ljalaskmine \u00fchest Git-repositaariumist<\/h2>\n<p>\nSageli esineb olukordi, kus rakendus on jagatud paljude enam-v\u00e4hem iseseisvate teenuste vahel. Nende teenuste versioonid v\u00f5ivad toimuda iseseisvalt: korraga v\u00f5ib v\u00e4lja tulla \u00fcks v\u00f5i mitu teenust, samas kui teised peavad j\u00e4tkama t\u00f6\u00f6d ilma muudatusteta. Kuid koodi hoidmise ja projekti haldamise seisukohalt on mugavam hoida selliseid rakenduse teenuseid \u00fches repos.<\/p>\n<p>On olukordi, kus teenused on t\u00f5eliselt iseseisvad ja ei ole seotud \u00fche rakendusega. Sellisel juhul asuvad nad erinevates projektides ja nende v\u00e4ljalaskmine toimub iga projekti eraldi CI\/CD protsesside kaudu.<\/p>\n<p>Kuid reaalsuses jagavad arendajad sageli \u00fchte rakendust mitmeks mikroteenuseks, kuid iga\u00fche jaoks eraldi reposse ja projekti rakendamine ... oleks kindlasti \u00fcle j\u00f5u k\u00e4iv. Just sellest olukorrast juttu ongi: mitmed sellised mikroteenused asuvad \u00fches projektirepos ja v\u00e4ljalaskmine toimub \u00fchtse CI\/CD protsessi kaudu.<\/p>\n<h3>M\u00e4rgistamine Git-haru ja Git-t\u00e4gi j\u00e4rgi<\/h3>\n<p>\nOletame, et kasutatakse k\u00f5ige levinumat m\u00e4rgistamisstrateegiat \u2014 <i>tag-or-branch<\/i>. Git-harude puhul m\u00e4rgistatakse pildid haru nime j\u00e4rgi, \u00fchel ajal on \u00fche haru nime j\u00e4rgi avaldatud ainult \u00fcks pilt. Git-t\u00e4gi puhul m\u00e4rgistatakse pildid vastavalt t\u00e4gi nimele.<\/p>\n<p>Uue Git-t\u00e4gi loomisel \u2014 n\u00e4iteks uue versiooni v\u00e4ljaandmisel \u2014 luuakse k\u00f5igi projekti piltide jaoks Docker Registry's uus Docker-t\u00e4gi:<\/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>\nNeed uued nimed j\u00f5uavad Helm-mallide kaudu Kubernetes'i konfiguratsiooni. Deployment'i k\u00e4ivitamisel k\u00e4suga <code>werf deploy<\/code> toimub v\u00e4lja muude v\u00e4ljade v\u00e4rskendamine <code>image<\/code> Kubernetes'i ressursimaaniifestides ja vastavate ressursside taask\u00e4ivitamine seoses pildi nime muutumisega.<\/p>\n<p><b>Probleem<\/b>: juhul, kui eelmisest v\u00e4ljaandest (Git-t\u00e4gi) ei ole pildi sisu tegelikult muutunud, vaid ainult selle Docker-t\u00e4gi, toimub <i>liigne<\/i> taask\u00e4ivitamine, ning seega on v\u00f5imalik m\u00f5ningane h\u00e4irivus. Kuigi selleks ei olnud tegelikke p\u00f5hjusi.<\/p>\n<p>Tulemusena, praeguse sildistamisstrateegiaga tuleb luua mitu eraldi Git-repositooriumit ning kerkib \u00fcles mitu repositooriumi v\u00e4ljaandmise korraldamise probleem. \u00dcldiselt on selline s\u00fcsteem \u00fclekoormatud ja keeruline. Paremini oleks \u00fchendada mitu teenust \u00fchte repositooriumisse ja luua selliseid Docker-t\u00e4gesid, et v\u00e4ltida liigseid taask\u00e4ivitamisi.<\/p>\n<h3>Sildistamine Git-commit\u2019i j\u00e4rgi<\/h3>\n<p>\nWerfis on samuti olemas sildistamistrateegia, mis on seotud Git-commit'idega.<\/p>\n<p>Git-commit on Git-repositooriumi sisu identifikaator ja s\u00f5ltub failide redigeerimise ajaloost Git-repositooriumis, seega tundub loogiline seda kasutada piltide sildistamiseks Docker Registry's.<\/p>\n<p>Siiski, sildistamine Git-commit\u2019i j\u00e4rgi omab samu puudusi, mis Git-haru v\u00f5i Git-t\u00e4he puhul:<\/p>\n<ul>\n<li> V\u00f5ib olla loodud t\u00fchi commit, mis ei muuda faile, ja Docker-t\u00e4gi muutub.<\/li>\n<li> V\u00f5ib olla loodud merge-commit, mis ei muuda faile, ja Docker-t\u00e4gi muutub.<\/li>\n<li> V\u00f5ib olla loodud commit, mis muudab Git'is faile, mida pildiga ei impordita, ja Docker-t\u00e4gi muutub taas.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Sildistamine Git-haru nime j\u00e4rgi ei peegelda pildi versiooni<\/h2>\n<p>\nOn veel \u00fcks probleem, mis on seotud Git-harude sildistamisstrateegiaga.<\/p>\n<p>Haru nime j\u00e4rgi sildistamine t\u00f6\u00f6tab seni, kuni selle haru commit'id kogutakse j\u00e4rjestikku ajaliselt.<\/p>\n<p>Kui praeguses skeemis k\u00e4ivitab kasutaja vanema p\u00fchenduse uuesti koostamise, mis on seotud m\u00f5ne haruga, siis werf \u00fcle kirjutab pildi vastava Docker-tagi uue versiooniga vanema p\u00fchenduse jaoks. Selle m\u00e4rgiga kasutatavad Deployment'id v\u00f5ivad sel hetkel pod'ide reinitsiatsioonil t\u00f5mmata teise pildi versiooni, mille tagaj\u00e4rjel meie rakendus kaotab \u00fchenduse CI-s\u00fcsteemiga ja satub des sinksroonimise probleemidesse.<\/p>\n<p>Lisaks, kui j\u00e4rjestikused push'id teevad \u00fchte haru, mille vahel on v\u00e4ike ajavahemik, v\u00f5ib vana commit ehitada hiljem kui uuem: vana versioon katab uue Git-haru sildi alla. Sellised probleemid v\u00f5ivad lahendada CI\/CD-s\u00fcsteem (nt GitLab CI, kus j\u00e4rjestikuste commit'ide jaoks k\u00e4ivitatakse torujuhe viimase jaoks). Kuid mitte k\u00f5ik s\u00fcsteemid ei toetada seda ja peaks olema usaldusv\u00e4\u00e4rsem viis selliste fundamentaalsete probleemide v\u00e4ltimiseks.<\/p>\n<h2>Mis on sisu p\u00f5hine sildistamine?<\/h2>\n<p>\nNii et, mis on sisu p\u00f5hine sildistamine \u2014 sildistamine sisu p\u00f5hjal.<\/p>\n<p>Docker-t\u00e4gide loomiseks ei kasutata Git'i primitiive (Git-haru, Git-tagi...), vaid kontrollsumma, mis on seotud:<\/p>\n<ul>\n<li> <i>pildi sisuga<\/i>. Pildi sildi identifikaator peegeldab selle sisu. Uue versiooni ehitamisel ei muutu see identifikaator, kui pildis ei muutu failid;<\/li>\n<li> <i>selle pildi loomise ajalooga Git'is<\/i>. Erinevatesse Git-harudesse ja erineva ehitusajaloo kaudu werf seotud pildid omavad erinevaid sildi identifikaatoreid.<\/li>\n<\/ul>\n<p>\nSellise identifikaatori sildina esindab nii \u00f6eldud <b>etapi allkiri<\/b>.<\/p>\n<p>Iga pilt koosneb etappide kogumist: <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> jne. Igal etapil on identifikaator, mis peegeldab selle sisu \u2014 <b>etapi allkiri<\/b> <i>(etapi allkiri)<\/i>.<\/p>\n<p>L\u00f5plik pilt, mis koosneb nendest etappidest, on sildistatud nii \u00f6eldud etappide kogumi allkirja \u2014 <b>etappide allkiri<\/b>, \u2014 mis on \u00fcldine k\u00f5igi pildi etappide jaoks.<\/p>\n<p>Igal pildil konfigureerimise j\u00e4rgi <code>werf.yaml<\/code> on tavaliselt oma selline allkiri ja vastavalt Docker-silt.<\/p>\n<p>Etapi allkiri lahendab k\u00f5ik eeltoodud probleemid:<\/p>\n<ul>\n<li> On resistentne t\u00fchi Git-commit'ide suhtes.<\/li>\n<li> On resistentne Git-commit'ide suhtes, mis muudavad faile, mis ei ole pildile asjakohased.<\/li>\n<li> Ei too kaasa probleemi kehtiva pildi versiooni katmisest, kui taask\u00e4ivitada ehitusi vanade Git-commit'ide jaoks harust.<\/li>\n<\/ul>\n<p>\nN\u00fc\u00fcd on see soovitatav m\u00e4rgistamisstrateegia ja seda kasutatakse vaikimisi werf'is k\u00f5igis CI-s\u00fcsteemides.<\/p>\n<h2>Kuidas lubada ja kasutada werf'is<\/h2>\n<p>\nTegelikult sai see valik meeskonna poolt <code>werf publish<\/code>: <code>--tag-by-stages-signature=true|false<\/code><\/p>\n<p>CI-s\u00fcsteemis m\u00e4\u00e4ratakse m\u00e4rgistamisstrateegia k\u00e4suga <code>werf ci-env<\/code>. Varem m\u00e4\u00e4rati selle jaoks parameeter <code>werf ci-env --tagging-strategy=tag-or-branch<\/code>. N\u00fc\u00fcd, kui n\u00e4idatakse <code>werf ci-env --tagging-strategy=stages-signature<\/code> v\u00f5i ei n\u00e4idata seda valikut, siis werf kasutab vaikimisi m\u00e4rgistamisstrateegiat <code>stages-signature<\/code>. K\u00e4sk <code>werf ci-env<\/code> seadistab automaatselt vajalikud lipud k\u00e4sule <code>werf build-and-publish<\/code> (v\u00f5i <code>werf publish<\/code>), seega ei ole nende k\u00e4skude jaoks t\u00e4iendavaid valikuid vaja n\u00e4idata.<\/p>\n<p>N\u00e4iteks k\u00e4sk:<\/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 v\u00f5ib luua j\u00e4rgmised kujutised:<\/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>\nSiin <code>4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d<\/code> \u2014 see on pildistamise etapi signatuur <code>backend<\/code>, vaid <code>f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6<\/code> \u2014 etapi signatuur pildi jaoks <code>frontend<\/code>.<\/p>\n<p>Kasutades spetsiaalseid funktsioone <code>werf_container_image<\/code> ja <code>werf_container_env<\/code> Helmi mallides ei pea midagi muutma: need funktsioonid genereerivad automaatselt \u00f5iged pildinimed.<\/p>\n<p>N\u00e4ide CI-s\u00fcsteemi konfiguratsioonist:<\/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>\nRohkema teabe jaoks seadistamise kohta on saadaval dokumentatsioon:<\/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\">K\u00e4itusviis \u2192 Avaldamine (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\">T\u00f6\u00f6tamine CI\/CD \u2192 \u00dclevaade \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\">Integratsioon GitLab CI\/CD-ga \u2192 .gitlab-ci.yml<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Kokkuv\u00f5ttes<\/h2>\n<p><\/p>\n<ul>\n<li> Uus valik <code>werf publish --tag-by-stages-signature=true|false<\/code>.<\/li>\n<li> Uue valiku v\u00e4\u00e4rtus <code>werf ci-env --tagging-strategy=stages-signature|tag-or-branch<\/code> (kui ei n\u00e4idata, siis kasutatakse vaikimisi <code>stages-signature<\/code>).<\/li>\n<li> Kui varem kasutati Git-kinnitustega m\u00e4rgistamisvalikuid (<code>WERF_TAG_GIT_COMMIT<\/code> v\u00f5i valikut <code>werf publish --tag-git-commit COMMIT<\/code>), peab kindlasti \u00fcle minema m\u00e4rgistamisstrateegiale <i>stages-signature<\/i>.<\/li>\n<li> Uued projektid on parem kohe uuele m\u00e4rgistamisstruktuurile \u00fcle viia.<\/li>\n<li> Vanad projektid oleks soovitatav viia over werf 1.1, kuid vana <i>tag-or-branch<\/i> j\u00e4tkub endiselt.<\/li>\n<\/ul>\n<p>\nSisu p\u00f5hine m\u00e4rgistamine lahendab artiklis k\u00e4sitletud k\u00f5ik probleemid:<\/p>\n<ul>\n<li> Docker-tagi nime vastupidavus t\u00fchjade Git-kinnituste suhtes.<\/li>\n<li> Docker-tagi nime vastupidavus Git-kinnituste suhtes, mis muudavad mitteolulisi faile pildile.<\/li>\n<li> Ei tekita probleeme, kui vana Git-commitide jaoks k\u00e4ivitate ehitusi ja versiooni pildistamine ei toimi.<\/li>\n<\/ul>\n<p>\nKasutage! Ja \u00e4rge unustage meid k\u00fclastada <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, et luua issue v\u00f5i leida juba olemasolev, anda pluss, luua PR v\u00f5i lihtsalt j\u00e4lgida projekti arengut.<\/p>\n<h2>P.S.<\/h2>\n<p>\nLugege ka meie blogist:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/493170\/\">werf 1.1 v\u00e4ljaanne: t\u00e4na t\u00e4iustused ehitajale ja tulevikuplaanid<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">Esitleme werf 1.0 stabiilset versiooni: mis on GitOps, olek ja plaanid<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/460351\/\">werf \u2014 meie t\u00f6\u00f6riist CI\/CD jaoks Kuberneteses (\u00fclevaade ja video ettekandest)<\/a><\/noindex>\u00bb;<\/li>\n<li> Uuenduste m\u00e4rkmete ts\u00fckkel werf-is:\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/476646\/\">3-way merge werf-is: Kubernetesesse installimine koos Helmiga 'steroidide peal'<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468049\/\">werf-i kasutamine keerukate Helm-chartide jaoks<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465131\/\">Toetamine monorepo ja multirepo werf-is ning kuidas see on seotud Docker Registryga<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/463613\/\">Saate n\u00fc\u00fcd Docker-pilte werf-is ehitada ka tavalise Dockerfile'i abil<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Allikas: <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.1.1 - 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\/et\/blog\/administrirovanie\/content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\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\/et\/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\udd47Sisu p\u00f5hine m\u00e4rgistamine werf-i ehitajas: miks ja kuidas see toimib? | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/et\/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":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\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\/et\/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\/et\/wp-json\/wp\/v2\/posts\/76769","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=76769"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/76769\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/76770"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=76769"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=76769"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=76769"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}