{"id":33654,"date":"2019-10-31T21:53:58","date_gmt":"2019-10-31T18:53:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/deploj-prilozhenij-v-vm-nomad-i-kubernetes\/"},"modified":"2019-10-31T21:53:58","modified_gmt":"2019-10-31T18:53:58","slug":"deploj-prilozhenij-v-vm-nomad-i-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/deploj-prilozhenij-v-vm-nomad-i-kubernetes","title":{"rendered":"Implanta\u00e7\u00e3o de aplicativos em VM, Nomad e Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ol\u00e1 a todos! Meu nome \u00e9 Pavel Agaletsky. Sou l\u00edder de equipe na equipe que desenvolve o sistema de entrega da Lamoda. Em 2018, eu falei na confer\u00eancia HighLoad++, e hoje quero apresentar a transcri\u00e7\u00e3o da minha palestra.<\/p>\n

Meu tema se concentra na experi\u00eancia da nossa empresa em implantar sistemas e servi\u00e7os em diferentes ambientes. Desde nossos tempos pr\u00e9-hist\u00f3ricos, quando implant\u00e1vamos todos os sistemas em servidores virtuais comuns, at\u00e9 a transi\u00e7\u00e3o gradual do Nomad para a implanta\u00e7\u00e3o no Kubernetes. Vou explicar por que fizemos isso e quais foram os problemas que encontramos no processo.<\/p>\n

\r\n \"Por\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex><\/p>\n

Implanta\u00e7\u00e3o de aplicativos em VM<\/h1>\n

\nCome\u00e7amos h\u00e1 3 anos, quando todos os sistemas e servi\u00e7os da empresa eram implantados em servidores virtuais comuns. A parte t\u00e9cnica foi organizada de forma que todo o c\u00f3digo dos nossos sistemas era armazenado e compilado por meio de um sistema de build autom\u00e1tico usando o Jenkins. Com o Ansible, ele era distribu\u00eddo a partir do nosso sistema de controle de vers\u00f5es para os servidores virtuais. Cada sistema que existia na nossa empresa era implantado em pelo menos 2 servidores: um deles era o head, o outro era o tail. Esses dois sistemas eram absolutamente id\u00eanticos em todas as suas configura\u00e7\u00f5es, pot\u00eancia, configura\u00e7\u00e3o e assim por diante. A \u00fanica diferen\u00e7a entre eles era que o head recebia o tr\u00e1fego de usu\u00e1rios, enquanto o tail nunca recebia tr\u00e1fego de usu\u00e1rios. <\/p>\n

Por que isso foi feito? <\/p>\n

Quando implant\u00e1vamos novas vers\u00f5es do nosso aplicativo, quer\u00edamos garantir a possibilidade de uma implanta\u00e7\u00e3o sem costuras, ou seja, sem consequ\u00eancias vis\u00edveis para os usu\u00e1rios. Isso era alcan\u00e7ado ao implementar a nova vers\u00e3o compilada usando o Ansible no tail. L\u00e1, as pessoas encarregadas da implanta\u00e7\u00e3o podiam verificar e garantir que tudo estava em ordem: todas as m\u00e9tricas, se\u00e7\u00f5es e aplicativos funcionavam; os scripts necess\u00e1rios eram executados. Somente depois de assegurar que estava tudo bem, o tr\u00e1fego era redirecionado. Ele come\u00e7ava a fluir para o servidor que antes era o tail. E aquele que antes era o head permanecia sem tr\u00e1fego de usu\u00e1rios, mantendo a vers\u00e3o anterior do nosso aplicativo.<\/p>\n

Assim, para os usu\u00e1rios, foi tudo muito fluido. Pois a altern\u00e2ncia \u00e9 instant\u00e2nea, j\u00e1 que \u00e9 apenas uma mudan\u00e7a do balanceador. \u00c9 muito f\u00e1cil reverter para uma vers\u00e3o anterior, apenas alterando o balanceador de volta. Tamb\u00e9m pudemos garantir a capacidade do aplicativo em produ\u00e7\u00e3o antes que o tr\u00e1fego de usu\u00e1rios come\u00e7asse a fluir, o que foi bastante conveniente. <\/p>\n

Quais foram os benef\u00edcios que vimos em tudo isso?<\/p>\n

    \n
  1. Acima de tudo, \u00e9 bastante simples de funcionar.<\/b> Est\u00e1 claro para todos como funciona esse tipo de esquema de deploy, pois a maioria das pessoas j\u00e1 fez deploy em servidores virtuais comuns.<\/li>\n
  2. \u00c9 bastante confi\u00e1vel<\/b>, pois a tecnologia de deploy \u00e9 simples, testada por milhares de empresas. Milh\u00f5es de servidores s\u00e3o implantados exatamente assim. \u00c9 dif\u00edcil quebrar algo. <\/li>\n
  3. E por fim, conseguimos realizar deploys at\u00f4micos<\/b>. Deploys que ocorrem para os usu\u00e1rios de forma instant\u00e2nea, sem uma fase percept\u00edvel de transi\u00e7\u00e3o entre a vers\u00e3o antiga e a nova. <\/li>\n<\/ol>\n

    \nMas em tudo isso tamb\u00e9m vimos algumas desvantagens: <\/p>\n

      \n
    1. Al\u00e9m do ambiente de produ\u00e7\u00e3o e do ambiente de desenvolvimento, existem outros ambientes. Por exemplo, qa e pr\u00e9-produ\u00e7\u00e3o. Naquele momento, t\u00ednhamos muitos servidores e cerca de 60 servi\u00e7os. Por essa raz\u00e3o, era necess\u00e1rio manter a vers\u00e3o atualizada <\/b>da m\u00e1quina virtual para cada servi\u00e7o. E se voc\u00ea quiser atualizar as bibliotecas ou adicionar novas depend\u00eancias, deve faz\u00ea-lo em todos os ambientes. Tamb\u00e9m era necess\u00e1rio sincronizar o tempo em que voc\u00ea planejava implantar a nova vers\u00e3o do seu aplicativo com o tempo em que o devops faria as configura\u00e7\u00f5es necess\u00e1rias do ambiente. Nessa situa\u00e7\u00e3o \u00e9 f\u00e1cil chegar a um ponto em que o ambiente se diferencie um pouco em todos os ambientes consecutivos. Por exemplo, no ambiente QA haveria vers\u00f5es de bibliotecas diferentes, e na produ\u00e7\u00e3o \u2014 outras, o que levaria a problemas. <\/li>\n
    2. A complexidade na atualiza\u00e7\u00e3o das depend\u00eancias<\/b> do seu aplicativo. Isso n\u00e3o depende de voc\u00ea, mas de outra equipe. Ou seja, da equipe devops que mant\u00e9m os servidores. Voc\u00ea deve definir a tarefa correspondente para eles e fornecer uma descri\u00e7\u00e3o do que deseja fazer.<\/li>\n
    3. Naquela \u00e9poca, tamb\u00e9m quer\u00edamos dividir os grandes monolitos que t\u00ednhamos em pequenos servi\u00e7os, pois entend\u00edamos que a quantidade deles s\u00f3 aumentaria. Naquele momento, j\u00e1 t\u00ednhamos mais de 100. Era necess\u00e1rio criar uma nova m\u00e1quina virtual para cada novo servi\u00e7o, que tamb\u00e9m precisava ser mantida e implantada. Al\u00e9m disso, n\u00e3o era uma \u00fanica m\u00e1quina, mas pelo menos duas. A isso se somava ainda o ambiente de QA. Isso causa problemas e torna a cria\u00e7\u00e3o e o lan\u00e7amento de novos sistemas mais complicados, caros e demorados.<\/b><\/li>\n<\/ol>\n

      \nPor isso, decidimos que seria mais conveniente passar do deployment de m\u00e1quinas virtuais comuns para o deployment de nossas aplica\u00e7\u00f5es em cont\u00eaineres Docker. Com o Docker, \u00e9 necess\u00e1rio um sistema que possa iniciar a aplica\u00e7\u00e3o no cluster, pois voc\u00ea n\u00e3o consegue simplesmente levantar um cont\u00eainer. Normalmente, \u00e9 desej\u00e1vel monitorar quantos cont\u00eaineres est\u00e3o em execu\u00e7\u00e3o, para que eles sejam iniciados automaticamente. Por essa raz\u00e3o, precis\u00e1vamos escolher um sistema de gerenciamento. <\/p>\n

      Refletimos bastante sobre qual deles escolher. O fato \u00e9 que, naquela \u00e9poca, nossa pilha de deployment em servidores virtuais comuns estava um pouco desatualizada, pois as vers\u00f5es dos sistemas operacionais eram antigas. Em algum momento, havia at\u00e9 o FreeBSD, que n\u00e3o era muito conveniente de manter. Entend\u00edamos que precis\u00e1vamos migrar para o Docker o mais r\u00e1pido poss\u00edvel. Nossos DevOps analisaram sua experi\u00eancia pr\u00e9via com diferentes solu\u00e7\u00f5es e escolheram um sistema chamado Nomad. <\/p>\n

      Transi\u00e7\u00e3o para o Nomad<\/h1>\n

      \nO Nomad \u00e9 um produto da empresa HashiCorp. Eles tamb\u00e9m s\u00e3o conhecidos por outras solu\u00e7\u00f5es:<\/p>\n

      \"Implanta\u00e7\u00e3o
      \n
      \n\u00abConsul\u00bb<\/b> \u2014 \u00e9 uma ferramenta para descoberta de servi\u00e7os.<\/p>\n

      \u00abTerraform\u00bb<\/b> \u2014 \u00e9 um sistema para gerenciamento de servidores, permitindo que voc\u00ea os configure atrav\u00e9s de uma configura\u00e7\u00e3o conhecida como infrastructure-as-a-code.<\/p>\n

      \u00abVagrant\u00bb<\/b> permite que voc\u00ea implante m\u00e1quinas virtuais localmente ou na nuvem usando arquivos de configura\u00e7\u00e3o espec\u00edficos. <\/p>\n

      Naquele momento, o Nomad parecia uma solu\u00e7\u00e3o simples, que poderia ser adotada rapidamente sem alterar toda a infraestrutura. Al\u00e9m disso, \u00e9 f\u00e1cil de aprender. Por isso, escolhemos exatamente ele como nosso sistema de orquestra\u00e7\u00e3o de cont\u00eaineres. <\/p>\n

      O que voc\u00ea precisa para implantar seu sistema no Nomad? <\/p>\n

        \n
      1. Antes de mais nada, voc\u00ea precisa de um imagem docker<\/b> do seu aplicativo. \u00c9 necess\u00e1rio empacot\u00e1-lo e coloc\u00e1-lo em um reposit\u00f3rio de imagens docker. No nosso caso, esse reposit\u00f3rio \u00e9 o artifactory \u2014 um sistema que permite fazer push de diversos artefatos de diferentes tipos. Ele pode armazenar arquivos, imagens docker, pacotes Composer PHP, pacotes NPM e muito mais. <\/li>\n
      2. Tamb\u00e9m \u00e9 necess\u00e1rio um arquivo de configura\u00e7\u00e3o<\/b>, que informar\u00e1 ao Nomad o que, onde e em que quantidade voc\u00ea deseja implantar. <\/li>\n<\/ol>\n

        \nQuando falamos sobre o Nomad, o formato do arquivo utilizado \u00e9 a linguagem HCL, que \u00e9 a abrevia\u00e7\u00e3o de HashiCorp Configuration Language<\/i>. Essa linguagem \u00e9 uma superconjunto do Yaml, que permite descrever seu servi\u00e7o em termos de Nomad. <\/p>\n

        \"Implanta\u00e7\u00e3o
        \n
        \nEla permite especificar quantos cont\u00eaineres voc\u00ea deseja implantar, de quais imagens e passar a eles v\u00e1rios par\u00e2metros durante a implanta\u00e7\u00e3o. Assim, voc\u00ea alimenta esse arquivo ao Nomad, que inicia os cont\u00eaineres em produ\u00e7\u00e3o de acordo com ele. <\/p>\n

        No nosso caso, percebemos que simplesmente criar arquivos HCL id\u00eanticos para cada servi\u00e7o n\u00e3o seria muito pr\u00e1tico, pois existem muitos servi\u00e7os e \u00e0s vezes \u00e9 necess\u00e1rio atualiz\u00e1-los. \u00c0s vezes, um servi\u00e7o n\u00e3o est\u00e1 implantado em uma \u00fanica inst\u00e2ncia, mas em v\u00e1rias. Por exemplo, um dos sistemas que temos em produ\u00e7\u00e3o possui mais de 100 inst\u00e2ncias em produ\u00e7\u00e3o. Eles s\u00e3o iniciados a partir das mesmas imagens, mas diferem nas configura\u00e7\u00f5es e arquivos de configura\u00e7\u00e3o. <\/p>\n

        Portanto, decidimos que seria conveniente armazenar todos os nossos arquivos de configura\u00e7\u00e3o para implanta\u00e7\u00e3o em um \u00fanico reposit\u00f3rio central. Assim, eles se tornam visualiz\u00e1veis: \u00e9 f\u00e1cil mant\u00ea-los e \u00e9 poss\u00edvel ver quais sistemas temos. Em caso de necessidade, tamb\u00e9m n\u00e3o \u00e9 dif\u00edcil atualizar ou modificar algo. Adicionar um novo sistema tamb\u00e9m n\u00e3o ser\u00e1 dif\u00edcil \u2014 basta criar um arquivo de configura\u00e7\u00e3o em um novo diret\u00f3rio. Dentro dele est\u00e3o os arquivos: service.hcl, que cont\u00e9m a descri\u00e7\u00e3o do nosso servi\u00e7o, e alguns arquivos env, que permitem configurar esse servi\u00e7o ao ser implantado em produ\u00e7\u00e3o. <\/p>\n

        \"Implanta\u00e7\u00e3o
        \n
        \nNo entanto, alguns dos nossos sistemas est\u00e3o implantados em produ\u00e7\u00e3o n\u00e3o em uma \u00fanica inst\u00e2ncia, mas em v\u00e1rias ao mesmo tempo. Portanto, decidimos que seria conveniente armazenar n\u00e3o as configura\u00e7\u00f5es em sua forma bruta, mas sim sua vers\u00e3o templatinizada. Como linguagem de template, escolhemos jinja 2<\/i>. Neste formato, armazenamos tanto as configura\u00e7\u00f5es do pr\u00f3prio servi\u00e7o quanto os arquivos env necess\u00e1rios para ele. <\/p>\n

        Al\u00e9m disso, colocamos no reposit\u00f3rio um script de implanta\u00e7\u00e3o comum a todos os projetos, que permite iniciar e implantar seu servi\u00e7o em produ\u00e7\u00e3o, no ambiente necess\u00e1rio, no alvo desejado. Quando transformamos nossa configura\u00e7\u00e3o HCL em um template, o arquivo HCL, que antes era uma configura\u00e7\u00e3o comum do Nomad, passa a ter uma apar\u00eancia um pouco diferente.<\/p>\n

        \"Implanta\u00e7\u00e3o
        \n
        \nOu seja, substitu\u00edmos algumas vari\u00e1veis na configura\u00e7\u00e3o por inser\u00e7\u00f5es de vari\u00e1veis que s\u00e3o extra\u00eddas dos arquivos env ou de outras fontes. Al\u00e9m disso, conseguimos gerar arquivos HCL dinamicamente, o que significa que podemos aplicar n\u00e3o apenas inser\u00e7\u00f5es comuns de vari\u00e1veis. Como o jinja suporta loops e condi\u00e7\u00f5es, tamb\u00e9m podemos criar arquivos de configura\u00e7\u00e3o que mudam dependendo de onde voc\u00ea implanta seus aplicativos. <\/p>\n

        Por exemplo, voc\u00ea deseja implantar seu servi\u00e7o em pr\u00e9-produ\u00e7\u00e3o e em produ\u00e7\u00e3o. Digamos que, na pr\u00e9-produ\u00e7\u00e3o, voc\u00ea n\u00e3o queira executar scripts cron, mas apenas ver o servi\u00e7o em um dom\u00ednio separado para garantir que ele funcione. Para qualquer pessoa que implanta o servi\u00e7o, o processo parece muito simples e transparente. Basta executar o arquivo deploy.sh, indicando qual servi\u00e7o voc\u00ea deseja implantar e em qual alvo. Por exemplo, voc\u00ea deseja implantar um sistema na R\u00fassia, na Bielorr\u00fassia ou no Cazaquist\u00e3o. Para isso, \u00e9 suficiente trocar um dos par\u00e2metros, e o arquivo de configura\u00e7\u00e3o correto ser\u00e1 gerado. <\/p>\n

        Quando o servi\u00e7o Nomad j\u00e1 est\u00e1 implantado em seu cluster, ele se parece com isto.<\/p>\n

        \"Implanta\u00e7\u00e3o
        \n
        \nPara come\u00e7ar, voc\u00ea precisa de um balanceador externo que receba todo o tr\u00e1fego dos usu\u00e1rios. Ele funcionar\u00e1 juntamente com o Consul e descobrir\u00e1 onde, em qual n\u00f3, reside o endere\u00e7o IP<\/a> servi\u00e7o espec\u00edfico que corresponde ao determinado nome de dom\u00ednio. Os servi\u00e7os no Consul aparecem a partir do pr\u00f3prio Nomad. Como s\u00e3o produtos da mesma empresa, eles est\u00e3o bem integrados entre si. Pode-se dizer que o Nomad \u00e9 capaz de registrar todos os servi\u00e7os executados nele dentro do Consul, por padr\u00e3o. <\/p>\n

        Ap\u00f3s o balanceador externo de carga saber para qual servi\u00e7o redirecionar o tr\u00e1fego, ele o encaminha para o cont\u00eainer correspondente ou para v\u00e1rios cont\u00eaineres que pertencem \u00e0 sua aplica\u00e7\u00e3o. \u00c9 certo que a seguran\u00e7a tamb\u00e9m deve ser considerada. Mesmo que todos os servi\u00e7os sejam executados nas mesmas m\u00e1quinas virtuais dentro de cont\u00eaineres, geralmente \u00e9 necess\u00e1rio proibir o acesso livre de qualquer servi\u00e7o a qualquer outro. N\u00f3s alcan\u00e7amos isso por meio da segmenta\u00e7\u00e3o. Cada servi\u00e7o era executado em sua pr\u00f3pria rede virtual, onde foram definidas regras de roteamento e regras de permiss\u00e3o\/proibi\u00e7\u00e3o de acesso a outros sistemas e servi\u00e7os. Eles podiam estar tanto dentro desse cluster quanto fora dele. Por exemplo, se voc\u00ea deseja proibir um servi\u00e7o de se conectar a um determinado banco de dados, isso pode ser feito atrav\u00e9s da segmenta\u00e7\u00e3o em n\u00edvel de rede. Ou seja, mesmo que seja por erro, voc\u00ea n\u00e3o pode acidentalmente se conectar do ambiente de teste ao seu banco de dados de produ\u00e7\u00e3o.<\/p>\n

        Quanto nos custou o processo de transi\u00e7\u00e3o em termos de recursos humanos? <\/p>\n

        Levaram cerca de 5 a 6 meses para a transi\u00e7\u00e3o de toda a empresa para o Nomad. Fizemos a transi\u00e7\u00e3o servi\u00e7o por servi\u00e7o, mas em um ritmo bastante r\u00e1pido. Cada equipe teve que criar seus pr\u00f3prios cont\u00eaineres para os servi\u00e7os. <\/p>\n

        Adotamos a abordagem de que cada equipe \u00e9 respons\u00e1vel por suas pr\u00f3prias imagens Docker. Os DevOps fornecem a infraestrutura geral necess\u00e1ria para a implanta\u00e7\u00e3o, ou seja, o suporte do pr\u00f3prio cluster, suporte do sistema CI e assim por diante. Naquele momento, mais de 60 sistemas haviam se mudado para o Nomad, totalizando cerca de 2 mil cont\u00eaineres. <\/p>\n

        Os DevOps s\u00e3o respons\u00e1veis pela infraestrutura geral relacionada \u00e0 implanta\u00e7\u00e3o, aos servidores. Por outro lado, cada equipe de desenvolvimento \u00e9 respons\u00e1vel pela implementa\u00e7\u00e3o de cont\u00eaineres para seu sistema espec\u00edfico, pois \u00e9 a equipe que sabe exatamente o que precisa em cada cont\u00eainer.<\/p>\n

        Raz\u00f5es para desistir do Nomad<\/h1>\n

        \nQuais benef\u00edcios obtivemos ao migrar para a implanta\u00e7\u00e3o utilizando o Nomad e o Docker, entre outros?<\/p>\n

          \n
        1. N\u00f3s garantimos condi\u00e7\u00f5es iguais<\/b> para todos os ambientes. Em desenvolvimento, ambiente de QA, pr\u00e9-produ\u00e7\u00e3o e produ\u00e7\u00e3o, utilizam-se as mesmas imagens de container, com as mesmas depend\u00eancias. Portanto, voc\u00ea praticamente n\u00e3o tem chance de que na produ\u00e7\u00e3o apare\u00e7a algo diferente do que foi testado localmente ou em um ambiente de teste. <\/li>\n
        2. Tamb\u00e9m descobrimos que \u00e9 suficiente adicionar facilmente um novo servi\u00e7o<\/b>. Qualquer novo sistema, em termos de deploy, \u00e9 muito f\u00e1cil de iniciar. Basta ir at\u00e9 o reposit\u00f3rio que armazena as configura\u00e7\u00f5es, adicionar mais uma configura\u00e7\u00e3o para o seu sistema, e tudo estar\u00e1 pronto. Voc\u00ea pode fazer o deploy do seu sistema em produ\u00e7\u00e3o sem esfor\u00e7os adicionais da parte do DevOps. <\/li>\n
        3. Todos arquivos de configura\u00e7\u00e3o<\/b> em um \u00fanico reposit\u00f3rio comum se mostraram observ\u00e1veis<\/b>. No momento em que fizemos o deploy dos nossos sistemas usando servidores virtuais<\/a>, utilizamos o Ansible, onde as configura\u00e7\u00f5es estavam no mesmo reposit\u00f3rio. No entanto, para a maioria dos desenvolvedores, isso era um pouco mais complicado. Aqui, o volume de configura\u00e7\u00f5es e c\u00f3digo que voc\u00ea precisa adicionar para fazer o deploy do servi\u00e7o foi significativamente reduzido. Al\u00e9m disso, para DevOps, \u00e9 muito f\u00e1cil corrigir ou alterar isso. No caso de transi\u00e7\u00f5es, por exemplo, para uma nova vers\u00e3o do Nomad, eles podem pegar e atualizar massivamente todos os arquivos operacionais que est\u00e3o no mesmo lugar.<\/li>\n<\/ol>\n

          \nMas tamb\u00e9m enfrentamos algumas desvantagens: <\/p>\n

          Descobrimos que n\u00e3o conseguimos alcan\u00e7ar a continuidade nos deploys <\/b>no caso do Nomad. Durante a implanta\u00e7\u00e3o de containers de diferentes condi\u00e7\u00f5es, poderia ocorrer que este estivesse em execu\u00e7\u00e3o, e o Nomad o reconhecesse como pronto para receber tr\u00e1fego. Isso acontecia antes mesmo do aplicativo dentro dele conseguir iniciar. Por causa disso, o sistema, por um curto per\u00edodo, come\u00e7ou a retornar erros 500, pois o tr\u00e1fego come\u00e7ava a ir para um container que ainda n\u00e3o estava pronto para aceit\u00e1-lo. <\/p>\n

          Encontramos alguns bugs<\/b>. O maior problema \u00e9 que o Nomad n\u00e3o lida muito bem com um grande cluster quando voc\u00ea tem muitos sistemas e cont\u00eaineres. Quando voc\u00ea deseja colocar em manuten\u00e7\u00e3o um dos servidores que faz parte do cluster Nomad, h\u00e1 uma grande probabilidade de que o cluster n\u00e3o se sinta bem e se desfa\u00e7a. Alguns cont\u00eaineres podem, por exemplo, cair e n\u00e3o se levantar \u2014 isso pode custar muito caro para voc\u00ea, se todos os seus sistemas em produ\u00e7\u00e3o estiverem no cluster gerenciado pelo Nomad. <\/p>\n

          Portanto, decidimos refletir sobre o nosso pr\u00f3ximo passo. Naquela \u00e9poca, come\u00e7amos a entender muito melhor o que quer\u00edamos alcan\u00e7ar. Em resumo: buscamos confiabilidade, um pouco mais de funcionalidades do que o Nomad oferece e um sistema mais maduro e est\u00e1vel. <\/p>\n

          Nesse sentido, nossa escolha recaiu sobre o Kubernetes como a plataforma mais popular para executar clusters. Especialmente considerando que o tamanho e a quantidade de nossos cont\u00eaineres eram bastante grandes. Para esses fins, o Kubernetes parecia ser o sistema mais adequado dentre os que avaliamos. <\/p>\n

          Transi\u00e7\u00e3o para o Kubernetes<\/h1>\n

          \nVou explicar um pouco sobre os principais conceitos do Kubernetes e como eles diferem do Nomad. <\/p>\n

          \"Implanta\u00e7\u00e3o
          \n
          \nEm primeiro lugar, o conceito mais b\u00e1sico no Kubernetes \u00e9 o pod. Pod<\/b> \u2014 \u00e9 um grupo de um ou mais cont\u00eaineres que sempre s\u00e3o executados juntos. E eles funcionam como se estivessem sempre na mesma m\u00e1quina virtual. Eles t\u00eam acesso entre si pelo endere\u00e7o IP 127.0.0.1 em portas diferentes. <\/p>\n

          Suponha que voc\u00ea tenha uma aplica\u00e7\u00e3o PHP que consiste em nginx e php-fpm \u2013 um esquema cl\u00e1ssico. \u00c9 prov\u00e1vel que voc\u00ea queira que os cont\u00eaineres de nginx e php-fpm estejam sempre juntos. O Kubernetes permite que voc\u00ea consiga isso, descrevendo-os como um \u00fanico pod. Isso \u00e9 exatamente o que n\u00e3o conseguimos obter com o Nomad.<\/p>\n

          O segundo conceito \u00e9 deployment<\/b>. O fato \u00e9 que um pod por si s\u00f3 \u00e9 algo ef\u00eamero, ele inicia e desaparece. Voc\u00ea quer primeiro matar todos os seus cont\u00eaineres anteriores e, em seguida, iniciar novas vers\u00f5es de uma s\u00f3 vez, ou prefere implant\u00e1-las gradualmente \u2013 \u00e9 exatamente esse processo que o conceito de deployment gerencia. Ele descreve como voc\u00ea implanta seus pods, em que quantidade e como atualiz\u00e1-los. <\/p>\n

          O terceiro conceito \u00e9 servi\u00e7o<\/b>. Seu service \u00e9 basicamente seu sistema, que aceita um certo tr\u00e1fego e depois o direciona para um ou mais pods correspondentes ao seu servi\u00e7o. Isso significa que voc\u00ea pode dizer que todo o tr\u00e1fego de entrada para um servi\u00e7o com um determinado nome deve ser enviado especificamente para esses pods. E assim, ele oferece balanceamento de tr\u00e1fego. Voc\u00ea pode executar dois pods da sua aplica\u00e7\u00e3o, e todo o tr\u00e1fego de entrada ser\u00e1 equilibrado uniformemente entre os pods relacionados a esse servi\u00e7o.<\/p>\n

          E o quarto conceito b\u00e1sico \u00e9 Ingress<\/b>. Este \u00e9 um servi\u00e7o que \u00e9 executado em um cluster Kubernetes. Ele atua como um balanceador de carga externo, que aceita todas as solicita\u00e7\u00f5es. Atrav\u00e9s da API do Kubernetes, o Ingress pode determinar para onde essas solicita\u00e7\u00f5es devem ser enviadas. E faz isso de forma muito flex\u00edvel. Voc\u00ea pode dizer que todas as solicita\u00e7\u00f5es para este host e este URL devem ser enviadas para este servi\u00e7o. E aquelas solicita\u00e7\u00f5es que chegam a este host e a outro URL devem ser enviadas para outro servi\u00e7o. <\/p>\n

          O mais incr\u00edvel sob a perspectiva de quem desenvolve a aplica\u00e7\u00e3o \u00e9 que voc\u00ea pode gerenciar tudo isso por conta pr\u00f3pria. Definindo a configura\u00e7\u00e3o do Ingress, voc\u00ea pode direcionar todo o tr\u00e1fego que chega a uma determinada API para cont\u00eaineres separados, programados, por exemplo, em Go. E aquele tr\u00e1fego que chega ao mesmo dom\u00ednio, mas a outro URL, pode ser enviado para cont\u00eaineres escritos em PHP, onde h\u00e1 muita l\u00f3gica, mas s\u00e3o menos r\u00e1pidas.<\/p>\n

          Se compararmos todos esses conceitos com o Nomad, podemos dizer que os primeiros tr\u00eas conceitos formam juntos um Service. E o \u00faltimo conceito n\u00e3o existe no Nomad. Como substituto, usamos um balanceador de carga externo: isso pode ser haproxy, nginx, nginx+ e assim por diante. No caso do Kubernetes, voc\u00ea n\u00e3o precisa introduzir esse conceito adicional separadamente. No entanto, se olharmos para o Ingress internamente, ele pode ser nginx, haproxy ou traefik, mas de alguma forma integrado ao Kubernetes. <\/p>\n

          Todos os conceitos que descrevi s\u00e3o, na verdade, recursos que existem dentro do cluster Kubernetes. Para descrev\u00ea-los no Kubernetes, utiliza-se o formato yaml, que \u00e9 mais leg\u00edvel e familiar do que arquivos HCL no caso do Nomad. Mas estruturalmente, eles descrevem, por exemplo, o mesmo que um pod. Eles dizem \u2013 quero implantar esses pods aqui, com essas imagens, em tal quantidade. <\/p>\n

          \"Implanta\u00e7\u00e3o
          \n
          \nAl\u00e9m disso, entendemos que n\u00e3o quer\u00edamos criar manualmente cada recurso separadamente: deployment, servi\u00e7os, Ingress e outros. Em vez disso, quer\u00edamos descrever cada sistema em termos do Kubernetes durante o deployment, para evitar ter que recriar manualmente todas as depend\u00eancias necess\u00e1rias na ordem correta. Para isso, escolhemos o Helm como a ferramenta que nos permitiria fazer isso. <\/p>\n

          Conceitos principais do Helm<\/h1>\n

          \nO Helm \u00e9 um gerenciador de pacotes<\/b> gerenciador de pacotes para Kubernetes. Ele \u00e9 muito semelhante ao funcionamento dos gerenciadores de pacotes em linguagens de programa\u00e7\u00e3o. Eles permitem armazenar um servi\u00e7o que consiste, por exemplo, em um deployment do nginx, um deployment do php-fpm, uma configura\u00e7\u00e3o para Ingress, configmaps (que s\u00e3o entidades que permitem definir vari\u00e1veis de ambiente e outros par\u00e2metros para o seu sistema) sob a forma dos chamados charts. Com isso, o Helm funciona sobre o Kubernetes.<\/b>Ou seja, n\u00e3o se trata de um sistema \u00e0 parte, mas sim de mais um servi\u00e7o executado dentro do cluster. Voc\u00ea interage com ele por meio de sua API via comandos de console. Sua conveni\u00eancia e valor est\u00e3o no fato de que, mesmo que o Helm apresente falhas ou seja removido do cluster, seus servi\u00e7os n\u00e3o desaparecer\u00e3o, pois o Helm serve basicamente para iniciar o sistema. A funcionalidade e o estado dos servi\u00e7os \u00e9 responsabilidade do pr\u00f3prio Kubernetes. <\/p>\n

          Tamb\u00e9m percebemos que a templating<\/b>, que antes t\u00ednhamos que implementar manualmente atrav\u00e9s da integra\u00e7\u00e3o do jinja em nossas configura\u00e7\u00f5es, \u00e9 uma das principais capacidades do Helm. Todas as configura\u00e7\u00f5es que voc\u00ea cria para seus sistemas s\u00e3o armazenadas no Helm na forma de templates, semelhantes ao jinja, mas que na verdade utilizam a templating da linguagem Go, na qual o Helm foi escrito, assim como o Kubernetes. <\/p>\n

          O Helm nos adiciona mais alguns conceitos. <\/p>\n

          Chart<\/b> \u00e9 a descri\u00e7\u00e3o do seu servi\u00e7o. Em outros gerenciadores de pacotes, seria chamado de pacote, bundle ou algo similar. Aqui, ele \u00e9 chamado de chart. <\/p>\n

          Values <\/b>s\u00e3o as vari\u00e1veis que voc\u00ea deseja usar para compor suas configura\u00e7\u00f5es a partir dos templates. <\/p>\n

          Release<\/b>. Sempre que um servi\u00e7o \u00e9 implantado usando helm, ele recebe uma vers\u00e3o incremental do release. O Helm se lembra de como era a configura\u00e7\u00e3o do servi\u00e7o no release anterior, no pen\u00faltimo, e assim por diante. Por isso, se for necess\u00e1rio reverter, basta executar o comando helm callback, especificando a vers\u00e3o anterior do release. Mesmo que, no momento da revers\u00e3o, a configura\u00e7\u00e3o correspondente n\u00e3o esteja dispon\u00edvel em seu reposit\u00f3rio, o helm ainda se lembrar\u00e1 de como ela era e reverter\u00e1 seu sistema para o estado em que estava no release anterior. <\/p>\n

          No caso de usarmos helm, as configura\u00e7\u00f5es comuns do Kubernetes tamb\u00e9m se transformam em templates, onde \u00e9 poss\u00edvel usar vari\u00e1veis, fun\u00e7\u00f5es e operadores condicionais. Assim, voc\u00ea pode compor a configura\u00e7\u00e3o do seu servi\u00e7o dependendo do ambiente.<\/p>\n

          \"Implanta\u00e7\u00e3o
          \n
          \nNa pr\u00e1tica, decidimos proceder de maneira um pouco diferente do que fizemos com o Nomad. Se no Nomad, um \u00fanico reposit\u00f3rio armazenava tanto as configura\u00e7\u00f5es de implanta\u00e7\u00e3o quanto as vari\u00e1veis n necess\u00e1rias para implantar nosso servi\u00e7o, aqui decidimos dividi-las em dois reposit\u00f3rios separados. No reposit\u00f3rio \"deploy\" s\u00e3o armazenadas apenas as vari\u00e1veis n necess\u00e1rias para a implanta\u00e7\u00e3o, enquanto no reposit\u00f3rio \"helm\" s\u00e3o guardadas as configura\u00e7\u00f5es ou charts.<\/p>\n

          \"Implanta\u00e7\u00e3o
          \n
          \nO que isso nos proporcionou? <\/p>\n

          Embora n\u00e3o armazenemos dados realmente sens\u00edveis nos pr\u00f3prios arquivos de configura\u00e7\u00e3o, como senhas de bancos de dados, que s\u00e3o mantidas como secrets no Kubernetes, ainda existem aspectos que n\u00e3o queremos permitir o acesso a todos. Portanto, o acesso ao reposit\u00f3rio \"deploy\" \u00e9 mais restrito, enquanto o reposit\u00f3rio \"helm\" cont\u00e9m apenas a descri\u00e7\u00e3o do servi\u00e7o. Por essa raz\u00e3o, ele pode ser acessado de forma segura por um grupo maior de pessoas. <\/p>\n

          Como temos n\u00e3o apenas produ\u00e7\u00e3o, mas tamb\u00e9m outros ambientes, gra\u00e7as a essa separa\u00e7\u00e3o podemos reutilizar nossos charts do helm para implantar servi\u00e7os n\u00e3o apenas na produ\u00e7\u00e3o, mas tamb\u00e9m, por exemplo, no ambiente de QA. Mesmo para que possam ser implantados localmente usando Minikube<\/i> \u2014 isso \u00e9 uma ferramenta para execu\u00e7\u00e3o local do Kubernetes. <\/p>\n

          Dentro de cada reposit\u00f3rio, deixamos a divis\u00e3o em diret\u00f3rios separados para cada servi\u00e7o. Ou seja, dentro de cada diret\u00f3rio, encontram-se os templates relacionados ao respectivo chart, descrevendo os recursos que precisam ser implantados para iniciar nosso sistema. No reposit\u00f3rio 'deploy', deixamos apenas o env. Nesse caso, n\u00e3o usamos a templata\u00e7\u00e3o com jinja, pois o helm j\u00e1 oferece templata\u00e7\u00e3o out of the box - essa \u00e9 uma de suas principais fun\u00e7\u00f5es. <\/p>\n

          Deixamos um script para a implanta\u00e7\u00e3o - deploy.sh, que simplifica e padroniza o in\u00edcio da implanta\u00e7\u00e3o usando helm. Assim, para qualquer um que deseje implantar, a interface de implanta\u00e7\u00e3o \u00e9 exatamente como era no caso da implanta\u00e7\u00e3o atrav\u00e9s do Nomad. O mesmo deploy.sh, o nome do seu servi\u00e7o e o local onde voc\u00ea deseja implant\u00e1-lo. Isso resulta na execu\u00e7\u00e3o do helm. Ele, por sua vez, coleta as configura\u00e7\u00f5es dos templates, insere os arquivos values necess\u00e1rios e, em seguida, implanta, enviando-os para o Kubernetes. <\/p>\n

          Como resultado, obtemos um servi\u00e7o de \"monitoramento como servi\u00e7o\", automatizado na linha de produ\u00e7\u00e3o de integra\u00e7\u00e3o cont\u00ednua. O desenvolvedor ou testador precisa apenas definir a lista de m\u00e9tricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lan\u00e7amentos: todas as notifica\u00e7\u00f5es sobre desempenho, consumo de recursos ou regress\u00f5es arquitet\u00f4nicas.<\/h1>\n

          \nO servi\u00e7o Kubernetes parece mais complexo do que o Nomad. <\/p>\n

          \"Implanta\u00e7\u00e3o
          \n
          \nAqui, o tr\u00e1fego de sa\u00edda chega ao Ingress. Este \u00e9 o controlador de front que recebe todas as solicita\u00e7\u00f5es e posteriormente as direciona aos servi\u00e7os correspondentes a essas solicita\u00e7\u00f5es. Ele os define com base nas configura\u00e7\u00f5es que fazem parte da descri\u00e7\u00e3o do seu aplicativo no helm e que os desenvolvedores definem por conta pr\u00f3pria. O servi\u00e7o, por sua vez, envia as solicita\u00e7\u00f5es para seus pods, ou seja, cont\u00eaineres espec\u00edficos, equilibrando o tr\u00e1fego de entrada entre todos os cont\u00eaineres que pertencem a esse servi\u00e7o. E, claro, n\u00e3o devemos esquecer que n\u00e3o podemos nos afastar da seguran\u00e7a em n\u00edvel de rede. Portanto, no cluster Kubernetes, h\u00e1 uma segmenta\u00e7\u00e3o baseada em tagging. Todos os servi\u00e7os t\u00eam tags espec\u00edficas, \u00e0s quais est\u00e3o associados os direitos de acesso dos servi\u00e7os a determinados recursos externos\/internos dentro ou fora do cluster. <\/p>\n

          Ao realizar a migra\u00e7\u00e3o, vimos que o Kubernetes possui todas as funcionalidades do Nomad, que us\u00e1vamos anteriormente, e ainda adiciona muitas novas. Ele pode ser expandido por meio de plugins, na verdade, atrav\u00e9s de tipos personalizados de recursos. Ou seja, voc\u00ea tem a possibilidade n\u00e3o apenas de usar o que vem no Kubernetes por padr\u00e3o, mas de criar seu pr\u00f3prio recurso e servi\u00e7o que vai ler esse recurso. Isso oferece oportunidades adicionais para expandir seu sistema sem a necessidade de reinstalar o Kubernetes e sem a necessidade de fazer altera\u00e7\u00f5es. <\/p>\n

          Um exemplo desse uso \u00e9 o Prometheus, que roda dentro do nosso cluster Kubernetes. Para que ele comece a coletar m\u00e9tricas de um determinado servi\u00e7o, precisamos adicionar \u00e0 descri\u00e7\u00e3o do servi\u00e7o um tipo de recurso adicional, chamado de monitor de servi\u00e7o. O Prometheus, por saber ler e ser executado no Kubernetes, automaticamente come\u00e7a a coletar m\u00e9tricas do novo sistema. Isso \u00e9 bastante conveniente. <\/p>\n

          O primeiro deploy que fizemos no Kubernetes foi em mar\u00e7o de 2018. E durante esse tempo nunca tivemos problemas com ele. Funciona de maneira bastante est\u00e1vel, sem bugs significativos. Al\u00e9m disso, podemos expandi-lo ainda mais. Hoje em dia, as capacidades que ele possui nos atendem bem, e a velocidade de desenvolvimento do Kubernetes nos agrada muito. Atualmente, mais de 3000 cont\u00eaineres est\u00e3o em Kubernetes. O cluster ocupa v\u00e1rios N\u00f3s. Ele \u00e9 gerenci\u00e1vel, est\u00e1vel e muito controlado.
          \n
          Fonte:           habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

          \u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041f\u0430\u0432\u0435\u043b \u0410\u0433\u0430\u043b\u0435\u0446\u043a\u0438\u0439. \u042f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0442\u0438\u043c\u043b\u0438\u0434\u043e\u043c \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 Lamoda. \u0412 2018 \u0433\u043e\u0434\u0443 \u044f \u0432\u044b\u0441\u0442\u0443\u043f\u0430\u043b \u043d\u0430 \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u0438 HighLoad++, \u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u0445\u043e\u0447\u0443 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0443 \u0441\u0432\u043e\u0435\u0433\u043e \u0434\u043e\u043a\u043b\u0430\u0434\u0430. \u041c\u043e\u044f \u0442\u0435\u043c\u0430 \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u0430 \u043e\u043f\u044b\u0442\u0443 \u043d\u0430\u0448\u0435\u0439 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u043f\u043e \u0434\u0435\u043f\u043b\u043e\u044e \u0441\u0438\u0441\u0442\u0435\u043c \u0438 \u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 \u0432 \u0440\u0430\u0437\u043d\u044b\u0435 \u0441\u0440\u0435\u0434\u044b. \u041d\u0430\u0447\u0438\u043d\u0430\u044f \u043e\u0442 \u043d\u0430\u0448\u0438\u0445 \u0434\u043e\u0438\u0441\u0442\u043e\u0440\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0432\u0440\u0435\u043c\u0435\u043d, \u043a\u043e\u0433\u0434\u0430 \u043c\u044b \u0434\u0435\u043f\u043b\u043e\u0438\u043b\u0438 \u0432\u0441\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":25343,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33654","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Deploy de aplicativos em VM, Nomad e Kubernetes | ProHoster","description":"Ol\u00e1 a todos! Meu nome \u00e9 Pavel Agaletsky. Eu sou o l\u00edder da equipe que desenvolve o sistema de entrega da Lamoda.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/deploj-prilozhenij-v-vm-nomad-i-kubernetes","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\u0414\u0435\u043f\u043b\u043e\u0439 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0432 VM, Nomad \u0438 Kubernetes | ProHoster","og:description":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041f\u0430\u0432\u0435\u043b \u0410\u0433\u0430\u043b\u0435\u0446\u043a\u0438\u0439. \u042f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0442\u0438\u043c\u043b\u0438\u0434\u043e\u043c \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 Lamoda.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/deploj-prilozhenij-v-vm-nomad-i-kubernetes","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":"2019-10-31T18:53:58+00:00","article:modified_time":"2019-10-31T18:53:58+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33654","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":"2026-02-08 20:38:40","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:36:34","updated":"2026-02-08 20:38:40","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\/33654","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=33654"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/33654\/revisions"}],"predecessor-version":[{"id":157982,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/33654\/revisions\/157982"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/25343"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=33654"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=33654"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=33654"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}