Proponho me familiarizar com a decodificação do relatório de Denis Yakovlev "Automação de infraestrutura. Por que estamos fazendo isso?"
O próprio relatório de 2016. O relatório foi especialmente descriptografado para quem cria máquinas virtuais com as mãos.
Relate como nós, no 2GIS, automatizamos o trabalho com infraestrutura.
“Você precisa correr o mais rápido possível para permanecer no lugar, mas para chegar a algum lugar, você deve correr pelo menos duas vezes mais rápido” (Alice no país das maravilhas).
O que essa frase significa para nós? Em um ambiente altamente competitivo, as empresas devem se esforçar para entregar seus produtos aos usuários o mais rápido possível. Diminuir o tempo de colocação no mercado é uma tarefa em vários níveis. Para resolvê-lo, você precisa alterar os processos e as ferramentas de desenvolvimento. Uma base importante para todo o processo de desenvolvimento é a infraestrutura. Quanto maior a infraestrutura, maiores problemas, casos de uso etc. Se todas as operações com ele não forem automatizadas, o número de problemas aumentará. Um deles é o tempo que um desenvolvedor gasta em questões de infraestrutura em vez de escrever a lógica de negócios.
Vamos falar sobre:
- Quais problemas de infraestrutura enfrentaram as equipes;
- Como os processos de desenvolvimento e teste sofreram com isso;
- Como implementamos o OpenStack;
- Quais são os nossos cenários para usar o OpenStack;
- Como a automação recebeu um impulso adicional no desenvolvimento e novos produtos internos começaram a aparecer;
- Quais aspectos que nos restam não são automatizados.
Sobre mim. Empresa 2GIS. Eu trabalho na empresa há dois anos.
Equipe de Infraestrutura e Operações. Damos suporte principalmente à infraestrutura interna do departamento da Web. Recentemente, outras equipes internas de produtos se juntaram a nós. Também somos responsáveis pela operação dos produtos web da empresa em produção. E também estamos pesquisando e desenvolvendo novas ferramentas para facilitar nossa vida e melhorar a vida de nossos amados desenvolvedores. Existem apenas 9 de nós.
Primeiro entendemos a infraestrutura. Por que estamos falando dela? O que é isso Quando começamos a falar sobre ela?
Desde os primeiros momentos de trabalho no produto e em algum projeto, temos uma pergunta - onde vamos implantar? onde verificar os resultados? onde testar e assim por diante.
Imediatamente a primeira resposta é local. Localmente porque é muito simples. Desenvolvido em seu laptop, lançado, verificado - está tudo bem. Você fica pensando - por que verificar além do seu laptop? Tudo funciona para mim.
E se tivermos um sistema operacional no laptop e outro estiver girando na produção? Ou nosso produto deve oferecer suporte a vários sistemas operacionais?
O caso não é coberto. Ou seja, diferentes sistemas operacionais.
Se tivermos a oportunidade e tomarmos uma decisão com muita força de vontade - temos Linux em todos os lugares. Por exemplo, alguns Ubuntu. O resto é todo do maligno. Parece-nos que resolvemos todos os nossos problemas.
Mas simplesmente combinar o sistema operacional não é suficiente. Precisamos de pacotes de uma determinada versão.
pensamos em como resolver esse problema. E lembre-se - nós temos isolamento. Coisas muito altas. Graças a Deus existem tantos produtos no mercado. Tomamos o VirtualBox. Crie uma máquina virtual. Nós lançamos nosso produto. Fazemos instantâneos. Temos o meio ambiente.
Estamos desenvolvendo. Nosso produto está ficando mais difícil. Este não é mais apenas um aplicativo de banco de dados php. O aplicativo cresceu para um sistema distribuído. Temos outros produtos chegando.
A empresa está se desenvolvendo. E temos novos casos de uso. Todos esses produtos desejam integrar, para poderem trabalhar juntos. Temos recursos que passam por vários produtos. Somos constantemente solicitados a mostrar o que você desenvolveu. Vamos vê-lo em algum lugar. Não temos mais recursos para testes manuais. Lembramos que há integração contínua, autoteste. Para fazer isso, você precisa de um software adicional. O ambiente local dos EUA, mesmo com todo o isolamento, não é mais suficiente. É aqui que a infraestrutura entra. Precisamos de um local onde possamos implantar nossos produtos e mostrar a alguém os resultados. De alguma forma, precisamos gerenciar tudo isso e deve ser conveniente.
Vamos olhar para a nossa empresa 2GIS.
Este é um guia e mapas. Você pode olhar para o mapa da cidade, procurar organizações.
Temos: produtos da web, móveis, aplicativos de desktop. Existem cerca de 35 equipes diferentes de tamanhos diferentes.
Que problemas tivemos com a infraestrutura? No final de 2013, usamos proxmox. Este é um sistema de gerenciamento de virtualização. Utilizando-o, você pode criar máquinas virtuais KVM ou contêineres OpenVZ. Mas tudo isso é feito manualmente através de interfaces. Para o pleno funcionamento, você ainda precisa entrar na máquina virtual e configurar a rede, dns.
Portanto, por algum tempo, o fluxo de nosso desenvolvimento ficou como segue. Como desenvolvedor, estou procurando administradores de tíquetes. Os administradores, quando têm tempo, criam uma máquina virtual. Eles fornecem um endereço IP, login, senha. Mas se eu precisar reimplementar esta máquina virtual, vou novamente para os administradores que já me olham com suspeita. Eles dizem - um cara, tanto quanto possível?
Não houve separação de projetos. Havia um conjunto de máquinas virtuais em vários servidores, onde os administradores criavam tudo com as mãos. Havia uma alta probabilidade de erro humano. Você pode confundir o endereço IP ou excluir a máquina virtual errada. Muitos, muitos casos assim. E a responsabilidade pela máquina virtual é incompreensível. Os desenvolvedores não assumem responsabilidade, os administradores também não tomam banho de vapor. Não está claro que alguém precise de uma máquina virtual ou que todo mundo a tenha esquecido e não saiba.
Além disso, há uma API fraca. Os plugins são pagos ou perl.
Mas, além dos problemas, tínhamos algo mais útil. Tínhamos nosso próprio ferro, no qual tudo isso estava girando. Nossos administradores de sistema são ótimos companheiros, sabem cozinhar esse ferro, cuidar dele e comprá-lo corretamente. E eles tiveram alguma experiência com virtualização.
Começamos a pensar: que solução nos conviria? Como deve ser nossa infraestrutura para não interferir no processo de desenvolvimento, mas ajudar?
Obtivemos a seguinte lista de requisitos como resultado do estudo:
Utilização eficaz de ferro. Não queremos ter máquinas virtuais órfãs. Não queremos apenas aquecer o ar no data center.
Queremos ter recursos de equipe para que a equipe assuma a responsabilidade pelos recursos que usa. E ela estava atenta a eles.
Queremos que a solução seja modular, escolha apenas os serviços de que precisamos. E em caso de necessidade, com maior desenvolvimento, será capaz de expandir.
A solução deve ser finalizada facilmente. Se novos requisitos aparecerem, poderemos refinar a solução para nossas necessidades específicas.
Não precisamos apenas de uma interface com o usuário, precisamos de uma API para gravar nossas ligações e gerenciar a infraestrutura.
Queremos isolar as equipes, e especialmente a equipe de teste de carga. Eu queria que ela não perturbasse o resto.
Quais foram as nossas opções?
Observamos a nuvem pública: AWS e muito mais. A opção é atraente, pois eles enfrentam quase todos os problemas relacionados à infraestrutura. Era possível levar e pagar muito dinheiro para essas empresas famosas, mas estávamos constrangidos pela situação repugnante com o dólar (ou sanções). Eu realmente não queria bloquear nenhum fornecedor. A terceira opção, na qual analisamos o que temos no mercado de código aberto? Quais soluções são oferecidas? Temos nosso próprio hardware, resta escolher algo entre esses muitos aplicativos de código aberto.
Então, no final, nossas pesquisas e experimentos nos levaram a um software chamado OpenStack. Softinke, claro, parece muito rude.
O OpenStack é um software completo, de fato, é um conjunto de serviços para a construção de uma nuvem pública ou privada. O OpenStack é uma solução de código aberto. Todos os serviços são escritos em python. Cada serviço é responsável por sua tarefa, possui sua própria API.
E parece assim. Lembre-se desta imagem. Então vamos voltar para ela. Existem serviços compartilhados (gerais). Existem serviços para esse fim: computação, rede, armazenamento. E nosso aplicativo ou usuário trabalha com esses serviços.
Solução de código aberto. O lançamento ocorre meio ano. O lançamento inclui componentes básicos. Cada versão inclui novos componentes que aparecem inicialmente nesta incubadora. Eles passam algum tempo lá, corrigem bugs, estabilizam e assim por diante. E em algum momento, a comunidade decide que esse componente deve ser incluído nos componentes básicos a partir do próximo release. Há também muitas correspondências, reuniões e conferências diferentes. A maior conferência é a OpenStack Summit. Realizado todos os anos. E na última cúpula do OpenStack, havia cerca de quatro ou cinco mil participantes. Um evento tão grande. Muitos relatórios.
Muitas pessoas estão contribuindo para essa decisão. Aqui dei apenas uma lista desses tops. Essa lista é suficiente para entender a seriedade do projeto e quais empresas e quantos recursos investem nele.
Como resolvemos nossos problemas de infraestrutura.
- Um dos componentes do OpenStack é o planejador, que seleciona o host no qual a máquina virtual será criada.
- A equipe agora tem seus próprios recursos. Essa é a quantidade de CPU, memória e muito mais. Nós nos livramos desse cenário para criar um virtual no tiket (aplicativo).
- OpenStack é um conjunto de serviços que é. Pegamos apenas o kit básico que fornecia nossas necessidades.
- Como o OpenStack é de código aberto, é possível modificá-lo.
- Cada serviço tem uma API. Existem compilações python. Ou seja, é bastante simples interagir com cada serviço e escrever suas próprias ligações.
- Isolamento. Podemos isolar equipes para nós em projetos, zonas de agregação, redes e assim por diante.
Os desenvolvedores da equipe receberam a infraestrutura como serviço. Como é isso?
Existem dois conceitos de pilha e modelo. Stack é um conjunto de recursos de nuvem: máquinas virtuais, rede, registros DNS e muito mais. Um modelo é uma descrição dessa pilha. No caso do OpenStack, este é um arquivo YAML comum. Aqui está parte do arquivo. Ele diz que existe uma entidade como um servidor com um servidor OS Nova do tipo interno. Para sua operação normal, você precisa de um endereço IP e um registro DNS. Aqui, os parâmetros de nome são aceitos como entrada, sabor é uma descrição dos recursos que este servidor precisa. Sistema operacional da imagem. key_name - qual chave pública colocar ao implantar o servidor. Temos todos esses modelos no repositório de cada um no git. Todo mundo tem acesso. Todos podem enviar uma solicitação de recebimento.
E a criação do Stack é a seguinte. Heat é o componente OpenStack responsável pela orquestração. Dizemos isso neste contexto. Este é um ótimo utilitário que instalamos para nós mesmos. Dizemos muito calor, crie uma pilha com esse nome, aqui está uma descrição dos recursos que precisamos para criar essa pilha. E aqui está a entrada que nosso modelo exige, que descreve nossa pilha. Nós carregamos no calor. Ele mexe lá por um tempo, cria todos os recursos necessários para nós dentro de si. E também neste modelo aqui podemos especificar a saída. Quando o Heat criou o Stack, ele pode gerar informações: endereço IP, acesso e o restante que pedimos. Além disso, já podemos aplicar essas informações para automação adicional.
Para que você não pense que o OpenStack é simples e barato, eu lhe direi para qual hardware o OpenStack funciona. O painel de controle gira em 3 infra-nós. Estes são servidores de ferro com esses recursos. Esta é a configuração recomendada para failover.
Também temos dois nós de rede KVM que atendem nossa rede.
Recursos da equipe, giramos em 8 nós de computação. Eles são divididos em 3 zonas de agregação. Um nó de computação é alocado por zona para teste de carga. Lá, os servidores são criados apenas a partir da equipe de teste de carga. Para não interferir com o resto. Temos uma zona de agregação para nosso projeto de automação de teste de GUI interno. Ele tem certos requisitos. Está localizado em uma zona de agregação separada. Todo o restante de nossos ambientes de desenvolvimento, servidores e ambientes de teste estão girando na terceira grande zona de agregação. São necessários 6 nós de computação.
Giramos cerca de 350 máquinas virtuais para todas as equipes.
O que entendemos quando já tínhamos ido de alguma maneira. Para implantar e dar suporte a esse software, você precisa de uma equipe. Equipe dependendo de seus recursos.
As equipes devem ter certas competências.
Primeiro de tudo, é naturalmente Ansible. A implantação do OpenStack é escrita em Ansible. Existe um projeto OpenStack-Ansible . Se você deseja adicionar o OpenStack-Ansible às suas necessidades, as pessoas que farão isso precisam possuir o Ansible.
Experiência de virtualização. Você precisa ser capaz de cozinhar a virtualização, precisa ajustar. Entenda como isso funciona.
A mesma rede.
O mesmo vale para os serviços de back-end que o OpenStack usa para seu trabalho. Este banco de dados é MySQL Galera e RabbitMQ como uma fila.
Compreendendo como o DNS funciona. Como configurá-lo.
O OpenStack é escrito em python. Você deve poder ler o código. Idealmente, você precisa ser capaz de corrigir. Pesquisar correções da comunidade. Ser capaz de estrear o código. Tudo isso é muito útil. Se uma equipe tem essa abordagem, sabe como usar uma abordagem como Infraestrutura como código, como ansible, por exemplo, todas as alterações são armazenadas no código, elas não terão problemas ao configurar mãos.
Integração contínua. O conjunto de serviços OpenStack inclui um serviço como tempest . Nele, todos os testes são escritos em todos os componentes. Se alterarmos a configuração, execute um diploma separado na instalação da Multifuncional e execute tempest - procuramos ver se algo caiu conosco. O IC está configurado e a equipe deve entender isso e deve poder configurar tudo isso.
Porque tudo parece simples e atraente dado.
Mas quando você começa a se aprofundar mais, entende que, de fato, tudo se parece com isso. Isso pode ser uma surpresa para alguém.
A introdução do OpenStack não é apenas uma solução técnica. Além disso, você precisa poder vender, explicar às equipes o novo paradigma de como elas agora funcionam, quais benefícios ela traz. Como trabalhar com ele para obter lucro. Escrevemos muita documentação. A documentação está no formato início rápido (início rápido), primeiros passos (primeiros passos). Ou seja, o que precisa ser feito para facilitar rapidamente sua vida e não gastar muito tempo nela.
Conduzimos o TechTalk, conversamos, criamos tópicos, mostramos, conversamos, agora veja agora você pode obter seu produto da seguinte maneira. literalmente, aqui estamos escrevendo um modelo, estamos lançando-o. Tudo é bem simples. Agora você não precisa procurar os administradores e pedir alguma coisa por lá.
Em casos especialmente difíceis, quando o projeto é complexo, há muitos casos, chegamos às equipes, trabalhamos diretamente com as equipes. Ou seja, eles de alguma forma tentaram ajudá-los na automação de processos. Configure todas as equipes. Acabou com alguns insetos. Eles entenderam que não configuramos algo errado lá. Em geral, trabalho duro com equipes.
Recebemos uma rápida implantação de produtos. Anteriormente, para receber produtos, era necessário realizar muitas ações manuais, interagir com muitas pessoas. Agora temos a criação de Envinronment (Ambiente, servidor) por botão. E se o deploy for gravado e funcionar para o projeto, seremos implantados pelo botão ou pelo novo Envinronment (Ambiente, servidores) com o produto instalado.
A falta de uma infraestrutura normal foi um bloqueador para algumas equipes em termos de implementação do processo de IC dentro da equipe. Resolvemos os problemas de infraestrutura, as equipes criadas no servidor de CI, configuramos o pipeline, as máquinas virtuais são criadas no pipeline. Em geral, eles deram um impulso ao desenvolvimento desses processos.
Eles também ajudaram alguns produtos internos que usam a infraestrutura para automatizar os testes. O VM Master é um produto que testa nosso online. Ele precisa criar muitas máquinas virtuais para entrar no site a partir de diferentes navegadores, seguir algumas etapas para entender que o online funciona em todos os navegadores conhecidos. Ou seja, eles o ajudaram muito.
Um bom bônus é que eles descarregaram os administradores (eles mesmos). Porque, em algum momento, a atividade de criar uma máquina virtual começou a ocupar espaço no tempo. E todo mundo começou a ficar nervoso. Agora estamos fazendo coisas interessantes, produtos complexos. Nos livramos da tarefa de rotina.
Perguntas?
Pergunta: Quanto tempo levou para implantar o OpenStack?
Resposta: A pergunta é complicada porque tivemos um processo que pode acomodar uma série de comédia. Ele tem um alto limiar de entrada. Compreendemos toda a nossa infraestrutura, procuramos uma solução - levou três meses. Em um mês, lançamos a primeira instalação em algum lugar. Adicionamos alguns projetos lá. Eles moravam lá. Então o fator humano aconteceu - eles atiraram na cabeça desta instalação. Percebemos que a falta de tolerância a falhas é ruim. Então esperamos pelo ferro.
Pergunta: Você usa suporte pago?
Resposta: não, não usamos.
Pergunta: Qual versão do OpenStack você está usando?
Resposta: As versões do OpenStack são chamadas de palavras. Primeiro foi Juno, depois atualizamos para o Liberty.
Pergunta: As máquinas virtuais são criadas no pipeline Integração contínua?
Resposta: Construir em Jenkins pode causar calor e criar uma máquina virtual.
Pergunta: Você encontrou problemas com o compartilhamento de recursos? Grosso modo, 2 máquinas virtuais estão no mesmo servidor físico. Um deles começa a carregar um disco, por exemplo, um banco de dados. Se enfrentou, como você decidiu?
Resposta: Não encontramos problemas com o compartilhamento de recursos. Os produtos um do outro não interferem muito. Organizamos os scripts. Se você precisar executar um cenário pesado, execute testes de carga, precisará ir para a equipe de teste de carga e eles executarão o teste de carga.
: - ?
: OpenStack . . . .
: . . OpenStack ?
: . OpenStack . .
: OpenStack?
: . proxmox. OpenStack.
: DevOps?
: DevOps , . , , .
PS 2019 OpenStack heat Terraform .