usar - Como o Docker é diferente de uma máquina virtual?




o que é docker e para que serve (13)

Eu 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 a implantação de software em uma imagem do Docker (se esse é o termo correto) é mais fácil do que simplesmente implantar em um ambiente de produção consistente?


1. Leve

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

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

Em segundo lugar, os contêineres do Docker podem iniciar em vários milissegundos, enquanto a VM é iniciada 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, aumentar ainda mais a economia de espaço e criar mais rapidamente.

Se todos os contêineres usam o Ubuntu como imagens base, nem toda imagem tem seu próprio sistema de arquivos, mas compartilham os mesmos arquivos ubuntu de sublinhado, e só diferem em seus próprios dados de aplicativo.

3. Kernel OS Compartilhado

Pense em contêineres como processos!

Todos os contêineres em execução em um host são, na verdade, um monte de processos com diferentes sistemas de arquivos. Eles compartilham o mesmo kernel do sistema operacional, apenas encapsula a biblioteca e as dependências do sistema.

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

Por que isso importa?

Todos esses parecem 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, testando-a (compartilhamento entre Dev & QA), a implantação na produção leva horas, até dias. Se alguma coisa der errado, você tem que começar de novo, perdendo ainda mais tempo. Então, use ferramenta de gerenciamento de configuração (fantoche, sal, chef, etc) para instalar novos softwares, baixar novos arquivos é o preferido.

Quando se trata de janela de encaixe, é impossível usar um contêiner docker recém-criado para substituir o antigo. A manutenção é muito mais fácil: criar uma nova imagem, compartilhá-la com QA, testá-la, implantá-la leva apenas alguns minutos (se tudo estiver automatizado), horas no pior dos casos. Isso é chamado de infraestrutura imutável : não mantenha software (upgrade), crie um novo.

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


A maioria das respostas aqui fala sobre máquinas virtuais. Eu vou dar uma resposta de uma linha para esta questão que me ajudou mais nos últimos dois anos usando o Docker. É isso:

O Docker é apenas uma maneira sofisticada 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 fera. Eu sinto que explicar o que é o Docker ajudará você a entender isso mais do que explicar o que é uma máquina virtual. Especialmente porque há muitas respostas bem 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 é compartimentalizado usando cgroups dentro do kernel do sistema host do restante dos processos. Você pode realmente ver seus processos contêineres do Docker executando ps aux no host. Por exemplo, iniciar o apache2 "em um contêiner" está iniciando o apache2 como um processo especial no host. Ele foi compartimentado de outros processos na máquina. É importante observar que seus contêineres não existem fora do tempo de vida do seu processo em contêiner. Quando seu processo morre, seu contêiner morre. Isso é porque o Docker substitui o pid 1 dentro do seu contêiner com o seu aplicativo ( pid 1 é normalmente o sistema init). Este último ponto sobre o pid 1 é muito importante.

No que diz respeito ao sistema de arquivos usado por cada um desses processos de contêiner, o Docker usa imagens suportadas pelo UnionFS , que é o que você está baixando quando você faz um docker pull ubuntu . Cada "imagem" é apenas uma série de camadas e metadados relacionados. O conceito de camadas é muito importante aqui. Cada camada é apenas uma mudança da camada abaixo dela. Por exemplo, quando você exclui um arquivo no Dockerfile durante a criação de um contêiner do Docker, na verdade você está apenas criando uma camada na parte superior da última camada que diz "esse 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 camadas em si são apenas pacotes de arquivos. Você pode testar isso com o docker save --output /tmp/ubuntu.tar ubuntu e depois cd /tmp && tar xvf ubuntu.tar . Então você pode dar uma olhada ao redor. Todos esses diretórios que parecem hashes longos são, na verdade, as camadas individuais. Cada um contém arquivos ( layer.tar ) e metadados ( json ) com informações sobre essa camada em particular. Essas camadas apenas descrevem mudanças 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 estivessem olhando apenas para as camadas superiores de alterações. É por isso que o arquivo parece ser excluído, mesmo que ele ainda exista em 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 tenham ocorrido no sistema de arquivos nas camadas mais superiores de cada contêiner. Isso pode poupar muito espaço em disco quando seus contêineres compartilham suas camadas de imagem de base. No entanto, quando você monta diretórios e arquivos do sistema host em seu contêiner por meio de volumes, esses volumes "ignoram" o UnionFS, portanto, as alterações não são armazenadas em camadas.

A rede no Docker é obtida usando uma ponte ethernet (chamada docker0 no host) e interfaces virtuais para cada contêiner no host. Ele cria uma sub-rede virtual no docker0 para que seus contêineres se comuniquem "entre". Há 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 documentações que já vi. Geralmente é bem escrito, conciso e preciso. Eu recomendo que você verifique a documentação disponível para mais informações, e confie na documentação sobre qualquer outra coisa que você leia online, incluindo o . Se você tiver perguntas específicas, eu recomendo juntar-se ao #docker no IRC da Freenode e perguntar lá (você pode até usar o webchat da Freenode para isso!).


Através deste post, vamos desenhar 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 solicitações de CPU, memória, disco rígido, rede e outros recursos de hardware são gerenciados por uma camada de virtualização que traduz essas solicitações para o hardware físico subjacente.

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

LXC s:

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

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

Mas a grande questão é, é possível ?, será sensato?

uma. Os LXCs são definidos para uma instância do Linux. Pode ser de diferentes tipos de Linux (por exemplo, um container Ubuntu em um host CentOS, mas ainda é Linux.) Da mesma forma, contêineres baseados em Windows têm escopo para uma instância do Windows agora, se olharmos para VMs, eles têm um escopo bem mais amplo hipervisores você não está limitado a sistemas operacionais Linux ou Windows.

b. Os LXCs têm baixos custos indiretos e apresentam melhor desempenho em comparação às VMs. Ferramentas viz. O Docker, criado com base na tecnologia LXC, forneceu aos desenvolvedores uma plataforma para executar seus aplicativos e, ao mesmo tempo, capacitou as pessoas da área de operações com uma ferramenta que permitiria a implantação do mesmo contêiner em servidores de produção ou data centers. Ele tenta fazer a experiência entre um desenvolvedor executando um aplicativo, inicializando e testando um aplicativo e uma pessoa de operações implementando esse aplicativo sem problemas, porque é nesse ponto que reside toda a fricção e o objetivo do DevOps é decompor esses silos.

Portanto, a melhor abordagem é que os provedores de infraestrutura em nuvem defendam o uso adequado das VMs e do 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, as VMs e os LXCs têm sua própria existência e importância individuais.


Boas respostas. Apenas para obter uma representação da imagem do container vs VM, dê uma olhada no abaixo.

Source


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

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


O Docker não é uma metodologia de virtualização. Ele se baseia em outras ferramentas que realmente implementam a virtualização baseada em contêiner ou a virtualização em nível de sistema operacional. Para isso, o Docker estava inicialmente usando o driver LXC, depois foi movido para o libcontainer, que agora é renomeado como runc. O Docker se concentra principalmente na automação da implantação de aplicativos dentro de contêineres de aplicativos. 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êineres ou de implementação de aplicativos em sistemas contêineres.

Para saber como é diferente de outras virtualizações, vamos passar pela 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 mainframes para permitir que múltiplos aplicativos sejam executados simultaneamente. No entanto, o cenário mudou drasticamente quando as empresas e as comunidades de código aberto puderam fornecer um método para lidar com as instruções privilegiadas de uma forma ou de outra e permitir que vários sistemas operacionais fossem executados simultaneamente em um único sistema baseado em x86.

Hipervisor

O hipervisor lida com a criação do ambiente virtual no qual as máquinas virtuais convidadas operam. Ele supervisiona os sistemas 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 perceber isso, 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 das tecnologias de virtualização, principalmente na nuvem, levou o uso da virtualização ainda mais, 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. incorporação de suporte de hardware em processadores de commodity, 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 o ambiente operacional convidado. Primeiramente, 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 totalmente em software. O hipervisor usado nesse tipo é conhecido como hipervisor Tipo 2. Ele é instalado na parte superior do sistema operacional host, que é responsável por traduzir o código do kernel do sistema operacional convidado para as instruções do software. A tradução é feita inteiramente em software e não requer nenhum 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 é a sobrecarga de recursos adicionais do sistema que leva a uma redução no desempenho em comparação com outros tipos de virtualização.

Exemplos nesta categoria incluem o VMware Player, o VirtualBox, o QEMU, o Bochs, o 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 executadas nela. Ele ajuda o sistema operacional, o hardware virtualizado e o hardware real a colaborar para alcançar o desempenho ideal. Esses hipervisores geralmente têm uma pegada pequena e não requerem recursos extensos.

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. Tem o melhor desempenho e densidade possíveis e apresenta 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 visto como um grupo de processos rastreado.

O conceito de um contêiner é possibilitado pelo recurso namespaces adicionado ao kernel do Linux versão 2.6.24. O contêiner adiciona seu ID a cada processo e adiciona novas verificações de controle de acesso a todas as chamadas do sistema. Ele é acessado pela chamada de sistema clone () que permite criar instâncias separadas de namespaces globais anteriores.

Os namespaces podem ser usados ​​de muitas 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 dentro do contêiner parecem estar sendo executados 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 namespaces, 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 para habilitar a virtualização baseada em contêiner, é usado para agrupar processos e gerenciar seu consumo agregado de recursos. É comumente usado para limitar a memória e o consumo de CPU dos contêineres. Como um sistema Linux conteinerizado tem apenas um kernel e o kernel tem visibilidade total dos contêineres, existe apenas um nível de alocação e agendamento de recursos.

Várias ferramentas de gerenciamento estão disponíveis para containers 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 única 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 planejador da máquina host, economizando a necessidade de recursos extras.

Os estados de contêiner (imagens Docker ou LXC) são pequenos em comparação com as imagens de máquinas virtuais, portanto, as imagens de contêiner são fáceis de distribuir.

O gerenciamento de recursos em contêineres é obtido por meio de cgroups. O Cgroups não permite que os contêineres consumam mais recursos do que os alocados para eles. No entanto, a partir de agora, todos os recursos da máquina host são visíveis em máquinas virtuais, mas não podem ser usados. Isso pode ser feito executando top ou htop em containers e host machine 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 forem possíveis por causa dos recursos disponíveis no kernel do Linux, a questão óbvia é como os sistemas não-Linux executam contêineres. O Docker para Mac e o Windows usam as VMs do Linux para executar os contêineres. Docker Toolbox usado para executar contêineres em VMs de caixa virtual. Mas o mais recente Docker usa o Hyper-V no Windows e o Hypervisor.framework no Mac.

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

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

A VM do Linux que o Docker executa no Mac é somente leitura. No entanto, você pode bater 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 dessa VM.

Existem algumas limitações para hypervisor.framework. Por causa disso, o Docker não expõe a interface de rede docker0 no Mac. Portanto, você não pode acessar contêineres do host. A partir de agora, docker0 está disponível apenas 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.


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 na 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 MV assume o anel da CPU 0 (ou o "modo raiz" em CPUs mais recentes) e intercepta todas as chamadas privilegiadas feitas pelo sistema operacional convidado para criar a ilusão de que o sistema operacional convidado possui seu próprio hardware. Curiosidade: Antes de 1998, era impossível conseguir isso na arquitetura x86, porque não havia como fazer esse tipo de interceptação. O pessoal da VMWare foi o primeiro que teve a idéia de reescrever os bytes executáveis ​​na memória para chamadas privilegiadas do sistema operacional convidado para conseguir isso.

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

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

Por volta de 2006 , pessoas incluindo alguns dos funcionários do Google implementaram um novo recurso de nível de kernel chamado namespaces (no entanto, a idéia existia long antes no FreeBSD ). Uma função do sistema operacional é permitir o compartilhamento de recursos globais, como rede e disco, nos processos. E se esses recursos globais fossem agrupados em namespaces para que eles sejam visíveis apenas para os processos executados no mesmo namespace? Digamos que você consiga um pedaço de disco e coloque-o no espaço de nomes X e, em seguida, os processos em execução no namespace Y não podem ver ou acessá-lo. Da mesma forma, os processos no namespace X não podem acessar nada na memória alocada para o namespace Y. É claro que os processos no X não podem ver ou falar com processos no namespace Y. Isso fornece virtualização e isolamento para recursos globais. É assim que o docker funciona: Cada contêiner é executado em seu próprio namespace, mas usa exatamente o mesmo kernel que todos os outros contêineres. O isolamento acontece porque o kernel conhece o namespace que foi atribuído ao processo e, durante as chamadas de API, garante que o processo possa acessar apenas recursos em seu próprio namespace.

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 em VMs. No entanto, você pode executar diferentes distros do Linux, porque eles compartilham o mesmo kernel. O nível de isolamento não é tão forte quanto na VM. Na verdade, havia uma maneira de o contêiner "guest" assumir o host nas implementações iniciais. Além disso, você pode ver que quando você carrega um novo contêiner, toda a nova cópia do sistema operacional não inicia como na VM. Todos os contêineres compartilham o mesmo kernel . É por isso que os contêineres são leves. Além disso, ao contrário da VM, você não precisa pré-alocar partes significativas de memória para os contêineres porque não estamos executando uma nova cópia do sistema operacional. Isso permite executar milhares de contêineres em um sistema operacional durante o uso do 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.


Em relação a:-

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

A maioria dos softwares é implantada em muitos ambientes, normalmente um mínimo de três dos seguintes:

  1. PC (s) de desenvolvedor individual
  2. Ambiente de desenvolvedor compartilhado
  3. PC testador individual
  4. Ambiente de teste compartilhado
  5. Ambiente de controle de qualidade
  6. Ambiente UAT
  7. Teste de carga / desempenho
  8. Live staging
  9. Produção
  10. Arquivo

Existem também os seguintes fatores a considerar:

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

Como você pode ver, o número total de servidores extrapolados para uma organização raramente está em números únicos, é muito frequentemente em números triplos e pode ser ainda significativamente maior ainda.

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

Portanto, pense em sua pergunta mais como isso: "Dada a extrema dificuldade de manter todos os ambientes consistentes, é mais fácil implantar software em uma imagem de encaixe, mesmo considerando a curva de aprendizado?" . Acho que você descobrirá que a resposta será invariavelmente "sim" - mas só há uma maneira de descobrir, postar essa nova pergunta no .


Há muitas boas respostas técnicas 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 as VMs e o Docker é como você gerencia a promoção de seu aplicativo.

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

  1. Muitas vezes, essas VMs terão diferentes patches e bibliotecas.
  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. O backout requer a remoção de alterações na VM. Ou restaurando se possível.

Com o Docker, a idéia é que você empacote seu aplicativo dentro de seu próprio contêiner junto com as bibliotecas necessárias e depois promova o contêiner inteiro como uma única unidade.

  1. Exceto pelo kernel, os patches e bibliotecas são idênticos.
  2. Como regra geral, há apenas um aplicativo por contêiner que simplifica a configuração.
  3. 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 distintos, enquanto no Docker você promove tudo em um único hit.

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


Há 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 . Essa é a razão pela qual é pesado e leva tempo para inicializar, consumindo mais recursos do sistema.

No Docker, os contêineres compartilham o kernel com o host; por isso, é leve e pode começar 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 inativa durante muitas das vezes. No Docker, os contêineres não são alocados com quantidade fixa de recursos de hardware e estão livres para usar os recursos, dependendo dos requisitos e, portanto, são altamente escalonáveis.

O Docker usa o sistema UNION File . O Docker usa uma tecnologia copy-on-write para reduzir o espaço de memória consumido pelos contêineres. Leia mais aqui


Fonte: Kubernetes em ação.


Com uma máquina virtual , temos um servidor, temos um sistema operacional hospedeiro nesse servidor e, em seguida, temos um hipervisor. E, em seguida, executando em cima desse hipervisor, temos qualquer número de sistemas operacionais convidados com um aplicativo e seus binários dependentes e bibliotecas nesse servidor. Ele traz todo um sistema operacional convidado com ele. É muito pesado. Também há um limite para o quanto você pode realmente colocar em cada máquina física.

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

Tudo o que tem lá é o código do aplicativo e quaisquer binários e bibliotecas que ele requer. E esses binários e bibliotecas podem, na verdade, ser compartilhados em diferentes contêineres, se você quiser que eles sejam também. E o que isso nos permite fazer é uma série de coisas. Eles têm tempo de inicialização muito mais rápido . Você não pode levantar uma única VM em alguns segundos assim. E igualmente, derrubá-los o mais rápido possível. Assim, podemos aumentar e diminuir muito rapidamente e veremos isso mais tarde.

Cada contêiner acha 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, ele está sendo virtualizado.


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

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

Por exemplo, se você desenvolver um servidor da Web que seja executado na porta 4000, ao implantá-lo em seu ambiente de "teste", essa porta já será usada por algum outro programa, portanto, ele deixará de funcionar. Em contêineres existem camadas; Todas as alterações que você fez no sistema operacional seriam salvas em uma ou mais camadas e essas camadas seriam parte da imagem, assim, onde quer que a imagem esteja, as dependências também estarão presentes.

No exemplo mostrado abaixo, a máquina host possui três VMs. Para fornecer aos aplicativos no isolamento completo das VMs, cada um deles tem suas próprias cópias de arquivos do sistema operacional, bibliotecas e código do aplicativo, juntamente com uma instância completa na memória de um sistema operacional.Considerando que a figura abaixo mostra o mesmo cenário com 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 para esses arquivos. O único espaço incremental que eles ocupam é qualquer memória e espaço em disco necessários para o aplicativo ser executado no contêiner. Embora o ambiente do aplicativo pareça um SO dedicado, o aplicativo é implementado da mesma forma que em um host dedicado. O aplicativo conteinerizado é iniciado em segundos e muitas outras 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/





virtualization