web-dev-qa-db-fra.com

Ajout d'un répertoire hôte partagé à un conteneur LXC / LXD

J'ai expérimenté LXC/LXD sur Ubuntu 14.04 et tout fonctionne très bien. Je dois juste comprendre comment obtenir des répertoires partagés fonctionnant entre ma machine hôte et un conteneur afin de pouvoir abandonner Virtualbox une fois pour toutes.

J'ai vu cette page: https://wiki.gentoo.org/wiki/LXD

Ce qui fournit des instructions, mais je continue juste à avoir des erreurs.

Est-ce que quelqu'un connaît des instructions simples et claires pour que cela fonctionne? Toute aide très appréciée.

lxclxd
18
user47227

J'ai maintenant une solution sûre et efficace à ce problème, utilisant des profils LXD pour gérer le mappage entre UID et GID dans le conteneur et sur l'hôte.

Un Gist très utile peut être trouvé ici:

https://Gist.github.com/bloodearnest/ebf044476e70c4baee59c5000a10f4c8

0
user47227

Les instructions sur https://wiki.gentoo.org/wiki/LXD que vous mentionnez sont correctes mais nécessitent peut-être un peu plus d'explications.

Sur l'hôte, vous vérifiez d'abord la propriété du répertoire dans lequel les données du conteneur sont stockées. Courir

Sudo ls -l /var/lib/lxd/containers

et cochez le propriétaire du conteneur avec lequel vous souhaitez partager le répertoire. Dans mon cas, uid et gid étaient tous deux 100000.

Ensuite, utilisez-les pour changer la propriété du répertoire que vous voulez partager:

Sudo chown 100000:100000 /tmp/share_on_Host

Partagez le répertoire avec le conteneur de la manière indiquée dans votre commentaire:

lxc config device add mycontainer sharedtmp disk \
                  path=/tmp/share_on_guest source=/tmp/share_on_Host

Maintenant, dans le conteneur, vous verrez que le répertoire /tmp/share_on_guest (je ne conseillerais pas de monter votre répertoire en tant que /tmp car il est utilisé par le système pour d’autres éléments et dispose d’autorisations spéciales) appartient à root. À partir de là, vous pouvez utiliser chown dans le conteneur pour remplacer le propriétaire par les noms uid et gid appropriés pour votre utilisateur dans le conteneur.

En remarque, après avoir modifié la propriété dans le conteneur, par exemple, Un utilisateur avec uid 33 vous verrez sur l'hôte que le uid est maintenant 100033, ce qui est tout à fait logique.

19
ph0t0nix

Voici une réponse mise à jour à cette question.

Montez le dossier hôte /var/www en tant que /var/test dans le conteneur.

lxc config device add mycontainer vartest disk source=/var/www path=/var/test
3
Guest8354542556745

Vous pouvez affecter des périphériques supplémentaires au conteneur, qui peuvent être des dossiers accessibles à l'hôte.

$ lxc config ## display help
...
lxc config device add [<remote>:]<container> <device> <type> [key=value...]
    Add a device to a container.
...

Notez que <device> est simplement un nom arbitraire que vous attribuez, qui sera utilisé comme identifiant pour la gestion ultérieure du périphérique.

Par exemple, pour monter le dossier de l'hôte "./Host" en tant que "/ mnt/Host" dans le conteneur ...

lxc config device add mycontainer vartest disk source=$(pwd)/Host path=/mnt/Host

Il reste un problème - si vous souhaitez que ce dossier soit accessible en écriture à la fois à l'hôte et au conteneur, la propriété et les autorisations doivent être configurées en conséquence. Cela est compliqué par le mode par défaut de LXD qui virtualise les plages numériques pour les valeurs utilisateur et groupe idname__. Il existe cependant une solution simple : contourner cette virtualisation en configurant le conteneur pour qu'il s'exécute avec des privilèges équivalents à l'hôte ...

lxc config set <container> security.privileged true

Les implications complètes de cette approche pour la sécurité de l'hôte ne me sont pas claires pour le moment, mais sembleraient être quelque peu "contenues" par la virtualisation. Le risque pratique dépend de comment et pourquoi vous allez utiliser le conteneur. Voir les notes techniques sur https://insights.ubuntu.com/2017/06/15/custom-user-mappings-in-lxd-containers

Notez en outre que cette approche fonctionne probablement mieux si vous opérez normalement dans le conteneur en tant qu'utilisateur non root, par exemple si vous vous connectez avec ...

lxc exec zesty -- su --login ubuntu
3
nobar