Embora eu acredite genuinamente que os contêineres, microsserviços e orquestração de contêineres sejam excelentes, sempre defendo a regra simples: a ferramenta certa para a tarefa certa. Aqui está um projeto DevOps em que trabalhei recentemente para o Mouseflow que exemplifica essa regra.
Um pequeno histórico sobre o projeto
Mais de 500 servidores Linux e Windows hospedados em dois data centers. A maioria dos aplicativos está em .NET, com menos de 10 serviços, alguns dos quais estão supercarregados e outros não, HBase é o banco de dados principal, série da loja ElasticSearch, usamos Ansible para implantar servidores e, claro, OddEye para monitoramento.
Estamos usando TeamCity para construir e MSDeploy para implantar nossos aplicativos .NET em servidores Windows. Normalmente, a implantação leva menos de 10 minutos, é claro que durante este procedimento o serviço permanece online com tempo de inatividade zero.
Quais são os objetivos?
Sem SPOF
Performance máxima
Menos servidores (já temos mais de 500)
Fácil gerenciamento de infraestrutura
O máximo de previsão de problemas possíveis
O máximo de automação de tarefas possível
O mínimo de tempo possível é gasto em manutenção por máquina e infraestrutura geral.
Muitas pessoas dirão que a única, ou pelo menos a solução ideal para atingir esses objetivos, é implantar Dockers, orquestrá-los com o Kubernetes ou pelo menos ir para a AWS e solicitar toneladas de instâncias de nuvem. Mas um dos nossos objetivos é atingir o “desempenho máximo”. Isso significa que devemos estar o mais perto possível do hardware, portanto, instâncias em nuvem com vizinhos barulhentos não são uma opção para nós.
Chegando perto com metal puro
Os contêineres são provavelmente a maneira mais eficiente de virtualizar ambientes, mas toda abstração é uma perda de desempenho, talvez um pouco, mas é. Além disso, nem Hadoop / HBase nem ElasticSearch, que são nossos principais serviços, funcionam bem com contêineres. Portanto, a melhor solução que resta é trabalhar com servidores dedicados. O fato é que muitas pessoas se esquecem de ferramentas antigas testadas em batalha e se esquecem de que a maioria dessas ferramentas ainda está em uso pelos maiores jogadores.
Não queremos desperdiçar centenas de horas de trabalho e manter muitas pessoas em uma equipe para gerenciar esses servidores. Queremos fazer isso de forma eficiente com uma equipe pequena. Então, como conseguir isso? Precisávamos de um data center confiável que fornecesse bons servidores com preços razoáveis nos Estados Unidos e na Europa. Após algumas pesquisas, optamos por trabalhar com os melhores provedores
Há uma tarefa importante para o pessoal local dos data centers com que trabalhamos: eles devem entregar servidores com configurações definidas por nós para KVM, para que possamos ter acesso offline aos servidores se algo der errado e, de alguma forma, perdermos contato com SO sobre SSH. Pedimos uma quantidade inicial de racks e servidores e começamos a configurar nosso sistema. A primeira coisa foi criar um servidor TFTP com imagens de instalação, que deveria ter algumas configurações básicas e chaves SSH. Feito isso, poderíamos inicializar a máquina via PXE e instalar automaticamente o sistema operacional nela.
O procedimento de entrega dos servidores é o seguinte:
Pedimos ao data center para fornecer uma certa quantidade de servidores e configurar KVMs com os endereços IP desejados
Quando os servidores são entregues, nós os ligamos via KVM e os inicializamos via PXE
Após alguns minutos, o SO está instalado e pronto para uso.
Quando o sistema operacional básico é instalado e configurado, precisamos implantar software e serviços. A maioria de nossos servidores está executando HDFS / HBase ou ElasticSearch. Portanto, a tarefa é automatizar o processo de instalação e configuração. Não demorou muito para escolhermos o Ansible como a ferramenta de automação preferida. O motivo para selecionar Ansible era óbvio: o Ansible depende do SSH e não requer a instalação de nenhum agente nos sistemas de destino. Como instalamos as chaves SSH durante a instalação do sistema operacional, não resta mais nada a fazer nas máquinas finais para usá-las como clientes Ansible. Instalamos o Ansible na máquina principal e criamos vários manuais para automatizar as instalações do HDFS / HBase e do ElasticSearch.
Como mencionei acima, muitos de nossos aplicativos são executados em .NET no Windows, portanto, nossa equipe de desenvolvimento está usando o MSDeploy para lidar com a implantação correta de aplicativos. Quando mudarmos para o .NET core no Linux, que está em nosso roteiro, faremos vários manuais do Ansible para isso também.
Nosso time:
2x DevOps
Monitoramento 4x (fazendo monitoramento humano 24/7/365 em turnos)
Entregue:
Mais de 500 servidores
Mais de 2 PB de dados HBase
Mais de 50 bilhões de documentos no ElasticSearch
Minha mensagem não é nova: Escolha a ferramenta certa para a tarefa certa, o que está em alta pode não ser o mais adequado para o seu caso. E, claro, é definitivamente possível gerenciar um monstro de metal com uma micro equipe.
