Desbravando Linux Containers (LXC) – Docker – uma visão superficial (mas suficiente)

Docker

Como o objetivo desta série não é abordar diretamente o Docker, e sim Linux Containers, não devo me aprofundar muito e, portanto, apenas pretendo fornecer uma visão superficial do Docker, que em si é muito completo e complexo (caso tenha interesse em se aprofundar e conhecer mais o Docker, haverá uma lista de links ao fim desta postagem).

O Docker [www.docker.io] é baseado no LXC e funciona como uma ‘interface de gerenciamento’ para seus containers. Para simplificar toscamente a apresentação, o Docker apresenta-se como uma camada entre o kernel de seu sistema operacional hospedeiro e os containers (deve haver uma comparação mais apropriada, mas não me veio à mente no momento). O diagrama abaixo, retirado do site do docker, oferece uma visão de como a coisa toda funciona.

Um fato de grande importância é que o Docker apenas permite uma única aplicação/processo por container.

Vale a pena lembrar que por trás da limitação de única aplicação por container existe uma vantagem: A configuração do Docker utilizada em ambiente de desenvolvimento pode ser replicada com sucesso para um ambiente de produção.

Conforme mencionado, o Docker funciona nativamente em ambientes GNU/Linux, sem necessidade de virtualização. Para instalar, basta seguir as instruções do guia de instalação do docker. O mesmo guia tem versões para instalações em ambiente Mac OS X e ambiente Windows.

Docker Container Engine

Cada container do engine docker é composto por uma imagem base e layers sobrepostos contendo cada um as alterações aplicadas. A imagem base é a camada read-only do container. Essa camada não sofre alterações, servindo como referencia para os layers que ser-lhe-ão sobrepostos. Cada nova alteração é montada sobre um novo layer. Alterações somente são persistidas caso sejam submetidas ou ‘comitadas’. Nesse ponto, pode perceber alguma semelhança com o git?

Na pagina do Project Atomic, na parte da documentação sobre filesystems vemos um trecho sobre como funciona a organização de camadas:

Containers are a bit more complicated. Each containers has two layers, one (called the init layer), which is based on an image layer and a child of that which contains the actual container content. The init layer contains a few files that must always exist in Docker containers (e.g. /.dockerinit). Commiting a container (and thus creating an image) involves finding all the changes from the init layer to the container layer and applying those to a new layer based on the same image the container used.

Para uma compreensão mais apropriada, recomendaria uma leitura do texto na pagina do Project Atomic sobre filesystems. Esse texto me serviu como referência para compreender algumas particularidades que em tempo oportuno irei abordar.

Talvez a grande desvantagem em usar containers seja baseada no fato de que consistem em tecnologia nativa a ambientes Gnu/Linux, obrigando a usuários de outros SO a usarem virtualização completa de um ambiente linux, sendo dessa forma, penalizados em matéria de desempenho.

Na próxima postagem pretendo abordar com um pouco mais de propriedade o Docker, embora o objetivo seja traçar as linhas gerais para o uso do LXC puro.

Veja a seguir a lista de links relacionados a este post.

Páginas: 1 2 3

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s

%d blogueiros gostam disto: