Il existe également une excellente série de billets de blog de Stéphane Graber, responsable technique de LXD chez Canonical Ltd, publiés ici :

https://www.stgraber.org/2016/03/11/lxd-2-0-blog-post-series-012/

et ici :

http://insights.ubuntu.com/2016/03/14/the-lxd-2-0-story-prologue/

LXC vs LXD

Les articles de blog sont agréables et informatifs et il est bon de les lire pour commencer, mais ils ne constituent pas une bonne documentation une fois que vous avez commencé. Si vous êtes comme moi, il se peut que vous ayez une idée assez claire de la différence entre Docker et LXC/LXD après avoir lu seulement quelques articles de blog couramment trouvés à ce sujet. Mais la différence entre l'ancien projet LXC et le nouveau projet LXD n'était pas du tout claire pour moi, et la plupart des pages que j'ai trouvées ne font pas un bon travail d'explication d'une manière que je pourrais comprendre. Elles essaient surtout de dissiper la confusion entre un conteneur d'application (Docker) et un conteneur de système d'exploitation (LXC/LXD). Puis j'ai trouvé cet article de blog : Quelle est la place de lxd ?

Comme vous le savez peut-être déjà, tous ces outils (Docker/LXC/LXD) utilisent des fonctionnalités communes du noyau, comme les espaces de noms et les groupes de noms, mais il s'agit simplement de savoir comment l'espace utilisateur décide de les utiliser. Un résumé du post ci-dessus s'est concentré sur l'évolution de LXC par rapport à LXD, d'après ma compréhension :

• LXC a été créé à l'origine pour tester les nouvelles fonctionnalités du noyau ; en tant que tel, c'était un méli-mélo de Shell Shell et de programmes C (encore utilisés aujourd'hui via les "anciens" outils de ligne de commande LXC).
• Il a ensuite été refactorisé en une bibliothèque. Les outils de ligne de commande en espace utilisateur LXC existants utilisent maintenant cette bibliothèque.
• LXD est une nouvelle méthode d'interfaçage avec cette bibliothèque qui ne s'encombre pas de la rétrocompatibilité avec les anciens outils de ligne de commande LXC. Il est donc plus facile à utiliser et plus performant.

_{Si quelqu'un (comme un mainteneur) voit des erreurs ci-dessus, n'hésitez pas à corriger ma réponse :)}

Quelques notes sur libvirt-lxc

En outre, si vous envisagez libvirt-lxc (par exemple, si vous utilisez déjà l'option libvirt avec KVM) :

• Red Hat l'a déprécié : https://access.redhat.com/articles/1365153
• Upstream dit qu'ils vont continuer à travailler dessus : https://www.redhat.com/archives/libvirt-users/2015-August/msg00026.html
• Même si libvirt-lxc a lxc dans le nom, il n'utilise pas réellement lxc et utilise directement les fonctionnalités du noyau. Il ne faut donc pas confondre libvirt conducteur avec lxc malgré la confusion des noms. Référence : http://libvirt.org/drvlxc.html (Notez que je pense que proxmox fait utilice lxc approprié, mais pas le plus récent lxd outils).
• Stéphane Graber suggère d'utiliser libvirt avec les conteneurs est mal adapté, et que si quelqu'un pouvait concevoir d'écrire une libvirt-lxd il pense que c'est aussi un mauvais ajustement. En résumé : libvirt est conçu pour gérer les VM et les conteneurs ne sont pas des VM. Les choses se compliquent donc et vous ne prenez en charge qu'un dénominateur commun de fonctionnalités. Référence : https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-November/010820.html
• Pour renforcer le précédent, il n'est pas si facile de créer de nouveaux conteneurs avec libvirt-lxc . Par exemple, vous devez lui donner un chemin vers un rootfs EXISTANT pour un nouveau conteneur que vous voulez créer, et il n'y a pas de support dans libvirt-lxc pour le faire tourner. Il ne vous reste donc plus qu'à utiliser des outils externes tels que lxc-create pour créer un nouveau conteneur à partir d'un modèle, et ensuite faire un nouveau libvirt-lxc en utilisant le répertoire existant qui vient d'être créé, ce qui me laisse alors me demander : "pourquoi s'embêter avec libvirt-lxc au lieu d'utiliser simplement lxd directement ?"

Documentation LXD

Pour en revenir à votre question, j'ai essayé de rassembler toute la documentation de référence sur LXD que j'ai pu trouver. Il y a de la bonne documentation ici :

https://github.com/lxc/lxd/tree/master/doc

En particulier :

• configuration.md propose une liste de référence des options de configuration possibles.
• imagehandling.md explique comment les images du système d'exploitation sont mises en cache localement.
• lxd-ssl-authentication.md traite de l'API REST et de la manière dont elle est exposée à la fois sur un socket UNIX local et, éventuellement, sur HTTPS, ainsi que de la manière dont elle est sécurisée.
• storage-backends.md discute des limitations et de la configuration de chaque backend de stockage.
• userns-idmap.md Par défaut, lxd utilise des conteneurs non privilégiés, ce qui signifie que les UID/GID des conteneurs doivent être mis en correspondance avec les UID/GID des hôtes.
• Une grande partie de la documentation restante n'est pas aussi critique à lire, ou est plus orientée vers les développeurs.

Les liens ci-dessus proviennent de la branche master de lxd en amont, vous pouvez donc vérifier le doc pour les sources du paquet que vous avez réellement installé, afin de ne pas utiliser accidentellement une nouvelle fonctionnalité que vous n'avez pas encore installée.

Il n'y a pas vraiment beaucoup de pages de manuel, mais voici ce que j'ai trouvé inclus dans la page d'accueil du site web. lxd y lxd-client paquets :

• LXC(1) - programme client pour communiquer avec le démon serveur. Actuellement (14/5/2016) plutôt inutile et peu informatif. Espérons qu'à l'avenir une série de manpages puisse être faite pour cet outil, un peu comme le btrfs manpages.
• LXD(1) - ligne de commande du démon serveur.

Bien sûr, il y a aussi la page du guide du serveur : https://help.ubuntu.com/lts/serverguide/lxd.html

Enfin, rappelez-vous que lxd est basé sur la bibliothèque lxc (mais pas sur les anciens outils de ligne de commande lxc). Cela signifie que la configuration de lxc peut toujours être effectuée directement, par exemple en utilisant les outils suivants raw.lxc option de configuration en lxd. Par conséquent, une référence à la configuration LXC sous-jacente est utile, mais n'oubliez pas qu'elle doit être évitée si possible pour éviter un conflit avec LXD (par exemple, si vous définissez le même élément de configuration dans LXD et LXC). Vous pouvez fouiller dans les pages de manuel pour les trouver si nécessaire : https://linuxcontainers.org/lxc/manpages/