{"id":76764,"date":"2020-04-04T13:42:24","date_gmt":"2020-04-04T11:42:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee"},"modified":"2020-04-04T13:42:24","modified_gmt":"2020-04-04T11:42:24","slug":"reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","title":{"rendered":"Version 1.1 de werf : am\u00e9liorations dans l'assembleur aujourd'hui et plans futurs","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Version 1.1 de werf : am\u00e9liorations dans l&#039;assembleur aujourd&#039;hui et plans futurs\" src=\"\/wp-content\/uploads\/2020\/04\/c7c26e4a0b7bddb90ba087a4db7175dc.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/\">werf<\/a><\/noindex> \u2014 notre outil CLI GitOps open source pour la construction et la livraison d'applications dans Kubernetes. Comme promis, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">la sortie de la version v1.0<\/a><\/noindex> a marqu\u00e9 le d\u00e9but de l'ajout de nouvelles fonctionnalit\u00e9s \u00e0 werf et de la r\u00e9vision des approches habituelles. Nous sommes maintenant ravis de pr\u00e9senter la version v1.1, qui repr\u00e9sente une avanc\u00e9e majeure et une base pour l'avenir. <i>du g\u00e9n\u00e9rateur<\/i> werf. La version est actuellement disponible dans <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">le canal 1.1 ea<\/a><\/noindex>.<\/p>\n<p>La base de la version est une nouvelle architecture de stockage des \u00e9tapes et l'optimisation des deux g\u00e9n\u00e9rateurs (pour Stapel et Dockerfile). La nouvelle architecture de stockage ouvre des possibilit\u00e9s pour la mise en \u0153uvre de constructions distribu\u00e9es \u00e0 partir de plusieurs h\u00f4tes et d'ex\u00e9cutions parall\u00e8les sur un m\u00eame h\u00f4te.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>L'optimisation inclut l'\u00e9limination des calculs inutiles lors du calcul des signatures des \u00e9tapes et la modification des m\u00e9canismes de calcul des sommes de contr\u00f4le des fichiers vers des m\u00e9thodes plus efficaces. Cette optimisation r\u00e9duit le temps moyen de construction d'un projet avec werf. Et les constructions vides, lorsque toutes les \u00e9tapes existent dans le cache <i>stages-storage<\/i>, sont d\u00e9sormais r\u00e9ellement rapides. Dans la plupart des cas, le red\u00e9marrage d'une construction s'effectue en moins d'une seconde ! Cela s'applique \u00e9galement aux proc\u00e9dures de v\u00e9rification des \u00e9tapes lors de l'ex\u00e9cution des \u00e9quipes <code>werf deploy<\/code> et <code>werf run<\/code>.<\/p>\n<p>Aussi, dans cette version, une strat\u00e9gie de marquage des images bas\u00e9e sur le contenu est apparue \u2014 <i>content-based tagging<\/i>, qui est d\u00e9sormais activ\u00e9e par d\u00e9faut et est la seule recommand\u00e9e.<\/p>\n<p>Examinons de plus pr\u00e8s les nouvelles fonctionnalit\u00e9s cl\u00e9s de werf v1.1, tout en parlant de nos projets pour l'avenir.<\/p>\n<h2>Qu'est-ce qui a chang\u00e9 dans werf v1.1 ?<\/h2>\n<p><\/p>\n<h3>Un nouveau format de nommage des \u00e9tapes et un algorithme de s\u00e9lection des \u00e9tapes \u00e0 partir du cache<\/h3>\n<p>\nUne nouvelle r\u00e8gle de g\u00e9n\u00e9ration de nom d'\u00e9tape. Maintenant, chaque construction d'\u00e9tape g\u00e9n\u00e8re un nom d'\u00e9tape unique, qui se compose de 2 parties : la signature (comme dans v1.0) plus un identifiant temporel unique.<\/p>\n<p>Par exemple, le nom complet de l'image d'\u00e9tape peut ressembler \u00e0 ceci :<\/p>\n<p><code>werf-stages-storage\/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835<\/code><\/p>\n<p>\u2026 ou en g\u00e9n\u00e9ral :<\/p>\n<p><code>werf-stages-storage\/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC<\/code><\/p>\n<p>Ici :<\/p>\n<ul>\n<li> <code>SIGNATURE<\/code> \u2014 c'est la signature de l'\u00e9tape, qui repr\u00e9sente l'identifiant du contenu de l'\u00e9tape et d\u00e9pend de l'historique des modifications dans Git qui ont conduit \u00e0 ce contenu ;<\/li>\n<li> <code>TIMESTAMP_MILLISEC<\/code> \u2014 c'est un identifiant garanti unique de l'image, qui est g\u00e9n\u00e9r\u00e9 au moment de la construction de la nouvelle image.<\/li>\n<\/ul>\n<p>\nL'algorithme de s\u00e9lection des \u00e9tapes \u00e0 partir du cache est bas\u00e9 sur la v\u00e9rification de la parent\u00e9 des commits Git :<\/p>\n<ol>\n<li> Werf calcule la signature d'un certain stade.<\/li>\n<li> Dans <i>stages-storage<\/i> Il peut y avoir plusieurs stades correspondant \u00e0 cette signature. Werf s\u00e9lectionne tous les stades appropri\u00e9s selon la signature.<\/li>\n<li> Si le stade actuel est li\u00e9 \u00e0 Git (git-archive, stade personnalis\u00e9 avec des patches Git : <code>install<\/code>, <code>beforeSetup<\/code>, <code>configuration<\/code>; ou git-latest-patch), alors werf choisit uniquement les stades qui sont li\u00e9s \u00e0 un commit qui est un anc\u00eatre du commit actuel (pour lequel la construction est invoqu\u00e9e).<\/li>\n<li> Parmi les stades appropri\u00e9s restants, un est s\u00e9lectionn\u00e9 \u2014 le plus ancien par date de cr\u00e9ation.<\/li>\n<\/ol>\n<p>\nUn stade pour diff\u00e9rentes branches Git peut avoir la m\u00eame signature. Mais werf emp\u00eachera l'utilisation du cache li\u00e9 \u00e0 diff\u00e9rentes branches, m\u00eame si les signatures co\u00efncident.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/reference\/stages_and_images.html#%D0%B8%D0%BC%D0%B5%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D1%81%D1%82%D0%B0%D0%B4%D0%B8%D0%B9\">\u2192 Documentation<\/a><\/noindex>.<\/p>\n<h3>Nouvel algorithme de cr\u00e9ation et de sauvegarde des stades dans le stockage des stades<\/h3>\n<p>\nSi, lors de la recherche de stades dans le cache, werf ne trouve pas de stade appropri\u00e9, alors un processus de construction d'un nouveau stade est initi\u00e9.<\/p>\n<p>Notons que plusieurs processus (sur un ou plusieurs h\u00f4tes) peuvent commencer \u00e0 construire le m\u00eame stade \u00e0 peu pr\u00e8s au m\u00eame moment. Werf utilise un algorithme de verrouillage optimiste <i>stages-storage<\/i> au moment de la sauvegarde de l'image fra\u00eechement construite dans <i>stages-storage<\/i>. Ainsi, lorsque la construction d'un nouveau stade est pr\u00eate, werf verrouille <i>stages-storage<\/i> et sauvegarde l'image fra\u00eechement construite uniquement si aucune image appropri\u00e9e n'existe d\u00e9j\u00e0 <i>(selon la signature et d'autres param\u00e8tres \u2014 voir le nouvel algorithme de recherche de stades dans le cache)<\/i>.<\/p>\n<p>L'image fra\u00eechement construite aura garantissant un identifiant unique selon <code>TIMESTAMP_MILLISEC<\/code> <i>(voir le nouveau format de nommage des stades)<\/i>. Dans le cas o\u00f9 une image appropri\u00e9e serait trouv\u00e9e dans <i>stages-storage<\/i> , werf rejettera l'image fra\u00eechement construite et utilisera l'image du cache.<\/p>\n<p>En d'autres termes : le premier processus qui terminera de construire l'image (le plus rapide) obtiendra le droit de la sauvegarder dans le stages-storage (et ensuite, cette unique image sera utilis\u00e9e pour toutes les constructions). Le processus de construction plus lent ne bloquera jamais le processus le plus rapide dans la sauvegarde des r\u00e9sultats de la construction du stade actuel et dans le passage \u00e0 la construction du suivant.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/reference\/stages_and_images.html#%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0-%D0%B8-%D1%81%D0%BE%D1%85%D1%80%D0%B0%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5-%D1%81%D1%82%D0%B0%D0%B4%D0%B8%D0%B9\">\u2192 Documentation<\/a><\/noindex>.<\/p>\n<h3>Am\u00e9lioration des performances du constructeur Dockerfile<\/h3>\n<p>\n\u00c0 l'heure actuelle, le pipeline des stades pour l'image construite \u00e0 partir du Dockerfile se compose d'un seul stade \u2014 <code>dockerfile<\/code>. Lors du calcul de la signature, la somme de contr\u00f4le des fichiers est prise en compte. <code>context<\/code>, qui seront utilis\u00e9s lors de la construction. Avant cette am\u00e9lioration, werf parcourait r\u00e9cursivement tous les fichiers et obtenait un hash de contr\u00f4le en additionnant le contexte et le mode de chaque fichier. \u00c0 partir des versions v1.1, werf peut utiliser les hashes de contr\u00f4le calcul\u00e9s, stock\u00e9s dans le d\u00e9p\u00f4t Git.<\/p>\n<p>\u00c0 la base de l'algorithme se trouve <noindex><a rel=\"nofollow\" href=\"https:\/\/git-scm.com\/docs\/git-ls-tree\">git ls-tree<\/a><\/noindex>. L'algorithme prend en compte les enregistrements dans <code>.dockerignore<\/code> et parcourt r\u00e9cursivement l'arbre des fichiers uniquement si n\u00e9cessaire. Ainsi, nous nous sommes d\u00e9tach\u00e9s de la lecture du syst\u00e8me de fichiers, et la d\u00e9pendance de l'algorithme \u00e0 la taille <code>context<\/code> n'est pas significative.<\/p>\n<p>L'algorithme v\u00e9rifie \u00e9galement les fichiers non suivis et les prend en compte dans le hash de contr\u00f4le si n\u00e9cessaire.<\/p>\n<h3>Am\u00e9lioration des performances lors de l'importation de fichiers<\/h3>\n<p>\nDans les versions werf v1.1, un serveur rsync est utilis\u00e9 lors <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/configuration\/stapel_image\/import_directive.html\">de l'importation des fichiers \u00e0 partir des artefacts et des images<\/a><\/noindex>. Auparavant, l'importation se faisait en deux \u00e9tapes \u00e0 l'aide du montage d'un r\u00e9pertoire \u00e0 partir du syst\u00e8me h\u00f4te.<\/p>\n<p>Les performances des importations sur macOS ne sont plus limit\u00e9es par les volumes Docker, et les importations se font dans le m\u00eame temps que sur Linux et Windows.<\/p>\n<h3>Tagging bas\u00e9 sur le contenu<\/h3>\n<p>\nWerf v1.1 prend en charge ce que l'on appelle le tagging bas\u00e9 sur le contenu de l'image \u2014 <i>content-based tagging<\/i>. Les tags des images Docker r\u00e9sultantes d\u00e9pendent du contenu de ces images.<\/p>\n<p>Lors de l'ex\u00e9cution de la commande <code>werf publish --tags-by-stages-signature<\/code> ou <code>werf ci-env --tagging-strategy=stages-signature<\/code> taguera les images publi\u00e9es par ce que l'on appelle la <b>signature des \u00e9tapes<\/b> de l'image. Chaque image est tagu\u00e9e avec sa propre signature des \u00e9tapes de cette image, qui est calcul\u00e9e selon les m\u00eames r\u00e8gles que la signature r\u00e9guli\u00e8re de chacune des \u00e9tapes individuellement, mais constitue un identifiant g\u00e9n\u00e9ralis\u00e9 de l'image.<\/p>\n<p>La signature des \u00e9tapes de l'image d\u00e9pend de :<\/p>\n<ol>\n<li> le contenu de cette image ;<\/li>\n<li> l'historique des modifications dans Git qui ont conduit \u00e0 ce contenu.<\/li>\n<\/ol>\n<p>\nDans le d\u00e9p\u00f4t Git, il y a toujours des commits vides qui ne modifient pas le contenu des fichiers de l'image. Par exemple, des commits uniquement avec des commentaires ou des commits de fusion, ou des commits qui modifient les fichiers dans Git qui ne seront pas import\u00e9s dans l'image.<\/p>\n<p>L'utilisation du tagging bas\u00e9 sur le contenu r\u00e9sout les probl\u00e8mes de red\u00e9marrages inutiles des pods de l'application dans Kubernetes en raison de changements de nom d'image, m\u00eame si le contenu de l'image n'a pas \u00e9t\u00e9 modifi\u00e9. D'ailleurs, cela fait partie des raisons qui emp\u00eachent de stocker de nombreux microservices d'une seule application dans un unique d\u00e9p\u00f4t Git.<\/p>\n<p>De plus, le tagging bas\u00e9 sur le contenu est une m\u00e9thode de tagging plus fiable que le tagging bas\u00e9 sur les branches Git, car le contenu des images r\u00e9sultantes ne d\u00e9pend pas de l'ordre d'ex\u00e9cution des pipelines dans le syst\u00e8me CI pour la compilation de plusieurs commits de la m\u00eame branche.<\/p>\n<p><b>Important<\/b>: \u00e0 partir de maintenant <i>stages-signature<\/i> \u2014 ce sont des <b>la seule strat\u00e9gie de balisage recommand\u00e9e<\/b>. C'est celle qui sera utilis\u00e9e par d\u00e9faut dans l'\u00e9quipe <code>werf ci-env<\/code> (si aucune autre sch\u00e9ma de balisage n'est explicitement indiqu\u00e9).<\/p>\n<p><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\">\u2192 Documentation<\/a><\/noindex>. Cette fonctionnalit\u00e9 aura \u00e9galement sa propre publication. <b>MIS \u00c0 JOUR<\/b> (3 avril) : Article avec des d\u00e9tails <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/495112\/\">a \u00e9t\u00e9 publi\u00e9e<\/a><\/noindex>.<\/p>\n<h3>Niveaux de journalisation<\/h3>\n<p>\nL'utilisateur a maintenant la possibilit\u00e9 de contr\u00f4ler la sortie, de d\u00e9finir le niveau de journalisation et de travailler avec les informations de d\u00e9bogage. Options ajout\u00e9es <code>--log-quiet<\/code>, <code>--log-verbose<\/code>, <code>--log-debug<\/code>.<\/p>\n<p>Par d\u00e9faut, la sortie contient un minimum d'informations :<\/p>\n<p><img decoding=\"async\" alt=\"Version 1.1 de werf : am\u00e9liorations dans l&#039;assembleur aujourd&#039;hui et plans futurs\" src=\"\/wp-content\/uploads\/2020\/04\/58e981b2e0c579ddde817eadc1732874.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLors de l'utilisation de la sortie d\u00e9taill\u00e9e (<code>--log-verbose<\/code>) on peut voir comment fonctionne werf :<\/p>\n<p><img decoding=\"async\" alt=\"Version 1.1 de werf : am\u00e9liorations dans l&#039;assembleur aujourd&#039;hui et plans futurs\" src=\"\/wp-content\/uploads\/2020\/04\/487ed5dfc5df0178f7c09f8da697ceff.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa sortie d\u00e9taill\u00e9e (<code>--log-debug<\/code>), en plus des informations de d\u00e9bogage de werf, contient \u00e9galement les journaux des biblioth\u00e8ques utilis\u00e9es. Par exemple, on peut voir comment se d\u00e9roule l'interaction avec Docker Registry, ainsi que noter les endroits o\u00f9 un temps consid\u00e9rable est d\u00e9pens\u00e9 :<\/p>\n<p><img decoding=\"async\" alt=\"Version 1.1 de werf : am\u00e9liorations dans l&#039;assembleur aujourd&#039;hui et plans futurs\" src=\"\/wp-content\/uploads\/2020\/04\/99c1f3c2ab3803ff11fae1f2d5c9a5af.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Plans futurs<\/h2>\n<p>\n<b>Attention !<\/b> Les fonctionnalit\u00e9s d\u00e9crites ci-dessous avec la mention <b>v1.1<\/b> seront disponibles dans cette version, beaucoup d'entre elles \u2014 dans un avenir proche. Les mises \u00e0 jour arriveront par des auto-mises \u00e0 jour <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/guides\/installation.html#%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1-1-%D1%80%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D1%83%D0%B5%D0%BC%D1%8B%D0%B9-multiwerf\">lors de l'utilisation de multiwerf<\/a><\/noindex>. Ces fonctionnalit\u00e9s ne touchent pas la partie stable des fonctions v1.1, leur apparition ne n\u00e9cessitera pas d'intervention manuelle de l'utilisateur dans les configurations existantes.<\/p>\n<h3>Prise en charge compl\u00e8te des diff\u00e9rentes impl\u00e9mentations de Docker Registry (NOUVEAU)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version : v1.1<\/i><\/li>\n<li> <i>D\u00e9lai : mars<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2199\">Probl\u00e8me<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nL'objectif est que l'utilisateur puisse utiliser n'importe quelle impl\u00e9mentation sans restrictions lors de l'utilisation de werf. <\/p>\n<p>Actuellement, nous avons s\u00e9lectionn\u00e9 le jeu de solutions suivant pour lesquelles nous nous engageons \u00e0 garantir une prise en charge compl\u00e8te :<\/p>\n<ul>\n<li> Default (library\/registry)*,<\/li>\n<li> AWS ECR,<\/li>\n<li> Azure*,<\/li>\n<li> Docker Hub,<\/li>\n<li> GCR*,<\/li>\n<li> GitHub Packages,<\/li>\n<li> GitLab Registry*,<\/li>\n<li> Harbor*,<\/li>\n<li> Quay.<\/li>\n<\/ul>\n<p>\nLes solutions marqu\u00e9es d'une \u00e9toile sont celles qui sont d\u00e9j\u00e0 compl\u00e8tement prises en charge par werf. Pour les autres, il existe un soutien, mais avec des restrictions.<\/p>\n<p>On peut identifier deux probl\u00e8mes majeurs :<\/p>\n<ul>\n<li> Certaines solutions ne prennent pas en charge la suppression de balises via l'API Docker Registry, ce qui emp\u00eache les utilisateurs d'utiliser le nettoyage automatique mis en \u0153uvre dans werf. Cela est vrai pour AWS ECR, Docker Hub et GitHub Packages.<\/li>\n<li> Certain solutions do not support so-called nested repositories (Docker Hub, GitHub Packages, and Quay) or support it but the user must create them manually using the UI or API (AWS ECR).<\/li>\n<\/ul>\n<p>\nWe plan to address these and other issues using the native APIs of the solutions. This task also includes covering the full cycle of werf operation with tests for each of them.<\/p>\n<h3>Distributed image building (\u2191)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.2 v1.1 (the priority for implementing this feature has been increased)<\/i><\/li>\n<li> <i>Timeline: March-April March<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/1614\">Probl\u00e8me<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nCurrently, werf v1.0 and v1.1 can only be used on a single dedicated host for building and publishing images and deploying applications in Kubernetes.<\/p>\n<p>To unlock distributed working capabilities of werf, where building and deploying applications in Kubernetes is launched on several arbitrary hosts and these hosts do not retain their state between builds (temporary runners), werf requires the implementation of using Docker Registry as a stage storage.<\/p>\n<p>Previously, when the werf project was still called dapp, this possibility existed. However, we encountered several issues that need to be addressed when implementing this feature in werf.<\/p>\n<p><b>Remarque<\/b>. Cette fonctionnalit\u00e9 ne suppose pas que le constructeur fonctionne \u00e0 l'int\u00e9rieur des pods Kubernetes, car il est n\u00e9cessaire de se d\u00e9barrasser de la d\u00e9pendance au serveur Docker local (dans le pod Kubernetes, il n'y a pas d'acc\u00e8s au serveur Docker local, car le processus lui-m\u00eame est lanc\u00e9 dans un conteneur, et le travail avec le serveur Docker via le r\u00e9seau n'est pas support\u00e9 par werf et ne le sera pas). Le support du fonctionnement dans Kubernetes sera mis en \u0153uvre s\u00e9par\u00e9ment.<\/p>\n<h3>Official support for GitHub Actions (NEW)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version : v1.1<\/i><\/li>\n<li> <i>D\u00e9lai : mars<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2210\">Probl\u00e8me<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nIncludes werf documentation (sections <i>reference<\/i> et <i>guide<\/i>), as well as the official GitHub Action for working with werf.<\/p>\n<p>De plus, cela permettra \u00e0 werf de fonctionner sur des runners \u00e9ph\u00e9m\u00e8res.<\/p>\n<p>La m\u00e9canique d'interaction de l'utilisateur avec le syst\u00e8me CI sera bas\u00e9e sur l'attribution d'\u00e9tiquettes aux pull requests pour d\u00e9clencher certaines actions de build\/d\u00e9ploiement de l'application.<\/p>\n<h3>Local development and deployment of applications with werf (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version : v1.1<\/i><\/li>\n<li> <i>Timeline: January-February April<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/1940\">Probl\u00e8me<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nThe main goal is to achieve a single unified config for deploying applications both locally and in production, without complex actions, 'out of the box.'<\/p>\n<p>Il est \u00e9galement n\u00e9cessaire pour werf de disposer d'un mode de fonctionnement qui facilite la modification du code de l'application et permet de recevoir instantan\u00e9ment des retours d'informations sur l'application en cours d'ex\u00e9cution pour le d\u00e9bogage.<\/p>\n<h3>Nouvel algorithme de nettoyage (NOUVEAU)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version : v1.1<\/i><\/li>\n<li> <i>D\u00e9lais : avril<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2212\">Probl\u00e8me<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nDans la version actuelle de werf v1.1, la proc\u00e9dure <code>cleanup<\/code> ne pr\u00e9voit pas le nettoyage des images pour le sch\u00e9ma de balisage bas\u00e9 sur le contenu (content-based tagging) \u2014 ces images vont s'accumuler.<\/p>\n<p>De plus, dans la version actuelle de werf (v1.0 et v1.1), diff\u00e9rentes politiques de nettoyage sont utilis\u00e9es pour les images publi\u00e9es selon des sch\u00e9mas de balisage : branche Git, tag Git ou commit Git.<\/p>\n<p>Un nouvel algorithme de nettoyage unifi\u00e9 pour tous les sch\u00e9mas de balisage a \u00e9t\u00e9 con\u00e7u, bas\u00e9 sur l'historique des commits dans Git :<\/p>\n<ul>\n<li> Conserver au maximum N1 images, li\u00e9es aux N2 derniers commits pour chaque git HEAD (branches et tags).<\/li>\n<li> Conserver au maximum N1 images d'\u00e9tape, li\u00e9es aux N2 derniers commits pour chaque git HEAD (branches et tags).<\/li>\n<li> Conserver toutes les images utilis\u00e9es dans les ressources de cluster Kubernetes (tous les contextes kube du fichier de configuration et les namespaces sont scann\u00e9s ; ce comportement peut \u00eatre restreint par des options sp\u00e9ciales).<\/li>\n<li> Conserver toutes les images utilis\u00e9es dans les manifestes de configuration des ressources enregistr\u00e9es dans les releases Helm.<\/li>\n<li> Une image peut \u00eatre supprim\u00e9e si elle n'est li\u00e9e \u00e0 aucun HEAD dans git (par exemple, parce que le HEAD correspondant a \u00e9t\u00e9 supprim\u00e9) et qu'elle n'est utilis\u00e9e dans aucun des manifestes du cluster Kubernetes et dans les releases Helm.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Construction parall\u00e8le des images (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version : v1.1<\/i><\/li>\n<li> <i>D\u00e9lais : janvier-f\u00e9vrier avril*<\/i><\/li>\n<\/ul>\n<p>\nLa version actuelle de werf construit les images et artefacts d\u00e9crits dans <code>werf.yaml<\/code>, de mani\u00e8re s\u00e9quentielle. Il est n\u00e9cessaire de parall\u00e9liser le processus de construction des \u00e9tapes d'images et d'artefacts ind\u00e9pendants, ainsi que de fournir une sortie pratique et informative.<\/p>\n<p><i>* Remarque : le d\u00e9lai est d\u00e9cal\u00e9 en raison de la priorit\u00e9 accrue accord\u00e9e \u00e0 la mise en \u0153uvre de la construction distribu\u00e9e, qui ajoutera davantage de possibilit\u00e9s de mise \u00e0 l'\u00e9chelle horizontale, ainsi que l'utilisation de werf avec GitHub Actions. La construction parall\u00e8le constitue la prochaine \u00e9tape d'optimisation, offrant une scalabilit\u00e9 verticale lors de la construction d'un seul projet.<\/i><\/p>\n<h3>Migration vers Helm 3 (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version : v1.2<\/i><\/li>\n<li> <i>D\u00e9lais : f\u00e9vrier-mars mai*<\/i><\/li>\n<\/ul>\n<p>\nComprend la migration vers une nouvelle base de code <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/news\/t\/475722\/\">Helm 3<\/a><\/noindex> et un moyen \u00e9prouv\u00e9 et pratique de migrer les installations existantes.<\/p>\n<p><i>* Remarque : la migration vers Helm 3 n'ajoutera pas de fonctionnalit\u00e9s importantes \u00e0 werf, car toutes les caract\u00e9ristiques cl\u00e9s de Helm 3 (fusion \u00e0 3 voies et absence de tiller) sont d\u00e9j\u00e0 impl\u00e9ment\u00e9es dans werf. De plus, werf dispose <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/differences_with_helm.html\">de capacit\u00e9s suppl\u00e9mentaires<\/a><\/noindex> au-del\u00e0 de celles-ci. Cependant, cette transition reste dans nos projets et sera mise en \u0153uvre.<\/i><\/p>\n<h3>Jsonnet pour d\u00e9crire la configuration de Kubernetes (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version : v1.2<\/i><\/li>\n<li> <i>D\u00e9lais : janvier-f\u00e9vrier avril-mai<\/i><\/li>\n<\/ul>\n<p>\nWerf prendra en charge la description de la configuration pour Kubernetes au format Jsonnet. Ainsi, werf restera compatible avec Helm et offrira la possibilit\u00e9 de choisir le format de description.<\/p>\n<p>La raison est que les mod\u00e8les du langage Go, selon de nombreuses personnes, ont un seuil d'entr\u00e9e \u00e9lev\u00e9 et la clart\u00e9 du code de ces mod\u00e8les souffre \u00e9galement.<\/p>\n<p>L'impl\u00e9mentation d'autres syst\u00e8mes de description de configuration Kubernetes (par exemple, Kustomize) est \u00e9galement envisag\u00e9e.<\/p>\n<h3>Travail au sein de Kubernetes (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version : v1.2<\/i><\/li>\n<li> <i>D\u00e9lais : avril-mai mai-juin<\/i><\/li>\n<\/ul>\n<p>\nObjectif : assurer la construction d'images et la livraison d'applications en utilisant des runners dans Kubernetes. C'est-\u00e0-dire que la construction de nouvelles images, leur publication, le nettoyage et le d\u00e9ploiement peuvent se faire directement depuis les pod Kubernetes.<\/p>\n<p>Pour mettre en \u0153uvre cette possibilit\u00e9, il faut d'abord la possibilit\u00e9 de construction d'images distribu\u00e9es <i>(voir point ci-dessus)<\/i>.<\/p>\n<p>Un support pour le mode de fonctionnement du constructeur sans serveur Docker (c'est-\u00e0-dire une construction similaire \u00e0 Kaniko ou dans l\u2019espace utilisateur) est \u00e9galement n\u00e9cessaire.<\/p>\n<p>Werf prendra en charge la construction dans Kubernetes non seulement \u00e0 l'aide de Dockerfile, mais aussi avec son propre constructeur Stapel, avec des reconstructions incr\u00e9mentales et Ansible.<\/p>\n<h2>Un pas vers le d\u00e9veloppement ouvert<\/h2>\n<p>\nNous aimons notre communaut\u00e9 (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/werf_ru\">Telegram<\/a><\/noindex>) et souhaitons que de plus en plus de personnes aident \u00e0 am\u00e9liorer werf, comprennent la direction dans laquelle nous avan\u00e7ons et participent au d\u00e9veloppement.<\/p>\n<p>R\u00e9cemment, il a \u00e9t\u00e9 d\u00e9cid\u00e9 de passer \u00e0 <noindex><a rel=\"nofollow\" href=\"https:\/\/help.github.com\/en\/github\/managing-your-work-on-github\/about-project-boards\">GitHub project boards<\/a><\/noindex> afin d'ouvrir un peu le processus de travail de notre \u00e9quipe. Il est maintenant possible de consulter les plans \u00e0 court terme, ainsi que les travaux en cours dans les domaines suivants :<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/9\">Documentation et site<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/7\">Tests<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/6\">Bugs et mauvaise exp\u00e9rience utilisateur<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/5\">1.1<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\nUn grand travail a \u00e9t\u00e9 r\u00e9alis\u00e9 sur les probl\u00e8mes :<\/p>\n<ul>\n<li> Les obsol\u00e8tes ont \u00e9t\u00e9 supprim\u00e9s.<\/li>\n<li> Les existants ont \u00e9t\u00e9 mis au format uniforme, avec un nombre suffisant de d\u00e9tails et d'explications.<\/li>\n<li> De nouveaux probl\u00e8mes ont \u00e9t\u00e9 ajout\u00e9s avec des id\u00e9es et des suggestions.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Comment activer la version v1.1<\/h2>\n<p>\nLa version est disponible actuellement dans <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">le canal 1.1 ea<\/a><\/noindex> (dans les canaux <i>stable<\/i> et <i>rock-solid<\/i> les versions appara\u00eetront \u00e0 mesure qu'elles se stabilisent, mais <i>ea<\/i> elle est d\u00e9j\u00e0 suffisamment stable pour \u00eatre utilis\u00e9e, car elle a pass\u00e9 les canaux <i>alpha<\/i> et <i>beta<\/i>). S'active via <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/guides\/installation.html#%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1-1-%D1%80%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D1%83%D0%B5%D0%BC%D1%8B%D0%B9-multiwerf\">multiwerf<\/a><\/noindex> de la mani\u00e8re suivante :<\/p>\n<pre><code class=\"bash\">source $(multiwerf use 1.1 ea)\nwerf COMMAND ...<\/code><\/pre>\n<p><\/p>\n<h2>Conclusion<\/h2>\n<p>\nLa nouvelle architecture de stockage des \u00e9tapes et l'optimisation du fonctionnement du constructeur pour les constructeurs Stapel et Dockerfile offrent des possibilit\u00e9s de r\u00e9aliser des constructions distribu\u00e9es et parall\u00e8les dans werf. Ces fonctionnalit\u00e9s seront bient\u00f4t disponibles dans la m\u00eame version v1.1 et deviendront automatiquement accessibles via le m\u00e9canisme des mises \u00e0 jour automatiques (pour les utilisateurs <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/guides\/installation.html#%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1-1-%D1%80%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D1%83%D0%B5%D0%BC%D1%8B%D0%B9-multiwerf\">multiwerf<\/a><\/noindex>). <\/p>\n<p>Dans cette version, une strat\u00e9gie de taggage bas\u00e9e sur le contenu des images a \u00e9t\u00e9 ajout\u00e9e \u2014 <i>content-based tagging<\/i>, \u2014 qui est devenue la strat\u00e9gie par d\u00e9faut. De plus, le journal des principales commandes a \u00e9t\u00e9 r\u00e9vis\u00e9 : <code>werf build<\/code>, <code>werf publish<\/code>, <code>werf deploy<\/code>, <code>werf dismiss<\/code>, <code>werf cleanup<\/code>.<\/p>\n<p>La prochaine \u00e9tape importante sera l'ajout de constructions distribu\u00e9es. Les constructions distribu\u00e9es sont devenues une t\u00e2che plus prioritaire depuis v1.0 par rapport aux constructions parall\u00e8les, car elles apportent plus de valeur \u00e0 werf : mise \u00e0 l'\u00e9chelle verticale des constructeurs et support des constructeurs \u00e9ph\u00e9m\u00e8res dans divers syst\u00e8mes CI\/CD, ainsi que la possibilit\u00e9 d'ajouter un support officiel pour GitHub Actions. Par cons\u00e9quent, les d\u00e9lais de mise en \u0153uvre des constructions parall\u00e8les ont \u00e9t\u00e9 repouss\u00e9s. Cependant, nous travaillons pour r\u00e9aliser rapidement les deux fonctionnalit\u00e9s.<\/p>\n<p>Restez \u00e0 l'\u00e9coute ! Et n'oubliez pas de nous rendre visite sur <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, pour cr\u00e9er une issue, trouver une d\u00e9j\u00e0 existante et lui donner un coup de pouce, cr\u00e9er une PR ou simplement suivre le d\u00e9veloppement 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\/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\/493170\/\">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. \u041a\u0430\u043a \u0438 \u043e\u0431\u0435\u0449\u0430\u043b\u0438, \u0432\u044b\u0445\u043e\u0434 \u0432\u0435\u0440\u0441\u0438\u0438 v1.0 \u0437\u043d\u0430\u043c\u0435\u043d\u043e\u0432\u0430\u043b \u043d\u0430\u0447\u0430\u043b\u043e \u0434\u043e\u0431\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u0432 werf \u043d\u043e\u0432\u044b\u0445 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0435\u0439 \u0438 \u043f\u0435\u0440\u0435\u0441\u043c\u043e\u0442\u0440\u0430 \u043f\u0440\u0438\u0432\u044b\u0447\u043d\u044b\u0445 \u043f\u043e\u0434\u0445\u043e\u0434\u043e\u0432. \u0422\u0435\u043f\u0435\u0440\u044c \u043c\u044b \u0440\u0430\u0434\u044b \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0440\u0435\u043b\u0438\u0437 v1.1, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0431\u043e\u043b\u044c\u0448\u0438\u043c \u0448\u0430\u0433\u043e\u043c \u0432 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0438 \u0438 \u0437\u0430\u0434\u0435\u043b\u043e\u043c \u043d\u0430 \u0431\u0443\u0434\u0443\u0449\u0435\u0435 \u0441\u0431\u043e\u0440\u0449\u0438\u043a\u0430 werf. \u0412\u0435\u0440\u0441\u0438\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u0430 \u043d\u0430 \u0434\u0430\u043d\u043d\u044b\u0439 \u043c\u043e\u043c\u0435\u043d\u0442 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":76765,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-76764","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\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee\" \/>\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\udd47\u0420\u0435\u043b\u0438\u0437 werf 1.1: \u0443\u043b\u0443\u0447\u0448\u0435\u043d\u0438\u044f \u0432 \u0441\u0431\u043e\u0440\u0449\u0438\u043a\u0435 \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u0438 \u043f\u043b\u0430\u043d\u044b \u043d\u0430 \u0431\u0443\u0434\u0443\u0449\u0435\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee\" \/>\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:24+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-04-04T11:42:24+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\udd47Version werf 1.1 : am\u00e9liorations du constructeur aujourd'hui et plans pour l'avenir | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","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\udd47\u0420\u0435\u043b\u0438\u0437 werf 1.1: \u0443\u043b\u0443\u0447\u0448\u0435\u043d\u0438\u044f \u0432 \u0441\u0431\u043e\u0440\u0449\u0438\u043a\u0435 \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u0438 \u043f\u043b\u0430\u043d\u044b \u043d\u0430 \u0431\u0443\u0434\u0443\u0449\u0435\u0435 | ProHoster","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","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:24+00:00","article:modified_time":"2020-04-04T11:42:24+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"76764","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:23","updated":"2022-09-28 14:39:02","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\/76764","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=76764"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/76764\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/76765"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=76764"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=76764"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=76764"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}