ISPsystem, perdoe e adeus! Por que e como escrevemos nosso painel de controle do servidor

ISPsystem, perdoe e adeus! Por que e como escrevemos nosso painel de controle do servidor

Olá! Somos "Hosting Technologies" e lançados há 5 anos VDSina — a primeira hospedagem vds criada especificamente para desenvolvedores. Nós nos esforçamos para torná-lo conveniente, como o DigitalOcean, mas com suporte russo, métodos de pagamento e servidores na Rússia. Mas a DigitalOcean não é apenas confiabilidade e preço, é também um serviço.

O software do ISPsystem acabou sendo uma corda que amarrava nossas mãos no caminho para um serviço legal. Há três anos, usávamos o Billmanager billing e o painel de controle do servidor VMmanager e rapidamente percebemos que era quase impossível prestar um bom serviço sem um painel de controle próprio.

Como o ISPsystem matou a conveniência

Insetos

Não podíamos consertar o bug sozinhos - todas as vezes tínhamos que escrever para o suporte de outra pessoa e esperar. A solução de qualquer problema exigia a resposta de uma empresa terceirizada.

O suporte do sistema ISP respondeu normalmente, mas as correções vieram apenas após alguns lançamentos, e nem sempre e nem todas. Às vezes, bugs críticos foram corrigidos por várias semanas. Tivemos que tranquilizar os clientes, pedir desculpas e esperar que o ISPsystem consertasse o bug.

Ameaça de inatividade

As atualizações podem gerar paradas imprevisíveis que provocam novos erros.

Cada atualização era uma loteria: eu tinha que encobrir o faturamento e fazer sacrifícios aos deuses das atualizações - algumas vezes a atualização causava um tempo de inatividade de 10 a 15 minutos. Nossos administradores neste momento estavam sentados em seus olhos - nunca sabíamos quanto tempo duraria o tempo de inatividade e não podíamos prever quando o ISPsystem decidiria lançar uma nova atualização.

Na quinta geração o Billmanager ficou melhor, mas para ter acesso aos recursos necessários tive que instalar um beta, que já era atualizado toda semana. Se algo quebrasse, eu tinha que dar acesso a outros desenvolvedores para que eles consertassem alguma coisa.

Interface de painel inconveniente

Tudo foi dividido em diferentes painéis e controlado de diferentes lugares. Por exemplo, os clientes pagaram por meio do Billmanager e tiveram que reiniciar ou reinstalar o VDS no VMManager. Nossa equipe também tinha que alternar entre as janelas para ajudar um cliente, verificar a carga em seu servidor ou ver qual sistema operacional ele estava usando.

Essa interface leva tempo - tanto nosso quanto de nossos clientes. Não há dúvida de qualquer conveniência, como a da DigitalOcean, em tal situação.

Ciclos de vida curtos com atualizações frequentes de API

Escrevemos nossos próprios plugins - por exemplo, um plugin com métodos de pagamento adicionais que não estão no VMManager.

Nos últimos anos, o VMManager teve um ciclo de vida relativamente curto e, em novas versões, os nomes das variáveis ​​ou funções na API podiam mudar arbitrariamente - isso quebrou nossos plugins. O suporte para versões mais antigas foi rapidamente eliminado e teve que ser atualizado.

Não pode ser modificado

Mais precisamente, é possível, mas extremamente ineficiente. As restrições de licença não permitem que você faça alterações no código-fonte, você só pode escrever plugins. Máximo de plugins - alguns itens de menu, um assistente passo a passo. ISPsystem são projetados para versatilidade, mas precisávamos de soluções especializadas.

Portanto, a decisão de escrever meu próprio painel estava madura. Nós estabelecemos metas:

  • Responda rapidamente a erros, bugs e seja capaz de corrigi-los você mesmo sem fazer o cliente esperar.
  • Modifique livremente a interface para fluxos de trabalho e necessidades do cliente.
  • Aumente a usabilidade com um design limpo e compreensível.

E começamos o desenvolvimento.

Nova Arquitetura de Painel

Temos uma equipe de desenvolvimento autossuficiente, então nós mesmos escrevemos o painel.
O trabalho principal foi feito por três engenheiros - o diretor técnico Sergey criou a arquitetura e escreveu o agente do servidor, Alexey fez o faturamento e o front-end foi montado por nosso front-ender Artysh.

Passo 1: Agente do Servidor

O agente do servidor é um servidor web python que gerencia a biblioteca libvirt, que por sua vez rege Qemu-kvm hipervisor.

O agente gerencia todos os serviços no servidor: criar, interromper, excluir vds, instalar sistemas operacionais, alterar parâmetros e assim por diante por meio da biblioteca libvirt. No momento da publicação do artigo, são mais de quarenta funções diferentes, que complementamos dependendo da tarefa e das necessidades do cliente.

Em teoria, o libvirt poderia ser controlado diretamente do faturamento, mas isso exigia muito código adicional e decidimos separar essas funções entre o agente e o faturamento - o faturamento simplesmente faz solicitações ao agente por meio da API JSON.

O agente é a primeira coisa que fizemos, pois não exigia nenhuma interface e era possível testá-lo diretamente do console do servidor.

O que o agente do servidor nos deu: apareceu uma camada que simplifica a vida de todos - o faturamento não precisa enviar um monte de comandos, mas apenas fazer uma solicitação. E o agente fará tudo o que for necessário: por exemplo, alocará espaço em disco e RAM.

Etapa 2. Faturamento

Para nosso desenvolvedor Alex, este não foi o primeiro painel de controle - Alex está na hospedagem há muito tempo, então ele geralmente entendia o que o cliente precisava e o que o hoster precisava.

Chamamos o faturamento entre nós de “painel de controle”: ele contém não apenas dinheiro e serviços, mas também sua gestão, suporte ao cliente e muito mais.

Para mudar do software ISPSystem, era necessário preservar totalmente a funcionalidade anterior para os clientes, transferir todas as ações financeiras dos usuários do antigo faturamento para o novo, bem como todos os serviços e conexões entre eles. Estudamos o que está no produto atual, depois as soluções dos concorrentes, principalmente DO e Vultr. Analisamos as desvantagens e vantagens, coletamos feedback de pessoas que trabalharam com produtos antigos do ISPsystem.

O novo faturamento usou duas pilhas: PHP clássico, MySQL (e no futuro está planejado mudar para PostgreSQL), Yii2 como uma estrutura no back-end e VueJS na frente. As pilhas funcionam independentemente umas das outras, são desenvolvidas por pessoas diferentes e se comunicam usando a API JSON. Para o desenvolvimento, então e agora, usamos PHPStorm и tempestade da web da JetBrains e os amo muito (ei pessoal!)

O painel é projetado de forma modular: módulos de sistema de pagamento, módulo de registrador de domínio ou, por exemplo, um módulo de certificado SSL. Você pode facilmente adicionar um novo recurso ou remover um antigo. A base para a expansão é construída arquitetonicamente, inclusive na direção oposta, “em direção ao hardware”.
ISPsystem, perdoe e adeus! Por que e como escrevemos nosso painel de controle do servidor
O que temos: um painel de controle sobre o qual temos controle total. Agora os bugs são corrigidos em horas, não em semanas, e novos recursos são implementados a pedido dos clientes, e não a pedido do ISPSystem.

Passo 3 Interface

ISPsystem, perdoe e adeus! Por que e como escrevemos nosso painel de controle do servidor
A interface é uma criação da nossa equipe.

Primeiro, analisamos o que aconteceria se fizéssemos um complemento na API do sistema ISP sem alterar fundamentalmente nada na interface. Ficou mais ou menos e decidimos fazer tudo do zero.

Acreditamos que o principal é tornar a interface lógica, com um design limpo e minimalista, e assim obteremos um belo painel. A localização dos elementos foi discutida no Megaplan e a interface que os usuários veem no painel de controle agora vai nascer aos poucos.

O design da página de cobrança foi o primeiro a aparecer, pois já fizemos plugins de pagamento para ISPsystem.

A parte dianteira

Eles decidiram fazer do painel um aplicativo SPA - pouco exigente em recursos e com carregamento rápido de dados. Nosso front-ender Artysh decidiu escrevê-lo no Vue - naquela época, o Vue havia acabado de aparecer. Presumimos que o framework se desenvolveria dinamicamente, como o React, depois de algum tempo a comunidade Vue cresceria e um mar de bibliotecas apareceria. Apostamos no Vue e não nos arrependemos - agora leva pouco tempo para adicionar novas funções ao front que já foram programadas no back-end. Falaremos mais sobre o painel frontal em um artigo separado.

Conectando o front-end ao back-end

O front-end foi conectado ao back-end por meio de notificações push. Tive que trabalhar muito e escrever meu próprio manipulador, mas agora as informações na página são atualizadas quase instantaneamente.

O que aconteceu: A interface do painel ficou mais simples. Nós o tornamos adaptável, e o carregamento rápido permite que você o use até mesmo no celular nos últimos minutos antes da decolagem, sem instalar um aplicativo separado para trabalhar com o painel.

Etapa 4. Esquema de teste e migração

Quando tudo começou e os primeiros testes foram aprovados, surgiu a questão da migração. Em primeiro lugar, instalamos o billing e começamos a testar seu funcionamento com o agente servidor.

Em seguida, escrevemos um script simples que transfere o banco de dados do faturamento antigo para o novo.

Tive que testar e verificar novamente literalmente tudo, já que os dados foram mesclados em um novo banco de dados de três antigos: Billmanager, VMmanager e o IPmanager do gerente. Talvez as migrações de teste sejam a coisa mais difícil que encontramos no processo de desenvolvimento de um novo painel.

Depois de verificar novamente, fechamos o faturamento antigo. A migração final dos dados foi um momento muito conturbado, mas, graças a Deus, foi concluída em poucos minutos e sem problemas perceptíveis. Houve pequenos bugs que corrigimos durante a semana. A maior parte do tempo foi gasto testando o que aconteceu.

Em seguida, enviamos cartas aos clientes com o endereço do novo painel e cobrança e fizemos um redirecionamento.

Em resumo: ESTÁ VIVO!

Final feliz

Desde as primeiras horas de trabalho do nosso software, sentimos todas as delícias da transição. O código era totalmente nosso e com uma arquitetura conveniente, e a interface era limpa e lógica.
ISPsystem, perdoe e adeus! Por que e como escrevemos nosso painel de controle do servidor
Primeira revisão após o lançamento do novo painel

Lançamos o processo de transição em dezembro, na véspera do Ano Novo de 2017, quando a carga era menor, para facilitar a transição dos clientes - quase ninguém trabalha na véspera de feriados.

A principal coisa que obtivemos ao mudar para nosso sistema (além da confiabilidade e conveniência gerais) é a capacidade de adicionar funcionalidades rapidamente para os principais clientes - para ser a cara deles, não a bunda deles.

Qual é o próximo?

Estamos crescendo, a quantidade de dados, clientes, dados de clientes está crescendo. Tive que adicionar um servidor Memcached e dois gerenciadores de filas com tarefas diferentes ao back-end. O frontend possui cache e suas próprias filas.

Claro, ainda tivemos aventuras conforme o produto se desenvolveu e se tornou mais complexo, por exemplo, quando adicionamos o HighLoad.

No próximo artigo, contaremos como foi lançado o tarifário Hi-CPU: sobre hardware, software, quais tarefas resolvemos e o que fizemos.

Fonte: habr.com

Adicionar um comentário