Docker um novo conceito de virtualização - Parte 2

Na primeira parte deste artigo, fiz uma introdução bem detalhada sobre Linux Contêiner tecnologia que cunhou o que hoje conhecemos como Docker. Agora você deve estar confuso a respeito da adoção pragmática desta tecnologia. Antes de mostrar na prática quão vantajoso é montar um servidor Docker do zero, vou dar ênfase aos tipos de virtualização de modo que possamos compreender a fundo este novo paradigma:


Hypervisor

O Hypervisor é uma camada de software localizada entre o hardware e as máquinas virtuais, sendo responsável por fornecer recursos (storage, CPU, memória, rede, etc.) da máquina física para a máquina virtual. Ele permite que vários sistemas operacionais possam ser executados em um mesmo host. Os hypervisores também são conhecidos como monitores de máquinas virtuais VMM, e podem ser classificados em dois tipos distintos:

  • Hypervisores do tipo 1 : São aqueles que originalmente são executados no hardware bare-metal, isto é, metal nú, as máquinas virtuais (guests) rodam diretamente sobre ele.

Exemplos de servidores do tipo 1 : Vmware ESX, Microsoft Hyper-V, Citrix Xen Server, Proxmox, oVirt etc...

  • Hypervisores do tipo 2 : São os hypervisores que são executados no contexto de outro sistema operacional (que também pode ser executado dentro de um bare-metal).

Exemplos de servidores do tipo 2: Oracle VirtualBox, Microsoft Virtual PC, QEMU, VMWare Player etc..

O Docker nativamente não é executado em máquinas virtuais. Em vez disso, usa recursos internos de contenção do Kernel Linux como Cgroups, Namespaces, UnionFS, chroot para executar aplicações em ambientes virtuais. Esses ambientes virtuais chamados contêineres, têm listas de usuários separados, sistemas de arquivos separados, e dispositivo de rede basicamente.

Inicialmente Docker foi construído como uma camada de abstração em cima do Linux Containers (LXC) como mencionei no artigo anterior. No entanto, o LXC não é mais padrão e foi substituído com uma biblioteca personalizada chamada libcontainer escrita em Go.

A única restrição para o uso do libcontainer em distribuições GNU/Linux, é o uso de um kernel superior à versão 3.8.

Os namespaces também já foram abordados no artigo anterior. Já os cgroups, tem o papel de isolar o uso de recursos como (CPU, memória, I/O) a cada contêiner criado.


UnionFS

Quando o Docker inicializa um contêiner a partir de imagem pela primeira vez, primeiramente ele monta o sistema de arquivos raiz "/", como somente leitura. Depois, em vez de fazer o sistema de arquivos de leitura e escrita, o Docker atribui uma outra camada de sistema de arquivos a esse contêiner utilizando montagens unidas (union mounts). O UnionFS permite que o Docker crie um repositório de mudanças no sistema de arquivos e este é um recurso que economiza espaço e permite alterações em contêineres com muita facilidade.

Unionfs funde vários diretórios em uma única visualização unificada.

Para mais detalhes, o site linuxjournal faz uma abordagem completa sobre o funcionamento do UnionFS.


Orquestração de contêineres Docker

Compreendido as diferenças entre o Hypervisor do tipo 1 e do tipo 2, fica mais fácil de compreender como funciona o LXC, o libcontainer e a proposta do Docker propriamente. No entanto, até aqui não relatei uma vantagem que existe nos sistemas com hypervisor que é justamente o ambiente de gerenciamento das máquinas virtuais. Por padrão, o Docker não vem com nenhuma ferramenta para gerenciamento de clusters.

Por esse motivo, é necessário trabalhar com orquestração de contêineres. Isto é, trabalhar com ferramentas que ajudam na organização e gestão em cima desta proposta. Os orquestradores mais conhecidos são:

  • Docker Swarm

    • Docker Swarm serviço de clustering nativo do Docker. Com Swarm é possível criar um pool de hosts como se fossem um único host. Dito de forma simples, é possível criar cluster's para melhor administrar e organizar um conjunto de container's.
  • Kubernetes

    • Assim como no Docker Swarm, o Kubernetes é um sistema desenvolvido pelo Google para gerenciamento de aplicativos em containers através de múltiplos hosts de um cluster. Tem como principal objetivo facilitar a implantação de aplicativos baseados em microservices. Ele foi baseado na experiência do Google de muitos anos trabalho com containers, adaptando o para se trabalhar com Docker.

Kubernetes contém ferramentas que vão além da API do Docker.

  • OpenStack
    • Tendo em vista que o OpenStack vai muito além de um orquestrador Docker, isto é, trata-se de uma solução completa e complexa para serviços em cloud computing. Mas como o foco aqui é Docker, a ferramenta no OpenStack responsável pela orquestração Docker se chama Magnum. O Magnum OpenStack, permite usar o Kubernetes ou Docker Swarm como opção dentro do ambiente OpenStack para os mesmos fins.

Obs: Estas ferramentas serão melhor exploradas mais a diante.


Até um próximo post, e espero que tenham gostado da abordagem dada a este material.


Sugestão para estudo: