{"id":38075,"date":"2019-10-31T22:21:32","date_gmt":"2019-10-31T19:21:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-blagodarya-kubernetes-i-avtomatizatsii-migrirovat-v-oblako-za-dva-chasa\/"},"modified":"2019-10-31T22:21:32","modified_gmt":"2019-10-31T19:21:32","slug":"kak-blagodarya-kubernetes-i-avtomatizatsii-migrirovat-v-oblako-za-dva-chasa","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/kak-blagodarya-kubernetes-i-avtomatizatsii-migrirovat-v-oblako-za-dva-chasa","title":{"rendered":"How to migrate to the cloud in two hours using Kubernetes and automation","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"How
\n
\nA empresa \u00ab\u0423\u0420\u0423\u0421\u00bb testou o Kubernetes de v\u00e1rias maneiras: implanta\u00e7\u00e3o aut\u00f4noma em bare metal, no Google Cloud, e depois transferiu sua plataforma para a nuvem Mail.ru Cloud Solutions (MCS). Igor Shishkin,t3ran<\/a><\/noindex>, administrador de sistemas s\u00eanior da \u00ab\u0423\u0420\u0423\u0421\u00bb.
\n<\/a><\/noindex><\/p>\n

O que faz a \u00ab\u0423\u0420\u0423\u0421\u00bb <\/h2>\n

\nExistem muitas maneiras de melhorar a qualidade do ambiente urbano, e uma delas \u00e9 torn\u00e1-lo ecologicamente seguro. Este \u00e9 precisamente o trabalho da empresa \u00ab\u0423\u0420\u0423\u0421 \u2014 Servi\u00e7os Digitais Inteligentes\u00bb. Aqui, s\u00e3o implementadas solu\u00e7\u00f5es que ajudam as empresas a monitorar importantes indicadores ambientais e a reduzir o impacto negativo no meio ambiente. Sensores coletam dados sobre a composi\u00e7\u00e3o do ar, n\u00edvel de ru\u00eddo e outros par\u00e2metros, e, em seguida, enviam essas informa\u00e7\u00f5es para a plataforma unificada \u00ab\u0423\u0420\u0423\u0421 \u2014 \u042d\u043a\u043e\u043c\u043e\u043d\u00bb para an\u00e1lise e formula\u00e7\u00e3o de recomenda\u00e7\u00f5es. <\/p>\n

Como funciona a \u00ab\u0423\u0420\u0423\u0421\u00bb internamente<\/h2>\n

\nO cliente t\u00edpico da \u00ab\u0423\u0420\u0423\u0421\u00bb \u00e9 uma empresa localizada em uma \u00e1rea residencial ou pr\u00f3xima a ela. Isso pode ser uma f\u00e1brica, porto, dep\u00f3sito ferrovi\u00e1rio ou qualquer outro objeto. Se nosso cliente j\u00e1 recebeu um aviso, foi multado por polui\u00e7\u00e3o ou deseja emitir menos ru\u00eddo e reduzir o n\u00famero de emiss\u00f5es nocivas, ele vem at\u00e9 n\u00f3s, e oferecemos uma solu\u00e7\u00e3o pronta para monitoramento ambiental.<\/p>\n

\"How
\nNo gr\u00e1fico de monitoramento da concentra\u00e7\u00e3o de H2S, s\u00e3o vis\u00edveis as emiss\u00f5es regulares noturnas de uma empresa pr\u00f3xima.<\/i><\/p>\n

Os dispositivos que usamos na \u00ab\u0423\u0420\u0423\u0421\u00bb cont\u00eam v\u00e1rios sensores que coletam informa\u00e7\u00f5es sobre a presen\u00e7a de certos gases, n\u00edvel de ru\u00eddo e outros dados para avaliar a situa\u00e7\u00e3o ambiental. O n\u00famero exato de sensores \u00e9 sempre determinado pela tarefa espec\u00edfica.<\/p>\n

\"How
\nDependendo da especificidade das medi\u00e7\u00f5es, os dispositivos com sensores podem ser instalados nas paredes dos edif\u00edcios, postes e em outros locais arbitr\u00e1rios. Cada dispositivo coleta informa\u00e7\u00f5es, agrega os dados e envia para um gateway de recep\u00e7\u00e3o. L\u00e1, armazenamos os dados para armazenamento a longo prazo e os processamos para an\u00e1lise posterior. Um exemplo simples do que obtemos ap\u00f3s a an\u00e1lise \u00e9 o \u00edndice de qualidade do ar, tamb\u00e9m conhecido como AQI.<\/p>\n

Paralelamente, muitos outros servi\u00e7os operam em nossa plataforma, mas em sua maioria eles t\u00eam um car\u00e1ter de suporte. Por exemplo, o servi\u00e7o de notifica\u00e7\u00e3o envia alertas aos clientes se algum dos par\u00e2metros monitorados (como o n\u00edvel de CO2) ultrapassar o valor permitido.<\/p>\n

Como armazenamos dados. A hist\u00f3ria com Kubernetes em bare metal<\/h2>\n

\nNo projeto de ecomonitoramento \u00abURUS\u00bb, existem v\u00e1rios reposit\u00f3rios de dados. Em um, armazenamos dados 'brutos' - aquilo que recebemos diretamente dos dispositivos. Este reposit\u00f3rio \u00e9 como uma 'fita magn\u00e9tica', como as antigas fitas cassete, com o hist\u00f3rico de todas as medi\u00e7\u00f5es. O segundo tipo de reposit\u00f3rio \u00e9 utilizado para dados pr\u00e9-processados \u2014 dados dos dispositivos enriquecidos com metadados sobre as conex\u00f5es dos sensores e as leituras dos dispositivos, pertencentes a organiza\u00e7\u00f5es, locais, etc. Essas informa\u00e7\u00f5es permitem avaliar dinamicamente como um determinado indicador mudou ao longo de um determinado per\u00edodo de tempo. Usamos o reposit\u00f3rio de dados 'brutos' tamb\u00e9m como backup e para recuperar dados pr\u00e9-processados, se necess\u00e1rio.<\/p>\n

Quando, h\u00e1 alguns anos, est\u00e1vamos procurando como resolver o problema de armazenamento, t\u00ednhamos duas op\u00e7\u00f5es para escolher a plataforma: Kubernetes e OpenStack. Mas como a \u00faltima parece bastante monstruosa (basta olhar sua arquitetura para se certificar disso), decidimos ficar com o Kubernetes. Outro argumento a seu favor foi a ger\u00eancia program\u00e1tica relativamente simples e a possibilidade de distribuir de forma mais flex\u00edvel at\u00e9 mesmo os n\u00f3s f\u00edsicos em recursos. <\/p>\n

Paralelamente ao dom\u00ednio do pr\u00f3prio Kubernetes, estudamos tamb\u00e9m maneiras de armazenar dados, enquanto mantivemos todos os nossos reposit\u00f3rios no Kubernetes em nosso hardware, adquirimos uma excelente expertise. Tudo o que t\u00ednhamos na \u00e9poca vivia justamente no Kubernetes: armazenamento stateful, sistema de monitoramento, CI\/CD. O Kubernetes se tornou para n\u00f3s uma plataforma all-in-one. <\/p>\n

Mas n\u00f3s quer\u00edamos trabalhar com Kubernetes como um servi\u00e7o, em vez de nos ocuparmos com sua manuten\u00e7\u00e3o e desenvolvimento. Al\u00e9m disso, n\u00e3o gost\u00e1vamos do custo associado \u00e0 sua manuten\u00e7\u00e3o em bare metal, e o desenvolvimento era uma constante necessidade! Por exemplo, uma das primeiras tarefas foi integrar os controladores Ingress do Kubernetes na infraestrutura de rede da nossa organiza\u00e7\u00e3o. Essa \u00e9 uma tarefa complexa, especialmente se considerarmos que, naquela \u00e9poca, nada estava pronto para a gest\u00e3o program\u00e1tica de recursos como registros DNS ou aloca\u00e7\u00e3o. endere\u00e7os IP<\/a>Mais tarde, come\u00e7amos a experimentar armazenamento externo de dados. N\u00e3o chegamos a implementar o controlador PVC, mas naquela \u00e9poca j\u00e1 estava claro que era um grande projeto que exigiria profissionais dedicados.<\/p>\n

A transi\u00e7\u00e3o para o Google Cloud Platform - uma solu\u00e7\u00e3o tempor\u00e1ria.<\/h2>\n

\nPercebemos que n\u00e3o pod\u00edamos continuar assim e migramos nossos dados de bare metal para o Google Cloud Platform. Na verdade, naquela \u00e9poca, para uma empresa russa, n\u00e3o havia muitas op\u00e7\u00f5es interessantes: al\u00e9m do Google Cloud Platform, apenas a Amazon oferecia um servi\u00e7o semelhante, mas ainda assim optamos pela solu\u00e7\u00e3o do Google. Para n\u00f3s, parecia mais economicamente vantajoso, mais pr\u00f3ximo do Upstream, sem mencionar que o Google em si \u00e9 uma esp\u00e9cie de PoC do Kubernetes em produ\u00e7\u00e3o.<\/p>\n

O primeiro grande problema surgiu junto com o crescimento da nossa base de clientes. Quando surgiu a necessidade de armazenar dados pessoais, nos deparamos com a escolha: ou trabalhamos com o Google e violamos as leis russas, ou buscamos uma alternativa na R\u00fassia. A escolha, em geral, era previs\u00edvel. \ud83d\ude42<\/p>\n

Como imagin\u00e1vamos o servi\u00e7o de nuvem ideal<\/h2>\n

\nNo in\u00edcio das nossas buscas, j\u00e1 sab\u00edamos o que quer\u00edamos do futuro provedor de nuvem. Que tipo de servi\u00e7o procur\u00e1vamos:<\/p>\n