Get best of the week

Portal de ambientes de teste ou salve nossos devops



Há alguns anos, nos sentimos em algum tipo de sonho surreal. Todos ao redor foram à nuvem para testes (é conveniente expandir e contrair ambientes de teste) e tentamos descobrir quais ferramentas prontas para uso devem ser entregues. Para fazer isso, nós, juntamente com os clientes, descobrimos como os processos dos devops funcionam. E aconteceu que apenas algumas empresas na Rússia usam a automação com competência.

Explicarei imediatamente que, na maior parte do tempo, conversamos com aqueles que estão envolvidos no desenvolvimento de até 150 a 200 pessoas na empresa ou com setores onde a TI é tradicionalmente difícil. As empresas maiores geralmente têm um processo e sua própria nuvem e vêm até nós para implantação de backup.

A produção é geralmente bem estabelecida. Há um ciclo, plano de lançamento, há um objetivo, o código vai para o objetivo junto com os desenvolvedores.

Testes e controle de qualidade também são bem depurados com mais frequência.

E entre eles existe um abismo. E o DevOps está tentando preenchê-lo. Esse super-homem deve fazer o lançamento (e, idealmente, montá-lo no Jenkins ou algo semelhante), criar um carro, distribuir tudo lá, verificar o trabalho, talvez passar alguns pré-testes e entregá-lo ao controle de qualidade.

Qual é o problema?


Quando um produto é um tipo pequeno de aplicativo da Web, não há problema. Diretamente, o desenvolvedor ou testador pega o banco de dados do backup, conecta-se à versão mais recente e executa.

Mas quando o produto cresce um pouco, o colapso da produção se instala.

Devops conseguiu o lançamento, mas ele aceitou e não pretendia. Então ele começa a procurar o extremo e a resolver os desenvolvedores. Uma versão pode ser coletada por várias horas à noite, e os desenvolvedores geralmente ficam no escritório durante o dia.

Quase tudo é feito à mão. Ou seja, as operações estão sentadas e olhando para a barra de progresso da montagem. Porque qualquer lugar pode dar errado. Aqueles que são mais enérgicos vinculam tudo isso a seus próprios roteiros, e às vezes acaba sendo muito bonito e eficiente. Porém, mais frequentemente, vemos que o plano de entrega de liberação é executado em etapas, uma pessoa separada é responsável por cada etapa e é mais fácil repetir o procedimento vinte vezes com as mãos, porque, caso contrário, acontece que não funciona.

Ao mesmo tempo, alguém deve ser responsável pelo processo como um todo, e esse é o principal fator de parada. Uma tentativa de encontrar essa pessoa geralmente termina em fracasso. Ou seja, ele é responsável pela automação e é ele quem está interessado nela. Responsável por seções individuais e depois transferir as setas para alguém em desenvolvimento, é claro, é sempre mais fácil.

A virtualização adiciona mais aspectos do caos. Os ambientes virtuais são sempre uma bagunça. A pessoa responsável pelo agrupamento (servidor, rack), está mal orientada, a quem pertence, se é necessário ou não. É lógico que o administrador do sistema não precise se preocupar muito com o que está acontecendo com os desenvolvedores. Mas os devops deveriam, mas seu papel geralmente não implica esse conhecimento. E ele tem medo de desligar o excesso, porque ele não entende se será necessário ainda ou não.

É necessário emitir contas internas para os acordos mútuos dos departamentos. Alguém considera o tempo de atividade, alguém considera o uso do processador e, em seguida, eles compartilham igualmente ou em algumas proporções os custos como eletricidade e o trabalho dos administradores.

Inesperadamente, mas nenhum produto acabado


Parece que todo este transportador deve ser coberto com algum tipo de produto. Existem muitas boas soluções pontuais. O mesmo Ansible é implantado perfeitamente, mas não sabe como orientar máquinas virtuais. E os hipervisores podem. Existem todas as ferramentas para devops-scripting, você pode conectar os módulos ... Você só precisa pegar e montar a partir dessa cadeia de software, certo?

Não por aqui. Bancos e empresas estatais vieram com o desejo de testar na nuvem. Todo bom guarda de segurança é propenso à paranóia, geralmente por um bom motivo. Para o IB Bank, cada nova instalação é um fator muito irritante. Conheço um caso em que as operações arrastaram Jenkins e Terraform para a infraestrutura, implantaram o bash por trás dela e o DBMS que contém tudo isso. Acabou sendo um bom transportador semiautomático, que poderia ser finalizado até uma implantação totalmente autônoma. Somente para segurança da informação foi um desastre.

Eles queriam tudo em um. E para gerenciar a máquina virtual (e vários fornecedores, incluindo o Openstack). O Cliente em um aplicativo pode ter Vmvar e Hyper-in, e algo mais antigo e terrível para oferecer suporte ao FreeBSD ou OS / 2.

Precisamos da nossa bicicleta


Em geral, escrevemos nossa plataforma. Sob o capô - Ansible, fora da caixa - integração com Jenkins. Você pode escrever seus próprios scripts para o Ansible. Você pode fazer tudo, desde a coleção de sub-redes ao gerenciamento de liberações.



O portal vive no paradigma do ambiente de teste. Esta é a sua principal essência. Um ambiente de teste = uma sub-rede. Além disso, se for realmente ruim - há integração com o RPA, caso não exista API, e você precisa de um robô para imitar as ações do usuário e clicar nos botões da interface. Há cobrança, tempo de atividade e utilização são considerados do aplicativo para o aplicativo: até que a solicitação de destruição tenha sido gravada, o dinheiro vai pingar.

Isto é o que parece. Criando um ambiente usando um modelo:



Adicionando uma máquina virtual:



Script:



Como acabou um pouco mais tarde, as queixas de "não quero rodar em 50 sistemas" são ouvidas de todos os lados. Nós estávamos com uma dor importante. Qualquer grande cliente com teste queria algo semelhante, mas por algum motivo não o resolveu ou o resolveu organizacionalmente com as pessoas do script. Os problemas são muito diferentes, começando em computadores virtuais sem nome (eles o excluíram e então alguém lembrou que era necessário) e terminando com o fato de que ninguém quer ser responsável pelos scripts contínuos. Os scripts de roll-up são difíceis de escrever, os regulamentos também sofrem. Em algum lugar do ciclo, deve haver o anonimato dos dados, e parece que "em algum momento no início do ano, criamos um banco de dados anônimo", e o software mudou seis vezes, os dados foram atualizados.

Em geral, se algo parecido de repente o machuca, basta assistir. O acesso à demonstração está disponível na Technoserv Cloud .

More articles:


All Articles