{"id":83787,"date":"2020-06-03T07:42:26","date_gmt":"2020-06-03T05:42:26","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/devoxx-uk-kubernetes-v-prodakshene-blue-green-deployment-avtomasshtabirovanie-i-avtomatizacziya-razvertyvaniya-chast-2"},"modified":"2020-06-03T07:42:26","modified_gmt":"2020-06-03T05:42:26","slug":"devoxx-uk-kubernetes-v-prodakshene-blue-green-deployment-avtomasshtabirovanie-i-avtomatizacziya-razvertyvaniya-chast-2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/devoxx-uk-kubernetes-v-prodakshene-blue-green-deployment-avtomasshtabirovanie-i-avtomatizacziya-razvertyvaniya-chast-2","title":{"rendered":"DEVOXX UK. Kubernetes em produ\u00e7\u00e3o: Blue\/Green deployment, escalabilidade autom\u00e1tica e automa\u00e7\u00e3o de implanta\u00e7\u00f5es. Parte 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Kubernetes \u00e9 uma excelente ferramenta para executar cont\u00eaineres Docker em um ambiente de produ\u00e7\u00e3o clusterizado. No entanto, existem tarefas que o Kubernetes n\u00e3o consegue resolver. Com implanta\u00e7\u00f5es frequentes em um ambiente de produ\u00e7\u00e3o, precisamos de um Blue\/Green deployment totalmente automatizado para evitar interrup\u00e7\u00f5es nesse processo, que tamb\u00e9m requer o manuseio de solicita\u00e7\u00f5es HTTP externas e a execu\u00e7\u00e3o de descargas SSL. Isso exige integra\u00e7\u00e3o com um balanceador de carga, como o ha-proxy. Outra tarefa \u00e9 o escalonamento semi-autom\u00e1tico do pr\u00f3prio cluster Kubernetes ao operar em um ambiente de nuvem, como, por exemplo, a redu\u00e7\u00e3o parcial do cluster durante a noite.<\/p>\n

Embora o Kubernetes n\u00e3o possua essas funcionalidades 'prontas para uso', ele fornece uma API que pode ser utilizada para resolver essas tarefas. Ferramentas para implanta\u00e7\u00e3o autom\u00e1tica de Blue\/Green e escalonamento do cluster Kubernetes foram desenvolvidas no \u00e2mbito do projeto Cloud RTI, que foi baseado em c\u00f3digo aberto.<\/p>\n

Neste artigo, uma transcri\u00e7\u00e3o de v\u00eddeo, \u00e9 explicado como configurar o Kubernetes junto com outros componentes de c\u00f3digo aberto para criar um ambiente pronto para produ\u00e7\u00e3o, que lida com o c\u00f3digo do commit git commit sem interrup\u00e7\u00f5es em produ\u00e7\u00e3o.<\/p>\n

\"DEVOXX<\/a><\/noindex><\/p>\n

DEVOXX UK. Kubernetes em Produ\u00e7\u00e3o: Blue\/Green deployment, autoscaling e automa\u00e7\u00e3o de implanta\u00e7\u00f5es. Parte 1.<\/a><\/noindex><\/p>\n

Assim, ap\u00f3s ter acesso aos seus aplicativos a partir do mundo externo, voc\u00ea pode come\u00e7ar a configurar a automa\u00e7\u00e3o completa, ou seja, lev\u00e1-la ao est\u00e1gio em que pode executar um git commit e garantir que esse git commit finalize em produ\u00e7\u00e3o. Naturalmente, ao realizar esses passos durante a implanta\u00e7\u00e3o, n\u00e3o queremos enfrentar interrup\u00e7\u00f5es. Portanto, toda automa\u00e7\u00e3o no Kubernetes come\u00e7a com a API. <\/p>\n

\"DEVOXX
\n
\nKubernetes n\u00e3o \u00e9 a ferramenta que pode ser utilizada de maneira produtiva 'pronta para uso'. Claro, voc\u00ea pode fazer isso, usar kubectl e assim por diante, mas ainda assim a API \u00e9 o aspecto mais interessante e \u00fatil desta plataforma. Usando a API como um conjunto de fun\u00e7\u00f5es, voc\u00ea pode acessar praticamente tudo o que deseja fazer no Kubernetes. O kubectl em si tamb\u00e9m utiliza a REST API. <\/p>\n

Este \u00e9 um REST, ent\u00e3o voc\u00ea pode usar qualquer linguagem e ferramentas para trabalhar com esta API, mas bibliotecas personalizadas facilitar\u00e3o muito sua vida. Minha equipe escreveu 2 dessas bibliotecas: uma para Java \/ OSGi e uma para Go. A segunda n\u00e3o \u00e9 muito utilizada, mas, de qualquer forma, voc\u00ea tem essas ferramentas \u00fateis \u00e0 sua disposi\u00e7\u00e3o. Elas constituem um projeto open-source parcialmente licenciado. Existem muitas dessas bibliotecas para v\u00e1rias linguagens, ent\u00e3o voc\u00ea pode escolher as mais adequadas. <\/p>\n

\"DEVOXX
\n
\nAssim, antes de come\u00e7ar a automatizar a implanta\u00e7\u00e3o, \u00e9 necess\u00e1rio garantir que esse processo n\u00e3o enfrentar\u00e1 per\u00edodos de inatividade. Por exemplo, nossa equipe realiza implanta\u00e7\u00f5es em produ\u00e7\u00e3o durante o meio do dia, quando as pessoas utilizam os aplicativos ao m\u00e1ximo, portanto, \u00e9 muito importante evitar atrasos nesse processo. Para evitar per\u00edodos de inatividade, utilizamos 2 m\u00e9todos: implanta\u00e7\u00e3o blue\/green ou atualiza\u00e7\u00e3o cont\u00ednua. No \u00faltimo caso, se voc\u00ea tiver 5 r\u00e9plicas do aplicativo em opera\u00e7\u00e3o, elas s\u00e3o atualizadas sequencialmente, uma ap\u00f3s a outra. Este m\u00e9todo funciona muito bem, mas n\u00e3o \u00e9 adequado se voc\u00ea tiver vers\u00f5es diferentes do aplicativo em execu\u00e7\u00e3o simultaneamente durante o processo de implanta\u00e7\u00e3o. Nesse caso, voc\u00ea pode atualizar a interface do usu\u00e1rio enquanto o backend ainda estiver rodando uma vers\u00e3o anterior, e a funcionalidade do aplicativo ser\u00e1 interrompida. Portanto, do ponto de vista da programa\u00e7\u00e3o, trabalhar nessas condi\u00e7\u00f5es \u00e9 bastante complicado. <\/p>\n

Essa \u00e9 uma das raz\u00f5es pelas quais preferimos usar a implanta\u00e7\u00e3o blue\/green para automatizar a implanta\u00e7\u00e3o de nossos aplicativos. Com esse m\u00e9todo, voc\u00ea deve garantir que em um determinado momento somente uma vers\u00e3o do aplicativo esteja ativa. <\/p>\n

O mecanismo de implanta\u00e7\u00e3o blue\/green funciona da seguinte forma. Recebemos o tr\u00e1fego para nossos aplicativos atrav\u00e9s do ha-proxy, que o direciona para as r\u00e9plicas em execu\u00e7\u00e3o da mesma vers\u00e3o do aplicativo. <\/p>\n

Quando uma nova implanta\u00e7\u00e3o ocorre, usamos o Deployer, que recebe os novos componentes e realiza o deploy da nova vers\u00e3o. O deploy da nova vers\u00e3o do aplicativo significa que um novo conjunto de r\u00e9plicas \u00e9 'levantado', ap\u00f3s o que essas r\u00e9plicas da nova vers\u00e3o s\u00e3o iniciadas em um novo pod separado. No entanto, o ha-proxy n\u00e3o tem conhecimento delas e ainda n\u00e3o direciona nenhuma carga de trabalho para elas.<\/p>\n

Portanto, \u00e9 necess\u00e1rio primeiro realizar uma verifica\u00e7\u00e3o de opera\u00e7\u00e3o das novas vers\u00f5es por meio de health checking, para garantir que as r\u00e9plicas estejam prontas para lidar com a carga.<\/p>\n

\"DEVOXX
\n
\nTodos os componentes de implanta\u00e7\u00e3o devem suportar alguma forma de health check. Isso pode ser apenas uma verifica\u00e7\u00e3o simples de HTTP, onde voc\u00ea recebe um c\u00f3digo de status 200, ou uma verifica\u00e7\u00e3o mais profunda, na qual voc\u00ea verifica a conex\u00e3o das r\u00e9plicas com o banco de dados e outros servi\u00e7os, a resili\u00eancia das conex\u00f5es do ambiente din\u00e2mico, se tudo est\u00e1 sendo iniciado e funcionando corretamente. Esse processo pode ser bastante complexo. <\/p>\n

\"DEVOXX
\n
\nDepois que o sistema confirmar a opera\u00e7\u00e3o de todas as r\u00e9plicas atualizadas, o Deployer atualizar\u00e1 a configura\u00e7\u00e3o e transmitir\u00e1 o confd correto, que reconfigurar\u00e1 o ha-proxy. <\/p>\n

\"DEVOXX
\n
\nSomente depois disso o tr\u00e1fego ser\u00e1 direcionado para o pod com as r\u00e9plicas da nova vers\u00e3o, enquanto o pod antigo desaparecer\u00e1. <\/p>\n

\"DEVOXX
\n
\nEsse mecanismo n\u00e3o \u00e9 uma caracter\u00edstica do Kubernetes. O conceito de Blue\/green deployment existe h\u00e1 bastante tempo e sempre utilizou um balanceador de carga. Primeiro, voc\u00ea direciona todo o tr\u00e1fego para a vers\u00e3o antiga do aplicativo e, ap\u00f3s a atualiza\u00e7\u00e3o, migra totalmente para a nova vers\u00e3o. Esse princ\u00edpio \u00e9 usado n\u00e3o apenas no Kubernetes.<\/p>\n

Agora, vou apresentar a voc\u00eas um novo componente de implanta\u00e7\u00e3o \u2013 o Deployer, que realiza verifica\u00e7\u00f5es de opera\u00e7\u00e3o, reconfigura o proxy e assim por diante. Este \u00e9 um conceito que n\u00e3o diz respeito ao mundo externo e existe dentro do Kubernetes. Vou mostrar como criar seu pr\u00f3prio conceito de Deployer usando ferramentas open-source. <\/p>\n

Ent\u00e3o, a primeira coisa que o Deployer faz \u00e9 criar um controlador de replica\u00e7\u00e3o RC usando a API do Kubernetes. Essa API cria pods e servi\u00e7os para o pr\u00f3ximo desdobramento, ou seja, cria um cluster totalmente novo para nossos aplicativos. Assim que o RC confirma que as r\u00e9plicas foram iniciadas, ele realiza um teste de sa\u00fade (Health check). Para isso, o Deployer utiliza o comando GET \/health. Este comando ativa os componentes de verifica\u00e7\u00e3o correspondentes e verifica todos os elementos necess\u00e1rios para o funcionamento do cluster. <\/p>\n

\"DEVOXX
\n
\nDepois que todos os pods reportam sua 'sa\u00fade', o Deployer cria um novo item de configura\u00e7\u00e3o \u2013 um armazenamento distribu\u00eddo etcd, usado internamente pelo Kubernetes, incluindo para o armazenamento da configura\u00e7\u00e3o do balanceador de carga. Gravamos os dados no etcd, e uma pequena ferramenta chamada confd monitora o etcd para detectar novos dados. <\/p>\n

Se detectar alguma altera\u00e7\u00e3o na configura\u00e7\u00e3o original, ele gera um novo arquivo de configura\u00e7\u00f5es e o envia para o ha-proxy. Nesse caso, o ha-proxy reinicia sem perder qualquer conex\u00e3o e direciona a carga para os novos services que garantem o funcionamento da nova vers\u00e3o dos nossos aplicativos. <\/p>\n

\"DEVOXX
\n
\nComo voc\u00ea pode ver, apesar da variedade de componentes, n\u00e3o h\u00e1 nada complicado aqui. Voc\u00ea s\u00f3 precisa prestar mais aten\u00e7\u00e3o \u00e0 API e ao etcd. Quero falar sobre um deploier open-source que usamos \u2013 o Amdatu Kubernetes Deployer.<\/p>\n

\"DEVOXX
\n
\nEsse \u00e9 um instrumento para orquestra\u00e7\u00e3o de desdobramentos do Kubernetes, com as seguintes funcionalidades: <\/p>\n