Docker – Perguntas Frequentes

Após uma conversa dentro da OCTO sobre Docker versus LXC e Virtual Machines (VMs), este post contem algumas perguntas e respostas sobre os conceitos e as principais diferenças entre essas tecnologias.

Pergunta: Qual é a diferença entre VMs e containers LXC?

Uma Virtual Machine (VM) consiste em rodar diversos Sistemas Operacionais (SOs) clientes completos (Linux, Windows, BSD, …) em recursos de hardware compartilhados. Tais SOs podem ser diferentes em cada VM e também pode ser diferente do sistema operacional base, onde rodam as VMs. Cada kernel do Sistema Operacional virtualizado considera sua execução em um hardware comum, sendo ele genérico ou um driver hypervisor específico.

Os Containers são isolamento de recursos: processos, sistema de arquivos, interfaces de rede e outros recursos do kernel (memória compartilhada, mutexes, semáforos, …) sendo executando dentro de um sistema operacional, com algumas limitações (CPU, memória, iops). Os Containers são comumente descritos como “chroot on steroids”. O FreeBSD jails ou o Solaris zones/containers possuem o mesmo objetivo.

Padrão Virtualização

Padrão Virtualização

Padrão Container

Padrão Container

Pergunta: Um container LXC pode rodar diversas distribuições Linux em um mesmo host?

Resposta direta: Sim.

Resposta elaborada: Os containers compartilham o kernel de seus sistemas operacionais hosts. Logo, eles são capazes de coletar dados desses sistemas, porém possuem seu próprios grupo de processos, configurações de rede e sistemas de arquivo. É possível incializar um container LXC Debian em um host LXC CentOS: neste caso o comando uname retorna a informação do kernel do host, exceto o hostname, dado que o arquivo /etc/*-release contem a informação do Debian sendo executado. Neste caso, o sistemas de gerenciamento de pacotes será o RPM para o host e o DPKG para o container.

Pergunta: Então, se containers são nada mais do que isolamento, porque compará-los a VMs?

No mundo Linux, incializar um container com um conjunto de processos de um sistema operacional completo (init, systemd, upstart, ssh) com um sistema de arquivos dedicado, dá acesso a um sistema isolado o qual realmente se comporta como uma VM, de uma perspectiva do usuário. É possível “logar” na máquina através de ssh em um IP dedicado, executar comandos como sudo, ps, top, yum/apt-get install, keill, service apache2 restart. OpenStack, libvirt, vagrant se conectam com LXC com uma outra maneira de prover VMs, mesmo que o termo não se encaixe.

Pergunta: E como fica o consumo de memória?

O consumo de memória consiste somente no total consumido pelo processo. Isto faz com que containers sejam tão leves que é possível lançar vários containers no mesmo host.

Pergunta: O que são Dockerfiles?

Assim como um Makefile ou um Vagrantfile, um Dockerfile é um arquivo texto utilizado para descrever a maneira como construir uma imagem Docker. A sintaxe de um Dockerfile é bem simples e contém somente alguns comandos auto-explicativos (FROM, RUN, CMD, USER, EXPOSE).

# Imagem incial
FROM ubuntu:latest

# Os comandos a serem executados para construção do container
RUN apt-get -y install python-software-properties
RUN add-apt-repository -y ppa:nginx/stable
RUN apt-get update
RUN apt-get install -y nginx

ADD nginx.conf /etc/nginx/
ADD nginx.sh /

# qual porta de rede será acessível para este container
EXPOSE 80

# o comando a ser executado sempre que o container for iniciado
CMD ["/nginx.sh"]

Perguntas: Que tipo de combinação VM vs Containers são possíveis?

VMs sobre VMs

Faz sentido em poucos casos, por exemplo quando testes de deployment de OpenStack sobre o OpenStack. A degradacão de performance é uma questão a ser tratada.

Container sobre VMs

Este é provavelmente o caso que faz mais sentido, principalmente quando é realmente complicado obter um VM do time de infraestrutura. Isto permite manter a VM limpa e completamente separada do ciclo de vida do container. A reinstalação do container pode ser executada a qualquer momento. E pode haver problemas relacionados com NAT, MASQUERADE, PAT para expor os serviços do container.

Containers sobre Containers

Não há problemas em executar este tipo de alinhamento. O container host deve possuir privilégios LXC para rodar. Muitos container sobre containers não fazem sentido e não há casos reais desses cenários.

VMs sobre Containers

Não deve-se fazer isso. Teoricamente, pode aplicar em hypervisors que rodem em um kernel Linux real (kvm por exemplo). Não há benefícios nesta abordagem.

Perguanta: Com relação ao Puppet / Chef / Salt / Ansible, faz sentido usar essas ferramentas junto ao Docker? Dentro ou fora de um container Docker?

Do lado do host faz sentido. É possível encontrar módulos puppet para gerenciar containers Docker.

Do lado do cliente, não há nada ainda muito definido. Há basicamente duas situações onde o gerenciamento de configuração pode ser utilizado:

  • No momento da construção – criação do container
  • No momento de inicialização – para finalizar a configuração, aplicando parâmetros específicos de ambiente, antes de inicializar o processo.

Como exemplo, pode-se imaginar um Dockerfile onde o puppet é utilizado, sem o master, para executar algumas configurações do container (momento de construção):

# Aqui é considerado que há uma imagem Centos com o Puppet disponível
FROM centos:puppet
ADD conf /etc/puppet/
RUN puppet apply -v -e 'include tomcat7_rhel'

Utilizar tal ferramenta no momento de incialização ou até no momento de execução pode ser útil, caso seja necessário executar alguma configuração de ambiente bem complicada.

Ainda se está longe de um consenso sobre o assunto. De qualquer forma, isso implica em dividir as classes / cookbooks para claramente separar em duas execuções, o que é um grande refactoring.

Mas, e agora?

Há ainda diversas questões a serem respondidas, como uso de local registry, gerenciamento de configuração, administração / operação, rede, storage, entre outras.

Caso tenha alguma dúvida, entre em contato conosco.

Ferramentas de análise estática para C# e .NET, NDepend em Profundidade

Como um arquiteto de software, muitas vezes eu tenho que analisar muitos código de aplicações, a fim de executar uma verificação de qualidade.

É um código de boa aparência? Qual a sua complexidade e cobertura de teste? Posso considerar o código como sustentável e com uma boa escalabilidade?

É claro que eu não vou gastar todo o meu tempo lendo cada arquivo-fonte, seria muito demorado e com certeza nada produtivo. Para isso, existem as ferramentas de análise estática de código fonte.

Read more

Prevendo o futuro com filtros colaborativos

É possível prever o futuro? Muitos acreditam que um homem chamado Michel de Nostradamus foi capaz. Suas previsões têm intrigado estudiosos por mais de quatrocentos anos.

Collaborative Filtering

Prever o futuro sempre foi um dos maiores desejos do ser humano, isso pode ser visto em quadrinhos, filmes de Hollywood, e até mesmo na cigana que te aborda na rua para ler a sua mão. A ciência afirma que prever o futuro pode ser uma capacidade humana: uma pesquisa empírica sugere que o cérebro possui uma certa capacidade de perceber o que está por vir…

Mas, falando em tecnologia, como os aplicativos atuais conseguem oferecer produtos e serviços como se tivessem “adivinhando” a necessidade do usuário? O Neo diria que eles usam os poderes do Oráculo, mas acredite, não é bem assim…

Read more

Até onde podemos ir com um desktop comum e uma aplicação Java reativa para web?

Programação reativaA tendência atual é que cada vez mais usuários fiquem conectados em todos os lugares e o tempo todo, muitas vezes em várias máquinas simultaneamente (desktop, tablet, celular). A promessa da programação reativa é prover recursos para suportar na mesma máquina muito mais conexões paralelas, e lidar com mais requisições por segundo, com menos threads e com muito menos memória e CPU do que os modos convencionais de programação. Para esse estudo nós criamos três versões de uma aplicação de teste:

  • versão servlet tradicional: uma servlet e chamada para um web service com Apache HttpClient
  • versão servlet assíncrona 3.0: uma servlet assíncrona e chamada para um web service com Apache HttpAsyncClient
  • versão 100% reativa: servidor HttpCore NIO e chamada de um web service com ApacheAsyncClient

Em seguida colocamos essas três versões sob testes de carga bastante agressivos para ver o que elas poderiam suportar. Read more

Os Padrões dos Gigantes da Web – DevOps

O movimento DevOps põe em cheque a fronteira entre as equipes de desenvolvimento e de operações. Não que essa discussão seja nova, mas a reestruturação proposta pelo DevOps é mais profunda, e bastante coerente com as metodologias ágeis, já presentes em boa parte das equipes de desenvolvimento, mas ainda distantes das equipes de operações.

O DevOps inclui muitas lições aprendidas dos Gigantes da Web (Amazon, Facebook, LinkedIn, etc.), que perceberam que não adianta fazer o desenvolvimento ágil, e parar nos processos lentos das equipes tradicionais de operações. O Time to Market (TTM) é um conceito chave para o sucesso dessas empresas, e para melhorá-lo é preciso rapidez não só no desenvolvimento, mas em toda a cadeia do produto.

Há outras vantagens no DevOps, mas o ponto central é realmente o TTM.

 

Read more

A prática do “Enquadramento 360”: Como começar um projeto da maneira certa!

É muito comum em projetos de software investirmos muito tempo em análise de requisitos e inúmeras páginas de documentação, que requer muito tempo (as vezes até 6 meses!) e ao final quase sempre são apenas “engavetadas”.

Me deparei muitas vezes com essa situação e comecei a me questionar a respeito de até onde vale a pena focar tanto tempo e esforço construindo inúmeros diagramas e especificações.

Read more

Medindo o desempenho de aplicações Web – Parte 3

Nos artigos anteriores (artigo 1 e artigo 2), vimos quais são os tipos de teste de performance que podem ser realizados para garantir o bom desempenho da aplicação, e também como um teste de carga pode nos ajudar a descobrir o quão performática é nossa aplicação.

Nesse artigo veremos o que é, e como pode ser realizado um novo conceito de testes: o PWPO.

Read more

Medindo o desempenho de aplicações Web – Parte 2

No artigo anteriorvimos o que é um teste de carga, teste de stress e teste de não regressão de performance. Além disso vimos qual a importância de realizar testes de desempenho para garantir o bom funcionamento da aplicação web, e o quanto se perde em tempo (e dinheiro) tendo um site lento.

Nesse artigo veremos como um teste de carga poderá nos ajudar a descobrir o quão performática nossa aplicação e quais são os passos para planejar e executar um teste de carga.

Read more

Medindo o desempenho de aplicações Web – Parte 1

Naquela típica conversa de almoço, certa vez, um colega disse que com uma pequena ajuda do Google poderia facilmente listar os estereótipos mais populares sobre uma nação, bastando pra isso digitar: “por que os [nacionalidade X] são tão…”, e rir com os resultados.

image002

 

image003

 

Depois de algumas risadas eu pensei: qual seria o consenso da opinião pública sobre os maiores sites da internet. Adaptando um pouco a ideia anterior podemos ter algumas respostas interessantes:

image004

image005

image006

Pra minha surpresa os resultados indicaram que boa parte das pessoas está perguntando sobre o mesmo tema: o desempenho dos sites.

Read more