Qual a diferença entre o Docker e uma máquina virtual?

Continuo relendo a documentação do Docker para tentar entender a diferença entre o Docker e uma VM completa. Como ele consegue fornecer um sistema de arquivos completo, ambiente de rede isolado etc. sem ser tão pesado?

Por que implantar software em uma imagem do Docker (se esse é o termo certo) é mais fácil do que simplesmente implantar em um ambiente de produção consistente?

O Docker usou originalmente LinuX Containers (LXC), mas depois mudou para runC (anteriormente conhecido como libcontainer ), que é executado no mesmo sistema operacional que o host. Isso permite compartilhar muitos recursos do sistema operacional do host. Além disso, ele usa um sistema de arquivos em camadas ( AuFS ) e gerencia a rede.

O AuFS é um sistema de arquivos em camadas, para que você possa ter uma parte somente leitura e uma parte de gravação que são mescladas. Pode-se ter as partes comuns do sistema operacional como somente leitura (e compartilhadas entre todos os seus contêineres) e depois dar a cada contêiner sua própria montagem para gravação.

Então, digamos que você tenha uma imagem de contêiner de 1 GB; se você quiser usar uma VM completa, precisará ter 1 GB x número de VMs que desejar. Com o Docker e o AuFS, você pode compartilhar a maior parte dos 1 GB entre todos os contêineres e, se tiver 1000 contêineres, ainda poderá ter pouco mais de 1 GB de espaço para o SO dos contêineres (supondo que todos estejam executando a mesma imagem do SO) .

Um sistema virtualizado completo obtém seu próprio conjunto de recursos alocados a ele e faz um compartilhamento mínimo. Você obtém mais isolamento, mas é muito mais pesado (requer mais recursos). Com o Docker, você obtém menos isolamento, mas os contêineres são leves (requerem menos recursos). Assim, você pode facilmente executar milhares de contêineres em um host, e ele nem piscará. Tente fazer isso com o Xen e, a menos que você tenha um host muito grande, acho que não é possível.

Um sistema virtualizado completo geralmente leva alguns minutos para iniciar, enquanto os contêineres do Docker / LXC / runC levam alguns segundos e, geralmente, menos de um segundo.

Existem prós e contras para cada tipo de sistema virtualizado. Se você deseja um isolamento completo com recursos garantidos, uma VM completa é o caminho a percorrer. Se você deseja isolar os processos um do outro e executar vários deles em um host de tamanho razoável, o Docker / LXC / runC parece ser o caminho a seguir.

Para obter mais informações, confira este conjunto de postagens no blog que explicam bem como o LXC funciona.

Por que implantar software em uma imagem do docker (se esse for o termo certo) é mais fácil do que simplesmente implantar em um ambiente de produção consistente?

Implantar um ambiente de produção consistente é mais fácil falar do que fazer. Mesmo se você usar ferramentas como Chef e Puppet , sempre haverá atualizações do sistema operacional e outras coisas que mudam entre hosts e ambientes.

O Docker oferece a capacidade de capturar instantaneamente o sistema operacional em uma imagem compartilhada e facilita a implantação em outros hosts do Docker. Localmente, dev, qa, prod, etc .: tudo a mesma imagem. Claro que você pode fazer isso com outras ferramentas, mas não com tanta facilidade ou rapidez.

Isso é ótimo para testar; digamos que você tenha milhares de testes que precisam se conectar a um banco de dados, e cada teste precisa de uma cópia original do banco de dados e fará alterações nos dados. A abordagem clássica para isso é redefinir o banco de dados após cada teste com código personalizado ou com ferramentas como o Flyway - isso pode consumir muito tempo e significa que os testes devem ser executados em série. No entanto, com o Docker, você pode criar uma imagem do seu banco de dados e executar uma instância por teste e, em seguida, executar todos os testes em paralelo, pois você sabe que todos eles serão executados no mesmo instantâneo do banco de dados. Como os testes estão sendo executados em paralelo e em contêineres do Docker, eles podem ser executados todos na mesma caixa ao mesmo tempo e devem terminar muito mais rapidamente. Tente fazer isso com uma VM completa.

Dos comentários ...

Interessante! Suponho que ainda esteja confuso com a noção de "captura instantânea do sistema operacional". Como alguém faz isso sem, bem, criar uma imagem do sistema operacional?

Bem, vamos ver se consigo explicar. Você começa com uma imagem de base, faz as alterações e confirma essas alterações usando a janela de encaixe, e ela cria uma imagem. Esta imagem contém apenas as diferenças da base. Quando você deseja executar sua imagem, também precisa da base, e ela se sobrepõe à imagem usando um sistema de arquivos em camadas: como mencionado acima, o Docker usa o AuFS. O AuFS mescla as diferentes camadas e você obtém o que deseja; você só precisa executá-lo. Você pode continuar adicionando mais e mais imagens (camadas) e ele continuará salvando apenas as diferenças. Como o Docker geralmente se baseia em imagens prontas de um registro , você raramente precisa "instantaneamente" todo o sistema operacional.

Boas respostas. Apenas para obter uma representação de imagem de contêiner versus VM, dê uma olhada no abaixo.

Fonte

Pode ser útil entender como a virtualização e os contêineres funcionam em baixo nível. Isso vai esclarecer muitas coisas.

Nota: Estou simplificando um pouco a descrição abaixo. Veja as referências para mais informações.

Como a virtualização funciona em baixo nível?

Nesse caso, o gerenciador de VM assume o anel da CPU 0 (ou o "modo raiz" nas CPUs mais recentes) e intercepta todas as chamadas privilegiadas feitas pelo SO convidado para criar a ilusão de que o SO convidado possui seu próprio hardware. Curiosidade: Antes de 1998, pensava-se que era impossível conseguir isso na arquitetura x86 porque não havia como fazer esse tipo de interceptação. Os funcionários da VMWare foram os primeiros a reescrever os bytes executáveis ​​na memória para chamadas privilegiadas do SO convidado para conseguir isso.

O efeito líquido é que a virtualização permite executar dois sistemas operacionais completamente diferentes no mesmo hardware. Cada sistema operacional convidado passa por todo o processo de inicialização, carregamento do kernel etc. Você pode ter uma segurança muito rígida, por exemplo, o sistema operacional convidado não pode ter acesso total ao sistema operacional host ou a outros convidados e estragar tudo.

Como os contêineres funcionam em nível baixo?

Por volta de 2006 , as pessoas, incluindo alguns dos funcionários da Google implementou novo recurso nível do kernel chamados namespaces (no entanto, a ideia de longo antes existia no FreeBSD) Uma função do sistema operacional é permitir o compartilhamento de recursos globais, como rede e disco, aos processos. E se esses recursos globais estivessem agrupados em espaços para nome, para que fiquem visíveis apenas para os processos executados no mesmo espaço para nome? Digamos, você pode obter um pedaço de disco e colocá-lo no espaço para nome X e, em seguida, os processos em execução no espaço para nome Y não podem vê-lo ou acessá-lo. Da mesma forma, os processos no espaço para nome X não podem acessar nada na memória que está alocada no espaço para nome Y. É claro que os processos no X não podem ver ou falar com processos no espaço para nome Y. Isso fornece um tipo de virtualização e isolamento para recursos globais. É assim que a janela de encaixe funciona: cada contêiner é executado em seu próprio espaço para nome, mas usa exatamente o mesmocomo todos os outros contêineres. O isolamento ocorre porque o kernel conhece o espaço para nome que foi atribuído ao processo e, durante as chamadas à API, garante que o processo possa acessar apenas recursos em seu próprio espaço para nome.

As limitações de contêineres vs VM devem ser óbvias agora: você não pode executar sistemas operacionais completamente diferentes em contêineres, como nas VMs. No entanto, você pode executar diferentes distribuições do Linux porque elas compartilham o mesmo kernel. O nível de isolamento não é tão forte quanto na VM. De fato, havia uma maneira de o contêiner "convidado" assumir o controle nas implementações iniciais. Além disso, você pode ver que, quando você carrega um novo contêiner, toda a nova cópia do SO não inicia como na VM. Todos os contêineres compartilham o mesmo kernel. É por isso que os recipientes são leves. Além disso, diferentemente da VM, você não precisa pré-alocar uma parte significativa da memória para os contêineres porque não estamos executando uma nova cópia do SO. Isso permite executar milhares de contêineres em um sistema operacional enquanto os coloca em sandbox, o que pode não ser possível se estivéssemos executando uma cópia separada do sistema operacional em sua própria VM.

Eu gosto da resposta de Ken Cochrane.

Mas quero acrescentar um ponto de vista adicional, não abordado em detalhes aqui. Na minha opinião, Docker também difere em todo o processo. Ao contrário das VMs, o Docker não é (apenas) o compartilhamento ideal de recursos de hardware; além disso, fornece um "sistema" para aplicativos de empacotamento (preferível, mas não obrigatório, como um conjunto de microsserviços).

Para mim, ele se encaixa na diferença entre ferramentas orientadas a desenvolvedores como rpm, pacotes Debian , Maven , npm + Git de um lado e ferramentas ops como Puppet , VMware, Xen, o nome dele ...

Por que implantar software em uma imagem do docker (se esse for o termo certo) é mais fácil do que simplesmente implantar em um ambiente de produção consistente?

Sua pergunta pressupõe algum ambiente de produção consistente. Mas como mantê-lo consistente? Considere uma quantidade (> 10) de servidores e aplicativos, estágios no pipeline.

Para manter isso sincronizado, você começará a usar algo como Puppet, Chef ou seus próprios scripts de provisionamento, regras não publicadas e / ou muita documentação ... Em teoria, os servidores podem funcionar indefinidamente, e são mantidos completamente consistentes e atualizados. A prática falha ao gerenciar completamente a configuração de um servidor, portanto, há um escopo considerável para o desvio da configuração e alterações inesperadas nos servidores em execução.

Portanto, existe um padrão conhecido para evitar isso, o chamado servidor imutável . Mas o padrão imutável do servidor não era amado. Principalmente devido às limitações das VMs usadas antes do Docker. Lidar com imagens grandes de vários gigabytes, movê-las, apenas para alterar alguns campos do aplicativo, foi muito trabalhoso. Compreensível...

Com um ecossistema Docker, você nunca precisará movimentar gigabytes em "pequenas alterações" (obrigado aufs e Registry) e não precisará se preocupar em perder desempenho empacotando aplicativos em um contêiner Docker em tempo de execução. Você não precisa se preocupar com versões dessa imagem.

E, finalmente, você ainda poderá reproduzir ambientes de produção complexos, mesmo no seu laptop Linux (não me ligue se não funcionar no seu caso;))

E é claro que você pode iniciar contêineres do Docker em VMs (é uma boa ideia). Reduza o provisionamento do servidor no nível da VM. Todos os itens acima podem ser gerenciados pelo Docker.

PS Enquanto isso, o Docker usa sua própria implementação "libcontainer" em vez do LXC. Mas o LXC ainda é utilizável.

O Docker não é uma metodologia de virtualização. Ele se baseia em outras ferramentas que realmente implementam virtualização baseada em contêiner ou virtualização no nível do sistema operacional. Para isso, o Docker estava usando inicialmente o driver LXC e depois foi transferido para o libcontainer, que agora é renomeado como runc. O Docker se concentra principalmente em automatizar a implantação de aplicativos dentro de contêineres. Os contêineres de aplicativos são projetados para empacotar e executar um único serviço, enquanto os contêineres do sistema são projetados para executar vários processos, como máquinas virtuais. Portanto, o Docker é considerado uma ferramenta de gerenciamento de contêiner ou implantação de aplicativos em sistemas em contêiner.

Para saber como é diferente de outras virtualizações, vamos analisar a virtualização e seus tipos. Então, seria mais fácil entender qual é a diferença lá.

Virtualização

Em sua forma concebida, foi considerado um método de dividir logicamente os mainframes para permitir que vários aplicativos fossem executados simultaneamente. No entanto, o cenário mudou drasticamente quando empresas e comunidades de código aberto foram capazes de fornecer um método para lidar com as instruções privilegiadas de uma maneira ou de outra e permitir que vários sistemas operacionais fossem executados simultaneamente em um único sistema baseado em x86.

Hypervisor

O hypervisor gerencia a criação do ambiente virtual no qual as máquinas virtuais convidadas operam. Ele supervisiona os sistemas de convidados e garante que os recursos sejam alocados aos convidados conforme necessário. O hipervisor fica entre a máquina física e as máquinas virtuais e fornece serviços de virtualização para as máquinas virtuais. Para realizá-lo, ele intercepta as operações do sistema operacional convidado nas máquinas virtuais e emula a operação no sistema operacional da máquina host.

O rápido desenvolvimento de tecnologias de virtualização, principalmente na nuvem, impulsionou ainda mais o uso da virtualização, permitindo a criação de vários servidores virtuais em um único servidor físico com a ajuda de hipervisores, como Xen, VMware Player, KVM, etc., e incorporação de suporte de hardware em processadores básicos, como Intel VT e AMD-V.

Tipos de virtualização

O método de virtualização pode ser categorizado com base em como ele imita o hardware para um sistema operacional convidado e emula um ambiente operacional convidado. Principalmente, existem três tipos de virtualização:

• Emulação
• Paravirtualização
• Virtualização baseada em contêiner

Emulação

A emulação, também conhecida como virtualização completa, executa o kernel do sistema operacional da máquina virtual inteiramente em software. O hypervisor usado neste tipo é conhecido como hypervisor Tipo 2. Ele é instalado na parte superior do sistema operacional host, responsável por converter o código do kernel do SO convidado em instruções de software. A tradução é feita inteiramente em software e não requer envolvimento de hardware. A emulação possibilita a execução de qualquer sistema operacional não modificado que suporte o ambiente emulado. A desvantagem desse tipo de virtualização é uma sobrecarga adicional de recursos do sistema que leva a uma diminuição no desempenho em comparação com outros tipos de virtualização.

Exemplos nesta categoria incluem VMware Player, VirtualBox, QEMU, Bochs, Parallels, etc.

Paravirtualização

A paravirtualização, também conhecida como hipervisor Tipo 1, é executada diretamente no hardware, ou “bare-metal”, e fornece serviços de virtualização diretamente para as máquinas virtuais em execução nele. Ajuda o sistema operacional, o hardware virtualizado e o hardware real a colaborar para alcançar o desempenho ideal. Esses hipervisores normalmente têm uma pegada bastante pequena e não exigem, eles próprios, recursos extensivos.

Exemplos nesta categoria incluem Xen, KVM, etc.

Virtualização baseada em contêiner

A virtualização baseada em contêiner, também conhecida como virtualização no nível do sistema operacional, permite várias execuções isoladas em um único kernel do sistema operacional. Possui o melhor desempenho e densidade possíveis e possui gerenciamento dinâmico de recursos. O ambiente de execução virtual isolado fornecido por esse tipo de virtualização é chamado de contêiner e pode ser visualizado como um grupo de processos rastreados.

O conceito de um contêiner é possível graças ao recurso de namespaces adicionado ao kernel Linux versão 2.6.24. O contêiner adiciona seu ID a todos os processos e adiciona novas verificações de controle de acesso a todas as chamadas do sistema. É acessado pela chamada de sistema clone () que permite criar instâncias separadas de namespaces anteriormente globais.

Os espaços para nome podem ser usados ​​de várias maneiras diferentes, mas a abordagem mais comum é criar um contêiner isolado que não tenha visibilidade ou acesso a objetos fora do contêiner. Os processos em execução no contêiner parecem estar em execução em um sistema Linux normal, embora estejam compartilhando o kernel subjacente com processos localizados em outros namespaces, o mesmo para outros tipos de objetos. Por exemplo, ao usar espaços para nome, o usuário raiz dentro do contêiner não é tratado como raiz fora do contêiner, adicionando segurança adicional.

O subsistema Linux Control Groups (cgroups), o próximo componente principal a habilitar a virtualização baseada em contêiner, é usado para agrupar processos e gerenciar seu consumo agregado de recursos. É comumente usado para limitar o consumo de memória e CPU dos contêineres. Como um sistema Linux em contêiner possui apenas um kernel e o kernel tem total visibilidade nos contêineres, há apenas um nível de alocação e programação de recursos.

Várias ferramentas de gerenciamento estão disponíveis para contêineres Linux, incluindo LXC, LXD, systemd-nspawn, lmctfy, Warden, Linux-VServer, OpenVZ, Docker, etc.

Contêineres vs Máquinas Virtuais

Ao contrário de uma máquina virtual, um contêiner não precisa inicializar o kernel do sistema operacional; portanto, os contêineres podem ser criados em menos de um segundo. Esse recurso torna a virtualização baseada em contêiner exclusiva e desejável do que outras abordagens de virtualização.

Como a virtualização baseada em contêiner adiciona pouca ou nenhuma sobrecarga à máquina host, a virtualização baseada em contêiner tem desempenho quase nativo

Para virtualização baseada em contêiner, nenhum software adicional é necessário, ao contrário de outras virtualizações.

Todos os contêineres em uma máquina host compartilham o agendador da máquina host, economizando a necessidade de recursos extras.

Os estados do contêiner (imagens do Docker ou LXC) são pequenos em comparação às imagens da máquina virtual, portanto, as imagens do contêiner são fáceis de distribuir.

O gerenciamento de recursos em contêineres é alcançado por meio de cgroups. O Cgroups não permite que os contêineres consumam mais recursos do que os alocados. No entanto, a partir de agora, todos os recursos da máquina host estão visíveis nas máquinas virtuais, mas não podem ser usados. Isso pode ser realizado executando-se topou htopem contêineres e na máquina host ao mesmo tempo. A saída em todos os ambientes será semelhante.

Atualizar:

Como o Docker executa contêineres em sistemas não Linux?

Se os contêineres são possíveis devido aos recursos disponíveis no kernel do Linux, a pergunta óbvia é como os sistemas não Linux executam os contêineres. O Docker para Mac e Windows usa VMs Linux para executar os contêineres. Caixa de ferramentas do Docker usada para executar contêineres em VMs do Virtual Box. Mas, o Docker mais recente usa o Hyper-V no Windows e o Hypervisor.framework no Mac.

Agora, deixe-me descrever como o Docker for Mac executa contêineres em detalhes.

O Docker para Mac usa https://github.com/moby/hyperkit para emular os recursos do hypervisor e o Hyperkit usa hypervisor.framework em seu núcleo. Hypervisor.framework é a solução nativa de hypervisor do Mac. O Hyperkit também usa VPNKit e DataKit para namespace de rede e sistema de arquivos, respectivamente.

A VM do Linux que o Docker executa no Mac é somente leitura. No entanto, você pode se basear nele executando:

screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty.

Agora, podemos até verificar a versão do Kernel desta VM:

# uname -a Linux linuxkit-025000000001 4.9.93-linuxkit-aufs #1 SMP Wed Jun 6 16:86_64 Linux.

Todos os contêineres são executados dentro desta VM.

Existem algumas limitações no hypervisor.framework. Por esse motivo, o Docker não expõe docker0a interface de rede no Mac. Portanto, você não pode acessar contêineres do host. A partir de agora, docker0só está disponível dentro da VM.

O Hyper-v é o hipervisor nativo no Windows. Eles também estão tentando aproveitar os recursos do Windows 10 para executar sistemas Linux nativamente.

Neste post, traçaremos algumas linhas de diferenças entre VMs e LXCs. Vamos primeiro defini-los.

VM :

Uma máquina virtual emula um ambiente de computação física, mas as solicitações de CPU, memória, disco rígido, rede e outros recursos de hardware são gerenciadas por uma camada de virtualização que converte essas solicitações no hardware físico subjacente.

Nesse contexto, a VM é chamada como Convidada, enquanto o ambiente em que é executado é chamado de host.

LXC s:

Linux Containers (LXC) são recursos no nível do sistema operacional que possibilitam executar vários contêineres isolados do Linux, em um host de controle (o host LXC). Os contêineres do Linux servem como uma alternativa leve às VMs, pois não exigem a visualização dos hypervisores. Virtualbox, KVM, Xen, etc.

Agora, a menos que você tenha sido drogado por Alan (Zach Galifianakis - da série Hangover) e esteja em Las Vegas no ano passado, você estará bem ciente do tremendo interesse que há pela tecnologia de contêineres Linux, e se eu for um contêiner específico O projeto que criou um burburinho em todo o mundo nos últimos meses é: o Docker leva a algumas opiniões repetidas de que os ambientes de computação em nuvem devem abandonar as máquinas virtuais (VMs) e substituí-los por contêineres devido à sua sobrecarga mais baixa e desempenho potencialmente melhor.

Mas a grande questão é: é possível? Será sensato?

uma. Os LXCs têm escopo definido para uma instância do Linux. Podem ser diferentes tipos de Linux (por exemplo, um contêiner Ubuntu em um host CentOS, mas ainda é Linux.) Da mesma forma, os contêineres baseados no Windows estão com escopo definido para uma instância do Windows agora, se observarmos as VMs, elas têm um escopo bem mais amplo e usam o hipervisores você não está limitado aos sistemas operacionais Linux ou Windows.

b. Os LXCs têm baixos custos indiretos e melhor desempenho em comparação às VMs. Ferramentas viz. O Docker, construído sobre os ombros da tecnologia LXC, forneceu aos desenvolvedores uma plataforma para executar seus aplicativos e, ao mesmo tempo, capacitou o pessoal de operações com uma ferramenta que lhes permitirá implantar o mesmo contêiner em servidores de produção ou data centers. Ele tenta tornar a experiência entre um desenvolvedor executando um aplicativo, inicializando e testando um aplicativo e uma pessoa de operações implantando esse aplicativo sem problemas, porque é aqui que todo o atrito reside e o objetivo do DevOps é quebrar esses silos.

Portanto, a melhor abordagem é que os provedores de infraestrutura em nuvem defendam o uso apropriado das VMs e LXC, pois cada um deles é adequado para lidar com cargas de trabalho e cenários específicos.

Abandonar VMs não é prático a partir de agora. Portanto, VMs e LXCs têm sua própria existência e importância individuais.

A maioria das respostas aqui fala sobre máquinas virtuais. Darei a você uma resposta unilateral a essa pergunta que me ajudou mais nos últimos anos de uso do Docker. É isso:

O Docker é apenas uma maneira elegante de executar um processo, não uma máquina virtual.

Agora, deixe-me explicar um pouco mais sobre o que isso significa. Máquinas virtuais são sua própria besta. Sinto vontade de explicar o que o Docker é o ajudará a entender isso mais do que explicar o que é uma máquina virtual. Especialmente porque existem muitas respostas excelentes aqui dizendo exatamente o que alguém quer dizer quando diz "máquina virtual". Assim...

Um contêiner do Docker é apenas um processo (e seus filhos) que é compartimentado usando cgroups dentro do kernel do sistema host a partir do restante dos processos. Você pode realmente ver seus processos de contêiner Docker executando ps auxno host. Por exemplo, iniciar apache2"em um contêiner" está apenas começando apache2como um processo especial no host. Acabou de ser compartimentado de outros processos na máquina. É importante observar que seus contêineres não existem fora da vida útil do processo em contêiner. Quando seu processo morre, seu contêiner morre. Isso ocorre porque o Docker substitui pid 1o contêiner pelo seu aplicativo ( pid 1normalmente o sistema init). Este último ponto sobre pid 1é muito importante.

Quanto ao sistema de arquivos usado por cada um desses processos de contêiner, o Docker usa o UnionFS imagens suportadas pelo , que é o que você está baixando quando faz um . Cada "imagem" é apenas uma série de camadas e metadados relacionados. O conceito de camadas é muito importante aqui. Cada camada é apenas uma alteração da camada abaixo dela. Por exemplo, quando você exclui um arquivo no seu Dockerfile ao criar um contêiner do Docker, na verdade você está apenas criando uma camada na parte superior da última camada que diz "este arquivo foi excluído". Aliás, é por isso que você pode excluir um arquivo grande do seu sistema de arquivos, mas a imagem ainda ocupa a mesma quantidade de espaço em disco. O arquivo ainda está lá, nas camadas abaixo do atual. As próprias camadas são apenas pacotes de arquivos. Você pode testar isso com e, em seguida . Então você pode dar uma olhada ao redor. Todos os diretórios que parecem hashes longos são na verdade as camadas individuais. Cada um contém arquivos ( ) e metadados (docker pull ubuntudocker save --output /tmp/ubuntu.tar ubuntucd /tmp && tar xvf ubuntu.tarlayer.tarjson) com informações sobre essa camada específica. Essas camadas apenas descrevem alterações no sistema de arquivos que são salvas como uma camada "em cima" de seu estado original. Ao ler os dados "atuais", o sistema de arquivos lê os dados como se estivesse observando apenas as camadas superiores de alterações. É por isso que o arquivo parece ter sido excluído, mesmo que ainda exista nas camadas "anteriores", porque o sistema de arquivos está apenas olhando para as camadas mais superiores. Isso permite que contêineres completamente diferentes compartilhem suas camadas do sistema de arquivos, mesmo que algumas mudanças significativas possam ter ocorrido no sistema de arquivos nas camadas mais superiores de cada contêiner. Isso pode economizar uma tonelada de espaço em disco quando seus contêineres compartilham suas camadas de imagem base. Contudo,

A rede no Docker é obtida usando uma ponte Ethernet (chamada docker0no host) e interfaces virtuais para cada contêiner no host. Ele cria uma sub-rede virtual docker0para seus contêineres se comunicarem "entre". Existem muitas opções de rede aqui, incluindo a criação de sub-redes personalizadas para seus contêineres e a capacidade de "compartilhar" a pilha de rede do host para que seu contêiner acesse diretamente.

O Docker está se movendo muito rápido. Sua documentação é uma das melhores que eu já vi. Geralmente é bem escrito, conciso e preciso. Eu recomendo que você verifique a documentação disponível para obter mais informações e confie na documentação sobre qualquer outra coisa que você leia online, incluindo Stack Overflow. Se você tiver perguntas específicas, eu recomendo entrar #dockerno Freenode IRC e perguntar lá (você pode até usar o webchat da Freenode para isso!).

O Docker encapsula um aplicativo com todas as suas dependências.

Um virtualizador encapsula um sistema operacional que pode executar qualquer aplicativo que normalmente possa ser executado em uma máquina bare metal.

Ambos são muito diferentes. O Docker é leve e usa LXC / libcontainer (que depende do namespace de kernel e cgroups) e não possui emulação de máquina / hardware, como hypervisor, KVM. Xen que são pesados.

O Docker e o LXC se destinam mais ao sandbox, contêiner e isolamento de recursos. Ele usa a API do clone do SO do host (atualmente apenas o kernel Linux) que fornece namespacing para IPC, NS (montagem), rede, PID, UTS, etc.

E quanto à memória, E / S, CPU, etc.? Isso é controlado usando cgroups, onde você pode criar grupos com determinadas especificações / restrições de recursos (CPU, memória, etc.) e colocar seus processos lá. Além do LXC, o Docker fornece um back-end de armazenamento ( http://www.projectatomic.io/docs/filesystems/ ), por exemplo, sistema de arquivos de montagem em união onde é possível adicionar camadas e compartilhar camadas entre os diferentes namespaces de montagem.

Esse é um recurso poderoso, no qual as imagens de base geralmente são somente de leitura e somente quando o contêiner modifica algo na camada é que ele escreve algo na partição de leitura / gravação (também conhecida como cópia na gravação). Ele também fornece muitos outros wrappers, como registro e controle de versão de imagens.

Com o LXC normal, você precisa vir com alguns rootfs ou compartilhá-los e quando compartilhados, e as alterações são refletidas em outros contêineres. Devido a muitos desses recursos adicionais, o Docker é mais popular que o LXC. O LXC é popular em ambientes incorporados por implementar segurança em torno de processos expostos a entidades externas, como rede e interface do usuário. O Docker é popular no ambiente de multilocação na nuvem, onde é esperado um ambiente de produção consistente.

Uma VM normal (por exemplo, VirtualBox e VMware) usa um hipervisor e as tecnologias relacionadas possuem firmware dedicado que se torna a primeira camada do primeiro SO (SO host ou SO convidado 0) ou um software que é executado no SO host para forneça emulação de hardware como CPU, USB / acessórios, memória, rede etc. aos sistemas operacionais convidados. As VMs ainda são (a partir de 2015) populares no ambiente multilocatário de alta segurança.

O Docker / LXC quase pode ser executado em qualquer hardware barato (menos de 1 GB de memória também é bom, desde que você tenha um kernel mais recente) vs. VMs normais precisam de pelo menos 2 GB de memória, etc., para fazer algo significativo com ele . Mas o suporte ao Docker no sistema operacional host não está disponível em sistemas operacionais como o Windows (a partir de novembro de 2014), onde tipos de VMs podem ser executados no Windows, Linux e Macs.

Aqui está uma foto do docker / rightscale:

1. leve

Esta é provavelmente a primeira impressão para muitos alunos do docker.

Primeiro, as imagens do docker geralmente são menores que as imagens da VM, facilitando a criação, a cópia e o compartilhamento.

Segundo, os contêineres do Docker podem iniciar em vários milissegundos, enquanto a VM inicia em segundos.

2. Sistema de arquivos em camadas

Esse é outro recurso importante do Docker. As imagens têm camadas, e imagens diferentes podem compartilhar camadas, tornam ainda mais economia de espaço e são mais rápidas de construir.

Se todos os contêineres usam o Ubuntu como suas imagens de base, nem todas as imagens têm seu próprio sistema de arquivos, mas compartilham os mesmos arquivos sublinhados do ubuntu e diferem apenas em seus próprios dados de aplicativo.

3. Kernel do SO compartilhado

Pense em contêineres como processos!

Todos os contêineres executados em um host são, de fato, vários processos com diferentes sistemas de arquivos. Eles compartilham o mesmo kernel do sistema operacional, apenas encapsulam a biblioteca e as dependências do sistema.

Isso é bom para a maioria dos casos (nenhum kernel extra do SO mantém), mas pode ser um problema se forem necessários isolamentos rigorosos entre os contêineres.

Por que isso importa?

Tudo isso parece melhorias, não revolução. Bem, a acumulação quantitativa leva à transformação qualitativa .

Pense na implantação de aplicativos. Se quisermos implantar um novo software (serviço) ou atualizar um, é melhor alterar os arquivos e processos de configuração em vez de criar uma nova VM. Como criar uma VM com serviço atualizado, testá-la (compartilhar entre Dev e QA), implantar na produção leva horas, até dias. Se algo der errado, você terá que começar de novo, perdendo ainda mais tempo. Portanto, use a ferramenta de gerenciamento de configuração (fantoche, salina, chef etc.) para instalar um novo software, é preferível o download de novos arquivos.

Quando se trata de janela de encaixe, é impossível usar um contêiner de janela de encaixe recém-criado para substituir o antigo. Manutenção é muito mais fácil! Construir uma nova imagem, compartilhá-la com o controle de qualidade, testá-la e implantá-la leva apenas alguns minutos (se tudo estiver automatizado), horas no pior caso. Isso é chamado de infraestrutura imutável : não mantenha (atualize) o software, crie um novo.

Ele transforma como os serviços são entregues. Queremos aplicativos, mas precisamos manter as VMs (o que é uma dor e pouco tem a ver com nossos aplicativos). O Docker faz você se concentrar nos aplicativos e suaviza tudo.

O Docker, basicamente contêineres, suporta a virtualização do SO, ou seja, seu aplicativo sente que possui uma instância completa de um SO, enquanto a VM suporta a virtualização de hardware . Você sente que é uma máquina física na qual pode inicializar qualquer sistema operacional.

No Docker, os contêineres em execução compartilham o kernel do sistema operacional host, enquanto nas VMs eles têm seus próprios arquivos de sistema operacional. O ambiente (o sistema operacional) no qual você desenvolve um aplicativo seria o mesmo ao implementá-lo em vários ambientes de atendimento, como "teste" ou "produção".

Por exemplo, se você desenvolver um servidor Web executado na porta 4000, ao implementá-lo no ambiente de "teste", essa porta já será usada por algum outro programa, para que pare de funcionar. Nos recipientes existem camadas; todas as alterações feitas no sistema operacional seriam salvas em uma ou mais camadas e essas camadas seriam parte da imagem; portanto, para onde a imagem for, as dependências também estarão presentes.

No exemplo mostrado abaixo, a máquina host possui três VMs. Para fornecer isolamento total às aplicações nas VMs, cada uma delas possui suas próprias cópias de arquivos, bibliotecas e códigos de aplicativos, além de uma instância completa na memória de um sistema operacional. Enquanto a figura abaixo mostra o mesmo cenário com os contêineres. Aqui, os contêineres simplesmente compartilham o sistema operacional do host, incluindo o kernel e as bibliotecas, para que não precisem inicializar um sistema operacional, carregar bibliotecas ou pagar um custo de memória privada por esses arquivos. O único espaço incremental que ocupam é a memória e o espaço em disco necessários para a execução do aplicativo no contêiner. Embora o ambiente do aplicativo pareça um sistema operacional dedicado, o aplicativo é implantado da mesma maneira que faria em um host dedicado. O aplicativo em contêiner inicia em segundos e muito mais instâncias do aplicativo podem caber na máquina do que no caso da VM.

Fonte: https://azure.microsoft.com/en-us/blog/containers-docker-windows-and-trends/

Existem três configurações diferentes que fornecem uma pilha para executar um aplicativo (Isso nos ajudará a reconhecer o que é um contêiner e o que o torna muito mais poderoso do que outras soluções):

1) Traditional Servers(bare metal)
2) Virtual machines (VMs)
3) Containers

1) A pilha tradicional de servidores consiste em um servidor físico que executa um sistema operacional e seu aplicativo.

Vantagens:

• Utilização de recursos brutos

• Isolamento

Desvantagens:

• Tempo de implantação muito lento
• Caro
• Recursos desperdiçados
• Difícil de escalar
• Difícil de migrar
• Configuração complexa

2) A pilha da VM consiste em um servidor físico que executa um sistema operacional e um hipervisor que gerencia sua máquina virtual, recursos compartilhados e interface de rede. Cada VM executa um sistema operacional convidado, um aplicativo ou conjunto de aplicativos.

Vantagens:

• Bom uso de recursos
• Fácil de escalar
• Fácil de fazer backup e migrar
• Eficiência de custos
• Flexibilidade

Desvantagens:

• A alocação de recursos é problemática
• Bloqueio do fornecedor
• Configuração complexa

3) Na Configuração do contêiner , a principal diferença com outra pilha é a virtualização baseada em contêiner que usa o kernel do sistema operacional host para analisar várias instâncias de convidado isoladas. Essas instâncias de convidado são chamadas como contêineres. O host pode ser um servidor físico ou uma VM.

Vantagens:

• Isolamento
• Leve
• Recursos eficazes
• Fácil de migrar
• Segurança
• Baixa sobrecarga
• Ambiente de produção e desenvolvimento de espelhos

Desvantagens:

• Mesma Arquitetura
• Aplicativos pesados ​​de recursos
• Problemas de rede e segurança.

Comparando a configuração do contêiner com seus predecessores, podemos concluir que a contêiner é a configuração mais rápida, mais eficiente em termos de recursos e mais segura que conhecemos até o momento. Contêineres são instâncias isoladas que executam seu aplicativo. O Docker gira o contêiner de uma maneira, as camadas obtêm memória de tempo de execução com os drivers de armazenamento padrão (drivers de sobreposição), que são executados em segundos e a camada de cópia na gravação criada por cima, assim que confirmada no contêiner, que possibilita a execução de recipientes.No caso de VMs, isso levará cerca de um minuto para carregar tudo no ambiente de virtualização. Essas instâncias leves podem ser substituídas, reconstruídas e movidas facilmente. Isso nos permite espelhar o ambiente de produção e desenvolvimento e é uma tremenda ajuda nos processos de CI / CD. As vantagens que os contêineres podem oferecer são tão atraentes que estão definitivamente aqui para ficar.

Em relação a:-

"Por que implantar software em uma imagem do docker é mais fácil do que simplesmente implantar em um ambiente de produção consistente?"

A maioria dos softwares é implantada em muitos ambientes, geralmente no mínimo três dos seguintes itens:

1. PCs de desenvolvedores individuais
2. Ambiente de desenvolvedor compartilhado
3. Testador individual PC (s)
4. Ambiente de teste compartilhado
5. Ambiente de controle de qualidade
6. Ambiente UAT
7. Teste de carga / desempenho
8. Encenação ao vivo
9. Produção
10. Arquivo

Existem também os seguintes fatores a serem considerados:

• Todos os desenvolvedores e testadores terão configurações de PC sutil ou muito diferentes, pela própria natureza do trabalho.
• Os desenvolvedores geralmente podem desenvolver em PCs fora do controle das regras corporativas ou de padronização de negócios (por exemplo, freelancers que desenvolvem em suas próprias máquinas (geralmente remotamente) ou contribuem para projetos de código aberto que não são 'empregados' ou 'contratados' para configurar seus PCs de uma certa maneira. caminho)
• Alguns ambientes consistirão em um número fixo de várias máquinas em uma configuração com balanceamento de carga
• Muitos ambientes de produção terão servidores baseados em nuvem criados e destruídos dinamicamente (ou 'elasticamente'), dependendo dos níveis de tráfego

Como você pode ver, o número total extrapolado de servidores para uma organização raramente aparece em números únicos, geralmente em números triplos e pode facilmente ser significativamente mais alto ainda.

Isso tudo significa que criar ambientes consistentes em primeiro lugar já é difícil o suficiente apenas por causa do grande volume (mesmo em um cenário de campo verde), mas mantê-los consistentes é praticamente impossível, dado o alto número de servidores, a adição de novos servidores (dinamicamente ou manualmente), atualizações automáticas de fornecedores, antivírus, navegadores e similares, instalações manuais de software ou alterações de configuração executadas por desenvolvedores ou técnicos de servidor, etc. Permitam-me repetir que - é praticamente (sem trocadilhos) impossível para manter os ambientes consistentes (ok, para os puristas, isso pode ser feito, mas envolve uma quantidade enorme de tempo, esforço e disciplina, e é exatamente por isso que VMs e contêineres (por exemplo, Docker) foram criados em primeiro lugar).

Então, pense em sua pergunta mais ou menos assim: "Dada a extrema dificuldade de manter todos os ambientes consistentes, é mais fácil implantar software em uma imagem do docker, mesmo ao considerar a curva de aprendizado?" . Eu acho que você encontrará que a resposta será invariavelmente "sim" - mas só há uma maneira de descobrir: publique esta nova pergunta no Stack Overflow.

Existem muitas respostas que explicam mais detalhadamente as diferenças, mas aqui está minha breve explicação.

Uma diferença importante é que as VMs usam um kernel separado para executar o sistema operacional . É por isso que é pesado e leva tempo para inicializar, consumindo mais recursos do sistema.

No Docker, os contêineres compartilham o kernel com o host; portanto, é leve e pode iniciar e parar rapidamente.

Na virtualização, os recursos são alocados no início da configuração e, portanto, os recursos não são totalmente utilizados quando a máquina virtual fica ociosa durante muitas vezes. No Docker, os contêineres não são alocados com uma quantidade fixa de recursos de hardware e são livres para usar os recursos, dependendo dos requisitos e, portanto, são altamente escaláveis.

O Docker usa o sistema de arquivos UNION . O Docker usa uma tecnologia de copiar na gravação para reduzir o espaço de memória consumido pelos contêineres. Leia mais aqui

Com uma máquina virtual , temos um servidor, temos um sistema operacional host nesse servidor e, em seguida, temos um hipervisor. E, em seguida, rodando sobre esse hypervisor, temos vários sistemas operacionais convidados com um aplicativo e seus binários dependentes e bibliotecas nesse servidor. Traz todo um sistema operacional convidado. É bastante pesado. Também há um limite para o quanto você pode realmente colocar em cada máquina física.

Os contêineres do Docker, por outro lado, são um pouco diferentes. Nós temos o servidor. Nós temos o sistema operacional host. Mas, em vez disso, um hipervisor , temos o mecanismo Docker , neste caso. Nesse caso, não estamos trazendo todo um sistema operacional convidado. Estamos trazendo uma camada muito fina do sistema operacional e o contêiner pode entrar no sistema operacional host para acessar a funcionalidade do kernel. E isso nos permite ter um contêiner muito leve.

Tudo o que há nele é o código do aplicativo e todos os binários e bibliotecas que ele exige. E esses binários e bibliotecas podem realmente ser compartilhados entre diferentes contêineres, se você desejar que eles também sejam. E o que isso nos permite fazer é uma série de coisas. Eles têm um tempo de inicialização muito mais rápido . Você não pode suportar uma única VM em alguns segundos assim. E igualmente, derrubando-os o mais rápido possível ... para que possamos aumentar e diminuir muito rapidamente e veremos isso mais tarde.

Todo contêiner pensa que está sendo executado em sua própria cópia do sistema operacional. Ele tem seu próprio sistema de arquivos, registro próprio, etc., o que é uma espécie de mentira. Na verdade, está sendo virtualizado.

Fonte: Kubernetes em ação.

Eu usei o Docker em ambientes de produção e preparo muito. Quando você se acostumar, você achará muito poderoso para construir um contêiner múltiplo e ambientes isolados.

O Docker foi desenvolvido com base no LXC (Linux Container) e funciona perfeitamente em muitas distribuições do Linux, especialmente no Ubuntu.

Os contêineres do Docker são ambientes isolados. Você pode vê-lo quando emite o topcomando em um contêiner do Docker que foi criado a partir de uma imagem do Docker.

Além disso, eles são muito leves e flexíveis graças à configuração do dockerFile.

Por exemplo, você pode criar uma imagem do Docker e configurar um DockerFile e informar que, por exemplo, quando estiver em execução, wget 'this', apt-get 'that', execute 'algum shell script', definindo variáveis ​​de ambiente e assim por diante.

Em projetos e arquitetura de microsserviços, o Docker é um ativo muito viável. Você pode obter escalabilidade, resiliência e elasticidade com o Docker, o Docker swarm, o Kubernetes e o Docker Compose.

Outra questão importante sobre o Docker é o Docker Hub e sua comunidade. Por exemplo, implementei um ecossistema para monitorar kafka usando Prometheus, Grafana, Prometheus-JMX-Exporter e Docker.

Para fazer isso, baixei os contêineres do Docker configurados para zookeeper, kafka, Prometheus, Grafana e jmx-collector e montei minha própria configuração para alguns deles usando arquivos YAML ou, para outros, alterei alguns arquivos e configurações no contêiner do Docker e eu construa um sistema inteiro para monitorar kafka usando Dockers de vários contêineres em uma única máquina com isolamento, escalabilidade e resiliência, para que essa arquitetura possa ser facilmente movida para vários servidores.

Além do site do Docker Hub, há outro site chamado quay.io que você pode usar para ter seu próprio painel de imagens do Docker e puxar / pressionar para / a partir dele. Você pode até importar imagens do Docker do Docker Hub para o cais e executá-las no cais em sua própria máquina.

Nota: Em primeiro lugar, aprender o Docker parece complexo e difícil, mas quando você se acostuma, não pode trabalhar sem ele.

Lembro-me dos primeiros dias de trabalho com o Docker quando emiti os comandos errados ou removi meus contêineres e todos os dados e configurações por engano.

É assim que o Docker se apresenta:

A Docker é a empresa que impulsiona o movimento de contêineres e o único provedor de plataforma de contêineres a abordar todos os aplicativos na nuvem híbrida. As empresas de hoje estão sob pressão para se transformar digitalmente, mas são limitadas por aplicativos e infraestrutura existentes, racionalizando um portfólio cada vez mais diversificado de nuvens, datacenters e arquiteturas de aplicativos. O Docker permite a verdadeira independência entre aplicativos e infraestrutura e desenvolvedores e operações de TI para liberar seu potencial e cria um modelo para melhor colaboração e inovação.

Portanto, o Docker é baseado em contêiner, o que significa que você tem imagens e contêineres que podem ser executados na sua máquina atual. Não inclui o sistema operacional como VMs , mas um pacote de diferentes pacotes de trabalho, como Java, Tomcat, etc.

Se você entende os contêineres, obtém o que é o Docker e como ele é diferente das VMs ...

Então, o que é um contêiner?

Uma imagem de contêiner é um pacote executável leve e independente de um software que inclui tudo o necessário para executá-lo: código, tempo de execução, ferramentas do sistema, bibliotecas do sistema, configurações. Disponível para aplicativos baseados em Linux e Windows, o software em contêiner sempre será o mesmo, independentemente do ambiente. Os contêineres isolam o software de seus arredores, por exemplo, diferenças entre ambientes de desenvolvimento e de armazenamento temporário e ajudam a reduzir conflitos entre equipes que executam software diferente na mesma infraestrutura.

Como você pode ver na imagem abaixo, cada contêiner possui um pacote separado e, executando em uma única máquina, compartilha o sistema operacional da máquina ... Eles são seguros e fáceis de transportar ...

Há muitas respostas técnicas interessantes aqui que discutem claramente as diferenças entre VMs e contêineres, bem como as origens do Docker.

Para mim, a diferença fundamental entre VMs e Docker é como você gerencia a promoção do seu aplicativo.

Com as VMs, você promove seu aplicativo e suas dependências de uma VM para a próxima DEV, para UAT e PRD.

1. Geralmente, essas VMs têm patches e bibliotecas diferentes.
2. Não é incomum que vários aplicativos compartilhem uma VM. Isso requer gerenciamento de configuração e dependências para todos os aplicativos.
3. A restauração requer desfazer alterações na VM. Ou restaurá-lo, se possível.

Com o Docker, a idéia é agrupar seu aplicativo dentro de seu próprio contêiner junto com as bibliotecas necessárias e, em seguida, promover todo o contêiner como uma única unidade.

1. Exceto pelo kernel, os patches e as bibliotecas são idênticos.
2. Como regra geral, há apenas um aplicativo por contêiner que simplifica a configuração.
3. O backout consiste em parar e excluir o contêiner.

Portanto, no nível mais fundamental das VMs, você promove o aplicativo e suas dependências como componentes discretos, enquanto no Docker você promove tudo em um único clique.

E sim, há problemas com os contêineres, incluindo o gerenciamento deles, embora ferramentas como Kubernetes ou Docker Swarm simplifiquem muito a tarefa.