Estamos muito próximos de iniciar algumas atividades mais práticas, com exemplos, tutoriais e estudos de caso, mas antes de chegarmos a este ponto gostaria de apresentar mais alguns conceitos, que serão importantes nas montagens de nossos laboratórios. Vamos falar sobre o uso de máquinas virtuais e containers.
Olhando superficialmente podem ser tecnologias muito parecidas, permitem que executemos programas e serviços diversos, usando recursos da máquina física, mas rodando de forma isolada do sistema operacional da máquina física. Mas as diferenças não param por aí.
Introdução a virtualização
A chegada da virtualização foi uma verdadeira alavanca nas possibilidades de estudo e laboratórios.
Imaginem vocês que lá pelo final da década de 90 para eu poder fazer meus estudos de redes e internet de forma mais aprofundada eu precisava ter duas CPUs em casa (e eu tinha). A internet era outra, os recursos eram outros, tudo era relativamente mais complicado por falta de acesso a equipamentos capazes de rodar tudo junto. No máximo você tinha locais onde poderia rodar alguns websites gratuitamente (basicamente só html, uns anos depois um pouco de CGI em perl e depois sites com asp e php).
No começo dos anos 2000 eu conheci o VMWARE Workstation, com ele eu podia criar uma máquina virtual (que chamaremos de VM – virtual machine) inteiramente isolada do meu sistema principal e rodar o que eu quisesse nessa VM. Poucos anos depois outras opções apareceram, hoje temos Xen, VMWare Workstation e Player, VirtualBox, KVM entre outros.
Uma máquina virtual é exatamente isso, um computador virtual. Ele possui BIOS, inicialização completa dos dois estágios do boot e você pode instalar qualquer sistema operacional, independente do sistema hospedeiro (a máquina física que roda a máquina virtual). A VM é literalmente a emulação de um computador completo.
É claro que a máquina hospedeira tem que ter recursos de processamento, memória e disco suficientes para atender a demanda, mas se você souber dividir bem dá pra fazer milagres!
Venho usado linux como sistema principal em meu computador pessoal desde 2001, e a melhor forma de eu ter algum windows para testes é com virtualização.
Além disso os sistemas de virtualização ainda possuem recursos completos de rede, geralmente oferecendo as seguintes conexões:
- Bridge – Onde o sistema compartilha a interface física ente o hospedeiro e a VM, funcionando como se a VM estivesse conectada no mesmo switch/roteador wifi que o hospedeiro
- NAT – Onde o sistema cria uma rede virtual entre o hospedeiro e a VM e já faz todo processo de tradução de endereços para que a VM tenha acesso a internet
- Host-Only – Onde a conectividade existe apenas entre o hospedeiro e a VM
- Internal – Onde apenas as VMs se comunicam, não existindo conectividade entre o hospedeiro e a VM
Se você mesclar essas possibilidades pode criar quase qualquer cenário que puder imaginar.
Imagine que você quer começar a estudar como montar um gateway/firewall para uma rede local. Você pode ter uma VM com duas interfaces, uma Bridge/NAT e uma Host-only, que será o gateway/firewall e uma segunda VM apenas com a interface Host-only que se comunicará com a internet através do NAT que iremos configurar no gateway.
Dividindo direitinho o ambiente e já rodei laboratórios com 14 VMs usando exclusivamente o meu computador pessoal. Era uma rede de um provedor de internet com muitos mikrotiks e meu objeto de estudo era uma limitação de tráfego que estava atrapalhando a expansão do provedor. Uma situação assim não tem muito como fazer testes reais enquanto se investiga o problema.
Imagine eu solicitando que o provedor interrompa suas atividades por uma hora para que eu possa rodar alguns testes. Nunca que o cliente me contrataria :p
Ao invés disso eu repliquei as configurações dele neste ambiente virtualizado, avaliei o problema, identifiquei o gargalo, testei soluções e depois de tudo pronto validei com um teste simples na rede do cliente.
Comprovado o problema entreguei um relatório completo descrevendo o problema, como isolar e sugestões de solução para ele.
Sem virtualização eu teria que ter esse monte de equipamento ligado, além de cabeamento, switchs e réguas de energia pra ligar tudo.
Levando para ambientes mais corporativos a virtualização permite um melhor uso dos recursos disponíveis, além de permitir algum grau de redundância, dependendo da forma como for configurado. Além disso tanto o KVM quanto o Hyper-V são gratuitos (no caso do hyper-v “gratuito”, por que você precisa comprar a licença do windows).
Por permitir toda essa maleabilidade a virtualização pode ser o melhor recurso para montagem de laboratórios para estudos.
Introdução a Containerização
Os containers ganharam popularidade a partir de 2013 com a chegada do docker, eles são um tipo de virtualização, mas funcionam de uma forma diferente. Enquanto uma VM possui toda estrutura de uma computador tradicional o container utiliza boa parte dos recursos do sistema operacional hospedeiro. De forma superficial um container é um conjunto muito específico de aplicações e bibliotecas que rodam de forma isolada, mas fazem o acesso ao hardware utilizando o sistema hospedeiro.
Por este motivo se você utiliza o Linux só poderá rodar containers linux, e se utiliza windows só poderá rodar containers windows (embora a partir do windows 10 com o WSL – windows subsytem for linux você possa rodar containers linux no windows).
No universo dos containers do Docker é a solução mais popular, mas ainda existem vários outros sistemas como o LXC, Podman, runC e containerd, todos com funcionalidades semlhantes.
A grande vantagem do container é que o tempo de carregamento é absurdamente rápido, visto que ele só precisa carregar poucas aplicações adicionais. Além disso o gerenciamento de imagens e volumes permite fazer com que sistemas inteiros sejam atualizados com poucos comandos e pouco tempo de indisponibilidade (as vezes zero indisponibilidade, dependendo da sua infraestrutura).
Containers rodam de forma completamente isolada do sistema operacional, ou seja você não precisa instalar nada no sistema hospedeiro, tudo é feito na imagem do container.
Além disso também possui possibilidade de gerenciar multiplas redes, o que permite isolar partes específicas de um projeto de acordo com a necessidade.
Por sua dinâmica de funcionamento containers são excelentes para hospedar estruturas de sistemas desenvolvidos para web, que atualmente é a forma mais comum de desenvolvimento de novos projetos.
Além disso, com centenas de imagens disponíveis é possível montar um ambiente (para hospedagem ou testes) de um sistema em poucos minutos.
Também é possível fazer muitos estudos de rede usando containers, mas a montagem do ambiente é um tanto mais complexa do que na virtualização, por não ser sua função principal.
Eu levei muitos anos (e me arrependo muito disso) para entender o uso real dos containers, mas é aquele história, quando você se sente confortável com uma tecnologia, adotar outra pode ser bastante complexo. Hoje consigo visualizar situações onde containers são superiores a virtualização e situação onde o uso dos dois é mais vantajosa.
E quando devo usar o que?
Aqui entra a beleza do caos, a resposta certa pra esta pergunta é: Depende do que você quer fazer, quais são os requisitos do projeto e o que vai ser executado.
Se você precisa rodar um sistema que não pode ser separado e tem pre-requisitos muito específicos, provavelmente a virtualização vai lhe atender melhor.
Se você vai rodar um sistema web, que possui componentes que podem ser divididos, provavelmente containers vão lhe atender melhor.
Se você está montando um projeto que vai iniciar agora, e possui um time interessado em trabalhar com tecnologias diversas, provavelmente uma mistura dos dois mundos trará melhor resultado, por exemplo, com VMs nos ambientes de dev e QA, por ser mais fácil debugar e acompanhar o ambiente, e containers no ambiente de produção, por permitir melhor escalabilidade e por possuir processos que podem ser padronizados e simplificar o processo de atualização dos componentes envolvidos.
No final das contas é o projeto quem determina a tecnologia que vai ser utilizada.
E o que roda no cluster de raspberry?
No cluster eu uso uma versão de um sistema chamado proxmox. Nós utilizamos ele em nossa empresa, a OTZ, ha mais de 5 anos, sempre mantendo atualizado e nunca tivemos problemas.
O proxmox é uma interface de gerenciamento para o qemu/KVM e também para containers LXC. Ainda não testei os containers LXC, mas este blog está rodando em um container docker, que está rodando em uma máquina virtual, que está hospedada no cluster. Eu apresentei maiores detalhes no post “Conhecendo minha rede“.
Além disso venho rodando qemu/KVM em meu computador pessoal ha mais de 3 anos, se você usa linux deixe o virtual box de lado, vale a pena aprender como virtualizar com o KVM, é nativo do kernel linux e tem todas as funcionalidades necessárias 🙂
Se você usa windows, devia mudar para o linux :p fica a dica! =)
Acho que agora apresentei conceitos suficientes para que possamos embarcar em jornadas mais interessantes. Preparem seus containers, iniciem suas VMs que vamos começar a colocar a mão na massa e ver na prática tudo o que falamos até aqui!
Se ficou alguma dúvida deixa um comentário que me ajudará a melhorar o texto e responderei com o maior prazer!
Meu muito obrigado a quem teve a paciência de chegar até aqui, nos vemos na próxima!