Como É Que o Docker é diferente de uma máquina virtual?

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

Fonte: https://www.docker.com/what-container#/package_software

Pode ser útil compreender como a virtualização e os contentores funcionam a baixo nível. Isso esclarecerá muitas coisas. Nota: estou simplificando um pouco na descrição abaixo. Veja referências para mais informações.

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

Neste caso, o VM manager assume o anel de CPU 0 (ou o" root mode " em CPUs mais recentes) e intercepta todas as chamadas privilegiadas feitas pelo guest OS para criar ilusão de que o guest OS tem o seu próprio hardware. Diversao fato: antes de 1998 pensava-se ser impossível conseguir isso na arquitetura x86 porque não havia maneira de fazer esse tipo de interceptação. O pessoal do VMWare foi o primeiro {[11] } que teve uma ideia de reescrever os bytes executáveis em 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 so completamente diferentes no mesmo hardware. Cada sistema operacional guest passa por todo o processo de inicialização, carregamento de kernel etc. Você pode ter uma segurança muito apertada, por exemplo, guest OS não pode ter acesso total ao host OS ou outros hóspedes e estragar as coisas.

Como funcionam os contentores a um nível baixo?

Por aí.2006, pessoas incluindo alguns dos funcionários do Google implementaram uma nova funcionalidade de nível de kernel chamada namespaces (no entanto, a idea long antes de existir no FreeBSD ). Uma função do SO é permitir o compartilhamento de recursos globais como rede e disco para processo. E se esses recursos globais foram embrulhados em espaços de nomes para que eles sejam visíveis apenas para aqueles processos que funcionam no mesmo espaço de nomes? Diga, você pode obter um pedaço de disco e colocá-lo no espaço de nomes X e, em seguida, processos em execução no espaço de nomes Y não pode vê-lo ou acessá-lo. Da mesma forma, os processos no espaço de nomes X não podem acessar nada na memória que é alocado ao espaço de nomes Y. naturalmente, os processos em X não podem ver ou falar com processos no espaço de nomes Y. isto fornece um tipo de virtualização e isolamento para recursos globais. É assim que o docker funciona: cada contentor funciona no seu próprio espaço de nomes, mas usa exactamente o mesmo como todos os outros contentores. O isolamento acontece porque o kernel conhece o espaço de nomes que foi atribuído ao processo e durante as chamadas da API ele garante que o processo só pode acessar recursos em seu próprio espaço de nomes.

As limitações dos contentores vs VM devem ser óbvias agora: não se pode rodar um so completamente diferente em contentores como no VMs. Entanto você Pode executar diferentes distros do Linux porque eles compartilham o mesmo kernel. O nível de isolamento não é tão forte como no VM. Na verdade, havia uma maneira para o container "convidado" assumir host em implementações iniciais. Também você pode ver que quando você carrega um novo container, toda a nova cópia do OS não começa como ele faz em VM. Todos os contentores partilham o mesmo núcleo . É por isso que os contentores são leves. Também ao contrário da VM, você não tem que pré-alocar um pedaço significativo de memory to containers because we are not running new copy of OS. Isso permite executar milhares de contêineres em um SO enquanto sandboxing-los que pode não ser possível fazer se estávamos executando uma cópia separada do SO em seu próprio VM.

Gosto da resposta do Ken Cochrane. Mas eu quero acrescentar um ponto de vista adicional, não coberto em detalhes aqui. Na minha opinião, o Docker também difere em todo o processo. Em contraste com o VMs, o Docker não é (apenas) sobre a partilha óptima de recursos de hardware, além disso fornece um "sistema" para a aplicação de embalagens (preferível, mas não uma obrigação, como um conjunto de micro-serviços).

Para mim, encaixa-se na lacuna entre ferramentas orientadas para programadores como rpm, pacotes Debian , Maven, MPN + Git de um lado e ferramentas de operações como Puppet , VMware, Xen, o que quiseres...

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

A sua pergunta pressupõe um ambiente de produção consistente. Mas como mantê-lo consistente? Considere alguma quantidade (>10) de servidores e aplicações, estágios no pipeline. Para manter isto dentro sync você vai 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 correr indefinidamente, e ser mantidos completamente consistentes e atualizados. A prática falha em Gerenciar a configuração de um servidor completamente, então há um escopo considerável para a deriva de configuração, e mudanças inesperadas em servidores em execução. Então há um padrão conhecido para evitar isto, o chamado imutável servidor. Mas o padrão imutável do servidor não era amado. Principalmente por causa das limitações de VMs que foram usadas antes do Docker. Lidar com várias imagens grandes gigabytes, movendo essas imagens grandes ao redor, apenas para mudar alguns campos na aplicação, foi muito trabalhoso. Compreensivel... Com um ecossistema de acopladores, você nunca precisará se mover em torno de gigabytes em "pequenas mudanças" (agradecimentos aufs e registro) e você não precisa se preocupar com a perda de desempenho por embalagem aplicações em um recipiente de Docker no tempo de execução. Você não precisa se preocupar com versões dessa imagem.

E, finalmente, muitas vezes, até será capaz de reproduzir ambientes de produção complexos mesmo no seu portátil Linux (não me ligue se não funcionar no seu caso;)

E é claro que você pode iniciar contentores de Docker em VMs (é uma boa ideia). Reduza o fornecimento do servidor no nível VM. Tudo isso pode ser gerido pelo Docker.

P. S. Entretanto, o Docker usa o seu implementação própria "libcontainer" em vez de LXC. Mas o LXC ainda pode ser usado.

O Docker não é uma metodologia de virtualização. Ele se baseia em outras ferramentas que realmente implementam virtualização baseada em container ou virtualização de nível do sistema operacional. Para isso, o Docker estava inicialmente usando o driver LXC, então transferido para a libcontainer, que agora é renomeado como runc. Docker se concentra principalmente em automatizar a implantação de aplicações dentro de recipientes de Aplicação. Os recipientes de aplicação são concebidos para embalar e executar um único serviço, enquanto os recipientes do sistema são concebidos para executar vários processos, como máquinas virtuais. Assim, o Docker é considerado como uma ferramenta de gerenciamento de contêineres ou de implementação de aplicações em sistemas contentorizados. 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.

Virtualização

Na sua forma concebida, foi considerado um método de divisão lógica dos mainframes para permitir que múltiplos aplicações para executar simultaneamente. No entanto, o cenário mudou drasticamente quando as empresas e as comunidades de código aberto foram capazes de fornecer um método para lidar com as instruções privilegiadas, de uma forma ou de outra, e permitir que vários sistemas operacionais sejam executados simultaneamente em um único sistema com base em x86.

Hipervisor

O hypervisor lida com a criação do ambiente virtual no qual as máquinas virtuais clientes operam. Supervisiona os sistemas de hóspedes e faz certifique-se de que os recursos são alocados aos hóspedes, conforme necessário. O hypervisor situa-se 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, intercepta as operações do sistema operacional convidado nas máquinas virtuais e emula a operação no sistema operacional da máquina hospedeira. O rápido desenvolvimento das tecnologias de virtualização, principalmente na nuvem, tem impulsionado o uso da virtualização, permitindo vários servidores virtuais a serem criados em um único servidor físico com a ajuda de hipervisores, como Xen, VMware Player, KVM, etc., e a incorporação de suporte de hardware em processadores de mercadorias, tais como Intel VT e AMD-V.

Tipos De Virtualização

O método de virtualização pode ser categorizado com base na forma como imita o hardware a um sistema operacional convidado e emula o ambiente operacional convidado. Em primeiro lugar, existem três tipos de virtualização:

• emulação
• paravirtualização
• virtualização baseada em contentores

Emulação

A emulação, também conhecida como virtualização completa, executa o núcleo virtual do sistema operacional inteiramente em software. O hipervisor usado neste tipo é conhecido como hipervisor tipo 2. Ele está instalado no topo do sistema operacional host, que é responsável por traduzir o código do kernel guest OS para instruções de software. A tradução está feita. totalmente em software e não requer nenhum envolvimento de hardware. A emulação torna possível executar qualquer sistema operacional não modificado que suporte o ambiente sendo emulado. A desvantagem deste tipo de virtualização é a sobrecarga adicional de recursos do sistema que leva à diminuição do desempenho em comparação com outros tipos de virtualizações.

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

Paravirtualização

A paravirtualização, também conhecida como Hypervisor tipo 1, funciona diretamente no hardware, ou "bare-metal", e fornece serviços de virtualização diretamente para as máquinas virtuais que rodam nele. Ele ajuda o sistema operacional, o hardware virtualizado e o hardware real a colaborar para alcançar o desempenho ideal. Estes hipervisores normalmente têm uma pegada bastante pequena e não, eles próprios, exigem extensa recurso.

Exemplos nesta categoria incluem Xen, KVM, etc.

Virtualização baseada em contentores

Virtualização baseada em contêineres, também conhecida como virtualização de nível do sistema operacional, permite várias execuções isoladas dentro de um único núcleo do sistema operacional. Ele tem o melhor desempenho possível e densidade e recursos de gestão dinâmica de recursos. O ambiente de execução virtual isolado fornecido por este tipo de virtualização é chamada de container e pode ser visto como um grupo de processos traçados.

O conceito de um recipiente é possível pela funcionalidade de espaços de nomes adicionada à versão 2.6.24 do kernel Linux. O container adiciona seu ID a cada processo e adicionando novas verificações de controle de acesso a cada chamada do sistema. Ele é acessado pelo clone () system call que permite a criação de instâncias separadas de espaços de nomes previamente globais.

Podem ser usados espaços de nomes de muitas maneiras diferentes, mas a abordagem mais comum é criar um recipiente isolado que não tem visibilidade ou acesso a objetos fora do recipiente. Processos rodando dentro do recipiente parecem estar rodando em um sistema Linux normal, embora eles estejam compartilhando o núcleo subjacente com processos localizados em outros espaços de nomes, o mesmo para outros tipos de objetos. Por exemplo, ao usar espaços de nomes, o usuário root dentro do container não é tratado como root fora do container, adicionando segurança adicional.

O subsistema "grupos de controlo Linux" (cgroups), próximo componente principal para permitir a virtualização baseada em contentores, é usado para agrupar processos e gerir o seu consumo agregado de recursos. É comumente usado para limitar o consumo de memória e CPU de contêineres. Uma vez que um sistema Linux contém apenas um kernel e o kernel tem plena visibilidade para os containers, há apenas um nível de alocação de recursos e agendamento.

[7] ferramentas estão disponíveis para Linux containers, incluindo LXC, LXD, systemd-nspawn, lmctfy, Warden, Linux-VServer, OpenVZ, Docker, etc.

Containers vs Máquinas Virtuais

Ao contrário de uma máquina virtual, um recipiente não precisa de arrancar o kernel do sistema operativo, por isso os recipientes podem ser criados em menos de um segundo. Esta característica torna a virtualização baseada em contêineres única e desejável do que outras abordagens de virtualização.

Desde que a virtualização baseada em contentores adiciona pouca ou nenhuma sobrecarga para a máquina anfitriã, a virtualização baseada em contentores tem um desempenho quase nativo

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

Todos os contentores numa máquina anfitriã partilham o escalonador da máquina anfitriã poupando a necessidade de recursos adicionais.

Os Estados do contentor (imagens do acoplador ou do LXC) são pequenos em comparação com as imagens das máquinas virtuais, pelo que as imagens do contentor são fáceis de utilizar. distribuir.

A gestão dos recursos em contentores é conseguida através dos cgroups. Os Cgroups não permitem que os contentores consumam mais recursos do que os que lhes são atribuídos. 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. Isto pode ser realizado executando {[[0]} ou htop em contentores e máquinas hospedeiras ao mesmo tempo. A saída em todos os ambientes será semelhante.

Actualização:

Como É Que A Docker gere contentores em sistemas não-Linux?

Se os containers são possíveis por causa das características disponíveis no kernel Linux, então a questão óbvia é que como os sistemas não-Linux executam containers. Tanto o Docker para Mac como o Windows usam o Linux VMs para executar os containers. A caixa de ferramentas do acoplador utilizada para executar contentores em VMs de caixa Virtual. Mas, o último Atracador usa Hiper-V nas janelas e hipervisor.framework in Mac.

Agora, deixe-me descrever como o Docker do Mac gere os contentores em detalhe. Acoplador para utilizações Mac https://github.com/moby/hyperkit para emular as capacidades de hipervisor e o Hyperkit usa o hypervisor.estrutura no seu núcleo. Hipervisor.framework é a solução de hipervisor nativa de Mac. Hyperkit também usa VPNKit e DataKit para a rede de espaços de nomes e sistema de arquivos, respectivamente.

O VM Linux que o Docker executa no Mac é apenas para leitura. No entanto, você pode bater nele correndo:

screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty. Agora, podemos até verificar a versão do Kernel deste VM:

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

Todos os contentores correm dentro deste VM.

Há algumas limitações no hipervisor.quadro. Por causa daquele Ancoradouro não expõe a interface de rede no Mac. Então, não podes aceder a contentores do hospedeiro. A partir de agora, docker0 só está disponível dentro da VM. Hiper-V é o hipervisor nativo nas janelas. Eles também estão tentando alavancar as capacidades do Windows 10 para executar sistemas Linux nativamente.

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 físico de computação, mas os pedidos de CPU, memória, disco rígido, rede e outros recursos de hardware são geridos por uma camada de virtualização que traduz estes pedidos para o hardware físico subjacente.

Neste contexto, a VM é chamada de hóspede, enquanto o ambiente em que funciona é liguei para o anfitrião.

LXC s:

Os Containers Linux (LXC) são capacidades operacionais ao nível do sistema que permitem executar vários containers Linux isolados, numa máquina de controlo (a máquina LXC). Os Containers Linux servem como uma alternativa leve ao VMs, uma vez que eles não requerem o hipervisors viz. Virtualbox, KVM, Xen, etc.

Agora, a menos que tenha sido drogado pelo Alan (Zach Galifianakis-da série de ressaca) e tenha estado em Vegas durante o último ano, será bastante ciente sobre o tremendo surto de interesse para a tecnologia de containers Linux, e se eu vou ser específico um projeto de container que criou um zumbido ao redor do mundo nos últimos meses is – Docker levando a algumas opiniões ecoando que os ambientes de computação em nuvem devem abandonar máquinas virtuais (VMs) e substituí-los por containers devido à sua baixa sobrecarga e potencialmente melhor desempenho. Mas a grande questão é: será possível? será sensato?

A. LXCs são escopiados para uma instância do Linux. Pode ser diferentes sabores do Linux (por exemplo, um recipiente Ubuntu em um host de CentOS, mas ainda é Linux. Da mesma forma, os recipientes baseados no Windows são escopiados para uma instância do Windows agora se olharmos para o VMs eles têm um escopo bastante mais amplo e usando os hipervisores você não está limitado a sistemas operacionais Linux ou Windows.

B. LXCs têm custos gerais baixos e melhor desempenho em comparação com VMs. Ferramentas viz. Ancoradouro construído sobre os ombros de A tecnologia LXC forneceu aos desenvolvedores uma plataforma para executar suas aplicações e, ao mesmo tempo, capacitou as pessoas de operações com uma ferramenta que lhes permitirá implantar o mesmo contêiner em servidores de produção ou centros de dados. Ele tenta fazer a experiência entre um desenvolvedor executando uma aplicação, inicializando e testando uma aplicação e uma pessoa de operações implantando essa aplicação sem descontinuidade, porque é aqui que todo o atrito está e o propósito do DevOps é quebrar aqueles silos.

A melhor abordagem é que os fornecedores de infra-estruturas nas nuvens devem defender uma utilização adequada do VMs e do LXC, uma vez que cada um deles é adequado para lidar com cargas de trabalho e cenários específicos.

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

A maioria das respostas aqui fala de máquinas virtuais. Vou dar - lhe uma resposta de um liner a esta pergunta que me ajudou mais nos últimos dois anos a usar o Docker. É isto:

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

Agora, deixe-me explicar um pouco mais sobre o que isso significa. As máquinas virtuais são a sua própria besta. Apetece-me explicar-te o que o Docker vai ajudar-te a entender mais isto. do que explicar o que é uma máquina virtual. Especialmente porque há muitas boas respostas aqui dizendo exatamente o que alguém quer dizer quando diz "máquina virtual". Entao...

Um contentor do acoplador é apenas um processo (e os seus filhos) que é compartimentalizado usando cgroups dentro do núcleo do sistema hospedeiro a partir do resto dos processos. Você pode realmente ver os seus processos de container Docker executando ps aux na máquina. Por exemplo, começar apache2 "num recipiente" é apenas começando apache2 como um processo especial na máquina. Foi separado de outros processos na máquina. É importante notar que seus contêineres não existem fora do tempo de vida de seu processo contido. Quando o processo morre, o contentor morre. Isso porque o Docker substitui pid 1 dentro do seu recipiente com a sua aplicação (pid 1 é normalmente o sistema init). Este último ponto sobre pid 1 é muito importante.

Até ao sistema de ficheiros utilizado por cada um dos processos de container, o Docker usa UnionFS - imagens suportadas, que é o que está a transferir quando 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 por baixo dela. Por exemplo, quando você apaga um arquivo em seu Dockerfile ao construir um container Docker, você está realmente apenas criando uma camada no topo da última camada que diz "Este arquivo foi excluído". Alias, é 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 bolas de alcatrão de arquivos. Podes testar isto com docker save --output /tmp/ubuntu.tar ubuntu e depois cd /tmp && tar xvf ubuntu.tar. Depois podes dar uma vista de olhos. Todos aqueles diretórios que se parecem com hashs longos são na verdade as camadas individuais. Cada um contém ficheiros (layer.tar) e metadados (json) com informação sobre esse particular camada. Essas camadas apenas descrevem mudanças no sistema de arquivos que são salvos como uma camada "no topo" de seu estado original. Ao ler os dados "atuais", o sistema de arquivos lê os dados como se estivesse olhando apenas para a maioria das camadas de mudanças. É por isso que o arquivo parece ser excluído, mesmo que ainda exista em camadas "anteriores", porque o sistema de arquivos está apenas olhando para a maioria das camadas. Isto permite que contentores completamente diferentes partilhem as suas camadas do sistema de Ficheiros, mesmo que alguns mudanças significativas podem ter acontecido com o sistema de arquivos no topo-a maioria das camadas em cada recipiente. Isto pode poupar-lhe uma tonelada de espaço em disco, quando os seus contentores partilham as suas camadas de imagem base. No entanto, quando você montar diretórios e arquivos do sistema host em seu recipiente por meio de volumes, esses volumes "bypass" os UnionFS, de modo que as mudanças não são armazenados em camadas.

A ligação em rede no 'Docker' é conseguida utilizando uma Ponte ethernet (chamada docker0 no servidor), e interfaces virtuais para todos os contentores do hospedeiro. Cria uma sub-rede virtual em docker0 para que os seus contentores se comuniquem "entre" uns aos outros. Existem muitas opções para trabalhar em rede aqui, incluindo a criação de sub-redes personalizadas para os seus contentores, e a capacidade de "partilhar" a pilha de rede do seu host para o seu contentor aceder directamente.

O Docker está a mover-se muito depressa. A sua documentação é a melhor documentação que já vi. É geralmente bem escrito, conciso e preciso. I recomendo que você verifique a documentação disponível para mais informações, e confie na documentação sobre qualquer outra coisa que você leu on-line, incluindo estouro de pilha. Se você tem perguntas específicas, eu recomendo juntar #docker no IRC Freenode e fazer lá (você pode até usar o webchat do Freenode para isso!).

O 'Docker' encapsula uma aplicação com todas as suas dependências.

Um virtualizador encapsula um SO que pode executar quaisquer aplicações que possa normalmente executar numa máquina de metal nua.

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

Docker e LXC significam mais para sandboxing, contenção e isolamento de recursos. Ele usa a API de clone do sistema operacional (atualmente apenas Linux), que fornece namespacing para IPC, NS (mount), network, PID, UTS, etc.

E a memória?, CPU, etc.? Isso é controlado usando cgroups onde você pode criar grupos com determinado recurso (CPU, memória, etc.) Especificação / restrição e colocar seus processos lá. No topo do LXC, o Docker fornece uma infra-estrutura de armazenamento ( http://www.projectatomic.io/docs/filesystems/) por exemplo, o sistema de ficheiros union mount, onde pode adicionar camadas e partilhar camadas entre diferentes espaços de nomes de mount.

Esta é uma característica poderosa onde as imagens de base são normalmente lidas apenas e apenas quando o recipiente modifica alguma coisa na camada que irá escrever alguma coisa para ler-escrever partição (t. c. p.copy on write). Ele também fornece muitas outras embalagens, como registro e versionamento de imagens.

Com o LXC normal, você precisa vir com alguns rootfs ou compartilhar os rootfs e quando compartilhado, e as mudanças são refletidas em outros recipientes. Devido a muitos destes recursos adicionados, o Docker é mais popular do que o LXC. LXC é popular em ambientes embutidos para implementar a segurança em torno de processos expostos a entidades externas como a rede e a IU. O Docker é popular no ambiente cloud multi-tenancy, onde um ambiente de produção consistente é esperado.

Um VM normal (por exemplo, VirtualBox e VMware) usa um hipervisor, e tecnologias relacionadas ou têm firmware dedicado que se torna a primeira camada para o primeiro So (host OS, ou guest OS 0) ou um software que funciona no sistema operacional host para fornecer emulação de hardware, tais como CPU, USB/acessórios, memória, rede, etc., para os SOS convidados. VMs são ainda (a partir de 2015) populares em ambiente multi-inquilinos de alta segurança.

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

Aqui está uma foto do docker / rightscale. :

1. Lightweight

Esta é provavelmente a primeira impressão para muitos aprendizes de Estivador.

Primeiro, as imagens do acoplador são geralmente menores que as imagens VM, o que torna mais fácil construir, Copiar, Partilhar.

Em segundo lugar, os contentores do Docker podem começar em vários milissegundos, enquanto o VM começa em segundos.

2. Sistema De Ficheiros Em Camadas

Esta é outra característica chave do Docker. As imagens têm camadas, e diferentes imagens podem compartilhar camadas, torná - lo ainda mais economizador de espaço e mais rápido para construir.

Se todos os contentores usam o Ubuntu como suas imagens de base, nem todas as imagens têm o seu próprio sistema de ficheiros, mas partilham os mesmos ficheiros do Ubuntu sublinhado, e só diferem nos seus próprios dados de Aplicação.

3. Núcleo do sistema operacional partilhado

Pense nos contentores como processos!

Todos os contentores que funcionam num host são, de facto, um monte de processos com sistemas de ficheiros diferentes. Eles compartilham o mesmo kernel do SO, apenas encapsula biblioteca de sistema e dependências.

Isto é ... bom para a maioria dos casos(Nenhum kernel extra OS mantém), mas pode ser um problema se isolações rigorosas são necessárias entre recipientes. Porque é que isso importa? Tudo isto parece uma melhoria, Não uma revolução. Bem, a acumulação quantitativa conduz a uma transformação qualitativa.

Pensa na implantação das aplicações. Se queremos implantar um novo software(serviço) ou atualizar um, é melhor mudar os arquivos de configuração e processos em vez de criar um novo VM. Porque Criar um VM com serviço atualizado, testá-lo(partilha entre Dev & QA), implantar para a produção leva horas, mesmo dias. Se alguma coisa correr mal, tens de começar de novo, a perder ainda mais tempo. Então, use a ferramenta de gerenciamento de configuração (puppet,saltstack, chef etc.) para instalar um novo software, é preferível baixar novos arquivos.

No que diz respeito ao docker, é impossível usar um contentor novo para substituir o antigo. A manutenção é muito mais fácil!Construir uma nova imagem, partilhá-la com QA, testá-lo, implantá-lo só leva minutos(se tudo é automatizado), horas no pior caso. Isto é chamado infra-estrutura imutável: não mantenha(upgrade) software, crie um novo em vez disso. Transforma a forma como os Serviços são prestados. Queremos aplicações, mas temos de manter o VMs(o que é uma dor e tem pouco a ver com as nossas aplicações). O Docker faz-te concentrar em aplicações e suaviza tudo.

O 'Docker', basicamente contentores, suportaa virtualização do ' Os ', ou seja, a sua aplicação sente que tem uma instância completa de um sistema operacional, enquanto que o ' VM 'suportaa virtualização do 'hardware' . Você sente como se fosse uma máquina física na qual você pode arrancar qualquer so.

Na Docker, os contentores em execução partilham o kernel do sistema operacional, enquanto que em VMs têm os seus próprios ficheiros de SO. O ambiente (o SO) no qual você desenvolve uma aplicação seria o mesmo quando você a implanta para vários ambientes de serviço, tais como "testing" ou "production".

Por exemplo, se você desenvolver um servidor web que corre na porta 4000, quando você o implanta no seu ambiente de "teste", essa porta já é usada por algum outro programa, então ela deixa de funcionar. Em containers existem camadas; todas as mudanças que você fez para o SO seriam salvos em uma ou mais camadas e essas camadas seriam parte da imagem, então onde quer que a imagem vai as dependências estariam presentes também.

No exemplo mostrado abaixo, a máquina hospedeira tem três VMs. A fim de fornecer as aplicações no VMs completo isolamento, cada um deles tem suas próprias cópias de arquivos de SO, bibliotecas e código de aplicação, juntamente com uma instância completa em memória de um SO. Considerando que a figura abaixo mostra o mesmo cenário com os contêineres. Aqui, containers simplesmente compartilham o sistema operacional host, incluindo o kernel e bibliotecas, para que eles não precisem arrancar um SO, carregar bibliotecas ou pagar um custo de memória privada para arquivo. O único espaço incremental que eles levam é qualquer espaço de memória e disco necessário para a aplicação correr no recipiente. Enquanto o ambiente da aplicação se sente como um SO dedicado, a aplicação implementa exatamente como seria em um host dedicado. A aplicação contendo começa em segundos e muitas mais instâncias da aplicação podem caber na máquina do que no caso VM.

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

Em relação a: -

"Porque é que a implantação de software para uma imagem de docker é mais fácil do que simplesmente implantação para um ambiente de produção consistente ?"

A maior parte do software é implantado em muitos ambientes, tipicamente um mínimo de três dos seguintes:

1. desenvolvimento individual PC(s)
2. Ambiente de desenvolvimento Partilhado
3. Testador individual PC(s)
4. Ambiente de ensaio Partilhado
5. ambiente QA
6. UAT ambiente
7. ensaio de carga / desempenho
8. encenação ao vivo
9. Produção
10. Arquivo

Há também os seguintes factores a considerar:

• Os programadores, e mesmo os testadores, terão todas configurações de PC subtileza ou vastamente diferentes, pela própria natureza do trabalho
• Os promotores de projectos podem muitas vezes desenvolver-se em PC para além do controlo das regras de normalização das empresas ou das empresas (por exemplo, trabalhadores à tarefa que desenvolvem por conta própria máquinas (muitas vezes remotamente) ou contribuidores para projectos de código aberto que não são "empregados" ou "contratados" para configurar os seus PCs de uma determinada Forma)
• alguns ambientes consistirão num número fixo de máquinas múltiplas numa configuração de carga equilibrada
• 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 pode ver o número total extrapolado de servidores para um fornecedores e similares, instalação manual de software ou mudanças de configuração realizadas por desenvolvedores ou técnicos de servidores, etc. Deixe - me repetir que-é virtualmente (sem trocadilhos) impossível manter ambientes consistentes (OK, para o purista, pode ser feito, mas envolve uma enorme quantidade de tempo, esforço e disciplina, que é precisamente por isso que VMs e contêineres (por exemplo, Docker) foram concebidos em primeiro lugar).

Então pensa na tua pergunta mais assim dado o extremo dificuldade de manter todos os ambientes consistentes, é mais fácil implantar software para uma imagem de docker, mesmo tendo em conta a curva de aprendizagem ?". Eu acho que você vai encontrar a resposta será invariavelmente "Sim" - mas só há uma maneira de descobrir, postar esta nova pergunta no Stack Overflow.

Existem três configurações diferentes que fornecem uma pilha para executar uma aplicação (isto nos ajudará a reconhecer o que é um recipiente e o que o torna tão poderoso do que outras soluções):

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

1) a pilha do servidor tradicional consiste num servidor físico que executa um sistema operativo e a sua aplicação.

Vantagens:

• Utilização de matérias-primas recursos

• 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 de VM consiste num servidor físico que executa um sistema operativo e um hipervisor que gere a sua máquina virtual, recursos partilhados e interface de rede. Cada Vm corre um sistema operacional convidado, uma aplicação ou um conjunto de aplicações.

Vantagens:

• boa utilização dos recursos
• fácil de escalar
Fácil de fazer backup e migrar
• relação custo / eficácia
• flexibilidade

Desvantagens:

• a afectação de recursos é problemática
• vendedor lockin
• configuração complexa

3) a configuração do contentor , a chave a diferença com outras stack é que a virtualização baseada em container usa o núcleo do sistema operacional host para rum múltiplas instâncias isoladas. Estes exemplos de convidados são chamados de containers. O host pode ser um servidor físico ou VM.

Vantagens:

• isolamento
• peso leve
• recursos eficazes
Fácil de migrar
• Segurança
• despesas gerais baixas
• produção e desenvolvimento espelhados Ambiente

Desvantagens:

• A Mesma Arquitectura
• aplicações pesadas de Recursos
Questões de rede e segurança.

Comparando a configuração do contentor com os seus antecessores, podemos concluir que a contenção é a configuração mais rápida, mais eficaz e mais segura que conhecemos até à data. Os contentores são casos isolados que executam a sua aplicação. acoplador roda o recipiente de uma forma, camadas obter memória de tempo de execução com drivers de armazenamento padrão (drivers sobrepostos) que funcionam dentro de segundos e camada copy-on-write criado em cima dele, uma vez que nos comprometemos no container, que alimenta a execução de containers.No caso de VM's que levará cerca de um minuto para carregar tudo para o ambiente virtualizado. Estas 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. Vantagem os contentores são tão convincentes que estão aqui para ficar.

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

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

No Docker, os containers compartilham o kernel com a máquina; 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 está ociosa durante muitas das vezes. No Docker, os containers não são alocados com quantidade fixa de recursos de hardware e é livre de usar os recursos dependendo dos requisitos e, portanto, é altamente escalável.

O 'Docker' usa o sistema de ficheiros da União .. O Docker usa uma tecnologia copy-on-write para reduzir o espaço de memória consumido pelos recipientes. Leia mais aqui

Com uma máquina virtual, temos um servidor, temos um sistema operacional host nesse servidor, e depois temos um hipervisor. E então correndo em cima daquele hipervisor, temos qualquer número de sistemas operacionais com uma aplicação e seus binários dependentes, e bibliotecas naquele servidor. Traz consigo todo um sistema operativo de hóspedes. É muito pesado. Também há um limite para o quanto você pode realmente colocar em cada físico maquina.

Por outro lado, os contentores para Docker são ligeiramente diferentes. Temos o servidor. Temos o sistema operativo. Mas em vez de um hipervisor , temos o motordo acoplador , neste caso. Neste caso, não vamos levar um sistema operativo de hóspedes connosco. estamos a trazer uma camada muito fina do sistema operativo, e o contentor pode descer para o sistema operativo, a fim de chegar à funcionalidade do kernel la. E isso nos permite ter um recipiente muito leve.

Tudo o que tem lá é o código da aplicação e quaisquer binários e bibliotecas que ele requer. E esses binários e bibliotecas podem ser compartilhados em diferentes contêineres, se você quiser que eles também sejam. E o que isso nos permite fazer, é uma série de coisas. Eles têm tempo de arranque muito mais rápido . Não consegues levantar um único VM em alguns segundos assim. E igualmente, derrubá-los tão rapidamente.. para que possamos escalar para cima e para baixo muito rapidamente e veremos isso mais tarde.

Cada contentor pensa que está a funcionar na sua própria cópia do sistema operativo. Tem o seu próprio sistema de ficheiros, registo próprio, etc. o que é uma espécie de mentira. Está a ser virtualizado.

Usei muito o estivador em ambientes de produção e encenação. Quando você se acostumar com isso você vai encontrá-lo muito poderoso para a construção de um multi container e ambientes isolados.

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

Os contentores do Cais são ambientes isolados. Você poderá vê-lo quando emitir o comando top num contentor de Docker que foi criado a partir de um 'Docker' imagem. Além disso, 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 ficheiro do DockerFile e dizer que, por exemplo, quando estiver em execução, então wget 'this', apt-get 'that', executar 'some shell script', definir variáveis de ambiente e assim por diante.

Em projectos de micro-serviços e o programador de arquitectura é um activo muito viável. Você pode alcançar escalabilidade, resiliência e elasticidade com o Docker, o Docker enxame, Kubernetes e Docker Compose.

Outra questão importante em relação ao Docker é o Docker Hub e a sua comunidade. Por exemplo, implementei um ecossistema para monitorar kafka usando Prometheus, Grafana, Prometheus-JMX-exportador, e Dokcer.

Para fazer o que eu baixei configurado janela de Encaixe recipientes para o tratador, kafka, Prometheus, Grafana e jmx-coletor, em seguida, montei o meu próprio configuração para alguns deles, usando yml arquivos de ou para outros mudei alguns arquivos de configuração e, em o container Docker e eu construímos um sistema inteiro para monitorar kafka usando Acopladores multi-containers em uma única máquina com isolamento, escalabilidade e resiliência que esta arquitetura pode 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 o seu próprio painel de imagens do Docker lá e puxar/empurrar para/a partir dele. Você pode até importar imagens do Docker Hub para o quay e depois executá - las do quay por conta própria. maquina. Nota: aprender Docker em primeiro lugar parece complexo e difícil, mas quando você se acostuma a ele então você não pode trabalhar sem ele. Lembro-me dos primeiros dias de trabalho com o Docker quando emiti os comandos errados ou removi os meus contentores e todos os dados e configurações erradamente.

É assim que o Docker se apresenta:

A Docker é a empresa que conduz o movimento do contentor e a única fornecedor de plataforma de contêineres para abordar todas as aplicações em toda a nuvem híbrida. Os negócios de hoje estão sob pressão para digitalmente transformar, mas são limitados por aplicações existentes e infra-estrutura ao mesmo tempo que racionaliza um portfólio cada vez mais diversificado of clouds, datacenters and application architectures. Acoplador activa verdadeiro independência entre aplicações e infra-estruturas e desenvolvedores e operações de TI para desbloquear seu potencial e criar um modelo para uma melhor colaboração e inovação.

Então o 'Docker' {[3] } é baseado em contentores, o que significa que tem imagens e contentores que podem ser rodados na sua máquina actual. Não inclui o sistema operacional como VM s, mas como um pacote de diferentes pacotes de trabalho como Java, Tomcat, etc.

Se compreenderes contentores, ficas com o que é o Docker. e como é diferente de VM s...

Então, o que é um contentor?

Uma imagem de contentor é um pacote leve, independente e executável de um pedaço de software que inclui tudo o necessário para executá - lo: código, tempo de execução, ferramentas de Sistema, bibliotecas de sistemas, configurações. Disponível para ambos Aplicativos baseados em Linux e Windows, softwares containerizados serão sempre executados o mesmo, independentemente do ambiente. Isolamento do software dos contentores do seu entorno, por exemplo diferenças entre desenvolvimento e ambientes de estadiamento e ajudar a reduzir os conflitos entre as equipas em execução software diferente na mesma infra-estrutura.

Como você vê na imagem abaixo, cada recipiente tem uma embalagem separada e rodando em uma única máquina compartilha o sistema operacional da máquina... Eles são seguros e fáceis de enviar...

Há aqui muitas respostas técnicas agradáveis que discutem claramente as diferenças entre VMs e contentores, bem como as origens do Docker. Para mim, a diferença fundamental entre VMs e Docker é como você gerencia a promoção de sua aplicação.

Com VMs você promove sua aplicação e suas dependências de um VM para o próximo DEV para UAT para PRD.

Muitas vezes estes VM terão diferentes patches e bibliotecas.
1. não é invulgar para múltiplas aplicações para compartilhar uma VM. Isto requer a gestão de configuração e dependências para todas as aplicações.
2. a retirada requer a anulação de alterações na VM. Ou restaurá-lo, se possível.

Com o Docker, a ideia é que você acumule a sua aplicação dentro do seu próprio recipiente, juntamente com as bibliotecas de que necessita e, em seguida, promova o recipiente inteiro como uma única unidade.

1. excepto para o 'kernel', os 'patches' e as bibliotecas são idêntico.
2. Como regra geral, existe apenas uma aplicação por contentor que simplifica a configuração.
3. O Backout consiste em parar e apagar o contentor.

Então, no nível mais fundamental com o VMs você promove a aplicação e suas dependências como componentes discretos enquanto com o Docker você promove tudo em um só hit. E sim, há problemas com os contentores, incluindo a sua gestão, embora ferramentas como o Kubernetes ou o Docker estejam muito simplifique a tarefa.

Fonte: Kubernetes em acção.