LXC vs LXD
As postagens do blog são agradáveis & amp; informativo e bom de ler para começar, mas boa documentação que eles não fazem uma vez que você começou. Se você é como eu, pode ser bastante claro sobre a diferença entre o Docker & amp; LXC / LXD depois de ler apenas algumas postagens comuns no blog sobre isso .. Mas a diferença entre o projeto LXC mais antigo e o novo projeto LXD não foi nada claro para mim, e a maioria das páginas que encontrei simplesmente não faz um bom trabalho. trabalho explicando de uma maneira que eu pudesse entender. Principalmente eles tentam limpar a confusão entre um contêiner de aplicativo (Docker) e um contêiner do sistema operacional (LXC / LXD). Então eu encontrei este post: Onde o lxd se encaixa
Como você já deve saber, todas essas ferramentas (Docker / LXC / LXD) usam recursos comuns do kernel, como namespaces e cgroups, é apenas uma questão de como o userspace decide usá-los. Um resumo do post acima focado na evolução do LXC vs LXD, com base no meu entendimento:
- O LXC foi originalmente criado para testar os novos recursos do kernel; como tal, era uma mistura de scripts de shell e programas em C (ainda usados hoje por meio das "antigas" ferramentas de linha de comando LXC).
- Então isso foi refatorado em uma biblioteca. As ferramentas de linha de comando existentes do LXC userspace usam essa biblioteca agora.
- O LXD é uma maneira básica de fazer interface com essa biblioteca que não é afetada pela compatibilidade com versões anteriores das antigas ferramentas de linha de comando LXC. Então é mais fácil de usar e mais capaz.
Se alguém (como um mantenedor) vir alguns erros acima, sinta-se à vontade para corrigir minha resposta. :)
Algumas notas sobre libvirt-lxc
Além disso, caso você esteja considerando libvirt-lxc (por exemplo, se já estiver usando libvirt com KVM):
- Red Hat desatualizou isto: link
- A Upstream diz que ainda vai trabalhar nisso: link
- Mesmo que
libvirt-lxc tenha lxc no nome, ele não usa realmente lxc e, em vez disso, usa diretamente os recursos do kernel. Portanto, não confunda esse libvirt driver com lxc apesar da confusão de nomenclatura. Referência: link (Note que eu acho que o proxmox faz usar lxc propriamente, mas não o% mais recente co_de% tools).
- Stéphane Graber sugere que usar
lxd com contêineres é um ajuste inadequado e que, embora alguém possa escrever um libvirt , ele acha que também é um ajuste inadequado. Em resumo: libvirt-lxd é projetado para gerenciar VMs e contêineres não são VMs, portanto, as coisas ficam confusas e você só suporta um denominador comum de recursos. Referência: link
- Para reforçar o anterior, não é tão fácil criar novos contêineres com
libvirt . Por exemplo, você precisa fornecer um caminho para um rootfs EXISTING para um novo contêiner que deseja criar, e não há suporte em libvirt-lxc para gerá-lo. Assim, você pode fazer coisas como usar ferramentas externas como libvirt-lxc para criar um novo contêiner a partir de um modelo e criar um novo contêiner lxc-create usando esse diretório existente, o que me faz perguntar: "por que se preocupar com libvirt-lxc em vez de apenas usar libvirt-lxc diretamente? "
Documentação LXD
Voltando à sua pergunta, eu tentei reunir toda a documentação de referência no LXD que eu encontrei. Há alguma documentação legal aqui:
link
Em particular:
-
lxd tem uma boa lista de referência de possíveis opções de configuração.
-
configuration.md fala sobre como as imagens do sistema operacional são armazenadas em cache localmente.
-
imagehandling.md discute a API REST e como ela é exposta em ambos os soquete UNIX local e, opcionalmente, em HTTPS e como isso é assegurado.
-
lxd-ssl-authentication.md discute as limitações & amp; configuração de cada back-end de armazenamento.
-
storage-backends.md lxd por padrão usa contêineres sem privilégios, o que significa que o contêiner UID / GID deve ser mapeado para um host UID / GID; isso discute isso.
- Grande parte da documentação restante não é tão crítica para ler, ou é mais voltada para desenvolvedores.
Os links acima são da ramificação mestre de userns-idmap.md upstream, portanto, você pode querer verificar o diretório lxd das origens do pacote que você instalou, para não usar acidentalmente algum novo recurso que você não usa. ainda não foram instalados.
Não existem muitas páginas man, mas aqui está o que eu encontrei incluído nos pacotes doc e lxd :
-
lxd-client - programa cliente para se comunicar com o servidor daemon. Atualmente (14/05/2016) bastante inútil e pouco informativo. Espero que, no futuro, uma série de manpages possa ser feita para essa ferramenta, muito parecida com as% man_de% manpages.
-
LXC(1) - linha de comando do servidor daemon.
Naturalmente, há também a página do guia do servidor: link
Por fim, lembre-se de que o lxd é baseado na biblioteca lxc (mas não nas antigas ferramentas de linha de comando lxc). Isto significa que a configuração lxc ainda pode ser feita diretamente, por ex. usando a opção de configuração btrfs em lxd. Portanto, alguma referência à configuração subjacente do LXC é útil, mas lembre-se de que deve ser evitado, se possível, para evitar um conflito com o LXD (por exemplo, se você definir o mesmo item de configuração em LXD e LXC). Você pode vasculhar as páginas de manual para encontrá-las, se necessário: link