{"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\/ro\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","title":{"rendered":"Lansarea werf 1.1: \u00eembun\u0103t\u0103\u021biri \u00een constructor ast\u0103zi \u0219i planuri de viitor","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Lansarea werf 1.1: \u00eembun\u0103t\u0103\u021biri \u00een constructor ast\u0103zi \u0219i planuri de viitor\" 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 instrumentul nostru CLI GitOps cu cod deschis pentru construc\u021bia \u0219i livrarea aplica\u021biilor \u00een Kubernetes. A\u0219a cum am promis, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">lansarea versiunii v1.0<\/a><\/noindex> a marcat \u00eenceputul ad\u0103ug\u0103rii de noi func\u021bionalit\u0103\u021bi \u00een werf \u0219i revizuirii abord\u0103rilor folosite. Suntem acum \u00eenc\u00e2nta\u021bi s\u0103 prezent\u0103m versiunea v1.1, care reprezint\u0103 un pas important \u00een dezvoltare \u0219i o baz\u0103 pentru viitor. <i>builder-ului<\/i> werf. Versiunea este disponibil\u0103 \u00een prezent \u00een <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">canalul 1.1 ea<\/a><\/noindex>.<\/p>\n<p>Fundamentul versiunii este noua arhitectur\u0103 a stoc\u0103rii etapelor \u0219i optimizarea func\u021bion\u0103rii ambelor builder-e (pentru Stapel \u0219i Dockerfile). Noua arhitectur\u0103 de stocare deschide posibilit\u0103\u021bi pentru implementarea construc\u021biilor distribuite de pe mai multe gazde \u0219i construc\u021biilor paralele pe o singur\u0103 gazd\u0103.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Optimizarea func\u021bion\u0103rii include eliminarea calculelor inutile \u00een etapa de calculare a semn\u0103turilor etapelor \u0219i modificarea mecanismelor de calculare a sumelor de control ale fi\u0219ierelor pentru o eficien\u021b\u0103 mai mare. Aceast\u0103 optimizare reduce timpul mediu de construc\u021bie al proiectului folosind werf. Iar construc\u021biile goale, c\u00e2nd toate etapele exist\u0103 \u00een cache <i>stages-storage<\/i>, sunt acum cu adev\u0103rat rapide. \u00cen cele mai multe cazuri, reluarea construc\u021biei va dura mai pu\u021bin de 1 secund\u0103! Acest lucru se aplic\u0103 \u0219i procedurilor de verificare a etapelor \u00een timpul lucrului echipelor <code>werf deploy<\/code> \u0219i <code>werf run<\/code>.<\/p>\n<p>De asemenea, \u00een aceast\u0103 versiune a fost introdus\u0103 o strategie de etichetare a imaginilor \u00een func\u021bie de con\u021binut \u2014 <i>content-based tagging<\/i>, care acum este activat\u0103 ca implicit\u0103 \u0219i este singura recomandat\u0103.<\/p>\n<p>S\u0103 analiz\u0103m mai \u00een detaliu noile caracteristici cheie din werf v1.1 \u0219i \u00een acela\u0219i timp s\u0103 discut\u0103m despre planurile de viitor.<\/p>\n<h2>Ce s-a schimbat \u00een werf v1.1?<\/h2>\n<p><\/p>\n<h3>Un nou format de denumire a etapelor \u0219i un nou algoritm de selec\u021bie a etapelor din cache<\/h3>\n<p>\nO nou\u0103 regul\u0103 de generare a numelui etapei. Acum, fiecare construc\u021bie a unei etape genereaz\u0103 un nume unic de etap\u0103, care const\u0103 din 2 p\u0103r\u021bi: semn\u0103tura (a\u0219a cum era \u00een v1.0) plus un identificator temporal unic.<\/p>\n<p>De exemplu, numele complet al imaginii etapei poate ar\u0103ta astfel:<\/p>\n<p><code>werf-stages-storage\/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835<\/code><\/p>\n<p>\u2026 sau, \u00een general, astfel:<\/p>\n<p><code>werf-stages-storage\/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC<\/code><\/p>\n<p>Aici:<\/p>\n<ul>\n<li> <code>SIGNATURE<\/code> \u2014 este semn\u0103tura etapei, care reprezint\u0103 identificatorul con\u021binutului etapei \u0219i depinde de istoria modific\u0103rilor din Git, care au dus la acest con\u021binut;<\/li>\n<li> <code>TIMESTAMP_MILLISEC<\/code> \u2014 acesta este un identificator garantat unic al imaginii, care este generat \u00een momentul construc\u021biei unei noi imagini.<\/li>\n<\/ul>\n<p>\nAlgoritmul de selec\u021bie a etapelor din cache se bazeaz\u0103 pe verificarea rela\u021biei \u00eentre commit-urile Git:<\/p>\n<ol>\n<li> Werf calculeaz\u0103 semn\u0103tura unei anumite etape.<\/li>\n<li> \u00cen <i>stages-storage<\/i> pot exista mai multe etape cu aceea\u0219i semn\u0103tur\u0103. Werf selecteaz\u0103 toate etapele corespunz\u0103toare semn\u0103turii.<\/li>\n<li> Dac\u0103 etapa curent\u0103 este legat\u0103 de Git (git-archive, etap\u0103 personalizat\u0103 cu patch-uri Git: <code>install<\/code>, <code>beforeSetup<\/code>, <code>setup<\/code>; sau git-latest-patch), atunci werf selecteaz\u0103 doar acele etape care sunt legate de un commit care este str\u0103mo\u0219ul commit-ului curent (pentru care este apelat\u0103 construc\u021bia).<\/li>\n<li> Dintre etapele corespunz\u0103toare r\u0103mase, se alege una \u2014 cea mai veche dup\u0103 data cre\u0103rii.<\/li>\n<\/ol>\n<p>\nEtapa pentru diferite ramuri Git poate avea aceea\u0219i semn\u0103tur\u0103. \u00cens\u0103 werf va preveni utilizarea cache-ului asociat diferitelor ramuri \u00eentre aceste ramuri, chiar dac\u0103 semn\u0103turile au coincis.<\/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 Documenta\u021bie<\/a><\/noindex>.<\/p>\n<h3>Un nou algoritm pentru crearea \u0219i salvarea etapelor \u00een stocarea etapelor<\/h3>\n<p>\nDac\u0103 \u00een timpul selec\u021biei etapelor din cache werf nu g\u0103se\u0219te o etap\u0103 corespunz\u0103toare, atunci este ini\u021biat procesul de construc\u021bie a unei noi etape.<\/p>\n<p>Observa\u021bi c\u0103 mai multe procese (pe un singur sau mai multe gazde) pot \u00eencepe construc\u021bia acelea\u0219i etape \u00een aproximativ acela\u0219i timp. Werf folose\u0219te un algoritm de blocare optimist\u0103 <i>stages-storage<\/i> \u00een momentul salv\u0103rii imaginii proasp\u0103t construite \u00een <i>stages-storage<\/i>. Astfel, atunci c\u00e2nd construc\u021bia unei noi etape este gata, werf blocheaz\u0103 <i>stages-storage<\/i> \u0219i salveaz\u0103 acolo imaginea proasp\u0103t construit\u0103 doar \u00een cazul \u00een care nu exist\u0103 deja o imagine corespunz\u0103toare <i>(dup\u0103 semn\u0103tur\u0103 \u0219i alte parametri \u2014 vezi noul algoritm pentru selec\u021bia etapelor din cache)<\/i>.<\/p>\n<p>Imaginea proasp\u0103t construit\u0103 va avea cu siguran\u021b\u0103 un identificator unic dup\u0103 <code>TIMESTAMP_MILLISEC<\/code> <i>(vezi noul format de denumire a etapelor)<\/i>. \u00cen cazul \u00een care \u00een <i>stages-storage<\/i> se va g\u0103si o imagine corespunz\u0103toare, werf va respinge imaginea proasp\u0103t construit\u0103 \u0219i va folosi imaginea din cache.<\/p>\n<p>Cu alte cuvinte: primul proces care finalizeaz\u0103 construirea imaginii (cel mai rapid) va avea dreptul s\u0103 o salveze \u00een stocarea etapelor (\u0219i apoi aceast\u0103 singur\u0103 imagine va fi folosit\u0103 pentru toate construc\u021biile). Procesul lent de construc\u021bie nu va bloca niciodat\u0103 un proces mai rapid de la salvarea rezultatelor construc\u021biei etapei curente \u0219i trecerea la construc\u021bia urm\u0103toarei.<\/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 Documenta\u021bie<\/a><\/noindex>.<\/p>\n<h3>Performan\u021ba constructorului Dockerfile a fost \u00eembun\u0103t\u0103\u021bit\u0103<\/h3>\n<p>\n\u00cen prezent, pipeline-ul etapelor pentru imaginea construit\u0103 din Dockerfile const\u0103 \u00eentr-o singur\u0103 etap\u0103 \u2014 <code>dockerfile<\/code>. La calcularea semn\u0103turii se consider\u0103 suma de control a fi\u0219ierelor. <code>context<\/code>, care vor fi utilizate la construc\u021bie. P\u00e2n\u0103 la aceast\u0103 \u00eembun\u0103t\u0103\u021bire, werf parcurgea recursiv toate fi\u0219ierele \u0219i ob\u021binea un checksum, sum\u00e2nd contextul \u0219i modul fiec\u0103rui fi\u0219ier. \u00cencep\u00e2nd cu versiunile v1.1, werf poate utiliza checksum-urile calculate, stocate \u00een repository-ul Git.<\/p>\n<p>La baza algoritmului se afl\u0103 <noindex><a rel=\"nofollow\" href=\"https:\/\/git-scm.com\/docs\/git-ls-tree\">git ls-tree<\/a><\/noindex>. Algoritmul ia \u00een considerare \u00eenregistr\u0103rile din <code>.dockerignore<\/code> \u0219i parcurge recursiv arborele fi\u0219ierelor doar atunci c\u00e2nd este necesar. Astfel, ne-am dezghemuit de citirea sistemului de fi\u0219iere, iar dependen\u021ba algoritmului de dimensiunea <code>context<\/code> nu este semnificativ\u0103.<\/p>\n<p>De asemenea, algoritmul verific\u0103 fi\u0219ierele untracked \u0219i le include \u00een checksum, dac\u0103 este necesar.<\/p>\n<h3>Performan\u021ba la importarea fi\u0219ierelor a fost \u00eembun\u0103t\u0103\u021bit\u0103<\/h3>\n<p>\n\u00cen versiunile werf v1.1, se folose\u0219te un server rsync la <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/configuration\/stapel_image\/import_directive.html\">importarea fi\u0219ierelor din artefacte \u0219i imagini<\/a><\/noindex>. \u00cen trecut, importarea se realiza \u00een dou\u0103 etape, utiliz\u00e2nd montarea directorului din sistemul gazd\u0103.<\/p>\n<p>Performan\u021ba importurilor pe macOS nu mai este limitat\u0103 de volumele Docker, iar importurile se realizeaz\u0103 \u00een acela\u0219i timp ca pe Linux \u0219i Windows.<\/p>\n<h3>Etichete bazate pe con\u021binut<\/h3>\n<p>\nWerf v1.1 suport\u0103 a\u0219a-numita etichetare \u00een func\u021bie de con\u021binutul imaginii \u2014 <i>content-based tagging<\/i>. Etichetele imaginilor Docker rezultate depind de con\u021binutul acestor imagini.<\/p>\n<p>C\u00e2nd rula\u021bi comanda <code>werf publish --tags-by-stages-signature<\/code> sau <code>werf ci-env --tagging-strategy=stages-signature<\/code> vor fi etichetate imaginile publicate, folosing a\u0219a-numita <b>semn\u0103tur\u0103 a etapelor<\/b> imaginii. Fiecare imagine este etichetat\u0103 cu propria semn\u0103tur\u0103 a etapelor acelei imagini, care este calculat\u0103 dup\u0103 acelea\u0219i reguli ca \u0219i semn\u0103tura regulat\u0103 a fiec\u0103rei etape \u00een parte, dar este un identificator general al imaginii.<\/p>\n<p>Semn\u0103tura etapelor imaginii depinde de:<\/p>\n<ol>\n<li> con\u021binutul acestei imagini;<\/li>\n<li> istoricul modific\u0103rilor \u00een Git, care au dus la acest con\u021binut.<\/li>\n<\/ol>\n<p>\n\u00cen repository-ul Git exist\u0103 \u00eentotdeauna commituri goale care nu modific\u0103 con\u021binutul fi\u0219ierelor imaginii. De exemplu, commituri cu doar comentarii sau commituri de tip merge sau commituri care modific\u0103 acele fi\u0219iere din Git, care nu vor fi importate \u00een imagine.<\/p>\n<p>Utilizarea tagging-ului bazat pe con\u021binut rezolv\u0103 problemele legate de repornirile inutile ale pod-urilor aplica\u021biei \u00een Kubernetes din cauza schimb\u0103rilor de nume ale imaginilor, chiar \u0219i atunci c\u00e2nd con\u021binutul imaginii nu s-a modificat. Apropo, aceasta este una dintre cauzele care \u00eempiedic\u0103 stocarea mai multor microservicii ale unei aplica\u021bii \u00eentr-un singur repository Git.<\/p>\n<p>De asemenea, tagging-ul bazat pe con\u021binut este o metod\u0103 mai fiabil\u0103 de etichetare dec\u00e2t etichetarea pe baza ramurilor Git, deoarece con\u021binutul imaginilor rezultate nu depinde de ordinea execu\u021biei pipeline-urilor \u00een sistemul CI pentru construirea mai multor commit-uri din aceea\u0219i ramur\u0103.<\/p>\n<p><b>Este important<\/b>: \u00eencep\u00e2nd de acum <i>stages-signature<\/i> \u2014 acesta este <b>strategia unic\u0103 recomandat\u0103 de etichetare<\/b>. Aceasta va fi utilizat\u0103 implicit \u00een echip\u0103 <code>werf ci-env<\/code> (dac\u0103 nu se specific\u0103 explicit o alt\u0103 schem\u0103 de etichetare).<\/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 Documenta\u021bie<\/a><\/noindex>. Aceast\u0103 func\u021bionalitate va avea, de asemenea, o publica\u021bie separat\u0103. <b>ACTUALIZAT<\/b> (3 aprilie): Articolul cu detalii <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/495112\/\">publicat\u0103<\/a><\/noindex>.<\/p>\n<h3>Niveluri de jurnalizare<\/h3>\n<p>\nUtilizatorul a primit oportunitatea de a controla ie\u0219irea, de a stabili nivelul de jurnalizare \u0219i de a lucra cu informa\u021biile de depanare. Au fost ad\u0103ugate op\u021biuni <code>--log-quiet<\/code>, <code>--log-verbose<\/code>, <code>--log-debug<\/code>.<\/p>\n<p>Implicit, ie\u0219irea con\u021bine informa\u021bii minimum:<\/p>\n<p><img decoding=\"async\" alt=\"Lansarea werf 1.1: \u00eembun\u0103t\u0103\u021biri \u00een constructor ast\u0103zi \u0219i planuri de viitor\" src=\"\/wp-content\/uploads\/2020\/04\/58e981b2e0c579ddde817eadc1732874.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAtunci c\u00e2nd se folose\u0219te ie\u0219irea detaliat\u0103 (<code>--log-verbose<\/code>) se poate urm\u0103ri cum func\u021bioneaz\u0103 werf:<\/p>\n<p><img decoding=\"async\" alt=\"Lansarea werf 1.1: \u00eembun\u0103t\u0103\u021biri \u00een constructor ast\u0103zi \u0219i planuri de viitor\" src=\"\/wp-content\/uploads\/2020\/04\/487ed5dfc5df0178f7c09f8da697ceff.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIe\u0219irea detaliat\u0103 (<code>--log-debug<\/code>), pe l\u00e2ng\u0103 informa\u021biile de depanare werf, con\u021bine, de asemenea, jurnalele bibliotecilor utilizate. De exemplu, se poate observa cum are loc interac\u021biunea cu Docker Registry \u0219i se pot fixa locurile \u00een care se cheltuie un timp semnificativ:<\/p>\n<p><img decoding=\"async\" alt=\"Lansarea werf 1.1: \u00eembun\u0103t\u0103\u021biri \u00een constructor ast\u0103zi \u0219i planuri de viitor\" src=\"\/wp-content\/uploads\/2020\/04\/99c1f3c2ab3803ff11fae1f2d5c9a5af.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Planuri ulterioare<\/h2>\n<p>\n<b>Aten\u021bie!<\/b> Func\u021bionalit\u0103\u021bile descrise mai departe, marcate cu <b>v1.1<\/b> vor fi disponibile \u00een aceast\u0103 versiune, multe dintre ele \u2014 \u00een cur\u00e2nd. Actualiz\u0103rile vor veni prin actualiz\u0103ri automat\u0103 <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\">atunci c\u00e2nd se utilizeaz\u0103 multiwerf<\/a><\/noindex>. Aceste func\u021bionalit\u0103\u021bi nu afecteaz\u0103 partea stabil\u0103 a func\u021biilor v1.1, apari\u021bia lor nu va necesita interven\u021bia manual\u0103 a utilizatorului \u00een configura\u021biile existente.<\/p>\n<h3>Suport complet pentru diverse implement\u0103ri Docker Registry (NOU)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versiune: v1.1<\/i><\/li>\n<li> <i>Termene: martie<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2199\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nScopul \u2014 utilizatorul s\u0103 utilizeze o implementare arbitrar\u0103 f\u0103r\u0103 restric\u021bii atunci c\u00e2nd folose\u0219te werf. <\/p>\n<p>\u00cen prezent, am eviden\u021biat urm\u0103torul set de solu\u021bii pentru care ne propunem s\u0103 garant\u0103m suport complet:<\/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>\nSolu\u021biile marcate cu stea sunt cele care sunt deja complet suportate de werf. Pentru celelalte exist\u0103 suport, dar cu limit\u0103ri.<\/p>\n<p>Se pot eviden\u021bia dou\u0103 probleme principale:<\/p>\n<ul>\n<li> Unele solu\u021bii nu suport\u0103 \u0219tergerea etichetelor prin intermediul API-ului Docker Registry, ceea ce nu permite utilizatorilor s\u0103 foloseasc\u0103 cur\u0103\u021barea automat\u0103 implementat\u0103 \u00een werf. Acest lucru este valabil pentru AWS ECR, Docker Hub \u0219i GitHub Packages.<\/li>\n<li> Unele solu\u021bii nu suport\u0103, a\u0219a-numitele, repositoare imbricate (Docker Hub, GitHub Packages \u0219i Quay) sau le suport\u0103, dar utilizatorul trebuie s\u0103 le creeze manual, folosind UI sau API (AWS ECR).<\/li>\n<\/ul>\n<p>\nAceste \u0219i alte probleme inten\u021bion\u0103m s\u0103 le rezolv\u0103m folosind API-urile native disponibile. Aceast\u0103 sarcin\u0103 include, de asemenea, testarea \u00eentregului ciclu de func\u021bionare al werf pentru fiecare dintre ele.<\/p>\n<h3>Construirea distribuit\u0103 a imaginilor (\u2191)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versiune: v1.2 v1.1 (prioritatea pentru implementarea acestei func\u021bionalit\u0103\u021bi a fost crescut\u0103)<\/i><\/li>\n<li> <i>Termene: martie-aprilie martie<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/1614\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\n\u00cen prezent, werf v1.0 \u0219i v1.1 pot fi utilizate doar pe un singur gazd\u0103 dedicat\u0103 pentru opera\u021biuni de construire \u0219i publicare a imaginilor \u0219i desf\u0103\u0219urarea aplica\u021biilor \u00een Kubernetes.<\/p>\n<p>Pentru a deschide posibilit\u0103\u021bile lucrului distribuit cu werf, c\u00e2nd construirea \u0219i desf\u0103\u0219urarea aplica\u021biilor \u00een Kubernetes sunt ini\u021biate pe mai multe gazde arbitrare \u0219i aceste gazde nu \u00ee\u0219i p\u0103streaz\u0103 starea \u00eentre construc\u021bii (runneri temporari), werf trebuie s\u0103 implementeze func\u021bionalitatea de a utiliza Docker Registry ca depozit pentru etape.<\/p>\n<p>Anterior, c\u00e2nd proiectul werf era denumit dapp, exista aceast\u0103 func\u021bionalitate. Totu\u0219i, ne-am confruntat cu o serie de probleme care trebuie luate \u00een considerare pentru implementarea acestei func\u021bii \u00een werf.<\/p>\n<p><b>Not\u0103<\/b>. Aceast\u0103 func\u021bionalitate nu presupune utilizarea unui constructor \u00een interiorul pod-urilor Kubernetes, deoarece este necesar s\u0103 se elimine dependen\u021ba de serverul Docker local (\u00een pod-ul Kubernetes nu exist\u0103 acces la serverul Docker local, deoarece procesul este pornit \u00eentr-un container, iar gestionarea serverului Docker prin re\u021bea nu este suportat\u0103 \u0219i nu va fi suportat\u0103 de werf). Suportul pentru func\u021bionarea \u00een Kubernetes va fi implementat separat.<\/p>\n<h3>Suport oficial pentru GitHub Actions (NOU)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versiune: v1.1<\/i><\/li>\n<li> <i>Termene: martie<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2210\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nInclude documenta\u021bia werf (sec\u021biunile <i>reference<\/i> \u0219i <i>ghid<\/i>), precum \u0219i un GitHub Action oficial pentru lucru cu werf.<\/p>\n<p>\u00cen plus, va permite utilizarea werf pe runner-e efemere.<\/p>\n<p>Mecanica interac\u021biunii utilizatorului cu sistemul CI se va baza pe atribuirea de etichete pe pull-request-uri pentru a ini\u021bia anumite ac\u021biuni de construc\u021bie\/deploy al aplica\u021biei.<\/p>\n<h3>Dezvoltarea local\u0103 \u0219i desf\u0103\u0219urarea aplica\u021biilor cu werf (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versiune: v1.1<\/i><\/li>\n<li> <i>Termene: ianuarie-februarie aprilie<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/1940\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nPrincipala obiectiv\u0103 este de a ob\u021bine o configura\u021bie unificat\u0103 pentru desf\u0103\u0219urarea aplica\u021biilor at\u00e2t local, c\u00e2t \u0219i \u00een produc\u021bie, f\u0103r\u0103 ac\u021biuni complicate, \u00about of the box\u00bb.<\/p>\n<p>De la werf, se cere, de asemenea, un mod de lucru \u00een care s\u0103 fie comod s\u0103 editezi codul aplica\u021biei \u0219i s\u0103 ob\u021bii feedback instantaneu de la aplica\u021bia func\u021bional\u0103 pentru debugging.<\/p>\n<h3>Noul algoritm de cur\u0103\u021bare (NOU)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versiune: v1.1<\/i><\/li>\n<li> <i>Termene: aprilie<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2212\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\n\u00cen versiunea curent\u0103 werf v1.1, procedura <code>cleanup<\/code> nu prevede cur\u0103\u021barea imaginilor pentru schema de etichetare pe baza con\u021binutului (content-based tagging) - aceste imagini se vor acumula.<\/p>\n<p>De asemenea, \u00een versiunea curent\u0103 werf (v1.0 \u0219i v1.1) se folosesc politici diferite de cur\u0103\u021bare pentru imaginile publicate pe schemele de etichetare: ramur\u0103 Git, etichet\u0103 Git sau commit Git.<\/p>\n<p>S-a conceput un nou algoritm unificat pentru toate schemele de etichetare pentru cur\u0103\u021barea imaginilor pe baza istoricului commit-urilor \u00een Git:<\/p>\n<ul>\n<li> A p\u0103stra nu mai mult de N1 imagini, asociate cu ultimele N2 commit-uri pentru fiecare din git HEAD (ramuri \u0219i etichete).<\/li>\n<li> A p\u0103stra nu mai mult de N1 imagini-stadii, asociate cu ultimele N2 commit-uri pentru fiecare din git HEAD (ramuri \u0219i etichete).<\/li>\n<li> S\u0103 stoc\u0103m toate imaginile care sunt folosite \u00een orice resurse din clusterul Kubernetes (toate kube-context-urile din fi\u0219ierul de configura\u021bie \u0219i namespace-urile sunt scanate; se poate restric\u021biona acest comportament prin op\u021biuni speciale).<\/li>\n<li> A p\u0103stra toate imaginile care sunt folosite \u00een manife\u0219tele de configurare a resurselor, salvate \u00een versiunile Helm.<\/li>\n<li> O imagine poate fi eliminat\u0103 dac\u0103 nu este asociat\u0103 cu niciun HEAD din git (de exemplu, pentru c\u0103 HEAD-ul corespunz\u0103tor a fost \u0219ters) \u0219i nu este folosit\u0103 \u00een niciunul dintre manife\u0219tele din cluster-ul Kubernetes \u0219i \u00een versiunile Helm.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Construirea paralel\u0103 a imaginilor (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versiune: v1.1<\/i><\/li>\n<li> <i>Termene: ianuarie-februarie aprilie*<\/i><\/li>\n<\/ul>\n<p>\nVersiunea curent\u0103 werf construie\u0219te imaginile \u0219i artefactele descrise \u00een <code>werf.yaml<\/code>, succesiune. Este necesar s\u0103 se paralelizeze procesul de construc\u021bie al stadiilor independente de imagini \u0219i artefacte, precum \u0219i s\u0103 se asigure o ie\u0219ire comod\u0103 \u0219i informativ\u0103.<\/p>\n<p><i>* Not\u0103: termenul a fost mutat din cauza cre\u0219terii priorit\u0103\u021bii pentru implementarea construc\u021biei distribuite, care va ad\u0103uga mai multe capabilit\u0103\u021bi pentru scalarea orizontal\u0103, precum \u0219i utilizarea werf cu GitHub Actions. Totu\u0219i, construc\u021bia paralel\u0103 este urm\u0103torul pas de optimizare, oferind scalabilitate vertical\u0103 \u00een construirea unui singur proiect.<\/i><\/p>\n<h3>Tranzi\u021bia la Helm 3 (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versiunea: v1.2<\/i><\/li>\n<li> <i>Termene: februarie-martie mai*<\/i><\/li>\n<\/ul>\n<p>\nInclude tranzi\u021bia la o nou\u0103 baz\u0103 de cod <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/news\/t\/475722\/\">Helm 3<\/a><\/noindex> \u0219i un mod verificat \u0219i comod de migrare a instala\u021biilor existente.<\/p>\n<p><i>* Not\u0103: trecerea la Helm 3 nu va ad\u0103uga func\u021bionalit\u0103\u021bi semnificative \u00een werf, deoarece toate caracteristicile cheie ale Helm 3 (3-way-merge \u0219i absen\u021ba tiller) sunt deja implementate \u00een werf. Mai mult, werf are <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/differences_with_helm.html\">func\u021bionalit\u0103\u021bi suplimentare<\/a><\/noindex> pe l\u00e2ng\u0103 cele men\u021bionate. Totu\u0219i, aceast\u0103 trecere r\u0103m\u00e2ne \u00een planurile noastre \u0219i va fi realizat\u0103.<\/i><\/p>\n<h3>Jsonnet pentru descrierea configura\u021biei Kubernetes (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versiunea: v1.2<\/i><\/li>\n<li> <i>Termene: ianuarie-februarie aprilie-mai<\/i><\/li>\n<\/ul>\n<p>\nWerf va sus\u021bine descrierea configura\u021biei pentru Kubernetes \u00een format Jsonnet. \u00cen acest proces, werf va r\u0103m\u00e2ne compatibil cu Helm \u0219i va exista op\u021biunea de alegere a formatului de descriere.<\/p>\n<p>Cauza este faptul c\u0103 \u0219abloanele limbajului Go, conform opiniei multora, au un prag de intrare ridicat, iar claritatea codului acestor \u0219abloane sufer\u0103 de asemenea.<\/p>\n<p>De asemenea, se ia \u00een considerare posibilitatea implement\u0103rii altor sisteme de descriere a configura\u021biei Kubernetes (de exemplu, Kustomize).<\/p>\n<h3>Lucrul \u00een interiorul Kubernetes (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versiunea: v1.2<\/i><\/li>\n<li> <i>Termene: aprilie-mai mai-iunie<\/i><\/li>\n<\/ul>\n<p>\nObiectiv: a asigura construirea imaginilor \u0219i livrarea aplica\u021biei cu ajutorul runner-urilor \u00een Kubernetes. Adic\u0103, construirea de noi imagini, publicarea acestora, cur\u0103\u021barea \u0219i implementarea pot avea loc direct din pod-urile Kubernetes.<\/p>\n<p>Pentru a implementa aceast\u0103 func\u021bionalitate, este necesar\u0103 mai \u00eent\u00e2i capacitatea de construire distribuit\u0103 a imaginilor <i>(vezi punctul de mai sus)<\/i>.<\/p>\n<p>Este, de asemenea, necesar\u0103 suportul pentru modul de lucru al constructorului f\u0103r\u0103 server Docker (adic\u0103, construc\u021bie de tip Kaniko sau construc\u021bie \u00een userspace).<\/p>\n<p>Werf va sus\u021bine construirea \u00een Kubernetes nu doar prin Dockerfile, ci \u0219i prin constructorul s\u0103u Stapel cu recompil\u0103ri incrementale \u0219i Ansible.<\/p>\n<h2>O mi\u0219care c\u0103tre dezvoltarea deschis\u0103<\/h2>\n<p>\nNe p\u0103sa de comunitatea noastr\u0103 (<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>) \u0219i dorim ca din ce \u00een ce mai mul\u021bi oameni s\u0103 ajute la \u00eembun\u0103t\u0103\u021birea werf, s\u0103 \u00een\u021beleag\u0103 \u00een ce direc\u021bie ne \u00eendrept\u0103m \u0219i s\u0103 participe la dezvoltare.<\/p>\n<p>Recent a fost decis\u0103 trecerea la <noindex><a rel=\"nofollow\" href=\"https:\/\/help.github.com\/en\/github\/managing-your-work-on-github\/about-project-boards\">tablouri de proiecte GitHub<\/a><\/noindex> pentru a deschide procesul de lucru al echipei noastre. Acum este posibil s\u0103 vedem planurile imediate, precum \u0219i lucr\u0103rile curente \u00een urm\u0103toarele direc\u021bii:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/9\">Documenta\u021bie \u0219i Site<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/7\">Testare<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/6\">Defec\u021biuni \u0219i UX slab<\/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>\nS-a realizat o munc\u0103 semnificativ\u0103 cu problemele:<\/p>\n<ul>\n<li> Au fost eliminate cele irelevante.<\/li>\n<li> Cele existente au fost aduse \u00eentr-un format uniform, cu un num\u0103r suficient de detalii \u0219i specifica\u021bii.<\/li>\n<li> Au fost ad\u0103ugate probleme noi cu idei \u0219i sugestii.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Cum s\u0103 activa\u021bi versiunea v1.1<\/h2>\n<p>\nVersiunea este disponibil\u0103 \u00een prezent \u00een <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">canalul 1.1 ea<\/a><\/noindex> (\u00een canalele <i>stable<\/i> \u0219i <i>rock-solid<\/i> versiunile vor ap\u0103rea pe m\u0103sur\u0103 ce se stabilizeaz\u0103, totu\u0219i <i>ea<\/i> \u00een sine este deja suficient de stabil\u0103 pentru utilizare, deoarece a trecut prin canale <i>alpha<\/i> \u0219i <i>beta<\/i>). Se activeaz\u0103 <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\">prin multiwerf<\/a><\/noindex> \u00een urm\u0103torul mod:<\/p>\n<pre><code class=\"bash\">source $(multiwerf use 1.1 ea)\nwerf COMMAND ...<\/code><\/pre>\n<p><\/p>\n<h2>Concluzie<\/h2>\n<p>\nNoua arhitectur\u0103 de stocare a etapelor \u0219i optimizarea func\u021bion\u0103rii compilatorului pentru Stapel \u0219i Dockerfile deschid oportunit\u0103\u021bi pentru implementarea compil\u0103rilor distribuite \u0219i paralele \u00een werf. Aceste caracteristici vor ap\u0103rea cur\u00e2nd \u00een aceea\u0219i versiune v1.1 \u0219i vor deveni disponibile automat prin mecanismul de actualiz\u0103ri automate (pentru utilizatori <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>\u00cen aceast\u0103 versiune a fost ad\u0103ugat\u0103 o strategie de etichetare bazat\u0103 pe con\u021binutul imaginilor \u2014 <i>content-based tagging<\/i>, \u2014 care a devenit strategia implicit\u0103. De asemenea, a fost revizuit jurnalul principal al comenzilor: <code>werf build<\/code>, <code>werf publish<\/code>, <code>werf deploy<\/code>, <code>werf dismiss<\/code>, <code>werf cleanup<\/code>.<\/p>\n<p>Urm\u0103torul pas semnificativ va fi ad\u0103ugarea compil\u0103rilor distribuite. Compil\u0103rile distribuite au devenit o sarcin\u0103 mai prioritar\u0103 dec\u00e2t compil\u0103rile paralele din versiunea v1.0, deoarece adaug\u0103 mai mult\u0103 valoare werf: scalarea vertical\u0103 a compilatorilor \u0219i suport pentru compilatoare efemere \u00een diferite sisteme CI\/CD, precum \u0219i posibilitatea de a oferi suport oficial pentru GitHub Actions. Prin urmare, termenul de realizare a compil\u0103rilor paralele a fost mutat. Cu toate acestea, lucr\u0103m pentru a implementa rapid ambele func\u021bionalit\u0103\u021bi.<\/p>\n<p>R\u0103m\u00e2ne\u021bi la curent cu nout\u0103\u021bile! \u0218i nu uita\u021bi s\u0103 ne vizita\u021bi la <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, pentru a crea o problem\u0103, a g\u0103si una deja existent\u0103 \u0219i a pune un vot, a crea un PR sau pur \u0219i simplu pentru a observa evolu\u021bia proiectului.<\/p>\n<h2>P.S.<\/h2>\n<p>\nCiti\u021bi \u0219i \u00een blogul nostru:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">Prezent\u0103m werf 1.0 stabil: ce leg\u0103tur\u0103 are cu GitOps, statutul \u0219i planurile<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/460351\/\">werf \u2014 our tool for CI\/CD in Kubernetes (overview and presentation video)<\/a><\/noindex>\u00bb;<\/li>\n<li> Utilizarea werf pentru lansarea chart-urilor complexe Helm\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/476646\/\">Mergerea 3-way \u00een werf: implementare \u00een Kubernetes cu Helm \u201epe steroizi\u201d<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468049\/\">Utilizarea werf pentru implementarea chart-urilor complex Helm<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465131\/\">Suport pentru monorepo \u0219i multirepo \u00een werf \u0219i ce leg\u0103tur\u0103 are cu Docker Registry<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/463613\/\">Acum, pute\u021bi construi imagini Docker \u00een werf \u0219i folosind un Dockerfile obi\u0219nuit<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Sursa: <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.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\/ro\/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.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"ro_RO\" \/>\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\/ro\/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\udd47Versiunea werf 1.1: \u00eembun\u0103t\u0103\u021biri \u00een compilator ast\u0103zi \u0219i planuri pentru viitor | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/ro\/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":"ro_RO","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\/ro\/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\/ro\/wp-json\/wp\/v2\/posts\/76764","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=76764"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/76764\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/76765"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=76764"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=76764"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=76764"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}