Respostas:
Nas Perguntas frequentes do Docker :
O Docker não substitui o lxc. "lxc" refere-se aos recursos do kernel do linux (especificamente espaços para nome e grupos de controle) que permitem processos de sandboxing uns dos outros e controlam suas alocações de recursos.
Além dessa base de baixo nível dos recursos do kernel, o Docker oferece uma ferramenta de alto nível com várias funcionalidades poderosas:
Implantação portátil em máquinas.O Docker define um formato para agrupar um aplicativo e todas as suas dependências em um único objeto que pode ser transferido para qualquer máquina habilitada para o docker e executado lá com a garantia de que o ambiente de execução exposto ao aplicativo será o mesmo. O Lxc implementa o processo de sandbox, que é um pré-requisito importante para a implantação portátil, mas isso por si só não é suficiente para a implantação portátil. Se você me enviasse uma cópia do seu aplicativo instalado em uma configuração lxc personalizada, ele certamente não seria executado na minha máquina da mesma forma que na sua, porque está vinculado à configuração específica da sua máquina: rede, armazenamento, registro, distribuição, etc. O Docker define uma abstração para essas configurações específicas da máquina, para que o mesmo contêiner do docker possa ser executado - inalterado - em muitas máquinas diferentes,
Centrado no aplicativo. O Docker é otimizado para a implantação de aplicativos , ao contrário de máquinas. Isso se reflete em sua API, interface do usuário, filosofia de design e documentação. Por outro lado, os scripts auxiliares do lxc focam nos contêineres como máquinas leves - basicamente servidores que inicializam mais rapidamente e precisam de menos memória ram. Achamos que há mais contêineres do que apenas isso.
Construção automática . O Docker inclui uma ferramenta para que os desenvolvedores montem automaticamente um contêiner a partir de seu código-fonte, com controle total sobre as dependências de aplicativos, ferramentas de construção, empacotamento etc. Eles são livres para usar make, maven, chef, fantoche, salt, pacotes debian, rpms, source tarballs ou qualquer combinação dos itens acima, independentemente da configuração das máquinas .
Versionamento. O Docker inclui recursos semelhantes ao git para rastrear versões sucessivas de um contêiner, inspecionando a diferença entre versões, enviando novas versões, revertendo etc. O histórico também inclui como um contêiner foi montado e por quem, para que você tenha total rastreabilidade no servidor de produção todo o caminho de volta ao desenvolvedor upstream. O Docker também implementa uploads e downloads incrementais, semelhantes ao "git pull", para que novas versões de um contêiner possam ser transferidas apenas enviando diffs.
Reutilização de componentes. Qualquer contêiner pode ser usado como uma "imagem base" para criar componentes mais especializados. Isso pode ser feito manualmente ou como parte de uma construção automatizada. Por exemplo, você pode preparar o ambiente python ideal e usá-lo como base para 10 aplicativos diferentes. Sua configuração ideal do postgresql pode ser reutilizada para todos os seus projetos futuros. E assim por diante.
Partilha. O Docker tem acesso a um registro público ( https://registry.hub.docker.com/ ), onde milhares de pessoas fizeram upload de contêineres úteis: qualquer coisa, desde redis, couchdb, postgres a bouncers irc, trilhos para servidores de aplicativos, trilhos de servidores de aplicativos e hadoop para basear imagens para várias distribuições. O registro também inclui uma "biblioteca padrão" oficial de contêineres úteis mantidos pela equipe do docker. O registro em si é de código aberto, para que qualquer pessoa possa implantar seu próprio registro para armazenar e transferir contêineres particulares, por exemplo, para implantações internas de servidores.
Ecossistema de ferramentas. O Docker define uma API para automatizar e personalizar a criação e implantação de contêineres. Há um grande número de ferramentas integradas ao docker para ampliar seus recursos. Implantação do tipo PaaS (Dokku, Deis, Flynn), orquestração de vários nós (maestro, sal, mesos, openstack nova), painéis de gerenciamento (docker-ui, horizonte de open -ack, estaleiro), gerenciamento de configuração (chef, fantoche), integração contínua (jenkins, strider, travis) etc. O Docker está se estabelecendo rapidamente como o padrão para ferramentas baseadas em contêineres.
Eu espero que isso ajude!
Vamos dar uma olhada na lista de recursos técnicos do Docker e verificar quais são fornecidos pelo LXC e quais não.
1) Isolamento do sistema de arquivos : cada contêiner de processo é executado em um sistema de arquivos raiz completamente separado.
Fornecido com LXC comum.
2) Isolamento de recursos : recursos do sistema como CPU e memória podem ser alocados de maneira diferente para cada contêiner de processo, usando cgroups.
Fornecido com LXC comum.
3) Isolamento de rede : cada contêiner de processo é executado em seu próprio namespace de rede, com uma interface virtual e um endereço IP próprio.
Fornecido com LXC comum.
4) Cópia na gravação : os sistemas de arquivos raiz são criados usando a cópia na gravação, o que torna a implantação extremamente rápida, barata na memória e no disco.
Isso é fornecido pelo AUFS, um sistema de arquivos de união do qual o Docker depende. Você pode configurar o AUFS manualmente manualmente com o LXC, mas o Docker o usa como padrão.
5) Log : os fluxos padrão (stdout / stderr / stdin) de cada contêiner de processo são coletados e registrados para recuperação em tempo real ou em lote.
O Docker fornece isso.
6) Gerenciamento de alterações: as alterações no sistema de arquivos de um contêiner podem ser confirmadas em uma nova imagem e reutilizadas para criar mais contêineres. Nenhum modelo ou configuração manual necessária.
"Configuração de modelo ou manual" é uma referência ao LXC, onde você precisaria aprender sobre essas duas coisas. O Docker permite tratar contêineres da maneira que você está acostumado a tratar máquinas virtuais, sem aprender sobre a configuração do LXC.
7) Shell interativo : o docker pode alocar um pseudo-tty e anexar à entrada padrão de qualquer contêiner, por exemplo, para executar um shell interativo descartável.
O LXC já fornece isso.
Apenas comecei a aprender sobre o LXC e o Docker, por isso gostaria de receber quaisquer correções ou respostas melhores.
unshareferramenta básica (ou diretamente o clone()syscall). Da mesma forma, o Docker torna essas coisas mais fáceis de usar (e traz muitos outros recursos para a mesa, como a capacidade de empurrar / puxar imagens). Meu 2c.
update-indexe read-tree, sem ferramentas familiares como add, commit, e merge. O Docker fornece essa camada de "porcelana" sobre o "encanamento" do LXC, permitindo que você trabalhe com conceitos de nível superior e se preocupe menos com os detalhes de nível inferior.
O post e as respostas acima estão rapidamente ficando obsoletos, à medida que o desenvolvimento do LXD continua aprimorando o LXC . Sim, eu sei que Docker também não ficou parado.
O LXD agora implementa um repositório para imagens de contêineres LXC, das quais um usuário pode enviar / enviar por push para contribuir ou reutilizar.
A API REST do LXD para LXC agora permite a criação / implantação / gerenciamento local e remoto de contêineres LXC usando uma sintaxe de comando muito simples.
Os principais recursos do LXD são:
Agora existe o plugin NCLXD para o OpenStack, permitindo que o OpenStack utilize o LXD para implantar / gerenciar contêineres LXC como VMs no OpenStack em vez de usar KVM, vmware etc.
No entanto, o NCLXD também permite uma nuvem híbrida de uma mistura de VMs tradicionais de HW e VMs LXC.
O plug-in OpenStack nclxd, uma lista de recursos suportados, inclui:
stop/start/reboot/terminate container
Attach/detach network interface
Create container snapshot
Rescue/unrescue instance container
Pause/unpause/suspend/resume container
OVS/bridge networking
instance migration
firewall support
Quando o Ubuntu 16.04 for lançado em abril de 2016, haverá recursos interessantes adicionais, como suporte a dispositivos de bloco e suporte a migração ao vivo .
As janelas de encaixe usam imagens criadas em camadas. Isso adiciona muito em termos de portabilidade, compartilhamento, controle de versão e outros recursos. Essas imagens são muito fáceis de portar ou transferir e, como estão em camadas, as alterações nas versões subseqüentes são adicionadas em forma de camadas sobre as camadas anteriores. Portanto, ao portar várias vezes, você não precisa portar as camadas de base. Os estivadores têm contêineres que executam essas imagens com o ambiente de execução contido; eles adicionam alterações como novas camadas, proporcionando fácil controle de versão.
Além disso, o Docker Hub é um bom registro com milhares de imagens públicas, onde você pode encontrar imagens com SO e outros softwares instalados. Assim, você pode obter um bom avanço para sua aplicação.
Para manter esse nível, isso já foi solicitado e respondido acima .
No entanto, eu daria um passo para trás e responderia de maneira um pouco diferente, o próprio mecanismo de encaixe adiciona a orquestração como um de seus extras e essa é a parte disruptiva. Quando você começa a executar um aplicativo como uma combinação de contêineres executando 'em algum lugar' em vários mecanismos de contêineres, fica realmente emocionante. Robustez, Escala Horizontal, abstração completa do hardware subjacente, eu poderia continuar ...
Não é apenas o Docker que fornece isso; de fato, o padrão de orquestração de contêiner de fato é o Kubernetes, que vem em vários sabores, o Docker, mas também o OpenShift, SuSe, Azure, AWS ...
Então, abaixo do K8S, existem motores de contêineres alternativos; os interessantes são o Docker e o CRIO - recentemente construídos, sem daemon, destinados como um mecanismo de contêiner especificamente para o Kubernetes, mas imaturos. É a competição entre esses que eu acho que será a verdadeira escolha a longo prazo para um mecanismo de contêiner.