{"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\/pl\/blog\/administrirovanie\/content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet","title":{"rendered":"Tagowanie oparte na zawarto\u015bci w zbieraczu werf: po co i jak to dzia\u0142a?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Tagowanie oparte na zawarto\u015bci w zbieraczu werf: po co i jak to dzia\u0142a?\" 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 nasze narz\u0119dzie CLI GitOps z otwartym kodem \u017ar\u00f3d\u0142owym do budowania i dostarczania aplikacji w Kubernetes. W <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/493170\/\">wydaniu v1.1<\/a><\/noindex> wprowadzono now\u0105 funkcj\u0119 w budowniczym obraz\u00f3w: tagowanie obraz\u00f3w na podstawie zawarto\u015bci lub <i>tagowania opartego na zawarto\u015bci<\/i>. Dotychczas typowy schemat tagowania w werf zak\u0142ada\u0142 tagowanie obraz\u00f3w Docker na podstawie tagu Git, ga\u0142\u0119zi Git lub commit'u Git. Jednak wszystkie te schematy maj\u0105 wady, kt\u00f3re s\u0105 w pe\u0142ni rozwi\u0105zywane przez now\u0105 strategi\u0119 tagowania. Szczeg\u00f3\u0142y na jej temat i co sprawia, \u017ce jest tak dobra \u2014 znajduj\u0105 si\u0119 poni\u017cej.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Wydanie zestawu mikrous\u0142ug z jednego repozytorium Git<\/h2>\n<p>\nCz\u0119sto zdarza si\u0119 sytuacja, w kt\u00f3rej aplikacja jest podzielona na wiele bardziej lub mniej niezale\u017cnych us\u0142ug. Wydania tych us\u0142ug mog\u0105 odbywa\u0107 si\u0119 niezale\u017cnie: jednocze\u015bnie mo\u017ce by\u0107 wydawana jedna lub kilka us\u0142ug, podczas gdy pozosta\u0142e musz\u0105 dzia\u0142a\u0107 bez \u017cadnych zmian. Ale z punktu widzenia przechowywania kodu i zarz\u0105dzania projektem wygodniej jest trzyma\u0107 takie us\u0142ugi aplikacji w jednym repozytorium.<\/p>\n<p>S\u0105 sytuacje, gdy us\u0142ugi s\u0105 rzeczywi\u015bcie niezale\u017cne i nie s\u0105 zwi\u0105zane z jedn\u0105 aplikacj\u0105. W takim przypadku b\u0119d\u0105 one zlokalizowane w oddzielnych projektach, a ich wydanie b\u0119dzie realizowane za pomoc\u0105 oddzielnych proces\u00f3w CI\/CD w ka\u017cdym z projekt\u00f3w.<\/p>\n<p>Jednak w rzeczywisto\u015bci deweloperzy cz\u0119sto dziel\u0105 jedno aplikacj\u0119 na kilka mikrous\u0142ug, ale zak\u0142adanie oddzielnego repozytorium i projektu dla ka\u017cdej z nich... \u2014 to oczywiste nadmiarowe dzia\u0142anie. To w\u0142a\u015bnie o tej sytuacji b\u0119dzie mowa dalej: kilka takich mikrous\u0142ug znajduje si\u0119 w jednym repozytorium projektu, a wydania odbywaj\u0105 si\u0119 za pomoc\u0105 jednego procesu w CI\/CD.<\/p>\n<h3>Tagowanie wed\u0142ug ga\u0142\u0119zi Git i tagu Git<\/h3>\n<p>\nZa\u0142\u00f3\u017cmy, \u017ce u\u017cywana jest najcz\u0119\u015bciej spotykana strategia tagowania \u2014 <i>tag-or-branch<\/i>. Dla ga\u0142\u0119zi Git obrazy s\u0105 tagowane nazw\u0105 ga\u0142\u0119zi, dla jednej ga\u0142\u0119zi w danym momencie istnieje tylko jeden opublikowany obraz o nazwie tej ga\u0142\u0119zi. Dla tag\u00f3w Git obrazy s\u0105 tagowane zgodnie z nazw\u0105 tagu.<\/p>\n<p>Przy tworzeniu nowego tagu Git \u2014 na przyk\u0142ad przy wydaniu nowej wersji \u2014 dla wszystkich obraz\u00f3w projektu w Docker Registry zostanie utworzony nowy tag Docker:<\/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>\nTe nowe nazwy obraz\u00f3w trafiaj\u0105 przez szablony Helm do konfiguracji Kubernetes. Przy uruchomieniu wdro\u017cenia poleceniem <code>werf deploy<\/code> nast\u0119puje aktualizacja pola <code>image<\/code> w manifestach zasob\u00f3w Kubernetes i ponowne uruchomienie odpowiednich zasob\u00f3w w zwi\u0105zku ze zmienion\u0105 nazw\u0105 obrazu.<\/p>\n<p><b>Problem<\/b>: w przypadku, gdy rzeczywi\u015bcie zawarto\u015b\u0107 obrazu nie zmieni\u0142a si\u0119 od poprzedniego wdro\u017cenia (tagu Git), a jedynie jego tag Docker, nast\u0119puje <i>niepotrzebne<\/i> ponowne uruchomienie tej aplikacji i w zwi\u0105zku z tym mo\u017cliwy jest pewien przest\u00f3j. Chocia\u017c nie by\u0142o \u017cadnych rzeczywistych powod\u00f3w do przeprowadzania tego ponownego uruchomienia.<\/p>\n<p>W konsekwencji, przy obecnej schemacie tagowania musimy tworzy\u0107 kilka oddzielnych repozytori\u00f3w Git, co rodzi problem organizacji wdro\u017cenia tych kilku repozytori\u00f3w. Og\u00f3lnie rzecz bior\u0105c, taka schemat wydaje si\u0119 by\u0107 przeci\u0105\u017cony i skomplikowany. Lepiej jest \u0142\u0105czy\u0107 wiele us\u0142ug w jedno repozytorium i tworzy\u0107 takie tagi Docker, aby unikn\u0105\u0107 niepotrzebnych ponownych uruchomie\u0144.<\/p>\n<h3>Tagowanie przez commit Git<\/h3>\n<p>\nW werf r\u00f3wnie\u017c istnieje strategia tagowania zwi\u0105zana z commitami Git.<\/p>\n<p>Commit Git jest identyfikatorem zawarto\u015bci repozytorium Git i zale\u017cy od historii edycji plik\u00f3w w repozytorium Git, dlatego wydaje si\u0119 logiczne u\u017cywa\u0107 go do tagowania obraz\u00f3w w Docker Registry.<\/p>\n<p>Jednak tagowanie wed\u0142ug commit\u00f3w Git ma te same wady, co tagowanie wed\u0142ug ga\u0142\u0119zi Git lub tag\u00f3w Git:<\/p>\n<ul>\n<li> M\u00f3g\u0142 zosta\u0107 utworzony pusty commit, kt\u00f3ry nie zmienia plik\u00f3w, a tag Docker obrazu zostanie zmieniony.<\/li>\n<li> M\u00f3g\u0142 zosta\u0107 utworzony commit merge, kt\u00f3ry nie zmienia plik\u00f3w, a tag Docker obrazu zostanie zmieniony.<\/li>\n<li> M\u00f3g\u0142 zosta\u0107 utworzony commit, kt\u00f3ry zmienia te pliki w Git, kt\u00f3re nie s\u0105 importowane do obrazu, a tag Docker obrazu zn\u00f3w zostanie zmieniony.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Tagowanie wed\u0142ug nazwy ga\u0142\u0119zi Git nie odzwierciedla wersji obrazu<\/h2>\n<p>\nJest jeszcze jeden problem zwi\u0105zany ze strategi\u0105 tagowania wed\u0142ug ga\u0142\u0119zi Git.<\/p>\n<p>Tagowanie wed\u0142ug nazwy ga\u0142\u0119zi dzia\u0142a, dop\u00f3ki commity tej ga\u0142\u0119zi s\u0105 zbierane sukcesywnie w porz\u0105dku chronologicznym.<\/p>\n<p>Je\u015bli u\u017cytkownik uruchomi ponowne zbudowanie starego commita zwi\u0105zanego z okre\u015blon\u0105 ga\u0142\u0119zi\u0105 w bie\u017c\u0105cym schemacie, werf nadpisze obraz odpowiednim Docker-tagiem now\u0105 wersj\u0105 obrazu dla starego commita. U\u017cywaj\u0105ce tego tagu deploymenty od tego momentu ryzykuj\u0105 podczas ponownego uruchamiania pod\u00f3w pobranie innej wersji obrazu, w wyniku czego nasza aplikacja straci po\u0142\u0105czenie z systemem CI i ulegnie desynchronizacji.<\/p>\n<p>Ponadto, podczas kolejnych push\u00f3w do jednej ga\u0142\u0119zi z niewielkim odst\u0119pem czasu mi\u0119dzy nimi, starszy commit mo\u017ce zosta\u0107 zbudowany p\u00f3\u017aniej ni\u017c nowszy: starsza wersja obrazu nadpisze now\u0105 wed\u0142ug tagu ga\u0142\u0119zi Git. Takie problemy mo\u017ce rozwi\u0105za\u0107 system CI\/CD (na przyk\u0142ad w GitLab CI dla serii commit\u00f3w uruchamiany jest pipeline ostatniego). Nie wszystkie systemy to wspieraj\u0105, dlatego potrzebny jest bardziej niezawodny spos\u00f3b zapobiegania tej fundamentalnej problematyce.<\/p>\n<h2>Co to jest oznaczanie oparte na tre\u015bci?<\/h2>\n<p>\nZatem czym jest oznaczanie oparte na tre\u015bci \u2014 tagowanie obraz\u00f3w wed\u0142ug zawarto\u015bci.<\/p>\n<p>Do tworzenia Docker-tag\u00f3w u\u017cywane s\u0105 nie prymitywy Gita (ga\u0142\u0105\u017a Git, tag Git\u2026), lecz suma kontrolna zwi\u0105zana z:<\/p>\n<ul>\n<li> <i>zawarto\u015bci\u0105 obrazu<\/i>. Identyfikator-tagu obrazu odzwierciedla jego zawarto\u015b\u0107. Podczas budowy nowej wersji ten identyfikator nie zmieni si\u0119, je\u015bli w obrazie nie zmieni\u0142y si\u0119 pliki;<\/li>\n<li> <i>histori\u0105 tworzenia tego obrazu w Gicie<\/i>. Obrazy zwi\u0105zane z r\u00f3\u017cnymi ga\u0142\u0119ziami Gita i r\u00f3\u017cn\u0105 histori\u0105 budowy poprzez werf b\u0119d\u0105 mia\u0142y r\u00f3\u017cne identyfikatory-tag\u00f3w.<\/li>\n<\/ul>\n<p>\nJako taki identyfikator-tagu wyst\u0119puje tzw. <b>sygnatura etap\u00f3w obrazu<\/b>.<\/p>\n<p>Ka\u017cdy obraz sk\u0142ada si\u0119 z zestawu etap\u00f3w: <code>od<\/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> i.t.d. Ka\u017cdy etap ma identyfikator, kt\u00f3ry odzwierciedla jego zawarto\u015b\u0107, \u2014 <b>sygnatura etapu<\/b> <i>(stage signature)<\/i>.<\/p>\n<p>Finalny obraz, z\u0142o\u017cony z tych etap\u00f3w, jest tagowany tzw. sygnatur\u0105 zestawu tych etap\u00f3w \u2014 <b>sygnatura etap\u00f3w<\/b>, \u2014 kt\u00f3ra jest uog\u00f3lniaj\u0105ca dla wszystkich etap\u00f3w obrazu.<\/p>\n<p>Ka\u017cdy obraz z konfiguracji <code>werf.yaml<\/code> w og\u00f3lnym przypadku b\u0119dzie mia\u0142 swoj\u0105 sygnatur\u0119 i odpowiednio, tag Docker.<\/p>\n<p>Sygnatura etap\u00f3w rozwi\u0105zuje wszystkie wymienione problemy:<\/p>\n<ul>\n<li> Jest odporna na puste commity Git.<\/li>\n<li> Jest odporna na commity Git, kt\u00f3re zmieniaj\u0105 pliki, kt\u00f3re nie s\u0105 istotne dla obrazu.<\/li>\n<li> Nie prowadzi do problemu z nadpisywaniem aktualnej wersji obrazu podczas ponownego uruchamiania bud\u00f3w dla starszych commit\u00f3w ga\u0142\u0119zi.<\/li>\n<\/ul>\n<p>\nTeraz to jest zalecana strategia tagowania i jest u\u017cywana domy\u015blnie w werf dla wszystkich system\u00f3w CI.<\/p>\n<h2>Jak w\u0142\u0105czy\u0107 i u\u017cywa\u0107 w werf<\/h2>\n<p>\nOdpowiednia opcja pojawi\u0142a si\u0119 w poleceniu <code>werf publish<\/code>: <code>--tag-by-stages-signature=true|false<\/code><\/p>\n<p>W systemie CI strategi\u0119 tagowania definiuje si\u0119 poleceniem <code>werf ci-env<\/code>. Wcze\u015bniej dla niej definiowano parametr <code>werf ci-env --tagging-strategy=tag-or-branch<\/code>. Teraz, je\u015bli wska\u017anik <code>werf ci-env --tagging-strategy=stages-signature<\/code> lub nie okre\u015bla\u0107 tej opcji, werf domy\u015blnie u\u017cyje strategii tagowania <code>stages-signature<\/code>. Komenda <code>werf ci-env<\/code> automatycznie ustawi potrzebne flagi dla polecenia <code>werf build-and-publish<\/code> (lub <code>werf publish<\/code>), dlatego nie musisz podawa\u0107 dodatkowych opcji dla tych polece\u0144.<\/p>\n<p>Na przyk\u0142ad polecenie:<\/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 mo\u017ce utworzy\u0107 nast\u0119puj\u0105ce obrazy:<\/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>\nTutaj <code>4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d<\/code> \u2014 to jest sygnatura etap\u00f3w obrazu <code>backend<\/code>, a <code>f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6<\/code> \u2014 sygnatura etap\u00f3w obrazu <code>frontend<\/code>.<\/p>\n<p>Przy u\u017cyciu specjalnych funkcji <code>werf_container_image<\/code> i <code>werf_container_env<\/code> w szablonach Helm nie trzeba nic zmienia\u0107: te funkcje b\u0119d\u0105 automatycznie generowa\u0107 prawid\u0142owe nazwy obraz\u00f3w.<\/p>\n<p>Przyk\u0142ad konfiguracji w systemie CI:<\/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>\nWi\u0119cej informacji na temat konfiguracji dost\u0119pne jest w dokumentacji:<\/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\">Podr\u0119cznik \u2192 Publikacja (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\">Praca z CI\/CD \u2192 Informacje og\u00f3lne \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\">Integracja z GitLab CI\/CD \u2192 .gitlab-ci.yml<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Podsumowuj\u0105c<\/h2>\n<p><\/p>\n<ul>\n<li> Nowa opcja <code>werf publish --tag-by-stages-signature=true|false<\/code>.<\/li>\n<li> Nowa warto\u015b\u0107 opcji <code>werf ci-env --tagging-strategy=stages-signature|tag-or-branch<\/code> (je\u015bli nie podano, to domy\u015blnie b\u0119dzie <code>stages-signature<\/code>).<\/li>\n<li> Je\u015bli wcze\u015bniej u\u017cywano opcji tagowania wed\u0142ug commit\u00f3w Git (<code>WERF_TAG_GIT_COMMIT<\/code> lub opcja <code>werf publish --tag-git-commit COMMIT<\/code>), konieczne jest prze\u0142\u0105czenie na strategi\u0119 tagowania <i>stages-signature<\/i>.<\/li>\n<li> Nowe projekty najlepiej od razu prze\u0142\u0105cza\u0107 na now\u0105 schem\u0119 tagowania.<\/li>\n<li> Stare projekty przy migracji na werf 1.1 nale\u017cy prze\u0142\u0105cza\u0107 na now\u0105 schem\u0119 tagowania, jednak stara <i>tag-or-branch<\/i> nadal jest wspierana.<\/li>\n<\/ul>\n<p>\nTagowanie oparte na tre\u015bci rozwi\u0105zuje wszystkie opisane w artykule problemy:<\/p>\n<ul>\n<li> Odporno\u015b\u0107 nazwy tagu Docker na puste commity Git.<\/li>\n<li> Odporno\u015b\u0107 nazwy tagu Docker na commity Git, kt\u00f3re zmieniaj\u0105 irrelewantne dla obrazu pliki.<\/li>\n<li> Nie prowadzi do problemu z nadpisywaniem aktualnej wersji obrazu podczas ponownego uruchamiania bud\u00f3w dla starych commit\u00f3w Git dla ga\u0142\u0119zi Git.<\/li>\n<\/ul>\n<p>\nKorzystaj! I nie zapomnij zagl\u0105da\u0107 do nas na <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, aby stworzy\u0107 issue lub znale\u017a\u0107 ju\u017c istniej\u0105ce, postawi\u0107 plus, stworzy\u0107 PR lub po prostu obserwowa\u0107 rozw\u00f3j projektu.<\/p>\n<h2>P.S.<\/h2>\n<p>\nPrzeczytaj tak\u017ce na naszym blogu:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/493170\/\">Wydanie werf 1.1: ulepszenia w kompilatorze oraz plany na przysz\u0142o\u015b\u0107.<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">Prezentujemy werf 1.0 stable: co ma wsp\u00f3lnego z GitOps, status i plany<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/460351\/\">werf \u2014 nasze narz\u0119dzie do CI\/CD w Kubernetes (przegl\u0105d i wideo wyk\u0142adu)<\/a><\/noindex>\u00bb;<\/li>\n<li> Cykl notatek o nowo\u015bciach w werf:\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/476646\/\">Fuzja 3-way w werf: wdro\u017cenie w Kubernetes z Helm \u201ena sterydach\u201d<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468049\/\">U\u017cycie werf do wdra\u017cania z\u0142o\u017conych chart\u00f3w Helm<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465131\/\">Wsparcie dla monorepo i multirepo w werf i jakie ma to znaczenie dla Docker Registry<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/463613\/\">Budowanie obraz\u00f3w Docker w werf jest teraz mo\u017cliwe r\u00f3wnie\u017c za pomoc\u0105 zwyk\u0142ego Dockerfile<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>\u0179r\u00f3d\u0142o: <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\/pl\/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=\"pl_PL\" \/>\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\/pl\/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\udd47Tagowanie oparte na tre\u015bci w narz\u0119dziu werf: po co i jak to dzia\u0142a? | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/pl\/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":"pl_PL","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\/pl\/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\/pl\/wp-json\/wp\/v2\/posts\/76769","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/comments?post=76769"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/76769\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media\/76770"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=76769"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=76769"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=76769"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}