{"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\/pl\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","title":{"rendered":"Wydanie werf 1.1: ulepszenia w kompilatorze oraz plany na przysz\u0142o\u015b\u0107.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Wydanie werf 1.1: ulepszenia w kompilatorze oraz plany na przysz\u0142o\u015b\u0107.\" 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 nasze narz\u0119dzie GitOps CLI z otwartym kodem \u017ar\u00f3d\u0142owym do budowania i dostarczania aplikacji w Kubernetes. Jak obiecali\u015bmy, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">premiera wersji v1.0<\/a><\/noindex> oznacza pocz\u0105tek dodawania nowych funkcji do werf oraz przegl\u0105du ustalonych podej\u015b\u0107. Teraz z rado\u015bci\u0105 prezentujemy wydanie v1.1, kt\u00f3re stanowi du\u017cy krok naprz\u00f3d i zapowiada przysz\u0142o\u015b\u0107 <i>kompilatora<\/i> werf. Wersja jest obecnie dost\u0119pna w <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">kanale 1.1 ea<\/a><\/noindex>.<\/p>\n<p>Podstaw\u0105 wydania jest nowa architektura magazynu etap\u00f3w oraz optymalizacja dzia\u0142ania obu kompilator\u00f3w (dla Stapel i Dockerfile). Nowa architektura magazynu otwiera mo\u017cliwo\u015bci realizacji rozproszonych kompilacji z kilku host\u00f3w oraz r\u00f3wnoleg\u0142ych kompilacji na jednym ho\u015bcie.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Optymalizacja dzia\u0142ania obejmuje eliminacj\u0119 zb\u0119dnych oblicze\u0144 na etapie obliczania sygnatur etap\u00f3w oraz zmian\u0119 mechanizm\u00f3w obliczania sum kontrolnych plik\u00f3w na bardziej efektywne. Ta optymalizacja zmniejsza \u015bredni czas kompilacji projektu przy u\u017cyciu werf. A tak\u017ce puste kompilacje, gdy wszystkie etapy istniej\u0105 w cache <i>stages-storage<\/i>, s\u0105 teraz naprawd\u0119 szybkie. W wi\u0119kszo\u015bci przypadk\u00f3w ponowne uruchomienie kompilacji zajmie mniej ni\u017c 1 sekund\u0119! Dotyczy to r\u00f3wnie\u017c procedur weryfikacji etap\u00f3w podczas pracy z zespo\u0142ami <code>werf deploy<\/code> i <code>werf run<\/code>.<\/p>\n<p>R\u00f3wnie\u017c w tej edycji pojawi\u0142a si\u0119 strategia tagowania obraz\u00f3w na podstawie tre\u015bci \u2014 <i>tagowania opartego na zawarto\u015bci<\/i>, kt\u00f3ra jest teraz domy\u015blnie w\u0142\u0105czona i jest jedyn\u0105 zalecan\u0105.<\/p>\n<p>Przyjrzyjmy si\u0119 dok\u0142adniej kluczowym nowinkom w werf v1.1, a tak\u017ce opowiemy o planach na przysz\u0142o\u015b\u0107.<\/p>\n<h2>Co zmieni\u0142o si\u0119 w werf v1.1?<\/h2>\n<p><\/p>\n<h3>Nowy format nazewnictwa etap\u00f3w i algorytm dobierania etap\u00f3w z cache<\/h3>\n<p>\nNowa zasada generowania nazwy etapu. Teraz ka\u017cda kompilacja etapu generuje unikaln\u0105 nazw\u0119 etapu, kt\u00f3ra sk\u0142ada si\u0119 z 2 cz\u0119\u015bci: sygnatura (jak w v1.0) plus unikalny identyfikator czasowy.<\/p>\n<p>Na przyk\u0142ad pe\u0142na nazwa obrazu etapu mo\u017ce wygl\u0105da\u0107 tak:<\/p>\n<p><code>werf-stages-storage\/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835<\/code><\/p>\n<p>\u2026 lub w og\u00f3lnym uj\u0119ciu:<\/p>\n<p><code>werf-stages-storage\/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC<\/code><\/p>\n<p>Gdzie:<\/p>\n<ul>\n<li> <code>SIGNATURE<\/code> \u2014 to sygnatura etapu, kt\u00f3ra reprezentuje identyfikator tre\u015bci etapu i zale\u017cy od historii zmian w Git, kt\u00f3re doprowadzi\u0142y do tej tre\u015bci;<\/li>\n<li> <code>TIMESTAMP_MILLISEC<\/code> \u2014 to gwarantowany unikalny identyfikator obrazu, kt\u00f3ry jest generowany w momencie budowy nowego obrazu.<\/li>\n<\/ul>\n<p>\nAlgorytm dobierania etap\u00f3w z cache oparty jest na sprawdzaniu pokrewie\u0144stwa commit\u00f3w Git:<\/p>\n<ol>\n<li> Werf oblicza sygnatur\u0119 etapu.<\/li>\n<li> W <i>stages-storage<\/i> Mo\u017ce istnie\u0107 wiele etap\u00f3w o danej sygnaturze. Werf wybiera wszystkie odpowiednie etapy zgodnie z sygnatur\u0105.<\/li>\n<li> Je\u015bli bie\u017c\u0105cy etap jest zwi\u0105zany z Git (git-archive, u\u017cytkownik etapu z \u0142atkami Git: <code>install<\/code>, <code>beforeSetup<\/code>, <code>setup<\/code>; lub git-latest-patch), to werf wybiera tylko te etapy, kt\u00f3re s\u0105 zwi\u0105zane z commit'em, b\u0119d\u0105cym przodkiem bie\u017c\u0105cego commita (dla kt\u00f3rego wywo\u0142ano budow\u0119).<\/li>\n<li> Z pozosta\u0142ych odpowiednich etap\u00f3w wybierany jest jeden \u2014 najstarszy pod wzgl\u0119dem daty utworzenia.<\/li>\n<\/ol>\n<p>\nEtap dla r\u00f3\u017cnych ga\u0142\u0119zi Git mo\u017ce mie\u0107 t\u0119 sam\u0105 sygnatur\u0119. Jednak werf zapobiegnie u\u017cywaniu pami\u0119ci podr\u0119cznej zwi\u0105zanej z r\u00f3\u017cnymi ga\u0142\u0119ziami, nawet je\u015bli sygnatury si\u0119 pokrywaj\u0105.<\/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 Dokumentacja<\/a><\/noindex>.<\/p>\n<h3>Nowy algorytm tworzenia i zapisywania etap\u00f3w w repozytorium etap\u00f3w<\/h3>\n<p>\nJe\u015bli podczas wyszukiwania etap\u00f3w w pami\u0119ci podr\u0119cznej werf nie znajdzie odpowiedniego etapu, inicjowany jest proces budowy nowego etapu.<\/p>\n<p>Zauwa\u017cmy, \u017ce kilka proces\u00f3w (na jednym lub kilku hostach) mo\u017ce rozpocz\u0105\u0107 budow\u0119 tego samego etapu w mniej wi\u0119cej tym samym czasie. Werf wykorzystuje algorytm optymistycznej blokady <i>stages-storage<\/i> w momencie zapisywania nowo zbudowanego obrazu w <i>stages-storage<\/i>. W ten spos\u00f3b, gdy budowa nowego etapu jest gotowa, werf blokuje <i>stages-storage<\/i> i zapisuje tam nowo zbudowany obraz tylko wtedy, gdy nie istnieje ju\u017c odpowiedni obraz <i>(zgodnie z sygnatur\u0105 i innymi parametrami \u2014 zob. nowy algorytm wyszukiwania etap\u00f3w w pami\u0119ci podr\u0119cznej)<\/i>.<\/p>\n<p>Nowo zbudowany obraz zapewne b\u0119dzie mia\u0142 unikalny identyfikator wed\u0142ug <code>TIMESTAMP_MILLISEC<\/code> <i>(zob. nowy format nazewnictwa etap\u00f3w)<\/i>. W przypadku, gdy w <i>stages-storage<\/i> znajdzie si\u0119 odpowiedni obraz, werf odrzuci nowo zbudowany obraz i u\u017cyje obrazu z pami\u0119ci podr\u0119cznej.<\/p>\n<p>Innymi s\u0142owy: pierwszy proces, kt\u00f3ry zako\u0144czy budow\u0119 obrazu (najszybszy), otrzyma prawo do jego zapisania w stages-storage (i to w\u0142a\u015bnie ten jeden obraz b\u0119dzie u\u017cywany dla wszystkich bud\u00f3w). Wolniejszy proces budowy nigdy nie zablokuje szybszego procesu przed zapisaniem wynik\u00f3w budowy bie\u017c\u0105cego etapu i przej\u015bciem do budowy nast\u0119pnego.<\/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 Dokumentacja<\/a><\/noindex>.<\/p>\n<h3>Poprawiono wydajno\u015b\u0107 budowniczego Dockerfile<\/h3>\n<p>\nDo tej pory pipeline etap\u00f3w dla obrazu budowanego z Dockerfile sk\u0142ada si\u0119 z jednego etapu \u2014 <code>dockerfile<\/code>. Przy obliczaniu sygnatury uwzgl\u0119dniana jest suma kontrolna plik\u00f3w <code>context<\/code>, kt\u00f3re b\u0119d\u0105 u\u017cywane podczas budowy. Przed tym ulepszeniem werf rekursywnie przechodzi\u0142 przez wszystkie pliki i oblicza\u0142 sum\u0119 kontroln\u0105, sumuj\u0105c kontekst i modu\u0142 ka\u017cdego pliku. Pocz\u0105wszy od wersji v1.1, werf mo\u017ce korzysta\u0107 z obliczonych sum kontrolnych, przechowywanych w repozytorium Git.<\/p>\n<p>Podstaw\u0105 algorytmu jest <noindex><a rel=\"nofollow\" href=\"https:\/\/git-scm.com\/docs\/git-ls-tree\">git ls-tree<\/a><\/noindex>. Algorytm uwzgl\u0119dnia wpisy w <code>.dockerignore<\/code> i przechodzi rekursywnie przez drzewo plik\u00f3w tylko w razie potrzeby. Dzi\u0119ki temu uwolnili\u015bmy si\u0119 od odczytywania systemu plik\u00f3w, a zale\u017cno\u015b\u0107 algorytmu od rozmiaru <code>context<\/code> nie jest istotna.<\/p>\n<p>Algorytm r\u00f3wnie\u017c sprawdza pliki untracked i w razie potrzeby uwzgl\u0119dnia je w sumie kontrolnej.<\/p>\n<h3>Ulepszono wydajno\u015b\u0107 podczas importowania plik\u00f3w<\/h3>\n<p>\nW wersjach werf v1.1 wykorzystuje si\u0119 serwer rsync podczas <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/configuration\/stapel_image\/import_directive.html\">importowania plik\u00f3w z artefakt\u00f3w i obraz\u00f3w<\/a><\/noindex>. Wcze\u015bniej import odbywa\u0142 si\u0119 w dw\u00f3ch krokach z u\u017cyciem montowania katalogu z systemu gospodarza.<\/p>\n<p>Wydajno\u015b\u0107 import\u00f3w w macOS nie jest ju\u017c ograniczona przez Docker volumes, a importy odbywaj\u0105 si\u0119 w tym samym czasie, co w systemach Linux i Windows.<\/p>\n<h3>Tagowanie oparte na zawarto\u015bci<\/h3>\n<p>\nWerf v1.1 wspiera tzw. tagowanie oparte na zawarto\u015bci obrazu \u2014 <i>tagowania opartego na zawarto\u015bci<\/i>. Tagi wynikowych obraz\u00f3w Docker zale\u017c\u0105 od zawarto\u015bci tych obraz\u00f3w.<\/p>\n<p>Podczas uruchamiania polecenia <code>werf publish --tags-by-stages-signature<\/code> lub <code>werf ci-env --tagging-strategy=stages-signature<\/code> b\u0119d\u0105 tagowane publikowane obrazy tzw. <b>podpisem etap\u00f3w<\/b> obrazu. Ka\u017cdy obraz jest tagowany swoim w\u0142asnym podpisem etap\u00f3w tego obrazu, kt\u00f3ry jest obliczany na tych samych zasadach, co zwyk\u0142y podpis ka\u017cdego etapu z osobna, ale stanowi uog\u00f3lniony identyfikator obrazu.<\/p>\n<p>Podpis etap\u00f3w obrazu zale\u017cy od:<\/p>\n<ol>\n<li> zawarto\u015bci tego obrazu;<\/li>\n<li> historii zmian w Git, kt\u00f3re doprowadzi\u0142y do tej zawarto\u015bci.<\/li>\n<\/ol>\n<p>\nW repozytorium Git zawsze znajduj\u0105 si\u0119 puste commity, kt\u00f3re nie zmieniaj\u0105 zawarto\u015bci plik\u00f3w obrazu. Na przyk\u0142ad, commity tylko z komentarzami, merge-commity lub commity, kt\u00f3re zmieniaj\u0105 te pliki w Git, kt\u00f3re nie b\u0119d\u0105 importowane do obrazu.<\/p>\n<p>W przypadku u\u017cycia tagowania opartego na tre\u015bci rozwi\u0105zywane s\u0105 problemy z niepo\u017c\u0105danymi restartami pod\u00f3w aplikacji w Kubernetes z powodu zmiany nazwy obrazu, nawet gdy zawarto\u015b\u0107 obrazu si\u0119 nie zmieni\u0142a. Zreszt\u0105 to jest jedna z przyczyn, kt\u00f3re uniemo\u017cliwiaj\u0105 przechowywanie wielu mikroserwis\u00f3w jednej aplikacji w jednym repozytorium Git.<\/p>\n<p>Tagowanie oparte na tre\u015bci jest r\u00f3wnie\u017c bardziej niezawodnym sposobem tagowania ni\u017c tagowanie oparte na ga\u0142\u0119ziach Git, poniewa\u017c zawarto\u015b\u0107 wynikowych obraz\u00f3w nie zale\u017cy od kolejno\u015bci wykonywania potok\u00f3w w systemie CI do budowy kilku commit\u00f3w z tej samej ga\u0142\u0119zi.<\/p>\n<p><b>Wa\u017cne<\/b>: pocz\u0105wszy od tego momentu <i>stages-signature<\/i> \u2014 to <b>jedyna zalecana strategia tagowania<\/b>. B\u0119dzie ona u\u017cywana domy\u015blnie w zespole <code>werf ci-env<\/code> (chyba \u017ce wyra\u017anie okre\u015blono inn\u0105 schemat tagowania).<\/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 Dokumentacja<\/a><\/noindex>. Ta funkcja zostanie r\u00f3wnie\u017c om\u00f3wiona w osobnym artykule. <b>ZAAKTUALIZOWANO<\/b> (3 kwietnia): Artyku\u0142 ze szczeg\u00f3\u0142ami <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/495112\/\">opublikowane<\/a><\/noindex>.<\/p>\n<h3>Poziomy logowania<\/h3>\n<p>\nU\u017cytkownik ma mo\u017cliwo\u015b\u0107 kontrolowania wyj\u015bcia, ustalania poziomu logowania i pracy z informacjami debuguj\u0105cymi. Dodano opcje <code>--log-quiet<\/code>, <code>--log-verbose<\/code>, <code>--log-debug<\/code>.<\/p>\n<p>Domy\u015blnie w wyj\u015bciu znajduje si\u0119 minimum informacji:<\/p>\n<p><img decoding=\"async\" alt=\"Wydanie werf 1.1: ulepszenia w kompilatorze oraz plany na przysz\u0142o\u015b\u0107.\" src=\"\/wp-content\/uploads\/2020\/04\/58e981b2e0c579ddde817eadc1732874.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPrzy u\u017cyciu szczeg\u00f3\u0142owego wyj\u015bcia (<code>--log-verbose<\/code>) mo\u017cna \u015bledzi\u0107, jak dzia\u0142a werf:<\/p>\n<p><img decoding=\"async\" alt=\"Wydanie werf 1.1: ulepszenia w kompilatorze oraz plany na przysz\u0142o\u015b\u0107.\" src=\"\/wp-content\/uploads\/2020\/04\/487ed5dfc5df0178f7c09f8da697ceff.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSzczeg\u00f3\u0142owe wyj\u015bcie (<code>--log-debug<\/code>), opr\u00f3cz informacji debuguj\u0105cych werf, zawiera r\u00f3wnie\u017c logi u\u017cywanych bibliotek. Mo\u017cna na przyk\u0142ad zobaczy\u0107, jak odbywa si\u0119 interakcja z Docker Registry i zidentyfikowa\u0107 miejsca, w kt\u00f3rych sp\u0119dza si\u0119 du\u017c\u0105 ilo\u015b\u0107 czasu:<\/p>\n<p><img decoding=\"async\" alt=\"Wydanie werf 1.1: ulepszenia w kompilatorze oraz plany na przysz\u0142o\u015b\u0107.\" src=\"\/wp-content\/uploads\/2020\/04\/99c1f3c2ab3803ff11fae1f2d5c9a5af.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Plany przysz\u0142o\u015bciowe<\/h2>\n<p>\n<b>Uwaga!<\/b> Opisane poni\u017cej funkcje z oznaczeniem <b>v1.1<\/b> stan\u0105 si\u0119 dost\u0119pne w tej wersji, z wielu z nich - w najbli\u017cszym czasie. Aktualizacje zostan\u0105 wprowadzone za po\u015brednictwem automatycznych aktualizacji <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\">przy u\u017cyciu multiwerf<\/a><\/noindex>. Te funkcje nie dotycz\u0105 stabilnej cz\u0119\u015bci funkcji v1.1, ich pojawienie si\u0119 nie wymaga r\u0119cznego interwencji u\u017cytkownika w istniej\u0105ce konfiguracje.<\/p>\n<h3>Pe\u0142na obs\u0142uga r\u00f3\u017cnych realizacji Docker Registry (NOWO\u015a\u0106)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Wersja: v1.1<\/i><\/li>\n<li> <i>Terminy: marzec<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2199\">Problemu<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nCelem jest to, aby u\u017cytkownik m\u00f3g\u0142 korzysta\u0107 z dowolnej realizacji bez ogranicze\u0144 podczas korzystania z werf. <\/p>\n<p>Na ten moment wyodr\u0119bniamy nast\u0119puj\u0105cy zestaw rozwi\u0105za\u0144, dla kt\u00f3rych zamierzamy zapewni\u0107 pe\u0142ne wsparcie:<\/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>\nRozwi\u0105zania zaznaczone gwiazdk\u0105 to te, kt\u00f3re obecnie s\u0105 ju\u017c w pe\u0142ni wspierane przez werf. Dla pozosta\u0142ych jest wsparcie, ale z ograniczeniami.<\/p>\n<p>Mo\u017cna wyr\u00f3\u017cni\u0107 dwa g\u0142\u00f3wne problemy:<\/p>\n<ul>\n<li> Niekt\u00f3re rozwi\u0105zania nie obs\u0142uguj\u0105 usuwania tag\u00f3w za pomoc\u0105 API Docker Registry, co uniemo\u017cliwia u\u017cytkownikom korzystanie z automatycznego czyszczenia, wdro\u017conego w werf. Dotyczy to AWS ECR, Docker Hub i GitHub Packages.<\/li>\n<li> Niekt\u00f3re rozwi\u0105zania nie obs\u0142uguj\u0105 tak zwanych zagnie\u017cd\u017conych repozytori\u00f3w (Docker Hub, GitHub Packages i Quay) albo obs\u0142uguj\u0105 je, ale u\u017cytkownik musi je tworzy\u0107 r\u0119cznie, korzystaj\u0105c z UI lub API (AWS ECR).<\/li>\n<\/ul>\n<p>\nTe i inne problemy zamierzamy rozwi\u0105za\u0107, korzystaj\u0105c z natywnych API tych rozwi\u0105za\u0144. W ten proces wchodzi r\u00f3wnie\u017c pokrycie testami ca\u0142ego cyklu pracy werf dla ka\u017cdego z nich.<\/p>\n<h3>Rozproszona budowa obraz\u00f3w (\u2191)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Wersja: v1.2 v1.1 (priorytet dla wdro\u017cenia tej funkcji zosta\u0142 zwi\u0119kszony)<\/i><\/li>\n<li> <i>Terminy: marzec-kwiecie\u0144 marzec<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/1614\">Problemu<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nNa chwil\u0119 obecn\u0105, werf v1.0 i v1.1 mo\u017cna u\u017cywa\u0107 jedynie na jednym dedykowanym ho\u015bcie do operacji budowy i publikacji obraz\u00f3w oraz do wdra\u017cania aplikacji w Kubernetes.<\/p>\n<p>Aby zrealizowa\u0107 mo\u017cliwo\u015bci rozproszonej pracy werf, kiedy budowa i wdro\u017cenie aplikacji w Kubernetes odbywaj\u0105 si\u0119 na wielu dowolnych hostach, a hosty te nie zachowuj\u0105 swojego stanu mi\u0119dzy budowami (tymczasowe runner\u2019y), wymagana jest realizacja mo\u017cliwo\u015bci u\u017cywania Docker Registry jako magazynu krok\u00f3w.<\/p>\n<p>Wcze\u015bniej, kiedy projekt werf nosi\u0142 nazw\u0119 dapp, ta funkcjonalno\u015b\u0107 istnia\u0142a. Jednak napotkali\u015bmy szereg problem\u00f3w, kt\u00f3re nale\u017cy uwzgl\u0119dni\u0107 przy wdro\u017ceniu tej funkcji w werf.<\/p>\n<p><b>Uwaga<\/b>. Ta funkcjonalno\u015b\u0107 nie zak\u0142ada dzia\u0142ania kompilatora wewn\u0105trz pod\u00f3w Kubernetes, poniewa\u017c w tym celu konieczne jest pozbycie si\u0119 zale\u017cno\u015bci od lokalnego serwera Docker (w podzie Kubernetes nie ma dost\u0119pu do lokalnego serwera Docker, poniewa\u017c sam proces jest uruchomiony w kontenerze, a praca z serwerem Docker przez sie\u0107 nie jest wspierana i nie b\u0119dzie wspierana przez werf). Wsparcie dla pracy w Kubernetes zostanie wdro\u017cone osobno.<\/p>\n<h3>Oficjalne wsparcie dla GitHub Actions (NOWO\u015a\u0106)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Wersja: v1.1<\/i><\/li>\n<li> <i>Terminy: marzec<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2210\">Problemu<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nZawiera dokumentacj\u0119 werf (sekcje <i>reference<\/i> i <i>guide<\/i>), a tak\u017ce oficjaln\u0105 akcj\u0119 GitHub do pracy z werf.<\/p>\n<p>Dodatkowo umo\u017cliwi to dzia\u0142anie werf na efemerycznych runnerach.<\/p>\n<p>Mechanika interakcji u\u017cytkownika z systemem CI b\u0119dzie oparta na wystawianiu etykiet na pull-requesty w celu inicjowania okre\u015blonych dzia\u0142a\u0144 zwi\u0105zanych z budow\u0105\/implementacj\u0105 aplikacji.<\/p>\n<h3>Lokalny rozw\u00f3j i wdra\u017canie aplikacji z werf (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Wersja: v1.1<\/i><\/li>\n<li> <i>Terminy: stycze\u0144-luty kwiecie\u0144<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/1940\">Problemu<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nG\u0142\u00f3wnym celem jest osi\u0105gni\u0119cie pojedynczej, zunifikowanej konfiguracji do wdra\u017cania aplikacji zar\u00f3wno lokalnie, jak i w produkcji, bez skomplikowanych dzia\u0142a\u0144, \u201ez pude\u0142ka\u201d.<\/p>\n<p>Od werf wymagana jest r\u00f3wnie\u017c taka metoda pracy, kt\u00f3ra umo\u017cliwia wygodn\u0105 edycj\u0119 kodu aplikacji i natychmiastowe uzyskiwanie informacji zwrotnej z dzia\u0142aj\u0105cej aplikacji do debugowania.<\/p>\n<h3>Nowy algorytm czyszczenia (NOWO\u015a\u0106)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Wersja: v1.1<\/i><\/li>\n<li> <i>Terminy: kwiecie\u0144<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2212\">Problemu<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nW bie\u017c\u0105cej wersji werf v1.1 w procedurze <code>cleanup<\/code> nie przewiduje si\u0119 czyszczenia obraz\u00f3w dla schematu tagowania opartego na zawarto\u015bci (content-based tagging) \u2014 te obrazy b\u0119d\u0105 si\u0119 gromadzi\u0107.<\/p>\n<p>W bie\u017c\u0105cej wersji werf (v1.0 i v1.1) stosowane s\u0105 r\u00f3\u017cne polityki czyszczenia dla obraz\u00f3w opublikowanych zgodnie z schematami tagowania: ga\u0142\u0105\u017a Git, znacznik Git lub commit Git.<\/p>\n<p>Wprowadzono nowy ujednolicony algorytm czyszczenia obraz\u00f3w dla wszystkich schemat\u00f3w tagowania, oparty na historii commit\u00f3w w Git:<\/p>\n<ul>\n<li> Przechowywa\u0107 nie wi\u0119cej ni\u017c N1 obraz\u00f3w powi\u0105zanych z N2 ostatnimi commitami dla ka\u017cdego z git HEAD (ga\u0142\u0119zie i tagi).<\/li>\n<li> Przechowywa\u0107 nie wi\u0119cej ni\u017c N1 obraz\u00f3w-etap\u00f3w powi\u0105zanych z N2 ostatnimi commitami dla ka\u017cdego z git HEAD (ga\u0142\u0119zie i tagi).<\/li>\n<li> Przechowywa\u0107 wszystkie obrazy, kt\u00f3re s\u0105 u\u017cywane w jakichkolwiek zasobach klastra Kubernetes (skanowane s\u0105 wszystkie kube-konteksty pliku konfiguracyjnego i namespace; takie zachowanie mo\u017cna ograniczy\u0107 specjalnymi opcjami).<\/li>\n<li> Przechowywa\u0107 wszystkie obrazy, kt\u00f3re s\u0105 u\u017cywane w manifestach konfiguracji zasob\u00f3w zapisanych w Helm-release.<\/li>\n<li> Obraz mo\u017ce by\u0107 usuni\u0119ty, je\u017celi nie jest powi\u0105zany z \u017cadnym HEAD z git (na przyk\u0142ad, poniewa\u017c odpowiedni HEAD zosta\u0142 usuni\u0119ty) i nie jest u\u017cywany w \u017cadnym z manifest\u00f3w w klastrze Kubernetes oraz w release'ach Helm.<\/li>\n<\/ul>\n<p><\/p>\n<h3>R\u00f3wnoleg\u0142a budowa obraz\u00f3w (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Wersja: v1.1<\/i><\/li>\n<li> <i>Terminy: stycze\u0144-luty kwiecie\u0144*<\/i><\/li>\n<\/ul>\n<p>\nAktualna wersja werf buduje obrazy i artefakty opisane w <code>werf.yaml<\/code>, kolejno. Nale\u017cy zr\u00f3wnolegli\u0107 proces budowy niezale\u017cnych etap\u00f3w obraz\u00f3w i artefakt\u00f3w, a tak\u017ce zapewni\u0107 wygodny i informacyjny wyj\u015bciowy.<\/p>\n<p><i>* Uwaga: termin zosta\u0142 przesuni\u0119ty z powodu wy\u017cszego priorytetu w realizacji rozproszonej budowy, kt\u00f3ra doda wi\u0119cej mo\u017cliwo\u015bci skalowania poziomego oraz u\u017cywania werf z GitHub Actions. R\u00f3wnoleg\u0142a budowa jest nast\u0119pnym krokiem optymalizacji, daj\u0105cym skalowalno\u015b\u0107 pionow\u0105 przy budowie jednego projektu.<\/i><\/p>\n<h3>Migracja na Helm 3 (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Wersja: v1.2<\/i><\/li>\n<li> <i>Terminy: luty-marzec maj*<\/i><\/li>\n<\/ul>\n<p>\nObj\u0119to to przej\u015bciem na now\u0105 baz\u0119 kodu <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/news\/t\/475722\/\">Helm 3<\/a><\/noindex> oraz sprawdzony, wygodny spos\u00f3b migracji istniej\u0105cych instalacji.<\/p>\n<p><i>* Uwaga: przej\u015bcie na Helm 3 nie doda istotnych mo\u017cliwo\u015bci do werf, poniewa\u017c wszystkie kluczowe funkcje Helm 3 (3-way-merge i brak tillera) s\u0105 ju\u017c zaimplementowane w werf. Co wi\u0119cej, werf ma <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/differences_with_helm.html\">dodatkowe mo\u017cliwo\u015bci<\/a><\/noindex> poza wymienionymi. Jednak to przej\u015bcie pozostaje w naszych planach i zostanie zrealizowane.<\/i><\/p>\n<h3>Jsonnet do opisu konfiguracji Kubernetes (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Wersja: v1.2<\/i><\/li>\n<li> <i>Terminy: stycze\u0144-luty, kwiecie\u0144-maj<\/i><\/li>\n<\/ul>\n<p>\nWerf b\u0119dzie wspiera\u0107 opis konfiguracji dla Kubernetes w formacie Jsonnet. Przy tym werf pozostanie zgodny z Helm i b\u0119dzie mo\u017cliwo\u015b\u0107 wyboru formatu opisu.<\/p>\n<p>Powodem jest to, \u017ce szablony j\u0119zyka Go, wed\u0142ug ocen wielu os\u00f3b, maj\u0105 wysoki pr\u00f3g wej\u015bcia, a zrozumia\u0142o\u015b\u0107 kodu tych szablon\u00f3w r\u00f3wnie\u017c cierpi.<\/p>\n<p>Rozwa\u017cana jest r\u00f3wnie\u017c mo\u017cliwo\u015b\u0107 wdro\u017cenia innych system\u00f3w opisu konfiguracji Kubernetes (na przyk\u0142ad Kustomize).<\/p>\n<h3>Praca wewn\u0105trz Kubernetes (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Wersja: v1.2<\/i><\/li>\n<li> <i>Terminy: kwiecie\u0144-maj, maj-czerwiec<\/i><\/li>\n<\/ul>\n<p>\nCel: zapewnienie budowy obraz\u00f3w i dostarczania aplikacji za pomoc\u0105 runner\u00f3w w Kubernetes. Tzn. budowa nowych obraz\u00f3w, ich publikacja, oczyszczanie i wdro\u017cenie mog\u0105 odbywa\u0107 si\u0119 bezpo\u015brednio z pod\u00f3w Kubernetes.<\/p>\n<p>Aby zrealizowa\u0107 t\u0119 mo\u017cliwo\u015b\u0107, najpierw wymagana jest mo\u017cliwo\u015b\u0107 rozproszonego budowania obraz\u00f3w <i>(patrz punkt powy\u017cej)<\/i>.<\/p>\n<p>Wymagana jest r\u00f3wnie\u017c obs\u0142uga trybu pracy budowniczego bez serwera Docker (tj. budowa podobna do Kaniko lub budowa w userspace).<\/p>\n<p>Werf b\u0119dzie wspiera\u0107 budow\u0119 w Kubernetes nie tylko za pomoc\u0105 Dockerfile, ale tak\u017ce przy u\u017cyciu swojego budowniczego Stapel z inkrementalnymi przebudowami i Ansible.<\/p>\n<h2>Krok w stron\u0119 otwartego rozwoju<\/h2>\n<p>\nKochamy nasz\u0105 spo\u0142eczno\u015b\u0107 (<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>) i chcemy, aby coraz wi\u0119cej os\u00f3b pomaga\u0142o uczyni\u0107 werf lepszym, rozumieli, w jakim kierunku zmierzamy i uczestniczyli w rozwoju.<\/p>\n<p>Niedawno podj\u0119to decyzj\u0119 o przej\u015bciu na <noindex><a rel=\"nofollow\" href=\"https:\/\/help.github.com\/en\/github\/managing-your-work-on-github\/about-project-boards\">GitHub project boards<\/a><\/noindex> aby ujawni\u0107 proces pracy naszej zespo\u0142u. Teraz mo\u017cna zobaczy\u0107 najbli\u017csze plany oraz obecne prace w nast\u0119puj\u0105cych obszarach:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/9\">Dokumentacja i Strona<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/7\">Testowanie<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/6\">B\u0142\u0119dy i Z\u0142a UX<\/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>\nWykonano du\u017c\u0105 prac\u0119 z issue:<\/p>\n<ul>\n<li> Usuni\u0119to nieaktualne.<\/li>\n<li> Istniej\u0105ce przekszta\u0142cono do jednolitego formatu, z odpowiedni\u0105 ilo\u015bci\u0105 szczeg\u00f3\u0142\u00f3w i detali.<\/li>\n<li> Dodano nowe issue z pomys\u0142ami i propozycjami.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Jak w\u0142\u0105czy\u0107 wersj\u0119 v1.1<\/h2>\n<p>\nWersja jest obecnie dost\u0119pna w <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">kanale 1.1 ea<\/a><\/noindex> (na kana\u0142ach <i>stable<\/i> i <i>rock-solid<\/i> wydania pojawi\u0105 si\u0119 w miar\u0119 stabilizacji, jednak <i>ea<\/i> sama w sobie jest ju\u017c wystarczaj\u0105co stabilna do u\u017cycia, poniewa\u017c przesz\u0142a przez kana\u0142y. <i>alpha<\/i> i <i>beta<\/i>). Aktywowane <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\">przez multiwerf<\/a><\/noindex> w nast\u0119puj\u0105cy spos\u00f3b:<\/p>\n<pre><code class=\"bash\">source $(multiwerf use 1.1 ea)\nwerf COMMAND ...<\/code><\/pre>\n<p><\/p>\n<h2>Podsumowanie<\/h2>\n<p>\nNowa architektura magazynu etap\u00f3w i optymalizacja pracy kompilatora dla Stapel i Dockerfile otwieraj\u0105 mo\u017cliwo\u015bci realizacji rozproszonych i r\u00f3wnoleg\u0142ych kompilacji w werf. Te funkcje wkr\u00f3tce pojawi\u0105 si\u0119 w tej samej wersji v1.1 i b\u0119d\u0105 automatycznie dost\u0119pne poprzez mechanizm autoaktualizacji (dla u\u017cytkownik\u00f3w <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>W tej wersji dodano strategi\u0119 tagowania na podstawie zawarto\u015bci obraz\u00f3w \u2014 <i>tagowania opartego na zawarto\u015bci<\/i>, \u2014 kt\u00f3ra sta\u0142a si\u0119 strategi\u0105 domy\u015bln\u0105. Zosta\u0142 r\u00f3wnie\u017c przetworzony log g\u0142\u00f3wnych komend: <code>werf build<\/code>, <code>werf publish<\/code>, <code>werf deploy<\/code>, <code>werf dismiss<\/code>, <code>werf cleanup<\/code>.<\/p>\n<p>Nast\u0119pnym istotnym krokiem b\u0119dzie dodanie rozproszonych kompilacji. Rozproszone kompilacje od czasu v1.0 sta\u0142y si\u0119 bardziej priorytetowym zadaniem ni\u017c kompilacje r\u00f3wnoleg\u0142e, poniewa\u017c dodaj\u0105 wi\u0119cej warto\u015bci do werf: wertykalne skalowanie kompilator\u00f3w oraz wsparcie efemerycznych kompilator\u00f3w w r\u00f3\u017cnych systemach CI\/CD, a tak\u017ce mo\u017cliwo\u015b\u0107 oficjalnego wsparcia GitHub Actions. Dlatego terminy realizacji kompilacji r\u00f3wnoleg\u0142ych zosta\u0142y przesuni\u0119te. Pracujemy jednak nad tym, aby jak najszybciej wdro\u017cy\u0107 obie te mo\u017cliwo\u015bci.<\/p>\n<p>\u015aled\u017a nas na bie\u017c\u0105co! I nie zapomnij odwiedzi\u0107 nas w <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, aby utworzy\u0107 zg\u0142oszenie, znale\u017a\u0107 ju\u017c istniej\u0105ce i doda\u0107 g\u0142os, stworzy\u0107 PR lub po prostu obserwowa\u0107 rozw\u00f3j projektu.<\/p>\n<h2>P.S.<\/h2>\n<p>\nPrzeczytaj tak\u017ce na naszym blogu:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">Prezentujemy werf 1.0 stable: co ma wsp\u00f3lnego z GitOps, status i plany<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/460351\/\">werf \u2014 nasze narz\u0119dzie do CI\/CD w Kubernetes (przegl\u0105d i wideo wyk\u0142adu)<\/a><\/noindex>\u00bb;<\/li>\n<li> Cykl notatek o nowo\u015bciach w werf:\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/476646\/\">Fuzja 3-way w werf: wdro\u017cenie w Kubernetes z Helm \u201ena sterydach\u201d<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468049\/\">U\u017cycie werf do wdra\u017cania z\u0142o\u017conych chart\u00f3w Helm<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465131\/\">Wsparcie dla monorepo i multirepo w werf i jakie ma to znaczenie dla Docker Registry<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/463613\/\">Budowanie obraz\u00f3w Docker w werf jest teraz mo\u017cliwe r\u00f3wnie\u017c za pomoc\u0105 zwyk\u0142ego Dockerfile<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>\u0179r\u00f3d\u0142o: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/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.1.1 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/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.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"pl_PL\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\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\/pl\/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\udd47Wydanie werf 1.1: ulepszenia w kompilatorze dzisiaj i plany na przysz\u0142o\u015b\u0107 | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/pl\/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":"pl_PL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\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\/pl\/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\/pl\/wp-json\/wp\/v2\/posts\/76764","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/comments?post=76764"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/76764\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media\/76765"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=76764"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=76764"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=76764"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}