{"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\/fr\/blog\/administrirovanie\/content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet","title":{"rendered":"Tagging bas\u00e9 sur le contenu dans l'assembleur werf : pourquoi et comment cela fonctionne-t-il ?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Tagging bas\u00e9 sur le contenu dans l&#039;assembleur werf : pourquoi et comment cela fonctionne-t-il ?\" 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 notre utilitaire GitOps CLI open source pour la construction et la livraison d'applications dans Kubernetes. Dans <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/493170\/\">la version v1.1<\/a><\/noindex> , une nouvelle fonctionnalit\u00e9 a \u00e9t\u00e9 introduite dans l'assembleur d'images : le taggage d'images bas\u00e9 sur le contenu ou <i>content-based tagging<\/i>. Jusqu'\u00e0 pr\u00e9sent, le sch\u00e9ma de taggage typique dans werf supposait le taggage des images Docker par le tag Git, la branche Git ou le commit Git. Mais chacun de ces sch\u00e9mas pr\u00e9sente des inconv\u00e9nients qui sont enti\u00e8rement r\u00e9solus par la nouvelle strat\u00e9gie de taggage. Les d\u00e9tails \u00e0 ce sujet et ce qui la rend si bonne \u2014 ci-dessous.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>D\u00e9ploiement d'un ensemble de microservices depuis un seul d\u00e9p\u00f4t Git<\/h2>\n<p>\nIl est courant que les applications soient divis\u00e9es en plusieurs services, plus ou moins ind\u00e9pendants. Les releases de ces services peuvent se faire ind\u00e9pendamment : un ou plusieurs services peuvent \u00eatre publi\u00e9s en m\u00eame temps, tandis que les autres doivent continuer \u00e0 fonctionner sans aucune modification. Cependant, en ce qui concerne le stockage du code et la gestion des projets, il est plus pratique de garder ces services d'application dans un seul d\u00e9p\u00f4t.<\/p>\n<p>Il y a des cas o\u00f9 les services sont r\u00e9ellement ind\u00e9pendants et ne sont pas li\u00e9s \u00e0 une seule application. Dans ce cas, ils seront situ\u00e9s dans des projets distincts et leur publication se fera par des processus CI\/CD s\u00e9par\u00e9s dans chacun des projets.<\/p>\n<p>Cependant, dans la r\u00e9alit\u00e9, les d\u00e9veloppeurs segmentent souvent une application unique en plusieurs microservices, mais cr\u00e9er un d\u00e9p\u00f4t et un projet distinct pour chacun\u2026 \u2014 est clairement excessif. C'est pr\u00e9cis\u00e9ment cette situation qui sera abord\u00e9e ici : plusieurs de ces microservices r\u00e9sident dans un d\u00e9p\u00f4t unique du projet et les releases se font \u00e0 travers un seul processus dans le CI\/CD.<\/p>\n<h3>Taggage par branche Git et tag Git<\/h3>\n<p>\nSupposons que la strat\u00e9gie de taggage la plus courante soit <i>tag-or-branch<\/i>. Pour les branches Git, les images sont tagg\u00e9es avec le nom de la branche, pour une branche donn\u00e9e, il n'existe \u00e0 un moment donn\u00e9 qu'une seule image publi\u00e9e au nom de cette branche. Pour les tags Git, les images sont tagg\u00e9es respectivement avec le nom du tag.<\/p>\n<p>Lorsqu'un nouveau tag Git est cr\u00e9\u00e9 \u2014 par exemple, lors de la sortie d'une nouvelle version \u2014 un nouveau tag Docker sera cr\u00e9\u00e9 pour toutes les images du projet dans le registre 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>\nCes nouveaux noms d'image passent par des mod\u00e8les Helm dans la configuration Kubernetes. Lors du lancement du d\u00e9ploiement avec la commande <code>werf deploy<\/code> la mise \u00e0 jour du champ <code>image<\/code> dans les manifestes des ressources Kubernetes et le red\u00e9marrage des ressources correspondantes en raison du changement de nom de l'image.<\/p>\n<p><b>Le probl\u00e8me<\/b>: dans le cas o\u00f9 le contenu de l'image n'a pas r\u00e9ellement chang\u00e9 depuis le dernier d\u00e9ploiement (tag Git), mais seulement son tag Docker, il se produit <i>un red\u00e9marrage<\/i> inutiles de cette application et, par cons\u00e9quent, il peut y avoir quelques interruptions. Bien qu'il n'y ait eu aucune raison r\u00e9elle de proc\u00e9der \u00e0 ce red\u00e9marrage.<\/p>\n<p>En cons\u00e9quence, avec le sch\u00e9ma de tagging actuel, il est n\u00e9cessaire de g\u00e9rer plusieurs d\u00e9p\u00f4ts Git distincts, ce qui pose le probl\u00e8me de l'organisation du d\u00e9ploiement de ces plusieurs d\u00e9p\u00f4ts. Dans l'ensemble, ce sch\u00e9ma devient encombr\u00e9 et complexe. Il est pr\u00e9f\u00e9rable de regrouper plusieurs services dans un seul d\u00e9p\u00f4t et de cr\u00e9er des tags Docker de sorte qu'il n'y ait pas de red\u00e9marrages inutiles.<\/p>\n<h3>Tagging par commit Git<\/h3>\n<p>\nIl existe \u00e9galement une strat\u00e9gie de tagging dans werf li\u00e9e aux commits Git.<\/p>\n<p>Un commit Git est un identifiant du contenu dans le d\u00e9p\u00f4t Git et d\u00e9pend de l'historique des modifications des fichiers dans le d\u00e9p\u00f4t Git, il semble donc logique de l'utiliser pour taguer les images dans le Docker Registry.<\/p>\n<p>Cependant, le tagging par commit Git pr\u00e9sente les m\u00eames inconv\u00e9nients que le tagging par branches Git ou par tags Git :<\/p>\n<ul>\n<li> Un commit vide pourrait avoir \u00e9t\u00e9 cr\u00e9\u00e9, sans modifier les fichiers, mais le tag Docker de l'image sera modifi\u00e9.<\/li>\n<li> Un commit de fusion pourrait avoir \u00e9t\u00e9 cr\u00e9\u00e9, sans modifier les fichiers, mais le tag Docker de l'image sera modifi\u00e9.<\/li>\n<li> Un commit pourrait avoir \u00e9t\u00e9 cr\u00e9\u00e9, modifiant des fichiers dans Git qui ne sont pas inclus dans l'image, et le tag Docker de l'image sera encore modifi\u00e9.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Le tagging par nom de branche Git ne refl\u00e8te pas la version de l'image.<\/h2>\n<p>\nIl y a aussi un autre probl\u00e8me li\u00e9 \u00e0 la strat\u00e9gie de tagging par branches Git.<\/p>\n<p>Le tagging par nom de branche fonctionne tant que les commits de cette branche sont r\u00e9cup\u00e9r\u00e9s successivement dans l'ordre chronologique.<\/p>\n<p>Si, dans le sch\u00e9ma actuel, un utilisateur relance la reconstruction d'un ancien commit li\u00e9 \u00e0 une certaine branche, werf \u00e9crasera l'image par le tag Docker correspondant avec la nouvelle version de l'image pour l'ancien commit. Les d\u00e9ploiements utilisant ce tag risquent donc, lors du red\u00e9marrage des pods, de tirer une autre version de l'image, ce qui peut entra\u00eener une perte de connexion avec le syst\u00e8me CI et une d\u00e9synchronisation de notre application.<\/p>\n<p>De plus, lors de push successifs dans une branche avec un court intervalle de temps entre eux, un ancien commit peut \u00eatre reconstruit apr\u00e8s un plus r\u00e9cent : l'ancienne version de l'image \u00e9crasera la nouvelle par le tag de la branche Git. Ces probl\u00e8mes peuvent \u00eatre g\u00e9r\u00e9s par un syst\u00e8me CI\/CD (par exemple, dans GitLab CI, un pipeline est lanc\u00e9 pour une s\u00e9rie de commits). Cependant, toutes les syst\u00e8mes ne le prennent pas en charge et il devrait y avoir un moyen plus fiable de pr\u00e9venir un probl\u00e8me aussi fondamental.<\/p>\n<h2>Qu'est-ce que le tagging bas\u00e9 sur le contenu ?<\/h2>\n<p>\nAinsi, qu'est-ce que le tagging bas\u00e9 sur le contenu \u2014 le tagging des images par leur contenu.<\/p>\n<p>Pour cr\u00e9er des tags Docker, on utilise non pas des primitives de Git (branche Git, tag Git\u2026), mais une somme de contr\u00f4le associ\u00e9e \u00e0 :<\/p>\n<ul>\n<li> <i>le contenu de l'image<\/i>. L'identifiant-tag de l'image refl\u00e8te son contenu. Lors de la construction d'une nouvelle version, cet identifiant ne changera pas si les fichiers de l'image n'ont pas \u00e9t\u00e9 modifi\u00e9s ;<\/li>\n<li> <i>l'historique de cr\u00e9ation de cette image dans Git<\/i>. Les images li\u00e9es \u00e0 diff\u00e9rentes branches Git et \u00e0 diff\u00e9rents historiques de construction via werf auront des identifiants-tags diff\u00e9rents.<\/li>\n<\/ul>\n<p>\nEn tant que tel, l'identifiant-tag est ce que l'on appelle une <b>signature des \u00e9tapes de l'image<\/b>.<\/p>\n<p>Chaque image est compos\u00e9e d'un ensemble d'\u00e9tapes : <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> etc. Chaque \u00e9tape a un identifiant qui refl\u00e8te son contenu \u2014 <b>signature de l'\u00e9tape<\/b> <i>(signature de l'\u00e9tape)<\/i>.<\/p>\n<p>L'image finale, compos\u00e9e de ces \u00e9tapes, est tagu\u00e9e par ce qu'on appelle la signature de l'ensemble de ces \u00e9tapes \u2014 <b>signature des \u00e9tapes<\/b>, \u2014 qui est g\u00e9n\u00e9ralisante pour toutes les \u00e9tapes de l'image.<\/p>\n<p>Chaque image de la configuration <code>werf.yaml<\/code> a en g\u00e9n\u00e9ral sa propre signature, et donc, son tag Docker.<\/p>\n<p>La signature des \u00e9tapes r\u00e9sout tous les probl\u00e8mes \u00e9nonc\u00e9s :<\/p>\n<ul>\n<li> Elle est r\u00e9sistante aux commits Git vides.<\/li>\n<li> Elle est r\u00e9sistante aux commits Git qui modifient des fichiers n'\u00e9tant pas pertinents pour l'image.<\/li>\n<li> Elle ne provoque pas de probl\u00e8me d'\u00e9crasement de la version actuelle de l'image lors du red\u00e9marrage des construits pour d'anciens commits Git de la branche.<\/li>\n<\/ul>\n<p>\nC'est maintenant la strat\u00e9gie de tagging recommand\u00e9e et utilis\u00e9e par d\u00e9faut dans werf pour tous les syst\u00e8mes CI.<\/p>\n<h2>Comment l'activer et l'utiliser dans werf<\/h2>\n<p>\nL'option correspondante est apparue pour la commande <code>werf publish<\/code>: <code>--tag-by-stages-signature=true|false<\/code><\/p>\n<p>Dans le syst\u00e8me CI, la strat\u00e9gie de tagging est d\u00e9finie par la commande <code>werf ci-env<\/code>. Auparavant, pour cela, un param\u00e8tre \u00e9tait d\u00e9fini <code>werf ci-env --tagging-strategy=tag-or-branch<\/code>. Maintenant, si vous indiquez <code>werf ci-env --tagging-strategy=stages-signature<\/code> ou si vous ne sp\u00e9cifiez pas cette option, werf utilisera par d\u00e9faut la strat\u00e9gie de tagging <code>stages-signature<\/code>. La commande <code>werf ci-env<\/code> ajoutera automatiquement les bonnes options pour la commande <code>werf build-and-publish<\/code> ou <code>werf publish<\/code>), donc aucune option suppl\u00e9mentaire pour ces commandes n'est n\u00e9cessaire.<\/p>\n<p>Par exemple, la commande :<\/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 peut cr\u00e9er les images suivantes :<\/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>\nIci <code>4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d<\/code> \u2014 c'est la signature de la phase de l'image <code>backend<\/code>, et <code>f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6<\/code> \u2014 signature de la phase de l'image <code>frontend<\/code>.<\/p>\n<p>Lors de l'utilisation de fonctionnalit\u00e9s sp\u00e9ciales <code>werf_container_image<\/code> et <code>werf_container_env<\/code> dans les mod\u00e8les Helm, rien n'a besoin d'\u00eatre chang\u00e9 : ces fonctions g\u00e9n\u00e9reront automatiquement les bons noms d'images.<\/p>\n<p>Exemple de configuration dans le syst\u00e8me 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>\nPlus d'informations sur la configuration sont disponibles dans la documentation :<\/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\">Guide \u2192 Publication (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\">Travailler avec CI\/CD \u2192 Informations g\u00e9n\u00e9rales \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\">Int\u00e9gration avec GitLab CI\/CD \u2192 .gitlab-ci.yml<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Au total<\/h2>\n<p><\/p>\n<ul>\n<li> Une nouvelle option <code>werf publish --tag-by-stages-signature=true|false<\/code>.<\/li>\n<li> Nouvelle valeur de l'option <code>werf ci-env --tagging-strategy=stages-signature|tag-or-branch<\/code> (si non sp\u00e9cifi\u00e9, alors par d\u00e9faut \u00e7a sera <code>stages-signature<\/code>).<\/li>\n<li> Si auparavant des options de tagging bas\u00e9es sur les commits Git \u00e9taient utilis\u00e9es (<code>WERF_TAG_GIT_COMMIT<\/code> ou option <code>werf publish --tag-git-commit COMMIT<\/code>), il est imp\u00e9ratif de passer \u00e0 la strat\u00e9gie de tagging <i>stages-signature<\/i>.<\/li>\n<li> Il est pr\u00e9f\u00e9rable de passer imm\u00e9diatement les nouveaux projets \u00e0 ce nouveau sch\u00e9ma de tagging.<\/li>\n<li> Pour les anciens projets convertis vers werf 1.1, il est conseill\u00e9 de passer au nouveau sch\u00e9ma de tagging, mais l'ancien <i>tag-or-branch<\/i> est toujours pris en charge.<\/li>\n<\/ul>\n<p>\nLe tagging bas\u00e9 sur le contenu r\u00e9sout tous les probl\u00e8mes abord\u00e9s dans l'article :<\/p>\n<ul>\n<li> La r\u00e9sistance du nom du tag Docker aux commits Git vides.<\/li>\n<li> La r\u00e9sistance du nom du tag Docker aux commits Git qui modifient des fichiers non pertinents pour l'image.<\/li>\n<li> Ne provoque pas de probl\u00e8me avec l'\u00e9crasement de la version actuelle de l'image lors du red\u00e9marrage des builds pour d'anciens commits Git sur des branches Git.<\/li>\n<\/ul>\n<p>\nProfitez-en ! Et n'oubliez pas de passer chez nous sur <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, pour cr\u00e9er une issue ou trouver d\u00e9j\u00e0 existante, mettre un like, cr\u00e9er une PR ou simplement observer l'\u00e9volution du projet.<\/p>\n<h2>P.S.<\/h2>\n<p>\nLisez aussi dans notre blog :<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/493170\/\">Version 1.1 de werf : am\u00e9liorations dans l'assembleur aujourd'hui et plans futurs<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">Nous vous pr\u00e9sentons werf 1.0 stable : quel est le rapport avec GitOps, le statut et les plans<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/460351\/\">werf est notre outil pour CI\/CD dans Kubernetes (aper\u00e7u et vid\u00e9o de la pr\u00e9sentation).<\/a><\/noindex>\u00bb;<\/li>\n<li> Utilisation de werf pour le d\u00e9ploiement de charts Helm complexes\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/476646\/\">Fusion \u00e0 trois voies dans werf : d\u00e9ploiement dans Kubernetes avec Helm \u00ab sur st\u00e9ro\u00efdes \u00bb<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468049\/\">Utilisation de werf pour le d\u00e9ploiement de charts Helm complexes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465131\/\">Support monorepo et multirepo dans werf et quel rapport avec Docker Registry<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/463613\/\">Il est d\u00e9sormais possible de cr\u00e9er des images Docker dans werf en utilisant un Dockerfile classique.<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Source : <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.2 - 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\/fr\/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.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"fr_FR\" \/>\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\/fr\/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\udd47Tagging bas\u00e9 sur le contenu dans le builder werf : pourquoi et comment cela fonctionne ? | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/fr\/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":"fr_FR","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\/fr\/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\/fr\/wp-json\/wp\/v2\/posts\/76769","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=76769"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/76769\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/76770"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=76769"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=76769"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=76769"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}