{"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\/pt\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","title":{"rendered":"Lan\u00e7amento do werf 1.1: melhorias no compilador hoje e planos para o futuro.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Lan\u00e7amento do werf 1.1: melhorias no compilador hoje e planos para o futuro.\" 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 nossa ferramenta CLI GitOps de c\u00f3digo aberto para construir e entregar aplicativos no Kubernetes. Como prometido, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">o lan\u00e7amento da vers\u00e3o v1.0<\/a><\/noindex> marcou o in\u00edcio da adi\u00e7\u00e3o de novas funcionalidades ao werf e a revis\u00e3o de abordagens tradicionais. Agora estamos felizes em apresentar o lan\u00e7amento v1.1, que \u00e9 um grande passo no desenvolvimento e uma base para o futuro <i>do construtor<\/i> werf. A vers\u00e3o j\u00e1 est\u00e1 dispon\u00edvel no <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">canal 1.1 ea<\/a><\/noindex>.<\/p>\n<p>A base do lan\u00e7amento \u00e9 a nova arquitetura de armazenamento de est\u00e1gios e a otimiza\u00e7\u00e3o do funcionamento de ambos os construtores (para Stapel e Dockerfile). A nova arquitetura de armazenamento abre oportunidades para a implementa\u00e7\u00e3o de builds distribu\u00eddos em v\u00e1rios hosts e builds paralelos em um \u00fanico host.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>A otimiza\u00e7\u00e3o inclui a elimina\u00e7\u00e3o de c\u00e1lculos desnecess\u00e1rios na fase de c\u00e1lculo das assinaturas dos est\u00e1gios e a mudan\u00e7a para mecanismos mais eficientes de c\u00e1lculo de somas de verifica\u00e7\u00e3o de arquivos. Essa otimiza\u00e7\u00e3o reduz o tempo m\u00e9dio de builds de projetos com o werf. E as builds nulas, quando todos os est\u00e1gios est\u00e3o em cache <i>stages-storage<\/i>, agora s\u00e3o realmente r\u00e1pidas. Na maioria dos casos, reiniciar uma build levar\u00e1 menos de 1 segundo! Isso tamb\u00e9m se aplica aos procedimentos de verifica\u00e7\u00e3o dos est\u00e1gios durante o trabalho das equipes <code>werf deploy<\/code> e <code>werf run<\/code>.<\/p>\n<p>Al\u00e9m disso, nesta vers\u00e3o, apareceu uma estrat\u00e9gia de etiquetagem de imagens baseada em conte\u00fado \u2014 <i>content-based tagging<\/i>, que agora est\u00e1 habilitada por padr\u00e3o e \u00e9 a \u00fanica recomendada.<\/p>\n<p>Vamos detalhar as principais inova\u00e7\u00f5es no werf v1.1 e aproveitamos para falar sobre os planos para o futuro.<\/p>\n<h2>O que mudou no werf v1.1?<\/h2>\n<p><\/p>\n<h3>Novo formato de nomea\u00e7\u00e3o de est\u00e1gios e algoritmo de sele\u00e7\u00e3o de est\u00e1gios do cache<\/h3>\n<p>\nNova regra de gera\u00e7\u00e3o de nome de est\u00e1gio. Agora, cada build de est\u00e1gio gera um nome de est\u00e1gio \u00fanico, que consiste em 2 partes: assinatura (como era na v1.0) mais um identificador de tempo \u00fanico.<\/p>\n<p>Por exemplo, o nome completo da imagem do est\u00e1gio pode ser assim:<\/p>\n<p><code>werf-stages-storage\/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835<\/code><\/p>\n<p>\u2026 ou de forma geral:<\/p>\n<p><code>werf-stages-storage\/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC<\/code><\/p>\n<p>Aqui:<\/p>\n<ul>\n<li> <code>SIGNATURE<\/code> \u2014 \u00e9 a assinatura do est\u00e1gio, que representa o identificador do conte\u00fado do est\u00e1gio e depende do hist\u00f3rico de altera\u00e7\u00f5es no Git que levaram a esse conte\u00fado;<\/li>\n<li> <code>TIMESTAMP_MILLISEC<\/code> \u2014 \u00e9 um identificador de imagem garantidamente \u00fanico, que \u00e9 gerado no momento da build de uma nova imagem.<\/li>\n<\/ul>\n<p>\nO algoritmo de sele\u00e7\u00e3o de est\u00e1gios do cache \u00e9 baseado na verifica\u00e7\u00e3o de rela\u00e7\u00f5es entre commits do Git:<\/p>\n<ol>\n<li> O Werf calcula a assinatura de um determinado est\u00e1gio.<\/li>\n<li> Em <i>stages-storage<\/i> podem existir v\u00e1rios est\u00e1gios para uma mesma assinatura. O Werf escolhe todos os est\u00e1gios adequados de acordo com a assinatura.<\/li>\n<li> Se o est\u00e1gio atual estiver relacionado ao Git (git-archive, est\u00e1gio personalizado com patches do Git: <code>install<\/code>, <code>beforeSetup<\/code>, <code>setup<\/code>; ou git-latest-patch), o werf escolhe apenas os est\u00e1gios que est\u00e3o relacionados ao commit que \u00e9 ancestral do commit atual (para o qual a constru\u00e7\u00e3o foi chamada).<\/li>\n<li> Dentre os est\u00e1gios restantes adequados, um \u00e9 escolhido \u2014 o mais antigo em data de cria\u00e7\u00e3o.<\/li>\n<\/ol>\n<p>\nUm est\u00e1gio pode ter a mesma assinatura para diferentes branches do Git. Mas o werf impedir\u00e1 o uso do cache relacionado a diferentes branches entre esses branches, mesmo que as assinaturas coincidam.<\/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\u00e7\u00e3o<\/a><\/noindex>.<\/p>\n<h3>Novo algoritmo para criar e salvar est\u00e1gios no reposit\u00f3rio de est\u00e1gios<\/h3>\n<p>\nSe durante a sele\u00e7\u00e3o de est\u00e1gios do cache o werf n\u00e3o encontrar um est\u00e1gio adequado, inicia-se o processo de constru\u00e7\u00e3o de um novo est\u00e1gio.<\/p>\n<p>Observe que v\u00e1rios processos (em um ou v\u00e1rios hosts) podem come\u00e7ar a construir o mesmo est\u00e1gio ao mesmo tempo. O Werf usa um algoritmo de bloqueio otimista <i>stages-storage<\/i> no momento de salvar a imagem rec\u00e9m-constru\u00edda em <i>stages-storage<\/i>. Assim, quando a constru\u00e7\u00e3o de um novo est\u00e1gio estiver pronta, o werf bloqueia <i>stages-storage<\/i> e salva a imagem rec\u00e9m-constru\u00edda l\u00e1 apenas se j\u00e1 n\u00e3o existir uma imagem adequada <i>(de acordo com a assinatura e outros par\u00e2metros \u2014 veja o novo algoritmo de sele\u00e7\u00e3o de est\u00e1gios do cache)<\/i>.<\/p>\n<p>A imagem rec\u00e9m-constru\u00edda ter\u00e1, garantidamente, um identificador \u00fanico de acordo com <code>TIMESTAMP_MILLISEC<\/code> <i>(veja o novo formato de nomea\u00e7\u00e3o de est\u00e1gios)<\/i>. No caso de encontrar uma imagem adequada em <i>stages-storage<\/i> , o werf descartar\u00e1 a imagem rec\u00e9m-constru\u00edda e usar\u00e1 a imagem do cache.<\/p>\n<p>Em outras palavras: o primeiro processo que terminar de construir a imagem (o mais r\u00e1pido) ter\u00e1 o direito de salv\u00e1-la no stages-storage (e, em seguida, apenas essa \u00fanica imagem ser\u00e1 usada para todas as constru\u00e7\u00f5es). O processo de constru\u00e7\u00e3o mais lento nunca bloquear\u00e1 um processo mais r\u00e1pido de salvar os resultados da constru\u00e7\u00e3o do est\u00e1gio atual e passar para a constru\u00e7\u00e3o do pr\u00f3ximo.<\/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\u00e7\u00e3o<\/a><\/noindex>.<\/p>\n<h3>Desempenho do construtor Dockerfile melhorado<\/h3>\n<p>\nAtualmente, o pipeline de est\u00e1gios para a imagem sendo constru\u00edda a partir do Dockerfile consiste em um \u00fanico est\u00e1gio \u2014 <code>dockerfile<\/code>. Ao calcular a assinatura, a soma de verifica\u00e7\u00e3o dos arquivos \u00e9 considerada. <code>contexto<\/code>, que ser\u00e3o utilizados durante a constru\u00e7\u00e3o. At\u00e9 essa atualiza\u00e7\u00e3o, werf percorria recursivamente todos os arquivos e obtinha um hash de verifica\u00e7\u00e3o, somando o contexto e o modo de cada arquivo. A partir das vers\u00f5es v1.1, werf pode usar os hashes de verifica\u00e7\u00e3o calculados armazenados no reposit\u00f3rio Git.<\/p>\n<p>A base do algoritmo \u00e9 <noindex><a rel=\"nofollow\" href=\"https:\/\/git-scm.com\/docs\/git-ls-tree\">git ls-tree<\/a><\/noindex>. O algoritmo considera registros em <code>.dockerignore<\/code> e percorre recursivamente a \u00e1rvore de arquivos apenas quando necess\u00e1rio. Assim, nos desvinculamos da leitura do sistema de arquivos, e a depend\u00eancia do algoritmo em rela\u00e7\u00e3o ao tamanho <code>contexto<\/code> n\u00e3o \u00e9 significativa.<\/p>\n<p>O algoritmo tamb\u00e9m verifica arquivos n\u00e3o rastreados e, quando necess\u00e1rio, os considera no hash de verifica\u00e7\u00e3o.<\/p>\n<h3>O desempenho ao importar arquivos foi melhorado<\/h3>\n<p>\nNas vers\u00f5es do werf v1.1, um servidor rsync \u00e9 utilizado ao <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/configuration\/stapel_image\/import_directive.html\">importar arquivos de artefatos e imagens<\/a><\/noindex>. Anteriormente, a importa\u00e7\u00e3o era realizada em duas etapas usando a montagem de diret\u00f3rios do sistema host.<\/p>\n<p>O desempenho das importa\u00e7\u00f5es no macOS n\u00e3o \u00e9 mais limitado aos volumes do Docker, e as importa\u00e7\u00f5es ocorrem no mesmo tempo que no Linux e Windows.<\/p>\n<h3>Tagueamento baseado em conte\u00fado<\/h3>\n<p>\nO werf v1.1 suporta o que \u00e9 chamado de tagueamento baseado no conte\u00fado da imagem \u2014 <i>content-based tagging<\/i>. As tags das imagens Docker resultantes dependem do conte\u00fado dessas imagens.<\/p>\n<p>Ao executar o comando <code>werf publish --tags-by-stages-signature<\/code> ou <code>werf ci-env --tagging-strategy=stages-signature<\/code> as imagens publicadas ser\u00e3o marcadas com a chamada <b>assinatura de est\u00e1gios<\/b> da imagem. Cada imagem \u00e9 marcada com sua pr\u00f3pria assinatura de est\u00e1gio, que \u00e9 calculada de acordo com as mesmas regras que a assinatura regular de cada est\u00e1gio individualmente, mas \u00e9 um identificador geral da imagem.<\/p>\n<p>A assinatura dos est\u00e1gios da imagem depende de:<\/p>\n<ol>\n<li> do conte\u00fado dessa imagem;<\/li>\n<li> do hist\u00f3rico de altera\u00e7\u00f5es no Git que levaram a esse conte\u00fado.<\/li>\n<\/ol>\n<p>\nNo reposit\u00f3rio Git, sempre existem commits vazios que n\u00e3o alteram o conte\u00fado dos arquivos da imagem. Por exemplo, commits apenas com coment\u00e1rios, ou commits de merge, ou commits que alteram aqueles arquivos no Git que n\u00e3o ser\u00e3o importados para a imagem.<\/p>\n<p>Ao usar a marca\u00e7\u00e3o baseada em conte\u00fado, resolvem-se os problemas de reinicializa\u00e7\u00f5es desnecess\u00e1rias dos pods de aplicativos no Kubernetes devido a altera\u00e7\u00f5es no nome da imagem, mesmo que o conte\u00fado da imagem n\u00e3o tenha mudado. Ali\u00e1s, essa \u00e9 uma das raz\u00f5es que dificultam o armazenamento de v\u00e1rios microsservi\u00e7os de um \u00fanico aplicativo em um \u00fanico reposit\u00f3rio Git.<\/p>\n<p>Al\u00e9m disso, a marca\u00e7\u00e3o baseada em conte\u00fado \u00e9 um m\u00e9todo de etiquetagem mais confi\u00e1vel do que a etiquetagem por branches do Git, pois o conte\u00fado das imagens resultantes n\u00e3o depende da ordem de execu\u00e7\u00e3o das pipelines no sistema CI para construir v\u00e1rios commits da mesma branch.<\/p>\n<p><b>Importante<\/b>: a partir deste momento <i>assinatura-dos-est\u00e1gios<\/i> seja <b>a \u00fanica estrat\u00e9gia de tagueamento recomendada<\/b>. Esta ser\u00e1 a utilizada por padr\u00e3o na equipe <code>werf ci-env<\/code> (a menos que uma outra estrat\u00e9gia de tagueamento seja explicitamente especificada).<\/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\u00e7\u00e3o<\/a><\/noindex>. Esta funcionalidade tamb\u00e9m ser\u00e1 dedicada a uma publica\u00e7\u00e3o separada. <b>ATUALIZADO<\/b> (3 de abril): artigo com detalhes <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/495112\/\">foi publicado<\/a><\/noindex>.<\/p>\n<h3>N\u00edveis de logging<\/h3>\n<p>\nO usu\u00e1rio agora tem a capacidade de controlar a sa\u00edda, definir o n\u00edvel de logging e trabalhar com informa\u00e7\u00f5es de depura\u00e7\u00e3o. As op\u00e7\u00f5es foram adicionadas <code>--log-quiet<\/code>, <code>--log-verbose<\/code>, <code>--log-debug<\/code>.<\/p>\n<p>Por padr\u00e3o, a sa\u00edda cont\u00e9m o m\u00ednimo de informa\u00e7\u00f5es:<\/p>\n<p><img decoding=\"async\" alt=\"Lan\u00e7amento do werf 1.1: melhorias no compilador hoje e planos para o futuro.\" src=\"\/wp-content\/uploads\/2020\/04\/58e981b2e0c579ddde817eadc1732874.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAo utilizar a sa\u00edda detalhada (<code>--log-verbose<\/code>) \u00e9 poss\u00edvel acompanhar como o werf funciona:<\/p>\n<p><img decoding=\"async\" alt=\"Lan\u00e7amento do werf 1.1: melhorias no compilador hoje e planos para o futuro.\" src=\"\/wp-content\/uploads\/2020\/04\/487ed5dfc5df0178f7c09f8da697ceff.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA sa\u00edda detalhada (<code>--log-debug<\/code>), al\u00e9m das informa\u00e7\u00f5es de depura\u00e7\u00e3o do werf, tamb\u00e9m cont\u00e9m logs das bibliotecas utilizadas. Por exemplo, \u00e9 poss\u00edvel ver como a intera\u00e7\u00e3o com o Docker Registry ocorre, al\u00e9m de registrar pontos onde um tempo consider\u00e1vel \u00e9 gasto:<\/p>\n<p><img decoding=\"async\" alt=\"Lan\u00e7amento do werf 1.1: melhorias no compilador hoje e planos para o futuro.\" src=\"\/wp-content\/uploads\/2020\/04\/99c1f3c2ab3803ff11fae1f2d5c9a5af.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Planos Futuros<\/h2>\n<p>\n<b>Aten\u00e7\u00e3o!<\/b> As funcionalidades descritas a seguir com a marca\u00e7\u00e3o <b>v1.1<\/b> estar\u00e3o dispon\u00edveis nesta vers\u00e3o, muitas delas em breve. As atualiza\u00e7\u00f5es vir\u00e3o atrav\u00e9s de atualiza\u00e7\u00f5es autom\u00e1ticas <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\">ao usar multiwerf<\/a><\/noindex>. Essas funcionalidades n\u00e3o afetam a parte est\u00e1vel das fun\u00e7\u00f5es v1.1, sua introdu\u00e7\u00e3o n\u00e3o exigir\u00e1 interven\u00e7\u00e3o manual do usu\u00e1rio nas configura\u00e7\u00f5es existentes.<\/p>\n<h3>Suporte total a v\u00e1rias implementa\u00e7\u00f5es do Docker Registry (NOVO)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Vers\u00e3o: v1.1<\/i><\/li>\n<li> <i>Prazo: mar\u00e7o<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2199\">Problema<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nO objetivo \u00e9 que o usu\u00e1rio utilize qualquer implementa\u00e7\u00e3o sem restri\u00e7\u00f5es ao usar o werf. <\/p>\n<p>Atualmente, destacamos o seguinte conjunto de solu\u00e7\u00f5es para as quais garantimos suporte total:<\/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>\nAs solu\u00e7\u00f5es marcadas com um asterisco s\u00e3o aquelas atualmente totalmente suportadas pelo werf. Para as demais, h\u00e1 suporte, mas com limita\u00e7\u00f5es.<\/p>\n<p>Podemos destacar dois problemas principais:<\/p>\n<ul>\n<li> Algumas solu\u00e7\u00f5es n\u00e3o suportam a remo\u00e7\u00e3o de tags atrav\u00e9s da API do Docker Registry, o que impede os usu\u00e1rios de utilizar a limpeza autom\u00e1tica implementada no werf. Isso \u00e9 verdade para AWS ECR, Docker Hub e GitHub Packages.<\/li>\n<li> Parte das solu\u00e7\u00f5es n\u00e3o suportam, os chamados reposit\u00f3rios aninhados (Docker Hub, GitHub Packages e Quay) ou suportam, mas o usu\u00e1rio deve cri\u00e1-los manualmente, usando a interface ou a API (AWS ECR).<\/li>\n<\/ul>\n<p>\nEstamos planejando resolver esses e outros problemas utilizando APIs nativas das solu\u00e7\u00f5es. Esta tarefa tamb\u00e9m inclui a cobertura de testes do ciclo completo de funcionamento do werf para cada uma delas.<\/p>\n<h3>Compila\u00e7\u00e3o distribu\u00edda de imagens (\u2191)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Vers\u00e3o: v1.2 v1.1 (a prioridade para a implementa\u00e7\u00e3o dessa funcionalidade foi aumentada)<\/i><\/li>\n<li> <i>Prazos: mar\u00e7o-abril mar\u00e7o<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/1614\">Problema<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nAtualmente, o werf v1.0 e v1.1 s\u00f3 podem ser usados em um \u00fanico host dedicado para opera\u00e7\u00f5es de compila\u00e7\u00e3o e publica\u00e7\u00e3o de imagens e implanta\u00e7\u00e3o de aplica\u00e7\u00f5es no Kubernetes.<\/p>\n<p>Para abrir as possibilidades de trabalho distribu\u00eddo do werf, quando a compila\u00e7\u00e3o e implanta\u00e7\u00e3o de aplica\u00e7\u00f5es no Kubernetes s\u00e3o iniciadas em v\u00e1rios hosts arbitr\u00e1rios e esses hosts n\u00e3o mant\u00eam seu estado entre as compila\u00e7\u00f5es (runners tempor\u00e1rios), o werf precisa implementar a capacidade de usar o Docker Registry como reposit\u00f3rio de est\u00e1gios.<\/p>\n<p>Anteriormente, quando o projeto werf ainda se chamava dapp, havia essa possibilidade. No entanto, enfrentamos uma s\u00e9rie de problemas que precisam ser considerados na implementa\u00e7\u00e3o dessa fun\u00e7\u00e3o no werf.<\/p>\n<p><b>Nota<\/b>. Essa funcionalidade n\u00e3o sup\u00f5e a opera\u00e7\u00e3o do compilador dentro dos pods do Kubernetes, pois para isso \u00e9 necess\u00e1rio eliminar a depend\u00eancia do servidor Docker local (nos pods do Kubernetes n\u00e3o h\u00e1 acesso ao servidor Docker local, uma vez que o pr\u00f3prio processo \u00e9 executado em um cont\u00eainer, e a intera\u00e7\u00e3o com o servidor Docker pela rede n\u00e3o \u00e9 suportada pelo werf e n\u00e3o ser\u00e1 suportada). O suporte para opera\u00e7\u00e3o no Kubernetes ser\u00e1 implementado separadamente.<\/p>\n<h3>Suporte oficial ao GitHub Actions (NOVO)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Vers\u00e3o: v1.1<\/i><\/li>\n<li> <i>Prazo: mar\u00e7o<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2210\">Problema<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nInclui a documenta\u00e7\u00e3o do werf (se\u00e7\u00f5es <i>refer\u00eancia<\/i> e <i>guia<\/i>), bem como a a\u00e7\u00e3o oficial do GitHub para trabalhar com o werf.<\/p>\n<p>Al\u00e9m disso, permitir\u00e1 que o werf funcione em runners ef\u00eameros.<\/p>\n<p>A mec\u00e2nica de intera\u00e7\u00e3o do usu\u00e1rio com o sistema CI ser\u00e1 baseada na aplica\u00e7\u00e3o de etiquetas aos pull requests para iniciar determinadas a\u00e7\u00f5es de constru\u00e7\u00e3o\/implementa\u00e7\u00e3o do aplicativo.<\/p>\n<h3>Desenvolvimento local e implanta\u00e7\u00e3o de aplica\u00e7\u00f5es com werf (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Vers\u00e3o: v1.1<\/i><\/li>\n<li> <i>Prazos: janeiro-fevereiro abril<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/1940\">Problema<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nO principal objetivo \u00e9 alcan\u00e7ar uma configura\u00e7\u00e3o unificada para a implanta\u00e7\u00e3o de aplica\u00e7\u00f5es tanto localmente quanto em produ\u00e7\u00e3o, sem a\u00e7\u00f5es complexas, \"pronto para uso\".<\/p>\n<p>A werf tamb\u00e9m requer um modo de opera\u00e7\u00e3o que permita editar o c\u00f3digo do aplicativo e receber feedback imediato do aplicativo em execu\u00e7\u00e3o para depura\u00e7\u00e3o.<\/p>\n<h3>Novo algoritmo de limpeza (NOVO)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Vers\u00e3o: v1.1<\/i><\/li>\n<li> <i>Prazos: abril<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2212\">Problema<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nNa vers\u00e3o atual do werf v1.1, o procedimento <code>cleanup<\/code> n\u00e3o contempla a limpeza de imagens para o esquema de tagueamento baseado em conte\u00fado \u2014 essas imagens ser\u00e3o acumuladas.<\/p>\n<p>Al\u00e9m disso, na vers\u00e3o atual do werf (v1.0 e v1.1), s\u00e3o utilizadas pol\u00edticas de limpeza diferentes para imagens publicadas de acordo com esquemas de tagueamento: branch do Git, tag do Git ou commit do Git.<\/p>\n<p>Um novo algoritmo de limpeza unificado para todos os esquemas de tagueamento foi concebido com base no hist\u00f3rico de commits no Git:<\/p>\n<ul>\n<li> Manter n\u00e3o mais do que N1 imagens, relacionadas aos N2 \u00faltimos commits para cada HEAD do git (branches e tags).<\/li>\n<li> Manter n\u00e3o mais do que N1 imagens de est\u00e1gios, relacionadas aos N2 \u00faltimos commits para cada HEAD do git (branches e tags).<\/li>\n<li> Armazenar todas as imagens que s\u00e3o utilizadas em quaisquer recursos do cluster Kubernetes (todas as configura\u00e7\u00f5es kube-context e namespaces s\u00e3o verificadas; esse comportamento pode ser restringido com op\u00e7\u00f5es espec\u00edficas).<\/li>\n<li> Manter todas as imagens que s\u00e3o utilizadas em manifests de configura\u00e7\u00e3o de recursos, salvos em releases do Helm.<\/li>\n<li> Uma imagem pode ser removida se n\u00e3o estiver associada a nenhum HEAD do git (por exemplo, porque o HEAD correspondente foi exclu\u00eddo) e n\u00e3o estiver em uso em nenhum dos manifests no cluster Kubernetes e nas releases do Helm.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Constru\u00e7\u00e3o paralela de imagens (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Vers\u00e3o: v1.1<\/i><\/li>\n<li> <i>Prazos: janeiro-fevereiro abril*<\/i><\/li>\n<\/ul>\n<p>\nA vers\u00e3o atual do werf constr\u00f3i imagens e artefatos descritos em <code>werf.yaml<\/code>, sequencialmente. \u00c9 necess\u00e1rio paralelizar o processo de constru\u00e7\u00e3o de est\u00e1gios independentes de imagens e artefatos, al\u00e9m de garantir uma sa\u00edda conveniente e informativa.<\/p>\n<p><i>* Observa\u00e7\u00e3o: o prazo foi adiado devido \u00e0 prioriza\u00e7\u00e3o da implementa\u00e7\u00e3o de uma constru\u00e7\u00e3o distribu\u00edda, que adicionar\u00e1 mais capacidades de escalabilidade horizontal, al\u00e9m do uso do werf com o GitHub Actions. A constru\u00e7\u00e3o paralela \u00e9 o pr\u00f3ximo passo de otimiza\u00e7\u00e3o, proporcionando escalabilidade vertical na constru\u00e7\u00e3o de um \u00fanico projeto.<\/i><\/p>\n<h3>Transi\u00e7\u00e3o para o Helm 3 (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Vers\u00e3o: v1.2<\/i><\/li>\n<li> <i>Prazos: fevereiro-mar\u00e7o maio*<\/i><\/li>\n<\/ul>\n<p>\nInclui a transi\u00e7\u00e3o para uma nova base de c\u00f3digo <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/news\/t\/475722\/\">Helm 3<\/a><\/noindex> e um m\u00e9todo comprovado e conveniente para migra\u00e7\u00e3o de instala\u00e7\u00f5es existentes.<\/p>\n<p><i>* Nota: a transi\u00e7\u00e3o para o Helm 3 n\u00e3o adicionar\u00e1 capacidades significativas ao werf, pois todos os recursos principais do Helm 3 (3-way-merge e aus\u00eancia de tiller) j\u00e1 est\u00e3o implementados no werf. Al\u00e9m disso, o werf possui <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/differences_with_helm.html\">capacidades adicionais<\/a><\/noindex> al\u00e9m das mencionadas. No entanto, essa transi\u00e7\u00e3o permanece em nossos planos e ser\u00e1 executada.<\/i><\/p>\n<h3>Jsonnet para descrever a configura\u00e7\u00e3o do Kubernetes (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Vers\u00e3o: v1.2<\/i><\/li>\n<li> <i>Prazos: janeiro-fevereiro abril-maio<\/i><\/li>\n<\/ul>\n<p>\nO werf suportar\u00e1 a descri\u00e7\u00e3o da configura\u00e7\u00e3o para Kubernetes no formato Jsonnet. Neste caso, o werf permanecer\u00e1 compat\u00edvel com o Helm e haver\u00e1 a possibilidade de escolher o formato de descri\u00e7\u00e3o.<\/p>\n<p>A raz\u00e3o \u00e9 que os templates da linguagem Go, segundo a avalia\u00e7\u00e3o de muitas pessoas, t\u00eam uma alta barreira de entrada, e a clareza do c\u00f3digo desses templates tamb\u00e9m \u00e9 comprometida.<\/p>\n<p>Tamb\u00e9m est\u00e1 sendo considerada a implementa\u00e7\u00e3o de outros sistemas de descri\u00e7\u00e3o de configura\u00e7\u00e3o do Kubernetes (por exemplo, Kustomize).<\/p>\n<h3>Trabalho dentro do Kubernetes (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Vers\u00e3o: v1.2<\/i><\/li>\n<li> <i>Prazos: abril-maio maio-junho<\/i><\/li>\n<\/ul>\n<p>\nObjetivo: garantir a constru\u00e7\u00e3o de imagens e a entrega de aplicativos usando runners no Kubernetes. Ou seja, a constru\u00e7\u00e3o de novas imagens, sua publica\u00e7\u00e3o, limpeza e deploy pode ocorrer diretamente de pods do Kubernetes.<\/p>\n<p>Para implementar essa possibilidade, primeiro \u00e9 necess\u00e1ria a capacidade de constru\u00e7\u00e3o distribu\u00edda de imagens <i>(veja o item acima)<\/i>.<\/p>\n<p>Al\u00e9m disso, \u00e9 necess\u00e1rio suporte ao modo de funcionamento do construtor sem servidor Docker (ou seja, constru\u00e7\u00e3o semelhante ao Kaniko ou constru\u00e7\u00e3o em userspace).<\/p>\n<p>O werf suportar\u00e1 a constru\u00e7\u00e3o no Kubernetes n\u00e3o apenas com Dockerfile, mas tamb\u00e9m com seu construtor Stapel com reconstru\u00e7\u00f5es incrementais e Ansible.<\/p>\n<h2>Passo em dire\u00e7\u00e3o ao desenvolvimento aberto<\/h2>\n<p>\nAmamos nossa comunidade (<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>) e queremos que cada vez mais pessoas ajudem a tornar o werf melhor, entendam para onde estamos indo e participem do desenvolvimento.<\/p>\n<p>Recentemente, foi decidido adotar <noindex><a rel=\"nofollow\" href=\"https:\/\/help.github.com\/en\/github\/managing-your-work-on-github\/about-project-boards\">quadros de projetos do GitHub<\/a><\/noindex> para abrir um pouco o fluxo de trabalho da nossa equipe. Agora \u00e9 poss\u00edvel ver os planos mais pr\u00f3ximos, bem como o trabalho atual nas seguintes \u00e1reas:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/9\">Documenta\u00e7\u00e3o e Site<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/7\">Testes<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/6\">Bugs e Mau 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>\nFoi feito um grande trabalho com issues:<\/p>\n<ul>\n<li> Removidos os que n\u00e3o eram mais relevantes.<\/li>\n<li> Os existentes foram padronizados, com detalhes e informa\u00e7\u00f5es suficientes.<\/li>\n<li> Adicionadas novas issues com ideias e sugest\u00f5es.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Como habilitar a vers\u00e3o v1.1<\/h2>\n<p>\nA vers\u00e3o est\u00e1 dispon\u00edvel no momento em <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">canal 1.1 ea<\/a><\/noindex> (nos canais <i>stable<\/i> e <i>rock-solid<\/i> as vers\u00f5es aparecer\u00e3o \u00e0 medida que se estabilizarem, no entanto, <i>ea<\/i> j\u00e1 \u00e9 bastante est\u00e1vel para uso, pois passou pelos canais <i>alpha<\/i> e <i>beta<\/i>). Ativada <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\">atrav\u00e9s do multiwerf<\/a><\/noindex> da seguinte maneira:<\/p>\n<pre><code class=\"bash\">source $(multiwerf use 1.1 ea)\nwerf COMMAND ...<\/code><\/pre>\n<p><\/p>\n<h2>Conclus\u00e3o<\/h2>\n<p>\nA nova arquitetura de armazenamento de est\u00e1gios e a otimiza\u00e7\u00e3o do funcionamento do construtor para os construtores Stapel e Dockerfile abrem possibilidades para implementar compila\u00e7\u00f5es distribu\u00eddas e em paralelo no werf. Essas capacidades estar\u00e3o dispon\u00edveis em breve na mesma vers\u00e3o v1.1 e ser\u00e3o automaticamente acess\u00edveis atrav\u00e9s do mecanismo de autoatualiza\u00e7\u00f5es (para os usu\u00e1rios <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>Nesta vers\u00e3o, foi adicionada uma estrat\u00e9gia de tagueamento com base no conte\u00fado das imagens \u2014 <i>content-based tagging<\/i>, \u2014 que se tornou a estrat\u00e9gia padr\u00e3o. Al\u00e9m disso, o log de comandos principais foi reestruturado: <code>werf build<\/code>, <code>werf publish<\/code>, <code>werf deploy<\/code>, <code>werf dismiss<\/code>, <code>werf cleanup<\/code>.<\/p>\n<p>O pr\u00f3ximo passo significativo ser\u00e1 a adi\u00e7\u00e3o de compila\u00e7\u00f5es distribu\u00eddas. Compila\u00e7\u00f5es distribu\u00eddas desde a vers\u00e3o v1.0 tornaram-se uma tarefa mais priorit\u00e1ria do que compila\u00e7\u00f5es em paralelo, pois agregam mais valor ao werf: escalabilidade vertical dos construtores e suporte a construtores ef\u00eameros em diferentes sistemas CI\/CD, al\u00e9m da possibilidade de proporcionar suporte oficial ao GitHub Actions. Portanto, os prazos para a implementa\u00e7\u00e3o de compila\u00e7\u00f5es em paralelo foram adiados. No entanto, estamos trabalhando para implementar ambas as possibilidades o mais r\u00e1pido poss\u00edvel.<\/p>\n<p>Fique ligado nas novidades! E n\u00e3o se esque\u00e7a de nos visitar em <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, para criar uma issue, encontrar uma j\u00e1 existente e dar um like, criar um PR ou apenas observar o desenvolvimento do projeto.<\/p>\n<h2>P.S.<\/h2>\n<p>\nConfira tamb\u00e9m em nosso blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">Apresentamos o werf 1.0 est\u00e1vel: qual \u00e9 o papel do GitOps, status e planos<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/460351\/\">werf \u2014 nossa ferramenta para CI\/CD no Kubernetes (vis\u00e3o geral e v\u00eddeo da apresenta\u00e7\u00e3o)<\/a><\/noindex>\u00bb;<\/li>\n<li> Ciclo de notas sobre novidades no werf:\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/476646\/\">Mesclagem em 3 vias no werf: deployment no Kubernetes com Helm \"potencializado\".<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468049\/\">Uso do werf para implanta\u00e7\u00f5es de charts Helm complexos<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465131\/\">Suporte a monorepo e multirepo no werf e qual a rela\u00e7\u00e3o com o Docker Registry.<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/463613\/\">Agora \u00e9 poss\u00edvel construir imagens Docker no werf tamb\u00e9m usando um Dockerfile comum<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Fonte: <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.3 - 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\/pt\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\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\/pt\/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\udd47Lan\u00e7amento do werf 1.1: melhorias no construtor hoje e planos para o futuro | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/pt\/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":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/76764","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=76764"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/76764\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/76765"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=76764"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=76764"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=76764"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}