Oi Pessoal!
Hoje vamos reproduzir aqui uma entrevista concedida pelo Jérôme Petazzoni para o site: opensource.com. Para quem não o conhece, o Jérôme é um dos principais evangelistas Docker, esteve presente na QCon que ocorreu em agosto em São Paulo. A entrevista foi realizada por Sandeep Khuperkar que é um dos moderadores do site. Veja abaixo:
O que são containers? Quais tecnologias de containers existem e como o Docker é diferente delas?
De um ponto de vista mais abrangente, containers são máquinas virtuais mais leves. Você pode instalar qualquer coisa em um container, independente de (e sem afetar!) outros containers em seu servidor. Cada container possuí sua própria camada de rede, processo (PID), sistema de arquivo, etc. A carga de trabalho é significantemente menor do que em VMs: containers iniciam mais rápido, requerem menos memória e espaço em disco. Isso por que, de um ponto de vista mais técnico, containers são processos regulares dentro do servidor, utilizando features do kernel como namespaces e cgroups para garantir isolamento. Iniciar um container é iniciar um processo UNIX normal; Criar um container é apenas uma clonagem instantânea de um sistema de arquivos copy-on-write (Que hoje é extemamente barato, tanto em tempo de criação quanto em uso de espaço em disco).
O Docker é diferente das demais tecnologias, pois ele não é apenas uma engine para criação de containers, Docker é uma plataforma composta pela Docker Engine (para criar e executar containers), o Docker Hub (um repositório de armazenamento de imagens publicas, onde é possível o usuário criar e armazenar imagens customizadas), e ainda um vasto ecosistema de ferramentas como Docker Compose, Docker Machine, Docker Swarm, e muitas outras, todas girando em torno de um API pública e aberta.
De que forma o Docker diferente de outras tecnologias de hypervisor para virtualização?
Pode-se dizer que Docker é um “hypervisor para containers”, mas muitos não aprovarão esse metafora, uma vez que hypervisors geralmente gerenciam VMs, e Docker gerencia containers. Os detalhes técnicos são muito diferentes, quando um hypervisor inicia uma VM, ele cria hardware virtual, e aproveita instruções da CPU ou de recursos específicos, como VT-x, AMD-V. Quando Docker cria um container, ele aproveita recursos do kernel como namespaces e cgrups , sem depender de recursos de hardware específicos.
Por um lado os containers são mais portáteis, pois podem ser executados tanto em VMs quanto em servidores físicos, Por outro eles não são portáteis devido ao fato de serem atrelados ao kernel do servidor onde estão, isso quer dizer, por exemplo, que você não pode executar um container Windows dentro de um kernel Linux (exceto se o seu Linux conseguir executar binários do Windows).
O que você sugere para gerenciar armazenamento em containers Docker? Como é possível vincular dados com containers Docker?
Docker tem trabalha com o conceito de “volumes”, que são os diretórios compartilhados entre o container e seu servidor. Volumes são conceitualmente semelhante as “pastas compartilhadas” em máquinas virtuais, exceto elo fato de que eles não necessitam de qualquer configuração particular no container, e tem zero de overhead, pois eles são implementados utilizando pontos montagens.
Quando você tem dados que encontram-se em um disco (seja disco local, ou um pool de RAID, ou algo montado através da rede, ou qualquer outra coisa) a opção mais fácil é montar esse disco no host, e em seguida, expô-lo ao container através de um “volume”.
Docker também tem (uma nova marca, ainda experimental) mecanismo de plug-in que permite que um container forneça armazenamento para outros containers. Isto significa que um container pode ser responsável pelo execução de um agente ou membro de uma rede Ceph, Gluster, ou qualquer outro cluster de armazenamento, e expor os dispositivos de bloco e os pontos de montagem para outros containers.
Como você faz para mover os dados de um container Docker para outro iniciado em outro servidor?
Exatamente como fizemos isso antes dos containers: armazenamento de rede, sistemas de arquivos distribuídos, a transferência de dados ou sincronização com rsync, unison, etc. Há, porém, duas vantagens ao usar containers: Em primeiro lugar, a nossa forma de acessar os dados são abstraídos do container, Se eu mudar, por exemplo, de DRBD para Ceph, meu container não precisa saber qual é a tecnologia utilizada, na verdade, o mesmo container será executado de forma idêntica em armazenamento local, ou em armazenamento distribuído. A outra vantagem vem desses novos plugins de armazenamento, eles vão fazer o acesso aos dados mais simples, separando corretamente o container de aplicação do container de armazenamento.
Como você pode garantir que as modificações de um container em execução são salva na criação de uma nova imagem?
Docker oferece chamadas de API para comparar um container com sua imagem original, e para criar uma nova imagem a partir de um container existente. Os comandos CLI para essas chamadas de API são “docker diff” e “docker commit”.
Como os containers Docker podem ajudar a criar soluções altamente disponíveis?
Quando você cria um sistema altamente disponível, você geralmente passa um bom um tempo pensando em uma lista de coisas que devem ser feitas. Docker tornará algumas dessas etapas mais fácil, por exemplo, garantindo que você possa implantar novas versões de seu software nas máquinas de produção de forma mais ágil. O Docker não vai resolver problemas magicamento (o uso da magia na criação de sistemas é não é aprovado geralmente), mas ele vai tornar muitas das coisas mais fáceis, mais rápidas, mais confiáveis – da mesma forma do que usar um gerenciador de pacotes é geralmente mais conveniente do que a compilação de tudo, desde o código fonte.
Como você vê a crescente adoção do Docke em clientes empresariais e ambientes de produção?
De um modo geral, a visão é essa:: Docker inicia como uma ferramenta para desenvolvimento para consistência e repetição do ambiente, similar como o Hashicorp’s Vagrant faz. Então, gradualmente se forma CI/CD, onde ele ajuda a reduzir tempos de teste pela metade (ou até mais). Dai em diante ele é utilizado em testes de pre-produção, onde o risco é menor. Eventualmente, uma vez que a equipe operacional ganhou experiência e confiança suficiente com o funcionamento do Docker, ele vai passa a atender todo o tráfego do ambiente de produção.
Legal não? Quer ver na íntegra? acesse: http://opensource.com/business/15/8/interview-jerome-petazzoni-docker-linuxcon
Fique atento e nos ajude divulgando do blog! Grande abraço.
Entusiasta Open Source, seu principal foco é ir atrás de ideias novas e torna-las realidade através de soluções simples e eficientes, o menos é mais, e o dividir é multiplicar.
